6.2 The Java 2 platforms

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:

1. Java 2 Platform, Standard Edition (J2SE)

2. Java 2 Platform, Enterprise Edition (J2EE)

3. 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 :

1. Components

2. Containers

3. {% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

   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.