The trademark write once, run
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
Figure 6.6 depicts a Java platform vis--vis a specific computing or consumer electronic environment. The Java API is an
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
The standard built-in
Though J2SE, with its support for XML, can be used as a basis for developing Web services or applications that
J2ME, the Java
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
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.
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
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,
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
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
The components (i.e., EJBs) are the end-user
The connectors in this model are external to the J2EE platform. They are located
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
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 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
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
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.