Java Web Services, part 1th: Development of Java Web Services in the coming year

2006 will be a landmark year for the development of Web services, especially Java Web services. The new third-generation framework is about to be unveiled, and these frameworks will provide better support for Doc/lit SOAP and potential performance improvements. At the same time, the fourth generation ws-* standards have finally begun to form a set of interoperable layers that extend SOAP and WSDL to support core enterprise requirements.

This article is part 1th of my Java web series, and I will discuss the current state of the following WEB services and the major changes that are about to occur in 2006, and will briefly explain how the new framework and technology relate and interact. The following articles will delve into many of these frameworks and technologies, hoping to give you an idea of the latest developments in the field and how they can help with your programming projects.

Background information

It has been more than six years since the SOAP 1.0 specification was published today. Before the SOAP specification was published, developers had already exchanged XML messages over Internet protocols, but the introduction of soap promised to standardize the technology and achieve better interoperability. SOAP also provides a variety of hooks (hook) mechanisms to facilitate expansion so that advanced infrastructure functionality can be added to enhance future XML message exchange. The WSDL specification was released shortly after SOAP was introduced, adding a standard representation of WEB service metadata. Major software vendors quickly saw the potential to combine soap and WSDL, and in the next few years soap Web services seemed to be an unstoppable development trend.

SOAP and WSDL Challenges

Despite the rapid rise of soap+wsdl across the industry, there are still problems in many ways that prevent SOAP from reaching the full success many people expect. The first aspect is interoperability. Although one of the most tempting important aspects of SOAP is its interoperability commitment, the real progress is not obvious. This was originally caused by the emphasis on the rpc/encoded style Web service (also known as the Rpc/enc), in which case the object model is serialized as XML and then reconstructed at the receiving end. This automatic serialization/deserialization feature makes Rpc/enc very easy to use (as long as it uses the relatively simple data structures it supports), but it can result in the generation of XML that cannot be used for any purpose. Worse, differences in language and platform support lead to a large number of incompatibilities between implementations.

The widely accepted WEB services best practices are now inclined to use the document/literal style (doc/lit) instead of the Rpc/enc style. In Doc/lit, the XML message format is defined by the XML Schema definition of the consortium. In theory, this should eliminate any problem with interoperability, because schema instances define the actual structure of the XML, and each platform is responsible for handling the XML appropriately. In practice, the degree of support for the extremely complex Schema standards of the world's standard is uneven, and other interoperability issues are brought about.

Earlier RPC/ENC interoperability issues and recent doc/lit interoperability issues will be exacerbated by a lack of awareness. For Doc/lit, the various frameworks support different schema-standard subsets, but do not list the missing features, making this particularly acute. Even if different frameworks claim to support specific pattern features, implementations are often incomplete, resulting in interoperability problems when using these features. Part of the reason for turning to doc/lit is the desire to take advantage of business or industry standard models. The design of such standard schemas is often not considered to be used in WEB services, so they often use features that the SOAP framework does not provide for good support.

Another problem with the SOAP Web service is the constant confusion between infrastructure expansion and basic SOAP processing-the layers of processing that can be applied on a range of WEB services. SOAP design runs easily add such extensions, but these extensions are usually only useful when they are standard supported by multiple frameworks. This requires collaboration across the industry, but is often difficult to do. Even the most basic extensions, such as attachments and security, will take several years to develop, but are still not supported by all frameworks.

The resistance of SOAP

The interoperability and standardization issues discussed in detail in the previous section limit the applicability of Soap Web services, and the SOAP framework itself is often complex and difficult to use. Limited advantages and potential complexity have led many developers to take a simpler alternative than SOAP. Most of the resistance to SOAP comes from aspects related to a technology called REST. Strictly speaking, REST is a standardized technique for the basic rules of HTTP protocols that can be applied to Web services. In practice, REST activity often holds normalization aside, and it contains everything that transmits an XML document on HTTP without using soap wrappers, essentially the same way as a direct XML document before SOAP occurs.

REST is far less ambitious than SOAP. REST is naturally limited to using HTTP as the transport layer (although it can be used for other transmissions in a similar way), while SOAP is theoretically independent of the transport layer (although it has so far been deployed only extensively using HTTP transports). REST does not include any way to add infrastructure extensions directly--but this restriction can be considered a trivial aspect until SOAP really begins to provide such extensions.

Because REST is not as functional as SOAP, there is usually no need to use any framework code to implement the client or server, so developers do not have to deal with the complexity of the framework. The inconvenient side is that the technology does need to implement HTTP and XML processing directly, but many developers are accustomed to dealing with these technologies. Dealing directly with XML can even be an advantage, because developers are more selective in this case than the choice provided by the SOAP framework.

So is it better to throw away SOAP and start using simpler REST? This may be a practical choice for many Web service application forms, so I'm not against the idea. However, there are many other applications (especially at the enterprise level) that require the infrastructure extension and transmission independence that SOAP promises. Moving to REST means that these applications will need to implement functions such as security, transaction processing, and collaboration directly, rather than providing these capabilities through the framework. Most enterprise applications will probably choose to avoid using WEB services altogether, rather than spend it.

But like in the movies, even if the future of SOAP looks really gloomy, there will still be new hope. This hope comes from the upcoming new generation of frameworks. The goal of these frameworks is to ultimately exploit the full potential of soap to make the implementation of a new SOAP Web service Application a reality, while significantly improving the interoperability of doc/lit Web services.