Gopalan Suresh Raj's Web Cornucopia
An Oasis for the parched Enterprise Services Engineer/Developer

    Technical Publications-Books-Enterprise Java Computing-Applications and Architectures

    Publications, Container-Managed-Models, Distributed-Computing

    In this book, I authored the following chapters:

    Using this book, developers should be able to:

    • Integrate relational databases with RMI and servlets using JDBC
    • Develop sophisticated servlet-based middleware
    • Design multi-tier EJB applications
    • Write Jini services
    • Understand advanced issues regarding RMI and Java IDL development
    • Perform Java/legacy-system integration using JNI
    Enterprise Java Computing-Applications and Architectures Enterprise Java Computing-Applications and Architectures
    English Original Japanese Translation

    Cambridge University Press (SIGS Books)
    Managing Object Technology Series, No 22
    June 1999, Paperback, 360 pages
    ISBN: 0521657121.

    This book empowers corporate developers to deliver mission-critical Java applications that can be deployed in the real world. With ‘Enterprise Java Computing’ the reader will master the critical building blocks that are necessary for developing robust client-server applications, without getting bogged down in the specifics of the Java language and its syntax.


    Chapter 8: Enterprise JavaBeans

    Page 296 - The figure 8-6 should look like this. The one in the book is missing the “Cart”, “Books” and “Music” labels for the Entity Beans

    Figure 8-6: The Four-tier architecture for our online bookstore Figure 8-6: The Four-tier architecture for our online bookstore


    Chapter 8: Enterprise JavaBeans

    Page 332 - 333 : To the Note on pages 332 and 333, I would like to add the following. The entire note with the additions should read as follows:


    Notice I have not talked about database connection pooling in the previous paragraph. While the current EJB specification does talk about instance pooling, it has nothing to say about connection pooling. To see how these instance management algorithms work, think about the EJB component instance as living inside the EJB container. When a method request travels from the client outside the container to the component instance, it must travel through the container. The container intercepts the method before it is delivered to the enterprise bean. This gives the container an opportunity to participate in the delivery of that request. And one of the ways the container can participate is by injecting an instance management algorithm into that delivery.

    Instance management is about faking out the client. The client code thinks it has a dedicated middle-tier instance, just waiting for the next client request. But the client has no idea whether an actual middle-tier instance really exists. All the client knows is this: By the time the method is actually delivered by the container, something needs to be there to receive that method.

    Instance Pooling and EJB

    EJB uses an instance management algorithm called Instance Pooling (IP). In the IP algorithm, the middle-tier instances are themselves pooled, not the database connections. After the method has been intercepted by the container, and before it has been delivered to the enterprise bean instance, the container does not create a brand new instance to process the request—it uses one from a pool of instances. When the instance has finished processing the method, the container does not destroy it. Instead, it is returned to the pool.

    Because the IP algorithm does not constantly create and destroy instances, it needn’t worry about the efficiency of creating and destroying database connections. Certainly, the actual creation of the instance may sometimes be slow, but that happens infrequently.

    The IP code moves the creation and destruction of the database connection out of the business logic and into the methods executed when the instance is first created during ejbActivate() and finally destroyed during ejbPassivate().

    In EJB, the actual middle-tier EJB component instance may be pooled. Since the component may not be running all the time, it does not use up a lot of system resources.

    As soon as the call comes in from the client, the EJB container may use an EJB component instance from a pool of shared instances. And as soon as the request is serviced and the reply is sent back to the client, the actual EJB component is returned back to the pool. It may not be destroyed.

    Generally, this is what happens on the Server when a client requests services from a typical stateless EJB component:

    1. Read the component’s state from the database.
    2. Perform the business logic.
    3. Write the component’s changed state, if any, back to the database.

    EJB isn’t stateless between calls from the client. For stateful beans the above scenario is true if and only if a call to the component coincides one to one with transaction boundaries. You can easily have the following scenario:

    1. Read the component’s state from the database.
    2. Perform the business logic.
    3. Return data to the client.
    4. Client makes 0-N more calls to the bean, performing business logic, and database operations.
    5. Write the component’s changed state, if any, back to the database.

    IP is conceptually simple and has less algorithm dependent code in the business logic. In fact, even the read and write of the component state can be moved out of the business logic if this algorithm is coupled with transactional notification.

    This is where the JDBC 2.0 specification could help because within it you’ll find built-in support for database connection pooling. This means any EJB product can use JDBC 2.0 for relational database access and the connection pooling can be portable across EJB container products.

    The Table Of Contents for the book is as follows:

    by Govind Seshadri

    Chapter 1: Introduction to Enterprise Java Computing

    • Key Enterprise Technologies
    • Using Java for Enterprise Application Development
    • Summary

    Chapter 2: Java Database Connectivity

    • JDBC Architecture
    • JDBC Driver Types
    • Selecting a JDBC Driver
    • JDBC URLs
    • Java/SQL Type Mappings
    • Using the JDBC API
    • Optimizing Queries With Prepared Statements
    • Calling stored procedures using callable statements
    • SQL Escape Syntax
    • Metadata
    • Transaction Management
    • Transaction Isolation Levels
    • Implementing Connection Pools
    • A three-tier solution: Integrating RMI with JDBC
    • JDBC 2.0
    • Summary

    Chapter 3: Deploying Java Servlets

    • Why Servlets are better than CGI Scripts
    • The Java Servlet Development Kit
    • Understanding the Servlet Life Cycle
    • Demonstrating Session-Tracking: The Shopping Cart Servlet
    • Using Cookies for Client-side Persistency
    • The SingleThreadModel Interface
    • Integrating Servlets with JDBC
    • Integrating Servlets with RMI
    • Applet-Servlet Communication Using Object Serialization
    • Summary

    Chapter 4: Melding Java with Legacy Systems using JNI

    • Introducing Native Methods
    • JNI Design Goals
    • What can you do with JNI?
    • Understanding the JNI Life-Cycle
    • Mapping between Java and C Data Types
    • Accessing Java Objects from Native Methods
    • Obtaining JVM Type Signatures
    • Accessing Java Arrays
    • Accessing Java Methods from Native Methods
    • JNI Exception Handling
    • Multithreaded programming with JNI
    • Using the Invocation API
    • Summary

    Chapter 5: Object Serialization

    • Fundamentals of Object Serialization
    • The Serializable Interface
    • Implementing Custom Serialization
    • Implementing Custom Serialization
    • Transmitting Objects over Sockets
    • Transmitting Objects over Compressed Sockets
    • Advanced Serialization
    • Encrypting Serialized Objects via Sealed Objects
    • Understanding Object Versioning
    • Serialization - Advantages and Disadvantages
    • Summary

    Chapter 6: Remote Method Invocation and Jini technology

    • Developing an RMI system - A stepwise approach
    • Understanding Remote Polymorphism
    • Implementing RMI Callbacks
    • Distributed Garbage Collection
    • Working With Firewalls
    • Remote Object Activation
    • Implementing Custom Sockets

    by Gopalan Suresh Raj

    • Jini Technology
    • Developing a Jini service
    • Comparing Jini with RMI
    • Applying Jini Technology
    • Future Trends
    • Summary

    Chapter 7: Java IDL - Java meets CORBA

    • The CORBA Distributed Computing Model
    • The Object Management Architecture
    • The CORBA 2.0 Architecture
    • The Interface Definition Language
    • IDL to Java Mapping
    • Developing CORBA Servers and Clients
    • Stringified Object References
    • The InterestRates Server Example
    • Common Object Services - The Naming Service
    • Common Object Services - The Event Service
    • Putting it all together - The Bank Example
    • Comparing CORBA and Java/RMI
    • Summary

    Chapter 8: Enterprise JavaBeans

    • Backgrounder - The Relevant Technologies
    • Enterprise JavaBeans - Components at the Server
    • The EJB Model
    • The EJB Lifecycle
    • EJB Components
    • Developing an N-tier EJB application
    • Developing Entity Beans
    • Developing Session Beans
    • Modelling using Session and Entity Beans
    • The EJB container
    • EJB Servers
    • Deploying EJBs
    • Future trends
    • Summary

    Author Bibliography

    Gopalan Suresh Raj is a Senior Analyst, Software Architect, and Developer with expertise in multi-tiered systems development, enterprise service architectures, and distributed computing. He is also an active author, including contributions to Professional JMS Programming, Wrox Press, 2001, Enterprise Java Computing-Applications and Architecture, Cambridge University Press, 1999, and The Awesome Power of JavaBeans, Manning Publications Co., 1998. He has submitted papers at international fora, and his work has been published in numerous technical journals. Visit him at his Web Cornucopia© site ( or mail him at