------------------------------------------------------------------------------------------------

Decision Situation: The database access method to be used by object applications is one of the most critical choices for designers. It is important to be aware of the possible performance loss between initial prototypes and full-scale operation.

Typical alternatives: There are tools and products that provide connectivity between object application environments and relational databases. Java Database Connectivity (JDBC) drivers are an example using an SQL call level interface. Persistence is a leading example of a tool that provides transparent access from C++ objects to normalized relational data.

Transparent Object Access For object-oriented applications, it is tempting to encapsulate database access with object wrappers. This approach shields application developers from the structure of the underlying database. In practice, this technique often works well for applications that have limited performance requirements. For high-speed access to larger relational databases, the performance penalty for conversion between object access and SQL can be very high. One possible solution is to replicate data into a persistent object store that is tuned for the application.

SQL Database Connectivity: For object applications that require high-performance access to existing relational databases, some form of non-transparent SQL-based access must be provided. These interfaces can be through an SQL-based procedural layer such as Open Database Connectivity (ODBC), an object API that uses SQL such as Java Database Connectivity(JDBC) or similar approaches. For even higher performance, Sun and others are developing an embedded SQL specification for Java called J/SQL. Embedded SQL will permit precompiling of SQL queries.

Decision criteria: In general , smaller applications can use the higher level object interfaces such as the Persistence product. As the performance requirements increase, it is necessary to expose more of the underlying database structure to the application in order to produce optimized queries. This can produce future maintenance problems when the database schema changes.

------------------------------------------------------------------------------------------------

Decision Situation: It is sometimes necessary to perform updates to multiple distributed databases as part of a single logical unit of work.

Typical alternatives: Two alternative choices are the standardized two-phase commit protocol used in the transaction processing monitors and proprietary database replication technologies such as that used by Sybase or Oracle. A third possibility is to use a transaction routing with queuing paradigm that has been adopted by the transaction processing monitor vendors.

Two-phase Commit: There are times when an application or a service has to update several databases as part of a single logical transaction(e.g. transfer of funds). A technique called two-phase commit has been developed to guarantee the integrity of this type of transaction. It requires participating databases to signal readiness to commit an update. When all of the databases are ready a signal is sent out that triggers a permanent update in all of the databases. This approach is also used by objects in the OMG Object Transaction Services. Some applications need this level of assurance but it has been found in practice that two-phase commit can be very inefficient and often is not absolutely necessary.

Database Replication: An alternate approach called database replication has been developed by database vendors and extended to most of the transaction processing monitors. In this method, database updates are transmitted asynchronously between participating databases with guaranteed delivery. This ensures that all of the databases will eventually receive and commit update. In general, database replication has become the technique of choice in most distributed computing architectures. However there will be some temporary inconsistencies between databases that may not be acceptable for some transactions.

Decision criteria: The two phase commit is often seen as necessary when in fact a less synchronous approach such as replication combined with guaranteed delivery would be sufficient. Two phase commit can severely impact performance over widely distributed databases. It should only be used in this case when absolutely necessary. Even for localized networks, it should be used with caution and only after perfomance evaluations.

Decision Situation: In the future there will be a decision to be made on the server side between ActiveX server components, Java Beans and other server technologies

Typical alternatives: Microsoft is pushing ActiveX as a server component technology. JavaSoft is developing specifications for Enterprise Java Beans. The current server technologies are not based on object-oriented components but have more maturity and functionality than either component

ActiveX on the Server: There are several alternative technologies available for building service components. Once again ActiveX has many advantages on Microsoft platforms but suffers from a lack of portability. There will be tight integration between operating system, SQL Server databases, and other Microsoft middleware based on ActiveX. Interoperability with non-Microsoft platforms and applications may be a problem.

Enterprise Java Beans: Enterprise Java Beans have been announced by JavaSoft and a specification effort is underway.. The goal of the JavaSoft enterprise architecture strategy is to produce a standardized Java interface layer on top of the underlying server operating system. It will probably be several years before the technology is ready for serious mission-critical applications. However, it is not necessary to use Enterprise Java Beans to build Java server components and interfaces

Decision criteria: The use of components to provide services can be started today but it is probably wise to hold off for a while on the new object-oriented component approach. The use of Java wrappers around current services is a compromise architecture that should be evaluated.

Decision Situation: This need for this decision will increase in the short term as the use of Java grows. However there will be tools available to allow Java language interfaces to be converted to Interface Definition Languages (IDLs) and vice-versa. This will reduce some of the impact of choosing Java or IDL.

Typical alternatives: There are divergent CORBA and Microsoft IDLs. Both of them are abstractions from programming languages. Java interfaces are part of the programming language.

Interface Definition Languages: The interfaces to server components must be made available to external clients and peers. Both the OMG and Microsoft employ a language-neutral interface definition language for server components. These IDLs are compiled into a language specific interface to the component. The advantages of IDLs for software engineering are clearly defined language-independent syntactical interfaces between components. In CORBA and DCOM, external services are defined using IDL. The disadvantage of IDL is the need to learn an additional language but tools are being developed to automatically.

Java Interfaces: Another approach that is being pushed by some members of the Java community is to use the interface feature that is available with the Java language in place of an external Interface Definition Language. This overcomes the need to learn a new language but seems to require a totally Java development environment. However there are tools that allow Java to interface to other languages including a compiler that transforms Java interfaces into OMG IDL. This capability will allow the use of languages such as C++, when necessary for reasons such as performance or legacy code reuse, within Java wrappers. Using Java interfaces, it will also be possible to transmit Java objects within messages. The Java interface technology is still maturing but will probably be worth serious consideration in the near future.

Decision criteria: The Java interfaces can be more seamless integrated with client and server Java implementations than any IDL. However Java wrappers around other languages have the same interface translation as the IDLs. The final decision among all of the alternatives will probably be based on market penetration of the various approaches. In the short run, Java has the advantage of running on any platform and allowing more flexible communication and dynamic placement for components.

Decision Situation: The communication paradigms that will be used between nodes in a distributed systems are a fundamental choice. It is possible to use alternate methods between different layers.

Typical alternatives: Examples of alternatives are session-based access to databases such as Oracle\rquote s SQLPLUS, basically synchronous requests such as the OMG Object Request Broker, and asynchronous messaging such as IBM' s MQSeries. Each of the three basic methods for communication has advantages for certain applications.

A good analogy that helps to understand the trade-offs is to with alternate styles of phone communication; conversational(session), request/reply/goodbye(synchronous), and phone messaging(asynchronous).

Session: Session-based protocols maintain a connection permitting a conversation dialogue with a server component. This can be very important for complicated interactions and critical transactions. Unfortunately these benefits are often outweighed in large-scale distributed applications by the cost in resources necessary for maintaining numerous sessions to centralized servers. Transaction processing monitors can help to reduce some of the cost of the session approach by sharing connections.

Synchronous Requests: Synchronous request is the fundamental paradigm for remote procedure calls (RPCs) and Object Request Broker. It is a distributed version of the communication between procedures or objects in single platform applications. In the simplest version, a request is sent and the requester blocks until a response is received and the connection is broken. This is more efficient than maintaining a session but can also cause problems with scalability when there are a large number of clients.

Asynchronous Communication: Asynchronous messaging does not maintain any direct connections between communicating components. It permits messages to be stored and delivered at a later time. This is not the best approach for applications that require an immediate, guaranteed response before proceeding. However there is much greater flexibility in routing, translating, batching and prioritizing asynchronous messages than in the other approaches.

Decision criteria: The decision should be based on the performance, synchronization, reliability and scalability requirements of the applications. In general, sessions are useful for maximum interaction at a higher cost in performance, synchronous request is good for simple data retrieval or invoking a procedure, while asynchronous messaging provides the best scalability and flexibility but suffers a penalty in immediate responsiveness.

Decision Situation: This decision determines how flexible the interfaces to service components will be. This is a separate decision from choosing between synchronous and asynchronous communication. It is possible to use synchronous messaging or asynchronous procedure calls.

Typical alternatives: Object request brokers and remote procedure calls use APIs. Transaction processing monitors often use an API with an attached message. Messaging products usually use some sort of self-definition that accompanies the data. Agents are active software components that can read, transform and route messages.

Object APIs: The standard communication used by Object Request Brokers and DCOM is based on a request-response approach similar to a remote procedure call. In general, the use of static APIs between client and server can improve performance but can limit flexibility. It is possible to use dynamic APIs at the cost of reduced performance. The use of downloadable clients with static client interfaces can provide a compromise solution. However the API approach will usually make it more difficult to introduce new modes of communication and functionality such as publish-and-subscribe or priority queued messaging.

Messaging An alternate architecture is to base communication on messages that can be generated or handled by components. This usually will require an active interface layer (agent) to relay messages to and from a component. The disadvantage of this approach is that it can not be made as transparent to the application developer as a set of APIs. It also will reduce the performance of simple request-response communication. The main benefit is the ability to change system components and message formats while still maintaining functionality by updating the adapter layers. Another advantage is the increased scalability possible if messages can be queued and processed by server components at a later time. The increased flexibility and scalability of messaging systems often overweighs the negative impacts in enterprise architectures.

Decision criteria: If system interfaces are stable and high performance is require an API approach could be the best choice. If greater flexibility is required, the messaging approach makes it easier to modify an interface to a component while leaving other components unchanged. This is possible because the agent layer can map older messages to the new interface.

Decision Situation: This is a subtle decision but can have an important impact for maintenance and flexibility. It is possible to using a combination of messaging strategies.

Typical alternatives: MQSeries is an example of simple messaging. NEONet from NEON is an example of rule-based routing. TIBCO is the leading vendor of publish-and-subscribe middleware.

Point-to-point messaging: If a messaging approach is chosen, it is possible to use point-to-point messaging among components and/or queues. The advantage of this approach is that it is simple to implement and is very flexible. The disadvantage for large systems is the configuration management and system management enhancements required as the number of messages increases.

Rule-based Routing: An alternate approach is to use a messaging system or product that includes enhancements for rule-based routing, data transformations and system management. These can be implemented as layers on top of simpler messaging. While this might increase the time and cost of initial implementation, it will often be required for highly distributed mission-critical applications.

Publish-and-subscribe messaging: This is a form of rule-based routing that allows applications to register to receive or send messages of a specified type. This approach is the most dynamic and flexible. In highly distributed system, there may be problems if the number and size of messages gets too large.

Decision criteria: In general, simple messaging can be used if there are a few large resources that are being sent the majority of the messages. If the messaging is occurring between many heterogeneous nodes and the message size is large, rule-based messaging should be the first choice. For dynamic widely distributed systems with many small messages, publish-and-subscribe is usually the best approach.

Decision situation: This decision determines the level of reliability of message delivery. This level of reliability can usually be chosen to depend on the message.

Typical alternatives: Several products such as MQSeries support all three types of message reliability alternatives. It is possible to build enhanced reliability on top of transient message middleware by means of customized acknowledgement protocols.

Transient Messages: Transient messages provide the best performance but can fail to deliver messages if the network, receiver platform or receiver application is not available.

Guaranteed Delivery: Guaranteed delivery usually refers to the ability to queue a message if the network or recipient platform is unavailable. Providing this capability hurts performance but is often necessary for important messages.

Transactional Messaging: Transactional messaging provides a level of reliability beyond guaranteed delivery. This is done by using transactions when placing or retrieving messages from a queue. This ensures that the message is not only delivered to the recipient platform but is actually retrieved successfully by the destination application. This approach can be very costly to performance but is essential for messages that must never be lost.

Decision criteria: The best approach is to ensure that the messaging middleware can handle the expected reliability and performance requirements for the application. Messages should be partitioned with respect to importance. Reliability guarantees should be used for messages only when necessary. In some cases, some additional customizations will have to be added to produce increased reliability. For example, applications with Web front-ends to reliable messaging middleware may require some additional acknowledgement protocol to compensate for the fragility of the Hypertext Transfer Protocol(HTTP).

Decision Situation: For many systems especially workflow, a key decision is whether to base the primary control flow on a procedural or event-driven paradigm

Typical alternatives: Monolithic applications and packages typically use procedural paradigms while systems of loosely coupled applications or components have tended towards even-driven approaches. The user interface paradigm has migrated from procedural screen interfaces to event-driven GUI interfaces.

Procedural: A procedural system restricts the number of alternates that must be considered during implementation. This can increase the speed of deployment and help improve performance. This approach often produces problems with maintenance as business processes and system requirements evolve.

Event-driven: An event-driven approach provide greater flexibility but forces the system designer to evaluate the handling of many different situations. This is similar to the trade-off between a GUI and terminal-based user interface. Publish-and-subscribe middleware combined with message-based interfaces to service components can help in coping with these problems.

Decision criteria: The procedural paradigm should be used for tightly coupled components with stable interaction patterns. In most other cases, the event-driven approach provides more flexibility and easier maintenance.

Decision Situation: Frameworks are a way to share design and software components among projects. They usually contain a skeleton application that is customized for specific applications

Typical alternatives: There are frameworks(white boxes) that allow application developers the ability to modify many of the internal components and interfaces. At the other extreme, some frameworks(black boxes) only allow limited parametric tuning and tightly controlled modifications.

White Box Frameworks: The reuse of application architectures and components linked together into frameworks can provide a tremendous value for future projects. It is necessary to provide mechanisms for customizing the pieces of the frameworks that will change from application to application. It is a great simplification if these changes can be made through table-driven or parametric inputs that do not require knowledge of the underlying architecture(black-box). The client-server application packages such as SAP have attempted to use this approach. Industrial experience has shown that it is very hard to design reusable components or frameworks on an initial project.

Black Box Frameworks: An alternative approach is to make visible to the developers those parts of the framework that can be changed without compromising the essential design or implementation.(white-box). For the initial implementations, developers could customize the framework by modifying code and interfaces. With increasing experience, pieces of the framework could be converted to parametrized components as the design of the framework stabilizes. This approach requires feedback between the maintainers of the framework and developers of new applications.

Decision criteria: The industry consensus is that it is advisable to use a white box approach for initial application implementations using the frameworks. As the problem domain and solution space is becomes better understood, it should be possible to move towards a black box architecture.