5.3. Approaching the Challenges
Key to resolving the business and technical challenges was to develop a system that was flexible anough to accomodate existing systems while providing the means to do business in completely new ways. It was also key to find a vendor capable of delivering the latest technology while working closely with the CORE team to ensure its success.
5.3.1. Architecture Choice
The choice of an architecture was based on careful consideration of these issues and other factors, including available skill levels within the organization and discussions with senior representatives from leading development tool vendors. As a result, it was decided that the J2EE platform, which had just been publicly released in draft specification form, would be evaluated, along with CORBA, for the server-side component model used by the CORE system. Some important architectural services requirements, along with their J2EE and CORBA implementations, are summarized in Table 5.1.
A comparison of the features of these technologies with the system requirements covered earlier led to the decision to move to J2EE as the architecture of choice, with CORBA integration mandatory. CORBA was seen as very mature but still requiring substantial effort to use for building highly scalable, fault-tolerant business systems. At the same time, the CORBA component specification was in very early development, and there were no vendor implementations. In contrast, Enterprise JavaBeans, JDBC, servlets, and JavaServer Pages APIs (all incorporated into the J2EE specification) were proving to offer a simplified but powerful programming model. J2EE also promised to extend these technologies with a full list of enterprise services, as well as integration with CORBA 2.3.
| Service | J2EE Implementation | CORBA Implementation |
|---|---|---|
| Naming A naming service enables the development of powerful and portable directory-enabled applications | JNDI The Java Naming and Directory Interface (JNDI) provides a unified interface to multiple naming and directory services in the enterprise. As part of the Java Enterprise API set, JNDI enables seamless connectivity to heterogeneous enterprise naming and directory services. | CosNaming The CosNaming service is a generic directory service. The naming service provides the principal mechanism through which most clients of an ORB-based system locate objects they intend to make requests of. |
| Database Connectivity Databases are nearly always an important feature of any large-scale enterprise application. | JDBC 2.0 JDBC provides cross-DBMS connectivity to a wide range of SQL databases. With a JDBC technology-enabled driver, a developer can easily connect all corporate data, even in a heterogeneous environment. | Not Specified CORBA doesn't specify database connectivity as a distinct service. Different database APIs, including JDBC, are expected to be used within each language mapping. Connecting transactional applications to databases is specified in CosTransactions service via resources and resource managers. |
| Transaction Management Transaction management is required to enforce the ACID transaction properties of atomicity, consistency, isolation, and durability. | JTA/JTS J2EE includes support for distributed transactions through two specifications, Java Transaction API (JTA) and Java Transaction Service (JTS). | CosTransaction
The Transaction service is a set of interfaces used to encapsulate a variety of existing transaction and resource-management technologies. It provides a standard interface across different implementations of transaction monitors. |
| Transaction Management | JTA/JTS
JTA is a high-level, implementation- and protocol-independent API that allows applications and application servers to access transactions. JTS specifies the implementation of a transaction manager, which supports JTA and implements the Java mapping of the OMG Object Transaction Service (OTS) 1.1 specification at the level below the API. JTS propagates transactions using the Internet Inter-ORB Protocol (IIOP). | CosTransaction The transaction service though, is used extensively with databases; it is not solely designed for this and has a wide range of applicability. The transactions service works in several modes, including direct and indirect context management and explicit and implicit propagation. |
| Component Model
A component model should address the challenges in enterprise application development, which include concurrency, transactions, security, and data access. The distribution of such components over a network should also be transparent. Since many business components are inherently persistent, it is important that a component model address this in a powerful, portable, and configurable way, transparent to the component provider. | EJB
Enterprise JavaBeans (EJB) servers reduce the complexity of developing middleware by providing automatic support for middleware services, such as transactions, security, database connectivity, and more. The EJB 1.1 specification requires that the EJB container provider implement persistence for entity beans with container-managed persistence. The advantage is that the entity bean can be largely independent from the data source in which the entity is stored. | CORBA components
At the time of the CORE project's inception, the CORBA component model was still undergoing the OMG's submission stage, so there were no implementations. The three major parts of CORBA components are:
|
| Messaging
Messaging provides a reliable, flexible service for the asynchronous exchange of critical business data and events throughout an enterprise. Messaging allows businesses to communicate asynchronously and across numerous decoupled processes. Messaging supports one-to-many and many-to-many communication. | JMS
The Java Messaging Service (JMS) API improves programmer productivity by defining a common set of messaging concepts and programming strategies that will be supported by all JMS technology-compliant messaging systems. JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise-messaging product. | CosEvents and CosNotification
The Event service provides a generic model for push- and pull-based message passing. It allows for transmitting messages among components in a decoupled mode. Events are communicated using IIOP. The Notification service provides a way to filter events and allows for the quality of service to be specified. The CORBA Messaging Specification was under development at the time the CORE project was initiated. |
| Web Integration With increasing reliance on both the Internet and intranets for application distribution, close integration of Web services was key to developing the thin-client front ends included in the CORE system specification. | Java Servlets/Java Server Pages Java Servlets and Java Server Pages (JSP) are platform-independent, 100% pure Java server-side modules that fit seamlessly into a Web-server framework and can be used to extend the capabilities of a Web server with minimal overhead, maintenance, and support. | Java Applets
The Firewall Specification defines a bi-directional General Inter-ORB Protocol connection useful for callbacks and event notifications. The Interoperable Name Service defines one URL-format object reference. |
| EIS Integration As more businesses move toward an e-business strategy, integration with existing enterprise information systems (EIS) becomes the key to success. Enterprises with successful e-businesses need to integrate their existing enterprise information systems with new thin-client, Web-based applications. | Connector
The J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous enterprise information systems. The J2EE Connector architecture enables an enterprise information system vendor to provide a standard resource adapter for its enterprise information system. The resource adapter plugs into an application server, providing connectivity among the system, the application server, and the enterprise application. If an application server vendor has extended its system to support the J2EE Connector architecture, it is assured of seamless connectivity to multiple EISs. | Not Specified The CORBA components container does not address this directly. But through the transaction service and CORBA inherent cross-language support, it is possible to integrate into many enterprise information systems. Most vendors of such systems provide a CORBA interface (IDL) for some parts of their offering. |
| Note that the above descriptions refer to specifications and not implementations. In fact, an implementation of a service within one specification may be used as the basis for another. As one example, JTS/JTA can be built on top of implementations of the CosTransaction Service | ||
Because the J2EE architecture is based on RMI-IIOP inter-object communications, it offered to combine the ease of the RMI programming model with the robustness and maturity of CORBA implementations. The CORBA-compliant IIOP protocol made it possible to interoperate with clients and servers implemented in other languages. In turn, this allowed planning for future migration and integration of the CORE system with other AT&T Unisource applications and systems.
5.3.2. Vendor Selection
After the desired technologies were identified, the next step involved contacting leading application server vendors to evaluate their offerings. The evaluation included prototyping, determining the level of standards compliance, and determining the level of technical quality of support provided. Vendors contacted included WebLogic, IBM (Websphere), Persistence, and Borland. The technical criteria for selection included
Compliance with the J2EE specification, in particular with the EJB 1.1 specification
CORBA 2.3 support, including RMI-IIOP as the communication protocol
Support for container-managed persistence in entity beans
Support for the Java 2 Platform, Standard Edition
Support for JDBC 2.0, Servlets, and JavaServer Pages technologies
Development tool integration
Flexibility in partitioning systems across nodes and processes
Ease of use in deployment, management, and clustering configuration
Integration with application management tools
Maturity of implementation and its underlying foundations
Performance measurements through the use of a test program
Customer service criteria included
Speed of vendor response to initial inquiries
Level and quality of vendor technical support
Feedback regarding concerns and queries coming from the vendor development team
Vendor recognition of partnership as the basis for working together
Based on these criteria, the team decided to go with the Borland AppServer. Support from the local Borland office was very good and the Borland AppServer development team seemed very responsive and positive to questions and suggestions. While the Borland solution was still in early development—moving from Alpha to Beta status—it was quite robust and offered high performance in the areas of main concern to the CORE project team. In early benchmark tests specifically tailored to the problem domain, Borland AppServer appeared to outperform other offerings. An additional benefit of choosing Borland AppServer was that the technology was built on top of Visibroker, which some of the team members had previously worked with.