IBM Cloud Authors: Yeshim Deniz, Liz McMillan, Elizabeth White, Pat Romanski, Stefan Bernbo

Related Topics: IBM Cloud

IBM Cloud: Article

Discovering and Documenting Business Application Patterns

Discovering and Documenting Business Application Patterns

Over the past two months, we've looked at the process of extracting a business application pattern from a series of business requirements. You've seen this pattern take shape, from its original form as a design meeting the specific needs of a particular business application (configurable product balance information) through an initial abstraction that was modified by other business requirements to reach its final form. In this article, the last of a three-part series, we'll look at applying the key pattern and cached balances pattern (with others) to the construction of applications, components, and Web services.

Reviewing Our Pattern
Last month's article concluded with a definition of our business application patterns: keys and cached balances. We tracked the maturation of these patterns through their initial concept as extracted from our product balances business requirement, to their modification due to additional requirements resulting from our application's need to flexibly manage financial account balances, to their representation both as abstract patterns and reusable partial implementations of each pattern (i.e., framelets). Our final patterns included an abstracted CachedBalanceSet class containing a set of balance values associated with abstracted access keys (the AccessKey class). These keys are controlled by another set of keys that specify their scope (the SpecificationKey class), and each of these key classes in turn contains a collection of key elements that implements an abstract Keyable interface that declares comparison methods such as equals (for AccessKeyable) and convert (for SpecificationKeyable). Figures 1 and 2 reflect these concepts in terms of UML.

Patterns Within the J2EE Architectural Context
Up to this point, we have not taken into account the specific demands and restrictions placed upon our pattern by the technical architecture within which it will be deployed. In other words, our pattern provides a set of high-level design guidelines that need to be adapted for specific use. Our choice of technical architecture is J2EE, and more specifically EJB. How does the EJB framework affect our low-level design choices when applying this pattern?

As we enter into the detailed design phase, let's review the characteristics of our CachedProductBalances class (and related classes and algorithms):

  • It represents a composite set of business information related to a specific business entity; namely the Product class.
  • Its methods are self-contained; i.e., their implementations do not depend upon making calls to other business entities.
  • Its methods will typically be called within the context of a broader business process (e.g., invoking updateBalance as part of incoming shipment processing) rather than as stand-alone business functionality.

    These characteristics need to be evaluated in the context of the EJB framework and the design options that framework presents. We should also rely on the experience of others in building robust J2EE applications - after all, that's what design patterns are all about. Let's take a look at some key design aspects and see what Core J2EE Patterns has to say about them.

    Entity Bean Design - the Composite Entity Pattern
    One of the early decisions we need to make when applying our pattern to EJB technology is which classes should be implemented as entity beans. The Composite Entity pattern states "entity beans are not intended to represent every persistent object in the object model. Entity beans are better suited for coarse-grained persistent business objects." Applying this principle to our high-level design for CachedBalanceSet, we see that most classes within this design are best left as simple Java classes; in other words, they are dependent objects. Should the CachedBalanceSet class itself be implemented as an entity bean? Given the previously listed characteristics (specifically that the CachedBalanceSet method implementations are self-contained), we can make a reasonable case for implementing CachedBalanceSet as an entity bean. However, we also need to consider what its relationship to the Product class should be and how its methods interact with broader business processes, as these points may very well cause us to revisit our initial decision.

    The Product class is a natural candidate for entity bean implementation. It represents a business entity with considerable information and functional behavior, and it presents us with a natural primary key - the product ID. If we implement the Product class as an entity bean, what effect does that have on our CachedBalanceSet class? Much depends upon the behavior we choose to expose on Product's interface. If we choose to treat the Product class primarily as a data holder, maintaining information such as product name, description, ID, and the like, without incorporating additional business process-related behavior (like product balance updating and retrieval), then we maintain a loose coupling between the Product class and the CachedBalanceSet class (see Figure 3). This lends credence to our tentative decision to implement the CachedBalanceSet class as an entity bean in its own right, but raises the question as to where to contain the business process- related behavior that manages product balances.

    Another aspect of the EJB architecture that we need to take into account is our ability to choose whether an entity bean is defined as local. Local entity beans reduce overhead associated with remote calls but at the expense of limiting access to the entity object to the local process. At this point in our design process we don't have clear guidance based on the Composite Entity pattern, but as we continue to expand our design toward components and Web services, we will see that local entity beans are the best choice for our design.

    If, on the other hand, we choose to embed product balance maintenance within the Product class, we see that we have introduced tight coupling between the Product class and the CachedBalanceSet class. Such tight coupling might cause us to reconsider our earlier decision to make the CachedBalanceSet class an entity bean, instead choosing to implement the CachedBalanceSet class as a dependent Java class within the Product class implementation (see Figure 4). However, this raises another question - how much overhead does introducing these dependent classes introduce to EJB activation and passivation? If our typical use of the Product class does not involve balance management, we might be better off separating the CachedBalanceSet class from the Product class as we originally proposed. If, on the other hand, most uses of the Product class involve balance management, then embedding the product balance management code as dependent objects within the Product class is probably the right decision. If we choose this option, we may be able to mitigate the EJB activation and passivation overhead through a bean-managed persistence (BMP) approach, deferring activation of the dependent CachedBalanceSet object within the Product EJB until it is needed. In fact, this is likely to be the choice we will make for CachedBalanceSets even if we choose to implement it as a separate entity bean, given that the internal intricacy of its contained objects, in this case as it is in general, involves a series of tradeoffs.

    Session Bean Design - the Session Facade Pattern
    Let's assume that we have chosen the decoupled approach as described above, resulting in two entity beans: Product and CachedBalanceSet. Where does the business logic responsible for maintaining product balances then reside?

    Again, Core J2EE Patterns gives us a strong hint. Reading from the Session Facade pattern, we see that a session bean "...manages the business objects and provides a uniform coarse-grained service access layer to clients." There are two important points being made here, one of which is directly applicable to our specific problem - session beans should be designed to manage underlying business objects. (We'll consider the second point when we discuss the relationship of Web services to components.) By introducing a WarehouseManagement session bean following the Session Facade pattern, we now have a natural place to locate our product balance maintenance implementation (along with many other business process-related algorithms that span products, warehouses, and other related business concepts such as lead and shipping time calculations (see Figure 5). By doing so, we have in fact created a coarse-grained component - one that presents a series of business services to clients without exposing those clients to the underlying complexity inherent in the implementation of those services. This approach also reinforces our earlier decision to separate product balance maintenance logic from the Product entity bean and maintain loose coupling between the Product and CachedBalanceSet classes.

    Now that we've introduced a session bean into our design, we need to consider whether this bean should be stateful or stateless. In general, Core J2EE Patterns recommends stateless session beans, as this allows the application server to more efficiently manage its memory pool by allocating beans out of a bean cache on a method-by-method basis. If, however, there is a need to maintain client session state outside of the client itself, then a stateful session bean approach may be warranted. In our case, we will assume that the stateless session bean approach is appropriate.

    Other design patterns may come into play as we drop down into the detailed design of our WarehouseManagement session bean. For example, we might choose to implement each of the methods our session bean exposes using the Strategy pattern, thus making our session bean highly configurable. Individual strategy implementations might in turn use the TemplateMethod pattern to provide a partially built algorithm that can be customized on a point-by-point basis. These are just a couple of examples of how design patterns can influence detailed design decisions.

    Bringing Web Services into the Picture
    Server-Side Considerations - the Transfer Object Pattern

    Now that we have our coarse-grained business services defined, we need to adapt them to the needs of potential clients. One type of client that is of considerable interest these days is remote invocation via a Web service. Web service- based invocation involves transmission of a client request to a remote service via an XML message whose format is specified by SOAP, typically transmitted over Internet protocols such as TCP/IP and HTTP. Introduction of this XML-based invocation into the picture adds some additional design restrictions above and beyond those created by the base J2EE architecture.

    Specifically, because our client communicates with our service via XML documents rather than remote objects (as would be the case in an n-tier J2EE implementation with JSPs and servlets invoking session bean methods through their remote interfaces via RMI), we need to ensure that the interface presented by our server component is easily consumable by the SOAP client and does not introduce a lot of overhead at the component (i.e., session bean) interface.

    The Transfer Object pattern provides us with an approach for consolidating the business information to be communicated between client and server. This pattern encourages the use of simple Java classes to encapsulate business data exposed on the public interface of a coarse-grained component. These simple data-oriented Java classes can then be easily processed by the serializer/deserializer logic provided by SOAP development and runtime frameworks such as those following the JAX-RPC specification.

    Client-Side Considerations - the Proxy and Business Delegate Patterns
    Remote Web services clients typically interact with a service via object-oriented proxies that are often generated by specialized Web services development tools from the WSDL document describing the service. These simple proxy classes provide individual methods for each of the operations described by the WSDL document. Each method directly invokes the underlying service (in our case the coarse-grained component implemented by our WarehouseManagement session bean) via the SOAP-based framework provided by the Web services runtime.

    In some cases, these directly generated client methods will be sufficient. There may be cases, however, in which it is desirable for the client to have an additional level of decoupling from the services it invokes. For example, we might choose to build up a cache of recently accessed product information to minimize remote activity and thus improve performance of our client, or we might want to build up a consolidated client view over multiple Web services. The Business Delegate pattern describes an approach that supports this level of isolation. Client activities occur solely through a client-side class, the Business Delegate, which in turn delegates any necessary remote invocations to the underlying business service (in this case our generated SOAP client). Because the Business Delegate class is interposed between the client code and the SOAP client, we have the freedom to introduce client-side caching for frequently accessed information, consolidated service groupings with embedded glue logic, or other useful features. The Business Delegate class can also serve as a stable interface point for the remainder of the client code, isolating any client-side changes that might result from changing server-side implementations to a single touch point.

    Figure 6 shows our full set of patterns working in concert from client to server through a client request scenario. As you can see, by defining our pattern independently of the technical architecture, we were able to easily take advantage of a number of useful concepts:

  • Grouping related business function into loosely coupled entities with embedded dependent objects - the Composite Entity pattern
  • Providing cross-entity business process functionality via an encapsulating facade - the Session Facade pattern
  • Consolidating the business information transferred between client and server into simple data-oriented objects - the Transfer Object pattern
  • Accessing server-side functionality via client-side proxies - the Proxy pattern
  • Introducing additional client-side isolation classes to support service consolidation, client-side caching, and other advanced client-side capabilities - the Business Delegate pattern

    Underneath it all reside our original business patterns, doing the heavy lifting of managing our product balances.


  • Alur, D.; Crupi, J.; and Malks, D. (2001). Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall.
  • Gamma, E.; Helm, R.; Johnson, R.; and Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
  • Carey, J. and Carlson, B. (2002). Framework Process Patterns: Lessons Learned Developing Application Frameworks. Addison-Wesley.
  • Carey, J.; Carlson, B.; Graser, T.; and Varlson, B. (2000). SanFrancisco Design Patterns: Blueprints for Business Software. Addison-Wesley.
  • More Stories By Brent Carlson

    Brent Carlson is vice president of technology and cofounder of LogicLibrary, a provider of software development asset (SDA) management tools. He is the coauthor of two books: San Francisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey). He also holds 16 software patents, with eight more currently under evaluation.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
    The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...