In-Depth

J2EE meets Web services

• By Ash Parikh, Rajesh Pradhan, Sean Jiang
• September 29, 2003

According to The Stencil Group, a San Francisco-based consulting and advisory firm, Web services can be generically defined as “... loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols.”

A Web service can be more specifically defined as a piece of software that can be referred to by a Uniform Resource Identifier (URI) and that uses XML to detail its contracts or interfaces and bindings. Other pieces of software can then look up a Web service using these details and exchange messages with it over standard Internet protocols.

Per the Web Services Architecture Working Draft 2002 with the W3C, the Web services architecture can be depicted as a layered collection or stack of components and technologies called the Basic Web Services Architecture. This architecture covers message exchange between roles, Web services details or descriptions, and the lookup of Web service details. As shown in Figure 1, the Basic Web Services Architecture models the collaborations between the Service Provider, the Service Discovery Agent and the Service Requestor.

Roles in the Basic Web Services Architecture can take on one or more responsibilities. Typically, a Service Requestor is a role that calls upon a Web service, while a Service Provider is one that listens to the request and fulfills it. The Discovery Agent is a mediator that houses the Web service details and allows them to be looked up.

The collaborations between the Service Discovery Agent, Service Requestor and Service Provider can be represented as publish, bind and interact activities/operations. These activities/operations enable the software components to advertise the service, look it up and collaborate with it.

The Basic Web Services Architecture can be extended to include features such as asynchronous messaging, caching, attachments, long-running transactions, reliable messaging, message authentication, session management and so on. This augmented suite is termed the Extended Web Services Architecture.

Per the Web Services Architecture Working Draft 2002 with the W3C, it is important to understand that a Web service is described as using a standard, formal XML notation, called its service description, that provides all of the details necessary to interact with the service, including message formats, transport protocols and location. The nature of the interface hides the implementation details of the service so that it can be used independent of the hardware or software platform on which it is implemented, as well as independent of the programming language in which it is written. Web services can be used alone or in conjunction with other Web services to carry out a complex aggregation or business transaction.

J2EE grows up

What began in the mid-’90s as the revolution called Java has now matured into three branches: Java 2 Standard Edition (J2SE), Java 2 Enterprise Edition (J2EE) and, more recently, Java 2 Micro Edition (J2ME). Fueled by the start of the Internet era and browser-based technology, the Java programming language and J2SE platform traces its early beginnings as an interesting client-side technology for developing and running applets and Java apps. With its growing popularity, Java’s adoption as a recognized, platform-independent application development option and its ease-of-use soon propelled it to preferred technology status. Performance is still a favorite topic for debate, but with more responsive JVMs, as well as better design and coding techniques, this has become somewhat of a moot point.

As interest in Java and the convenience it afforded increased, users in the enterprise world started to look into ways of re-inventing the Java platform as a distributed computing environment. With noteworthy forerunners such as CORBA and DCOM to learn from, Java thought leaders applied familiar concepts such as RPC and RMI to create a robust and scalable component-based environment called J2EE that would provide built-in features such as security and transaction support. What this meant for an enterprise was that enterprise application developers could concentrate on developing business logic and leave plumbing worries to the J2EE environment or container.

According to the J2EE specification, we have API-level access to develop the following software components in J2EE:

* 3Applets or GUI client components that run in Web browsers.

* Application client or standalone client components.

* Web components such as Servlets and JSPs that reside in Web servers and listen for HTTP requests from Web client components.

* EJB components or Enterprise Information System (EIS) business logic components that encapsulate business rules and partake in transactions.

A typical J2EE system can be divided into three tiers: the client tier, which comprises Web and non-Web browser-based client components; the app server tier, which is composed of Web components and Session EJBs; and the back-end tier of data representation and data interaction components such as Entity EJBs.

J2EE Web services: A marriage of convenience

As specified in the following snippet taken from the J2EE specification, the J2EE platform contains details on the implementation, assembly, deployment and consumption of Web services: “J2EE provides full support for both clients of Web Services as well as Web Service endpoints. Several Java technologies work together to provide support for Web Services. The Java API for XML-based RPC (JAX-RPC) provides support for Web Service calls using the SOAP/HTTP protocol. JAX-RPC defines the mapping between Java classes and XML as used in SOAP RPC calls. The SOAP with Attachments API for Java (SAAJ) provides support for manipulating low-level SOAP messages. The Web Services for J2EE specification fully defines the deployment of Web Service clients and Web Service endpoints in J2EE, as well as the implementation of Web Service endpoints using enterprise beans. The Java API for XML Registries (JAXR) provides client access to XML registry servers.”

The life cycle of J2EE components and Web services is not dissimilar; they almost mimic one another as both have sprung from similar distributed computing ideologies. From modeling a Web service to its creation, binding, deployment, publishing and consumption, a Web service presents no new tenets for understanding, and its inclusion in the J2EE component stack is a logical addition to enable loosely coupled interaction between applications. The combination of J2EE and Web services seems to be a perfect match:

* Since Web services build around existing designs, architecture-level changes to existing infrastructure are not necessary.

* One can expose J2EE components as Web services, thus enabling loose coupling of components.

* Portability of applications and functionality can be inherently provided by Web services technology.

* Web services realizations can reuse many of the features of the J2EE platform, such as security and transactions.

* Since a Web service is based on open standards, it ensures vendor-agnostic behavior, which was the intent of J2EE.

J2EE 1.4 Web services standards support

Sun Microsystems is expending a significant effort to ensure that the J2EE stack is closely aligned with dominant Web services standards. This is an important factor to ensure the success of this stack in the nascent and fragmented Web services landscape.

Besides existing support for a host of Web services standards such as SOAP, WSDL and UDDI, the J2EE stack has three emerging dimensions of conformance -- JAX-RPC, interoperability support and emerging Web services standards.

JAX-RPC -- The cornerstone of the Java APIs for Web service support is JAX-RPC. This interface serves as the basis of all SOAP-related calls within the Java stack. JAX-RPC provides a set of standard APIs for XML-based RPC in Java with the following developer benefits:

* Portable and interoperable Web services.

* Ease of development of Web services endpoints and clients.

* Increased developer productivity.

* Support for open standards such as XML, SOAP and WSDL.

* Standard API developed under the Java Community Process.

* Support for tools.

* RPC programming model with support for attachments.

* Support for SOAP message processing model and extensions.

* Secure Web services.

* Extensible type mapping.

Interoperability support -- WS-I is an open industry organization chartered to promote Web services interoperability across platforms, OSs and programming languages. The WS-I Basic Profile is an outline that specifies how Web services components can be used together to compose a Web service.

Sun was a late entrant to this organization (joining in October 2002) and was elected to the Board in April 2003. However, Sun has now thrown its full weight behind the Basic Profile. The December update to the J2EE 1.4 spec will include full support for the WS-I Basic Profile. This will ensure that the JAX API associated with Web services will result in Web services that are interoperable with other WS-I-conformant Web services platforms.

Emerging Web services standards -- There is tremendous impetus within various standards bodies to finalize various standards around advanced Web services. These include business process standards like BPEL4WS, WS-Choreography and ebXML, as well as standards around security and Web services management.

Various players in the J2EE arena are making important contributions to the J2EE stack via the Java Community Process (JCP). These contributions ensure that the J2EE stack is kept current vis-à-vis emerging Web services standards. Notable among these standards are JSR 109 (Implementing Enterprise Web Services), JSR 157 (ebXML CPP/A APIs for Java), JSR 183 (Web Services Message Security APIs), JSR 196 (Java Authentication Service Provider Interface for Containers), JSR 207 (Process Definition for Java), and JSR 208 (Java Business Integration).

A JSR of particular interest for this article is JSR 109, which addresses the need for a standardized format for the deployment, management and access of Web services. Per the specification, the following areas are addressed:

* A client-side programming model that suggests details for J2EE applications on how to access Web services, just as they would any remote object.

* A server-side programming model that suggests details on how Web services can be implemented as Servlets and Stateless Session EJBs and their respective life cycles.

* Web service deployment and deployment descriptors that will be used by the J2EE server to provide details on how Web services may be deployed.

J2EE Web services: Advantages

J2EE Web services represent an exciting and emerging software applications trend. Benefits of J2EE Web services include:

1) Many similarities in the development and runtime life cycle between J2EE and Web services. Both are self-describing packaged components deployed to and managed by a container. Both require lookup services for discovery and enable interaction by remote clients. Extending J2EE facilities to include Web services is evolutionary and therefore only natural.

2) A majority of IDE tool vendors have included support for Web services in their popular Java-based IDEs. With such tools, developers can generate, package, discover and deploy Web services using these IDEs, just like they would to a Java component. This leverages the developer’s existing knowledge of Java and the tool.

3) J2EE has mature design, development and management tools. Developers can leverage and expose an existing Java component, such as a Java class or Session EJBs managed by the J2EE container to a Web services client. They can also manage the entire life cycle of Web services with a SOAP engine that can be plugged into a Servlet engine, as well as other development tools that Java technology offers.

4) Ability to share services available in J2EE. Java clients can leverage JNDI services in the J2EE server for lookup.

5) Inheritance of features -- such as reliability, security and performance from a mature J2EE application server product.

6) Increase in productivity, and reduced retraining and development costs.

7) Built-in functions. Most J2EE servers and IDE tools have built-in functions for the development, description, publishing and invocation of Web services.

Life cycle of J2EE Web services

J2EE apps consist of software components. So what is a J2EE component? A J2EE component is basically a self-contained functional unit of software that can be utilized by a J2EE application and interacts with other software components.

It is thus not far-fetched to think of Web services as software components that share common creation and consumption strategies with J2EE components. Web services components have a lot in common with J2EE components as far as their life cycle is concerned.

The J2EE platform defines the following distinct roles in the application development and deployment life cycle: J2EE product provider, application component provider, application assembler, deployer, system administrator and tool provider. Many of these roles have an overlap in the world of Web services development and consumption. For example, you can find roles such as the Web services provider, Web services assembler, Web services deployer and tool provider, which are each very similar to roles in J2EE.

Although the details of implementations may vary, a generic mechanism to support J2EE Web services within a J2EE app server can be generically depicted.

The core components and operations center on the publishing, discovery and interaction of a well-defined service. Actions involved in a Web services life cycle include:

* Publishing the WSDL of the Web service to a registry.

* Discovery of the Web service by the client from the registry.

* Invocation of the Web service by the client.

* Binding the request into a SOAP XML message. * The SOAP call made by the client to the SOAP Servlet.

* Processing of the request by the SOAP Servlet and sending of the Message Oriented Request and Response to a Java class and Session EJBs through Java XML binding.

J2EE Web services -- Current vendor landscape

This section provides a synopsis of what major J2EE application server vendors such as BEA, IBM, Oracle and Sun are doing as far as providing Web services support. It also deals with Axis, the open-source SOAP engine from Apache. Most of the material presented in this section has been compiled from material available on each respective vendor’s Web site.

Apache Axis: The open-source SOAP engine -- Apache has been the leader in open-source SOAP engine development, with Axis being the third generation of Apache SOAP. Apart from being a SOAP engine, Axis is also packaged with a standalone server that can be plugged into Servlet engines such as Tomcat, which has a WSDL processor and a WSDL code generator. It fully supports SOAP 1.1 and some features of the new SOAP 1.2, and is much more flexible and configurable than the earlier version.

Axis has made a number of improvements over the old versions:

1) It employs the use of a SAX Parser for faster performance.

2) Its flexible architecture gives a developer the freedom to insert extensions into the engine.

3) It provides a set of flexible and open interfaces.

4) It supports component-oriented deployment.

5) It supports WSDL 1.1.

6) In publishing a Web service, Axis supports a Java Web Service (JWS) file that can be published without compiling the Java source code. This instantly transforms Java source files into being Web services-ready. With JWS, Axis automatically locates the file, compiles the class and converts SOAP calls correctly into Java invocations of the service class.

7) Axis also supports Web Service Deployment Descriptor (WSDD) details that enable the aggregation of all deployment options and parameters in the file.

BEA WebLogic Server 8.1 -- BEA’s support for Web services is built on an extensible, standards-based application infrastructure, the BEA WebLogic Enterprise Platform, which builds, deploys, manages and integrates enterprise-class Web services. Whether you are a J2EE expert using an IDE of choice (or text editor) leveraging BEA WebLogic Server 7.0’s Web services utilities, or a developer who prefers event and property sheet development provided by BEA WebLogic Workshop, you can build enterprise-class Web services that use standard J2EE components, such as stateless session EJBs, message-driven beans and JMS destinations “under the hood,” and that automatically inherit all the J2EE benefits provided by the BEA WebLogic Enterprise Platform.

BEA WebLogic Enterprise Platform’s Web services architecture fully interoperates with other leading vendors’ production Web services implementations. BEA WebLogic Server 7.0 provides a new set of “utilities” and runtime capabilities to build, expose and access Web services, shielding developers from requiring additional expertise in XML, SOAP and WSDL. BEA WebLogic Workshop allows app developers to create, test and deploy enterprise-class Web service apps on the BEA WebLogic Enterprise Platform. Supported by an enterprise-class runtime framework, BEA’s WebLogic Workshop was developed specifically for Web services.

SunONE Application Server 7 -- SunONE Application Server 7 is the first application server to be an exact representation of the J2EE Reference Implementation. It integrates the Java Web Services Developer Pack, including all the Java XML APIs, and provides the runtime support for mapping these APIs to underlying XML technologies, such as SOAP. Applications that access a UDDI registry through JAXR, or that exchange document-oriented messages with a server through JAXM, or that process XML documents returned by a Web service, can be deployed on SunONE Application Server 7. Support for WSDL is also provided. You can think of SunONE Application Server 7 as part of an integrated “end-to-end” Web services platform. It integrates with the SunONE Portal Server, the SunONE Directory Server and the SunONE Integration Server.

IBM WebSphere Application Server -- IBM WebSphere Application Server’s Open Services Infrastructure allows companies to deploy a core operating environment that works as a reliable foundation capable of handling high-volume, secure transactions and Web services. The IBM WebSphere Studio Application Developer, IBM’s core development environment, helps you to optimize and simplify Web services development by offering best practices, templates, code generation and a comprehensive development environment. It also enables the creation of J2EE and Web services apps with integrated support for Java components, EJB, Servlets, JSP, HTML, XML and Web services in one development environment.

Oracle9i Application Server -- Oracle’s J2EE Web services support is carried out in two areas: First, for the development and deployment phase, Oracle9i JDeveloper offers end-to-end support for modeling, developing, testing and debugging Web service components. Second, JDeveloper has a set of Web services wizards that can be used to build and deploy enterprise Web services, such as the SOAP Server Connection, UDDI Registry Connection, Web Service Stub/Skeleton, WSDL File, Java Web Service, JMS Web Service and the PL/SQL Web Service. The Oracle9iAS runtime architecture has built-in support for J2EE-based Web services in its SOAP container. The environment allows for the development and deployment of Web services using J2EE artifacts. It also provides the essential features of describing, publishing and invoking a Web service. The Oracle9iAS Web services runtime architecture includes a Servlet entry point, packaging and deployment options, and server skeleton code generation for Web services.

Built around Apache SOAP, Oracle9iAS SOAP has a number of enhancements based on the strength of its J2EE server, and a set of utility tools. For instance, ServiceMgr is an administrative utility that deploys and un-deploys SOAP services. Clustering the Oracle9iAS Container or the Oracle Container For Java (OC4J) can place two or more machines of similar configuration into an Oracle9iAS cluster. The Oracle9iAS infrastructure has facilities for ensuring that files on machines remain in-sync. Web services that involve the use of Oracle9iAS can take advantage of this feature.