Java Development News:
From the Trenches Series: db BausparenOnline
01 May 2003 | TheServerSide.com
|TheServerSide's From the Trenches Series is a collection of real-world applications, solving critical business problems, submitted by users of TheServerSide. In the series, we'll discuss the tools and techniques that J2EE architects and developers are using today. If you'd like to submit your own story, you can send a note to email@example.com.|
The challenge: db BausparenOnline
The first application in this series is the db BausparenOnline application, designed to Internet-enable a large bank's mainframe system. This application was jointly developed and submitted by a customer and consulting company. Deutsche Bank Bauspar AG has about 400 employees. It focuses on savings plans that help its customers build the capital to acquire real estate. The company provides sales applications on workstations in more than 1000 offices of its cooperation partners and branch offices of Deutsche Bank AG. Founded in 1990, privately owned Interactive Objects Software GmbH specializes in IT architecture, providing model-driven development tools and services. Their ArcStyler IDE supports the Object Management Group's Model Driven Architecture (MDA).
What business problem does the application solve?
This application, called db BausparenOnline, integrates with an existing mainframe application called the Bauspar System. It provides support to three distinct client sets, each with different user interfaces as shown in figure 1. Though the applications are distinct, they share much of the business logic and data stores. These are the critical use cases.
Figure 1. Presentations for three distinct customer groups are served through WebLogic applications on a Sun cluster, which then access CICS applications..
- Customers view contracts and download forms over the Internet.
- Customers check contract status.
- Customers check options for contract optimization.
- Mobile sales and field staff perform calculations and check contract status to support the sales process, with and without an Internet connection.
- The back office staff finalizes transactions and processes without having to reenter data provided by the customer or field staff.
The existing application was developed nearly two decades ago using IBM's transaction processor, CICS. They improved it continuously since then, increasing the capabilities as users had new requirements. Replacing it entirely would be cost prohibitive, but continuing to do dedicated COBOL development was not efficient, especially to serve Web-based applications. db BausparenOnline extends the Bauspar System with a number of distinct, but interrelated, user interfaces that automate the sales processes across back-office employees, the sales force, field staff, and the end customer.
The new application needed to improve the efficiency of the back office staff through improved automation, additional functions, and better integration with customer and sales force applications. db BausparenOnline also needed to reduce the prohibitive costs of maintaining desktop-based software across the Deutsche Bank AG branch offices and cooperating partners. Additionally, the new application needed to improve the level of service by the sales force and field staff, while making allowances for disconnected users so the mobile field staff could take the application, with all of the associated benefits, on the road.
How are the clients organized?
In the case of db BausparenOnline, three distinct applications access a business integration tier, which communicates with a mainframe running legacy programs. These are the customers, with the typical "client" computers that access the system.
- Sales partners and field staff: The user interface supporting the sales staff runs on over 30,000 workstations in each of the branch offices of Deutsche Bank AG and the offices of the cooperating partners. The application must support several different operating systems from Windows to OS/2, and browsers from Mozilla to IE and Opera. Using this application, the sales partners and field staff have access to calculation and status information on customer contracts, possibly without an Internet connection.
- Back office: A user interface running on 200 Microsoft Windows NT workstations running IE supports the back office staff. Through this interface, the staff finalizes transactions and processes, using data that's already been entered by the sales staff.
- Customers: End customers can process several types of requests via the Internet, and may have any type of browser. They can view existing contracts, and for pending deals, they can get information on contract options or the status of a pending contract. Finally, they can download necessary forms to support a contract, putting all of the information that they need at their fingertips.
db BausparenOnline is organized into three distinct applications that serve each of these communities. They are , called simply: Back Office, Sales and Web respectively. The applications share the same data repositories, and also share common code. The applications are organized as follows:
For db BausparenOnline, the core banking functionality remains on the mainframe. Since the COBOL developers had the existing banking expertise, the development team decided to leave the short, core business transactions in COBOL, on a mainframe-oriented transaction system called CICS. However, as they had to Internet- enable their application, their customer's demands grew more sophisticated and they needed to introduce an integration tier to help manage workflow and integration. They decided to access the mainframe tier from a J2EE integration platform using XML over messaging-oriented middleware. They keep views of the application uniform via an EJB- based layer, which provides support for workflow, and longer-duration transactions that tend to be difficult to support from the CICS layer on the mainframe
What architecture did they use?
This application was built using OMG's Model Driven Architecture, which insulates coexisting technologies from the core model. (You can read more about MDA at www.omg.org.) They chose MDA based on its ability to support key banking requirements:
- Evolutionary development. Since the bank supported many different technologies, they needed a process that would allow them to effectively integrate existing systems, mostly consisting of COBOL applications running on mainframe hardware.
- Implementation independence. MDA allowed the bank to support a development process that was independent of the development technologies. In the future, they hope that they will more easily accommodate change.
- Productivity, quality and effective communication. In addition, the development team hoped to have a more effective development process, based on their model-driven development approach.
What tools did they use?
The project team used ArcStyler, which tightly integrates with Rational Rose, to create and refine the UML model, and the ArcStyler Generator to use the UML to generate most of the components of the system. Rational Rose is integrated in the ArcStyler via special property bars, which are also used to model implementation-specific details about the deployment. ArcStyler uses a compatibility layer, called MDA Automation Cartridges, which customize the generation of code across a number of architectures. Embedded Jython methods allow access to the model information. ArcStyler also offers an IDE with debugging for the creation of templates, which contain custom code in protected areas that are preserved in succeeding code generation runs.
Developers can activate a generation run from ArcStyler for individual model classes, packages of model classes or for the complete model. A developer can control generation using custom properties, by using properties defined in the modeling tool (in this case, Rose), and by using a template. Within the template, a developer can define areas for custom client code, so that future generation runs will not replace any custom code.
Figure 2. The enterprise tier has three distinct applications, with two in one WebLogic instance and one in another. The server pair forms a failover cluster for availability
Going into this project, Deutsche Bank Bauspar AG evaluated application servers, with one mandate: to choose the application server that best met the needs of the application. They chose WebLogic to support the integration tier strictly on its abilities to support the db BausparenOnline requirements.
How did they design the integration tier?
Figure 2 shows the physical organization of the db BausparenOnline integration tier. Two WebLogic instances run on each server. One instance on each server hosts the Web Application and the other hosts both the Sales Application and the Back office Application. Each has Web and EJB containers in a JVM. These form failover clusters in two pairs. The Sales Application and the Back office Application are usually used on the first Sun server, and the Web Application on the second Sun server. Each application fails over to the second application server. The applications run in a Sun Cluster consisting of two Sun Fire 280R. An MQSeries Queue Manager and an Oracle 8.1.7 instance also run on the cluster. The configuration allows failover of each component of the solution, without an unnecessary proliferation of hardware.
Figure 3. db BausparenOnline is organized into logical layers of client, presentation, business, workflow, and data access layers.
Figure 3 shows the logical organization of the tier. The integration logic consists of four logical layers: data access (comprised of logical and physical layers), business, workflow, and presentation. These abstractions help to reduce the coupling between the application and the physical data store.
- The presentation layer consists of straight servlets and JSP. They are organized according to well-understood MVC principles via the Struts framework. The Struts actions contain no business logic. They pass requests through to the business layer.
- The business layer provides access to the data layer and invokes core mainframe services. It also provides transactional control for long transactions, via a Workflow Management layer, which will be described shortly. The business layer also provides verification logic, using the data from the server. All access to the business layer is through a session facade, implemented with stateless session beans. These beans (minus the business logic) were generated by the framework, described below in the Tools section. The application accesses the database via JDBC. The application accesses the mainframe via a framework that is generated by the ArcStyler tool, also described in the Tools section below. MQ Series with XML handles both synchronous and asynchronous integration with the mainframe.
- The business layer also calls the Workflow Management Layer to manage longer transactions and work flows. For example, the customer service staff just complete certain step-by-step activities to complete a complex process after several minutes. The workflow system persists form data, and transfers them to the mainframe when the staff member completes the transaction. The system uses an optimistic locking scheme, with value objects that carry the read time stamp. The data may only be changed if the time stamp is younger than the last modification of the record. This workflow system was custom developed by Deutsche Bank Bauspar AG development team.
- The data access layer is actually subdivided into logical and physical layers, both on the server and the mainframe. The logical layer is an abstract adapter of the physical access layer, and allows database access via Value objects under Java or XML, or copybooks under COBOL. On the integration tier, the data model is almost a complete mapping of the class model of Value Objects, so the layer simply collects associated instances. The physical layer actually implements the access to the database. JDBC accesses Oracle. The layer maps result sets onto Data Access Objects which correspond to the Value Objects of the logical layer.
With a high-level description of the application in place, we can drill down into the most interesting aspects of this application. We'll look at the integration with the mainframe tier, the toolset used to produce the application, and the treatment of disconnected clients.
How did they integrate the mainframe tier?
Most of the system still runs on mainframe hardware. The mainframe tier has a similar organization to the server tier. A data layer separated into physical and logical components accesses the mainframe database, and a business layer developed using CICS comprise the mainframe tier. There is no workflow layer.
The server tier communicates with the mainframe tier using an XML message model over MQ. The team developed the messaging model before the widespread acceptance of SOAP. It's essentially a lightweight RPC, with message types for method call and response especially adopted to the requirements of the interface. Parameters and return values can be primitive data classes and interfaces. This is an example of a method call:
XML Method call <Transaction Version="1" RequestId="000000EC4346AB5C0ACE22664346264E" SessionId="pi6kp9pkr1" TransactionCode="QCL2"> <MethodList Version="1"> <Method Version="1" Method="getStandort" Package="BL-User"> <ParameterList Version="01"> <Parameter Name="FilialNr" Type="Numchar(3)">615</Parameter> <Parameter Name="NdlNr" Type="Numchar(3)">010</Parameter> <Parameter Name="UserID" Type="Char(16)">AFH002</Parameter> </ParameterList> </Method> </MethodList> </Transaction>
The method response is similar. It maps the result of a CICS transaction onto an XML method response, with a set of return parameters, method status, packaging and versioning information.
During the design stage, the team can model methods as a class without instance data. Using the UML model, ArcStyler generates this XML and the code to do distributed method calls over MQ, packing and unpacking value objects, based on the method signatures. On the mainframe, the MQ listener maps the method invocation onto a CICS transaction
The ArcStyler tool generates much of the code needed for integration, including the XML method call and result blocks, 70% of the code in the business layer on the mainframe, and the stubs in the business layer on the server.
How much code was generated?
Though it's not a perfect measurement of programming efficiency, it's interesting to take a look at the application and see how much was generated, and how much needed to be built by hand. These are the numbers, reported as a percentage of generated code:
- XML interface: 100%
- Presentation layer: 40%
- Business layer (server): 60%
- Business layer (host): 70%
- Data access layers (Phys): 90%
- Data access layers (Log): 65%
Recall that the developers design an object domain with Rational Rose, and then use ArcStyler to generate code for the rest of the application, including the XML interface, the front end, the business layers on the server and mainframe tiers, and the data access layers on both tiers. For the presentation tier, the framework generated the Struts action and forms.
In particular, the framework generates:
- All XML
- Stubs for all interfaces
- The forms and actions for the presentation layer. (Some of the forms need to be heavily customized.)
- The interfaces, value objects, method stubs and marshalling for the business layer
- The value objects, persistence, and interfaces for the data access layer
The end result is a satisfying improvement in efficiency of the development process. The application is relatively new, so it will be interesting to watch how the loose coupling around the data layers improves maintenance, and to measure the maintenance and performance against similar systems that use EJB entity beans.
How did they handle disconnected clients?
One of the technical challenges that the team faced was the management of both connected and disconnected clients. The customer service client had to run as a client application both with and without Internet connections. The sales team needed to be able to process applications, run what-if scenarios, and handle simple customer service requests. To handle this contingency, the customer service application has an offline version of the application, with the following components:
- Web container. The client has a web container with Jakarta Tomcat, a lightweight servlet engine.
- Database. A lightweight database called HSQL stores enough data to remotely service transactions in the off-line mode.
- Business logic. The client has enough of the business logic to service transactions in the disconnected mode. The client does not have a full EJB server. Instead, when the presentation tier creates a request, a factory class generates a Java class, which duplicates the interface of the session facade. This business logic creates a request that uses data in the local database, and persists any data changes to the database for upload later.
- Presentation Logic. The client has presentation tier logic identical to that on the server. This is an interesting implementation that saves the effort of building a complete local user interface.
The client can then work in either connected mode or disconnected mode. When the application needs to initiate a transaction, a component with an abstract factory transparently determines whether the application is in the online or offline mode.
If it's in the online mode, the factory creates a proxy object, which transfers the invocations via RMI to a session bean on the business tier. The application accesses the server tier through the XML interface over HTTP. The client uses this interface to invoke the business tier logic as a Web service. A servlet accepts the HTTP Post call and then calls a servlet with its content, which interprets it and makes the appropriate method invocation.
If the request is in the offline mode, the presentation tier's factory object creates a Java class that directly calls the client side business logic. This class duplicates the session bean interface of the server-side session facade, but without EJB session beans. When the user again logs on, the requests are sent to the server, and the results returned to the user.
The Physical layer
The framework generates 90% of the physical layer. This layer is responsible for implementing the physical database access. In the server side, the access is JDBC to Oracle. The physical layer uses data access objects that map onto value objects.
The mainframe layer uses COBOL and native database connections. Each table has a COBOL module that provides access methods, which are in turn used by the logical layer.
The Logical Layer
The logical layer is simply an adapter of the physical access layer. On the server, it uses value objects through the DAO interface provided by the physical layer. Since the value objects map directly onto DAO, the primary responsibility of this layer is to manage collections of associated instances.
This application has an interesting mix of the common classic three tier architecture, and a business tier wrapped in a session faacadeade and the unusual. In particular, the off-line architecture is an interesting application of open source software to create a light-weight web server and database, allowing a uniform application architecture and maximizing the amount of common code. The use of MDA sheds some insight to how real customers are using ideas from OMG, after the CORBA surge of the mid 1990s. The effective use of Rose as a modeling tool as a foundation for code generation is also an interesting departure from conventional methods, where we've seen some backlash against RUPE and similar heavyweight processes. Finally, this profile shows that customers are attacking real, mission critical applications with J2EE. This one has elements of complexity, integration, and scale that form an educational real-world story. Thank you, Deutsche Bank Bauspar AG and Interactive Objects.