Client Server Programming With Java and Corba, Second Edition with CD Rom / Edition 2

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (37) from $1.99   
  • New (2) from $50.00   
  • Used (35) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$50.00
Seller since 2014

Feedback rating:

(178)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$50.00
Seller since 2014

Feedback rating:

(178)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

CORBA and JavaBeans are merging in cyberspace. Here's your completely updated guide to navigating this previously uncharted territory.

Whether you're a seasoned Java programmer, a distributed objects expert, or looking to be a little of both, this Second Edition of the enormously popular Client/Server

Programming with Java and CORBA gives you the programming know-how you need to combine these two technologies into workable client/server solutions for the Object Web.

Full of working code, tutorials, and design trade-offs, this one-of-a-kind book:
* Includes over 250 new pages on JavaBeans, CORBA Beans, and Enterprise JavaBeans. Shows you how to invoke CORBA objects from JavaBeans tools such as Visual Cafe, JBuilder, and Visual Age for Java
* Covers everything from simple ORB programming to exciting new areas such as CORBA 3.0's POA, Object Pass-by-Value, IDL-to-Java, and RMI-to-IIOP
* Uses tutorials and client/server benchmarks to compare CORBA and its competitors including Java/RMI, Java/DCOM, Sockets, HTTP/CGI, and Servlets
* Covers in detail Netscape's ORB: VisiBroker for Java 3.X; it shows you how to use Caffeine to write CORBA/Java applications without IDL
* Provides a Debit-Credit benchmark for JDBC databases to compare 2-tier vs. 3-tier client/server solutions
* Provides a JavaBeans version of Club Med-a Web-based, 3-tier client/server application that uses CORBA, Java, and JDBC
* Shows how to use CORBA's dynamic facilities such as callbacks, dynamic invocations, object introspection, and the interface repository
* Comes with a CD-ROM containing over 16 Java-based client/server applications (and other goodies).

They have written numerous bestselling books including Instant CORBA,The Essential Client/Server Survival Guide, Second Edition, and The Distributed Objects Survival Guide. The two Survival Guides both won the prestigious Software Development/Jolt Award for best computer books.

Visit our website at www.wiley.com/compbooks/


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.

Read More Show Less

Editorial Reviews

From Barnes & Noble

Fatbrain Review

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.

This edition features a complete rewrite of the sample programs -- for example the COUNT program now uses portable server-side APIs. The authors also specifically explain the integration of CORBA and Java object models; hence they provide a distributed object platform. After reviewing CORBA and Java, they arrive at a three-tier Object Web model. Here, they explore programming concepts, performance comparisons, local invocations and remote invocations. The fascinating performance comparisons include: applets versus client applications, just in time compilers versus interpreters, C++ versus Java ORB, and Java/CORBA versus legacies and competitors. The authors also explain CORBA's interface repository, including POA adopted in CORBA 3.0. They then compare CORBA/Java with JDBC and explain the Java Bean component model and the 100% CORBA-compatible Enterprise JavaBeans (EJBs). Finally, they bring all these technologies together in a revised JavaBeans ClubMed client/server application.

The CD-ROM contains client/server applications, tools and utilities.

To get up to speed, we strongly recommendthe author's prior introductory volumes such as The Essential Client/Server Survival Guide, The Essential Distributed Objects Survival Guide or Instant CORBA. Other good complementary volumes for this publication are Java Programming with CORBA and The Essential CORBA: Systems Integration Using Distributed Objects.

Booknews
A book/CD-ROM package showing how to combine Java and distributed objects technologies into workable client/server solutions for the Object Web, featuring working code, tutorials, and advice on design trade-offs. This second edition contains some 250 pages of new material on the integration of CORBA, JavaBeans, and Enterprise JavaBeans. It also uses tutorials and client/server benchmarks to compare CORBA and its competitors, and provides a JavaBeans version of Club Med, a Web-based, 3-tier client/server application that uses CORBA, Java, and JDBC. The companion CD-ROM contains Java-based client/server applications. Assumes a working knowledge of Java. Annotation c. by Book News, Inc., Portland, Or.
Read More Show Less

Product Details

  • ISBN-13: 9780471245780
  • Publisher: Wiley
  • Publication date: 3/28/1998
  • Edition description: CD Rom Included
  • Edition number: 2
  • Pages: 1072
  • Product dimensions: 7.34 (w) x 9.07 (h) x 2.33 (d)

Meet the Author

Robert Orfali and Dan Harkey are client/server system creators and distributed object consultants for IBM. They also head the CORBA/Java distributed objects master's program and lab at San Jose State University.
Read More Show Less

Read an Excerpt


Chapter 34

...After more than a year in the making, JavaSoft released-- in December, 1997--a public draft of its Enterprise JavaBeans (EJB) specification. The EJB specification defines a server component model for JavaBeans. An EJB is a specialized, non-visual JavaBean that runs on a server. Like JavaBeans, EJBs can be assembled via tools to create new applications.

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:

  • Activates and deactivates your components. In the CORBA world, the OTM works with the POA to activate and deactivate objects when requests arrive and when they complete.
  • Coordinates distributed transactions. The OTM lets you declaratively define your transactional objects. It starts transactions if none exist. It will then manage the completion of a transaction using the underlying CORBA Object Transaction Service (OTS).
  • Notifies your component of key events during its life cycle. The OTM notifies a component when it is created, activated, deactivated, and destroyed. Your component can then use these calls to explicitly manage its state, and to grab or release system resources.
  • Automatically manages the state of your persistent component. The more advanced OTMs can automatically load the state of a component from a persistent store and then later save it on transactional boundaries.
In summary, OTMs have what it takes to fulfill the promise of scalable server-side objects.

CORBA OTMs

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.

  • Distributed object infrastructure--EJB does not concern itself with the distributed object infrastructure; it assumes an underlying ORB that understands the CORBA RMI/IDL semantics. The ORB transport must also be able to propagate CORBA OTS transactions; IIOP ORBs are designed to provide this type of service.
  • Component packaging and deployment--EJB defines a packaging mechanism for server-side components based on JARs, manifests, and deployment descriptors. The container un-JARs the EJB and then runs it based on the instructions it gets from the manifest and the deployment descriptors.
  • Declarative transaction management--EJB supports implicit transactions built on the CORBA OTS/JTS service. Your bean does not need to make explicit calls to OTS/JTS to participate in a distributed transaction. The EJB container automatically manages the start, commit, and rollback of a transaction. You define the transactional attributes of a bean at design time (or during deployment) using declarative statements in the deployment descriptor. Optionally, a bean can explicitly control the boundaries of a transaction using explicit CORBA OTS/JTS semantics.
  • Factory support--EJB containers manage the entire life cycle of an enterprise bean. As a bean provider, you are responsible for defining a remote factory interface for your bean. You must define a factory interface that extends Factory and defines one or more create methods, one for each way you create an EJB object. The container provider will automatically generate the factory implementation. However, your bean must implement an ejbCreate method for each create method you defined in the factory interface. As a last step, you must register your factories with the container so that clients can create new beans. The container also provides a Finder interface to help clients locate existing entity beans.
  • Bean activation and passivation--as part of managing the life cycle of an enterprise bean, the container calls your bean when it is loaded into memory (or activated); it also calls it when it is deactivated from memory (or passivated).
  • Bean state management--EJB containers can manage both transient and persistent beans. Persistent (or entity) beans encapsulate in their object reference a unique ID that points to their state. An entity bean manages its own persistence by implementing the persistence operations directly. The container simply hands it a unique key and tells it to load its state. In a future release of EJB, the entity bean will be able to delegate the management of its persistence to its container. In the simplest case, the container will serialize the bean's state and store it in some persistent store. The more sophisticated containers will be able to map the bean's persistent fields to columns in an RDBMS. Finally, the container may choose to implement persistence using an embedded ODBMS.
  • Container metadata--EJB containers can provide metadata about the beans they contain. For example, the container can return the class name of the enterprise bean that this factory interface is associated with.
  • Security--EJB containers automate the management of some of the security aspects of your beans. You get to declaratively define the security rules for your enterprise bean in a SecurityDescriptor object; you must then serialize this object and put it in your bean's JAR. The EJB container uses this object to perform all security checks on behalf of your bean.
This short list should give you a good idea of what an EJB container does for its beans.

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:

  • Executes on behalf of a single client. By definition, a session bean instance is an extension of the client that creates it.
  • Can be transaction-aware.
  • Updates data in an underlying database.
  • Is relatively short-lived. Its lifetime is typically that of its client.
  • Is destroyed when the EJB server crashes. The client has to re-establish a new session object to continue a computation.
  • Does not represent data that should be stored in a database.
A session bean typically reads and updates data in a database on behalf of its client. Its fields may contain conversational state on behalf of the client. This state describes the conversation represented by a specific client/instance pair. Within a transaction, some of this data may be cached in the bean.

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:

  • Supports shared access from multiple users.
  • Participates in transactions.
  • Represents data in the database.
  • Can be long-lived (lives as long as the data in the database).
  • Survives crashes of the EJB server. A crash is transparent to the client.
  • Has a persistent object reference. The object reference encap- sulates the Object Id (or persistent key) for this bean.
The support for session objects is mandatory for an EJB 1.0 compliant container. The support for entity objects is optional, but it becomes mandatory for EJB 2.0 compliant containers.

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:

  • Obtain a factory object. The client invokes the getFactory method to obtain a factory; it then uses the factory to create new EJB objects in the container.
  • Destroy an EJB object. Typically, a client will explicitly destroy a session EJB object. In contrast, the life cycle of an entity EJB is usually controlled by its OTM. However, the client can hint that the object should be destroyed.
  • Obtain a Finder object. This allows a client to find existing entity beans in this container. Note that session objects are not tracked via a Finder; they're disposable objects.
  • Get metadata describing the container. The container maintains all sorts of information on the EJBs that run within it. Authorized clients can access some of this information.
In Figure 34-5, the client invokes the getFactory method on the Container object to obtain MyEjbFactory. Then it invokes create on MyEjbFactory to create MyEjb.

In addition, a client can obtain a reference to an existing EJB entity object in any of the following ways:

  • Receive a reference as a parameter in a method call (input parameter or result).
  • Invoke the Finder to locate objects that already exist in a given container.
  • Obtain a reference from a bean Handle. Note that a Handle contains a serialized version of an object reference inside a stream. You invoke getEJBObject on a Handle to obtain a live object reference for this bean. This function is equivalent to CORBA's string-to-object.
  • Invoke a CORBA Trader or Naming service. In addition, EJB supports the Java Naming and Directory Interface (JNDI). Netscape also intends to let you find CORBA/EJB objects via LDAP-based directories using URLs.
The CORBA object reference to an EJB contains additional Helper functions that you may find useful. A client can now invoke added functions on a CORBA object reference to:
  • Obtain a reference to the object's container.
  • Obtain the name of the enterprise bean class that provides the implementation of the business methods.
  • Obtain the EJB object's primary key. Every entity EJB object has a unique identity within its container. A client that holds a reference to an EJB object can determine the object's identity by invoking the getPrimaryKey method on the reference.
  • Obtain the EJB object's Handle.
  • Destroy the EJB object.
Note that these additional Helper functions are defined by the java.ejb.EJBObject interface. They are implemented by the container on behalf of your EJB. A CORBA container can easily implement these functions on top of the POA...
Read More Show Less

Table of Contents

Partial table of contents:

CORBA MEETS JAVA.

Client/Server, CORBA-Style.

Meet the CORBA/Java ORBs.

CORE CORBA/JAVA.

Your First CORBA Program.

ORBlets Meets Applets.

THE DYNAMIC CORBA.

The Dynamic Count.

MultiCount: The Jazzed-Up Count.

CORBA AND ITS COMPETITORS.

Sockets Versus CORBA/Java ORBs.

RMI Versus CORBA/Java ORBs.

DCOM Versus CORBA/Java ORBs.

THE EXISTENTIAL CORBA.

How Do I Find My ORB?

Metadata: Who Am I?

JDBC 2-TIER VERSUS 3-TIER.

JDBC Primer.

2-Tier Debit-Credit with JDBC.

FROM JAVABEANS TO ENTERPRISE JAVABEANS.

The Smiley JavaBean.

The Persistent JavaBean.

Cobra Beans.

GRAND FINALE: CLUB MED WITH COBRA/JAVABEANS.

The Club Med 3-Tier Client/Server.

The Club Med Client Beans.

CORBA/Java: The Good, the Bad, and the Ugly.

Where to Go for More Information.

Index.

Read More Show Less

First Chapter

Chapter 34. Enterprise JavaBeans and CORBA



What is particularly exciting about Enterprise

JavaBeans for Oracle is that it provides a

standardized way to build manageable Java business

components. Enterprise JavaBeans will take full

advantage of Oracle's Network Computing

Architecture's Cartridge infrastructure for

manageability, IIOP connectivity, and CORBA

services.



-- Beatriz Infante

Senior VP, Oracle



Iona Technologies welcomes the release of the

Enterprise JavaBeans specification. It leverages

related OMG and CORBA standards and clearly shows

JavaSoft's commitment to using open standards where

possible. We look forward to supporting Enterprise

JavaBeans in the Orbix family of products.



-- Annrai O'Toole

CTO, IONA Technologies





After more than a year in the making, JavaSoft released--

in December, 1997--a public draft of its Enterprise

JavaBeans (EJB) specification. The EJB specification

defines a server component model for JavaBeans. An EJB

is a specialized, non-visual JavaBean that runs on a

server. Like JavaBeans, EJBs can be assembled via tools

to create new applications.



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 scalable way 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:



o Activates and deactivates your components. In the

CORBA world, the OTM works with the POA to activate

and deactivate objects when requests arrive and when

they complete.



o Coordinates distributed transactions. The OTM lets

you declaratively define your transactional objects.

It starts transactions if none exist. It will then

manage the completion of a transaction using the

underlying CORBA Object Transaction Service (OTS).



o Notifies your component of key events during its life

cycle. The OTM notifies a component when it is

created, activated, deactivated, and destroyed. Your

component can then use these calls to explicitly

manage its state, and to grab or release system

resources.



o Automatically manages the state of your persistent

component. The more advanced OTMs can automatically

load the state of a component from a persistent store

and then later save it on transactional boundaries.



In summary, OTMs have what it takes to fulfill the

promise of scalable server-side objects.



CORBA OTMs



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.



o Distributed object infrastructure--EJB does not concern

itself with the distributed object infrastructure;

it assumes an underlying ORB that understands the

CORBA RMI/IDL semantics. The ORB transport must also

be able to propagate CORBA OTS transactions; IIOP

ORBs are designed to provide this type of service.



o Component packaging and deployment--EJB defines a

packaging mechanism for server-side components based

on JARs, manifests, and deployment descriptors. The

container un-JARs the EJB and then runs it based on

the instructions it gets from the manifest and the

deployment descriptors.



o Declarative transaction management--EJB supports

implicit transactions built on the CORBA OTS/JTS

service. Your bean does not need to make explicit

calls to OTS/JTS to participate in a distributed

transaction. The EJB container automatically manages

the start, commit, and rollback of a transaction.

You define the transactional attributes of a bean at

design time (or during deployment) using declarative

statements in the deployment descriptor. Optionally,

a bean can explicitly control the boundaries of a

transaction using explicit CORBA OTS/JTS semantics.



o Factory support--EJB containers manage the entire life

cycle of an enterprise bean. As a bean provider, you

are responsible for defining a remote factory

interface for your bean. You must define a factory

interface that extends Factory and defines one or

more create methods, one for each way you create an

EJB object. The container provider will

automatically generate the factory implementation.

However, your bean must implement an ejbCreate method

for each create method you defined in the factory

interface. As a last step, you must register your

factories with the container so that clients can

create new beans. The container also provides a

Finder interface to help clients locate existing

entity beans.



o Bean activation and passivation--as part of managing

the life cycle of an enterprise bean, the container

calls your bean when it is loaded into memory (or

activated); it also calls it when it is deactivated

from memory (or passivated).



o Bean state management--EJB containers can manage both

transient and persistent beans. Persistent (or

entity) beans encapsulate in their object reference

a unique ID that points to their state. An entity

bean manages its own persistence by implementing the

persistence operations directly. The container

simply hands it a unique key and tells it to load its

state. In a future release of EJB, the entity bean

will be able to delegate the management of its

persistence to its container. In the simplest case,

the container will serialize the bean's state and

store it in some persistent store. The more

sophisticated containers will be able to map the

bean's persistent fields to columns in an RDBMS.

Finally, the container may choose to implement

persistence using an embedded ODBMS.



o Container metadata--EJB containers can provide metadata

about the beans they contain. For example, the

container can return the class name of the enterprise

bean that this factory interface is associated with.



o Security--EJB containers automate the management of

some of the security aspects of your beans. You get

to declaratively define the security rules for your

enterprise bean in a SecurityDescriptor object; you

must then serialize this object and put it in your

bean's JAR. The EJB container uses this object to

perform all security checks on behalf of your bean.



This short list should give you a good idea of what an

EJB container does for its beans.



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:



o Executes on behalf of a single client. By definition, a session

bean instance is an extension of the client that creates it.



o Can be transaction-aware.



o Updates data in an underlying database.



o Is relatively short-lived. Its lifetime is typically that of its client.



o Is destroyed when the EJB server crashes. The client has to

re-establish a new session object to continue a computation.



o Does not represent data that should be stored in a database.



A session bean typically reads and updates data in a

database on behalf of its client. Its fields may contain

conversational state on behalf of the client. This

state describes the conversation represented by a

specific client/instance pair. Within a transaction,

some of this data may be cached in the bean.



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:



o Supports shared access from multiple users.



o Participates in transactions.



o Represents data in the database.



o Can be long-lived (lives as long as the data in the database).



o Survives crashes of the EJB server. A crash is transparent to the

client.



o Has a persistent object reference. The object reference encap-

sulates the Object Id (or persistent key) for this bean.



The support for session objects is mandatory for an EJB

1.0 compliant container. The support for entity objects

is optional, but it becomes mandatory for EJB 2.0

compliant containers.



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:



o Obtain a factory object. The client invokes the getFactory

method to obtain a factory; it then uses the factory to create new

EJB objects in the container.



o Destroy an EJB object. Typically, a client will explicitly destroy

a session EJB object. In contrast, the life cycle of an entity EJB

is usually controlled by its OTM. However, the client can hint

that the object should be destroyed.



o Obtain a Finder object. This allows a client to find existing

entity beans in this container. Note that session objects are not

tracked via a Finder; they're disposable objects.



o Get metadata describing the container. The container

maintains all sorts of information on the EJBs that

run within it. Authorized clients can access some

of this information.



In Figure 34-5, the client invokes the getFactory method

on the Container object to obtain MyEjbFactory. Then

it invokes create on MyEjbFactory to create MyEjb.



In addition, a client can obtain a reference to an

existing EJB entity object in any of the following ways:



o Receive a reference as a parameter in a method call (input

parameter or result).



o Invoke the Finder to locate objects that already exist in a given

container.



o Obtain a reference from a bean Handle. Note that a Handle

contains a serialized version of an object reference inside a

stream. You invoke getEJBObject on a Handle to obtain a live

object reference for this bean. This function is equivalent to

CORBA's string-to-object.



o Invoke a CORBA Trader or Naming service. In addition,

EJB supports the Java Naming and Directory Interface

(JNDI). Netscape also intends to let you find

CORBA/EJB objects via LDAP-based directories using

URLs.



The CORBA object reference to an EJB contains additional

Helper functions that you may find useful. A client can

now invoke added functions on a CORBA object reference

to:



o Obtain a reference to the object's container.



o Obtain the name of the enterprise bean class that provides the

implementation of the business methods.



o Obtain the EJB object's primary key. Every entity EJB object has

a unique identity within its container. A client that holds a

reference to an EJB object can determine the object's identity by

invoking the getPrimaryKey method on the reference.



o Obtain the EJB object's Handle.



o Destroy the EJB object.



Note that these additional Helper functions are defined

by the java.ejb.EJBObject interface. They are

implemented by the container on behalf of your EJB. A

CORBA container can easily implement these functions on

top of the POA.



The Remote EJB Interfaces



Figure 34-6 shows the remote EJB interfaces. These are

the same interfaces we covered in the last section. They

are implemented as CORBA (or RMI) objects that are

accessible to remote clients. Remember, the new

Java-to-IDL reverse-language mapping uses

java.rmi.Remote to flag a remote CORBA interface.



Figure 34-6. The Remote EJB Interfaces.



We also include the more detailed interface definitions.

Be warned that these interfaces were still under

construction as we go to press.



Listing 34-1. The java.ejb.EJBObject Interface.



public interface EJBObject extends java.rmi.Remote

{

public abstract void destroy();

public abstract String getClassName();

public abstract Container getContainer();

public abstract Handle getHandle();

public abstract Object getPrimaryKey();

public abstract boolean isIdentical(EJBObject bean);

}



Listing 34-2. The java.ejb.Container Interface.



public interface Container extends java.rmi.Remote

{

public abstract void destroy(Handle handle);

public abstract void destroy(Object primaryKey);

public abstract ContainerMetaData getContainerMetaData();

public abstract Factory getFactory();

public abstract Finder getFinder();

}



Listing 34-3. The java.ejb.ContainerMetaData Interface.



public interface ContainerMetaData extends java.rmi.Remote

{

public abstract String getClassName();

public abstract Container getContainer();

public abstract Class getPrimaryKeyClass();

}



Listing 34-4. The java.ejb.Factory Interface.



public interface Factory extends java.rmi.Remote

{

public abstract String getClassName();

public abstract Container getContainer();

}



Listing 34-5. The java.ejb.Finder Interface.



public interface Finder extends java.rmi.Remote

{

public abstract EJBObject findByPrimaryKey(Object

primaryKey);

public abstract String getClassName();

public abstract Container getContainer();

}



Listing 34-6. The java.ejb.Handle Interface.



public interface Handle extends java.io.Serializable

{

public abstract EJBObject getEJBObject();

}



An EJB Client/Server Scenario



Figure 34-7 shows an EJB client/server interaction

scenario; it assumes an IIOP ORB. The client creates a

new EJB instance and then invokes its methods. Here are

the steps:



Figure 34-7. An EJB Client/Server Scenario.



1. Find a container by name. The client invokes the

CORBA ORB pseudo-object's resolve_initial_references

to obtain an object reference to a Naming Service.

It then uses it to obtain a reference to the named

container.



2. Get a Factory for this class of bean. The client

invokes getFactory on the Container to obtain a

reference to the MyEjbFactory object.



3. Create and initialize a new bean. The client invokes

create on MyEjbFactory and passes it initialization

information. If this is an entity bean, the factory

object works with the POA to generate an object

reference with a unique key.



4. Invoke the methods on this enterprise bean. The

client can now invoke the CORBA methods that implement

the business function on MyEJB. Note that the call

may first go to a Tie object servant, which then

delegates it to a separate implementation object.

EJB requires this level of indirection to allow a

container to interject its value-added functions.



As you can see, there's nothing too earth-shattering in

the way a client interacts with its EJB. Most of the

EJB magic is totally invisible to clients.



The EJB/Container Protocol



At the heart of the EJB architecture is the managed

object framework a container (or OTM) provides to its

beans. From the time it is created until it is

destroyed, an enterprise bean lives inside a container.

The container provides security, concurrency,

transactions, persistence, and other services to the EJB

object. Even though much of this magic is totally

transparent to remote clients, it requires a tight level

of synchronization between a container and its beans.

Of course, the beans must play by the rules of their

framework--the container (or OTM)--to reap all these

benefits.



We already gave you the 50,000 foot view of what a

container does for its beans. In the next few sections,

we will zoom-in on the interfaces and protocols that the

two sides require of each other. Remember, this is a

server-side affair--the clients remain totally oblivious

to the protocols that tie the EJBs to their containers.



The Container/Bean Callbacks



EJB is mostly about the interfaces a managed object

exposes to its container, and vice versa. The only

purpose of these interfaces is to help the container

manage all of its objects in the most scalable way. The

container can activate and deactivate any object it

wants whenever it finds it necessary. In addition, the

container can help the object participate in

transactions; it can also synchronize the active

lifetime of an object with the boundaries of a

transaction.



To synchronize their actions, the container and its EJBs

communicate via callback interfaces. Containers make

no actual service demands on their beans. The container

calls its beans to notify them when some action may be

necessary; it also passes them object references to the

container's context-based services.



Figure 34-8 shows the key callback interfaces a

container exposes to its beans, and vice versa. From a

container/bean viewpoint, session and entity beans are

not alike--they each have their own interfaces. A

container maintains a SessionContext object for each

session bean that runs within it. Likewise, it

maintains an EntityContext object for each entity bean.

The container first creates a bean and then passes it a

context object; the bean is associated with its context

for the duration of its lifetime.



Figure 34-8. The Key EJB Container/Bean Callback Interfaces.



The container communicates with a session bean by

invoking the methods defined in the SessionBean

interface. A transactional session bean may also choose

to implement the optional SessionSynchronization

interface. To communicate with an entity bean, the

container invokes the methods defined in the EntityBean

interface. The bottom line is that to be called EJBs,

your CORBA servants must also implement either the

SessionBean or EntityBean interfaces.



The Container/Bean Interfaces



Figure 34-9 shows the hierarchy structure of the

java.ejb callback interfaces. The left side shows the

container interfaces; the right side shows the

interfaces for both session and entity beans. Notice

that all EJBs are serializable. The EnterpriseBean

interface is just a flag; every EJB class must implement

it. Session beans must implement the SessionBean

interface; entity beans must implement the EntityBean

interface. These are the two callback interfaces that

allow a container to manage the life cycle of its beans.



Figure 34-9. The EJB Container/Bean Interfaces.



The best way to understand these interfaces is to walk

through the major transitions in the life of an EJB

instance:



o Creation. An EJB instance's life starts when a

container creates a new instance of a bean and then

invokes either setSessionContext or setEntityContext

to pass the bean a reference to its context object--

which is the object the bean uses to callback the

container. Your EJB implementation can take

advantage of this call to allocate the resources it

will need during its lifetime--for example, a DBMS

connection. Note that an instance can be reused

during its lifetime to serve multiple EJB objects.

Consequently, the resources cannot be specific to an

EJB object reference.



o Life by the pool. EJB instances will live happily

inside pools of available instances until a client

request arrives. If there is no EJB instance in the

ready state to service this request, the container

picks an instance off the pool. All instances in the

pool are identical--they are not associated with the

identity of a specific EJB object.



o From pool to active state. There are two possible

transitions from the pool to the ready state: 1) via

the ejbCreate method, and 2) via the ejbActivate

method. The container invokes the ejbCreate method

when a client invokes the corresponding create method

on the EJB factory. If the client invokes a request

for an object that already exists, the container will

instead invoke ejbActivate. In both cases, the

instance is now active and associated with an EJB

object reference.



> The ejbCreate method gives your instance a chance

to validate the client- supplied arguments and

initialize the instance variables from the input

arguments. An entity instance must invoke the

setPrimaryKey method on its EntityContext to provide

the container with a primary key that it can then

embed into the EJB object reference. This is also

the reference the factory returns to the client.

Typically, your entity instance will also insert a

record into a database to represent this EJB object

reference; it will copy or compute the initial values

from the input arguments of the ejbCreate.



> The ejbActivate method gives your instance a

chance to acquire additional resources that it needs

while it is in the active state. An entity instance

uses this call to obtain the identity of the EJB

object by invoking either the getPrimary-Key or

getEJBObject methods on its EntityContext object. It

can then use this primary key to load its state from

a database.



o The active state. The EJB can receive any number of

method invocations from its clients. In addition,

the container invokes the ejbLoad and ejbStore

methods whenever it needs to notify an entity bean

instance to synchronize (or refresh) its state with

a persistent store.



o Back to the pool. There are two ways for a bean to

transition back to the pooled state: 1) when the

container calls ejbPassivate, and 2) when it calls

ejbDestroy. The container invokes the ejbPassivate

method to disassociate the instance from the EJB

object reference; the instance uses this method to

deallocate resources it obtained during the

ejbActivate. The container invokes the ejbDestroy

method to destroy the EJB object (when the client

invokes the destroy method on the EJB object or one

of the destroy methods on the container). The entity

bean uses ejbDestroy to delete its entity state from

the database. In all cases, the instance returns to

the pool; it is no longer associated with the identity

of the EJB object. The container can then reassign

the instance to any EJB object of the same enterprise

bean class.



o Destruction. An entity instance in the pool is

terminated when the container calls its

unsetEntityContext method. Your instance can take

advantage of this call to free any resources it holds.

Because the container does not reference this

instance, the Java garbage collector will eventually

invoke the finalize method on the instance and then

garbage collect it.



This short explanation should help you understand almost

all the interfaces in Figure 34-9. You should note that

some of the callbacks provide return values that an EJB

can use to vote on the outcome of a transaction (more

on this in the next section). The optional

SessionSynchronization interface allows a session bean

to be notified by its container of transaction

boundaries. In general, we recommend that you only use

explicit DBMS transactions with a session bean. We

believe that using JTS/OTS with a session bean is

overkill.



In case you're interested, here are the detailed

interface descriptions:



Listing 34-7. The java.ejb.EnterpriseBean Interface.



public interface EnterpriseBean extends java.io.Serializable

{

}



Listing 34-8. The java.ejb.SessionBean Interface.



public interface SessionBean extends EnterpriseBean

{

public abstract void ejbActivate();

public abstract void ejbDestroy();

public abstract void ejbPassivate();

public abstract void setSessionContext(SessionContext ctx);

}



Listing 34-9. The java.ejb.EntityBean Interface.



public interface EntityBean extends EnterpriseBean

{

public abstract void ejbActivate();

public abstract void ejbDestroy();

public abstract void ejbLoad();

public abstract void ejbPassivate();

public abstract void ejbStore();

public abstract void setEntityContext(EntityContext ctx);

public abstract void unsetEntityContext();

}



Listing 34-10. The java.ejb.InstanceContext Interface.



public interface InstanceContext

{

public abstract Identity getCallerIdentity();

public abstract Container getContainer();

public abstract CurrentTransaction getCurrentTransaction();

public abstract Properties getEnvironment();

public abstract boolean isCallerInRole(Identity role);

}



Listing 34-11. The java.ejb.SessionContext Interface.



public interface SessionContext extends InstanceContext

{

public abstract EJBObject getEJBObject();

}



Listing 34-12. The java.ejb.EntityContext Interface.



public interface EntityContext extends InstanceContext

{

public abstract EJBObject getEJBObject();

public abstract EJBObject getEJBObject(Object primaryKey);

public abstract Object getPrimaryKey();

public abstract void setPrimaryKey(Object primaryKey);

}



Listing 34-13. The java.ejb.SessionSynchronization Interface.



public interface SessionSynchronization

{

public abstract void beginTransaction();

public abstract void afterCompletion(boolean committed);

public abstract void beforeCompletion();

}



Support For Transactions



One of the key features of EJB is its support for

distributed transactions. EJB lets you write an

application that atomically updates data that is

distributed across multiple DBMSs and sites. The sites

may use EJB servers from different vendors. EJB

insulates you from dealing with the complexity of

distributed transactions. It shifts the burden of

managing transactions to the OTM providers. You simply

declare the transaction scope of your bean and then let

the OTM implement the necessary low-level, two-phase

commit protocols between a transaction manager and a

database system. IIOP--augmented with OTS--can

transparently handle the propagation of the transaction

context across the network.



The EJB Transaction Model



Enterprise JavaBeans supports flat transactions,

modeled after the OMG Object Transaction action Service

(OTS). An enterprise bean object that is

transaction-enabled corresponds to a CORBA

Transactional Server object. A future release may allow

an enterprise bean to act as a CORBA Recoverable Server

object. The framework hides most of the CORBA OTS

details from the application developer. Consequently,

most enterprise beans will not directly access the CORBA

OTS APIs (or the Java version called JTS). However, the

OTM must implement OTS (or JTS) for EJB to work.



EJB Transaction Usage



EJB allows an application program to update data in

multiple databases in a single transaction. In Figure

34-10, a client invokes EJB1 in Server 1 to update data

inside Oracle and DB2 DBMSs. Then, EJB1 calls EJB2 in

Server 2 to update data inside a Sybase DBMS and to

invoke a mainframe transaction via CICS. We use

IIOP/OTS to implicitly propagate the transaction across

the wire.



When the transaction commits (or aborts), the EJB

servers use the OTS distributed two-phase commit

protocol (as well as XA) to ensure that the database

updates are atomic. In other words, all the updates to

all the resource managers are either all committed or

all rolled back; it's all-or-nothing. CORBA OTS

gateways to CICS, IMS, Tuxedo, and MQSeries are

available from InSession, BEA, Visigenic/Borland, and

IBM. Gateways make it possible for existing resource

managers to transparently participate in EJB

transactions.



As an EJB application programmer, you do not have to

write any special code to make all this happen. You

invoke standard JDBC calls (without any commits or

rollbacks). Behind the scenes, the EJB servers enlist

all the DBMS managers that are part of the transaction.

They take care of issuing the commit on behalf of your

beans. They will also represent your beans in the

two-phase commit negotiation.



Figure 34-10. The Transparent Propagation of an EJB Transaction.



Figure 34-11 shows how a client uses the

java.jts.CurrentTransaction interface to explicitly

demarcate transaction boundaries. In this case, the

client: 1) invokes begin on the CORBA CurrentTransaction

object to start the transaction, 2) invokes EJB1 on

Server 1 to update data inside Oracle and DB2 DBMSs, 3)

invokes EJB2 on Server 2 to update data inside a Sybase

DBMS and to invoke a mainframe transaction via CICS, and

4) completes the transaction by invoking commit on its

CurrentTransaction object.



Figure 34-11. A Client-Demarcated EJB Transaction.



Under-the-cover IIOP automatically propagates the

transaction context to all the EJB servers. When the

client calls commit, the two servers use CORBA OTS to

automatically perform the two-phase commit protocol.

Again, if all this sounds a bit strange, you may want

to read our introduction to CORBA OTS in Instant CORBA.



Declarative Transaction Management



One of the key concepts in EJB is that the container can

interpose itself between every client method invocation

on an enterprise bean object. This is why they want

your servant to delegate the implementation to a

separate instance via the CORBA Tie mechanism. This

interposition makes it possible for an EJB container to

take over the transaction management responsibilities.

Your job is then to use simple declarative attributes

to inform the container of the transactional needs of

your beans. You specify these transaction attributes

in your enterprise bean's deployment descriptor. A

transaction attribute can be on a per-method basis or

for an entire bean.



Table 34-1 explains the actions a container takes when

it receives a call for a transactional bean. Each value

of that attribute results in a different action on the

part of the container.







Table 44-1. EJB's Declarative Transaction Attributes.



Transaction

Attribute Value



Container Action



Not_Supported



The container invokes the bean's method outside the scope of a transaction. If

the client calls within a transaction scope, the container suspends the transaction

scope within the current thread before delegating the method call to the

enterprise bean. The container resumes the suspended transaction when the bean

completes the method call.



Bean_Managed



An enterprise bean with this attribute can issue explicit transaction calls using

the java.jts.CurrentTransaction interface.



Requires



The container invokes the bean's method within the client's transaction. If the

client is not part of a transaction, the container automatically starts a new

transaction before delegating the call to the enterprise bean object. The container

attempts to commit the transaction when the bean completes the call. The

container performs the commit protocol before sending the method results back

to the client.



Supports



The container invokes an enterprise bean with this attribute in the client's

transaction. If the client is not part of a transaction, then the container invokes

the method outside of a transaction; it does not start a new transaction.



Requires_New



The container always invokes a bean with this attribute inside a new transaction.

The container will automatically start the new transaction before calling the bean;

it then attempts to commit the transaction when the method completes. The

container performs the commit protocol before it returns the method result to

the client. Note that if a client request is associated with a transaction, the

container suspends the incoming transaction; it resumes it when the new

transaction completes.



Mandatory



The container always invokes a bean with this attribute inside the client's

transaction. If the client is not part of a transaction, the container throws a

TransactionRequired exception to the client.



Figure 34-12 shows how you would use declarative

transaction attributes to let an EJB container

automatically manage the propagation of transactions on

your behalf. In this case, a non-transactional client

invokes EJB1, which has a Requires_new value on its

transactional attribute. So, the container starts a T1

transaction before passing the method call to EJB1.

EJB1 then calls EJB2, which has a Supports value on its

transactional attribute. So, the container will pass

it the T1 transaction context. Finally, EJB2 calls

EJB3, which has a Mandatory value in its transaction

attribute. The container is very happy to oblige and

also passes it the T1 transaction context. As a result,

all the beans execute as part of the T1 transaction.

The good news is that you don't have to write a single

line of code to make all this happen.



Figure 34-12. EJB Declarative Transactions: Scenario 1.



Figure 34-13 is another example of how you would use

declarative transaction attributes with your beans. In

this case, we're dealing with a transaction-savvy

client. The client invokes begin on the CORBA

CurrentTransaction object to start transaction T1; it

then invokes EJB1, which has a Supports value on its

transactional attribute. EJB1--now part of T1--first

invokes EJB2 and then EJB3. EJB2 has a Supports value,

so it happily joins the T1 transaction. However, EJB3

is marked as Requires_New. So the container

automatically starts a new transaction on its behalf

called T2, and then hands it the call. EJB3 in turn

calls EJB4 and infects it with the T2 transaction. In

this scenario, we end up with two independent

transactions T1 and T2. Each transaction will enlist

new supporters as it propagates its merry way.



Figure 34-13. EJB Declarative Transactions: Scenario 2.



EJB Packaging



One of the great strengths of EJB is that it extends the

existing JavaBeans packaging technology to take care of

the needs of server-side beans. You can use EJB

packaging to distribute a single enterprise bean or to

distribute an entire server-side application built of

multiple enterprise beans.



EJB-JAR and Manifest



Enterprise beans are packaged for deployment in a

standard JAR called an ejb-jar file. An ejb-jar file

contains: 1) the EJB's class files, 2) its deployment

descriptor, and 3) a manifest that identifies the

enterprise beans included in the JAR.



As usual, the manifest is named META-INF/MANIFEST.MF.

The sections that provide information on enterprise

beans use the following format:



Name = name of serialized (.ser) deployment descriptor file

Enterprise-Bean = True



For example:



Name: book/SmileyEJBDeployment.ser

Enterprise-Bean: True



Deployment Descriptor



You must include a deployment descriptor for each

enterprise bean in your JAR. A deployment descriptor

is a serialized instance of a

java.ejb.deployment.EntityDescriptor or

java.ejb.deployment.SessionDescriptor object.



Security Descriptor



The EJB architecture also allows a container to perform

declarative security management. Again, this means that

you don't have to write code to protect your bean.

However, this requires that you provide a security

descriptor, which is a serialized instance of

java.ejb.deployment.SecurityDescriptor.



The EJB Deployment Classes



Figure 34-14 shows the key classes in the

java.ejb.deployment package. These classes describe

the deployment and security properties of a bean. Think

of them as glorified data structures. You include

serialized versions of these classes in an ejb-jar to

specify your bean's deployment and security attributes.

The idea is to use an EJB deployment tool to set the

values of these attributes for your bean; you then

package the (.ser) files as part of an ejb---jar file.

The container uses the getter functions to read the

deployment descriptor from the ejb-jar file when it

imports your bean.



Figure 34-14. The EJB Deployment Classes.



Here's a quick description of these classes:



o The DeploymentDescriptor class is the common base class

for the SessionDescriptor and EntityDescriptor

classes. The setSecurityDescriptor method associates

a SecurityDescriptor with this bean. It causes the

container to apply the SecurityDescriptor to all the

methods of your enterprise bean. You can override

the per-bean security with a per-method security by

using a MethodDescriptor object. The

setTransactionAttribute method sets the enterprise

bean's transaction attribute; the acceptable values

of the transaction attribute are defined in the class

TransactionAttribute. The transaction attribute

applies to all the methods of the enterprise bean,

unless you override it with a per-method

MethodDescriptor object.



o The EntityDescriptor class defines the deployment

descriptor for an entity enterprise bean. You use a

serialized instance of this class as the standard

format for passing an entity EJB's declarative

attributes in the ejb-jar file.



o The SessionDescriptor class defines the deployment

descriptor for a session enterprise bean. You use a

serialized instance of this class as the standard

format for passing a session EJB's declarative

attributes in the ejb-jar file. You can declare the

state management of a session bean to be pinned, which

means a container can never deactivate it. You can

declare it to be stateful, which means a container

can deactivate it between transactions. Finally, you

can declare it to be stateless, which means a

container can use multiple instances of it.



o The MethodDescriptor class defines deployment

information for a single method. This per-method

information overrides any information you set at a

per-bean level. You can provide a MethodDescriptor

object for any remote method--including the EJB's

remote interface, factory, and finder.



o Th
Read More Show Less

Preface

Preface

The next shift catalyzed by the Web will be the adoption of
enterprise systems based on distributed objects and IIOP (Internet
Inter-ORB Protocol). IIOP will manage the communication between the
object components that power the system. Users will be pointing and
clicking at objects available on IIOP-enabled servers. We expect to
distribute 20 million IIOP clients over the next 12 months and
millions of IIOP-based servers over the next couple of years. We'll
put the platform out there so that people can start developing for
it.

-- Marc Andreessen,
Netscape Cofounder

Marc Andreessen eloquently describes the Object Web—or the morphing
of distributed objects and the Web. The Object Web is the latest
paradigmatic shift in the distributed software industry. It is
redefining the way we develop, deploy, maintain, package, and sell
our client/server applications. Objects break up the client and
server sides of an application into smart components that can play
together and roam across networks. The Web and intranets provide
the intergalactic networks where these components live. Java
provides the mobile code infrastructure. And, it also provides the
beans.

Is CORBA/Java Ready for Client/Server Prime Time?

The Object Web is still under construction. It seems that everyone
in the software business is building a piece of it today. In this
book, we look at two of the Object Web's core technologies: Java and
CORBA/IIOP. Java provides the mobile code foundation; CORBA
provides the distributed object infrastructure. They are both
foundations of the Object Web.

So, what is the state of these two foundation technologies? Can we
use CORBA and Java today to deploy a new generation of Web-based
client/server applications? Are they ready for mission-critical
prime time? What is the state of the CORBA/Java integration? What
role do JavaBeans and Enterprise JavaBeans play? These are the
questions we try to answer in this book.

We found that the best way to get a reality check on where things
stand is to write lots of working code. Currently, most Java
applications have been standalone demos, but the real value of Java
is when you build portable clients to much larger transactional
systems. This is where CORBA and JavaBeans come into the picture.
We hope to show you in this book that you can use CORBA and Java
today to create some dynamite client/server applications. So we
will put CORBA and JavaBeans through the wringer by running
benchmarks. We will also be developing industrial-strength
client/server applications using CORBA and Java. Finally, we will
look at some of the alternatives—including DCOM/ActiveX, RMI,
HTTP/CGI, Servlets, and Sockets.

The CORBA/Java Integration Story

You've probably already heard about CORBA; otherwise, you wouldn't
be reading this book. And, of course, you've heard of Java or you
wouldn't be from this planet. We assume that you think that CORBA
and Java are important new technologies, which is why you purchased
this book. So what could be left to say about CORBA and Java? It
may come as a surprise, but very little has been said about how CORBA
and Java play together. And, even less has been said about how CORBA
and JavaBeans play together. This entire book is about the
intersection of these two important object models.

We must warn our Java readers that CORBA is a lot more than just an
ORB—it is also a complete distributed object platform. CORBA extends
the reach of your applications across networks, languages, component
boundaries, and operating systems. CORBA supplements Java with a
rich set of distributed services that includes introspection,
dynamic discovery, transactions, relationships, security, naming,
and so on. CORBA provides the missing link between the Java mobile
code environment and the world of intergalactic objects.

Now, we must warn our CORBA readers that Java is much more than just
another language with CORBA bindings. Java is a mobile object
system; it's a portable operating system for running objects. Soon,
Java will allow your CORBA objects to run on everything from
mainframes to network computers and cellular phones. JavaSoft seems
to be defining new portable services every day—including server-side
components, transactions, security, persistence, and system
management. Like CORBA, Java is in the process of building a
gigantic object infrastructure.

Luckily, these two object infrastructures complement each other
well. Java starts where CORBA leaves off. CORBA deals with network
transparency, while Java deals with implementation transparency.
Java simplifies code distribution in large CORBA systems—its
bytecodes let you ship object behavior around. Java is an almost
ideal language for writing both client and server objects. Its
built-in multithreading, garbage collection, and error management
make it easier to write robust networked objects.

In the past, OMG has kept its distance from implementation and
language issues (except for bindings). Consequently, CORBA is a
language-independent object model, which is a good thing. However,
Java solves some thorny implementation problems that have stood in
the way of developing a truly portable distributed object market,
which is also a good thing.

What This Book Covers

This book explains the intersection of CORBA and Java in depth. It
is also a gentle guide to client/server programming with CORBA and
Java. The book introduces CORBA to Java programmers. However, we
do not introduce Java to CORBA programmers. We assume that you have
a working knowledge of the Java language. If you don't, there are
dozens of books that provide introductions to Java. Our book starts
with the JDK 1.1 (or above); we give detailed explanations of
anything that has to do with the new JDK system facilities—for
example, RMI, JDBC, JavaBeans, Enterprise JavaBeans, sockets,
serialization, security, and reflection.

This book consists of eight Parts that build on each other:

o Part 1 starts with an overview of what CORBA and Java do for each
other. We explain the 3-tier Object Web client/server model. We
provide a bird's-eye view of CORBA/IIOP for Java programmers. If
you come from a client/server background, this discussion will
help you understand what the Object Web is all about. We conclude
Part 1 by picking a CORBA/Java ORB for this book.

o Part 2 starts our exploration of the CORBA/Java programming model.
We develop a small client/server Ping that serves as a mini
crash-course in core CORBA/Java programming. This simple program
can be surprisingly useful. In Part 2, we use it to do the
following performance comparisons: local invocations versus
remote invocations, Java applets versus Java client applications,
JIT compilers versus interpreters, and C++ ORBs versus Java ORBs.
Finally, we use the program to show you how to call a C++ object
from Java, and vice versa.

o Part 3 starts out with a rewrite of our Count program using the
new portable server-side CORBA APIs as well as the standard CORBA
Naming Service. This move gives us an ORB-independent,
standards-based platform that we use to write the rest of the
programs in this book. We then show you how to program CORBA's
dynamic object facilities. The dynamic CORBA lets you create
very flexible systems where clients and servers discover each
other at run time. We look at two very versatile programming
mechanisms: dynamic invocations and callbacks. With CORBA's
dynamic invocations, any Java client can construct a remote method
call on-the-fly, and then invoke it. With callbacks, clients can
also be servers. Callbacks let servers call Java clients wherever
they are. You will learn how to create multithreaded Java objects
that are both clients and servers. This chapter also provides
Ping performance numbers for CORBA's dynamic facilities.

o Part 4 compares CORBA/Java with its competitors: 1) legacy Internet
middleware—including Java Sockets, Servlets, and CGI/HTTP, and
2) non-CORBA Java ORBs—including JavaSoft's RMI and Microsoft's
DCOM. We also cover Caffeine, which is the Netscape/Visigenic
answer to RMI; it provides an RMI-like programming environment
on top of CORBA/IIOP. Caffeine lets you write CORBA distributed
objects without CORBA IDL. It demonstrates a pure Java alternative
to the traditional CORBA development process. In addition to the
programming examples, we provide in-depth tutorials on each of
these technologies. We also run Ping benchmarks to give you a
feeling for their relative performance. It's not every day that
you see the same Java client/server program running over Sockets,
Servlets, HTTP/CGI, RMI, DCOM, and CORBA.

o Part 5 is about the "existential" CORBA. We explain CORBA's
Interface Repository and introspection facilities. We show you
how an object discovers its intergalactic universe. We also cover
CORBA's activation services—including the new CORBA 3.0 Portable
Object Adapter (POA). An ORB must provide the illusion that all
of its objects—and there can be millions of them--are up and running
and active all the time, even though they are not. This illusion
keeps the client code simple but it shifts the implementation
burden to the server side. You must write code that cooperates
with the ORB when you start and stop your objects or when the ORB
starts up or shuts down. Finally, we cover in detail the new CORBA
IDL-to-Java mapping. This is the mapping that lets us write very
portable ORB-independent applications. We also cover the
Java-to-IDL mapping. It lets you write CORBA code without IDL.
Instead, you use RMI semantics. This mapping is very important
because it unifies the CORBA and RMI worlds.

o Part 6 is about 2-tier and 3-tier client/server programming using
Java, CORBA, and JDBC. In some circles, client/server is
synonymous with SQL databases. This is not too surprising
considering that SQL database is the most prevalent application
model for client/server today. So one way to determine if CORBA
and Java are ready for client/server prime time is to see how
well they do database. Part 6 starts out with the world's longest
tutorial chapter on JDBC. Then we develop a Debit-Credit benchmark
that compares the performance of 2-tier versus 3-tier
client/server systems using CORBA, Java, and JDBC. We will also
compare the performance of static SQL versus dynamic SQL,
JDBC-style. You will learn--in a fun way--some of the architectural
trade-offs of the client/server discipline.

o Part 7 is about beans--including JavaBeans, CORBA Beans, and
Enterprise JavaBeans. We first go over the JavaBeans component
model in depth. Next, we explain the new CORBA component
initiative--the so-called CORBA Beans (or JavaBeans++). Then, we
cover Enterprise JavaBeans (EJBs). The EJB specification defines
a contract between a server-side JavaBean and an Object
Transaction Monitor (OTM). The OTM manages server-side beans in
a scalable way using transactions, state management, and automatic
activation and deactivation. EJB was designed from ground zero
to be 100% CORBA-compatible. It augments CORBA by defining the
interfaces between a server-side component (or bean) and its
container. 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, package,
and set the properties of your server-side components--including
their transactional, security, and state management policies.

o Part 8 concludes--in grand finale style--with a Web-based, Club Med
-client/server application. This Part brings it all together. We
write a bean-based client applet that associates GUI events with
method invocations on CORBA/Java server objects. In this 3-tier
client/server application, the middle-tier objects interact with
both the Web-applet clients and the Club Med JDBC database. We
also include a poor man's TP Monitor for managing multithreaded
server objects. We assemble our Club Med beans using three visual
tools: Symantec's Visual Cafe PDE, Borland's JBuilder C/S, and
IBM's VisualAge for Java. We show you how much visual
client/server assembly you can do with these tools today. We
even create a simple delegate class that makes our CORBA
server-side objects look like ordinary beans.

A lot of this material covers previously uncharted territory. As
far as we know, this is the first book that puts through the wringer
client/server systems that use CORBA, JavaBeans, and JDBC.
Consequently, we will develop complete 3-tier client/server
frameworks for these technologies from scratch.

What Are the Boxes For?

We use shaded boxes as a way to introduce concurrent threads in the
presentation material. It's the book's version of multitasking.
The Soapboxes introduce strong opinions or biases on some of the
more controversial topics of distributed object computing. Because
the discipline is so new and fuzzy, there's lots of room for
interpretation and debate--so you'll get lots of Soapboxes that are
just another opinion (ours). The Briefing boxes give you background
or tutorial type information. You can safely skip over them if
you're already familiar with a topic. The Detail boxes cover some
esoteric area of technology that may not be of interest to the
general readership. Typically, the same readers that skip over the
briefings will find the details interesting (so you'll still get
your money's worth). Lastly, we use Warning boxes to let you know
where danger lies--this is, after all, previously uncharted
territory.

How to Read This Book

As we recommend in all our books, it's best to ask your boss for a
one-week, paid sabbatical to go sit on a beach and read this book.
Tell him or her that it's the cheapest way to revitalize yourself
technically and find out all there is to know about distributed
objects, CORBA, and JavaBeans. Note that this time you should also
take a laptop with you to run all the programs that come with the
CD-ROM. One of the benefits of local/remote transparency is that
you can run all the client and server programs on the same machine--
including the ORB. So once you sink into that comfortable chair
overlooking the ocean, we think you'll find the book a lot of fun--
maybe even downright relaxing. If you do somehow become bored,
simply jump to the next Part until you find something you like. But
before jumping around, you need to read Chapter 4. It also helps
to read Part 1.

What's New in This Edition

We thank our readers for keeping the first edition of this book at
the top of the bestselling charts for over six consecutive months.
As a result of this phenomenal success, our publisher asked us to
do a "minor" update to bring this book up-to-date. Much to our
surprise, this update became a major nine-month effort.

Over half of this book contains entirely new material--including the
chapters on JavaBeans, CORBA Beans, Enterprise JavaBeans, Servlets,
Java-to-IDL, IDL-to-Java, POA, Portable Count, CORBA Naming, and the
JavaBeans version of Club Med. All the programs in the book were
completely updated to comply with JDK 1.1, the new CORBA/Java
mapping, VisiBroker 3.1, and the latest Netscape and Microsoft
products. We also updated the chapter on the Object Web to reflect
the latest in Internet middleware.

This book is at the bleeding edge of two technologies--JavaBeans and
CORBA. Both are moving at bullet-train speeds. So there's no
stability in sight. Writing code in this kind of environment is an
ongoing struggle; it just doesn't sit still. Our students in the
CORBA/Java graduate program suffer with us as we constantly look for
this stable cross-section of technology where it all works together--
they need it for their projects. Nirvana is where it all comes
together. The collection of products and standards we use in this
second edition represents the current Nirvana; it's a stable point.
We hope you can put this stable point to good use. Also, be sure
to visit our Web site for the latest updates and fixes to our
software.

Who Is This Book For?

This book is for anyone involved with client/server programming,
distributed objects, Java, or JavaBeans. It's particularly
important for the following readers:

o Java programmers who need to understand client/server computing,
distributed objects, CORBA/IIOP, JavaBeans, and JDBC. This book
prepares you for the brave new world of distributed components
and Enterprise JavaBeans.

o CORBA programmers who need to understand Java, JavaBeans, and
Enterprise JavaBeans. This book is all about CORBA/Java
integration. We also cover the latest Java-related CORBA
standards and work-in-process--including IDL-to-Java,
Java-to-IDL, RMI/IDL, Java/POA, Objects-by-Value, and CORBA
Components.

o MIS programmers who are evaluating distributed components, CORBA,
Java, JavaBeans, Enterprise JavaBeans, and intranets. This book
provides you with tons of benchmarks and apple-to-apple
comparisons with other forms of middleware--including DCOM,
HTTP/CGI, RMI, Servlets, and Sockets. We also give you a feel
for the state-of-the-art in visual client/server assembly using
off-the-shelf JavaBeans tools.

o Client/server architects who are thinking about using CORBA,
JavaBeans, and Enterprise JavaBeans on their platforms. This is
the first book that exhaustively looks at Java as a client/server
platform. You'll get the good, the bad, and the ugly.

Eventually, every programmer will have to write a JavaBean component
or distributed object program. So you'll find that reading this
book is time well spent. If nothing else, it will give you a
jump-start for programming the Object Web. Non-programmers can read
the tutorials, benchmarking chapters, and the detailed comparisons.
However, you may be better off reading one of our other books (see
the next section). This one is really for programmers.

How Does This Book Compare With Our Other Books?

Here's what we cover in the other three books:

o The Essential Client/Server Survival Guide, Second Edition (Wiley,
1996) provides an overview of the entire field of client/server
computing--including NOSs, SQL databases, data warehouses, TP
Monitors, groupware, the Internet, system management, tools, and
distributed objects. The book also includes a 100-page
introduction to the Object Web.

o The Essential Distributed Objects Survival Guide (Wiley, 1996)
covers distributed objects in-depth. The book also covers
components and business objects. However, it's not a programming
book.

o Instant CORBA (Wiley, 1997) is a 300-page quick introduction to
CORBA and its Object Services--including Security, Trader, and
Transactions. Again, it's not a programming book. It's an
introduction for people who are in a hurry.

We borrowed about 80 pages of relevant material from the two Survival
Guides to make this book stand on its own. We also include some
material from Instant CORBA.

CD-ROM and Book Web Site

The CD-ROM in our first edition was quite bare. In contrast, this
CD-ROM is full of great evaluation software. Borland even created
an evaluation copy of JBuilder Client/Server especially for this
book. Here's some of the software you'll find on this CD-ROM:

o Source code for all the programs in this book

o Borland/Visigenic VisiBroker for Java 3.1

o Borland/Visigenic VisiBroker for C++ 3.1

o Borland/Visigenic CORBA Naming Service

o Symantec Visual Café PDE

o IBM VisualAge for Java

o Borland JBuilder Client/Server

o JavaSoft JDK 1.1

o Connect Software FastForward JDBC driver

o Netscape Enterprise Server and Communicator

o InstallShield InstallShield Java Edition

With InstallShield, you should have no trouble installing the
programs on your favorite platform.

Because all this area is in flux, we will continue to maintain a Web
site with FAQs and code updates. So visit us at
http://www.corbajava-.engr.sjsu.edu.

A Personal Note

Despite the frustrations that come with exploring uncharted
territory, we really enjoyed writing this book. Java has brought
the fun back into client/server programming. JavaBeans is making
it even better. We hope that you'll enjoy the tutorials, code, and
Soapboxes. Drop us a line if you have something you want to "flame"
about. We'll take compliments, too. We're relying on word-of-mouth
to let people know about the book, so if you enjoy it, please spread
the word. Finally, we want to thank you, as well as our Martian
friends, for trusting us to be your guides.
Read More Show Less

Foreword

Foreword
by Zog the Martian

Greetings, Earthlings! I'm Zog, the captain of the Martian team.
My team and I have visited Earth several times to understand what
client/server is all about. In our previous visits, we discovered
The Essential Client/Server Survival Guide and The Essential
Distributed Objects Survival Guide. These two books were absolutely
vital in our mission to explore this new technology. We really like
the concept of the Object Web; it has great potential for our Martian
intergalactic network. So, we were very excited to hear about
Client/Server Programming with Java and CORBA by the same authors.
We returned to Earth to pick up a copy of the book and do some serious
CORBA/Java programming. It was just what we were looking for.

So what did I like about this book? It felt like it was talking
directly to me and to my crew in a friendly voice. That's very
important when you're from a foreign planet. The artwork is
absolutely wonderful. I like to see pictures of myself in books
(and especially on the cover). The ubiquitous scenarios show how
objects really interact with each other. It's not that inert boring
stuff you read in the textbooks. It makes objects come to life.

Mars has adopted Java as its programming language and JavaBeans as
its component model. This is the first programming book to cover
client/server computing and distributed objects with Java. It
contains a lot of good working programs that give us a jump-start
on how to use these distributed objects on our intergalactic
client/server webs. Hopefully, our CORBA objects will be able to
talk to yours.

This second edition is very timely. It explains how CORBA,
JavaBeans, and Enterprise JavaBeans are coming together. It answers
many of our questions about how to mix-and-match these technologies.
We love the new JavaBeans version of Club Med. And, we appreciate
the work the authors did to rewrite their programs using the new
Java/IDL language mapping; it makes us more ORB-independent. We
Martians cherish our independence.

The benchmarks are nice because they help us understand the
trade-offs we face in the design of our distributed software. There
are so many choices. You Earthlings don't make it any easier with
all your competing middleware--DCOM/ActiveX, RMI, Servlets, CORBA,
Caffeine, Sockets, and HTTP/CGI. Why don't you just build
applications instead of fighting middleware wars? As usual, the
Soapboxes help us understand the issues and what the latest Earthling
debates are all about. We like to hear strong opinions instead of
just sterilized information.

After our last trip to Earth, we Martians standardized on CORBA;
it's our distributed object bus. Now we're trying to get CORBA and
Java to work together. Once we do, we can start building our
intergalactic applications. So, I strongly recommend this Second
Edition to my fellow Martians. It's must reading for anyone who
wants to write intergalactic beans using CORBA and Java. Through
this foreword, I highly recommend this book to you Earthlings. If
I can program in Java and CORBA, so can you. Of course, if you wait
another year, you may not even have to program any more. You may
just be assembling your CORBA/JavaBeans via drag-and-drop. This
book already demonstrates some of what you can do with visual
assembly tools today.
Read More Show Less

Customer Reviews

Average Rating 5
( 1 )
Rating Distribution

5 Star

(1)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted March 29, 2000

    GET THIS BOOK

    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  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)