|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Renaissance ProgrammerUsing Transactions in your Object-Oriented ApplicationsBy Bruce Whitenack, Object PeopleA surprising discovery
The typical business transaction applications described in textbooks, such as Principle of Transaction Processing [Bernstein 97], are ones that are typically used as examples of object-oriented applications in many introductory OO Analysis and Design courses. See Table 1 as an example of typical business transactions supported by TP systems.
Table 1. Business Transactions TP Monitors are importantTransaction Processing systems using CICS or IMS are great to use for heavy-duty, large-scale business applications. They can handle a high volume of concurrent data accesses, thousands of clients, diverse and multiple resource managers (DB2, Oracle and VSAM or IMS), and perform concurrent operations without errors. They are able to grow incrementally without losing results. They make efficient use of system resources, such as scheduling and memory and have tools to configure and manage servers to optimize network usage. Whether their programs use objects or not, TP Monitors currently are the best vehicle for mission-critical applications that require robust, transactional services for large numbers of concurrent inputs accessing and processing information over networked systems. At this point in time, the performance of Object Request Brokers using an Object Transaction Service can be measured in seconds per transaction not transactions per second. Transaction Processing Monitors like CICS and IMS can handle hundreds of transactions per second. With MVS Smalltalk, where Smalltalk images are capable of running within the scope of a CICS or IMS transaction on a mainframe server machine, there now arises the need to incorporate design methods to map OO designs to a transactional designs. This is what will be addressed in this column. Object-Oriented Analysis and Design (with Transactions)I believe most of us are familiar with standard Object-Oriented Analysis and Design techniques. A typical analysis and design process would include activities and a path similar to the one below. Defining transactions (a.k.a. units of work) to support use cases and user actions is the highlighted design activity in this article. Main analysis activities:
Main design activities:
Additional related design activities (as required):
To understand how the transactions can be defined during OO analysis, design and implementation, it is necessary to consider what is the nature of transactions, what is the client-server transactional model to be used, what are the static and dynamic object models of the business domain, and what is the communication model between the client and the server. Transactions 101A transaction starts with a request message being sent to the computer system to execute a program that performs a business function for a user and generally access a shared database. The request message will kick off a task that runs the transaction program associated with the transaction request. See Figure 1: Transaction Processing. 
Figure 1: Transaction Processing A transaction is a recoverable unit of work. User or Business Units of Work (such as making a reservation for tickets for a performance for a customer) are defined from the point of view of the business user and are made up of a set of server transactions. Server transactions are Server Units of Work performed within the commit scope of a transaction processing task. Each Server Unit of Work includes a set of changes that are committed or rolled back as one (e.g. making a bank deposit or adding a customer). In the example below (see Figure 2: Use Case- Transaction Diagram), we have a scenario describing a Business Unit of Work from a reservation agent's point of view. It is supported by the Server Units of Work: Read Customer, Read Performance, Make Reservation.
Figure 2: Use Case-Transaction Diagram The above is an example of a business unit of work where several transactions are required. It is the simplest design approach for implementing a business unit of work. The basic philosophy is to design the user unit of work where all transactions are read-only until the user is ready to commit an update at the end. If you notice this diagram outlines a description of a use case for making a seat reservations for a performance for a customer. In fact, notice how close this is to the following use case description based only on use case analysis for a Ticket Reservation System. Use Case DescriptionUse Case Name: Make a reservation for a customer for an event. Actor(s): Ticket Agent Precondition: The Customer has made a prior reservation and exists in the system. The credit on the customer's credit card is sufficient for the reservation. There are seats available. The reservation is made more than 5 days before the event. Results: A Reservation is made for the customer for the event and the reservation is sent to the Ticketing System to be printed if necessary. The ticket is then mailed to the customer. Description: The ticket agent collects the necessary information from the customer including what event and what type of seats the customer wants. The agent informs the customer that there are seats available and where they are located. The customer decides to purchase the seats and the agent charges the reservation to the credit card number. Upon confirmation of the credit charge the customer is notified by the agent when the tickets should arrive. Exceptions: Credit card is not sufficient. Seats are not available. The Object Model to Transaction Model ProblemIn my last column I brought up a number of technology tensions that must be resolved in designing an object-oriented application that uses transaction processing. One key issue which will be addressed in this column is - How do you develop and integrate your object model in conjunction with a transaction model? To better understand the approaches that can be used to answer these questions, let's first take a look at an archetype for a system architecture that supports client-server transaction processing with business object models both on the client and the server ( see Figure 3: Client-Server Transaction-Managed Object Architecture). The business objects contain the information and perform the business logic required for the application. The unit of work architectures model the business and server units of work. Who is in control of the business unit of work? A general philosophy espoused by Oliver Sims [Sims 94] is that the user is in control where the required business processes are neutral about sequence and completion criteria. However the business objects are in control where the business demands it (as in some cases, certain criteria must be correct before a task can be completed). In Figure 2 the user is in control and then applies the commit at the end. The user could have determined seat availability before getting the customer information. The application must know what transaction requests to send to the server for each user action. The communication in this architecture between the client and the server is not via remote message sends to an object on the server but is via messaging mechanisms such as Remote Procedure Calls, peer to peer protocols or asynchronous messaging via a product like MQSeries. 
Figure 3: Client-Server Transaction-Managed Object Architecture © The Object People, 1997 The example application that I will refer to in the following discussion is a simplified Ticket Reservation System. A simple static object model for this domain is seen in Figure 4 below. 
Figure 4: Ticket Reservation System Object Model © The Object People, 1997 In developing an object model, the analyst/designer focuses on identifying the domain classes, their behaviors and attributes. In determining the dynamic relationships between objects, he focuses on the best combination of messages to support the use cases. The focus is not on transactions. However, the designer is thinking about units of work in terms of use cases and the operations of the classes (what messages each will respond to). In fact, there is a very close correlation between use cases and business units of work and between public messages sent by the application interface and transaction server units of work. The message flow diagrams described in Figures 5 and 6 below demonstrate a first pass in defining the messages that supports the use case, Making a Reservation for a Customer. These diagrams were designed with no thought to transaction processing. Their purpose here is to show typical messages developed in OO design. They will be used as the basis for mapping object messages to transaction requests in a TP environment. The format for the messages in the diagrams is based on the following template: (Numeric order) Message name (Parameters) object returned Rx within a Booch cloud indicates the object(s) returned as a result of the message numbered x. Make a Reservation for a Customer - Part 1The agent locates the event the customer is interested in and in this case, locates available balcony seats the customer wants. The agent locates the customer and prepares a reservation to make a credit card transaction. 
Figure 5: Message Diagram Part 1 © The Object People, 1997 Make a Reservation for a Customer - Part 2The ticket agent determines the cost of the reservation (7) and charges the transaction to the credit card successfully. The agent then causes the reservation to complete with the charge card information (8). The reservation is added to the Event and gets assigned a reservation number. 
Figure 6: Message Diagram Part 2 © The Object People, 1997 Based on the message flow diagrams depicted in Figures 5 and 6, above, we can determine the server units of work (transactions) to be performed as a result of user actions. Table 2 below depicts the transactions to object message mappings. The number associated with the unit of work name is the message number used in the message diagram.
Table 2: Transaction to Object Message Mappings © The Object People, 1997 Implementing the DesignOne implementation of this transaction to object messaging design would be to use CICS and its External Call Interface (ECI). ECI is a Remote Procedure Call for CICS which operates like an EXEC CICS LINK. It passes data in a buffer called the commarea to the "called" CICS programs on the server. The commarea could contain a Parsed record, byte stream or dumped set of objects that can be reconstituted in the receiving image using an Object loader. The called program on the Server can return data in the commarea. VisualAge has a CICS Proc Dialog part that can be used with CICS Client on the workstation to communicate with CICS on MVS. I encourage you to investigate how to use this feature. "ReservationSystem processTransaction." is the start-up code to execute a Server application program on CICS with MVS Smalltalk. Example code for processTransaction is shown below in Figure 7: MVS Smalltalk Example Code. In this method, aTransaction is an object that knows the name of the transaction type as well as other pertinent information. You may notice, processTransaction uses something like a case statement to determine what messages to send. This is indicative of the need to explore using the State Pattern and adding more behavior to Transaction. In looking at the code, you might wonder what the possibilities would be for designing a generalized Transaction class with instances of its subclasses (one for each server transaction type)shipped up to the server to perform within a transaction task. At this point in development, however, we are in the 'Make it Run' stage so the case statement is the initial approach to kicking off the appropriate object messaging in the Server application (i.e. image). Smalltalk Server ApplicationReservationServer >>
processTransaction
| aTransaction |
aTransaction := self getTransaction.
(aTransaction command) trimBlanks = 'GetEvents'
ifTrue: [EventSchedule getEvent: aTransaction eventName
forDate: aTransaction date
].
(aTransaction command) trimBlanks = 'GetBalconySeats'
ifTrue: [aTransaction event
nextBalconySeatsTogetherAvailableFor: aNumber].
………..
aTransaction command) trimBlanks = 'CreateReservation'
ifTrue: [Reservation newForEvent: anEvent
customer: aCustomer
withSeats: aCollectionOfSeats].
getTransaction
" Receive Commarea "
self result: CICS address exec.
self isOkay
ifTrue:[^Transaction address: (result commarea reference)]
Figure 7: MVS Smalltalk Example Code © The Object People, 1997 IssuesSome other issues have come up during this discussion and for future consideration they are: 1. Parameter passing. Should parameters be passed in either an Object which can be parsed, a byte stream of characters, or a dumped byte stream? What objects should be passed back to the client? 2. Object instantiation - After each transaction, is the image completely out of memory or can object be kept in server storage for succeeding transactions? This relates to: 3. Conversational or pseudo-conversational processing . This is an old issue in transaction processing. In pseudo-conversational mode the objects would be saved or passed back. They can be kept in memory when in conversational mode. 4. Should the object models on the client and the server be the same? What processing should be done on the client, and what should be done on the server? 5. How would a workflow application be designed and built in this environment? For further enlightenment on transaction processing and objects in a client-server architecture, I highly recommend the two books I have referred to. References:[Bernstein 97] Bernstein,P., Newcomer, E. 1997. Principles of Transaction Processing, San Francisco, California: Morgan Kaufmann Publishers, Inc. [Sims 94] Sims, O. 1994. Business Objects: Delivering Cooperative Objects For Client-Server, London, McGraw-Hill Book Company. Enjoy the article? Subscribe to Eye on Objects! | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bruce Whitenack is a Software Writer in Residence with The Object People, U.S. in Raleigh, North Carolina. He is the author of RAPPeL (Requirements Analysis Process Pattern Language) and co-author of Crossing Chasms as well as the course developer for VisualAge for Smalltalk Server: Transaction Managed Objects and TOPLink, a relational database to objects framework . He welcomes your comments.. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
have been struck recently, while developing the course VisualAge for Smalltalk
Server: Transaction-Managed Objects (a.k.a. MVS Smalltalk), how the example
applications we use in teaching object-oriented technology are primarily the
same applications which are best supported by transaction-processing systems
such as CICS and IMS.