1

A Java Container Framework for Server Component Models

Sanjay Dalal (sanjay@beasys.com) eCommerce Server Division, BEA Systems, Inc. 2315, N. First Street, San Jose, CA 95131

Abstract
Several server component models exist today and more are being added to the list. This includes Java 2 Enterprise Edition server component models, BEA's WLE CORBA Components, OMG's CORBA Component Model and Microsoft's COM+. All these models require containers to fulfill some common goals. This includes managing lifecycle, state, transaction and security of component in addition to providing it infrastructure services. While the component models define architecture for components and contracts between component and its container, it is left to vendors to define the architecture of containers. As containers of these component models share functional requirements, we could define architecture for a container of a generic server component model. We have put together elements of this architecture in the form of a white-box framework called Java Container Framework (JCF). We believe it essential to have such a framework when a product supports multiple component models.

1 Introduction
1.1 Evolution of Enterprise Application Architecture - need for Server Component Model
Enterprise scale application architecture has evolved from centralized to fat clientdatabase server to thin-client multi-tier architecture. The force behind this evolution is strong requirements for scalability, reliability, availability, manageability, flexibility and reusability demanded by these applications. In multi-tier thin-client architecture, business logic resides on severs and is shared by multiple clients. A combination of application server, middleware, database servers, networks and hardware provides reliability, scalability and availability to such applications. Application servers provide load-balancing, clustering, resource pooling, transaction management, persistence, security, administration and management among other things to applications. Server A Java Container Framework for Server Component Models 01/03/00

2 component architecture frees business-logic-savvy application developers from worrying about this infrastructure by giving that responsibility to Application Servers. Application developers only write components embodying business logic and rely on servers to provide necessary runtime environment. Enterprise applications come to life with deployment of components into application server.

1.2 Purpose
1.2.1 Why Container Framework?
We realized a need for a framework while implementing containers for Enterprise JavaBeans (EJB), Web Components (Java Servlets & JavaServer Pages (JSP)) and WLE CORBA Components (in Java) in BEA's WebLogic product. It appears developers of any product supporting Java 2 Enterprise Edition (J2EE) platform, OMG's CORBA Component Model or both will face the same situation as containers of these component models share a lot of functionality. Container framework seems to be a judicious approach to take.

1.2.2 Why Java?

Two (Enterprise JavaBeans and Web Components - Servlets & JavaServer Pages) out of four component models discussed here are based on Java 2 Enterprise Edition. The other two component models (WLE CORBA Components and OMG's CORBA Component Model) can also be implemented on Java platform. Therefore, it seemed appropriate to name the framework as Java Container Framework. We sincerely believe though that the architecture presented here is independent of platform of implementation.

1.3 Definitions
Framework A framework is a reusable design expressed as a set of abstract classes and the way their instances collaborate. It is a reusable design for all or part of a software system [9]. Application Server An application server provides an execution environment to host applications. It manages and recycles scarce system resources, such as processes, threads, memory, database connections, and network sessions on behalf of the applications. Some application servers also provide high availability, reliability and scalability by offering load balancing, fault-tolerance, clustering and administration. A typical application server provides access to infrastructure services, such as messaging, naming, directory,

A Java Container Framework for Server Component Models

01/03/00

3 transactions, persistence and security. An application server can potentially host multiple containers. The application server might not be confined to a single address space, process, virtual or physical machine. Component Components are pre-developed pieces of application code that can be assembled into working application systems. Usually, components are offered in two flavors: extensible and non-extensible. The behavior of extensible components can be extended by inheritance. By changing their properties (also called description or meta-data), nonextensible components are configured. Container Container provides execution environment for a component or a set of components of a component model. Containers inherit their environment from application server. While application servers can be considered containers hosting applications, a container provides a tailored execution environment specific to the component model it hosts. There may be more than one container, each hosting a different component model in an application server. Component Model A component model defines the basic architecture of a component, specifying the structure of its interfaces and the mechanisms by which it interacts with its container and with other components. The component model provides guidelines to create and implement components that can work together to form a larger application.

Application Server

Components

Containers Figure 1. Relationship between Application Server, Container and Component

A Java Container Framework for Server Component Models

01/03/00

4 This first section gives introduction to enterprise application architecture, a brief about its evolution and reasons behind emergence of server component models. It describes the purpose of designing a Java container framework and gives reasons behind its name. It also defines some important terms used throughout the paper. In section two a brief introduction of component models in discussion is given. It gives a summary of behavior of components, functionality offered by container and packaging and deployment information in each component model. In the third section we derive functional requirements for a generic container. These requirements do not necessarily satisfy one component model but might be a common set for all containers considered. Then we will try to define architecture by providing abstractions satisfying the requirements. Lastly, we will put these abstractions together in the form of Java Container Framework. In the end, we list advantages and disadvantages of the approach and give conclusion.

2 Component models
This section describes in brief component models considered while defining the architecture of Java Container Framework. It includes Java 2 Enterprise Edition (J2EE) Server component models [1], BEA's CORBA component model in WebLogic Enterprise Server (WLE) [8] and OMG's CORBA Component Model (CCM) [7]. Please refer to relevant specification for more details.

2.1 J2EE Component Models

J2EE defines numerous client and server side component models. Two server component models of J2EE are of interest here: Enterprise JavaBeans and Web Components (Servlets and JavaServer Pages).

2.1.1 Enterprise Java Beans (EJB)

Enterprise JavaBeans [2] are server side components that implement business logic operating on enterprise's data. There are two types of beans: Session and Entity. Session beans are created for a client on the server. These beans exist for duration of the session between client and server. Session bean can manage its own transactions or can rely on EJB Container for its transaction management. Session beans don't survive server crashes and are not shared.

A Java Container Framework for Server Component Models

01/03/00

5 Session beans are of two types: stateless and stateful. Stateless session beans are like services. These beans do not keep any state for the client. Stateful session beans keep conversational state for the client. EJB Container manages state for such beans. Entity beans are identified with primary key. Entity bean survives server crashes and exists as long as data exists. It is a shared object. Such a bean can manage its own state or can rely on EJB Container to manage its state in database. EJB Container always manages entity bean's transactions. EJB Container manages transaction, security, lifecycle and state of enterprise beans. It also provides programmatic access of transaction service, naming service, security environment and database connections through well-defined contracts. The container ensures serialization of requests for the beans. EJB Deployment Descriptor (in XML) contains declarative information about various classes of the bean, expected transaction, state and security management as well as environment needed to run the bean. It is a contract between various well-defined roles in EJB Component model to convey the requirements of the beans. Enterprise JavaBeans are packaged in ejb-jar file. The ejb-jar file includes enterprise bean classes, their remote and home interfaces and Deployment Descriptor.

2.1.2 Web Components

Web Components comprise of Java Servlets [4] and JavaServer Pages [5]. A Java Servlet generates dynamic content. Java Servlets are used to extend and enhance functionality of Web servers and to access business systems. Servlets are small, platform independent Java classes compiled to an architecture neutral byte code that can be loaded dynamically into and run by a web server. Servlets interact with web clients via a request response paradigm implemented by the servlet container. Servlet Container in conjunction with a web server or application server, provides the network services over which requests and responses are set, decodes MIME based requests, and formats MIME based responses. It also contains and manages servlets through their lifecycle. A Servlet Container may place security restrictions on the environment that a servlet executes in. The security enforcement might be based on declarative information or by providing programmatic access. The container also provides programmatic access of transaction, naming and database connectivity services to servlets.

A Java Container Framework for Server Component Models

01/03/00

6 Servlet Deployment Descriptor (in XML) is a contract between different well-defined roles in Web component model. It conveys the elements and configuration information of a web application. Servlets are packaged inside a WebARchieve (WAR) file along with other classes, JavaServer Pages, HTML documents, image files and other resources required to create a web application. A JavaServer Page (JSP) separates the user interface from content generation enabling web designers to change the overall page layout without altering the underlying dynamic content. A JSP page is a text-based document that describes how to process a request to create a response. The description inter-mixes template data with some dynamic actions and leverages on the Java Platform. A JSP is executed in a JSP container, which is installed on a Web server, or on a Web enabled application server. The JSP container delivers requests from a client to a JSP page and responses from the JSP page to the client. The semantic model underlying JSP pages is that of a servlet: a JSP page describes how to create a response object from a request object for a given protocol, possibly creating and/or using in the process some other objects. A JSP is packaged into a WAR file. It can be packaged in a source form or compiled into a Servlet, which is then packaged into a WAR with a deployment descriptor such that it looks as the original JSP to any client.

2.2 BEA's WLE CORBA Component Model

BEA WebLogic Enterprise Server (WLE, previously M3) defines a proprietary server component model for CORBA objects, called WLE CORBA Component Model. There are three types of CORBA components in WLE CORBA Component model: method-bound, transaction-bound and process-bound. The semantics of these components are defined based on their activation policy. Method-bound components are activated at method invocation on the component and deactivated at the end of method invocation. Transaction-bound components are activated when an operation is invoked on them. If the component is activated within the scope of a transaction, it remains active until the transaction is either committed or rolled back. If it is activated outside the scope of a transaction, its behavior is the same as that of a method-bound component. Process-bound components remain active in WLE CORBA Container till the process exists or the container is programmatically asked to deactivate them.

A Java Container Framework for Server Component Models

01/03/00

7 WLE CORBA Container (a.k.a. TP Framework) is built on an ORB and uses Portable Object Adapter (POA). It manages transaction and activation of WLE CORBA components. It also provides programmatic access to CORBA transaction, notification and security service to components in addition to access to factory finder and database connectivity services. The WLE container does not manage state for components. WLE Server Descriptor (in XML) contains meta-data of CORBA components including implementation classes and policies for transaction and activation. Java CORBA components are packaged in a JavaARchive (JAR) file.

2.3 OMG's CORBA Component Model (CCM)

OMG's CORBA Component Model is derived from Enterprise JavaBeans and BEA's WLE CORBA Component model. It categorizes components in four categories: stateless, conversational, process bound durable and process independent durable. Stateless components have behavior but no state and no identity. Session components have behavior, conversational state and non-persistent identity. Process components have behavior (optionally transactional), persistent state not visible to clients and persistent identity provided through user defined operations. Entity components have behavior (optionally transactional), persistent state visible to clients through persistent identity. The CORBA container is a server-side framework built on the ORB, the POA, and a set of CORBA services, which provides the runtime environment for a CORBA component. There are four containers each serving a component category described above. In addition to these, there are two containers serving Session and Entity EJBs and an empty container, which exposes all CORBA functions to component developer. Each container uses different POA (with unique set of POA policies) for different component categories. POA is used as component reference factory and to manage activation of component instances. Container provides access to transaction, security and naming services and optionally to persistence (and state) and notification services. The CCM Container concept is different than that in other component models in the sense that there is a container for a component category of a component model. In the context of JCF we will stick to a container per component model concept. In CCM, a software package consists of one or more descriptors and a set of files. The descriptor and associated files are grouped together in a ZIP archive file. The Software Package Descriptor (in XML) describes the characteristics of the package and points to

A Java Container Framework for Server Component Models

01/03/00

8 its various files. The CORBA Component Descriptor is one of the elements of Software Package descriptor. The component descriptor describes the structure of a component with respect to supported interfaces, inherited components, and uses and provides ports. A component package may be deployed alone, as is, or it may be included in a component assembly package and deployed as part of the assembly along with the other components of the assembly.

3 The Container Framework

Now, we need to figure out abstractions required to build a container framework. First, we will discuss what common functionality the containers of these component models are required to provide. Then, we will try to define the architecture by describing abstractions and in the end we will put these abstractions together working in collaboration to form a framework. Such a framework will offer all common container abstractions, that means, it will provide an abstract generic container. Containers for each component model can then be derived from this generic container and specialized as per need.

3.1 Functional Requirements for a Generic Container

3.1.1 Lifecycle Management
Container manages lifecycle of the components it hosts. This includes creation, removal, activation and passivation. Based on component's behavior, creation and removal is either controlled by application clients or the container can create and remove components as needed or both. In some component models, the container can passivate active components on certain events and activate them when needed subsequently. Rules for life cycle management of components are clearly defined in component models.

3.1.2 Transaction Management

Some component models define declarative transaction management for components. That means, the container manages transactions for the components. The container begins, suspends or resumes transactions at appropriate places in control flow and takes necessary actions (commit or rollback) for completing transaction. Alternatively, the components can manage transactions in some component models. The container then makes necessary interfaces available to the component.

A Java Container Framework for Server Component Models

01/03/00

3.1.3 State Management

Components can be stateless or can have conversational or durable state. Component models define contracts between components and container for state management. Component can either manage its own state or can rely on the container for the service.

3.1.4 Security
The container provides security environment to components. This may be in the form of users, groups or other security information. A component can rely on the container to do authorization for client requests or can do this on its own programmatically by using interfaces provided by the container. Containers may also provide secure environment for components by enforcing Java security protection domains.

3.1.5 Deployment
Component architectures require component level installment for applications. This is usually termed as component deployment. Components can be deployed in two ways: statically at application server startup or dynamically during runtime. In addition to providing a deployment framework, container should enforce component isolation and handle requests to different active versions of the components appropriately.

3.1.6 Administration and Management

While application servers provide administration and manageability at process level, containers provide the same at component level. Container implements management interfaces so that administration of components becomes easy. These interfaces may include methods to deploy/undeploy/redeploy components, tuning caches, resizing resource pools etc. Also included are methods to extract statistical information about activities on components, number of active components, elements involved in transactions and other manageable resources. This kind of information helps administrators make judicious decisions for managing and administering applications.

3.1.7 Infrastructure Services

A container provides a federated view of the underlying infrastructure services to the components. The container makes it possible for components to access some infrastructure services by well-defined interfaces. These services might be transaction, security, naming, database connectivity, messaging/event and other such useful services.

A Java Container Framework for Server Component Models

01/03/00

10

3.2 Architecture
In this section, we will discuss about the architecture of the Java Container Framework. Based on the requirements in section 3.1, we will define abstractions for elements of the container framework and describe their behavior.

3.2.1 Protocol Adapter

Different component models use different protocols. CORBA components use IIOP while EJB use RMI, RMI over IIOP or its variations while JSP/Servlets receive HTTP/HTTPS request. If the application server supports multiple protocols and containers hosted in it use different protocols, adapter design pattern can be used to provide isolation at messaging layer. Each container can plug in its own adapter into the messaging layer. This approach provides isolation and extensibility. Adapter receives remote requests from messaging layer underneath and delegates them as component requests to component activation framework. Usually, a component model uses only one kind of a protocol in implementation so there is only one such adapter per container.

3.2.2 Component Activation Framework

Component Activation Framework is the core of the Java Container Framework. Its main task is to manage lifecycle and activation of components. It also uses infrastructure services and collaborates with other parts of JCF. 3.2.2.1 Component meta-data

Component models define meta-data for components. This is usually defined in a class called descriptor. Descriptor defines a contract between a component provider and deployer. It contains information about remote and other necessary interfaces and implementation classes of the component, names with which components are advertised to the outside world, information about execution environment expected from the container including activation, state, transaction and security policies to be enforced etc. It is also a good place to provide details about 3rd party tool (e.g. for state management) integration to the container. Based on the component, meta-data can be divided into the following classes:
3.2.2.1.1 Component Descriptor

This class contains meta-data of the component applicable at component scope. For example, it can contain information about state management and activation semantics expected by the component from the container. Component descriptors can but may not

A Java Container Framework for Server Component Models

01/03/00

11 necessarily be deployment descriptors. Component descriptors are tuned to provide meta-data at runtime. Component descriptors can contain one or more method descriptors.
3.2.2.1.2 Method Descriptor

This class contains meta-data applicable at (remote) method scope of the component. For an example, it may contain information about security and transaction management expected from the container when certain method on certain remote interface of the component is invoked. 3.2.2.2 Component Registry

Component registry is a place where all the deployed components are registered in the container. Registry entry maps a unique component key (e.g. a fully qualified remote interface) with its descriptor. Registry keeps meta-data for all the deployed components in the container. Registry can be local to a container or can be shared by all containers. It can be local to a process or can be shared by multiple processes. When a request for a component arrives in a container, the registry is accessed to retrieve target component's descriptor. 3.2.2.3 Component Request

A component request embodies invocation context. In addition to including meta-data of the invoked method, invocation context also includes identity of target component and contexts for transaction and security. The request can also contain target component's descriptor. These request objects are created in protocol adapter. 3.2.2.4 Component Factory

Some component models define Component Factory (Home) interfaces for the components. These factories are used to create and find components. Factories are either implemented by containers or are code generated by deployment tools. Container uses factory to manage lifecycle of components. 3.2.2.5 Component Handler

A component model offers one or more types or categories of components. These components may display different behavior in terms of lifecycle, activation, transaction, state and security management. A component handler implements container's contract towards satisfying component's behavior. Usually, it is a good idea to define behavior of component handler based on the activation semantics of the component. Handler takes a

A Java Container Framework for Server Component Models

01/03/00

12 component request as input and invokes it on the target component instance. In doing so, it controls activation, passivation and optionally state and transaction management and performs authorization with the help of information in component descriptor. It can also take necessary precautions to fulfill the component's serialization requirements. To accomplish these functions, component handlers access necessary infrastructure services through runtime, obtain resources from pools and collaborate with other elements of the container framework. In addition, component handlers provide hooks at various welldefined points (e.g. before, after method invocation) in controlled flow of the request where interceptors can be invoked. 3.2.2.6 Interceptor

In cases when components rely on their container to manage transaction and authorization, the container has to intercept requests on components to demarcate transactions and perform security checks. Method level interceptor design pattern appropriately fits to the requirements here. Component handlers invoke interceptors for a request being processed based on pre-defined conditions in component descriptor. Apart from this, interceptors can also be used for integration of container with any 3rd party tool used for state management. Good thing about interceptor pattern is that it provides decoupling and introduces a HotSpot [9] in the framework.

3.2.3 State Management Adapter

Components can be stateless or stateful. State of the component can be conversational or durable (persistent). Component state may be managed by component itself, by the container or by any 3rd party tool (OR mapping, ODBMS). These various possibilities necessitate an adaptable approach towards state management in design of the container. With adapter design pattern different state management tools can be easily plugged in the container. In addition, the type of tool used to manage a component's state should not affect activation framework's control flow. Adapter pattern also provides necessary decoupling.

3.2.4 Security Interface

This is an interface used by container framework to access security environment in order to enforce authorization for components and resources used. It provides a single point of access to security environment. The information provided through the interface may include principals, environment specific roles, security policy domains (realms), and other security policies. Usage of such an interface decouples container framework from security environment and provides portability to some extent.

A Java Container Framework for Server Component Models

01/03/00

13

3.2.5 Cache
Containers can cache active components to improve response time and optimize resource utilization. Eviction of components might be done at method end, transaction end, process end, or when resources become scarce. Eviction or passivation policies are either governed by behavior of components (by declarative activation policies) or are enforced by an implementation of the container. Cache can be part of component activation framework or state management adapter.

3.2.6 Runtime
Every container has a runtime class. Runtime provides an interface to the container with infrastructure services like transaction, naming, database connectivity and security. Runtime is accessible everywhere in the container and usually works as a single point of access to obtain interfaces of infrastructure services and other elements of container. It can also be registered with the application server as a single point of access for container. When the container is instantiated, the runtime is created first. Runtime is a singleton in a container.

3.2.7 Resource Pools

Components may use different kinds of resources. These resources can be pooled to improve performance if their acquisition and release are expensive operations. The resource can be anything from a chunk in memory to database, network connections etc. It is good to have an abstraction for generic resizable resource pool in the container with adaptable resizing mechanisms.

3.2.8 Deployment
Deployment is a process of installing application components into application server. 3.2.8.1 Deployer

Deployer is an interface between management interface of a container and the container runtime environment. The task of this element is to deploy components from a package. The deployment process includes parsing deployment descriptor, loading required classes, creating and initializing necessary objects, setting environment for the component in container, registering component to component registry and advertising its existence to outside world by registering it to the naming service. Deployer can also make sure that components are isolated in terms of versions and security. Deployer similarly provides functions to undeploy or redeploy components.

A Java Container Framework for Server Component Models

01/03/00

14

3.2.9 Administration & Management Interfaces

A container implements management interfaces to enable its administration from console. These are exported to administration console directly or through application server. These interfaces might potentially include methods to deploy, undeploy and redeploy components, measuring activities on components deployed and gathering statistical runtime information. Thus, management interface is a contract between container and administration framework of the application server.

3.3 Putting all pieces together - The Java Container Framework

Infrastructure Services Component Handlers Runtime State Mgt. Adapters Admin. & Mgt. Interface Deployer

Component Registry Protocol Adapter Messaging Layer

Figure 2. Elements of Java Container Framework

A Java Container Framework for Server Component Models

01/03/00

15

4 Advantages and Disadvantages

4.1 Advantages
1. Adding new containers becomes fast, easy and cheap. A lot of design and code can be reused. 2. Maintenance is reduced as all containers in an application server share common container functionality.

Figure 3. Two container instances 3. Forms a solid base for the product. Efforts put behind well-designed framework in balance with the reality of software development always pays-off.

4.2 Disadvantages
1. If the abstractions of the framework are not designed properly (keeping future in sight), duplication of effort, code and behavior is inevitable. This weakens the whole purpose of designing a white-box framework. 2. Complexity increases as more derivatives are added.

A Java Container Framework for Server Component Models

01/03/00

16 3. Framework implementation is expensive in terms of time and labor. Initial work on designing infrastructure of the framework does not produce end product as expected by management. Special skills are required for white-box framework development and maintenance.

5 Conclusion
All server side component model specifications define behavior of components, rules to implement components, responsibility of different roles, packaging requirements and contracts between component and its container [ref 1.3 Component Model]. It is left to vendors to decide on the design of container. On one hand it is good not to include this in specification as it gives vendors liberty to implement a container in the most suitable way available. On the other hand it introduces a great deal of confusion on vendors' part by introducing duplication of efforts, design and code for different containers in the same product. For example, evolving J2EE platform specification [ref 1] describes in brief about different containers and their functionality, but it does not define any framework to implement these even though J2EE containers share a lot of functionality. This is not helpful to J2EE product providers. The same argument applies to CCM specification. In this paper, we have deliberately avoided defining APIs and concentrated only on the abstractions of container framework. We believe standard bodies like JavaSoft should formalize a Java Container Framework API in J2EE. OMG should do the same for CORBA Components.

6 Acknowledgements 7 References
1. Java 2 Platform Enterprise Edition, v 1.2, Public Release 2 (http://java.sun.com/j2ee). 2. Enterprise JavaBeans Specification, v 1.1 Public Release 2 (http://java.sun.com/products/ejb/newspec.html) 3. Enterprise JavaBeans Technology, Server Component Model for Java Platform, by Ann Thomas (http://java.sun.com/products/ejb/white_paper.html) for Sun Microsystems, Inc. 4. Java Servlet Specification, v2.2 Public Release 2 (http://jsp.java.sun.com/products/servlet) 5. JavaServer Pages Specification v1.1 Public Release 2 (http://jsp.java.sun.com/products/jsp) A Java Container Framework for Server Component Models 01/03/00

17 6. Design Patterns: Elements of Reusable Object-Oriented Software, by Gamma et. al., Addison-Wesley Pub Co. 7. CORBA Components, Volume 1, Object Management Group, (http://www.omg.org/cgi-bin/doc?orbos/99-07-01) 8. Making Component-based Systems Scale with BEA WebLogic Enterprise, BEA Systems Inc. (http://www.beasys.com/products/weblogic/enterprise/paper_components.html) 9. Evolving Frameworks, A Pattern Language for Developing Object-Oriented Frameworks, by Roberts D., Johnson R., University of Illinois (http://stwww.cs.uiuc.edu/~droberts/evolve.html).

A Java Container Framework for Server Component Models

01/03/00