Programming Model in a Nutshell

The WebSphere Application Server Enterprise Edition (WAS EE) Component Broker (CB) programming model is a distributed client-server model based on the COBRA II specification. With this model the actual object implementation executes in the server environment and the client programs, executing in a separate process space, send messages to the remote server object via a proxy object which communicates to the server implementation using IIOP. The focus of this discussion will be on the server side implementation.

Another key feature that you'll see as a result of CORBA is the strong separation between the interface and the implementation. This is confusing at first. Everything is CORBA is defined as an interface and then it is up to the developers to provide implementations. If you are already familiar with the Java programming language this won't be so strange to you. Java does the same thing with implements and extends.

CB applications are composed of layers of objects using well defined interfaces and patterns of interactions as defined by the Managed Object Framework.

Contents

Object Layers To top of page

Each of the objects listed above represent one of the architectural layers, each with a specific responsibility. The goal is to separate and isolate the business logic from the data storage mechanism on one end and the mechanism for accessing the common services on the other end. The primary responsibility of the application programmer then becomes one of specifying the interface for the Business Object and implementing the logic therein while the framework tools generate the framework specific objects such as the MO, DO and PO.

The Application Objects are transient managed objects that help to organize the overall structure of the application. The Application Objects are similar to controllers or coordinators that help manage a unit of work, they use the basic business objects and composed business object to implement the functionality defined by a Use Case.

Each Basic Business Object encapsulates a Data Object which in turn encapsulates one or more Persistent Objects.

Data and Persistent Objects

The primary responsibility of the Data Object is to separate the persistent storage mechanism, how the the data are stored, from the business logic. Maintaining this separation protects the business logic from changes in data storage technology. There can only be one Data Object for a given Business Object.

The Persistent Object is essentially a helper object used by the Data Object to do the actual IO to the data storage device. There can be several POs for a given DO as long as they meet the requirements of the container, e.g. access the same database.

The Procedural Application Object (PAO) is a special kind of PO used with procedural containers such as CICS and IMS.

The Data Object and the Persistent Object, interfaces and implementations, are very specific to the Managed Object Framework and are generated by the Object Builder tool. This allows the Business Object Programmer to focus on the implementation of the Business Object.

Basic Business Objects

The first fundamental building block is the basic Business Object. This generally relates to the most granular abstraction that is an entity or things from the business model. This is the object that represents the account, the policy, or the customer, for example. These abstractions are generally backed by relational database, APPC based CICS or IMS.

Composed Business Objects

A limitation of the basic Business Object is that it can only be associated with a single Data Object and thereby a single datasource. When working with existing systems the business entity that we wish to work with sometimes has data that must be gathered from different datasources. Using the Composed Business Object construct we can bring multiple Business Objects together into a single entity with a single interface that represents the business abstraction we need.

Basic business objects can be composed into larger or more coarsely grained compositions. These composed business objects still represents entities and will generally have attributes which are keys or references to basic business objects.

Construction of Composed Business Object is fully supported by the Object Builder tool. For more information see the on-line documentation.

Application Objects

Application Objects are one of the of the fundamental building blocks on the server side of a CB application. Application Objects live in transient containers and generally perform the role specified as ‘session bean’ in the EJB world. They are generally doing some process or action on behalf of the client. The methods of an Application Object will map nicely to the Use Cases in the Analysis Use case model.

As an example consider a Bank application object. In the banking Use Case model there is a use case defined to transfer money from one account to another called transferFunds.

It now becomes the responsibility of the Bank object to manage the transfer, making sure that the transfer happens as a single unit of work within the context of a transaction. The Bank object will use one or more account objects and perhaps an audit object (which are either Basic or Composed Business Objects ) to do the actual transfer. Since the Bank Object is the one managing the unit of work it is the natural place to initiate the transactional context and do the commit or rollback as necessary. By placing this responsibility with the Bank application object we relieve the client programmer of the burden of dealing with the transactional nature of the underlying data store.

Its important to note that the Application Object is transient and that is has a uses relationship with the Composed or Basic Business Objects, which will most likely be persistent.

A simple application might have only one layer of application object. That means that the application objects are directly calling basic business objects. More complex applications will leverage multiple layers of application objects, organizing logic in various application objects based on workflow, sequencing, and so on.

The Complete System To top of page

A complete system will then use layers of application objects that drive composed business objects (and basic business objects), while the compositions are made up of basic business objects.

Basic Business Objects are constructed first and then tested using Quick Test.

Composed Business Objects are constructed next, again Quick Test can be used to verify functionality and correctness.

The Application Objects are the last to be completed but it is not necessary to wait until the end to begin working on them. Since the Application Objects contain the interface that the client programs will be using and the interface has already been defined as part of the Analysis and Design effort, one can create Application Objects with the methods stubbed out to simulate the expected behavior. This will allow for parallel development of the client applications.

Another useful technique when developing Application Objects is to use a (CORBA) client program to develop the method and when the method has been tested and debugged, then move it to the Application Object. Using this approach saves time because the deployment of the managed object is avoided until you're confident in the correctness of the methods.

Specialized Homes To top of page

In the Component Broker Programming model the Home abstraction is used to create and find our distributed objects in a language and platform independent manner. A default implementation of the Home is automatically created for each kind (class) of Managed Object that is developed. The default Home provides the minimal set of methods for creating and finding managed objects, that is, by primary key.

If we wish to expand this interface, e.g. customize it so that we can create and find our managed objects in a manner optimized to our application needs as described by our analysis models, we can. We do this by creating a Specialized Home.

Creation of a specialized home is fully supported by the Object Builder tool and is described in the on-line documentation.

In general, if you have Basic Business Objects (entities) that are associated with a container and data store that permit queries, then you want to create Specialized Homes that are Queryable.

Your need for Queryable and/or Iterable Homes should be apparent based on the Use Cases and Scenarios defined in your analysis model.

Applications and Application Families To top of page

Once we've constructed all the parts that are required to implement the server side of our objects we have to have a way of packaging them up and deploying them on the servers in an orderly way. To do this we have the concepts of Application Family and Application.

The Application defines the set of Managed Objects that you want to execute together as an application unit, e.g. process and jvm. The Application Family bundles a group of Applications together so they can be deployed and managed as a unit.

Applications contain one or more Managed Objects. Application Families contain one or more Applications.

If you want to know more about creating Applications and Application Families see Tool Mentor: Configuring Applications Using Object Builder

This information is provided by IBM Corporation

 © Copyright IBM Corporation 1999-2000

 

Display Rational Unified Process using frames

Rational Unified Process