This chapter is from the book
This chapter is from the book
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
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.
JAF
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.1. A simplified view of the J2EE application model; EJBs are central to
this model, implementing the business logic and data management.
)
Figure
1.2. EJBs in relation to other enterprise application technologies.
JCA
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.
Gotcha!
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
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).
JNDI
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.
JSP
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.
JTA
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.
JTS
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.
JMS
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
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
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
CORBA
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].
DCOM, COM+, .NET
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.
XML
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.