The Shape of Things to Come, Part 2–Advanced Patterns for Developing a Distributed Business System
By: D. William Reynolds, Jr.
Founder and President; Austin Software Foundry; Austin, Texas
In the April issue of Powerline (available at http://www.sybase.com/inc/powerline/powerline_q298/shape.html), I introduced the concept of software patterns and began to construct a basic application framework from a small library of standard patterns–a framework that would ultimately jump-start your use of a tool suite like Sybase® PowerStudio™ in your development. Summarizing the description of software patterns from the earlier article:
- Software patterns represent tested solutions to common problems in the form of programming- language-independent, uniform descriptions of class and object combinations. The standard presentation of these combinations, or patterns, includes object models, implementation guidelines, and examples.
- The typical business information system destined for deployment in a distributed environment faces a common set of problems, which can be addressed by a combination of less than a dozen fundamental software patterns.
- Software patterns in this distributed application framework can be grouped into three broad categories: Application patterns, Domain patterns, and Technology patterns.
The use of software patterns by a development team results in a number of benefits. Key among these are:
- Increased success for distributed application development using tool sets like Sybase's PowerStudio through the knowledge of software patterns, the "physical laws" of software engineering, and their influence on software architectures and development processes built around them.
- Increased developer productivity and more widespread application of proven solutions by a wide range of software developers because of the high level of abstraction that software patterns allow.
In the second part of this article, we'll explore several Technology and Domain patterns to flesh out the application framework we started in the last article. These patterns will include Domain patterns for implementing Use Cases and managing multiple business contexts with a single application, and Technology patterns for handling messaging, event broadcasting and notification, separation of interface and implementation classes, and integration with existing or external systems or subsystems. The article will demonstrate through the application framework how you can use a complex tool suite like Sybase's PowerStudio to implement distributed applications.
Domain Patterns
There is one more Domain pattern you'll need, in addition to the Item-Item Description pattern from the first part of the article, in any framework that provides a business architecture for a software application. (A business architecture defines how business events, processes, entities, and rules are represented in software and how that software representation interfaces with the visual presentation and underlying system infrastructure of an application to provide business functionality.) Unlike the Item-Item Description pattern, this final Domain pattern is not specific to any particular business domain. Rather, we use it across all domains to provide architectural structure to the events, rules, and policies of any domain. And the pattern has different forms, depending on where we use it in the software development lifecycle.Use Case Pattern
During business process modeling and requirements analysis, what I call the conceptual modeling process, we call this pattern the Use Case pattern, from Ivar Jacobson's name for this analysis approach: Business Use Cases. Today most successful object-oriented system development efforts begin with the identification and modeling of the major system functionality using a standard approach from the Unified Modeling Language (UML) called Use Cases. Having one or two patterns that map closely back to this modeling process dramatically improves your ability to manage and trace requirements directly from your users down into the final software application, and, almost more importantly, back again.A Business Use Case model identifies major business processes, such as accepting a new order, manufacturing a product, restocking finished goods inventory, or acquiring raw materials. The model captures the interactions of the constituents of that process–the "actors." We use five major elements to describe a use case within a Use Case pattern.
- Business Process - a business object that describes a business process or workflow and is comprised of a specified collection of entity business objects and a pattern of interactions and business events. Examples include accepting a new order, manufacturing a product, restocking finished goods inventory, and acquiring raw materials.
- Business Actor - a business object that describes the role of any person, organization, or external system as it interacts with a Business Process. Examples include order-entry clerks or assembly-line technicians, payroll systems, customers, and suppliers.
- Business Entity - a business object that describes a person, place, thing, or concept. Examples include products, agreements/contracts, orders, people, organizations, and locations.
- Business Event - a business object that describes an occurrence at a point in time, the passage of time, or crossing of a boundary in time. Examples include inventory restocking thresholds reached, capacity limits reached, accounts overdrawn, and the end of a fiscal year.
- Business Event/Condition Rule - any behavior enforced on a business process, business entity, or business event based on a set of conditions that must be met and a resulting action that must be taken. Examples include if an inventory threshold is reached, then a certain quantity of material must be ordered; or if a customer lives in a particular state, then a different sales tax rate must be used to compute an order total.
The object model below represents the resulting Use Case pattern.
Click here to view the full size image.Figure 1: Object model for the Use Case pattern.
Business Context Pattern
Once the focus of development moves to designing the software implementation, what I refer to as the logical modeling process, the Use Case pattern transforms from a description of business processes and functions into a description of how to implement those processes and functions in software. We call the logical form of the Use Case pattern the Business Context pattern. Each Use Case provides a single context in which a tightly related series of software objects, functions, messages, and events must collaborate to supply a major chunk of functionality as triggered through the user interface or other external systems. Ivar Jacobson recognizes this transformation and refers to these Use Cases as System Use Cases. The elements of the Business Context pattern include:
- Business Context - a software object that acts in the roles of Controller (from the MVC Pattern introduced earlier) and Façade (from the façade pattern introduced later) to accept incoming requests (business events) and coordinate the necessary business entities to respond to the request.
- Business Entity - a software object that implements the data and behavior of a conceptual business entity.
- Business Event - a software object that implements the data and behavior of a conceptual business event as a command (from the Command Processor pattern introduced later).
- Business Rule - a software object that implements a deterministic or heuristic rule that may later dictate the behavior of a business process, business entity, or business event within a given context.
After applying the Business Context pattern to our application framework, we simply need to expand it with a few Technology patterns to build in the flexibility and adaptability that today's distributed business systems require. At a high level, here's what the final framework will look like.
Click here to view the full size image.Figure 2: The combination of less than a dozen standard patterns provides a robust, flexible framework to guide the development of distributed applications with a suite like PowerStudio.
Technology Patterns
Enterprise-scale software applications exist in a change-dominated environment, especially those applications that support customer-facing business processes. Potential variables include changes in business and technology as well as changes in the members of the team who build and maintain each application. The successful application must then stand on an identifiable and proven foundation of software engineering principles and within an adaptable architecture. Technology patterns dictate and ensure the consistency of this architecture while affording the necessary flexibility if used correctly.Of the four patterns I've introduced so far–Multiple Document Interface (MDI), Master-Detail, Item-Item Description, and Model-View-Controller–the most important is the Model-View-Controller Technology pattern. This pattern provides a key part of the technical foundation for your application architecture, yet allows you to replace other parts of the architecture, the Application and Domain patterns, for example, with patterns more suited to your needs. The following five Technology patterns, combined with the Model-View-Controller pattern, complete that technical foundation.
Partitioning Layering Patterns
Partitioning–the most fundamental principle of distributed software development. A distributed application must be constructed of separate modules, or partitions, that can be deployed on separate computers yet still interact to present the end user with a complete system. These partitions also need to be easily modified, extended, or replaced without affecting other parts of the system. Using the Model-View-Controller pattern, we began partitioning our application framework into the application or user-interface partition, the problem domain or business partition, and the technology partition.Now we will employ the Partitioning pattern to separate fundamentally different kinds of functionality, and the Layering pattern to break a single type of functionality, like networking, into different levels of abstraction, and then combine these layers to provide the complete function or service. The Partitioning pattern is what we used to separate the Application, Domain, and Technology elements of our framework into "partitions," and the Layering pattern can be used within any of these three partitions.
The best-known example of layering is the International Standards Organization (ISO) Open Systems Interconnect (OSI) 7-Layer Model of network protocols. The functionality to physically transmit bits over a wire lies at the lowest layer. The six layers built on top of that functionality all work together to do one thing–transmit data over a network. Each layer adds a distinct capability, including data link bit sequence error correction, network routing, packet composition/decomposition and transport, session synchronization, information and semantic presentation, and finally common application-level protocols and services.
So that you can understand layering database access functionality and partitioning it from business logic, I've applied the Partitioning and Layering patterns in the Technology Partition using the PowerJ™ powersoft.powerj class library in Figure 1. You could apply these same patterns to data access functionality implemented in PowerBuilder® or Power++™ as well.
Click here to view the full size image.Figure 3: In the Technology Partition, the powersoft.powerj.db library breaks down into three layers, which combine to supply all of the functionality necessary to connect to and interact with a database. The three layers are the query layer, the result set layer, and the row/column layer.
Facade Pattern
If client classes communicate with many of the classes within a particular partition or layer, breaking a system into partitions may not reduce complexity at all. In this situation, the Façade pattern provides the simplification you need for distributed deployment. The best analogy for the Façade pattern is a movie set for a western ghost town. In this movie set, the front of all the buildings looks like simplistic, wood-frame buildings from the late 1800s, but when you walk behind them, you find these building fronts, or facades, may cover modern structures that can be reused by simply replacing the false front. In a similar function, the Façade pattern acts as the public interface to the more complex set of classes that actually implement the behaviors represented by the façade, such as storing data in a database or queuing a print job to a network printing device.In Java™, <<Interface>> classes often play the role of façade. These classes present only those methods of an implementation class that are necessary in a given context. Within the Business Context pattern, the Business Context class is an <<Implementation>> class in Java that plays the role of a façade to hide the complexity within an entire business process, or Use Case.
Click here to view the full size image.Figure 4: A Façade pattern provides a single, simplified interface to more general, complex functions of a subsystem, module, component, or class.
Adapter Pattern
Two of the most difficult issues to deal with in application development are the constantly changing requirements presented by users and the constantly changing technologies used to construct information systems. The software engineering community, both academic and professional, is in the process of making a major leap forward in addressing this problem with solutions like object-oriented software development tools, iterative and incremental software development lifecycles, and component software technologies. The Adapter pattern is a part of these solutions and is one of the essential architectural techniques for providing the software infrastructures for extending and adapting applications in response to these evolving and changing requirements. In short, the Adapter pattern is at the heart of "plug-and-play" software.The Adapter pattern is like the electrical adapters used when travelling outside of your own country. Each electrical adapter possesses a specific number and shape of prongs that match the local electrical outlets of a specific country. The adapter also has specific slots on the other side for your appliances. When in use, the adapter simply passes electricity through to your appliance. The Adapter software pattern works in the same way, converting the interface of a supplier class into another interface that a client class expects, allowing otherwise incompatible classes to work together.
Figure 5: Adapter patterns translate commands and events from a client object to function calls, messages, commands, or events that a supplier object understands, and vice versa.
In our application framework, the Adapter pattern presents a general interface to the database access classes in the Technology Partition we examined earlier. The adapter will accept requests from the business entities in a general form and then translate those into SQL (Structured Query Language) if the underlying database is a relational system like Adaptive Server™ Anywhere (formerly Sybase SQL Anywhere™), or into OQL (Object Query Language) if the underlying database is replaced with a standard object database.
Click here to view the full size image.Figure 6: The data store adapter presents a general interface to business entities for retrieving data from a persistent data store, eliminating the need for exact knowledge of the underlying data access semantics.
Command Processor and Publisher-Subscriber Patterns
Command Processor Pattern
Most of the patterns we've explored so far help us break an application into many relatively independent parts, but they don't help too much when you need to hook everything back together into a cohesive application. The next two patterns will help you develop solid communication architectures between the various layers, partitions, and components of your applications. Distributed systems often employ these two patterns in combination–the Command Processor pattern and the Publisher-Subscriber pattern–to allow physically separate partitions (for example, user interface on a client machine and business logic on an application server) to compose and pass commands back and forth to invoke each other's behaviors (Command Processor pattern) by notifying each other when something changes (Publish-Subscribe pattern).
The Command Processor pattern allows your application to encapsulate system requests into objects, providing you with an architecture for sending commands from one component subsystem to another. Again, let's explore a familiar example to understand how the Command Processor pattern works–Microsoft Word.Current versions of Microsoft Word "remember" a list of the most recent commands, like Cut, Copy, Paste, that you've given and can Undo these commands in reverse order. To accomplish this, the application creates an object of each command type (Cut, for example), populates it with information about what and where you want to cut, executes the command, and saves it in a list of commands for later reference if you want to Undo it. As you tell it to Undo, it works backward through that list to reverse the commands you've given it.
The Command Processor pattern facilitates this functionality. Whenever a user, component, or subsystem calls a specific application function, that request is turned into a command object. The command processor class in the Command Processor pattern schedules the execution of these command objects, and may store them for later undo. This process separates the request for a function or service from its execution and packages the command into a form easily passed around a distributed system.
Click here to view the full size image.Figure 7: The user interface uses the Command Processor pattern to compose commands in response to events triggered by the user, then passes these commands to the business context for processing.
Publisher-Subscriber Pattern
To notify an application's various components or subsystems when something has changed within another component that they may be interested in, you can employ our final pattern–the Publisher-Subscriber pattern. Microsoft Excel offers a good example of the functionality encompassed in this pattern. In a spreadsheet application like Excel, one sheet may contain data and computations for weekly or monthly sales figures from several regions. Additionally, a pie chart may break down total sales by product for a specific period and a bar chart may depict total sales over the last few weeks or months. Both of these charts present information from the same underlying spreadsheet, and in Excel can both be displayed at the same time on your computer screen.What if you need to update the spreadsheet with new pieces of information?
- Corrected sales figures for the current month, in which total sales didn't change, but individual product sales changed slightly, affecting the proportion of sales between products.
- Corrected total sales information for last month.
The spreadsheet doesn't know which chart needs to know about these changes, so it simply sends (publishes) out a message (command) that data has changed. Since each chart observes (subscribes to) the spreadsheet, they receive this message and then can request (send back a command) the updated information if they determine they need it. The pie chart requests the information about current product sales, and the bar chart requests information about last month's total sales. Each chart then refreshes the presentation of the underlying data.
The Publisher-Subscriber pattern facilitates this kind of information exchange and consists of "publisher" objects and "subscriber" objects. A publisher object defines an interface for attaching and detaching subscriber objects as these objects request a subscription from a publisher object. A subscriber object defines an updating interface for objects registered as subscribers that should be notified of changes. The application then uses this framework to create concrete publisher and subscriber objects for each specific entity in your application that wants to subscribe to or publish specific information. The Publisher-Subscriber pattern allows one-to-many dependency relationships between objects that are to be defined, so that when one object changes state, all its dependents are notified and updated automatically.
Putting PowerStudio to Work
The Publisher-Subscriber pattern is key in the distributed application framework we're building with PowerStudio. This framework will have a PowerBuilder user interface, an application server such as Jaguar CTS™ where the business logic will execute using that server, and will use Adaptive Server Anywhere as its persistent data store. While preparing this article, I used PowerJ to implement a Publisher nonvisual class in Java and then registered it with the Jaguar CTS application server using the Jaguar CTS Manager. Remember, our business objects will run on the application server and have to notify the user interface whenever they change, which is the Publisher class's responsibility. The user interface will have to subscribe to any business objects it wants to communicate with, so I used PowerBuilder to write a Subscriber nonvisual user object, then generated the OLE/ActiveX interface for it from PowerBuilder. I then moved the ActiveX interface and the PowerBuilder implementation over to the Jaguar CTS application server and registered the Subscriber component with Jaguar CTS as an ActiveX component. Now my PowerBuilder user interface can subscribe to business objects written in PowerJ running on Jaguar CTS, which will then publish notification back to PowerBuilder as these business objects, or their data, changes.
Click here to view the full size image.Figure 8: Deploying PowerStudio classes on the Jaguar CTS application server. Jaguar CTS is where PowerBuilder, PowerJ, and Power++ components can execute and be shared by multiple users of a distributed application. The Publisher-Subscriber pattern, combined with the Command pattern, provides an open and flexible messaging architecture that can be used by any user interface implemented in any of the tools in PowerStudio.
Click here to view the full size image.Figure 9: A Publisher Java nonvisual class was created in PowerJ and registered as a Jaguar CTS component from the Java interface. A Subscriber PowerBuilder nonvisual class was created in PowerBuilder and was registered as a Jaguar CTS component from the ActiveX interface.
Integrating the Patterns into a Framework
Through its suite of development tools, PowerStudio makes available the four types of application development essential for implementing a distributed application based on our framework.
The framework can be implemented in almost any of the tools in PowerStudio, in almost any combination. The common principles that guide specific projects and help ensure consistent and reliable results are the patterns embedded in the framework. The specific implementation of the framework we have composed here uses PowerBuilder for the user interface, PowerJ for the business objects, and Adaptive Server Anywhere for the data storage.
- Component Repository and Assembly - PowerSite™ includes a component repository implemented in ObjectCycle® and allows you to integrate Web-based application development, component management, and configuration management for applications built using all of the other development tools in PowerStudio. You could easily replace the MDI User Interface pattern with a Browser pattern implemented with PowerSite and then attach that interface to the Jaguar CTS application server using the Publisher-Subscriber and Command Processor patterns.
- User Interface and Business Component Development - PowerBuilder, PowerJ, and Power++ each provide an excellent environment for implementing all of the patterns in the user interface and domain partitions of our distributed application framework.
- Distributed Messaging and Application Server - Jaguar CTS provides an industry-standard, distributed application server for deploying business logic constructed using the Business Context pattern in PowerBuilder, PowerJ, or Power++. This pattern provides a well-designed "business logic container" for implementing the business processes required by application users. The combination of Publisher-Subscriber and Command Processor patterns provide the distributed communication architecture that binds a distributed application together.
- Distributed Data Server - Using the Adapter pattern, the Adaptive Server Anywhere (formerly SQL Anywhere) relational database becomes an excellent persistent data service provided through our application framework.
REFERENCES:
[1]Alexander, C., The Timeless Way of Building, Oxford University Press, 1979.
[2]Austin Software Foundry, Architectures for Object-Oriented Development, 1998.
[3]Austin Software Foundry, Process Management for Object-Oriented Development, 1997.
[4]Booch, G., "Patterns," Object Magazine, 3(2), July-August 1993, pp. 24-27.
[5]Buschmann, F., et. al., Pattern-Oriented Software Architecture, John Wiley and Sons, New York, NY, 1996.
[6]Coad, P., "Object-Oriented Patterns," Communications of the ACM, 35(9) September 1992, pp.152-159.
[7]Coad, P., Mark Mayfield, Java Design: Building Better Apps and Applets, Prentice Hall, New Jersey, 1997.
[8]Coad, P., David North, Mark Mayfield, Object Models: Strategies, Patterns and Application, Prentice Hall, New Jersey, 1995.
[9]Gamma, E., et. al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.
[10]Jacobson, Ivar, Maria Ericsson, Agneta Jacobson , The Object Advantage : Business Process Reengineering With Object Technology, Addison-Wesley, Reading, MA 1995.
[11]Jacobson, Ivar, Object-Oriented Software Engineering, Addison-Wesley, Reading, MA 1992.
[12]Lea, D., "Cristopher Alexander: An Introduction for Object-Oriented Designers," Software Engineering Notes, 19(1), January 1994, pp. 39-45.AUTHOR:
D. William Reynolds, Jr. is the founder and President of Austin Software Foundry in Austin, Texas. Austin Software Foundry has been a Powersoft/Sybase partner since 1992 and authored Powersoft's Object-Oriented Analysis and Design with PowerBuilder, Object-Oriented PowerBuilder Development, and Application Partitioning with PowerBuilder courses. Bill has a B.S. in Finance from The University of California at Berkeley and an MBA in Information Systems Management from The University of Texas at Austin. He will be presenting many of the concepts and techniques from this article at Powersoft Conference '98 in Los Angeles in a course called Architecture for Object-Oriented Development.
