Host integration the precursor to EAI  [from a 2001 presentation for Attachmate]

1. Java and Web services

2. Web services related Java
    Implementations

3. PCgate: The need for grid computing

4. Host access/Web-to-host consolidation

5. Farabi: HostFront Enterprise Server

6. 2nd IONA interview on Artix

Java and Web Services

Since at least early 2002 it has been possible to develop Web services or applications that invoked Web services using Java – albeit typically with a high-end, commercial application server à la BEA’s WebLogic or IBM’s WebSphere. This was because total built-in support for SOAP etc. were not available in J2EE 1.3. Thus one had to rely on implementation specific Web services related extensions. But all of this has been rectified with J2EE 1.4 which sets out not just to be Web services savvy but to be a preferred platform for Web services related solutions. To this end many XML related APIs have now been included in Java – in particular J2EE. This repertoire of APIs is known as the ‘Java APIs for XML’ (JAX). The goal of JAX is to ensure that any and all Web services related software, on either side of the ‘invoker-provider’ model, can be created entirely in standard Java without recourse to tools written in other languages or implementation specific extensions.

The Java APIs for XML fall into two broad categories: those that deal explicitly with the processing of XML documents and those that deal with the procedures used to interchange XML oriented documents. There are three XML document oriented Java APIs. These being:

1.   Java API for XML Processing (JAXP)

2.   Java Architecture for XML Binding (JAXB)

3.   SOAP with Attachments API for Java (SAAJ)

 There are two APIs that deal with the procedures used to interchange XML oriented documents. These being:
   1.   Java API for XML-based RPC (JAX-RPC)

2.   Java API for XML Registries (JAXR)

JAXP is invaluable for processing XML documents. It is a powerful and extensible API that is based on the concept of using external ‘plug-in’ modules. JAXP supports SAX, DOM and XSLT – replete with full XML namespace processing. SAX and DOM are the two most popular APIs associated with XML. They both work using a document parsing model; in this case the accepted XML document parsing methodology. All XML parsers verify that an XML document is well formed [e.g. checks that there are no missing tags].

Some XML parsers are known as validating parsers. Validating parsers in addition to verifying the structure of an XML document, go a step further by validating the contents of a well formed XML docuument against the appropraite DTD or schema. Xerces, which is available from Apache in both Java and C++ versions, is a widely used example of a quientessential XML validating parser that support both the SAX and DOM APIs,

JAXP per se does not implement either the SAX or DOM APIs. Instead, it allows any Java application to invoke a suitable XML parser from within the Java application. JAXP in essence allows XML parsers to be plugged-in to a Java application via what Java referrs to as the pluggability layer. Xerces, which is comprehensive and all-inclusive, is rapidly becoming the ‘gold standard’ within the Java community for XML parsers. But other XML parsers are available from the likes of Oracle. There is also a very nimble, Java-based, non-validating XML parser known as Piccolo [piccolo.sourceforge.net].

SAX is an ‘event-based’ parser best suited for inter-program interactions à la those associated with Web services, while DOM is targeted at XML presentation oriented applications such as XML editors or XML browsers. An ‘event-based’ parser when parsing a document triggers an event each time it encounters a document ‘construct’ it recognizes. Thus in the example of an XML parser, an event could be triggered each time the parser encounters the “<” symbol, the “</” string or whitespace characters. In the case of Java, the event triggered by SAX would be a previously defined method within the application. Thus you would typically have a method to handle the start of an element that would be invoked each time the SAX parser encountered the “<” symbol. DOM, on the other hand, takes an XML document, parses it and creates an object representation of that document – in the form of a tree.

The current version of JAXP also includes support the XSLT. Consequently programmers can convert XML content obtained via a parser to other formats, including HTML. JAXP, very much in tune with XML trends, makes ure that there is full support for XML namespaces. Thus the bottom line here is that JAXP ensures that Java applications have unconstratined access to the structure and content of any XML document through the use of any appropriate XML parser – and moreover ensures that XML-defined data extracted in this manner can be easily converted to any other format using XSLT.

JAXB is another way by which Java applications can process XML documets. It is a Java technology that enables developers to easily generate Java classes [i.e. ‘templates’ for creating objects in the form of JavaBeans] from an XML schema. Thus you can use JAXB to create a representation of an XML schema in terms of Java code. It provides an easy and convnenient way by which Java developers can incorporate XML data and XML related processing functionality into Java applications without even having to know much about the intricasises and mechanics of XML.

SAAJ, though categorzied by the Java camp as an XML document related API, is very different from the other two APIs. Rather than being an API related to processing XML documents, as is the case with JAXP and JAXB, SAAJ is in reality a SOAP related API. It provides a standard means by which Java applications can send XML documents using SOAP. SAAJ is obviously targetted at Web services related scenarios. The current SAAJ API is based on the SOAP 1.2 specification.

Like SAAJ, JAX-RPC is another Web services oriented API – albeit this time on the procedural side rather than on the document realted side. JAX-RPC is the pivotal API when it comes to developing and deploying web services on a Java platform. It is a featured highlight as well as a cornerstone of the J2EE 1.4 imitative. JAX-RPC, as implied by the name is an RPC invocation mechanism. It enables Java applications to invoke XML-based RPC functionality per the SOAP 1.2 specification. It firmly aligns Java software with accepted Web services modus operandi for I/O as discussed in the previous chapter. JAX-RPC enables Java software to participate, with aplomb and ease, anywhere within a Web services related programming scenario – either as Web services being invoked by other applications or as applications invoking Java or non-Java based Web services.

JAXR, from a Java perspective, puts the icing on the cake vis-à-vis Web services. It is a uniform and standardized API for accessing and querying different kinds of XML registries – with UDDI and the OASIS sponsored ebXML registry being key among these. It provides Java applications with a unified information model that describes the content and metadata included within XML registries. With JAXR, Java developers can write powerful and versatile registry client software – for example for UDDI registration, update and query. With this set of APIs, all of which are integral parts of J2EE 1.4, the Java camp has indeed gone all out to make sure that they have left no bases uncovered when it comes to unstinted support for Web services. But they did not stop here. They raised the ante, obviously against .NET, by packaging all of these XML related APIs and more into what is called the Java Web Services Developer Pack (Java WSDP) 1.2.

Java WSDP is a free integrated toolkit to help Java developers create any type of XML related software using the latest Java APIs. It can be downloaded, at will, from java.sun.com, for the four traditional ‘reference’ platforms supported by Java – viz. Sun Solaris, Windows 2000, Window XP and Red hat Linux. Consistent with the fact that the current J2EE 1.4 support for the core Web services related technologies is highly standards compliant, Web services related software developed with WSDP is assured to conform to WS-I’s basic profile 1.0. In addition to offering JAXP, JAXB, SAAJ, JAX-RPC and JAXR, WSDP also includes additional value-added capabilities such as JavaServer Faces (JSF) and access to all of the J2EE security features including authentication and encryption. JSF is a technology for simplifying the building of user interfaces for sever-side Java software. JSF enables Java programmers to quickly and easily assemble reusable UI components into a displayable page, connect these components to the appropriate application data sources and then correlate client-generated events to server-side event handlers.

Web Services Related Java Implementations

Not counting the actual Web services and Web services dependent applications written in Java, the three most important categrories of Java implementations vis-à-vis 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 à la 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 towards the end of the summer 2003, all the well known app. 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 etc.

The overriding value propositions offered by commercial Java application servers, over and above the basic functionality available with a no-chrage 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 etc.]

• extensive back-end ‘connectors’ (or ‘adapters’) to existing application systems [e.g. ERP, CRM, ‘legacy’ etc.], 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, minicomputers [e.g. IBM AS/400], non-Solaris verions of Unix [e.g. AIX] and non-Red Hat versions of Linux

• tight integration with other pertinent enterprise-class server functionality such as meesage servers, Web servers [also referred to as HTTP servers], portal servers and e-commerce servers

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

 Next to the app. servers, the next most important Java implementations vis-à-vis Web services are the application development studios à la 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.

 In much the same way that one, given enough time, patience and skill, can still develop sophiticated 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, 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 serlet servers, there are also some no-charge, ‘open-source’ Java IDE initatives – most noteably the IBM-encouraged Eclipse platform that 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 just as in 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 less errors – though there will always be an initial leraning 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, philosphy and standards related issue invariably intertwined with the enterprise’s stance on using an app. server – given that the leading app. servers have companion, complementary studios with tight, ‘single-image’ integration between the two. However, whereas an enterprise may be forced to use a Java app. 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.

 Java-based legacy integration tools, the so called ‘host integration’ categrory 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 quientessential example, is that they enable enterprises to gainfully extract and resue 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 either using 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 using one or more of the connectors (or adapters) available with app. servers. One way or another these legacy intergartion 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.