- Shopping Bag ( 0 items )
Ships from: acton, MA
Usually ships in 1-2 business days
Make no mistake, the Object Web is the forthcoming paradigm of the Internet. This book prepares you for this new archetype, which is also described as the "morphing of distributed objects and the Web." This much revised and expanded client/server programming guide provides Object Web solutions and integrates JavaBeans, Enterprise JavaBeans and CORBA. Keep in mind that this is not a Java/CORBA tutorial, this is an advanced text. The authors assume prior knowledge of the Java language, CORBA ORBs, IDL and familiarity with distributed and client/server concepts.
The EJB server-side component architecture brings together most of the CORBA/Java concepts we cover in this book (and some more). As you can deduce from the above endorsements, EJBs were a big hit with the CORBA camp. Perhaps it's because they were designed from ground zero to be 100% CORBA-compatible. The designers seem to have met their target--the document that describes the EJB-to-CORBA mapping is a mere 20 pages.
We can attribute this lack of "impedance mismatch"to the fact that EJBs use the RMI/IDL CORBA subset for their distributed object model (see Chapter 21). In addition, they use the Java Transaction Service (JTS)--a Java implementation of the CORBA Object Transaction Service -- for their distributed transaction model. EJB also requires CORBA IIOP to: 1) interoperate across multivendor servers, 2) propagate transaction and security contexts, 3) service multilingual clients, and 4) support ActiveX clients via DCOM-to-CORBA bridges.
EJB augments CORBA by defining the interfaces between a server-side component (or bean) and its container. Server components are managed beans that run on a server. The container acts as a component coordinator. It uses a standard JAR package to import EJBs from tools and other containers. Once an EJB is inside its container, it can then be managed in a scalableway using transactions, state management, and automatic activation and deactivation.
The beauty of the EJB framework is that it lets you declaratively define most of your server-side run-time attributes. So you can use visual tools to administer and set the properties of your server-side components-- including their transactional, security, and state management policies.
In this chapter, we first introduce a new breed of CORBA server-side component coordinators called OTMs. Then we explain what EJBs do for these OTMs, and vice versa. Finally, we go over the details of the EJB component model. Be warned that this chapter deals with bleeding-edge technology, much of which is still under construction.
EJBs and CORBA Object Transaction Monitors
EJB is primarily a contract between a server-side JavaBean and a new breed of component coordinator. The Gartner Group calls this new breed of middleware an Object Transaction Monitor (OTM); EJB calls it a server-side Container. An OTM is a morph of a TP Monitor with an ORB. Or, if you prefer, it's a TP Monitor built on top of an ORB. In this section, we explain what is an OTM. We then tell you something about CORBA OTM products. Finally, we explain what EJB does for CORBA OTMs.
So, What Exactly Is an OTM?
An OTM is like an iceberg. Your application only sees the visible 10%. The other 90% provides functions that are beneath the water-line. OTMs imbue your applications with these invisible functions.
-- Jeri Edwards VP of Strategy, BEA Systems
An ORB is simply an object bus. With an object bus, anything goes. In contrast, an OTM provides a framework--or organized environment--for running server-side components (see Figure 34-1). With an OTM, you get organized anarchy: Everything goes as long as you play by the framework's rules.
Figure 34-1. Procedural Versus Framework Approaches to Developing Code.
Like all good frameworks, OTMs follow the Hollywood Principle:"Don't call us; we'll call you." The OTM framework is the primary orchestrator of your server-side components. It calls your components at the right time, and in the right sequence. If you play by the OTM's rules, your objects become managed, transactional, robust, persistent, and high-performing.
An OTM maximizes the reuse of scarce system resources by your components. It prestarts pools of objects, distributes their loads, provides fault-tolerance, and coordinates multi-component transactions. Without this new breed of component coordinators, you cannot manage millions of server-side objects--a key requirement of the Object Web.
In Part 6, we had to develop an object dispenser from scratch to get our application to scale. This was our "poor man's" version of a server-side framework. In contrast, with commercial OTMs, you will be able to get off-the-shelf frameworks that embody the best server-side programming practices. Your components will inherit these "best practices" from your OTM. The OTM becomes the central figure in the life of your components. Here are some of the activities an OTM orchestrates on behalf of your components:
A number of CORBA-based component coordinators are currently under construction. They come from four groups of vendors (see Figure 34-2):
Figure 34-2. CORBA Object Transaction Monitors (OTMs)
1. TP Monitor vendors moving to ORB-based middleware. The two examples from this camp are IBM's Component Broker and BEA System's Tuxedo/ Iceberg. Both of these products are currently in beta. The IBM Component Broker builds on the SOM CORBA ORB and borrows elements from the Encina and CICS TP Monitors. The result is a framework for managed components that lets you mix in over nine CORBA services. In addition, Component Broker provides instance managers that let you automatically manage an object's state and map it to data in an RDBMS. BEA Iceberg combines the scalable Tuxedo TP Monitor infrastructure with the BEA Object Broker CORBA ORB; it also provides a higher-level framework for managed components.
2. DBMS vendors moving from 2-tier to 3-tier. The textbook example of a CORBA OTM from this camp is Oracle's Application Server 4.0; it provides an application server for CORBA/Java components on top of the Borland/Visigenic ORB (and an Oracle server-side IIOP ORB). Gemstone/J is an application server that uses an ODBMS-enabled Java VM to manage a component's state. And, there's always a chance that Sybase may adapt its Jaguar application server to CORBA.
3. ORB vendors moving from pipes to TP-based application servers. The two examples of CORBA OTMs from this camp are Iona's OrbixOTM and Borland/Visigenic's Integrated Transaction Service (ITS).
4. Web server vendors moving to TP-based application servers. The two examples of CORBA OTMs from this camp are NetDynamics' Application Server 4.0 and Netscape/Kiva's forthcoming Enterprise Server 4.0. In addition, BlueStone is also starting to move in this space; its Sapphire/Web 4.0 application server now supports IIOP. Finally, Lotus' forthcoming IIOP-based Domino 5.0 may also be included in this category.
All these OTMs support the CORBA object model with extensions. And, they all strive to provide robust object application platforms that can scale to support millions of server-side objects. The more advanced OTMs build on the CORBA Object Transaction Service (OTS). Some even provide transaction connectivity to existing products such as CICS, IMS, Tuxedo, and MQSeries. In addition, they can coordinate CORBA transactions with RDBMSs (and other resource managers) via the X/Open DTP standard and its XA interfaces. This means that an advanced OTM can coordinate--as part of a single transaction--CORBA objects, TP Monitor applications, and resource managers such as RDBMSs, ODBMSs, and Message Queues.
In parallel, Microsoft is building its own server-side component infrastructure; it is based on DCOM and ActiveX. The Microsoft Transaction Server (née Viper) is the DCOM OTM, and it is tightly integrated with the Microsoft IIS Web Server. Microsoft's transaction model is called the Distributed Transaction Coordinator (DTC)--previously known as OLE/TP.
Enterprise JavaBeans and CORBA OTMs
So, what does all this have to do with EJB? This may come as a surprise: CORBA does not define a server-side component coordinator framework. The CORBA POA is a framework for managing persistent or transient objects. However, it does not deal with issues such as transactions, component packaging, or automatic state management. The integration of these pieces is left as an exercise for the vendors.
In addition, CORBA does not have a fully completed server-side component model. In the past five years, ORB vendors have concentrated on the interoperable aspects of CORBA. The CORBA services were defined using the Bauhaus Principle--every service does one thing well. However, there was no notion of a server-side component that could be used to represent a managed object--meaning a toolable object that also incorporates a variety of CORBA services--such as transactions, externalization, events, and licensing. The CORBA beans we described in the last chapter simply make regular CORBA objects more toolable. They are not managed server-side objects.
Consequently, the server-side components that are now being defined by the various CORBA OTM vendors will probably not be interchangeable (even if they are all CORBA-based). This is exactly where Enterprise JavaBeans come to the rescue. EJB defines a server-side component model as well as a component coordinator framework that is totally compatible with CORBA. If the CORBA OTM vendors all decide to implement the EJB specification, then we may get this totally portable server-side component infrastructure (at least for Java components).
As it turns out, all the major CORBA OTM vendors were heavily involved in the development of the EJB specification, which is probably why it took so long to develop. So now we have a JavaBeans-based component model that covers both the client and server sides of the equation. Informally, we were told that G4 plans to extend its CORBA Component Specification to include EJB when it is completed. In other words, the CORBA component model may include both JavaBeans and EJB. JavaBeans will represent simple CORBA objects; EJBs will represent managed CORBA objects that are also OTM-aware. To become a CORBA standard, EJBs must first be extended to support more than just Java on the server. Most of the CORBA OTMs support multilingual components. So there's still work to be done in this area.
The EJB Container Framework
In a multitier application architecture, most of an application's logic is moved from the client to one or more servers. A server component model simplifies the process of moving the logic to the server. The component model implements a set of automatic services to manage the component.
-- Ann Thomas Seybold Group Analyst
EJB provides the first formalized component-to-OTM contract for the CORBA world; it starts out where CORBA/POA leaves off. EJB defines the callback interfaces a JavaBean must expose to its OTM, and vice versa. In addition, EJB specifies a packaging mechanism for server-side components. Figure 34-3 shows the major functions a server-side container (or OTM) provides to the EJBs that run within it. Let's go over the pieces:
Figure 34-3. What EJBs Can Expect From Their Containers.
Session and Entity Beans
Like CORBA objects, an enterprise bean can either be transient or persistent. The EJB specification calls them session and entity beans. A session bean is a transient object that will not outlive the VM in which it is created. In contrast, the lifetime of an entity bean is not limited by the lifetime of the Java VM process in which it executes; a crash of the Java VM may result in a rollback of current transaction, but it neither destroys the EJB entity object nor invalidates a reference to it held by clients. You can later reconnect to this same bean using its object reference. Like its CORBA counterpart, this persistent object reference encapsulates a unique primary key; it allows the bean (or its container) to reload the state of that object.
According to the EJB specification, a typical session bean has the following characteristics:
Session beans are intended to be private resources used only by the client that creates them. For this reason, a session EJB is anonymous; it hides its identity. In contrast, an entity EJB exposes its identity as a primary key. According to the EJB specification, a typical entity bean has the following characteristics:
The EJB Client/Server Development Process
Today, for all practical purposes, EJB is a CORBA++ system. In fact, the only mapping EJB defines is for CORBA. You define your EJB server objects using the OMG's new RMI/IDL reverse-language mapping (see Chapter 21). Figure 34-4 shows the steps:
Figure 34-4. The EJB Client/Server Development Process.
1. Define your EJB's remote interface. Your EJB must declare its remote services via a Java interface. You do this by extending the java.ejb.EJBObject interface, which in turn extends the java.rmi.Remote interface. Each method in a remote interface must throw a java.rmi.RemoteException. If your EJB is transactional, then you must extend the CORBA TransactionalObject interface. It's just an empty flag that tells the ORB to propagate the transaction context over IIOP. Finally, you must define a factory interface for your EJB.
2. Optionally, generate CORBA IDL. Run your interfaces through an RMI2IDL translator to generate CORBA IDL. You will need CORBA IDL to support non-Java clients and to populate an Interface Repository.
3. Compile your interface. You must compile your interface using javac.
4. Create the IIOP stubs and skeletons. Run an RMI2IIOP postprocessor against the (.class) files to generate client stubs and server skeletons for your remote classes. The postprocessor will also generate the necessary helper classes as well as stubs and skeletons for your remote factory interface.
5. Implement the servant. You must provide a Java server class that implements the remote interface you published to the outside world. You can either directly derive this class from an ImplBase class or you may use the CORBA Tie mechanism to delegate the calls to a separate implementation class. EJB recommends that you follow the Tie approach (we cover Tie in Chapter 20).
6. Compile your EJB class. You must compile your servant class using javac.
7. Register your EJB implementation with the server. You must package your EJB servant object in an EJB JAR and then register it with a CORBA OTM server.
8. Implement the Factory object for this EJB. Typically, the code that implements your factory interface will automatically be generated for you. Remember that you must still: 1) define the factory interface for your EJB type, and 2) implement an ejbCreate method in your bean class for each create method you define in the factory interface.
9. Register your Factory with the server. Typically, you will package your factory class in the same JAR as your EJB and then register it with the CORBA OTM server.
10. Write your client code. With the appropriate CORBA bindings, you can write the EJB client in the language of your choice. You can obtain a reference to an EJB either via a Naming Service or by finding a Factory and then creating one. You can always ask your container (or OTM) to provide a reference to a Factory for a particular EJB class. Once you have a reference to the remote object, you then simply invoke its methods via the IIOP stubs that serve as its proxy.
11. Compile the client code. You do this using javac.
12. Start the client. You must load the client classes and their stubs.
As we go to press, there are no RMI2IIOP compilers on the market. There are also no CORBA OTMs that currently support EJBs. Consequently, we cannot validate the development steps we just showed you. We warned you that this was bleeding-edge stuff.
The Client's View of an EJB
To a client, an EJB is simply a remote CORBA object. You must first obtain an object reference for an EJB. Then you invoke the EJB like any local language object. It's just plain old CORBA. In addition, EJB specifies three new CORBA objects on the server that a client can use to find an existing enterprise bean or to create a new one from scratch (see Figure 34-5).
Figure 34-5. The Client's View of an EJB.
An EJB Container is a named object that represents the server where an enterprise bean lives. A client can find a Container object by name using a directory service. Once the client has a reference to a Container object, it can do the following:
In addition, a client can obtain a reference to an existing EJB entity object in any of the following ways:
|Pt. 1||CORBA Meets Java|
|Ch. 1||Client/Server, CORBA-Style|
|Ch. 2||The Object Web: CORBA Meets Java|
|Ch. 3||Meet the CORBA/Java ORBs|
|Pt. 2||Core CORBA/Java|
|Ch. 4||Your First CORBA Program|
|Ch. 5||ORBlets Meet Applets|
|Ch. 6||Java ORBs Meet C++ ORBs|
|Pt. 3||The Dynamic CORBA|
|Ch. 7||The Portable Count|
|Ch. 8||The Dynamic Count|
|Ch. 9||MultiCount: The Jazzed-Up Count|
|Pt. 4||CORBA and Its Competitors|
|Ch. 10||Sockets Versus CORBA/Java ORBs|
|Ch. 11||HTTP/CGI Versus CORBA/Java ORBs|
|Ch. 12||Servlets Versus CORBA/Java ORBs|
|Ch. 13||RMI Versus CORBA/Java ORBs|
|Ch. 14||Caffeine: The "Pure" CORBA/Java ORB|
|Ch. 15||DCOM Versus CORBA/Java ORBs|
|Ch. 16||And the Winner Is|
|Pt. 5||The Existential CORBA|
|Ch. 17||How Do I Find My ORB?|
|Ch. 18||Who Activates My Objects?|
|Ch. 19||Metadata: Who Am I?|
|Ch. 20||The CORBA IDL-to-Java Mapping|
|Ch. 21||The CORBA Java-to-IDL Mapping|
|Ch. 22||The Introspective CORBA/Java Object|
|Pt. 6||JDBC 2-Tier Versus 3-Tier|
|Ch. 23||JDBC Primer|
|Ch. 24||The JDBC Debit-Credit Benchmark|
|Ch. 25||2-Tier Debit-Credit with JDBC|
|Ch. 26||3-Tier Debit-Credit with JDBC and CORBA|
|Pt. 7||From JavaBeans To Enterprise JavaBeans|
|Ch. 27||The JavaBean Component Model|
|Ch. 28||The Smiley JavaBean|
|Ch. 29||The Event-Driven JavaBean|
|Ch. 30||The Propertied JavaBean|
|Ch. 31||The Persistent JavaBean|
|Ch. 32||The Introspective and Toolable JavaBean|
|Ch. 33||CORBA Beans|
|Ch. 34||Enterprise JavaBeans and CORBA|
|Pt. 8||Grand Finale: Club Med with CORBA/Java Beans|
|Ch. 35||The Club Med 3-Tier Client/Server|
|Ch. 36||The Club Med Client Beans|
|Ch. 37||The Club Med CORBA Server|
|Ch. 38||CORBA/Java: The Good, the Bad, and the Ugly|
|Where to Go for More Information|
Posted March 29, 2000
If you want to learn CORBA and be able to compare and contrast it with other ORB technologies this book is a must. The book has simple explanations and sample code that will run with the JDK1.2 ORB in addition to the Visibroker ORB. Big and Yellow and worth every penny!!!!!!!!Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.