Home > Articles > Programming > Java

  • Print
  • + Share This
This chapter is from the book

1.2 EJBs in the enterprise

EJBs, for all their power and flexibility, are most useful in conjunction with other components of an enterprise application. The J2EE model of enterprise application development—which is described in more detail below—sees EJBs as implementing the bulk of the application's business logic and data management. In this model (Figure 1.1), EJBs occupy an architectural 'tier' between the enterprise data sources (relational databases, directory servers) and the presentation elements (clients using Java, servlets, etc). Centralizing the application's business logic in EJBs allows a variety of different clients (including clients via CORBA protocols) to make use of that logic and decouples the application from the specific representation of its data in the enterprise data sources.

The rest of this section describes in more detail some of the J2EE3 and non-J2EE technologies with which EJBs are likely to interact. These interactions are summarized in Figure 1.2. Some of these technologies are sufficiently important that they have their own chapters in this book.

1.2.1 J2EE technologies

Java 2 enterprise edition (J2EE) is not a technology in its own right; it is an umbrella specification that dictates how a number of other Java technologies are to intraoperate. Not all of these are relevant to EJB developers, but those that are (particularly JNDI3 and JDBC3) are described in detail in this book. Others (JSP and servlets, for example) will be described briefly. For completeness, this section describes in outline all the technologies that are part of the J2EE group. It also describes some important non-Java technologies.


JavaIDL is a Java implementation of the CORBA interface description language (IDL). IDL is a language for specifying the methods of an object and their properties that is independent of the programming language. JavaIDL is a set of classes, which maps IDL data onto Java stubs that support the IIOP protocol.1On the whole, EJB developers don't need to be too concerned with JavaIDL, except where EJBs need to make explicit calls on CORBA ORBs. In most cases, the intricacies of JavaIDL are encapsulated—where necessary—in code generated by the EJB server vendor's tools.


JavaBeans activation framework (JAF) is a specification for mapping content handlers to arbitrary data types (typically MIME types). JAF gets only a brief (one-line) mention in the J2EE Specification; it is included because the JavaMail API has a dependency on it. EJB development is not likely to involve direct use of JAF.

Figure 1.1Figure 1.1. A simplified view of the J2EE application model; EJBs are central to this model, implementing the business logic and data management.

Figure 1.2Figure 1.2. EJBs in relation to other enterprise application technologies.


The J2EE Connector Architecture (JCA) is a relatively new addition to the J2EE standards. It defines a specification by which application servers can allow the components they host to get access to external resources, particularly legacy systems. The term 'connector' is used to describe any piece of software that allows this. At present, the major commercial EJB products all have their own proprietary ways of implementing connectors and often provide a range of connectors for popular data management systems, like IBM's CICS or SAP R/3. The problem is that not only are the connectors themselves proprietary and nonportable, the EJB code that makes use of them will only work with that vendor's connectors.

The JCA is an attempt to standardize the provision of connectors. A JCA-compliant product is portable across application servers and provides a uniform method of access for EJBs; thus the EJB code is also portable.

Providing a connector architecture is not straightforward. The systems that are connected may well have transactional semantics and need to be integrated with the transaction management system of the EJB container. In addition, it may be necessary to propagate the security context of the EJBs' caller into the connector. The JCA takes care of these issues and others.

At the time of writing, few commercial products are available that support JCA. The J2EE Reference Implementation, however, provides an implementation of it that can be used to experiment with the technology. JCA is described in more detail in Chapter 18.


The abbrevation 'JCA' is also used to denote the 'Java Cryptography API,' but in this book, 'JCA' will never be used in this sense, so there should be no confusion.


JDBC is a specification and API for providing Java program classes with access to relational databases in a vendor-neutral manner. We will have much more to say about this later (mainly in Chapter 8, but it is discussed extensively in other chapters as well).


Java Naming and Directory Interface (JNDI) was originally intended to fulfil the same role with respect to directory servers that JDBC does for database servers. That is, it is a specification and API that allows Java code to query and update a directory server. JNDI is still widely used for this, especially with LDAP directory servers (see page 178), but it has an additional role in the J2EE architecture. Here the JNDI API is used to retrieve classes that provide access to resources. These resources may be EJBs, database connections, simple data elements, mail servers, and many others. While information about the resource may be stored in a directory server, it may equally not be. The use of JNDI for this purpose is to avoid introducing a new API just for looking up resources. JNDI is extremely important to EJB development, and the whole of Chapter 7 is devoted to it.


Java Server Pages3 (JSP) are HTML or XML documents with embedded programmatic content. They are increasingly used for providing a Web-based user interface to EJB and database applications. In practice, JSPs are translated into servlets (see below), and have more-or-less the same properties and capabilities. JSP is an alternative technology to Microsoft's Active Server Pages (ASP) and to other server-side Web scripting technologies like PHP.


Java Transaction API (JTA) is a set of related APIs for Java components to communicate with the various components of a transactional system. In particular, there are APIs for use by application components, transaction managers, and resource managers. An EJB product is required to support the JTA APIs [EJB2.0 17.1.3] to the extent required to allow EJBs to demarcate transaction boundaries. The product can support the other APIs as well, and it would certainly improve inter-operability to do so, but at the time of writing, many commercial products do not provide such support. The implication is that if an EJB product is to take part in a distributed database transaction, it must use database drivers provided by the vendor of the EJB product, not the database. This issue, along with others relating to the use of JTA, is discussed in detail on page 287.


Many developers misunderstand the role of the Java Transaction Service (JTS), and its relationship to JTA. In fact, JTS is not part of the J2EE Specification (at least in Version 1.3), and EJB products are not required to support it [EJB2.0 17.1.3]. So what is it, and why is it important? The CORBA Object Transaction Service (OTS) Specification defines how transaction context can be propagated between distributed objects. This allows objects on different hosts to take part in the same distributed transaction. This is also a goal of EJB technology: If one EJB calls a method on another and the caller is part of a database transaction, then it should be possible for database work done by the called method to be encapsulated into the same transaction as the caller.

JTS specifies the interface between JTA (the transaction management methods that applications will use) and the low-level CORBA OTS. A JTS-compliant EJB product should allow EJBs to intraoperate seamlessly with CORBA components, at least in so far as transaction management is concerned. Although JTS is a specification, Sun Microsystems provides a full implementation of that specification; when developers talk of 'using JTS,' they often mean 'using Sun's implementation of JTS.' As CORBA integration becomes increasingly important in EJB technology, JTS may become more widespread. At present, most commercial products use proprietary techniques for propagating transaction context between EJBs.


Java Messaging Service (JMS) is a Java interface to asynchronous messaging products like IBM's MQ Series. JMS is becoming very important, as it provides an elegant way for EJB products to integrate with legacy systems. Version 1.3 of the J2EE Specification and Version 2.0 of the EJB Specification both add increased support requirements for JMS, and a compliant application server must provide not only an interface to a messaging service, but the actual infrastructure of a messaging service as well. The JMS architecture and its integration with EJBs, is discussed in detail in Chapter 10.


JavaMail is a specification for Java components to send and receive email messages in a vendor-neutral way. Although it is a specification and not an implementation, in practice most developers who are using it are actually using Sun's implementation, which provides support for SMTP, IMAP, and POP3 mail protocols. EJBs can use JavaMail to send email messages, as described on page 584.


Servlets are Java program classes that extend the functionality of a Web server. When a Web browser makes a request that corresponds to a servlet, the Web server calls the class's service() method. This method must generate content (usually HTML or XML) to be conveyed back to the browser. Servlets and JSPs are widely used to provide a Web interface to an EJB application; this technique is discussed in detail in Chapter 17.

1.2.2 Related technologies


Common Object Request Broker Architecture (CORBA) is a set of standards for allowing objects to interact in a distributed environment. In a sense, this is what EJB technology aims to do, and it is often thought that EJB and CORBA are competing technologies. There is indeed an overlap between what EJB servers do and what object request brokers do. The EJB developers have neatly sidestepped this issue by integrating some of the CORBA specifications into EJB. In particular, the IIOP protocol, which CORBA uses for communicating method-call information over a network, must now be supported by compliant EJB products. There is, of course, more to CORBA than remote method calls; Sun's developers have been very busy integrating other CORBA services into the Java environment. This is particularly evident in the development of JTS. The details of CORBA are beyond the scope of this book, although we will discuss those aspects that overlap with EJB technology (page 37).

The CORBA and IIOP specifications are defined and maintained by the Object Management Group (OMG), a large consortium of vendors and other interested parties. The size of the OMG means that its standards have very broad support, but it can take a long time to adapt to changes in technology. One vendor that is notably absent from the OMG is Microsoft, which has its own proprietary techniques for distributed computing, such as DCOM (see below). The relationship between EJB and CORBA is set out in detail in [EJB2.0 19.5].


Microsoft's Distributed Component Object Model (DCOM) and its successor COM+ are proprietary distributed object technologies from Microsoft. They are central components of Microsoft's integrated enterprise application framework called '.NET,' which includes a distributed transaction infrastructure, messaging services, Web components (based on ASP), and a database server.

While there are undoubtedly advantages to building a system from a set of products by a single vendor (there should be minimal problems with interoperability, for example), there are disturbing disadvantages as well. The most obvious of these is the difficulty of integrating products from other vendors. Another problem is Microsoft's continued unwillingness to produce versions of their products that run on Unix platforms; the majority of enterprise applications are deployed on Unix-based systems, even if something else is used for development.

Although Sun has not escaped criticism for its attempts to maintain control of the Java and J2EE standards, these standards are fully publicized and anyone can sell products that support them. The problem with Microsoft's offering is that the same company controls both the products and the specifications. Being in a position to do this puts a vendor at a huge advantage. Consider, for example, the task of producing integrated development environments (IDEs) to support the production of enterprise systems. It should be fairly clear that producing such tools is much simpler if everything the tools will work on is a product from the same vendor. If it proves to be impossible to achieve what is desired by users of the tools, no problem: We can change the underlying technology. This is simply not an option with a standards-based platform. Spare a thought for those brave souls who develop integrated development tools for J2EE: The tools must be able to generate and maintain code that complies with about 20 different open standards, all of which are developing rapidly under the pressure of about 100 major vendors. This is why it remains true that integrated tool support for J2EE is underdeveloped.

Use of Microsoft's distributed component technology does not preclude integration with EJBs. Part of Sun's J2EE support is a set of products that enable non-Java software to be clients of EJBs. These products, known collectively as client access services (CAS), currently support Microsoft COM and ActiveX clients (see developer.java.sun/developer/earlyAccess/j2eecas). Essentially these products use IIOP bridging technology, in which COM interactions are translated into IIOP interactions.


Extensible markup language (XML) is probably the most widely hyped, least understood of all the current enterprise technologies. In fact, XML is extremely simple; the cleverness is in the use which is made of it.

XML is a general-purpose language for describing data. Superficially an XML document resembles HTML, in that sections are demarcated using tags. What goes in and between these tags is entirely at the discretion of the developer, provided that basic syntactic integrity is maintained. This allows the format to be adapted to suit a large number of applications. In addition, the structure and content of the tags can be described formally in a document type definition (DTD), which allows the receiver of an XML document to ensure that the document is structured in a way that can be interpreted.2

XML owes its success to a number of factors:

  • It enjoys wide industry support. Among other things, this means that XML parsers and document assemblers are widely available.

  • It is a completely open standard.

  • The basic structure of an XML document can be checked against its DTD. This is particularly important in business-to-business applications, where the sender and receiver of a document may be very different kinds of business and may not work closely together.

Organizations involved in business-to-business (B2B) e-commerce are particularly excited about XML. To see why, consider that at present the majority of B2B transactions are carried out using proprietary EDI (electronic data interchange) services. These services are run by a small number of specialist providers, and are funded by subscription. In addition, many transactions are not carried on the Internet, but on private EDI networks, also maintained by specialist providers. The use of these services can be extremely expensive. In addition, the data formats used in EDI are often proprietary, and subscribers can easily by locked into a particular provider. With this background, it's easy to see why XML, which is open, flexible, and can readily be carried on a public network (with suitable encryption), is taking the B2B world by storm.

Although XML as a standard is well-supported, this does not necessarily mean that two XML-enabled applications can exchange data; this is one of the most widespread misconceptions about XML. To exchange data, the applications must at a minimum agree on a common DTD. As the use of XML has increased, large numbers of 'standard DTDs' have been defined by various industries. There are, for example, standard DTDs for data as diverse as livestock trades, curricula vitae, and interactive teaching materials. Having agreed on the DTDs, the collaborating organizations must agree on a protocol by which the XML documents will be encoded and transmitted.

So what does all this have to do with EJBs? The answer at present, sadly, is 'not much.' The EJB Specification only stipulates the use of XML for deployment descriptors (files that specify configuration data to the server). There's nothing to stop the developer coding EJBs that use XML for data interchange, but there is no built-in support for this. In particular, there is widespread interest in using XML to carry objects in EJB method calls (techniques for doing this are discussed on page 42) but EJB products aren't required to provide any support; it's up to the developer to implement it.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020