Chapter 8. Router solutions using Web Services Gateway 161
8.4 Design guidelines
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.
162 Broker Interactions for Intra- and Inter-enterprise
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.
Chapter 8. Router solutions using Web Services Gateway 163
? 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:
164 Broker Interactions for Intra- and Inter-enterprise
? 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
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.