Re-consider "code first" Web services

Have you started developing SOAP Web services? If so, then you have two development styles to choose from. The first is called "Start with WSDL (START-FROM-WSDL)" or "contract precedence (contract first)", which involves building a WSDL service description and directly associating the XML schema for data interchange. The second is called "Start with Code (START-FROM-CODE)" or "code First", which involves inserting the example service code into the framework of your choice and generating the wsdl+ schema (schema) from that code.

Whichever development style you use, the ultimate goal is the same-you want your service to have a stable wsdl+ pattern definition. This goal is especially important when you are working in an SOA environment. SOA requires a loosely coupled service, a fixed interface between services, and a separation from implementation. XML Web Services create an important foundation for implementing SOA, largely because WSDL and schemas allow you to specify the exchange of XML messages used by a Web service in a platform-neutral way. If the WSDL and schema are not stable, the service can only be used by clients that are directly or indirectly controlled by the service provider-this is not SOA.

"Start with Code" issue

The idea of "starting with code" to develop a Web service is opposed by many pundits in the field of Web services and SOA. They feel that "start with code" binds the XML message structure to a specific implementation, which discards the entire purpose of using WSDL and schemas. For the initial form of "code start"--soap encoding mode (SOAP encoding scheme)-indeed, it is widely used to support rpc/encoded. Using SOAP encoding, the XML schema is generated directly by the service provider's application of the data structure, and client code uses the resulting data structure copy to work. This automatic conversion between the data model and XML makes rpc/encoded popular in early soap-but it is also an important reason that this style was later abolished. It means that every time you change your service data structure, the pattern changes, and the client will need to regenerate their code with the new schema.

Figure 1. " SOAP encoding started by code

In addition to creating tight coupling with SOAP encoding, there are some drawbacks to XML data representation and schema definition. SOAP encoding is an XML serialization algorithm for object graphs, defined in a separate way in programming languages. Since it is a serialization algorithm, there is no flexibility in the resulting XML structure-you apply this algorithm to your data structure, and what you get is the SOAP encoding for those structures. Unfortunately, the serialization rules used cause the XML schema to be of little use to other rpc/encoded message exchanges (including document Checksums). The serialization format also leads to poor efficiency because of the cost of the referencing structure, excessive run-time printing, and the use of child elements for all components (instead of using attributes where appropriate).

Most of these issues apply to technologies that are only serialized between data structures and XML. But "Start with code" does not imply that the data model must be exposed through direct serialization. With some form of data binding, the current Web service stack typically supports flexible transformations between data models and XML. With data binding, you can maintain control of the XML representation of the data. That control means that your schema definition can be at least slightly isolated from the actual data model, and you can choose the XML representation that fits your data. With data-binding methods, most of the problems associated with SOAP encoding are no longer available.

"Start with WSDL" problem

The biggest problem with "start with WSDL", compared to working with code, is to use WSDL and patterns to define the cumbersome nature of work. Modern Ides are typically equipped with "smart" editors and powerful refactoring tools that make code changes easy. There are no equivalent tools for WSDL and schema at the moment. Even the most basic schema refactoring, such as converting local definitions to global definitions, is not supported by the mainstream WSDL and schema tools.

Because of the weakness of the tools, "Start with WSDL" also requires a solid understanding of WSDL and schema in order to achieve good results. If the tools available to developers are not based on standards, then the final WSDL and schema is often an ugly hodgepodge that makes the structure of services and data more ambiguous, rather than clearer. As far as the WSDL section is concerned, it is not difficult to understand it effectively, but the pattern is a different part. The Universal XML Schema recommendation (the full name of "schema") is at least as complex as most programming languages, and it takes a lot of effort to master it. Large organizations with specialized architectural teams can afford to hire or train model experts, but for smaller organizations, the complexity of schemas is a real barrier to service specifications that start with WSDL.

These "ease of use" issues apply even after developing the initial set of WSDL and schema definitions. The development of a service synthesis set is always an iterative process, repeated through specifications, prototypes, and test cycles. At each stage, the inconvenience of working with crappy tools can be a hindrance to development.

Make "Start from code" work

Currently, the available tools for "Start with code" to complete the service specification are far beyond the SOAP encoding model that is notorious for this type of development. They provide flexibility and scalability, enabling it to work with fairly complex data structures. Most importantly, they add a decoupling layer between the code-defined data structure and the corresponding XML representation.

Microsoft's. NET Framework and Sun's JAX-WS 2.0/JAXB 2.0 are two popular examples. Both use configuration information embedded in the source code (in the. NET is a property, in the JAX-WS/JAXB is labeled to control the data structure and XML conversion between. The controls provided by this inline configuration are limited, and usually equal to a detailed list of differences that differ from the default serialization selections. That means that XML does not have to be separated from the details of the data structure-for example, if you add a field to an object, it automatically becomes part of the XML representation, unless you explicitly list the domain to include-but it's much better than a purely serialization approach.

Figure 2. " The. NET and Jax-ws 2.0/JAXB 2.0 methods starting with code