Web ٍٍServices Top-down development

In top-down development, both client-side and server-side developers use WSDL (the top) to produce the artifacts (the bottom) necessary for their respective environments. Top-down development is an increasingly common practice for at least two important reasons. First, in many cases, the WSDL describing a service is available publicly in some registry (like a UDDI). With the tools available today, the server-side developer can start with the WSDL to define new implementations of the portType defined by the WSDL, and the client-side developer can start with the same WSDL to develop a client of the service. Second and even more important is the industry trend towards defining interoperable data standards using XML Schema Definitions (XSD). These industry standard data types defined using XSDs can be ideal for defining new Web services interfaces. Therefore, the top-down development pattern starts by identifying or developing XML schema relevant to the domain of the Web service, and then creating a WSDL for the Web service. Development of both the client and server side can then begin in parallel. The top-down development pattern encompasses the following development steps :

1. 1.     Identify or create an XML schema relevant to the problem domain that describes the input and output data types for Web services operations. The data types should be defined in one or more schema (.xsd) files. You can use standard schema development tools to create or modify the necessary schema. 
   2.     Create a new WSDL file that contains a types element that imports (not includes) the schema files from Step 1 and contains a portType that in turn contains operation elements referencing the data types defined in the imported schema as input and output parameters. The recommended style for creating this WSDL is wrapped-document literal to be WS-I compliant and for maximum interoperability with .NET environments. Sophisticated enterprise application development tools like the WebSphere Studio family include WSDL editors that provide tremendous assistance when creating WSDL documents.
   3.     Generate the provider-side and requester-side JAX-RPC artifacts. Note that these steps, described below, can be done in parallel by two different and independent teams. The implementation platform on each side can also be different.
   3.1. Use a Web services tool to generate the provider-side artifacts. A spectrum of tools exists, ranging from the command line driven WSDL2Java from Apache Axis or WebSphere Application Server to the Web service wizard in the WebSphere Studio family. The tools generate a Java class (a DTO) for every complex type defined in the WSDL types element. They also generate either a POJO or a stateless session EJB skeleton service implementation that has a method for each operation included in the portType. The tools may also generate any other provider-side artifacts required by JAX-RPC to deploy the implementation as a Web service in an application server. Examples of these artifacts include the webservices.xml file. There may also be other application server dependent metadata files generated by the tools. After running the tool, the serer-side developer must implement the appropriate business logic to fulfill the semantics of the operations in the service definition. 
   3.2.    Use a Web services tool to generate the DTOs, SEI, and client stub implementation for the service requester from the WSDL. This procedure is exactly the same as Step 4 in the bottom-up pattern described above. As before, the client-side developer must use the stub to invoke the service from the client-side business logic. 

• Evaluation of the top-down approach

The advantages of the top-down approach are:

It supports the use of existing standards-based XSD types. See Listings 4 and 5 above for an example.

When new schema types are developed for the current service, they can be easily reused for other services by simply importing the newly developed XSD into the other services.

It allows for parallel and independent development of client-side and server-side.

Incremental changes to the service are best managed by changing the WSDL itself. Since the WSDL is the common interface (or contract) for both the client-side and server-side, these changes can be easily managed so they don't affect interoperability with existing requesters or providers.

The tools will use the namespaces defined in the WSDL to determine the package names of the generated JavaBeans (or DTOs). Most of the tools support namespace to package name mappings. The advantage with starting from WSDL is that both the client-side and server-side can use different package name mappings without affecting the access of the service.

The disadvantages of the top-down approach are:

It requires knowledge of WSDL and XSD because both must be manually generated or manipulated. Even the sophisticated tools that exist today to generate WSDL and XSD require detailed knowledge of the structure of WSDL and XSD to ensure proper compliance with standards and optimal performance.

Tools support for the top-down approach has generally been more limited than the support for bottom-up, but that support is improving. For example, many tools do not properly handle WSDL files that import schemas instead of embedding them; and fully automated support for producing wrapped-document literal WSDL is lacking. The most common problem with importing schemas is that the XSDs must exist in the same directory as the WSDL file and relative path names don't always work.

It's important to note that you can use the bottom-up process to produce the WSDL that drives the top-down process. For example, you can create the WSDL published in a UDDI registry using the bottom-up process. We recommend that when doing this, you use tools to separate the schema in the WSDL types element from the rest of the definition so the schema can be reused. The key point in any top-down approach is that once the WSDL is produced (either manually or generated from code), it becomes the master interface that is used by both the requester and provider from that point on.