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:
s s s s s s

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 IBMs 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:
s

s s

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 dont 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:
s

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.

s s s

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
s s

Reliable delivery of messages Support for broadcast and queued modes of requests

RMI-IIOP offers
s s

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:
s s s s

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:
s

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.

s s

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:
s s

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:
s

Manage request and response messages a. Read whats 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 http://www.ibm.com/developerworks/webservices/library/ws-tipjax2.html . handlers, see

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:
s s

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:
s s s

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:
s s s s s

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:
s s s s s s s s

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 industrys 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 vendors 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.
s

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:
s s s s

The input message has a single part. The part is an element. The element has the same name as the operation. The elements complex type has no attributes.

In summary:
s s

s s

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-Is 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-Is Attachments Profile (AP) addresses the few interoperability issues that existed with SW/A. So, if you conform to WS-Is AP 1.0, and your vendors 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:
s s

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.
s s s s

Dont 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. Dont 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 statements 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, Javas 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:
s s

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 IBMs 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 versions 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 attributes 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 implementations 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 services 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:
s

Security is not one-size-fits-all. a. Proper usage requires analysis of application-specific security requirements.

s s

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:
s

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:

s

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:

s s

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
s

s s s s s s s s

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:

s

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:
s s s s s

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:

s

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

s

s s

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

s s

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:

s

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.
s

s s

When the application invoking the Web service is a middle tier and wants to propagate the users 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 users 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.
s s s

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:
s

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:

s

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:
s s

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. IBMs 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:
s s s s s

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.
s s s s s s

s s s s

s s s

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.