8.4 Design guidelines

< Day Day Up >

As the solution was being designed, the following topics were considered.

SOAP messaging style

SOAP provides support for both RPC style Web services and document-style Web services. In RPC style, Web services are invoked using remote method calls. In document-style messaging, Web Services are invoked by sending a complete well-formed document describing the task to be performed, and possibly, some parametric data.

These are some advantages of SOAP RPC-based Web services:

They are simpler to develop than SOAP message-oriented messaging.
They use a higher level API.
They support strong typing: all calls must conform to the method signature.

The disadvantages of RPC-based SOAP messaging are:

Higher coupling between the Web service requester and provider because the requester to provider binding includes both methods and parameters.

On the other hand, when using document-style Web services, the XML document is arbitrary. This style is more flexible and can be used to send one-way messages without needing a response (unlike RPC-style) but involves more work for the developer.

Prior to the Web Services Gateway provided with IBM WebSphere Application Server V5.0.2, RPC-style SOAP messages were required. With V5.0.2, support for document-style messages was added. If you are using the Apache SOAP Channel, then the SOAP message format must be RPC style. To handle Document style SOAP messages, use the SOAP/HTTP channel (which supports both RPC style and Document style SOAP messages). We used the RPC-based mechanism in our sample solution.

SOAP encoding style

In addition to the messaging style, the SOAP encoding style should be considered. Message parts can be encoded using encoding rules ("encoded"), or may reference a concrete schema definition ("literal").

WS-I has stated a preference for the use of literal, non-encoded XML.

SOAP caching

Using WebSphere Application Server dynamic caching to cache SOAP messages can significantly reduce the overhead of Web services. A Web service is a candidate for caching if its requests can be grouped into classes based on identifiers, and if the Web service's responses do not contain arbitrarily changing information based on the system state or time.

Caching a SOAP message is not as easy as putting it in a HashMap. You need to determine what makes two SOAP request identical. Only then can a caching framework determine when to send a client a cached response instead of letting the request propagate further into the system. To decide if two SOAP request are identical, you could have to look at the SOAP Body, or at the SOAP Body and some combination of SOAP header values.

Message optimization

The performance of an application based on Web services is affected by three factors:

Network transmission time.
The time it takes to handle the messages, including XML parsing, flow management, invocation of the service and the encoding of the final response
The time the service itself takes to execute

The two first factors can be improved by optimizing the number, size, and structure of the messages you use. For example:

Don't pass parameters that you don't need.
Don't use two or more invocations when you can do the same operation implementing a more complex service. A good example for this could be: Instead of repeatedly using an operation that returns the price of a product, implement a service that returns the price for a list of products.

The third factor can be improved using a good caching system, as discussed previously.

Security

Security is certainly important in an intra-enterprise environment, but becomes crucial in an inter-enterprise environment. General security guidelines are:

Use https when invoking external services.

The Web Services Gateway can invoke Web services that include https:// in their addresses, if the Java and WebSphere security properties have been configured to allow it.
Protect your services from non-authorized access.

Web Services Gateway provides a basic authentication and authorization mechanism based upon the broader security features of WebSphere Application Server. For more information, see "Basic authentication and authorization facilities" on page 211.

You can also use the WS-Security support of the Web Services Gateway to implement authentication and authorization controls.
When possible, implement security solutions based on common specifications, like WS-Security, facilitating interoperability.

You can configure the gateway for secure transmission of SOAP messages using tokens, keys, signatures and encryption in accordance with the Web Services Security (WS-Security) draft recommendation.

Security issues are discussed more in "Security" on page 211.

SOAP transport protocol

In principle, SOAP is transport protocol independent and can therefore potentially use a variety of protocols (such as HTTP, JMS, SMTP, and others) to connect the Web service requestor and the provider.

HTTP is currently the most popular transport protocol for SOAP. The reasons for this mainly result from the following advantages:

HTTP is the de facto standard on the Internet
HTTP is wide spread
HTTP is supported from most programming languages
HTTP has a simple extension for security, HTTPS
HTTP needs no complex infrastructure

But there are also some important limitations:

HTTP is optimized for use in browser and end-user scenarios
HTTP is a stateless communication protocol
HTTP does not provide reliable communication
HTTP establishes a point-to-point connection

These limitations are usually acceptable for human-to-machine communication using a Web browser. This may not be valid when switching to machine-to-machine communication. The requirements in machine-to-machine communication are usually more complex and other transport protocols may be more suitable.

For example, if you need assured, once-only delivery, message-oriented middleware may be more suitable. In Java you can use Java Messaging Service (JMS) with IBM WebSphere MQ. The advantages are:

Reliable messaging
Option of asynchronous communication

On the other hand, you have the following disadvantages:

More complex infrastructure
Not generally available for all potential customers
Message-oriented middleware skills are necessary
At this time most vendors only have limited support for SOAP over JMS

With the increasing adoption of Web services, the portfolio of supported transport protocols will also increase.

We use the HTTP transport protocol in our sample solution because HTTP can provide the connection we need between source application and target application without the need for added infrastructure.

In addition, HTTP is easier to deal with in an inter-enterprise situation. It is common to allow the HTTP protocol through firewalls and simplifies connectivity to external partners.

Apache SOAP versus SOAP/HTTP channels

The Apache SOAP channel and the SOAP/HTTP channel both support SOAP applications that are SOAP 1.1 compatible (for example Apache SOAP 2.3 and Axis SOAP 1.0). So if you have an application that uses a production-supported Axis 1.0 SOAP stack, generating SOAP 1.1, then it can use either channel.

If you are using the Apache SOAP Channel, then the SOAP message format must be RPC style. To handle document style SOAP messages, you must use the SOAP/HTTP channel (which supports both RPC and document style SOAP messages).

If you deploy Web services that pass attachments in a MIME message, then these Web services can only be accessed using the SOAP/HTTP channel.

Use of filters

Filters are session beans than intercept requests that arrive at the Web Services Gateway or responses than leave it. Filters can perform almost any task, and they have access to the context and to the message that is intercepted. They run in a separate enterprise application, so when building a filter, you have to consider the following Quality of Service issues:

Performance
Availability
Security
Standard compliance

For example, if you use the clustering feature of WebSphere Application Server for to enhance the Web Services Gateway performance and availability, take similar measures for the filter application.

Don't create filters that do a lot of tasks. Instead, create multiple filters that each perform one simple task (for example, logging, transforming content, routing, etc.). Then, associate all the filters to the service you need. This facilitates the development, reduces the complexity of the filters, and promotes the reuse.

< Day Day Up >