CTMs require that business objects adhere to the server-side component model implemented by the vendor. A good component model is critical to the success of a development project because it defines how easily an application developer can write business objects for the CTM. The component model is a contract that defines the responsibilities of the CTM and the business objects. With a good component model, a developer knows what to expect from the CTM, and the CTM understands how to manage the business object. Server-side component models are great at describing the responsibilities of the application developer and CTM vendor.
Server-side component models are based on a specification. As long as the component adheres to the specification, it can be used by the CTM. The relationship between the server-side component and the CTM is like the relationship between a CD-ROM and a CD player. As long as the component (CD-ROM) adheres to the player’s specifications, you can play it.
A CTM’s relationship with its component model is also similar to the relationship the railway system has with trains. The railway system manages the train’s environment, providing alternate routes for load balancing, multiple tracks for concurrency, and a traffic-control system for managing resources. The railway provides the infrastructure on which trains run. Similarly, a CTM provides server-side components with the entire infrastructure needed to support concurrency, transactions, load balancing, etc.
Trains on the railway are like server-side components: they all perform different tasks but they do so using the same basic design. The train focuses on performing a task, such as moving cars, not on managing the environment. For the engineer, the person driving the train, the interface for controlling the train is fairly simple: a brake and a throttle. For the application developer, the interface to the server-side component is similarly limited.
Different CTMs may implement different component models, just as different railways have different kinds of trains. The differences between the component models vary, like railway systems having different track widths and different controls, but the fundamental operations of CTMs are the same. They all ensure that business objects are managed so that they can support large populations of users in mission-critical situations. This means that resources, concurrency, transactions, security, persistence, load balancing, and distribution of objects can be handled automatically, limiting the application developer to a simple interface. This allows the application developer to focus on the business logic instead of the enterprise infrastructure.
Microsoft was the first vendor to ship a CTM. Originally called the Microsoft Transaction Server (MTS), it was later renamed COM+. Microsoft’s COM+ is based on the Component Object Model (COM), originally designed for use on the desktop but eventually pressed into service as a server-side component model. For distributed access, COM+ clients use the Distributed Component Object Model (DCOM).
When MTS was introduced in 1996, it was exciting because it provided a comprehensive environment for business objects. With MTS, application developers could write COM components without worrying about system-level concerns. Once a business object was designed to conform to the COM model, MTS (and now COM+) would take care of everything else, including transaction management, concurrency, and resource management.
Recently, COM+ has become part of Microsoft’s new .NET Framework. The core functionality provided by COM+ services remains essentially the same in .NET, but the way it appears to a developer has changed significantly. Rather than writing components as COM objects, .NET Framework developers build applications as managed objects . All managed objects, and in fact all code written for the .NET Framework, depends on a Common Language Runtime (CLR). For Java-oriented developers, the CLR is much like a Java virtual machine (VM), and a managed object is analogous to an instance of a Java class; i.e., to a Java object.
Although the .NET Framework provides many interesting features, as an open standard, it falls short. The COM+ services in the .NET Framework are Microsoft’s proprietary CTM, which means that using this technology binds you to the Microsoft platform. This may not be so bad, because .NET promises to work well, and the Microsoft platform is pervasive. In addition, the .NET Framework’s support for the Simple Object Access Protocol (SOAP) will enable business objects in the .NET world to communicate with objects on any other platform written in any language. This can potentially make business objects in .NET universally accessible, a feature that is not easily dismissed.
If, however, your company is expected to deploy server-side components on a non-Microsoft platform, .NET is not a viable solution. In addition, the COM+ services in the .NET Framework are focused on stateless components; there’s no built-in support for persistent transactional objects. Although stateless components can offer higher performance, business systems need the kind of flexibility offered by CTMs that include stateful and persistent components.
Until the fall of 1997, non-Microsoft CTMs were pretty much nonexistent. Promising products from IBM, BEA, and Hitachi were on the drawing board, while MTS was already on the market. Although the non-MTS designs were only designs, they all had one thing in common: they used CORBA as a distributed object service.
Most non-Microsoft CTMs were focused on what was at the time the more open standard of CORBA, so they could be deployed on non-Microsoft platforms and support non-Microsoft clients. CORBA is both language and platform independent, so CORBA CTM vendors could provide their customers with more implementation options.[5] The problem with CORBA CTM designs was that they all had different server-side component models. In other words, if you developed a component for one vendor’s CTM, you couldn’t turn around and use that same component in another vendor’s CTM. The component models were too different.
With Microsoft’s MTS far in the lead by 1997 (it had already been around for a year), CORBA-based CTM vendors needed a competitive advantage. One problem CTMs faced was a fragmented CORBA market in which each vendor’s product was different from the next. A fragmented market didn’t benefit anyone, so the CORBA CTM vendors needed a standard around which to rally. Besides the CORBA protocol, the most obvious standard needed was a component model, which would allow clients and third-party vendors to develop their business objects to one specification that would work in any CORBA CTM. Microsoft was, of course, pushing their component model as a standard—which was attractive because MTS was an actual working product—but Microsoft didn’t support CORBA. The Object Management Group (OMG), the same people who developed the CORBA standard, were defining an alternative server-side component model. This model held promise because it was sure to be tailored to CORBA, but the OMG was slow in developing a standard—too slow for the evolving CTM market.[6]
In 1997, Sun Microsystems was developing the most promising standard yet for server-side components: Enterprise JavaBeans. Sun offered some key advantages. First, Sun was respected and was known for working with vendors to define Java-based and vendor-agnostic APIs for common services. Sun had a habit of adopting the best ideas in the industry and then making the Java implementation an open standard—usually successfully. The Java database connectivity API, called JDBC, was a perfect example. Based largely on Microsoft’s ODBC, JDBC offered vendors a more flexible model for plugging in their own database access drivers. In addition, developers found the JDBC API much easier to work with than ODBC. Sun was doing the same thing in its newer technologies, such as the JavaMail API and the Java Naming and Directory Interface ( JNDI). These technologies were still being defined, but the collaboration among vendors was encouraging, and the openness of the APIs was attractive.
Although CORBA offered an open standard, it attempted to standardize low-level facilities such as security and transactions. Vendors could not justify rewriting existing products such as TUXEDO and CICS to the CORBA standards. EJB got around that problem by saying that how you implement the low-level services doesn’t matter; all that matters is that all the facilities are applied to the components according to the specification—a much more palatable solution for existing and prospective CTM vendors. In addition, the Java language offered some pretty enticing advantages, not all of them purely technical. First, Java was a hot and sexy technology, and simply making your product Java-compatible seemed to boost your exposure in the market. Java was more or less platform independent, and component models defined in the Java language had definite marketing and technical benefits.
As it turned out, Sun had not been idle after it announced Enterprise JavaBeans. Sun’s engineers had been working with several leading vendors to define a flexible and open standard to which vendors could easily adapt their existing products. This was a tall order because vendors had various kinds of servers, including web servers, relational database servers, application servers, and early CTMs. It’s likely that no one wanted to sacrifice their architecture for the common good, but eventually the vendors agreed on a model that was flexible enough to accommodate different implementations yet solid enough to support real mission-critical development. In December of 1997, Sun Microsystems released the first draft specification of Enterprise JavaBeans, EJB 1.0, and vendors have been flocking to the server-side component model ever since.
So what does it mean to be a standard server-side component model? Quite simply, it means that you can develop business objects using the Enterprise JavaBeans component model and expect them to work in any CTM that supports the complete EJB specification. This is a pretty powerful statement, because it largely eliminates the biggest problem faced by potential customers of CORBA-based CTM products: fear of vendor “lock-in.” With a standard server-side component model, customers can commit to using an EJB-compliant CTM with the knowledge that they can migrate to a better CTM if one becomes available. Obviously, care must be taken when using proprietary extensions developed by vendors, but this is nothing new. Even in the relational database industry—which has been using the SQL standard for a couple of decades—optional proprietary extensions abound.
Having a standard server-side component model has benefits beyond implementation independence. A standard component model provides a vehicle for growth in the third-party products. If numerous vendors support EJB, creating add-on products and component libraries is more attractive to software vendors. The IT industry has seen this type of cottage industry grow up around other standards, such as SQL; hundreds of add-on products can now be purchased to enhance business systems whose data is stored in SQL-compliant relational databases. Report-generating tools and data-warehouse products are typical examples. The GUI component industry has also seen the growth of its own third-party products. A healthy market for component libraries already exists for GUI component models such as Microsoft’s ActiveX and Sun’s original JavaBeans component model.
Many third-party products for Enterprise JavaBeans exist today. Add-on products for credit card processing, legacy database access, and other business services have been introduced for various EJB-compliant systems. These types of products make development of EJB systems simpler and faster than the alternatives, making the EJB component model attractive to corporate IS and server vendors alike. The market is growing for prepackaged EJB components in several domains, including sales, finance, education, web-content management, collaboration, and other areas.
In addition to supporting RMI-based distributed business objects, Enterprise JavaBeans 2.0 supports advanced asynchronous messaging. Asynchronous messaging is an important distributed computing paradigm that has become an important part of EJB.
An asynchronous messaging system allows two or more applications to exchange information in the form of messages. A message, in this case, is a self-contained package of business data and network-routing headers. The business data contained in a message can be anything—depending on the business scenario—and usually contains information about some business transaction. In enterprise messaging systems, messages inform an application of some event or occurrence in another system.
Messages are transmitted from one application to another on a network using message-oriented middleware (MOM). MOM products ensure that messages are properly distributed among applications. In addition, MOM usually provides fault tolerance, load balancing, scalability, and transactional support for enterprises that need to reliably exchange large quantities of messages.
MOM vendors use different message formats and network protocols for exchanging messages, but the basic semantics are the same. An API is used to create a message, give it a payload (application data), assign it routing information, and then send the message. The same API is used to receive messages produced by other applications.
In all modern enterprise-messaging systems, applications exchange messages through virtual channels called destinations . When you send a message, it’s addressed to a destination, not to a specific application. Any application that subscribes or registers an interest in that destination may receive that message. In this way, the applications that receive messages and those that send messages are decoupled. Senders and receivers are not bound to each other in any way and may send and receive messages as they see fit.
Enterprise JavaBeans 2.0 integrates the functionality of MOM into its component model for CTMs. This integration extends the EJB platform’s “operating system” so that it supports both RMI and asynchronous messaging. EJB 2.0 supports asynchronous messaging through the Java Message Service and a new kind of component called the message-driven bean.
Each MOM vendor implements its own networking protocols, routing, and administration facilities, but the basic semantics of the developer API provided by different MOMs are the same. It’s this similarity in APIs that makes the Java Message Service ( JMS) possible.
JMS is a vendor-agnostic Java API that can be used with many different MOM vendors. JMS is very similar to JDBC in that an application developer can reuse the same API to access many different systems. If a vendor provides a compliant service provider for JMS, the JMS API can be used to send messages to and receive messages from that vendor. For example, you can use the same JMS API to send messages with Progress’ SonicMQ as with IBM’s MQSeries.
All JMS vendors provide application developers with the same API for sending and receiving messages, and sometimes they provide a component model for developing routers that can receive and send messages. These component models, however, are proprietary and not portable across MOM vendors.
Enterprise JavaBeans 2.0 introduces a new kind of component, called a message-driven bean, which is a kind of standard JMS bean. It can receive and send asynchronous JMS messages, and because it’s co-located with other kinds of RMI beans (i.e., entity and session beans) it can also interact with RMI components.
Message-driven beans in EJB 2.0 act as an integration point for an EJB application, allowing other applications to send asynchronous messages that can be captured and processed by the application. This is an extremely important feature that will allow EJB applications to better integrate with legacy and other proprietary systems.
Message-driven beans are also transactional and require all the infrastructure associated with other RMI-based transactional server-side components. Like other RMI-based components, message-driven beans are considered business objects, which fulfill the important role of routing and interpreting requests and coordinating the application of those requests against other RMI-based components, namely enterprise beans. Message-driven beans are a good fit for the CTM landscape and are an excellent addition to the EJB platform.
[5] The recent introduction of SOAP brings into question the future of the CORBA Internet Inter-Operability Protocol (IIOP). It’s obvious that these two protocols are competing to become the standard language-independent protocol for distributed computing. IIOP has been around for several years and is therefore far more mature, but SOAP may quickly catch up by leveraging lessons learned in the development of IIOP.
[6] CORBA’s CTM component model, the CORBA Component Model (CCM), was eventually released. It has seen lackluster acceptance in general, and was forced to adopt Enterprise JavaBeans as part of its component model just to be viable and interesting.
Get Enterprise JavaBeans, Third Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
