 | Level: Introductory Ken Nordby (nordby@us.ibm.com), Software Engineer, IBM
28 Jul 2000 Part 3 of this article describes the deployment process for Enterprise JavaBeans components, which is more than installation because code generation is typically involved. Deployment also uses a special deployment descriptor file, which supports parameters that govern enterprise bean behavior, such as whether a bean requires transactions. This feature of bean deployment supports the EJB goal of declarative, as well as programmatic, specification of bean behavior. Part 3 also contrasts the two primary types of persistence, bean-managed and container-managed, and discusses the relationship of EJB components to CORBA. A simple three-tier EJB application is also presented.
The deployment process
Enterprise JavaBeans (EJB) components are installed in a special process called deployment. Support for the deployment process is provided by the container component. At a high level, deployment consists of the following steps:
- The bean developer creates required class files, interface files, and control information.
- The container analyzes input files and generates necessary classes.
- The container adds an entry to the JNDI namespace pointing to the home object.
The developer of an EJB component composes the Java source file for the bean, which contains the business logic methods that give the bean its functionality plus an ejbCreate() method. The bean class must also implement the javax.ejb.SessionBean interface or the javax.ejb.EntityBean interface. The bean developer additionally writes interface files that define extensions to the javax.ejb.EJBHome interface and the javax.ejb.EJBObject interface. The extension of the EJBHome interface, referred to as the bean's home interface, contains a create method, and if the bean is an entity bean, it also contains a finder method. The extension of the EJBObject interface, referred to as the bean's remote interface, specifies the business logic methods that are defined in the bean itself. The bean developer provides control information consisting of a deployment descriptor, environment properties, and a manifest file.
- A deployment descriptor is a serialized instance of a
javax.ejb.deployment.SessionDescriptor object or a javax.ejb.deployment.EntityDescriptor object.
- Environment properties are stored as key-value pairs in a file accessible through a
java.util.Properties object.
- A manifest file is required to identify the enterprise bean and its related files.
The class file for the enterprise bean, the class files for the two interfaces, the deployment descriptor file, the environment properties file, and a manifest file are archived using a file format named ejb-jar. The resultant ejb-jar file is provided to the container as input for the deployment process.
At deployment time the container analyzes the contents of the ejb-jar file and takes actions necessary to render the bean usable. These include generating new Java classes that implement the bean's home and remote interfaces, binding the home interface implementation into the JNDI namespace, and generating stub and skeleton helper classes required to support RMI communications. The container can also generate a subclass of the bean that incorporates container-specific code to facilitate managing the bean. Classes generated by the container at deployment time typically are container-specific, unlike the EJB component itself, which is portable.
Persistence, transactions, and security
The EJB container can play a major role in providing persistence, transactions, and security services for EJB component. The EJB specification allows bean developers flexibility in assigning responsibility for these services to the container or assuming responsibility within the bean itself. For example, persistence support for entity beans can be managed by the bean or by the container. If EJB component developers elect to use container-managed persistence, they add a property to the deployment descriptor called containerManagedFields. According to the EJB specification: "The value of the containerManagedFields property is a list of instance fields that the enterprise bean provider expects the container to manage by loading and storing from a database. The enterprise bean code should not contain any database access calls -- the database access calls will be generated by the container tools at deployment time.
"The containers that specialize in providing support for container-managed persistence will typically provide rich deployment-time tools to allow the enterprise bean deployer to establish the mapping of the instance fields to the underlying data source. It is expected that although the mapping process is made easy by the container provider's tools, the bean deployer may be involved in the mapping process (i.e., the mapping process is not fully automatic)." (Enterprise JavaBeans Specification 1.0) In addition to container-managed persistence, the EJB architecture also supports management of transactions by the container. The specification states: "Enterprise JavaBeans is a high-level component framework that attempts to hide system complexity from the application developer. Therefore, most enterprise beans and their clients do not need to access transaction management programmatically." (Enterprise JavaBeans Specification 1.0) When a bean developer relies on the container for transaction management, which is referred to as container-managed demarcation, the container uses the transaction attribute provided at deployment time:
"Whenever a client invokes an enterprise bean, the container interposes on the method invocation. The interposition allows the container to control transaction demarcation declaratively through the transaction attribute. For example, if an enterprise bean is deployed with the TX_REQUIRED transaction attribute, the container automatically initiates a transaction whenever a client invokes a transaction-enabled enterprise bean while the client is not associated with a transaction context." (Enterprise JavaBeans Specification 1.0) If bean developers choose to support transactions within the bean, they specify the TX_BEAN_MANAGED transaction attribute in the deployment descriptor, and are then free to use the javax.transaction.UserTransaction interface to demarcate transaction boundaries in the bean itself. By recognizing the TX_BEAN_MANAGED transaction attribute, the container understands that it is not expected to interpose transaction support. Containers provide security support for EJB components by enforcing constraints specified in AccessControlEntry objects and RunAs security identities. AccessControlEntry objects associate Identity objects with enterprise beans, either at the bean level or for individual methods. The Identity objects reflect users or roles permitted to invoke the bean's methods. Containers also apply a RunAs security identity to EJB components when they attempt to access a data resource or another bean. The RunAs identity can be set equal to a specific user account, a privileged system account, or the security identity of the client. Access control and RunAs information is specified by the bean developer in the deployment descriptor, and influences how the container manages the bean's behavior with respect to security. Although the 1.0 EJB specification addresses security issues, subsequent versions of the specification will define security functionality in greater detail.
Relationship between CORBA and EJB technology
The Common Object Request Broker Architecture (CORBA) lays the groundwork for a platform-neutral and language-neutral computing environment for distributed objects. In a CORBA environment, functionality resides in objects that are accessible to clients through Object Request Brokers (ORBs). Full CORBA implementations provide ORBs plus several run-time services referred to as CORBA Object Services and CORBA Common Facilities. ORBs can be provided without the associated Object Services and Common Facilities. (For example, IBM provides two such stand-alone ORBs.) Software that implements base ORB functionality is referred to as an ORB core. To support language independence, CORBA applications are coded in Interface Definition Language (IDL). This language is syntactically similar to C++ but contains no semantics: operations specified in IDL are operation interfaces, not operation implementations. Because of its support for multiple platforms and languages and the scalability which derives from its distributed character, CORBA is well-suited for hosting enterprise-scale information systems.
The EJB specification is also designed to support enterprise information systems. Is CORBA therefore a competitor? According to the Frequently Asked Questions for Enterprise JavaBeans, the answer is no:
"In fact, EJB technology complements CORBA quite nicely. CORBA provides a great standards-based infrastructure on which to build EJB servers. EJB technology makes it easier to build applications on top of a CORBA infrastructure." (Enterprise JavaBeans Frequently Asked Questions) Although the EJB and CORBA specifications describe independent technologies, EJB implementations currently utilize some aspects of CORBA technology. One example is RMI/IIOP. The EJB specification requires EJB components and their containers to use Remote Method Invocation (RMI) technology to implement method invocation between distributed objects. RMI specifies syntax and semantics for remote methods, but does not specify what transport protocol should be used to provide network connectivity. The CORBA Internet Inter-ORB Protocol (IIOP) basically defines a way to transmit CORBA messages over TCP/IP. Developing an EJB implementation that exchanges RMI data in the form of IIOP messages illustrates how EJB applications can effectively use parts of CORBA technology. Such a network also supports interoperability with CORBA applications that use IIOP to send native CORBA messages independently of RMI. The IBM EJB implementation, WebSphere Application Server, optimizes use of IIOP by recognizing when distributed objects reside on the same server and only invoking IIOP when objects are truly remote. To facilitate development of enterprise systems incorporating both EJB and CORBA technology, Sun Microsystems created a mapping between the EJB specification and CORBA. Mapping the EJB architecture to CORBA affects several aspects of EJB technology, including object distribution, naming, and transactions. The primary purpose of CORBA mapping is to ensure interoperability between EJB servers built by different vendors. Interoperability provides the following benefits:
- CORBA clients can access EJB components deployed in CORBA-based EJB servers
- Client programs can mix calls to CORBA objects with calls to enterprise beans in transactions
- Transactions can span multiple beans located on multiple CORBA-based EJB servers from different vendors
- A client using an ORB from one vendor can access beans on a CORBA-based EJB server from a different vendor
For CORBA clients to access EJB components, bean interfaces are mapped to IDL. For example, buy() and sell() methods defined in a stock-trading bean can be specified as CORBA operations in an IDL file. A non-bean CORBA client, such as a C++ client, can access this bean and invoke its methods using standard CORBA calls. The generation of IDL corresponding to an enterprise bean and its interfaces is the responsibility of the EJB container if the container uses IIOP as its distributed object protocol. The EJB naming service, which is based on the CORBA Object Services naming service, makes EJB components available to CORBA clients. The Java Naming and Directory Interface (JNDI) can provide an interface to the CORBA naming service, and clients can access the underlying naming service indirectly through JNDI calls or directly through the CORBA Object Services (COS) naming API. EJB transaction support depends on the CORBA transaction service, Object Transaction Service (OTS). The Java Transaction Service (JTS) represents the Java binding of OTS, which is language-neutral. CORBA-based EJB containers must recognize transaction boundaries issued by CORBA clients through the OTS interface as well as transactions issued by EJB applications through the Java Transaction API (JTA) interface, which is the application-level interface to JTS. JTA also represents the Java binding of The Open Group XA interface for attaching an application resource to an external transaction manager. The javax.transaction.UserTransaction interface, included in JTA, provides the API for application-level control of transaction boundaries. The UserTransaction interface can be used by beans with the transaction attribute set to TX_BEAN_MANAGED and by Java clients.
Using EJB components
Because the EJB architecture was designed to be highly flexible, enabling enterprise beans to be connected in arbitrarily complex ways, many different scenarios can be constructed to illustrate how applications can use enterprise beans. One useful scenario presents EJB components as key components in three-tier information systems that connect enterprise data, transactions, and application resources to the Web. An EJB-based three-tier programming model views a Web browser as the first tier, an application-enabled Web server as the second tier, and enterprise information resources as the third tier. In addition to EJB technology, Java servlet technology, JavaBeans technology, and Java Server Pages (JSP) technology are also implemented in this programming model. The following illustration shows the arrangement of tiers:
The first tier is a thin client capable of rendering common Web data types such as HTML and GIF and supporting HTTP communications -- typically a Web browser. The second tier is a Web application server, which is a Web server augmented with code, to provide run-time support for applications that can be invoked through the Web server. Existing Web applications historically use the CGI-BIN programming model, but tier-two application development is anticipated to migrate to the Java servlet programming model, which offers much improved performance and portability. In addition to supporting Java servlets, Web application servers will add EJB server functionality in order to support applications that use EJB components. The third tier represents enterprise-class information resources, which can include relational and object-oriented databases, transaction monitors, and custom applications. EJB technology plays a critical role in this design because it standardizes the interface between application components residing on tier two and the enterprise resources that make up tier three. Java servlets, beans, and server pages are not required elements of EJB application scenarios, but can work together with EJB components to provide a cohesive Java-based application environment. The environment pictured here assigns the following responsibilities to the participating Java components:
- Java servlets are assigned the role of application "controller"
- JSP pages handle presentation of data and user interface tasks
- Java beans play the role of "data encapsulator," storing intermediate results data
- EJB components provide the mechanism for accessing enterprise information resources
Customers might use a hypothetical EJB-based Web application to update stock on hand, where access to the inventory database is wrapped within an entity EJB component with container-managed persistence and container-managed transactions. Stock receipts can be entered through a Web browser, which presents an HTML form to capture part number, supplier, and so on, and invokes a servlet when submitted. The servlet code, acting in the role of application controller, determines which enterprise databases need to be updated and what additional information is required from the user. The servlet can access the main inventory database through the entity bean that represents it, invoking the JNDI interface to obtain a reference to the bean's home object and then using a finder method to locate the remote object for the requested part number. At this point the servlet can update the stock count by invoking a method on the remote object, which the container in turn delegates to the EJB component. Data integrity is preserved because the container demarcates a transaction around the database update, transparently to the bean, as well as ensuring data persistence by writing the data to the database transparently to the bean. Any result information returned from the EJB component to the servlet can be stored in properties of a (non-enterprise) Java bean using setter methods. At this point the servlet can transfer control to an appropriate JSP page to assemble the results into presentation format and route results back to the user. The JSP page would likely consist mostly of static text with placeholders for variable information pertaining to individual transactions. Before sending presentation data to the browser, the JSP page obtains the variable data elements from the properties of the Java bean using getter methods. A three-tier design based on EJBs confers several benefits, including:
- Business logic accessing enterprise data can be encapsulated in reusable, portable enterprise beans.
- Existing enterprise systems can be integrated as enterprise beans with little or no modification.
- Run-time services required for enterprise applications, such as transactions and persistence, can be factored out of beans and assigned to the bean container.
- Servlets that control application flow can be modified without requiring change to EJB components.
- Servlet code can focus on application control logic without regard to presentation of data.
- JSP pages can generate presentation information mixing static and dynamic content.
- System components written in the Java language are portable to any platform with a JVM.
Conclusion
The EJB specification represents the next step in the progression of Java technology in development of application platforms capable of supporting mission-critical, enterprise-class information systems. EJB components extend the Java component model introduced with the JavaBeans specification into the server domain, enabling development of business logic components reusable across enterprise applications and portable across Java-enabled platforms. Inclusion of object distribution based on RMI technology supports separation of executable components across multiple tiers, which permits maximum implementation flexibility and high scalability. Redefining conventional enterprise application run-time services as object services assignable to the container abstraction allows EJB component developers to concentrate on business logic, and reduces complications and platform dependencies often associated with run-time services. Enhancement of the Java run-time environment to include standard interfaces for naming and directory services, relational database access, transaction services, and remote object access makes it possible for Java developers to write robust enterprise applications without leaving the Java programming environment. Using other Java technologies in conjunction with EJB components -- such as Java servlets and JavaServer Pages technology -- creates a coherent programming model robust enough for large enterprise systems, but with clean functional interfaces that simplify development effort. And, since the EJB architecture is a logical extension of the JavaBeans component model, business logic developed as EJB components can be reused across multiple enterprise applications.
Another benefit of the enterprise bean architecture is the straightforward integration path for existing enterprise information systems, which may have nothing in common with the Java programming language or the bean programming model. Customers can protect their existing IT investment because existing enterprise information resources -- such as relational databases, transaction monitors, and custom line of business applications -- can be attached to Web front ends by wrapping them in EJB components, eliminating the need to replace applications or rewrite major pieces of code. Considering the great promise of EJB technology, it is not surprising that the IT industry has greeted the EJB specification with considerable interest. The single greatest value provided by the EJB architecture may be the separation of business logic programming from the challenge of integrating business logic with the complexities of enterprise-class server-side run-time environments. If the containers in which EJB components are deployed assume responsibility for managing run-time services such as persistence, transactions, and concurrent database access, bean developers are free to focus on developing software components that encapsulate business logic. The importance of this was expressed by the vice president of JavaSoft (quoted on the Sun Microsystems Web site):
"'The Enterprise JavaBeans API will give enterprise developers and solution providers a new strategic weapon to build their next generation industrial strength, mission-critical business applications,' said Jon Kannegaard, vice president of software products for JavaSoft, a business unit of Sun Microsystems. 'Because applications designed with the Enterprise JavaBeans API will work with existing enterprise systems, businesses gain a new competitive advantage with the Java platform, while preserving their investments in existing technology,' continued Kannegaard.
"Using the Enterprise JavaBeans API, developers will be able to remove the complexity from the application development process. This is possible because each Enterprise JavaBeans component encapsulates an essential business function. Currently developers have to know how to write both business logic and specialzed system-level programs that control features such as security and the ability to handle multiple transactions -- a tedious and complex task. The Enterprise JavaBeans API lets corporate developers concentrate on writing the logic to solve business problems, rather than writing code to facilitate the interaction of diverse technologies." (Press release: Sun Releases Draft Enterprise JavaBeans Specification for Public Review)
Resources
About the author | | | Ken Nordby is a software engineer in the IBM software development lab at Research Triangle Park, North Carolina. As a member of the SWG Product Affinity Services operations team, Ken worked with IBMers who develop and consult for the IBM WebSphere Application Server, IBM's implementation of Enterprise JavaBeans. Ken can be reached at nordby@us.ibm.com. |
Rate this page
| |
