6.2 The Java 2 platforms

The trademark write once, run anywhere platform independence of Java is not restricted to conventional computing platforms. Java technology, reflecting its roots as an embedded system for consumer electronics, even today is carefully positioned as a powerful, full-function software methodology that can be made to work on just about any electronic device. Java is already poised to be a major player in next -generation, multimedia, intelligent phones. It can be used in PDAs, and, given its symbiotic relationship with Windows, can be readily used with tablet PCs as well as Pocket PCs. It is yet again being considered for TV set-top boxes. Java-based smart cards, as shown in Figure 6.5, have been available since October 1996. These are known as Java cards, and information about them can be found at http://java.sun.com/products/javacard/.

Figure 6.5: A picture of a Java-based smart card from the java.sun.com Web site.

Given this wide spectrum of hardware and software permutations it is intended to work on, Java itself is thought of as a self-contained platform in its own right. Thus, there is the concept of a Java platform. The original Java platform had two key components : the JVM and the Java API.

Figure 6.6 depicts a Java platform vis--vis a specific computing or consumer electronic environment. The Java API is an extensive collection of predefined, ready-to-run software components for facilitating and expediting Java application or applet/servlet development. This API is grouped into standard libraries containing related sets of functional entities known as classes. Thus, there are libraries for GUI creation, database access, and so on. These libraries are known as a package. This overall Java platform is then ported onto a specific target system, whether it be a PC, mainframe, handheld, phone, or TV set-top box. Though this original premise that a Java platform consists of a JVM and a Java API set is still conceptually sound, Java technology and terminology, as is to be expected, have expanded and evolved. For a start, the term container is now preferred to that of JVM.

Figure 6.6: The concept of a Java platform, consisting of a JVM and a Java API, on a specific computing platform.

Since the introduction by Sun of the term Java 2 in December 1998, the current Java platform is known as the Java 2 platform. The Java 2 platform is billed by Sun as providing robust, end-to-end solutions for networked applications as well as being a trusted standard for embedded applications. Today s Java 2 platform consists of three editions. These are known as:

Java 2 Platform, Standard Edition (J2SE)
Java 2 Platform, Enterprise Edition (J2EE)
Java 2 Platform, Micro Edition (J2ME)

Figure 6.7 shows Sun s depiction of how these three editions stack up against each other. Also note that Sun, for the sake of completeness, includes the Java Card APIs. The optional packages, shown with J2EE and J2SE, are libraries of value-added services ”which in practice will typically be provided by an application server implementation.

Figure 6.7: Sun s depiction of the three Java 2 editions, J2EE (at left), J2SE, and J2ME, and how they stack up against each other.

J2SE, known as the core Java software, came about from what was known in early 1998 as Java 1.2. Today, J2SE, which is at Version 1.4, is positioned as a fast and secure foundation for building and deploying mission-critical enterprise applications ”albeit primarily for client-side (i.e., desktop) applications, whether they be in the form of applets or applications. J2SE provides the necessary Java APIs; compiler; tools; and run times for writing, debugging, deploying, and executing Java applets and applications. The J2SE JVM in this instance, as shown in Figure 6.7, is known as the Java Runtime Environment (JRE). J2SE supports JavaBeans but not EJBs.

The standard built-in repertoire of services offered by J2SE includes database access (i.e., JDBC), directory, and security. The security-related functions include Java authentication and authorization service (JAAS) for imposing access control; Java secure socket extension (JSSE), which is a Java version of SSL; and Java cryptography extension (JCE), which facilitates encryption. J2SE 1.4, in addition, includes support for key industry standards including XML, XML s DOM API, Kerberos, LDAP, and CORBA. It supports 64-bit addressing and thus gives Java applications the option of accessing hundreds of gigabytes of RAM for highly memory- intensive scenarios such as memory-resident table (i.e., database) processing. It is also claimed to be highly scalable and nimble .

Though J2SE, with its support for XML, can be used as a basis for developing Web services or applications that consume Web services, in reality it is the server-side-oriented and highly component-based J2EE platform that is invariably targeted for most Web services “related uses. This makes sense. As stated in its name , this is the Java platform intended for use by enterprises . J2EE includes support for servlets, JSPs, and EJBs. It is also the platform implemented by all of the major commercial Java application servers. Given its relevance to Web services, the next subsection focuses entirely on J2EE.

J2ME, the Java counterpart to Microsoft s Windows CE, is a highly optimized, low-resource consumption Java run-time environment targeted at small footprint consumer devices. In addition to being aimed at cell phones and TV set-top boxes, it is also positioned for use on pagers and smart cards. As with all things Java, the mantra, yet again, this time in the context of consumer devices, is write once for potential use on a wide range of devices. J2ME includes a flexible user interface, a robust security model, and support for a wide range of networking protocols. Recognizing that the MO of consumer devices can be very different from that of contemporary, Internet-dependent computers, J2ME caters to both network-connected and off-line (i.e., disconnected) applications ”though always ensuring that the necessary Java applications can be dynamically downloaded onto a device when it has a network connection.

J2ME, as shown in Figure 6.7, comes in two distinct configurations. The so-called CDC configuration, which includes a foundation profile as well as a personal profile, is for connected devices ”where CDC refers to connected device configuration. The other configuration is called CLDC. CLDC stands for connected limited device configuration. CLDC is for devices that are expected to work in off-line mode for extended periods of time. On this basis, CDC is targeted at TV set-top boxes, networked embedded devices (e.g., medical equipment), and high-end PDAs. CLDC, on the other hand, is for cell phones, pagers, and low-end PDAs. Each configuration includes a virtual machine and a minimal set of Java class libraries applicable to the range of devices being addressed by that configuration. Similarly, each configuration is carefully tailored to work optimally with the processor, memory, and I/O capabilities likely to be available on the target devices.

The profiles included with the J2ME configurations cater to the specific, run-time requirements of different device categories. Thus, the personal profile is for devices such as PDAs and high-end cell phones that require a GUI as well as the option for executing standard Java applets invoked from Web pages. This profile includes the full AWT library and ensures that standard Web applications, originally developed for desktop use, can be executed on devices running the CDC configuration. On the other hand, the foundation profile is a lower-level functional set, without a user interface, for use in networked embedded systems.

6.2.1 Java 2 Platform, Enterprise Edition (J2EE)

Whenever Java is being discussed, in earnest, within the context of Web services, it would typically be the capabilities offered by J2EE that are most likely being considered ”implicitly or otherwise . From a Java standpoint, J2EE is, indubitably, the obvious foundation technology for developing and deploying Web services. J2EE, from ground up, is a component-based methodology. It is built on top of J2SE and in essence adds enterprise- and server-related functionality to the J2SE core ”in particular, support for EJBs, servlets, and JSPs.

J2EE is a service-rich, distributed application model that places much emphasis on modularity, security, transaction processing, messaging, and interoperability with legacy applications. Its express purpose is to facilitate the development and use of platform-independent, server-side software for Web-oriented, n - tier applications ”including those that require either back-end data interchange connections to existing applications or those that leverage business logic from legacy applications that have been isolated and modularized into reusable components (e.g., JavaBeans).

J2EE s basic premise is that it will deliver a complete set of easy-to-access backbone services for component-based software so that the software developers can concentrate on the business logic aspects of the software without getting sidetracked trying to work out how they obtain necessary functionality such as directory lookup, authentication, and messaging. The component model advocated by J2EE is EJBs. J2EE, however, offers interoperability with CORBA. With the J2EE software model, business logic is encapsulated within EJBs. EJBs, which can be used by servlets and JSPs, run in a Java container. This container provides the EJBs with all of the necessary backbone services.

Figure 6.8, from Sun s BluePrint Design Guidelines for J2EE, clearly demonstrates the highly component-oriented role envisaged for J2EE in an n -tier application scenario. In this figure, J2EE is the basis for both of the central columns ”one of which provides the server-side business logic, exploiting EJBs, while the other, in conjunction with a Web server, handles the server-side data presentation aspects, leveraging the Web page design flexibility afforded by JSPs. It is the functionality associated with these two central columns that is implemented and leveraged by Java application servers. This figure also shows the possibility that J2EE-based clients , through standard Web browsers and where necessary augmented by applets or desktop J2SE-level Java applications, will in general be the norm for the client tier of J2EE applications.

Figure 6.8: Sun s representation of a possible J2EE-based n -tier model, highlighting the component-oriented nature of J2EE as well as the fact that in such a model it is possible to have Java on both the client and server sides.

The application model envisaged for J2EE divides enterprise applications into three fundamental parts :

Components
Containers
Connectors

The components (i.e., EJBs) are the end-user consumables that developers create using Java. Java developers creating components do not have to worry about also having to create containers and connectors. Containers and connectors are implemented and delivered by system vendors ”typically in the form of application servers. Containers are in essence the hosts for the components. Containers provide the necessary backbone services to the components ”as well as the end users making use of those components. Since containers are implemented on specific platforms, the exact run-time services they provide can typically be specified and customized for a particular set of components at the time the components are deployed on that platform. For example, containers could provide transparent load balancing and automatic failover capabilities.

The connectors in this model are external to the J2EE platform. They are located beneath the J2EE platform in the form of a portable API. They enable system vendors to provide seamless Java-based interoperability with specific system services or existing applications. Figure 6.9 shows the relationship between the three Cs of the J2EE application model. Figure 6.10 goes on to illustrate the overall J2EE architecture per Sun.

Figure 6.9: The Java application model divides enterprise applications into components, containers, and connectors.

Figure 6.10: The J2EE platform per Sun showing how it provides a set of standard services built upon the basic services provided with J2SE.

The fundamental value proposition of J2EE revolves around its provision of a comprehensive set of services. The prime services available with J2EE can be summarized as follows :

Relational database access with the Java Database Connectivity (JDBC) API
Directory and naming services, which enable J2EE components to look up other objects they require to access, provided via the Java Naming and Directory Interface (JNDI) API
A mail service to facilitate e-business application development (e.g., order confirmation via e-mail) via the JavaMail API
A powerful messaging mechanism, known as the Java Message Service (JMS), to enable components to send and receive messages asynchronously
While J2EE provides built-in transaction support, the Java Transaction API (JTA) provides J2EE components and clients with further control to fine-tune their transactions, including the ability for multiple components to participate in a single transaction
CORBA compliance via the JavaIDL, which enables Java components to interact with CORBA-compliant software resources, and the RMI-IIOP interface, which bridges the Java Remote Method Invocation API (RMI) with CORBA s equivalent Internet ORB Protocol (IIOP) to facilitate the integration of legacy business logic into new Java applications

Then there is also the tight integration with XML, along with the support for the XML DOM and SAX APIs via the Java API for XML Parsing (JAXP).

J2EE consists of four specific deliverables:

J2EE specification
J2EE reference implementation
J2EE Sun BluePrint
J2EE compatibility test suite

The specification spells out the J2EE architecture and the nature of the services that are associated with a given version of J2EE in terms of the J2EE API set. The specification is totally implementation agnostic . The various Java application servers provide specific implementations of this specification on various platforms. The reference implementation, per its name, provides a tangible interpretation of the J2EE specification for Windows (currently Windows 2000 Professional and Windows XP Professional versions), Sun Solaris, and Linux (typically RedHat) platforms. It includes software developed by the open -source Apache Software Foundation ”in particular, the Tomcat servlet engine. These days Sun, to the chagrin of the other application server vendors, also throws in the no-charge Sun ONE Application Server Platform Edition as another reference model.

The reference implementation also includes sample applications, tools (e.g., compilers and a debugger), and documentation. The reference implementation serves two key purposes. First, it provides those developing platform-specific implementations with a concrete, readily recreatable benchmark of how the J2EE services should operate and how they can be accessed. They can thus use the reference implementation to compare their implementations with what has been sanctioned, as the norm, by the Java community process (JCP). It thus takes the guesswork out of J2EE implementations. In addition, the reference implementation also serves as a fully functional, no-charge, easily Web-downloadable J2EE product that can be freely used without any caveats by developers who may want to develop Java applications or evaluate Java without incurring the cost of purchasing a commercial Java application server. Though only available on a limited but popular set of platforms, the reference implementation does, nonetheless, fulfill the open and free-of-charge credentials for Java.

The reference platform, along with the compatibility test suite, ensures that J2EE implementers should be able to guarantee a base level of consistency and interoperability between different implementations on different platforms. In the early days of Java, implementations of different platforms were not as consistent as they should have been. Thus, for example, an applet that would work immaculately on a browser running on Windows 98 might not work as well on Netscape running on a Mac. This led to software developers twisting the Java write once, run anywhere catchphrase to: write once, test everywhere. But now with the compatibility test suite, implementations are more consistent and predictable. A Java Application Verification Kit (AVK) is also available to validate Java software portability. The BluePrints, the final part of the J2EE deliverables, consist of both documentation and Java coding examples. They set out to serve as a best practices design guide for developing and deploying J2EE component-based enterprise applications.

J2EE is at version 1.4 (final draft 3) as of April 15, 2003. Catering for Web services was an overarching goal for J2EE 1.4. Consequently it is billed by the Sun camp as the most complete Web services platform ever. A key Web services “related feature in 1.4 is the new JAX-RPC 1.1 API ”where JAX stands for Java API for XML-based RPC. JAX-RPC enables Java developers to create SOAP-based, Web services “related, platform-independent software. With SOAP capability provided by JAX-RPC, Java software can act either as a Web service or as applications that make use of other Web services. JAX-RPC also supports Web service invocation parameters defined with WSDL. JAX-RPC can be used by servlets or EJBs. In addition to offering other XML Web services “related APIs, which are discussed in Section 6.3, J2EE 1.4 also features ground-breaking support for the WS-I basic profile 1.0 to guarantee a specific level of Web services “ related interoperability with other non-Java software.

The J2EE 1.4 also includes the J2EE Management 1.0 API. This new API defines the information model for J2EE management, including the standard Management EJB (MEJB). It includes the Java Management Extensions (JMX) API, which is used to log statistics of resource usage. In addition, 1.4 also introduces the J2EE Deployment 1.1 API, which provides a standard platform-independent API for the deployment of software on any target platform. There are also enhancements to the J2EE connector architecture, which now includes support for integration with JMS.