Technologies and Standards for Service-Oriented

Architecture Project Implementation

© copyright IBM Corporation 2005. All rights reserved.
Table of Contents
Web services advanced technology topics
About this module 2
Introduction 3
Best practices for Web services (1 of 2) 4
Best practices for Web services (2 of 2) 6
WebSphere Application Server V6: Best practices 10
Interoperability best practices (1 of 3) 12
Interoperability best practices (2 of 3) 13
Interoperability best practices (3 of 3) 15
Versioning Web services 17
WS-Security versus traditional security mechanisms (1 of 3) 20
WS-Security versus traditional security mechanisms (2 of 3) 22
WS-Security versus traditional security mechanisms (3 of 3) 26
Web services management 28
Summary 33
References 34
Test your knowledge 35
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Web services advanced technology topics

Page 1
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

About this module

Overview
This module is designed to provide an overview of some of the Web services topics that often need to be
addressed when making implementation decisions. This module looks at these topics and how they can
be used to solve business and technical challenges encountered when designing and implementing
SOAs.
Objectives
In this module, you will learn how to:

■ Describe design best practices that can be applied during the design of Web service
applications
■ Describe the best practices that impact the performance and QoS capabilities of Web
service applications
■ Describe WebSphere Application Server V6 capabilities for enhancing the performance of
Web services applications
■ Describe ways by which interoperability challenges can be resolved in Web service
implementations, including the use of WSDL styles and SOAP with Attachments
■ Discuss tradeoffs of using WS-Security versus traditional security mechanisms
■ Describe IBM's definition of Web services management and solution approaches

Before completing this module

Before reading this module you should complete the module IBM software support for SOA and Web
services.

Page 2
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Introduction
This course explores some of the advanced topics associated with Web services implementation
specifically architecture best practices, approaches to improve performance of Web services applications,
approaches to resolve interoperability issues within Web service implementations, Web services
versioning, and advanced topics in areas of WS-Security and Web services management.

Page 3
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Best practices for Web services (1 of 2)

Performance and QoS characteristics of Web services based applications need to be carefully thought out
and addressed during the design phase. They should not be delegated to the very end of the development
process. Here you will learn certain best practices that can be applied during the design of Web services
applications. Prior to even the design, you need consider whether Web services are even suitable within
the context of your business/IT problem. To understand the value of Web services technology, refer to the
course SW717: Introduction to the Value and Governance Model of Service-Oriented Architecture. You
can also review many technical articles and tutorials available from IBM’s developerWorks at
http://www.ibm.com/developerworks/ .
Message granularity
The key design issue for a service-oriented architecture (SOA) is to determine both the granularity of the
individual services along with the business requirements to accommodate change. The design trade-offs
of message granularity were discussed in detail in the course SW718 Design SOA Solutions and Apply
Project, Technical and Operational Governance. Here you learn the performance issues associated with
designing message granularity when using Web services.
Web services use a very simple, yet powerful format for message exchange: XML. While being able to
read and structure XML documents with just any simple text editor eases the use of XML, the process of
automatically creating and interpreting XML documents is more complex. Therefore, there is always a
point where the complexity of dealing with the protocol is higher than performing the actual computation.
Every Web services request by definition is a remote request, typically involving the Web container or JMS
plus the XML overhead of parsing and deserialization. In addition, there is the cost of going across the
network itself. If you have fine-grained messages, then you require many more operation invocations,
which involve the cost of all of these for each invocation. If you have course-grained messages, then you
reduce the number of times you incur these costs.
Review the chart below. If you need to send or retrieve a 50K object that has 10 properties, each 5K long,
you can retrieve all 50K as one Web service request, as 50 requests for 1K, or some other combination
such as 10 requests for 5K each. You can see that one 50 KB message is far better than either of the
other combinations because the overhead of the container, XML processing, and network costs is incurred
only once.

Performance comparison of sending 50 properties, each 1KB long

Page 4
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

However, just because in this example one course-grained message outperformed finer-grained
messages, does not mean this will hold true for all data types. When using course-grained messages, you
need to be careful about the size of the XML payload and data types used within messages.
Course-grained messages tend to involve more complex XML schema, and complex schema will put a
heavier burden on XML parsers and on serialization and deserialization. As messages get larger and
more complex, parsing time becomes a larger percentage of the total processing time; and the deeper the
nesting, the more complex and time-consuming the serialization and deserialization. Deeper nesting
translates to objects defined within other objects and collections of objects defined within other objects.
Increasing the level of object nesting translates to an increase in the number of objects that are
deserialized and created coming in from the input Web services XML. An object of a certain size that is
composed only of primitive types, strings, and so on, will yield better Web services performance than a
similar size object composed of deeply nested Java objects.
In addition, using short attribute, property and tag names within message design translates into better
performance. As each attribute, property, and tag name is transmitted verbatim, the length of a message
is directly dependent on the length on the attribute and property names. The general rule of thumb is: the
shorter the attribute, property, and tag names, the shorter the transmitted message and the faster the
communication and processing.
In summary, simple, course-grained messages perform the best, but since course-grained messages tend
to be complex, experimentation has shown that medium-grained messages usually perform best.
WebSphere Application Server V6.0 includes new serialization and deserialization technology that delivers
significant performance improvements over earlier versions of WebSphere Application Server and
competitors' Web services runtime environments. The serialization and deserialization runtime
environment in WebSphere Application Server V6 is enhanced to cache frequently used serializers and
deserializers. This can decrease the processing time for large messages.
Web services are distributed services
A Web Service is a remote service. You have already learned that usage of course grained messaging is
a best or leading practice. In addition, to reduce the overhead of remote invocation, you need to carefully
design the data objects that will be exchanged during interaction with Web service:

■ Minimize information being exchanged. For example, send a key instead of an entire record,
or, send only changed data. You can also consider caching the data on the caller – you will
learn later in this course the WebSphere Application Server V6 capabilities for client-side
and server-side caching.
■ Limit the number of network calls.
■ Let the business needs drive your design.
For example, if you are getting an employee record, but frequently only using a few fields
from it, you may want two operations: getPartialEmployeeRecord and
getFullEmployeeRecord.

Page 5
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Best practices for Web services (2 of 2)

Choosing a protocol
There are several different transport protocols available for invocation of Web services. Each has unique
capabilities and uses. Ideally you don’t want to artificially restrict your service to one type of transport
protocol. Some considerations when deciding on what protocols to support for Web services are:

■ Do you have the need for intermediaries? If so, then your intermediaries must be able to
speak that protocol.

a. Intermediaries might be needed for logging, filtering, authentication, authorization, and

routing.
■ Are your Services Synchronous, Asynchronous, or both? Some protocols fit certain models
better than others.
■ Can all your clients support this particular protocol? What technologies are they
implemented in? What level of the protocol (if a standard) can they support?
■ What are your performance needs?

Comparison of protocol choices for Web services

WebSphere Application Server V6.0 provides full support for JAX-RPC and JSR 109. However, in addition
it adds support for SOAP/JMS and provides JAX-RPC multiprotocol support. JAX-RPC multiprotocol
support allows the user to invoke a remote stateless session EJB using a RMI-IIOP invocation. This allows
managed clients (defined by JSR 109) to access Web services through a number of protocols while using
a common programming model (JAX-RPC). As you will learn, JAX-RPC multiprotocol support can offer
better performance in some cases as well as offer higher-level QoS features.
The above figure demonstrates the QoS features rendered by SOAP/JMS and RMI-IIOP. SOAP/JMS
offers

■ Reliable delivery of messages

■ Support for broadcast and queued modes of requests

RMI-IIOP offers

■ Provides for synchronous communication and reliable delivery of requests

■ Support for propagation of security and transactional contexts

Page 6
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

There are two ways to implement service providers using JSR 109. You can implement service provider
as a JavaBean; you can then make available the JavaBean as a Web service that is available over
SOAP/HTTP protocol. You can also implement the service provider as a stateless session EJB. With such
implementation you have choice of several protocols over which the Web service can be invoked:

■ SOAP over HTTP for non Java clients

■ RMI/IIOP for Java clients (without firewall issues)
■ Local calls when in the same JVM
■ MDB for messaging clients

a. This might be SOAP over JMS

JAX-RPC multiprotocol support in WebSphere Application Server V6

There are several architectural reasons to consider using stateless session EJBs as the Web service
implementation:

■ Web services can be made available over a variety of protocols.

a. Support both RMI/IIOP and Web services interfaces. If you know the Java client of a Web
service that is implemented as a stateless session EJB resides on the same machine,
then invoking the EJB directly using RMI/IIOP binding will offer you better performance.
b. Support SOAP over JMS for reliable messaging.
■ With WebSphere Application Server V6 performance of RMI/IIOP is comparable or better
than SOAP/HTTP (in some cases).
■ You can enforce security at method/operation level. Further security context can be
maintained over RMI-IIOP. Although HTTP and HTTPS get through firewalls much more
easily then IIOP, HTTP and HTTPS work well for single hops, but not across multiple hops.
For multi-hop scenario you can use WS-Security. The performance of WS-Security
encryption and digital signature validation has significantly improved within WebSphere
Application Server V6 because of the use of the SAAJ 1.2 implementation. However, you will

Page 7
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

still need to carefully evaluate the performance impact of WS-Security over traditional
security mechanism explained later in the section WS-Security versus traditional security
mechanisms.
■ Transaction context can be maintained over RMI-IIOP.

In summary, WebSphere Application Server V6.0 JAX-RPC multiprotocol support enables a wider choice
of protocols for Web services. Implementing Web services as stateless session EJBs enables you make
the Web services available over a wider variety of protocols while also offering performance and QoS
features such as reliability, transactions and security. RMI-IIOP offers comparable (and in some cases
better) performance to SOAP/HTTP using WebSphere Application Server V6.
Location transparency
Location transparency enables you to move a service from one machine to another without affecting the
clients using the service. Location transparency promotes looser coupling within Web service solutions.
For example, when using SOAP/HTTP, if you move a service from one machine to another, you will need
to update the host name and port in the WSDL endpoint address. But how does your client know the
service has moved and get the new endpoint? There is no standard way of letting the client know about
the change in endpoint address. Here are a few alternatives:

■ The client could be written to read the address from a properties file, but then the service
provider would need a way of updating the properties files for all its clients.
■ You could have a third party location (such as UDDI registry) for the endpoint which the
service provider updates and the service requester uses for lookup. This would mean that
you will be potentially making 2 remote calls per Web service invocation – you can cache the
endpoint in the client to limit these.
■ You can use an intermediary such as Enterprise Service Bus (ESB). An ESB acts as an
intermediary between service requesters and service providers and provide additional
services such for transport, mediation and event management. The service requesters can
invoke the service on the ESB, and ESB takes care of performing appropriate
transformations and routing the request to the service provider. ESB can thus provide
location transparency for services. You have learned in Module 2, IBM software support for
SOA and Web services, that IBM products such as Web Services Gateway, WebSphere
Application Server V6, WebSphere MQ and WebSphere Business Integration Message
Broker provide ESB implementation. If you use the Web Services Gateway as an ESB and
the WSDL endpoint address changes, changes will only be required in the Web Services
Gateway; the clients of the Gateway are unaffected.

JAX-RPC handlers
JAX-RPC handlers allow you to intercept a SOAP message at various times during a service invocation.
Handlers can exist on both the client and the server side. If you use JAX-RPC on the client side, you can
have a handler process a SOAP request message right before it goes on the network, and you can
process the response message before it is returned to the client. Similarly, you can intercept an incoming
SOAP request message on the server before invoking the service implementation, as well as the outgoing
response. Use handlers to:

■ ‘Manage’ request and response messages

a. Read what’s already in the message, for example:

Log each time a Web service is used.
Monitor health of service and response time.
b. Add information that is not yet there, for example:
Create and process header data introduced by new Web services specifications, for
example, WS-Security, WS-ReliableMessaging, and so forth.
Create a layer that deals with contextual information which is not part of the business
interface.
■ ‘Mediate’ consumer-provider interaction

Page 8
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

a. Data transformation
b. Routing

For more information on using handlers, see

http://www.ibm.com/developerworks/webservices/library/ws-tipjax2.html .
SOAP headers
SOAP defines the concept of a message header. It is an optional part of any SOAP message. If it exists,
the header contains information about the message, or about the context in which the message is sent, or
basically whatever the creator of the message thought was a good idea to put there instead of the actual
body of the message. Obviously, both the sender and the receiver of the message need to agree on its
format. SOAP headers are extensively used by Web service specifications. Examples of header data
include:

■ Contextual information such as ‘cookies’

■ QoS style data, for example: security, routing, message handshake, transactions

However, you need an API to insert and process this information from within JAX-RPC. JAX-RPC
handlers are used to process SOAP headers. Within JAX-RPC handlers you can use SAAJ 1.2 to get
access to contents of the SOAP header.

Page 9
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

WebSphere Application Server V6: Best practices

In addition to the above best practices, WebSphere Application Server V6 provides several capabilities
that can aid in the design and deployment of scalable and robust Web services solutions. These
capabilities lead to additional best practices that can be adopted during design and deployment of Web
services solution.
In-process optimization
With WebSphere Application Server V6, you can improve performance by using an optimized
communication path between a Web services client application and a Web container that are located in
the same application server process. Requests from the Web services client that are normally sent to the
Web container using a network connection are delivered directly to the Web container using an optimized
local path. The local path is available because the Web services client application and the Web container
are running in the same process.
This direct communication eliminates the need for clients and Web containers that are in the same
process to communicate over the network. For example, a Web services client might be running in an
application server. Instead of accessing the network to communicate with the Web container, the Web
services client can communicate with the Web container using the optimized local path. This optimized
local path improves the performance of the application server by allowing Web services clients and Web
containers to communicate without using network transports.
Web services caching
WebSphere Application Server V6 supports sophisticated caching capabilities for Web services, thus
improving performance of Web services applications. WebSphere Application Server consolidates several
caching activities, including servlets, Web services, and WebSphere commands into one service called
the dynamic cache. These caching activities work together to improve application performance, and share
many configuration parameters, which are set in the dynamic cache service of an application server.
The WebSphere Application Server V6 dynamic cache service supports the following scenarios for
caching Web services:

■ Reverse-proxy scenario where the proxy can act like a gateway caching requests for
invoked Web services, thereby reducing the load on server-hosted Web services.
■ A client-side cache where applications hosted on a content providers network can reduce
the network exchange of SOAP messages within an enterprise network.
■ Combination of both of the above scenario where the client and server are both running
WebSphere Application Server

WebSphere Application Server V6 Web services caching support

Page 10
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Web service server-side caching leverages servlet caching support and introduces caching of SOAP
requests. Web service specific components used to construct a cache ID are:

■ SOAP action in HTTP header

■ Entire SOAPEnvelope
■ Servlet path (in JSR 109 case, this refers to a port-component)
■ SOAP operation (requires parsing of SOAP message)
■ SOAP operation parameters (requires parsing of SOAP message)

Web Service client-side caching leverages the JAX-RPC handler framework that is already part of
WebSphere Application Server V6. It is configured like all the other caching capabilities in WebSphere, by
specifying a cachespec.xml file and defining the cache entries to be of type JAX-RPC client. Cache ID
rules for Web services client cache could use service name, port, operation and parameters to identify
requests and entries in cache. Similarly, cache IDs could also be built using special SOAP header fields if
the client generating these SOAP envelopes could add them for better performance.
Performance monitoring
You can use the Performance Monitoring Infrastructure (PMI) to measure the time required to process
Web services requests. PMI provides server-side monitoring and a client-side API to retrieve performance
data. In WebSphere Application Server V6, Tivoli Performance Viewer is now a thin client integrated into
the administrative console. It provides a simple viewer for the performance data provided by PMI.
PMI provides detailed statistics that can help you gain clear insight into the runtime behavior and
performance of Web services. Performance counters enable you to see key performance data for each
individual Web service including:

■ The number of requests dispatched to an implementation bean.

■ The number of requests dispatched with successful replies.
■ The average time in milliseconds to process full requests.
■ The average time in milliseconds between receiving the request and dispatching it to the
bean.
■ The average time in milliseconds between the dispatch and receipt of a reply from the bean.
This represents the time spent in business logic.
■ The average time in milliseconds between the receipt of a reply from a bean and the return
of a result to the client.
■ The average size of the SOAP request.
■ The average size of the SOAP reply.

More details on WebSphere Application Server V6 Web services capabilities can be found in the
References section.

Page 11
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Interoperability best practices (1 of 3)

Introduction
A big promise of Web services is interoperability. But even at its inception there were problems: there are
an abundance of specifications that are often unclear, inconsistent, and even contradictory. The Web
Services Interoperability Organization (WS-I) was formed to address these problems. Great strides have
been taken in WS-I to clarify the existing specifications, to make them consistent, and to clear up
contradictions. You will learn a brief overview of WS-I followed by several best practices that can be
applied towards developing interoperable Web services solutions.
WS-I compliance
For the most part, the industry has embraced WS-I profiles, and vendors either conform to them or are
working to conform to them.
IBM is in the forefront of WS-I conformance. The WS-I defines basic profiles. A basic profile is a set of
specified standards and the relevant clarifications defined against the specifications. On August 3, 2004,
the second generation of basic profiles (Basic Profile 1.1, Attachment Profile 1.0, and Simple SOAP
Binding Profile 1.0) became member approved drafts. IBM has conformed to these profiles in the present
release of WebSphere Application Server V6.0.
Being WS-I compliant means that your Web services implementation follows the industry’s conformance
standards with regard to interoperability. If the development tool you are using supports the development
of WS-I compliant Web services, you should turn this feature on and follow its advice. However,
conforming to WS-I does not mean that your application will be interoperable in any case, as some other
party may not be WS-I compliant. For the most part, if you comply with WS-I profiles, then you will
produce interoperable Web services. It is therefore a best practice to follow guidelines prescribed by WS-I
basic profiles in building your Web services applications. Note that WS-I defines conformance in terms of
Web Service instances and artifacts, not in terms of platforms or development tools. In other words, a
Web Service can be labeled WS-I conformant, but a vendor’s runtime environment cannot.
In addition to WS-I compliance, there are certain design best practices that can be applied when designing
Web services for maximum interoperability. Some of these specifically address interoperability with .NET.

Page 12
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Interoperability best practices (2 of 3)

Document and literal wrapped WSDL
WSDL allows for several combinations of encoding and style. Depending on your choice of these
attributes, you may have issues with interoperability and performance.

WSDL SOAP binding attribute choices

Following is some background information.

There are two ways to structure the content of the SOAP message.

■ RPC

a. The root element tag under the body is always the name of a method or function.
b. Also fixes the names under the root, which are the parameter names which are passed
into the methods.
c. Expects a response message with a single result element.
■ Document

a. The message contains a valid XML document under the body element.
b. The document can have can have multiple elements.

WS-I allows WSDL style and uses of RCP/literal and document/literal. However, .NET does not support
RPC/literal, so you should limit yourself to document/literal. Moreover, you should follow the wrapped
pattern of document/literal (.NET does not support non-wrapped document/literal WSDL). The wrapped
pattern is what .NET generates for its WSDL, and it is actually a good pattern. This is the direction the
industry is moving, so it is a good practice to follow the document/literal wrapped pattern in general, not
simply for .NET interoperability.

Page 13
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

The essential characteristics of the wrapped pattern are:

■ The input message has a single part.

■ The part is an element.
■ The element has the same name as the operation.
■ The element’s complex type has no attributes.

In summary:

■ Choose either RPC/literal or document/literal wrapped.

■ Avoid RPC/encoded. It leads to interoperability issues. It is also expensive because type
information is added to the SOAP message for every type, thus bloating the message and
requiring extra XML parsing. For further details, see
http://www.ibm.com/developerworks/webservices/library/ws-soapenc/ .
■ You should avoid non-wrapped document/literal. In the case of non-wrapped
document/literal, no operation name is sent in the SOAP message. Therefore dispatch
becomes expensive because the dispatcher must use the parameters to determine which
operation to dispatch to, not merely the operation name.
■ Document/literal wrapped is recommended over RPC/literal because it is more interoperable
and is becoming the industry standard. It is also the default when creating a Web service.
■ For more details about the various style and use options, see
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ .

Page 14
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Interoperability best practices (3 of 3)

WS-I’s Attachments Profile 1.0
If you wish to send binary data, a common way to do so is to send it as a MIME attachment in accordance
with the SOAP with Attachments (SW/A) specification. WS-I’s Attachments Profile (AP) addresses the few
interoperability issues that existed with SW/A. So, if you conform to WS-I’s AP 1.0, and your vendor’s
runtime environment conforms to AP 1.0, then you should have no problems.
However, Microsoft does not support SW/A. Therefore, you cannot exchange attachments with .NET.
A new proposed standard is being worked on by W3C called Message Transmission Optimization
mechanism (MTOM). As of November 2004, it is a proposed W3C recommendation. MTOM provides an
alternative encoding structure for handling attachments. MTOM specifies an optimization mechanism for
the transmission or wire format of SOAP messages. With MTOM the attachment data is outside the XML
payload but part of the SOAP infoset:

■ This allows XML-validation of the SOAP message (and gain the performance benefits of not
inlining and encoding the binary data).
■ This also allows for securing the binary data or the entire SOAP message.

MTOM is most likely future interoperability candidate if binary data is desired. Until MTOM is widely
available, however, there are means by which you can exchange binary data with MS.NET or with other
vendors' Web services runtime environments. You can inline the binary data within SOAP message by
using base 64 or hex binary encoding. This translates the binary data to plain text. However this approach
also increases the size of SOAP message by nearly 33%. You can also consider exchanging binary data
out of band. Either for interoperability with .NET or to handle large segments of data, you can simply send
a pointer to the data (for example, a URL), and let the receiver of the message retrieve the data outside of
the SOAP messaging protocol.
SOAP Faults
Design SOAP Faults as you would design Java Exceptions in your applications.

■ Don’t model Fault type hierarchy to follow every possible server application error condition
(use error codes instead).
■ Model Fault type hierarchy following client error recovery scenarios.
■ Implement SOAP Faults as XML types/elements in your WSDL.
■ Don’t use raw [faultcode] and [faultstring] for application error reporting.

JAX-RPC maps Java Exceptions to and from SOAP Faults. This makes SOAP “transparent” for passing
exceptions in scenarios where the JAX-RPC is being used at either ends of Web service interaction.
However, Fault is not a “portable” Exception serialization format. For instance, .Net maps any SOAP Fault
to a generic SOAPException type and lets you handle Fault [details] as raw XML DOM tree inside the
application. In addition, you can only control the first immediate child of Fault [details] portion since it
has to contain your WSDL message. SOAP engines may add their own data elements inside [detail],
for instance WebSphere Application Server will add a call stack after your fault message. Other elements
of SOAP Fault, such as [faultcode] and [faultstring] may be “hijacked” by SOAP engines that
use them to serialize native exceptions for the matching clients.
Import and include
An import statement brings in other namespaces. An include statement brings other declarations into the
current namespace.
Use XSD imports to import schema. Use WSDL imports to import WSDL. Import all of the namespaces
that you use. The import statement’s namespace attribute value must match the imported
targetNamespace value. You can find more details at
http://www.ibm.com/developerworks/xml/library/ws-tip-imports.html .
Nillable primitives
Nillable primitive types are allowed for Web services but there are interoperability issues when using them.
The best advice is to not use them at all and use dedicated flags to signal the condition that a value does

Page 15
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

not exist.
Data types
Even though Web services were designed with interoperability in mind, it is best to use simple data types
where possible. Simple means integers and strings. Also, compound data types (comparable with structs
in C, or records in Pascal) and arrays of simple types are simple. Anything that does not fall into this
pattern should be used carefully. In particular, Java’s collection classes and similarly complex data types
should be avoided because there might be no proper counterparts at the client side. When collections are
required, the safest bet is to use arrays. Arrays are supported by WS-I Basic Profile. You may want to use
a wrapper class to convert from specific collection into array and vice versa. For more details on this refer
to article at http://www.ibm.com/developerworks/webservices/library/ws-tip-coding.html
.NET interoperability resources
Microsoft has provided several resources that will help you understand interoperability issues with .NET
Web services. Following are two key resources:

■ Microsoft book: Building Interoperable Web services

http://download.microsoft.com/download/8/d/8/8d828b77-2ab2-4c8e-b389-e23684f12035/WSI-BP.pdf
■ Microsoft WS-I Sample Application implementation source http://ws-i.org

You can also consult the IBM developerWorks Web site listed in the References section for further details
on resolving interoperability issues with Web services and to understand in detail the WS-I compliance of
IBM’s products.

Page 16
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Versioning Web services

You may need to maintain different versions of Web services – to do this you need the ability to version
Web services. Unfortunately, this is not addressed by WSDL 1.1. The only sure way of supporting different
versions of a Web service is to create a completely different Web service under a new namespace.
One approach to Web services versioning is to simply modify your existing WSDL/XML files and send that
new version to your clients. But this is very risky because you may not know all your clients. What if the
new version of your service receives a message from a client that is not aware of the new version? You
may have designed it that way (or you may be very fortunate) so that your service is backward compatible
(see below). If not, the operation request will simply fail. This is not as you would want; nevertheless, no
real harm is done. If you are very unlucky, the invocation may succeed, but it may not invoke what you
expect it to invoke and valid, though incoherent, data may be exchanged.
The better choice is to create a new set of WSDL/XML files, complete with a new set of namespaces. This
way, an old client will not even be able to invoke the new service because the namespaces are different.
You still have to deal with the issue of the older versions of a given Web service. You will have to
determine the answers to some questions. Do you want to support all versions? Is only the latest version
going to exist? You could use UDDI to control access to different versions of a given Web service. An
article that discusses the details of namespace versioning is:
http://www.ibm.com/developerworks/webservices/library/ws-version/
While Web services versioning is not supported, and creating a whole new Web service for each version
is rather drastic, you still have some options to try before going to a completely different namespace for a
new version. Some of these options are: backward compatible changes, interception, and use of
xsd:anyType.
Backward compatible changes
Backward compatible changes are those changes that you can make to a Web service API that do not
require you to go to a new namespace. There are two sorts of backward compatible changes: changes to
service input and changes to service output. A backward compatible change to input is one in which a new
Web service can continue to receive data from an old client. A backward compatible change to output is
one in which a new Web service can continue to send data to an old client.
Changes to input
New operations
If you add a new operation to a service without removing any of the old ones, clients of the old version of
the API will continue to work with the new service.
New data types
You may add new data types to a service, either as extensions to existing complexTypes, or as new types
used by new methods. As long as you have not changed or removed any of the old types, a client of the
old version will continue to work with the new service.
New, optional fields in an existing data type
If you add an element to an existing complexType that is only received, not sent, by the new service, and
you make it optional (using the minOccurs=”0” attribute), then clients of old versions can still send the old
version’s type and the new service will accept it. Note that this does not hold true for types that old clients
receive. They know about the old type, they do not know about any new fields, so if they receive a new
type with a new field, they will fail to deserialize that type. It is, essentially, a wholly new type, one of which
the client is not aware.
You can also add new attributes to a complexType in the same manner as a new element provided to the
attribute’s schema has the attribute use=”optional”.
Type expansion
You can expand the data type that your service receives. For example, if the old type were a Boolean, but
you realized that 2 values were not enough and redesigned the type to be a string (with values “true”,
“false”, “maybe”, for instance), then a client sending the old type to a new service will still function.
This change will work with RPC/literal and document/literal services, but it will not work with an
Page 17
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

RPC/encoded service. Note that “encoded” means that type information is sent in the message. Since you
cannot change the appearance of a message, and changing the type will change the appearance of an
encoded message, you cannot apply this change to RPC/encoded. But RPC/encoded WSDL is losing
favor in the industry, so you would want to avoid it for that reason, anyway.
Type expansion works with literal services because their messages only contain values, not type
information. When “true” comes across, you do not know whether it is a Boolean or a string just by looking
at it; the service dispatcher has to get involved to determine its exact type.
Type expansion also only works with data types received by the new service, not sent from the service. If
you tried sending a value of an expanded type to a client that is not aware of that type, the client will fail to
deserialize that type.
Type expansion is a little riskier than the previous backward compatible choices. The others are all
additions; this one is a change. A change of an API often also involves a change of the underlying
implementation’s behavior. Provided the old behavior continues to exist with the old values, then type
expansion is safe. But if the behavior of the Web services implementation receiving old values changes,
then this is not a backward compatible change. You must preserve the semantics of the values.
Changes to output
Only one backward compatible change to output readily comes to mind: type restriction. Your server can
restrict the type of field sent to an older client. For example, assume the old version of a Web service
returns an xsd:string to the client. In the new version of the service, you decide that only specific values
are valid, so you create an enumeration restriction of a string with only those values. The old client will still
expect any sort of string, so it will not really care that you are now restricting the values.
Like type expansion, type restriction only works for literal data and if you do not change the behavior of the
service. Also like type expansion, type restriction only works in one direction, but in the opposite direction,
a new service sending data to an old client.
Interception
Another option for dealing with different versions of a Web service’s API is to intercept all messages
coming into and leaving from a service, determine what version the message supports, and then act
accordingly.
“Acting accordingly” could mean different things. One option is to have all existing versions of a service
deployed. Then the interceptor would determine which version the incoming message supports and would
dispatch it to the appropriate service.

Interception of a SOAP message

Another option is to have only the latest version of the service deployed. The interceptor would then
Page 18
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

transform the incoming message as appropriate for the latest version of the service.

Transforming a SOAP message

The question remains, then, how to indicate the version of an incoming message. The reasonable place to
carry a message version is in a SOAP header. You can either make it an explicit part of the programming
model by making it a parameter on the method call, or you can implicitly include it in the message using a
handler.
Use of xsd:anyType
Another approach is to use xsd:anyType for all input and output messages. Then you can allow any type
(or version of a type) to be sent or received. There are two issues with this approach.
First, WSDL is designed to be fully declarative. This approach removes the declarative nature of WSDL
and you need some other mechanism – verbal, written contract, and so on – to completely declare to the
client the valid values for any given message.
Second, this approach puts a much bigger burden on applications. They now have to handle versioning
explicitly themselves. It may be more work, but if done carefully, this could be a more robust versioning
solution.
In summary, versioning is not supported in WSDL 1.1. However, there are a number of things you can do
yourself to facilitate the versioning of Web services APIs.

Page 19
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

WS-Security versus traditional security mechanisms (1 of 3)

When determining what kind of security is appropriate for your application, it is important to remember
these points:

■ Security is not one-size-fits-all.

a. Proper usage requires analysis of application-specific security requirements.

■ Security-related Web services standards are still evolving.
■ Product support

a. Initial set of (OASIS WS-Security) standard platforms are becoming available.

The following lists several considerations when choosing the security model for your application:

■ Interoperability

a. What standards and profiles are supported on the other platforms?

■ Topology, end-to-end

a. Are intermediaries (potentially) present?

b. Are they trusted by all parties?
c. Is one transport used throughout?
■ Manageability and ease of use

a. What is the existing enterprise security infrastructure?

■ Accountability

a. Would billing or other processing be performed based on the identity of a party?

■ Performance

a. Is higher throughput more important than higher security?

■ Authentication

a. Do you want to know the identity of the other party before sending or accepting a
message?
b. Would you need proof if the other party disputes the content of a message?
c. Do you trust all potential intermediaries to authenticate or vouch for other parties?
d. Do you only care about the identity of the party at the other end of the connection?
e. How sure do you need to be of identity?
■ Integrity

a. Would intentional or accidental alteration of message content cause errors or liabilities?

b. Do you trust all potential intermediaries to maintain data integrity?
■ Confidentiality

a. Would unintentional disclosure of message content cause embarrassment or liability?

Page 20
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

b. Should all potential intermediaries have access to all confidential message content?

There are several good ways to secure your Web services implementations. When considering your
options, you should think about what your requirements really are today and create a solution that
addresses them. Because Web services security is added declaratively for the most part, changing
security approaches is largely an administrative task and will not require you to re-engineer your solution.
There is a great deal of focus on the performance and interoperability issues for Web services.
WebSphere Application Server V6 uses SAAJ 1.2 and delivers significant performance improvements for
WS-Security encryption and digital signature validation. WebSphere Application Server V6 supports
WS-Security 1.0, WS UserName Token Profile 1.0 and WS X.509 Binary Security Token Profile 1.0,
thereby enabling interoperability across other vendors’ runtime environments. Using SSL for integrity and
confidentiality and WS Security for authentication or identification is probably the best solution for most
applications today where intermediaries are not mandated.

Page 21
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

WS-Security versus traditional security mechanisms (2 of 3)

Transport Level Security and WS-Security
Quite often, based on your applications security requirements, traditional security mechanisms such as
Transport Level Security is sufficient. The following figure shows the protocol stacks over which transport
level security (such as TLS/SSL) operate.

Transport Level Security

The properties of Transport Level Security can be summarized as:

■ SSL/TLS

a. Provides reasonably fast and secure transport for Web services between adjacent SOAP
nodes
b. Provides server authentication at session establishment [using X.509]
c. Provides optional client authentication at session establishment [using X.509]
d. Provides data integrity and encryption for message exchanges using relatively efficient
symmetric key cryptography
e. Supported by various hardware-based accelerators
■ HTTP authentication provides following authentication mechanisms:

a. Optional client authentication

i. HTTP Basic (using password)

ii. HTTP Digest (using password)

Generally, you should use Transport Level Security in these situations:

■ When your solution requires very high transaction volume – because it is fast and scales
well
■ When your solution does not require intermediary processing (filtering or some form of
content based routing) – because SSL is designed to prevent intermediaries from altering or
reading the message in transit
■ When you have a low tolerance for interoperability issues associated with the emerging Web
Page 22
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

services security implementations but must work in a heterogeneous environment – because

SSL is mature and SSL implementations from different vendors interoperate well
■ When you need to secure attachments to Web services – because SSL encrypts all of the
transport level packets, the Web service headers, body, and attachments are all secured
■ When you have standalone Java applications as clients
■ When you need to identify the other party before sending or accepting messages
■ When there are no untrusted intermediaries present
■ When all message exchanges use HTTPS
■ When the only important identity is that of the party at the other end of the session
■ When the application spans a single security domain (internal EAI, request/response)
■ When the probability of disputes is minimal

a. Later proof of message content is not required

■ When security is needed for the entire HTTP message

a. HTTP headers
b. Attachments

Below are examples of instances when SSL may not be sufficient:

■ Using SSL/TLS, the entire message is encrypted.

a. This is inefficient if you do not need the entire message to be encrypted.

b. You cannot use content-based routing without terminating the SSL connection and
decrypting the whole message.
c. You cannot encrypt different parts using different keys for different "actors" in the message
processing path.
■ SSL/TLS does not provide nonrepudiation.

a. For nonrepudiation, information has to be stored "signed" using asymmetric key

cryptography. SSL does not provide access to the signed packets, and it uses symmetric
key cryptography for the data packets.
■ SSL/TLS is connection-oriented (single hop) not message-oriented (end-to-end).

a. The SSL connection is terminated at intermediaries and a new SSL connection must be
established for each hop; thus the identity of the original client is lost on the second hop.
b. If intermediaries are present,
Intermediaries get to see unencrypted message (whereas you may want some information
encrypted from end-to-end).
Intermediaries get to modify the message undetected; therefore you do not get
guaranteed integrity.

The following figure shows the high-level architecture of WS-Security within WebSphere Application
Server V6. WS-Security is designed and implemented as message level handlers of the WebSphere
Application Server V6 Web services engine. WS-Security handler is a “system handler” and is registered
to the Web service runtime environment. On the client side, the WS-Security handler is invoked to
generate the required security headers in the SOAP message before the message is sent out over the
wire. The security handler generates the security constraints defined in the deployment descriptor and
packages the security information (digital signature, encrypted data and security tokens) into the SOAP
message. On the server side, the WS-Security handler is called to enforce the declared security

Page 23
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

constraints in the deployment descriptor prior to dispatching the request to the Web Service EJB or
JavaBeans implementation. The security constraints of the request sender and request receiver must
match. Also, the security constraints of the response sender and response receiver must match. For
example, if you specify integrity as a constraint in the request receiver, then you must configure the
request sender to have integrity applied to the SOAP message. Otherwise, the request is denied because
the SOAP message does not include the integrity specified in the request constraint.

Web services security architecture in WebSphere Application Server V6

The properties of Web services security can be summarized as follows. In general, use Web services
security in the situations described below:

■ Provides end-to-end security through any number of intermediaries

■ Supports authentication and assertion of multiple party identities
■ Provides extensible support for legacy security tokens
■ Provides independence from delivery mechanism, works across multiple transports
■ Provides selective authentication, integrity, and confidentiality for SOAP message header or
body

a. Parts of a message can be signed or encrypted for a particular SOAP node.

b. XML signatures and encryption can be applied across:
Any subset of the SOAP envelope (other than parts of the security header)
Any security token
Any timestamp
Any previous signature or encryption block

In general, use Web services security in the situations described below:

■ When your application requires that intermediaries have access to some message content
(often SOAP headers) in order to process the message in transit – because WebSphere
Application Server V6 WS-Security Engine (WSSE) uses XML signatures and XML
encryption for integrity and confidentiality, you can encrypt some parts of the message while
leaving other parts in the clear.

Page 24
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

a. Intermediaries may be present

b. Potentially untrusted
c. End-to-end security required
■ When you want to persist the message in its encrypted or signed format – because of the
use of XML signatures and XML encryption — the message integrity and confidentiality
persist beyond a transport connection.
■ When your immediate requirements dictate that you will be processing tens to hundreds of
messages per second rather than thousands —which affords you the luxury of implementing
a strategic solution up front. Performance and interoperability are being addressed by
vendor runtime environments including WebSphere Application Server V6. WebSphere
Application Server V6 delivers significant performance improvement for WS-Security while
supporting the WS-Security 1.0. Other vendor runtime environments are also addressing
performance and interoperability and in the near future one can expect the WSSE stacks to
be as interoperable as SSL stacks are today.
■ When non-HTTPS transports may be present
■ When you have a need for authentication or assertion of multiple party identities

a. User, Portal, Service, and so on

■ When you have multiple security domains (B2B)
■ When the possibility of disputes exists

a. Need to prove origin (authentication) and content (integrity) of message

■ When you need security over a portion of the messages

a. Composed services
b. Business process and workflow
■ When it is important to enable adoption of emerging features (see Web Services Security
Roadmap)

a. WS-Trust
b. WS-Federation
c. WS-SecureConversation
d. WS-Policy and WS-SecurityPolicy

Page 25
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

WS-Security versus traditional security mechanisms (3 of 3)

Combining WS-Security and Transport Level Security
Quite often a combination of Transport Level Security and Web services security provides the complete
end-to-end solution for an application. Below is a graphic illustration of the combination of WS-Security
and Transport Level Security. In the graphic, WSSE stands for WebSphere Application Server V6
WS-Security engine. SSL/TLS provides integrity and confidentiality between the network endpoints.
WSSE performs authentication of Web services requests by delegating to WebSphere Application Server
V6 authentication mechanisms (such as SWAM and LTPA) and using a user registry.

WS-Security for authentication and SSL for the rest

Such a combination provides the following properties:

■ SSL provides

a. Data encryption and integrity

b. Server (peer) authentication
c. Optional client (peer) authentication
Lower likelihood of invalid messages from untrusted parties
■ WSSE provides

a. Data integrity and origin authentication

Page 26
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

b. Field level encryption

c. Security token propagation
d. Since fewer serialize and parse operations are needed, you may get better performance
than XML signature and encryption.
e. Supports complex (multiparty) authentication models

You can use such a combination when the following considerations apply.

■ When the application invoking the Web service is a middle tier and wants to propagate the
user’s identity, not some generic “server” identity – because the WSSE security
implementation in WebSphere Application Server allows for direct propagation of the current
context (LTPA) and for mapping the current context to tokens for propagation.
■ When you want to propagate context using your own token format or a token you can create
and manipulate using third-party libraries – because the WSSE stack is extensible through
custom security callbacks.
■ When you do not want any security code mixed in with your business code – because the
WSSE stack is completely controlled by deployment descriptors, there is no coupling of
business code with the security implementation.
■ When confidentiality with any intermediaries is not an issue.
■ When the Web service is a middle tier and needs to propagate a user’s identity and not
some generic “server” identity.

Security summary
Since WS-Security will have an impact on the overall response time and the number of simultaneous
requests that your solution can support, it is important that your decision to use WS-Security is justified. In
many cases, HTTPS with the transport KeepAlive enabled will provide you with a significantly better
performing solution than is possible when using XML digital signature and XML encryption. Yet, the extent
to which HTTPS provides you a better solution is really dependent on the overall processing times of your
business logic executed by your Web services implementations. If your services are doing simple inquiries
into a well-indexed database that take less than 100 milliseconds, then you will see a big difference
between the two choices. If your business logic is more complex or distributed on remote systems and the
processing takes a few seconds, the choices might not result in a significant difference.
You should exercise caution when comparing the impact of WS-Security and a
transport-dependent-based alternative such as HTTPS. The results of tests that only use Web services
request messages that are a simple string, and where the service itself does nothing more than echo the
message as a response, may lead you to meaningless conclusions that solutions leveraging WS-Security
will always result in significantly less performance than solutions leveraging HTTPS security mechanisms.
For example, sending a realistic 4K byte request message with a moderately complex XML structure
versus sending a 4K byte test message with a simple string increases the SOAP engine's processing time
by 30%, thus reducing the overall differences between the two security mechanisms. When your business
logic executes and has to process real business information, something other than the 25 millisecond
echo, and performs real work, you are able to genuinely understand the true impact that WS-Security will
have on your solution.
When business requirements justify message integrity between application endpoints for mission-critical
data, market-valued data, or for confidential data, digital signature capability provided by WS-Security is
the better choice and is readily available on vendors' applications servers, such as the WebSphere
Application Server.
Both XML digital signature and XML encryption will have an impact on your solution. If performance is
your primary concern over all other requirements, then HTTPS is your best choice. A common practice
today is to use XML digital signatures for application authentication and data integrity and to rely on
HTTPS to provide confidentiality. Whether the impact of using both XML digital signature and XML
encryption is trivial or significant can only be determined by enabling this capability within your application
environment using real business data and business logic, and then measuring the differences.

Page 27
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Web services management

The concept of management itself has been around for almost as long as computers have been around,
but managing Web services is a new endeavor. IBM views Web services management (WSM) as the
ability to manage a Web service and other elements of the architecture as discrete resources.

■ Must be able to discover the existence, availability, and health of the elements of the Web
services architecture.
■ Should respect policies for Web services architectural elements and control them through
configuration and operations.
■ Tools for managing Web services must supplement traditional IT management products. It is
important that the entire Web services architecture be manageable, not just the Web
services themselves.

IBM is driving the various standards bodies to develop specifications for WSM. In particular, IBM is
involved in the Organization for the Advancement of Structured Information Standards (OASIS), the World
Wide Web consortium (W3C), the Distributed Management Task Force (DMTF), and the Global Grid
Forum (GGF).
OASIS is involved in:

■ Web Services Distributed Management TC

a. Defining management using Web services

b. Defining management of Web services
c. Collaborate with W3C, GGF, DMTF, OASIS
d. OASIS has approved WSDM 1.0 as an OASIS standard
■ Provisioning TC

a. User and service provisioning

W3C has two internal groups working on WS-Management:

■ Web Services Architecture Working Group

a. Defined requirements to provide for manageable Web services architecture

implementations: information, access, discovery
■ Management Task Force

a. Defining the manageability characteristics of the architectural elements of the Web

services architecture
b. Publishing this as a W3C Note
c. WS-Management Service Lifecycle note published Feb, 2004
d. Led by IBM

DMTF models real-world managed objects. They have a large existing model. Their working groups are:

■ The Application Working Group intends to model the management of Web services.
■ The Interoperability Working Group is defining a Web services access to CIM/OMs based on
CIM/Ops and xmlCIM. (CIM is a DMTF model that is moving toward XML schema.)

GGF addresses management capabilities required in distributed computing such as distributed resource

Page 28
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

sharing, management, and integration: with desired quality of service (QoS) characteristics, using open
Internet standards.

Distributed Resources Management Enterprise quality of service

Grid services are the logical extension to Web services. Global Grid Forum (GGF) intends to drive much
of their work into the Web services community. For example, their first step is to introduce the WSDL
extensions from the OGSI specification.
IBM’s Web services management products
IBM is working on several products to support Web services management. The key IBM product for WSM
is Tivoli Monitoring for Transaction Performance (TMTP). TMTP supports transaction oriented
management of Web services. It allows you to monitor whether performance targets are being met by
Web services transactions. It allows you to view transaction history with performance violations. The
following pictures are screen captures from the TMTP tool.

Monitor transaction history and isolate the problems

Page 29
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Transaction decomposition is the technology that lets you determine where the problem is. The Topology
view will let you start with simplified transaction visualization, and drill down into it to increasing levels of
complexity. A method trace call table is available as well. Component attributes give detailed information,
including SQL statements on JDBC calls.

Where is the problem? Transaction decomposition

Page 30
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Once the problem is located you can use the tool to see the root cause of the problem and determine how
to resolve the problem.

What is the root cause? How do you fix it?

Page 31
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

The IBM Tivoli System Management Product portfolio has several products that can be applied in the
context of managing Web services. See References for more details on TMTP and other products within
IBM Tivoli System Management Products.
ETTK from IBM alphaWorks
IBM Emerging Technologies Toolkit available from IBM alphaWorks includes tools for Web services
management.
ETTK includes IBM Web Services Navigator (WSN) – an interactive tool for visualizing and understanding
the runtime behavior of deployed Web services. WSN is implemented as a plug-in extension for the IBM
Rational Application Developer version 6.0 and Eclipse workbench version 3.0.1. The IBM Web Services
Navigator uses log files of WebSphere Application Server activity recorded by a Web services data
collector, a companion technology to be released separately. Sample log files from a variety of Web
services applications are included with WSN and available for viewing with the IBM Web Services
Navigator.
To learn more about WSN and other advanced Web services tools that are part of ETTK, visit the
alphaWorks Web site available in the Reference section.

Page 32
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Summary
This module provides an overview of some of the Web services topics that often need to be addressed
when making implementation decisions. This module examines these topics and describes how they can
be used to solve business and technical challenges encountered when designing and implementing
SOAs.
The following key concepts were covered in this module:

■ Performance characteristics and best practices for Web services

■ WebSphere Application Server V6 capabilities that support the development and deployment
of scalable and robust Web services solutions
■ Interoperability challenges
■ WebSphere security versus traditional security mechanisms
■ Web services management

Page 33
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

References
The following resources provide further reading, or sources of help.

■ Apache: http://xml.apache.org .
■ IBM alphaWorks: http://www.alphaworks.ibm.com .
■ IBM Tivoli offerings are available at http://www.ibm.com/software/tivoli/ .
■ IBM Web services homepage: http://www.ibm.com/software/solutions/webservices/ .
■ Java Community Process (JCP): http://www.jcp.org .
■ New educational offerings from WebSphere Training and Technical Enablement are
available at http://www.ibm.com/developerworks/websphere/education/enablement/ and
from IBM IT Education Services at http://www.ibm.com/services/learning/ .
■ Oasis: http://www.oasis-open.org/home/index.php .
■ Performance Best Practices for Using WebSphere Web Services, Harvey Gunther,
WebSphere Developers Journal October, 2003.
■ Redbooks are available from http://www.redbooks.ibm.com .
■ Software Services for WebSphere can be found at
http://www.ibm.com/websphere/developer/services or contact a Software Services sales
specialist for your region at http://www.software.ibm.com/wsdd/services/contacts.html .
■ Technical articles, tutorials, and other resources are available from IBM developerWorks at
http://www.ibm.com/developerworks/ . For SOA and Web services follow the link
http://www.ibm.com/developerworks/webservices/newto/ .
■ Web services on WebSphere (WoW): http://www.ibm.com/websphere/wow .
■ World Wide Web Consortium (W3C): http://www.w3.org/ .
■ WS-I: http://ws-i.org .

Page 34
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.
 Technologies and Standards for Service-Oriented Architecture Project Implementation

Test your knowledge

The online version of this lecture contains a quiz you can take to test what you learned in this module.
Correct responses and your score are displayed after you answer the questions, but the scores are not
reported or recorded. You may take the quiz as often as you want.
To find the quiz, open the online version of Web services advanced technology topics to the Test your
knowledge page in the module.

Page 35
Course materials may not be reproduced in whole or in part without the prior written permission of IBM Corp.