Business Object Design and Implementation Workshop
Business Object Design and Implementation Workshop
Position Paper Object
Service - Application Programming Interface (OSAPI) 
Bruce
Miner (102707.1754@compuserve.com)
Organization
Date/Place: 16 October 1995/Austin, TX
The sun did not shine
It was too wet to play
So we sat in the house
On that cold, cold wet day
(The opening lines of 'The Cat in the Hat' by Dr. Seuss)
This document describes business requirements and solution oriented components that may be viable in managing object interaction in heterogeneous and distributed environments. The components have been designed to enable multiple requests from a single object executing concurrently such as would appear in a transaction processing environment.
The API which is central to this document was prototyped and found robust enough for consideration in several production level systems.
Please note that the focus of this initiative has been to enable early such deployment of objects so that their natural behavior could be observed. As such any defined architectures are considered to be transitional, in that we expect the techniques describes to be integrated at a system level at some time in the near future.
Koba Software has identified unfulfilled needs in the financial systems industry which include flexibility to accommodate complex solutions, quick response to change, ease of maintenance, and integrity of data on a large scale. This document describes one of the interim tools that Koba Software has developed to satisfy these requirements: Object Service - Application Programming Interface (OSAPI).
Current mainframe-based systems provide integrity of data and dependability, but they are not very flexible, easy to maintain, or responsive to change. PC-based systems accommodate change and provide flexibility and ease of maintenance. However, PC-based systems do not maintain integrity of data on a large scale. Client/server technology was developed in response to the shortcomings of the PC-based systems. It succeeds in supplying all the requirements, but only on a small scale. When combined with object-oriented programming techniques, client/server technology provides a stable and flexible system, however, the resulting system is rarely compatible with existing systems components.
Industry needs something similar to client/server technology but with the ability to work on a larger scale. This tool would have to provide the integrity of the mainframes, the flexibility and responsiveness of the PCs, and the interaction of the client/server. Koba Software believes that no single technology fulfills all the needs and that an architecture of technologies that uses the strengths of each different technology is the solution.
OSAPI has a number of requirements, including:
Current systems technologies and server applications evolved from the needs prevalent at the time of their construction. As time passed, the demands made on the systems changed and the limitations of the systems became apparent. New techniques and technology addressed the new needs, but, again, failed to provide the facility to change with the times. Client/server technology arrived to address many of the shortcomings of the previous approaches, but failed to meet the criteria on a large scale.
Early systems used technology that managed transaction acquisition, processing, and data management all within the same processing framework. Over time, systems became more complex and older systems were forced to change rapidly. Neither the hardware nor the software could keep up with the demands.
A number of developments occurred to accommodate both flexibility and complexity including:
In response to the need for more complexity and change at an ever increasing rate, two program development techniques arrived to assist in software development and large system maintenance. The two techniques, structured and modular, assisted with coordinating development efforts between many highly specialized teams. However, the demand of expanding requirements on the static data structures restricted the systems from changing quickly.
Database management systems (DBMSs) reduce the direct dependence of hardware and software on each other to alleviate some of the hardware and software constraints. DBMS has the following strengths:
Early DBMSs required highly skilled users to navigate and manipulate the systems effectively. Recent relational DBMSs address this problem by making navigation much easier and broadening the availability of the distributed database.
Client/server technology was developed to fulfill the need for a flexible and responsive method of sharing data from a single source. Client/server technology allows more than one client process to send requests for processing to the same server. A client process can be any software application that has access to a server process. A server process can be a mainframe or PC that is dedicated to storing data and processing requests from any client process.
Early client/server applications focused on presentation and data acquisition. They used tools such as graphical user interfaces (GUIs) to allow users to quickly generate systems and access information. More advanced tools made it easier to implement data management access facilities. Generally, the early client/server application were simple applications with a locally attached DBMS, and they were sufficient for single departments or smaller scale projects.
As systems development projects become more complex, the client/server applications face the same constraints as the early systems: inability to accommodate change and increasing complexity. Currently, the systems can be difficult to maintain and, when used on a wide area network (WAN), consume significant network resources and create communications bottlenecks. Also, the impact of the client processes on the data within the server processes is often unpredictable.
Object Oriented techniques base their approaches on three base concepts: These are:
The strength of the object oriented approach lies in encapsulation and enabling reuse. This reuse promotes the evolution of systems over time (as compared to redeveloping systems from scratch) thus reducing the impact of ongoing maintenance.
Confusion in the area of object oriented techniques was introduced when object oriented was confused with GUI interfaces, client/server, marketing departments who arbitrarily called their products object oriented and programming languages.
Traditional languages and databases allowed object oriented techniques to be applied however the majority of systems development efforts reverted to structured techniques at some point. Object oriented languages have evolved to support class and object use. Some of the early languages had difficulty navigating traditional relational database management systems
Several methodologies have evolved to support development within the object oriented framework.
The initial difficulties with data access experienced by object oriented applications have been overcome with more advanced interfaces as well as the advent of object database management systems. Of the major accepted methodologies a convergence is apparent with respect to the impact of concerted analysis and design.
Although current client/server technology is sufficient for small projects, it fails to meet today's need for the same abilities on a large scale. Any future development must be able to meet the demands for flexibility and complexity and still accommodate both application and technological requirements. The following table describes the requirements for future development:
Requirement:
Support distributed transaction management
Purpose:
To maintain data and transaction integrity
Description:
A system must prevent the data in a database from ever being corrupted even when different parts of complex transactions run on different servers. A system must be able to access more than one server process and select the most appropriate server process for each transaction or part of a transaction.
Requirement:
Support distributed systems management.
Purpose:
To administrate the components of a distributed enterprise.
Description:
A system must enable the configuration , monitoring and management of distributed systems components. These components include the networks, servers, gateways and database servers.
Requirement:
Utilize standard open interfaces.
Purpose:
To allow the use of flexible platform components.
Description:
A system must allow the utilization of specialized components in a heterogeneous environment. To enable this to take place on a continuous basis, the system must adhere to known standard open interfaces.
Requirement:
Allow processes to access static data locally.
Purpose:
To use communications networks more efficiently by reducing the number of messages for each request.
Description:
A process must be able to access the static data it needs to formulate or complete a request with minimal network traffic.
Requirement:
Manage development complexity
Purpose:
To accommodate increasing application complexity.
Description:
A system must enable the use of object-oriented techniques which minimize application re-engineering during the evolution of more complex systems.
Requirement:
Support and enforce business rules
Purpose:
To speed up processing of requests and to consistently enforce business standards.
Description:
A system can detect inaccuracies and incompatibilities in the content of a message as described by the business rules. The system can enforce the business rules at multiple process points.
Requirement:
Maintain independent versions concurrently
Purpose:
To accommodate change with a minimum of disruption to existing applications.
Description:
As technology continues to change and evolve, systems must allow client processes and server processes to develop independently
Requirement:
To allow for synchronous and asynchronous communications
Purpose:
To prevent communications bottlenecks
Description:
Distributed systems components should use asynchronous message-based communications while local systems components can communicate synchronously.
The Koba client/server architecture is designed to meet the requirements mentioned earlier:
.
The OSAPI, as described , performs it's function in servicing requests on a client, local server, gateway server, application server or host server as required. The balance of this section discusses the OSAPI internal components. Specifics of the transaction lifecycle are discussed later.
The OSAPI is organized into the following servicing component areas.
1) Configuration and Control Services.
2) Message and Unit of Work Services.
3) Static Data and Synchronization Services.
4) Business Rules Enforcement Services.
5) Communication Services.
This service area is unique to each occurrence/instance of the OSAPI. It defines the level and type of service required by this instance of the OSAPI. Gateway and server instances reflect the UOW control nature of their operation. Client instances reflect the nature of activity that this client may require services for.
This service area manages the interface with the application processes. This involves the manipulation of instance variables, relating of these instance variables to a message and the relating of these messages to a unit of work. The data typing and message structure are retrieved as static data from the information warehouse.
This service area manages the static data which this instance of the OSAPI as well as local applications may need in order to operate effectively. Gateway instances require automatic synchronization of any data which is maintained locally whereas client instances need to maintain data only as requested. The data structures, types and contents are defined in and retrieved from the information warehouse.
The business rule enforcement service area provides the facility by which business rules may be enforced local to an instance of the OSAPI. These are enforced as syntactical or domain rules at the client and as business contextual rules at the application servers. The business rules (and their represented knowledge) reside as static data in the information warehouse.
The communication service area manages the selected communication interface from this instance of the OSAPI. Typically selected services will reflect queue and control as well as response completion.
The data that comprises an object should be accessed only through that object whereas traditional application models allow data modification from any authorized task as orchestrated by the DBMS. The unit of work as implemented through the OSAPI and acting as agent of the object at a remote server complex, allows object level data persistence to take place.
The OSAPI manages instance variables on behalf of application objects. The instance variable content is set in the OSAPI as directed by application commands and is organized by the application's understanding of object. This allows for the bridging of application perception of data (instance variables) to the servers organization of data (transaction based messaging to an RDBMS oriented application).
Issues still exist with respect to coordinated error recovery and the global identification of objects. It should be specifically noted that dependence on large grained objects introduced at a platform level, to ensure the exploitation of local system level integrity mechanisms, may not be prudent. By introducing an external coordinating mechanism, collaborating with the object instance and in extreme cases with the underlying data mechanisms themselves, the severe design constraints realized by larger grained objects can be avoided.
The information refers to the database or collection of databases that provide a central facility for definition of structure and use of sensitive corporate data.
The data model contains the information that describes the elements, entities, relationships and attributes of the relational databases that support the corporate data. This element description is also utilized in formulating the message content as it relates to application level OSAPI access.
The OSAPI imports a local dictionary which is reflective of partial content of this data model, which allows for consistent data treatment throughout the system architecture.
Business rules contain the understanding of what a particular data element (or structure of data elements) can contain. Business rules are declarative in nature however are flexible enough to represent transaction and context applicable constraints.
The enforcement of business rules is carried out by the OSAPI and can be applied at different occurrences of the OSAPI (as required) that a requested transaction (UOW) can pass through in it's life cycle.
The OSAPI initiative highlights at an operational level how objects can be deployed in distributed, heterogeneous environments. The initiative also assists us in focusing on future issues such as:
Should we tell her
The things that went on there that day ?
Should we tell her about it ?
Now, what SHOULD we do ?
Well ...
What would you do
If your mother asked YOU ?
(The final lines of 'The Cat in the Hat' by Dr. Seuss)
Business Object Design and Implementation
| Page Hits | |
|---|---|
| This Page | |
| Since 9/2/95 | |