IBM Cloud Authors: Pat Romanski, Liz McMillan, Yeshim Deniz, Carmen Gonzalez, Elizabeth White

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.

    @ThingsExpo Stories
    BnkToTheFuture.com is the largest online investment platform for investing in FinTech, Bitcoin and Blockchain companies. We believe the future of finance looks very different from the past and we aim to invest and provide trading opportunities for qualifying investors that want to build a portfolio in the sector in compliance with international financial regulations.
    A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, whic...
    Imagine if you will, a retail floor so densely packed with sensors that they can pick up the movements of insects scurrying across a store aisle. Or a component of a piece of factory equipment so well-instrumented that its digital twin provides resolution down to the micrometer.
    In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settle...
    Product connectivity goes hand and hand these days with increased use of personal data. New IoT devices are becoming more personalized than ever before. In his session at 22nd Cloud Expo | DXWorld Expo, Nicolas Fierro, CEO of MIMIR Blockchain Solutions, will discuss how in order to protect your data and privacy, IoT applications need to embrace Blockchain technology for a new level of product security never before seen - or needed.
    Leading companies, from the Global Fortune 500 to the smallest companies, are adopting hybrid cloud as the path to business advantage. Hybrid cloud depends on cloud services and on-premises infrastructure working in unison. Successful implementations require new levels of data mobility, enabled by an automated and seamless flow across on-premises and cloud resources. In his general session at 21st Cloud Expo, Greg Tevis, an IBM Storage Software Technical Strategist and Customer Solution Architec...
    Nordstrom is transforming the way that they do business and the cloud is the key to enabling speed and hyper personalized customer experiences. In his session at 21st Cloud Expo, Ken Schow, VP of Engineering at Nordstrom, discussed some of the key learnings and common pitfalls of large enterprises moving to the cloud. This includes strategies around choosing a cloud provider(s), architecture, and lessons learned. In addition, he covered some of the best practices for structured team migration an...
    No hype cycles or predictions of a gazillion things here. IoT is here. You get it. You know your business and have great ideas for a business transformation strategy. What comes next? Time to make it happen. In his session at @ThingsExpo, Jay Mason, an Associate Partner of Analytics, IoT & Cybersecurity at M&S Consulting, presented a step-by-step plan to develop your technology implementation strategy. He also discussed the evaluation of communication standards and IoT messaging protocols, data...
    Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection between Coke and its customers. Digital signs pair software with high-resolution displays so that a message can be changed instantly based on what the operator wants to communicate or sell. In their Day 3 Keynote at 21st Cloud Expo, Greg Chambers, Global Group Director, Digital Innovation, Coca-Cola, and Vidya Nagarajan, a Senior Product Manager at Google, discussed how from store operations and ...
    In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and simple way to introduce Machine Leaning to anyone and everyone. He solved a machine learning problem and demonstrated an easy way to be able to do machine learning without even coding. Raju Shreewastava is the founder of Big Data Trunk (www.BigDataTrunk.com), a Big Data Training and consulting firm with offices in the United States. He previously led the data warehouse/business intelligence and B...
    "IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies were looking for permissioned blockchain," stated René Bostic, Technical VP of the IBM Cloud Unit in North America, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Conventi...
    When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be...
    Smart cities have the potential to change our lives at so many levels for citizens: less pollution, reduced parking obstacles, better health, education and more energy savings. Real-time data streaming and the Internet of Things (IoT) possess the power to turn this vision into a reality. However, most organizations today are building their data infrastructure to focus solely on addressing immediate business needs vs. a platform capable of quickly adapting emerging technologies to address future ...
    We are given a desktop platform with Java 8 or Java 9 installed and seek to find a way to deploy high-performance Java applications that use Java 3D and/or Jogl without having to run an installer. We are subject to the constraint that the applications be signed and deployed so that they can be run in a trusted environment (i.e., outside of the sandbox). Further, we seek to do this in a way that does not depend on bundling a JRE with our applications, as this makes downloads and installations rat...
    Widespread fragmentation is stalling the growth of the IIoT and making it difficult for partners to work together. The number of software platforms, apps, hardware and connectivity standards is creating paralysis among businesses that are afraid of being locked into a solution. EdgeX Foundry is unifying the community around a common IoT edge framework and an ecosystem of interoperable components.
    DX World EXPO, LLC, a Lighthouse Point, Florida-based startup trade show producer and the creator of "DXWorldEXPO® - Digital Transformation Conference & Expo" has announced its executive management team. The team is headed by Levent Selamoglu, who has been named CEO. "Now is the time for a truly global DX event, to bring together the leading minds from the technology world in a conversation about Digital Transformation," he said in making the announcement.
    In this strange new world where more and more power is drawn from business technology, companies are effectively straddling two paths on the road to innovation and transformation into digital enterprises. The first path is the heritage trail – with “legacy” technology forming the background. Here, extant technologies are transformed by core IT teams to provide more API-driven approaches. Legacy systems can restrict companies that are transitioning into digital enterprises. To truly become a lead...
    Digital Transformation (DX) is not a "one-size-fits all" strategy. Each organization needs to develop its own unique, long-term DX plan. It must do so by realizing that we now live in a data-driven age, and that technologies such as Cloud Computing, Big Data, the IoT, Cognitive Computing, and Blockchain are only tools. In her general session at 21st Cloud Expo, Rebecca Wanta explained how the strategy must focus on DX and include a commitment from top management to create great IT jobs, monitor ...
    "Cloud Academy is an enterprise training platform for the cloud, specifically public clouds. We offer guided learning experiences on AWS, Azure, Google Cloud and all the surrounding methodologies and technologies that you need to know and your teams need to know in order to leverage the full benefits of the cloud," explained Alex Brower, VP of Marketing at Cloud Academy, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clar...
    The IoT Will Grow: In what might be the most obvious prediction of the decade, the IoT will continue to expand next year, with more and more devices coming online every single day. What isn’t so obvious about this prediction: where that growth will occur. The retail, healthcare, and industrial/supply chain industries will likely see the greatest growth. Forrester Research has predicted the IoT will become “the backbone” of customer value as it continues to grow. It is no surprise that retail is ...