6.4 Web services - related Java implementations

6.4 Web services “ related Java implementations

Not counting the actual Web services and Web services “dependent applications written in Java, the three most important categories of Java implementations in relation to Web services are:

1. Java application servers (e.g., Sun s ONE Application Server)

2. Java software development studios (e.g., BEA WebLogic Workshop)

3. Java-based legacy integration tools (e.g., IBM s WebSphere Host Publisher)

While the availability of the free reference implementations and open -source offerings (e.g., Apache Tomcat and the Eclipse Web tools from eclipse.org) tends to sometimes cloud and confuse the picture, the Java platforms (e.g., J2EE 1.4) are also implementation- agnostic specifications like industry standard or an IETF RFC. This is where the commercial Java application servers, led by the market leaders from IBM, BEA, Sun, and Oracle, come into the picture. Their express charter is to deliver reliable, value-added, platform-specific implementations of a particular J2EE specification. Consequently, the level of J2EE supported by the commercial application servers will, and should, lag behind (typically from six to nine months) the release of a new version of the specification. Thus, toward the end of summer 2003, all the well-known application servers, including Sun s own ONE Application Server 7, were still based on J2EE 1.3 ”albeit with ahead of the spec, value-added support for SOAP, WSDL, UDDI, and WS-Security.

The overriding value propositions offered by commercial Java application servers, over and above the basic functionality available with a no-charge reference implementation, are:

• Platform-specific availability and performance-related features ”in particular, support for load balancing, system clustering, failover, multithreading (i.e., concurrent execution of different instances of the same Java code, with each instance serving a different user or sets of users), and object/content caching

• JDBC drivers optimized for specific, platform-dependent database offerings (e.g., DB2, Oracle, SQL Server, and so forth)

• Extensive back-end connectors (or adapters) to existing application systems (e.g., ERP, CRM, legacy, and so on), typically per the J2EE Java Connector Architecture (JCA), to facilitate the integration of existing software resources with new Java-based applications

• Graphical, easy-to-use and master, point-and-click deployment, monitoring, and management capabilities

• Support for additional platforms, in particular mainframes, mini-computers (e.g., IBM AS/400), non-Solaris versions of UNIX (e.g., AIX), and non-RedHat versions of Linux

• Tight integration with other pertinent enterprise-class server functionality, such as message servers, Web servers (also referred to as HTTP servers), portal servers, and e-commerce servers

• Bidirectional tie-in with selected application development studios, workshops, or IDEs

The best way to think of this is that commercial application servers deliver feature-rich, highly interoperable, industrial-strength Java run-time environments for enterprise-class, mission-critical applications. The intense competition for market share between IBM, BEA, Sun, and Oracle, for a start, ensures that each tries to outdo the others, especially when it comes to ease-of-use, security, manageability, scalability, and RAS (i.e., reliability, availability, and serviceability) issues. Much effort is devoted to offering incisive and tangible load balancing, failover, and server clustering capabilities.

At the very basic level, they all enable you to install multiple versions of the application server (or the virtual machine part of it) on the same system ”with dynamic load balancing (based on actual workload, round- robin , or application/user type criteria) and failover. This type of simple, run-time multiplicity is usually referred to as clustered Java VMs on a single CPU/system. The next step up from there is horizontal load balancing, where you run one or more Java VMs on separate CPUs ”with transparent, cooperative workload sharing and failover support between them.

A variation of this, known as vertical load balancing, is possible on parallel-architecture, high-processor-content server machines available from IBM (e.g., mainframes, iSeries, and UNIX pSeries), Sun (e.g., Sun Fire family), and so on. With this type of setup, one or more Java VMs are run as a cluster, each in a virtual partition powered by multiple CPUs and a pre-allocated set of memory and I/O resources. The end goal of all such load balancing and failover options is to ensure that server-side, mission-critical Java applications, when deployed on suitable hardware systems, are able to handle very large workloads, possibly serving hundreds of thousands of concurrent online users, without performance degradation or instability. This is a key area where Java on a non-WinTel platform (e.g., UNIX server) can really demonstrate irrefutable superiority when it comes to performance, capacity, and scalability over .NET.

The bottom line here is that commercial Java application servers of the WebSphere, WebLogic, and Oracle9i (soon to be 10g) ilk are essentially synonymous with enterprise-class, mission-critical Java deployment. If you are seriously considering Java-based e-business applications (with or without Web services) for an enterprise that is deemed to be mid- size (let s say 250 employees ) or greater, it would border on gross irresponsibility not to seriously evaluate one or more of the popular commercial application servers. If your enterprise is already using Java on an enterprise scale, then the chances are relatively good that you already have an application server or servers in place ”or a well-stated strategy as to how and when you are going to start using application servers. Basically, trying to run large-scale, high-volume Java applications without the aid of an application server is bound to be counter-productive ”akin to trying to drive a large truck cross-country in the middle of the summer without power steering and air conditioning.

An enterprise s IT platforms of choice could also dictate the need for a commercial application server ”and possibly even a specific application server from a particular vendor. The issue here is that the free Java servers from the Java camp do not support non-UNIX high-end systems ”in particular mainframes and AS/400 systems ”though it is estimated that the installed base for AS/400s is in excess of 600,000 systems. However, to be fair, IBM does offer no-charge, no-frills JDKs for these platforms ”though they do not set out to offer platform-specific exploitation capabilities (e.g., integration with workload management). Commercial application servers are also usually required for some non-Solaris versions of UNIX (e.g., AIX) ”though it should be noted that some vendors (e.g., H-P) take the Java reference implementation, customize it to their flavor of UNIX, and then make it available for download from their Web sites. Note that such platform-customized, redistributable versions of J2EE, though optimized for a particular vendor s platform(s), will typically not include all of the value-added features offered by commercial application servers.

If your preferred IT platform for mission-critical applications still happens to be IBM mainframes running MVS (e.g., OS/390 or z/OS) or AS/ 400s with OS/400, then you will most likely have to opt for IBM s own WebSphere Application Server (WAS) ”which is now at Version 5 (though it should be noted that z/OS does also include a no-charge JDK). Given how specialized these systems are and the considerable expense associated with testing, maintaining, and supporting mainframe software, as well as IBM s hold of this segment of the market, mainframes and AS/400s are no longer supported by the non-IBM application servers. This in itself should not be considered a grave imposition , given that WAS is the current market leader in this field and has over the years invariably set the standard for the value-added capabilities offered by application servers.

Figure 6.11, from IBM, highlights the key features of WAS 5.0.2. For comparison, as well as to keep the playing field as level as possible, Figure 6.12 shows the first page of BEA s equivalent marketing material for its WebLogic Server ”claimed by BEA to be the world s leading application server. To be fair to both IBM and BEA, the exact market share numbers for WebSphere and WebLogic are contentious at best, and WebLogic, a couple of years ago, was the market leader ”though the consensus is that IBM is now ahead, even if only by a nose.

Figure 6.11: The key features of the latest WebSphere Application Server V5.0.2, per IBM.

Figure 6.12: Some of the key features of the latest BEA WebLogic Server 8.1 per BEA.

This discussion has focused on the desirability of using application servers for running enterprise-class Java applications. However, from a Web-services perspective, it is indeed conceivable that enterprises of all sizes and shapes may also start looking at Java as an attractive platform on which to offer Web services ”particularly with Windows servers now under siege due to their apparently never-ending stream of security vulnerabilities. While commercial application servers will still provide better manageability, RAS, performance, and scalability, it is indeed possible for one to consider offering Java-based Web services on a UNIX or Linux platform by using just reference implementation or JBoss, at least to begin with, if cost is an issue and the usage levels for these Web services are expected to be light to moderate.

Next to the application servers, the most important Java implementations in relation to Web services are the application development studios such as BEA s WebLogic Workshop, IBM s WebSphere Studio Application Developer, and Sun ONE Studio. The express goal of these highly visual IDEs is to compress the software development cycle and thus enhance, by hook or by crook, programmer productivity ”that ever- elusive , Holy Grail of the software community. Figures 6.13(a) and 6.13(b) show representative screen shots from WebSphere Studio Application Developer, while Figure 6.14 shows one from BEA s WebLogic Workshop.

Figure 6.13(a): A representative screen shot from IBM s WebSphere Studio Application Developer, highlighting its highly visual, drag-and-drop software development paradigm ”in this instance, manipulating EJBs.

Figure 6.13(b): Another screen shot from IBM s WebSphere Studio Application Developer, in this case showing the dynamic creation of a user interface for a Java application using JSPs.

Figure 6.14: Creating JSPs with BEA s WebLogic Workshop.

In much the same way that one, given enough time, patience, and skill, can still develop sophisticated HTML Web pages just using a no-frills text editor (e.g., Windows Notepad), it is also possible to develop Java code of any complexity by using a straight text editor and the JDKs available with the Java platform. It should also be remembered that when it comes to Web services, there is also the new Java WSDP 1.2. Furthermore, as is the case with Java servlet servers, there are also some no-charge, open-source Java IDE initiatives ”most notably the IBM-encouraged Eclipse platform, which continues to gain vendor sponsorship and market visibility. To this end it should also be noted that IBM s high-profile WebSphere Studio products are now based on this open-source, readily extensible, Eclipse platform, thus making this product family even more attractive.

But as is the case with Web page design, using a visual, drag-and-drop IDE, rather than coding everything laboriously by hand, is invariably more convenient , more efficient, faster, and prone to fewer errors ”though there will always be an initial learning curve associated with using any IDE. Ease-of-use, convenience, and potential productivity enhancements are, nonetheless, the primary value propositions for using a studio for developing Java-based Web services or applications. In many ways this is another pivotal enterprise IT strategy, philosophy, and standards-related issue, which invariably becomes intertwined with the enterprise s stance on using an application server ”given that the leading application servers have companion, complementary studios with tight, single-image integration between the two. However, whereas an enterprise may be forced to use a Java application server because of the server platforms it uses (e.g., mainframes), the need for a studio product is unlikely to be dictated by platform preferences alone, given that Windows, UNIX, and Linux (in that order) will continue to be the platforms of choice used by Java programmers.

The bottom line here is that today s studio offerings are proven, flexible, and include an extensive repertoire of capabilities ”particularly in the areas of Web services “related technologies such as SOAP and WSDL. Once programmers have circumvented the inevitable, initial learning curve, these studios, by their very design, should accelerate software development, integration, testing, and deployment. In general, they should deliver a positive ROI in relatively quick time. So the moral here is that if an enterprise is serious about using Java as its strategic, long- term software development methodology, then it would behoove the enterprise to carefully evaluate some of the leading studio offerings to determine the potential benefits of standardizing its development framework on one of these visual IDEs.

Java-based legacy integration tools, the so-called host integration category within the Web-to-host genre of offerings, round off the Web services “ related Java implementations. The significance of these products, with IBM s WebSphere Host Publisher being the quintessential example, is that they enable enterprises to gainfully extract and reuse business logic fragments from mission-critical applications ”with each fragment now represented as an EJB. One or more of these EJBs could then be packaged as a Java-based Web service, using either a tool such as the Java WSDP or a studio product. Figure 6.15 shows the high-level architecture of the WebSphere Host Publisher product. In some cases this type of integration may also be realized by using one or more of the connectors (or adapters) available with application servers. One way or another, these legacy integration tools enable enterprises to maximize their considerable investment in mission-critical applications. The bottom line here is that Java is extremely enterprise savvy. There is no shortage of competitive and compelling industrial-strength Java implementations to enable enterprises to safely pursue a Java-centric Web-services strategy with confidence and panache.

Figure 6.15: High-level architecture of IBM s Java-based host integration product, WebSphere Host Publisher (at the V3.5 level), showing where EJBs, JSPs, XML, and the WebSphere Application Server come into play.