Web Service Design Methods

Classically, web services are created using one of two methods, typically referred to as bottom-up or top-down. Using the bottom-up approach, the developer writes java classes (usually in the form of EJBs, or Enterprise JavaBeans) that perform certain business functions then abstracts the design up into a Web Services Description Language (WSDL) document, which is a high-level XML document that is used to describe the web service. It is this document that might be used in a Universal Description, Discovery, and Integration (UDDI) registry, which is a directory used to advertise the availability of web services.

On the other hand, the top-down approach begins with a WSDL document that is created by a business analyst or architect. From the WSDL and its associated XML schemas the developer creates java classes that implement the schema objects (usually in the form of Apache XMLBeans or Java Architecture for XML Binding (JAXB) classes) and then writes web service methods on top of those classes that implement the business operation. While there is hot debate over which design method is best, suffice to say that there are very good reasons to use one method over another. For example, if the system running the web service does not already have its business objects and logic represented by EJBs, then the top-down approach is simpler and quicker to implement.

Modifying OracleAS Libraries

In OracleAS 10g, a web service is installed as an Oracle Container for J2EE (OC4J). Because each OC4J is a discretely running program within the application server, it is possible to use JAX-WS on a single OC4J without affecting the integrity of other web services running on the system.

First, the JAX-WS java library files must be installed as shared libraries. In addition, if the JAXB java classes will be used to convert XML schemas described in the WSDL to java classes then an XML transformation library will be necessary as well; for example, Saxon. Implementing these as shared libraries means that the same files may be used by multiple web services in multiple OC4J instances without reloading the libraries into server memory more than once.

Second, the new OC4J must have several Oracle libraries de-registered so they do not conflict with the JAX-WS software. The easiest way to do this is to deploy the web service with a deployment plan. Whatever method is used, the following default Oracle libraries must be de-registered: oracle.jwsdl, oracle.ws.client, oracle.ws.jaxrpc, and oracle.xml.

Summary

Although the removal of default Oracle libraries will make unavailable a few of the Oracle web service enhancements, the transition from JAX-RPC to JAX-WS web service technologies may be advantageous in certain situations. In the future, expect to see Oracle combine the standard java application server features of its WebLogic Suite, which already supports JAX-WS, with the enhanced administration features of the Oracle Application Server software.