Architecture Issues

This sections identifies some of the general OOBTPS architectural issues that are facing OMS.  Some of these issues are caused by the use of a distributed architecture and some issues are due to taking an OO approach. 

Transaction Persistence and Integrity.  there are several approaches to providing integrity and persistence in an OO based system - An RDBMS can be wrappered with OO classes, an OODBMS or ORDBMS can be used, or a TP monitor can be inserted.  Additionally, the persistence and transaction mechanisms can be exposed as first class objects and inherited, or they can be contained within business and data services.

Error Handling.  An OO system provides the opportunity to define errors as first class objects.  A distributed system must be able to handle additional types of errors (e.g., network and server failures) and handle new types of errors (e.g., a server implements new pre-conditions).  An error handling mechanism must apply across the entire architecture.  OMS is considering implementing a generic error class that can be returned from calls to business and data services.

Impact of data changes.  A critical element of most BTP systems is providing information to the user.  This information consists of object types (e.g. client, product) and properties (e.g., name, dollar value).  Object types and core properties are stable over time.  However, user tend to extend the list of properties as business conditions change.  This layered architectural model actually makes those changes more complex, but easier to implement.  Additional properties must be added at all three service layers, but they can be implemented incrementally and without impacting the existing applications.

Reporting.  A common part of  BTP systems are reports.  Reports access data in significantly different fashion than traditional business transactions.  Reports access a large number of records, often require several sorting and filtering criteria and frequently do calculations on the database.  Additionally, it is desirable to build these reports with a report generator which normally accesses a relational DBMS.  OMS is considering implementing a set of database views as part of the data services level interface.  This would allow use of report generators and ad-hoc queries without tying them to the actual DBMS structure.  How should a BTP system expose public properties for ad-hoc queries and reporting ?

Next Page