RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Applying Design Issues and Patterns in Web Services

Although the model of Web service interoperability is straightforward, it introduces new development practices and methodologies that can be difficult to learn. However, it can be a short-lived hurdle if you recognize certain patterns to design issues.

reation of Web service applications is yet another complex task to add to the IT department's list. Experience suggests it is not enough to approach Web services development armed with documentation on just the underlying technologies, such as SOAP and WSDL. Developers must also study the design issues and patterns related to the domain they intend to implement. For example, someone must decide whether to use RPC or document style encoding methods or whether asynchronous communication must be considered.

Without knowledge of patterns, the designer won't apply these techniques, resulting in poor performance, poor scalability, and poor reliability, or the designer will reinvent the wheel, attempting to solve the problem with a new approach. Design patterns provide a set of reusable ideas that can speed up the design process because these ideas, as frameworks, can be leveraged.

There are several basic aspects of Web service design that, when mastered, make a successful project:

  • Managing interoperability
  • Understanding the lower-level transport models
  • Providing the appropriate security
  • Planning for deployment issues.
This article covers these basic design requirements and explores how well known design patterns can be applied to Web services. In fact, you'll see that modeling a Web service can leverage much of the development techniques that you have employed with current software development technologies and languages.

Standards Improve Interoperability
A fundamental aspect of Web service design is interoperability. For a company's Internet applications to be most effective, Web services must interface seamlessly internally and, potentially, externally with partners, suppliers, and customers. But, these entities may not have the same sophistication when developing their Web services, or they may have different XML representations of the same business data. With this in mind, interoperability must be designed into the architecture, not left up to chance.

If you've ventured into Web service development, you already know the building blocks for these services are SOAP (Simple Object Access Protocol), WSDL (Web service Description Language), and UDDI (Universal Description, Discovery and Integration). Figure 1 shows the relationship between these building blocks. This article will not cover the details of each of these technologies, but will delve into a few important characteristics that must be considered during Web service design. (See "Related Resources," left, for links to other resources on the Web services building blocks.)

Figure 1: Building Blocks. This graphic shows the relationship between SOAP, WSDL, and UDDI, the building blocks of Web services.
WSDL is the key to managing interoperability. It provides contracts for describing the interfaces to both new and existing applications. This allows multiple organizations to standardize on an interface to a service, without having to worry about the underlying implementation. Another benefit of using WSDL is that it is the focal point for many of the Web service tools on the market today. Most tools provide a way to automatically generate client code from an existing WSDL document. This can end up saving developers development effort because they don't need to write any of the SOAP messaging code.

Of course, SOAP is the layer that implements messaging between Web service components. As such, SOAP should be a transparent interoperability technology. Unfortunately, many SOAP implementations vary from the standard by either creating extended features or by only making a subset of the functionality available. With different levels of SOAP support, it makes it difficult for true interoperability. Clients wanting to use Web services that run on different platforms have to be aware of these issues and code accordingly. If all vendors complied with the standards, the client wouldn't have to be concerned about the underlying platform used.

Furthermore, interoperability between SOAP implementations can be difficult, as interpretations of the standard can diverge. But standards creation to resolve SOAP interoperability issues is being done by a number of working groups, such as SOAP Builders and WS-I. Today, however, developers are forced to create multiple variants of Web services to adequately interoperate with partners, which is expensive and labor intensive.

Also applicable to SOAP, specific Web services platforms may support an older version of a specification, which may not be interoperable with your clients. Choosing basic data types such as strings, integers, and standard array types can ease this problem, as the use of complex data types could limit what types of SOAP clients can talk with your service. Another best practice is to provide schema definitions for all data types. A schema definition provides a mechanism for defining the structure and content of an XML document.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date