 | Level: Introductory Ken Nordby (nordby@us.ibm.com), Software Engineer, IBM
22 Jun 2000 This report provides an overview of Enterprise JavaBeans (EJB) technology, enabling readers to gain a quick understanding of essential concepts. Part 1 looks at the history of EJB technology and some of the goals, advantages, and technologies. In the interest of brevity and clarity, this report presents selected key elements of EJB technology. Note that while EJB components rely on several underlying Java services, such as the Java Transaction Service, knowledge of these related technologies is not necessary to use EJB components and realize their benefits.
Enterprise JavaBeans technology has received much acclaim since its introduction in March 1998. The following statement is an example:
"Since its introduction over two years ago, Enterprise JavaBeans
tm
technology has maintained unprecedented momentum among platform providers and enterprise development teams alike. That's because the EJB
tm
server-side component model simplifies development of middleware components that are transactional, scalable, and portable. Enterprise JavaBeans servers reduce the complexity of developing middleware by providing automatic support for middleware services such as transactions, security, database connectivity, and more." (Sun Microsystems Web site) The name Enterprise JavaBeans trades on the popularity of Java beans -- portable, reusable Java software components. Extending the concept of Java components from the client domain to the server domain, Enterprise JavaBeans technology represents an ambitious step forward in the growth of Java technology into a robust, scalable environment that can support mission-critical enterprise information systems. Java applications on the server
One reason the Java programming language initially gained popularity with Web developers was its support for downloadable Java programs known as applets. Applet support was built into the Java Development Kit (JDK), Version 1.0 in the form of the Applet class. In the V1.0 time frame, Java development centered around applets and applications. Books based on JDK V1.0 presented Java programming in terms of applets and applications: "A program in Java consists of one of more class definitions, each of which has been compiled into its own .class file of Java Virtual Machine object code. One of these classes must define a method called main(), which is where the program starts running. To invoke a Java program, you run the Java interpreter, java, and specify the name of the class that contains the main() method. Note that a Java applet is not an application -- it is a Java class that is loaded and run by an already running Java application such as a Web browser or applet viewer." (Flanagan, Java in a Nutshell) Java applications could be run on servers, but there was nothing in the JDK that made Java applications especially suited for use on server machines in either client-server or Web-based environments. Recognizing the potential for Java as a server language in Web environments, Sun Microsystems wrote the Java Servlet specification. In many ways analogous to applets, servlets are Java programs designed to run on Web server machines: "A servlet is a web component, managed by a container, that generates dynamic content. Servlets are small, platform-independent Java classes compiled to an architecture-neutral bytecode 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. This request-response model is based on the behavior of the Hypertext Transfer Protocol (HTTP)." (JavaSoft, "Java Servlet API Specification")
| |
The idea of running small user programs on servers under the control of a Web server is not new --Common Gateway Interface (CGI) programs, often referred to as CGI scripts, have been serving in this role for some time and have helped fuel the popularity of the Web. However, Java servlets can serve the same purpose with greater efficiency and portability, and hence are seen as the eventual replacement for CGI programs. Software that provides a run-time environment for servlets, typically referred to as a servlet engine, can be added to existing Web servers that do not natively support Java executables. With the advent of Java servlets, the way is open for application developers to create Java solutions for Web applications. However, servlets alone do not provide a sufficient model for true enterprise computing. CGI applications are often not complete applications in themselves, but represent a middle step in the overall processing of information requests received from users at Web browsers. For example, a common use of CGI applications is to access databases. When used in this role, CGI programs provide a means of connecting the user's data request to the enterprise database that can satisfy it. CGI programs often act as a kind of software intermediary, receiving requests from Web browsers, determining what computing resources must be invoked to satisfy them, and sending responses back to the browsers. Java servlets, like CGI programs, are best suited as a middle tier component connecting front-end Web requests with back-end data resources.
Three-tier architecture
Along with an evolution in Web programming, toward Java applications on the server, has come an architectural evolution away from the conventional two-tier client-server model, toward a three-tier approach. The two-tier model was innovative in its time because it off-loaded computational tasks from the main processor onto a smart client machine. An example would be a conventional LAN-based database application where database manager server software resides on a dedicated server machine and users access the database through client code on their workstations. As the client-server model has grown in use, concerns have been raised about scalability on the server, as well as code size and complexity on the client. A three-tier architecture has been proposed to alleviate perceived weaknesses in the two-tier model and to embrace the Web as a computing platform: "Many people... have concluded that traditional 2-tier, client/server architectures will not scale well because of the unpredictable number of user connections and data access and system administration issues. To address the limitations of 2-tier architectures, many development groups are moving to 3-tier architectures. This is roughly defined as a presentation layer at the client tier, a server in the middle and a database of some sort on the back end. The idea is to offload the code bloat on the client or the database server, centrally manage business logic and get more flexibility of working with the database instead of just stored procedures and triggers." (Kim, "Looking for a 3-Tier App Builder?") The three-tier model is commonly pictured with a Web browser as the client tier. Web browsers, with potential to become a true universal client, conceptually replace the “fat client” of the two-tier model. If browsers become accepted as the standard thin client for Web application architectures, what happens to the functionality that formerly resided on the fat client of the two-tier model? Rather than migrating back to the server -- for example, a database manager -- the application-specific functionality now is intended to reside on a new middle tier. The middle tier supports application server software, a form of middleware that sits between the minimal functionality of the thin client on the first tier and the rich functionality of server-side business systems on the third tier. Because the three-tier architecture has affinities to the Web processing model, the middle tier application server is often seen as a functional extension of the Web server. Existing Web applications that utilize CGI programs to convey user requests from Web browsers to non-Web based business systems and return responses to browsers are an implementation of the three-tier model. The gradual migration of these applications toward servlet technology represents an enhancement of the three-tier model.
 |
JavaBeans components
The JavaBeans specification brought the concept of component software into the world of Java programming. Components are self-contained, reusable software units, and in the case of JavaBeans components, they can be visually composed into Java programs using visual application development tools. The JavaBeans specification provides a way for Java developers to “componentize” their Java classes:
“Beans are Java classes that can be manipulated in a visual builder tool and composed together into applications. Any Java class that adheres to certain property and event interface conventions can be a Bean.” (JavaSoft, "Using the Beans Development Kit 1.0")
If software reuse is a good idea, should every Java class be made into a Java bean? Java classes lend themselves to the bean role if they meet certain criteria: “Before you develop any new software, it might be worthwhile to consider developing it in the form of a JavaBean. If the software module will provide functionality that can be visually manipulated, and can be customized to achieve some effect, it might be a good candidate for being a JavaBean. To help you determine if the software you want to develop should be a JavaBean, assuming that it should be written in Java, ask yourself the following questions, and make a decision accordingly:
Is it intended to be reusable? Or, is it likely to be reused?
Do you wish to use it with other reusable Java components?
Do you envision it being used in an IDE tool?
If the answer to all the questions above is yes, then it should be developed as a JavaBean.” (developerWorks, "JavaBeans Guidelines") The JavaBeans concept was developed to support reusable components in the Java programming environment, and is a generic design that can apply to Java programs running on client machines or server machines. Because of the emphasis on visual builder tools, and because many Java beans are graphical user interface (GUI) components, JavaBeans components might be thought of as a client-side technology. However, Java beans are not required to be visual, and they can be used in server environments. Java classes that are coded to be Java beans generally have the following characteristics:
- They use design patterns. These are coding conventions for methods and interfaces.
- They support visual software development tools. The class must expose variables (called properties), methods, and events.
- They can be customized. This includes support for default property editors or provision of unique customizer routines. Customization permits developers to change the behavior of a bean without changing the source code.
- They support introspection. This refers to disclosing properties, methods, and events to other classes, and can be accomplished with design patterns or creation of a BeanInfo class.
- They are persistent. This permits a bean to be customized in a visual builder and then saved in its customized state.
Java 2 Platform, Enterprise Edition
Sun Microsystems launched a technology initiative called Java 2 Platform, Enterprise Edition (J2EE), which aims to extend the reach of the Java platform to large-scale server environments: "On April 12, 1997, Sun announced an initiative to develop the Java Platform for the Enterprise. Using the open Java Community Process, Sun fostered the development of a collection of standard Java extensions known as the Enterprise Java APIs. These application-programming interfaces (APIs) provide vendor-independent programming interfaces for a variety of middleware implementations. The keystone of the Enterprise Java APIs is the Enterprise JavaBeans API, which defines a server-side component model and a vendor-independent programming interface for Java application servers." (Thomas, "Java 2 Platform,
Enterprise Edition: Ensuring Consistency, Portability, and Interoperability") J2EE provides the context for Enterprise JavaBeans technology. In fact, Enterprise JavaBeans technology is only one of several software technologies that Sun envisions as building blocks that will enable large enterprises to migrate mission-critical business systems to the Java environment. EJB components are defined in their own specification, but EJB technology is not a stand-alone technology. It builds on other Java technologies, specified jointly by Sun and other IT companies, which together provide content for the framework referred to as Java 2 Platform, Enterprise Edition. The following technologies are included in J2EE:
- Enterprise JavaBeans (EJB) technology
- Java Interface Definition Language (IDL)
- Java Message Service (JMS) API
- Java Naming and Directory Interface (JNDI)
- Java Remote Method Invocation (RMI) and Object Serialization
- Java Servlet API
- Java Transaction API (JTA)
- Java Transaction Service (JTS)
- JavaServer Pages (JSP) technology
- JDBC database access API
Participation in the enterprise Java framework does not mean that each technology depends on all the others. Individual specification documents indicate the dependencies of each technology. For example, release 1.0 of the Enterprise JavaBeans specification identifies a dependency on JNDI for locating components and on JTA for programmatically starting and stopping transactions.
EJB technology design goals
The first version of the EJB specification was published in draft mode in December 1997 and was released as Version 1.0 in March 1998. The authors set the following goals for the EJB architecture:
- Enterprise JavaBeans architecture will be the standard component architecture for building distributed object-oriented business applications in the Java programming language. Enterprise JavaBeans architecture will make it possible to build distributed applications by combining components developed using tools from different vendors.
- Enterprise JavaBeans architecture will make it easy to write applications: application developers will not have to understand low-level transaction and state management details, multi-threading, resource pooling, and other complex low-level APIs. However, an expert-level programmer will be allowed to gain direct access to the low-level APIs.
- Enterprise JavaBeans applications will follow the "Write Once, Run Anywhere" philosophy of the Java programming language. An EJB component can be developed once and then deployed on multiple platforms without recompilation or source code modification.
- The Enterprise JavaBeans architecture will address the development, deployment, and run-time aspects of an enterprise application's life cycle.
- The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at run time.
- The Enterprise JavaBeans architecture will be compatible with existing server platforms. Vendors will be able to extend their existing products to support Enterprise JavaBeans components.
- The Enterprise JavaBeans architecture will be compatible with other Java programming language APIs.
- The Enterprise JavaBeans architecture will provide interoperability between EJB components and non-Java programming language applications.
- The Enterprise JavaBeans architecture will be compatible with CORBA.
|
Benefits of using EJB technology
What benefits accrue to enterprises and developers from these design goals? The following list indicates some of the advantages expected to result from adopting the Enterprise JavaBeans environment:
EJB components make it simpler to write applications
. Despite the complexity of the EJB architecture, application developers are generally relieved from having to write code that accesses system services. A system component called the EJB container is charged with the task of making system services available to EJB components.
Server-side business logic can be portable
. Besides the inherent portability of the Java language, the EJB architecture provides a standardized set of application programming interfaces between the bean and the EJB container that supports it. This enables a developer to migrate a bean from one operational environment to another without rewriting its source code.
Server-side applications can be assembled from existing software components
, just as client-side applications can be assembled from existing Java beans, enabling software reuse.
EJB architecture has built-in support for typical enterprise-level system services
, including distributed objects, transactions, database, security, and global naming.
The EJB architecture is being adopted by multiple IT vendors
, with the promise that customers will be able to choose software components, such as EJB components, containers, and EJB servers, from the vendor of choice, as well as the promise of interoperability between different vendors' EJB architecture-conforming products.
Applications built with EJB components can be migrated from one server to another to support scalability
because of the strict separation of software components in the EJB model.
EJB architecture protects existing IT investments
by allowing applications to "wrap around" existing information systems and assets without requiring customers to replace existing technology. In fact, enterprises with data stored in relational databases already have an embryonic set of entity beans waiting to be accessed through EJB wrappers.
A closer look at JNDI
Enterprise JavaBeans components use the Java Naming and Directory Interface (JNDI) for access to directory services. There are two parts to JNDI: the Application Programming Interface (API) and the Service Provider Interface (SPI): "The JNDI architecture consists of the JNDI API and the JNDI SPI. The JNDI API allows Java applications to access a variety of naming and directory services. The JNDI SPI is designed to be used by arbitrary service providers including directory service providers. This enables a variety of directory and naming services to be plugged in transparently to the Java application using the JNDI API." (JavaSoft, "JNDI: Java Naming and Directory Interface") The JNDI API is not tied to a particular naming or directory technology or any vendor's directory service, and thus it contributes to the portability of EJB components. For example, customers can choose from several different technologies to deliver directory services to their EJB applications, including:
- LDAP: Sun's LDAP service provider supports versions 2 and 3 of the LDAP protocol.
- NIS: Sun offers a service provider for NIS, the Network Information Service (formerly known as Yellow Pages).
- COS Naming: Sun's service provider for COS Naming provides access to CORBA naming services.
- File System: Sun offers a service provider for accessing the file system.
- RMI Registry: Sun offers a service provider for the RMI Registry.
- Novell: service providers are available for access to the directory service NDS, as well as to the NetWare 3X Bindery, the Novell file systems, and other Novell services such as Extended NCP.
Although the JNDI specification is vendor-neutral, it should not be assumed that application servers implementing JNDI interfaces necessarily provide access to service provider code from multiple vendors. Key concepts of the JNDI naming architecture include:
- Bindings between objects and names.
- Sets of bindings called naming contexts.
- Naming systems, which are sets of naming contexts.
- Namespaces, which refer to all the names in a naming system.
- Classification of names into atomic, compound, and composite names. An atomic name is indivisible and can be bound to an object. A compound name is a combination of atomic names, and a composite name spans multiple naming systems.
A naming context is of particular importance: all naming operations are performed on context objects, and the process of name resolution always starts with an initial naming context. How does an EJB application use JNDI? The primary use of JNDI is to retrieve a reference to an EJB component. Because the EJB framework is a distributed object framework, EJB applications should not make assumptions about the location of EJB components. JNDI is a mechanism for obtaining a starting reference to a bean. When a bean is installed in an enterprise bean server, a software component referred to as the EJB container is responsible to create name-object bindings for the Java class files needed to use the bean. Applications use the JNDI lookup method to retrieve an object reference, as in the following example: Context initialContext = new InitialContext( );
CartHome cartHome = javax.rmi.PortableRemoteObject.narrow(
initialContext.lookup("applications/shopping_cart"), CartHome.class); |
The application is responsible to know the external name by which it can reference an enterprise bean, and uses JNDI to obtain a reference to it.
A closer look at JTA
In addition to JNDI, the Enterprise JavaBeans architecture uses the Java Transaction API (JTA). Support for transactions is an essential part of the EJB architecture because of the importance of transactions in maintaining data integrity and reliability. Transactions become even more important when enterprise applications are distributed: "The concept of transactions is an important programming paradigm for simplifying the construction of reliable and available applications, especially those that require concurrent access to shared data. The transaction concept was first deployed in commercial operational applications where it was used to protect data in centralized databases. More recently, the transaction concept has been extended to the broader context of distributed computation. Today it is widely accepted that transactions are the key to constructing reliable distributed applications." (Object Management Group, "Transaction Service Specification") Transactions are sometimes described as units of work with the following characteristics:
- Atomic -- if interrupted by failure, all effects are undone
- Consistent -- the effects of a transaction preserve invariant properties
- Isolated -- intermediate states are not visible to other transactions
- Durable -- effects of a completed transaction are persistent
Transactions are terminated in two ways: committing a transaction makes all its changes permanent, while rolling back a transaction undoes all its changes. The Object Management Group (OMG) created a specification for an object-oriented transaction service called Object Transaction Service (OTS). OTS is the foundation for transaction services within the EJB architecture. The following transaction specifications contribute to the transaction model adopted for enterprise beans:
- OMG Object Transaction Service (OTS)
- Sun Microsystems Java Transaction Service (JTS)
- Sun Microsystems Java Transaction API (JTA)
- The Open Group (X/Open) XA interface
The language-neutral Object Transaction Service provides basic concepts, definitions, and functionality for a robust distributed transaction service.
The Java Transaction Service is a Java mapping of OTS, defined in the packages org.omg.CosTransactions and org.omg.CosTSPortability. JTS provides support for services such as transaction demarcation and propagation of transaction context. JTS functionality is accessed by applications through the Java Transaction API.
The Java Transaction API specifies high-level interfaces between a transaction manager and other system components involved in distributed transactions, such as the application, the application server, and the resource manager. JTA functionality allows transactions to be managed by the application itself, by the application server, or by an external transaction manager. The JTA interfaces are contained in the javax.transaction and javax.transaction.xa packages. The XA interface defines the contract between a resource manager and an external transaction manager in a distributed transactional environment. External transaction managers can coordinate transactions across multiple resources. The Java mapping for XA is contained in the Java Transaction API.
What's ahead?
Part 2 of "What are Enterprise JavaBeans components?" will discuss the EJB programming model.
Resources - Learn more about Java technology and EJB architecture at the Sun Web site.
- Read about Java programming in terms of applets and applications in Java in a Nutshell by David Flanagan.
- Download a copy of the Java Servlet API Specification.
- Take the "Using the Beans Development Kit 1.0" tutorial from JavaSoft.
- Read a detailed description of J2EE in "Java 2 Platform, Enterprise Edition: Ensuring Consistency, Portability, and Interoperability", by Anne Thomas, Patricia Seybold Group.
- Find JNDI architecture and interfaces overviews, as well as scenarios and examples, in "JNDI: Java Naming and Directory Interface."
- Learn about these Java technologies that are included in the Java 2 Platform, Enterprise Edition:
- Find FAQs, LDAP-related RFCs, and more at Mark Wahl's LDAP Web site.
- Download the naming service for Java IDL, COS naming.
- Get details about the Java Remote Method Invocation (RMI), including specifications, examples, and FAQs.
- Learn about the many products and solutions offered by Novell.
- Visit the Object Management Group (OMG) Web site.
- Review the Open Group XA interface specification.
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
| |
