Special Cases You can come across many
issues, which can't be categorized in a particular type of issue like
the ones listed above. Such issues might be because of some problem in
the configurations of a service, or client, or might also be because of
some bug in a product. For example, there's a special problem between
WLS 9.0 and WCF Feb 2006 CTP.
When a client running in WLS 9.0 calls an operation defined in a WCF
Feb 2006 CTP service using WS-RM, the WLS requires at least one
"two-way" (Request-Response or Solicit-Response) operation to be
defined in the WCF service. Otherwise, WLS can't use WS-RM for
communicating with WCF. The "two-way" operation is required even if the
WLS client is only calling "one-way" operations in the WCF service.
To understand this special problem, you have to know the kinds of
messages that get exchanged in a typical WS-RM-based communication,
which is shown in Figure 2:
According to the WS-RM specification, a source end-point sends a
message with a <CreateSequence> element to a destination
end-point to start a reliable session. The destination end-point
responds with a message having a <CreateSequenceResponse>
element. When the destination end-point is deployed using WCF CTP, WCF
CTP sends the message with a <CreateSequenceResponse> element to
the location that's provided in the <ReplyTo> element (defined in
the WS-Addressing specification), which is present in the header of the
CreateSequence message. Whereas, when WLS 9.0 hosts a destination
end-point, it sends the response message to the location provided in
the <AcksTo> element (defined in the WS-RM specification), which
is present inside the <CreateSequence> element of the
CreateSequence message.
When a WLS 9.0 client sends WS-RM-based messages to a WCF CTP service
and there's no two-way operation defined in the service, the
<ReplyTo> element in the CreateSequence message sent by WLS
client contains the URI for an anonymous end-point (a well-known URI
defined in WS-Addressing) as given below:
<wsa:ReplyTo xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
The WCF CTP service uses the address provided in the
<ReplyTo> element to send the response message with the
<CreateSequenceResponse> element. Because the anonymous end-point
address provided here is used to indicate no response processing, no
CreateSequenceResponse reaches the client and hence a reliable session
can't be initiated. However, when a WCF CTP service has at least one
two-way operation defined, WLS 9.0 fills the <ReplyTo> element of
the CreateResponse message with the valid URI and hence a reliable
session can be initiated successfully.
Such problems are difficult to identify and can be found only through
careful troubleshooting and reading the information available in the
product documentation and on the Internet.
Development Best Practices
The WS-*-based
development is a complex activity because of all of these issues. You
can follow the best practices given below to reduce the complexity to
some extent.
1. Start implementing using only the basic Web Services specification.
If your Web Services aren't interoperating at the basic level,
implementing WS-* specifications will only make the issues harder to
identify.
2. For basic Web Services specifications, always use WS-I's Basic
Profile 1.0 or 1.1 guidelines. Most of vendors provide Basic
Profile-compliant products and have tested those products
comprehensively for interoperability. Hence, by following the Basic
Profile, you can easily avoid the issues that WS-I has already
addressed in the Basic Profile. You can verify if your Web Services are
following the Basic Profile by testing your WSDLs in WSDL testing
tools. There are many free tools, including those provided by WS-I, as
well as commercial ones, available to test WSDL.
3. Once your Web Services are interoperating with basic specifications
and BP1.x, start implementing the required WS-* specifications one by
one. If you implement all the required specifications (e.g.
WS-Security, WS-RM, and WS-AT) at the same time and come across an
issue, it would be difficult to identify the culprit.
4. Although this is a very common best practice that can be applied to
any scenario, I feel it's important to mention here. Search on the
Internet for other findings and samples. As WS-* specifications haven't
matured, the documentation for the available products is either
insufficient or incorrect in some areas. In such a situation, it
becomes important to learn from others' experiences. Look at the blogs
of a vendor's key employees involved in interoperability, post into
forums like ws-builders or soapbuilders (described later), or just do a
simple Web search. Many times, you'll find someone who has already
encountered the issue you're facing and he or she can either help you
or can tell you that the problem can't be addressed in the current
version of a product.
Troubleshooting Best Practices
Most of
the time you won't get successful interoperability in the first try.
You can follow the troubleshooting best practices given below to
identify the root cause of the issues you come across:
1. When a problem occurs, identify the step where the problem is
happening. The exact process followed to make a call from a Web Service
or a client to another Web Service may be different from one product to
the other, but the high-level steps remain the same:
a. Get the WSDL of the target Web Service that the client needs to call
b. Generate a "stub" or "proxy" using various tools available in Web
Services toolkits or client development environments (e.g., Add Service
Reference in Visual Studio 2005).
c. Use the generated proxy in the client code to send messages (or make calls) to the target Web Service.
The problem could exist in any of these steps. There could be
instances where the WSDL of a target service isn't compatible with your
client environment. The examples of such scenarios and their solutions
have already been explained.
When the problem exists in the proxy generation, you can look into the
output of the tool used for generating the proxy to find out the exact
error(s). If the error description doesn't provide much help, you can
try other best practices described in the following bullets.
1. When the problem happens in the messages exchanged, you need to
analyze the actual SOAP message exchanged to find the problem and fix
it. Many vendors provide tracing tools with their products that
generate traces of all messages exchanged between two communicating Web
Services. For example, Microsoft provides a TraceViewer tool with WCF
that helps you easily view, group, and filter traced messages. You can
also use the tools that provide traces for TCP packets such as the TCP
Monitor provided with Apache AXIS. To analyze the messages, you should
have adequate knowledge about the specification you're implementing.
You should know the different kinds of SOAP messages, their structure
as well as sequence, that get exchanged between the two interacting
components implementing that specification. For example, to diagnose an
issue in a WS-RM implementation, you have to know the different types
of messages that are exchanged during a reliable session:
CreateSquence, CreateSequenceResponse, Sequence,
SequenceAcknowledgement, etc. as shown in Figure 2.
In this step too, if the message analysis doesn't provide much help,
you can try other best practices described in the following bullets.
2. Try implementing a WS-* specification between two Web Services
developed on the same product. Do this on both the products you're
trying to interoperate. If you're successful then take the same
configurations to implement the specification between the Web Services
developed on different products. By doing this you can identify if the
issue lies in a particular product or in the general configuration of
that specification. When both of these options are ruled out, you can
look for other interoperability-related issues.
3. When you can't identify the reason for an issue that exists while
implementing a WS-* specification between your application's Web
Services, try implementing the specification between simple "hello
world" types of Web Services. This will help you separate business
logic-related problems from the specification's configuration-related
problems. If that succeeds then apply the same configurations to your
application's Web Services.
Web Services Interoperability Resources
There's a
huge amount of information available on Web Services interoperability
and WS-* specifications. I provide some selected resources and brief
descriptions here that I found useful.
Community Groups
- SOAP Builder Yahoo Group:
http://groups.yahoo.com/group/soapbuilders/
It's a community group to discuss cross-platform implementations and
interoperability issues primarily about core Web Services
specifications. You'll find messages from employees of key vendors such
as BEA, IBM, and Microsoft who are involved in building Web Services
and SOAP-based products. You'll find different types of messages:
general discussions, announcements of new events (such as Plug Fests),
product versions and features, and clarifications and solutions to
problems that product consumers have.
- WS-Builders Yahoo Group:
http://groups.yahoo.com/group/ws-builders/
It's another community group similar to the SOAP Builders group, but focused more on WS-* specifications.
SOAP Interoperability Labs & Plug Fests
As interoperability gains in importance, industry vendors are getting
together to make their products interoperate. Interoperability labs are
examples of industry's effort towards interoperability. In these
events, many vendors get together to test their products (application
servers, Web Services frameworks, SOAP toolkits, etc.) with the
products of other vendors.
Microsoft hosts similar events called WCF Plug Fests. At these events
Microsoft invites all industry vendors to its campus for a three- or
four-day workshop, where vendors test their products against WCF.
You can get very useful information from such events that may include
interoperability scenarios descriptions, scenario testing scripts, live
end-points, and sample WSDLs. Here are links to get information about
the past events:
Vendor's Home Pages on Web Services Specifications & Interoperability
Here's a list of a few vendor Web pages that are dedicated to Web Service specifications and interoperability
Summary Web Services have evolved over the past
few years and their support is now considered part of the core platform
of most SOA-based solutions. With this evolution, industry is coming up
with new specifications to support advance requirements like security,
reliability, and transactions. These specifications are commonly
referred as WS-* specifications and are relatively new compared to
basic Web Services specification such as WSDL, and UDDI. The products
providing support for the WS-* specifications haven't matured
adequately. As a result, achieving interoperability using them is
relatively difficult. However, if you select the products after a
detailed analysis about the specifications they support and you follow
the guidelines listed in this article, you can achieve an interoperable
implementation in much less time.
There are a variety of applications that supp...
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
