Web ٍٍServices Bottom-up development

The first generation of Web services tools for Java was targeted at exposing existing code as Web services. This approach is called bottom-up because the starting point is code that is being abstracted into an interface definition and subsequently exposed as a Web service implementing that interface. This pattern is familiar to many Web services practitioners and is well-supported by even the latest generations of Web services tools. The bottom-up development pattern encompasses the following development steps:-

1. Identify or create JavaBeans that represent the data types of the input and output parameters of a service interface. These can be existing or new JavaBeans. Because these JavaBeans are used to transfer data to and from the service, they are sometimes termed Data Transfer Objects (DTOs). Note that only the attributes that follow the JavaBean pattern (such attributes have a getter method and a setter method) are exposed in the Web service interface. You can use standard Java development tools to create or modify the required JavaBeans. 
2. Identify or create a Java class, either a Plain Old Java Object (POJO) or a Stateless Session EJB, that becomes the Web service implementation. The Java class must include the methods to be exposed in the Web service interface. These methods must use the DTOs from Step 1 as the input and output arguments. Note that the methods implementing the business logic exposed in the Web service must be marked as public. Again, you can use standard Java development tools to create or modify the Java class, as necessary. This class does not have to adhere to the rules for a JavaBean. The class may throw any exceptions in the exposed methods, as necessary.
3. Use a Web services tool to generate the Web service implementation from the Java class. There are several candidate tools of varying levels of sophistication, in that they may produce all or only some of the artifacts required by JAX-RPC to deploy and use the Web service. These tools all generate a WSDL document based on the signature of the Java class from Step 2. The tools create a complex type definition embedded in the WSDL types element for each data type (JavaBean) used in the public methods in the Java class. They also create an operation element in the portType for each public method in the Java class. The tools may also generate any other provider-side artifacts required to deploy the implementation as a Web service in an application server.
4. Use a Web services tool to generate the artifacts for the Web service requester using the WSDL generated in Step 3. The tools generate a Java class (DTO) for every complex type defined in the WSDL types element, a service endpoint interface (SEI) that has a method for each operation included in the portType, and a stub that implements the SEI that a client can use to send requests to and receive responses from a Web service implementation. The tools may generate other artifacts, depending on the nature of the requester (J2EE container or not) and the tool itself. The same tools that generate the provider implementation will typically have a requester version as well. Therefore, the same range of tools exists from the command line driven WSDL2Java from Apache Axis or Application Server to the Web service wizard in the WebSphere Studio Application Developer. 

• Evaluation of the bottom-up approach

The advantages of the bottom-up approach are:

It is a quick way to expose legacy implementations as Web services.

It requires little or no knowledge of WSDL or XML because the WSDL document is generated by the tools.

It has excellent tools support. In fact the sophisticated tools do all the work to create a deployable, executable Web service implementation on the provider side and all the work to allow a request to access the implementation on the requester side.

The disadvantages of the bottom-up approach are:

The generated schema defining the data types in the WSDL document derives only from the Java classes from the provider's environment and not from any standards-based schema (see Listing 3 above).

The provider-side data types may not be simple DTOs, in that they include additional business logic. Such logic can't be reconstructed on the requester side.

The generated schema is embedded in the WSDL, which makes reuse of the schema, perhaps in the definition of other Web services, more difficult. It is possible, of course, to extract the schema from the original WSDL document.

The development of the server-side Web service implementation and the client-side Web service requester can't proceed in parallel. The server-side skeleton and DTOs have to be developed before a WSDL can be generated that can be used to generate the client-side stubs and DTOs.

Incremental changes to the interface are more difficult to manage. For example, if the interface of the class that implements the service is changed and the WSDL is regenerated, more significant changes could occur in the WSDL, thus causing interoperability with existing clients to fail. The basic problem is that, on the server-side, the class implementing the service is deemed the master interface and, on the client-side, the WSDL provided by the server-side is the master interface. These two different masters can cause the interfaces to become out of sync and difficult to debug and fix.

The namespaces of the embedded schema types are typically generated from the Java package names of the server-side JavaBeans. Therefore, if the package names are changed, the namespace will be changed, which means the types are no longer compatible. Most of the tools allow a package to namespace mapping, but this must be explicitly set during the execution of the tool.