Redpaper

Martin Keen Roland Barcia Karl Bishop Edward Delio Rashmi Kaushik Matthew Perrins Doug Phillips Gregg Vay

Case Study: Web 2.0 SOA Scenario

This IBM Redpaper publication is one in a series of service-oriented architecture (SOA) papers that feature a case study involving a fictitious company named JKHL Enterprises (JKHLE). The focus of the case study in this paper is the Web 2.0 SOA scenario, and how JKHLE uses three realizations from this scenario to transform the companys travel agency business. This paper focuses specifically on the following Web 2.0 realizations: RESTful Service Creation Rendering and Consuming RESTful Services User Interface (UI) Composition and Communication

Copyright IBM Corp. 2009. All rights reserved.

ibm.com/redbooks

Web 2.0 technical overview

Web 2.0 represents an evolving World Wide Web platform. Web 1.0 refers to
connecting computers and making technology more efficient for computers. Web 2.0 is about connecting people and making technology efficient for people (see Figure 1).

Interaction Transaction Feedback Customer Customers Contributions Conversation

Web 1.0

Web 2.0

Figure 1 Web 1.0 and Web 2.0

Web 2.0 changes the way in which businesses interact with their customers. Note the following information about Web 2.0: It is about consumable services, rich Internet applications, and simplified programming models. It builds contextual relationships and facilitates knowledge sharing. It is about people and the way they collaborate.

Representational State Transfer

Representational State Transfer (REST) is the architectural model on which the World Wide Web is based. The popularity of REST is because of its simplicity and ease of consumption. REST provides the following principles: REST provides a resource-oriented approach to services (as opposed to an RPC-centric approach to services). All resources are addressable through relative URLs, for example /JKHLE/employees and /JKHLE/employees/sandy. REST typically uses HTTP as the transport protocol and supports HTTP GET POST, PUT, and DELETE.

Case Study: Web 2.0 SOA Scenario

REST-style services are easy to access from code running in Web browsers (or any other client or server) and expose and leverage existing content. Leading practices in REST derive from using the Web as it was architected and intended to be used. Specifications of interest to REST are: HTTP, MIME, Media Types, and URI. For more information about REST, go to: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

RESTful SOA
A RESTful SOA (sometimes referred to as WOA or ROA) is an instance of SOA that uses concepts from the Web as the primary service architecture: Limits choices to more easily implement an SOA Primarily uses REST to represent and access services Encodes data as JSON or XML (including XML schemas like ATOM) Might use alternate approaches such as JSON-RPC when appropriate Supports Rich User Interfaces built using AJAX A REST-style architecture maintains SOA principles. It enables a component-centric model in which various server-side and client components can be reused in a scalable but simple way1.

Introduction to the case study

JKHL Enterprises (JKHLE), as mentioned, is a fictitious company that is looking to expand its travel agency division. In this section, we introduce the JKHLE company, look at the companys business and technical challenges, and examine its current infrastructure (the as-is architecture).

JKHL Enterprises in the travel industry

JKHLE has a travel agency division that uses an online travel Web site to offer one-stop shopping for all travel services. The focus areas of the travel agency business are: Flight reservations Hotel reservations
1

Source: http://www.projectzer.org

Case Study: Web 2.0 SOA Scenario

Cruise reservations Weather conditions Traffic conditions City information (such as directions and areas of interest) JKHLE wants to develop a best-of-breed travel Web site. This Web site should offer easy-to-use services for customers and simplify the companys underlying business processes.

JKHL Enterprises business challenges

JKHLE is presented with the following business challenges that it must address: Provide a fast and easy architecture to deliver new products to consumers and partners quickly. Consume new interfaces from third parties such as weather and traffic reports. Remove business silos by leveraging SOA infrastructure and consumable service end points. Provide fast and simple, nondisruptive additions of new business data and services. Reduce call center costs. Expose business data to the public Internet in a consumable form.

As-is architecture and technical challenges

The current (as-is) architecture used by JKHLE is shown in Figure 2 on page 5.

Case Study: Web 2.0 SOA Scenario

Enterprise Internet Service Tier

Web Browser

HTTP Server

JSP HTTP

HTTPS

Struts Airline Application Server

Messaging MQ

J2EE Application Client

EMail
HTTPS HTTPS SOAP

Struts Hotel
Messaging MQ

HTTP Server

Application Server

Java Application

HTTPS HTTPS SOAP

Cruise Application Server

Weather

Figure 2 As-is architecture

This architecture presents the following technical challenges: Business policies are embedded in the business process. Changes to business policies require updates to the business process, which is slow, expensive, and error prone. As JKHLE continues to expand, this restriction becomes ever more important. Each business system operates in a silo, which causes significant problems when trying to realize a multiple-channel strategy for customers. Integrating third-party services into the overall solution is difficult. The inclusion of these third-party services is important, and helps to differentiate JKHLEs travel offerings from the companys competitors. Similarly, third-party companies are having difficulty integrating with JKHLEs services, limiting the use of JKHLEs travel services by external parties.

Case Study: Web 2.0 SOA Scenario

Using the Web 2.0 SOA scenario realizations

The Web 2.0 SOA scenario can be used to help JKHLE solve its business and technical challenges. This scenario defines three realizations: RESTful Service Creation realization Describes resource-based pattern that map to data sources. Rendering and Consuming RESTful Services realization Describes the formatting of data to be rendered, and the consuming of data based on RESTful service architectures. UI Composition and Communication realization Describes the presenting of data that is collected from RESTful services to users. Each realization can be combined or used individually to address a business solution.

To-be architecture
To solve its business and technical challenges, JKHLE builds a new architecture using the principles of the Web 2.0 SOA scenario. Figure 3 on page 7 shows this architecture, along with places where a realization is used.

Case Study: Web 2.0 SOA Scenario

Consumer Channel

Internet Service Domain Internet Service Tier

Service Integration Domain

Business Domain

Restful Realization

Weather
HTTP JS,PNG, HTML

Web Browser

HTTP Server

Application Content HTML, PNG, JS

WPS

City Info Traffic

HTTPS JSON

Hotel

Data Power ESB

ESB

Service Proxy

HTTPS JSON, ATOM

Messaging MQ

Integration

RESTful Realization

RESTful Realization

HTTP SOAP

Airline

Cruise RESTful Realization EMail

3rd Parties

HTTPS JSON XML ATOM

HTTPS SOAP

Figure 3 To-be architecture

This to-be reference architecture offers the following advantages: Business logic and business policies are now separate entities, enabling the fast, simple, nondisruptive addition of variations into the process. Simplified development interfaces enable the JKHLE business process to more easily make calls to third-party services, and also make it easier for third party services to invoke JKHLEs services. New services and new channels can be quickly integrated into the architecture.

Solution pattern for clients and RESTful servers

The to-be architecture adopted by JKHLE makes use of the design pattern between clients and RESTful servers, as shown in Figure 4 on page 8.

Case Study: Web 2.0 SOA Scenario

Client
Client Runtime Browser HTTP request (GET, POST, PUT, DELETE)

Server

RESTful Server HTTP response PAYLOAD(JSON,XML,ATOM,RSS) Stateless RESTful services. Returns resource state and supporting information (iscacheable, last-modified, links to related resources).

Stateful application. Session management, caching, sufficient state for services calls.

Figure 4 Solution pattern for clients and RESTful servers

This solution pattern is used as follows: A client (typically a rich Internet application (RIA)) prepares a resource-based call to a RESTful server. The server returns a payload of JSON, XML, RSS or ATOM back to the client. This is consumed by the RIA or calling service. The client uses the GET, POST, PUT, or DELETE methods on XMLHttpRequest (XHR) calls to map to RESTful entity behaviors.

Product mappings
Figure 5 on page 9 shows the products used by JKHLE to implement the to-be reference architecture.

Case Study: Web 2.0 SOA Scenario

Build Targeting Business Users

Runtime Targeting Developers (Dojo)

Rational Software Architect

IBM Mashup Center

WebSphere Application Server

WebSphere sMash

WebSphere sMash

WebSphere DataPower

Web Service Provider REST Consumer Web Service Consumer

REST Provider

Figure 5 Product mappings

In the remaining sections of this paper, we provide more details about each realization and the products JKHLE used to implement each realization.

Case Study: Web 2.0 SOA Scenario

RESTful Service Creation realization

The RESTful Service Creation realization is used by JKHLE to address interactions between the Internet service domain and service integration domain as shown in Figure 6 on page 10.

Consumer Channel

Internet Service Domain Internet Service Tier

Service Integration Domain

Business Domain

Web Browser

HTTP Server

HTTP JS,PNG, HTML

Application Content HTML, PNG, JS

WPS

HTTPS JSON

Hotel

Data Power ESB

ESB

Service Proxy

HTTPS JSON, ATOM

Messaging MQ

Integration

RESTful Realization

HTTPS SOAP

Airline

Cruise

3rd Parties

HTTPS JSON XML ATOM

HTTPS SOAP

EMail

Figure 6 Where JKHLE uses the RESTful Service Creation realization

The following architectural considerations are relevant to the RESTful Service Creation realization: Data sources to create RESTful services (such as Web services, databases, and screen scraping) Java objects (such as Java beans, EJB 3 and JPA) Resource models map to back-end entities Security Governance

10

Case Study: Web 2.0 SOA Scenario

Design patterns
This section describes two design patterns for the RESTful Service Creation realization. The first design pattern in shown in Figure 7 on page 11.
Each resource has a URL GET POST Browser PUT DELETE Each operation is an HTTP method Other Services (SOAP, and others) RESTful Service Adapter

Figure 7 Design pattern

This design pattern describes the following information: Existing legacy data is converted into a RESTful service. Each resource has a URI/URL and these resources are exposed by using the REST entity patterns. A simplified entity naming convention can be used. For example GetOrderServices?ordernumber=12345 changes to /rest/orders/12345. Each operation offered by the RESTful service is an HTTP method. For example a resource with the URI /JKHLE/hotel/reserve can be invoked by using GET /JKHLE/hotel/reserve. The RESTful service is responsible for calling the application service. This application service could be connected to an enterprise service bus on another back-end service through an adapter. The second design pattern is shown in Figure 8 on page 12

Case Study: Web 2.0 SOA Scenario

11

WebSphere Application Server

Remote System HTTP(s) X150 HTTP(s) Browser HTTP(s) Provides Web 2.0 Security for existing RESTful/ Web 2.0 protocol endpoints. Provides security and transformation for non-Web 2.0 endpoints. HTTP(s) HTTP(s)

Web 2.0 Feature Pack Java EE Application (EJB 3/Servlet)

HTTP(s)

expose Java EE Artifact as RESTful ...

HTTP(s)

WebSphere Application Server Web 2.0 Feature Pack Java EE Application (EJB 3/Servlet) expose Java EE Artifact as RESTful ...

Other

Browser

Other Services (SOAP, etc...)

Figure 8 Design pattern

This design pattern describes how the pattern is built: Build Java Enterprise Edition (Java EE) artifacts such as EJBs, servlets, or reuse existing Java EE artifacts. Use the WebSphere Application Server Feature Pack for Web 2.0 to expose these artifacts as JSON over HTTP or XML over HTTP entities. Use WebSphere DataPower in the DMZ to add additional Web 2.0 security services and transformations where necessary. Deliver the correct HTTP content based on the client. For example deliver JSON to Web browsers and XML, ATOM, and RSS to other clients.

Rendering and Consuming RESTful Services realization

The Rendering and Consuming RESTful Services realization is used by JKHLE to address interactions between the consumer channel and the Internet service domain, as shown in Figure 9 on page 13.

12

Case Study: Web 2.0 SOA Scenario

Consumer Channel

Internet Service Domain Internet Service Tier

Service Integration Domain

Business Domain

Web Browser

HTTP Server

HTTP JS,PNG, HTML

Application Content HTML, PNG, JS

WPS

HTTPS JSON

Hotel

Data Power ESB

ESB

Service Proxy

HTTPS JSON, ATOM

Messaging MQ

Integration

RESTful Realization

HTTPS SOAP

Airline

Cruise

3rd Parties

HTTPS JSON XML ATOM

HTTPS SOAP

EMail

Figure 9 Where JKHLE uses the Rendering and Consuming RESTful Services realization

The following architectural considerations are relevant to the Rendering and Consuming RESTful Services realization: Response payloads (such as XML, JSON, ATOM, and RSS) Governance for REST interface grouping Security (including HTTPS and SPNEGO)

Case Study: Web 2.0 SOA Scenario

13

Runtime considerations
The following products can be used to implement the Rendering and Consuming RESTful Services realization: WebSphere Application Server Feature Pack for Web 2.0 Exposes Java EE based artifacts through REST. WebSphere sMash Provides a development and runtime environment for creating Web 2.0 applications. Provides tight REST integration with Dojo widgets and Groovy or PHP scripting. WebSphere DataPower Provides a Web 2.0 application with support for REST-SOAP and JS inspection. The role that these products play and the design patterns for using these products in the Rendering and Consuming RESTful Services realization are described in this section.

WebSphere Application Server Feature Pack for Web 2.0

The Web 2.0 Feature Pack extends the capabilities of WebSphere Application Server with the following components: Web 2.0 to SOA connectivity This component is for enabling connectivity from Ajax clients to SOA services and other Java EE assets. This component extends enterprise data to customers and partners through Web feeds. Ajax messaging This component is for connecting Ajax clients to real-time updated data such as stock quotes or instant messaging. Ajax development toolkit This component is a best-in-class Ajax development toolkit for WebSphere Application Server based on Dojo, an open source JavaScript run time. The Web 2.0 Feature Pack can be used in the design pattern shown in Figure 10 on page 15.

14

Case Study: Web 2.0 SOA Scenario

Ajax Browser

Ajax Feed Reader

JSON

Atom / RSS

Ajax Proxy

Web Remoting

Web Feeds

SOA / JEE Assets WebSphere Application Server External Web Services

Figure 10 Design pattern

This design pattern enables connectivity with Ajax clients and mashups to external Web services, internal SOA services, and other Java EE assets. It extends enterprise data to customers and partners through Web feeds.

WebSphere sMash
WebSphere sMash enables developers to quickly build and execute agile, Web 2.0-based applications with PHP scripting, REST, and Dojo in an integrated runtime and tooling package. WebSphere sMash focuses on rapid time to market, ease of development and deployment, and convention over configuration. WebSphere sMash provides clean and simple REST interfaces. Each REST entity is defined by an event handler file, with unique functions that are mapped to the REST verbs. For example the REST verb POST is mapped to the event method onCreate() and has a sample URL of /resources/people. WebSphere sMash provides automatic transformation of response data to XML, JSON, and ATOM.

WebSphere DataPower
WebSphere DataPower is a family of specialized network appliances that help to integrate, simplify, secure, and accelerate SOA. WebSphere DataPower can be

Case Study: Web 2.0 SOA Scenario

15

used to support the Rendering and Consuming RESTful Services realization in a number ways: RESTful resource aggregation Scenario: A resource request spans multiple service implementations. The results of these calls have to be aggregated or assembled into a complex report. Solution: WebSphere DataPower acts as an intermediary that defines an aggregate resource URI. This intermediary fans out requests to providers and aggregates responses. Media type transformation Scenario: An existing provider implements a single media type, and clients require additional media types. Solution: WebSphere DataPower acts as an intermediary that transforms the Accept header in the request message, and transfers the entity body and Content-Type header in the response message. This solution exploits wire-speed transformation. REST / SOAP mediation Scenario: A provider supports REST but existing clients require SOAP. Solution: WebSphere DataPower acts as an intermediary that exposes SOAP. It transforms request messages from SOAP to REST, and transforms response messages from REST to SOAP. Version mediation Scenario: Consumers and providers evolve independently. The goal is to minimize the number of providers implementations. Solution: WebSphere DataPower acts as an intermediary that proxies multiple resource versions. Resource requests are cast to newer versions. Any necessary heading and entity transformation, enrichment, or filtering is also performed. Quality of service mediation Scenario: Consumers sign contracts that ration the use of resources. The usage contract must be monitored and enforced based on request rates and volume. Solution: WebSphere DataPower acts as an intermediary that monitors and enforces quality of service limits, throttling and shaping requests as necessary.

16

Case Study: Web 2.0 SOA Scenario

UI Composition and Communication realization

The UI Composition and Communication realization is used by JKHLE to provide additional functionality in the business domain, as shown in Figure 11.

Consumer Channel

Internet Service Domain Internet Service Tier

Service Integration Domain

Business Domain

Restful Realization

Weather
HTTP JS,PNG, HTML

Web Browser

HTTP Server

Application Content HTML, PNG, JS

WPS

City Info Traffic

HTTPS JSON

Hotel

Data Power ESB

ESB

HTTP SOAP

Service Proxy

HTTPS JSON, ATOM

Messaging MQ

Integration

Airline

Cruise RESTful Realization EMail

3rd Parties

HTTPS JSON XML ATOM

HTTPS SOAP

Figure 11 Where JKHLE uses the UI Composition and Communication realization

The following architectural considerations are relevant to the UI Composition and Communication realization: Stateless entities Frameworks (such as Dojo and JSF) Containers (such as portlets, iWdigets, and iViews) Governance Security (including HTTPS and single sign-on).

Case Study: Web 2.0 SOA Scenario

17

Runtime and tool considerations

A wide choice of client software and technologies is available, and IBM recognizes that it has to support all areas of this spectrum from heterogeneity to client SOA. To achieve this, IBM has the following strategy: Support UI aggregation through standards. This includes Web standards (such as JSR 53 and JSR 127), portlet applications (such as JSR 286, and JSR 168), mashups (such as OpenAjax and iWidget), and rich desktops/devices (such as Eclipse and iView). Deliver open aggregation through products. IBM promotes and accommodates technology for application content. This includes W3C open / Web standards and open frameworks for client containers (such as Web browsers and Lotus Expeditor) and Eclipse and SWT for desktop and mobile applications. Support client UI integration through middleware. IBM fully supports integration between the user integration, edge integration, and SOA layers. The IBM end-to-end software client platform strategy is shown in Figure 12.

18

Case Study: Web 2.0 SOA Scenario

Adobe Other Creative tools Suite

Designer Tools
Architecture DHTML + Mashups Realization Dojo + Mashups Eclipse, RAD, Widget Factory, Portlet Factory + Mashups, Zero App Builder Eclipse + RAD, Expeditor CAE + RAD, Expeditor

Client

Client Interaction Services

Server UI artifacts, data, etc. REST (or other) Local (light) Server Composite Application Shell Expeditor Browser Plug-in Profile Expeditor Desktop

Server Infrastructure

Client Runtime

Developer Tools

Figure 12 The IBM end-to-end software client platform strategy

Dojo
Dojo is an Open Source DHTML toolkit written in JavaScript. Dojo enables you to easily build dynamic capabilities into Web pages. Dojo provides a lot of power and consists of three major layers: Dojo Core, Dijit, and DojoX. The Dojo Toolkit is a JavaScript toolkit for developing Ajax applications with rich user interfaces. It works well across most modern client containers and has a small footprint with high function. IBM supports the Dojo Toolkit; Ajax applications that are created in the Dojo Toolkit can be used with WebSphere Application Server and WebSphere Portal. The Dojo Toolkit is available for download at: http://www.dojotoolkit.org/

Case Study: Web 2.0 SOA Scenario

19

Design pattern
WebSphere Portal and Dojo can be used to support the UI Composition and Communication realization as illustrated in the design pattern shown in Figure 13.

Browser Portlet
DOJO Dijit Service A Consumer

Portlet
DOJO Dijit Service B Consumer DOJO Dijit Service C Consumer

DOJO Toolkit HTTP(s)-AJAX HTTP(s)-AJAX HTTP(s)-AJAX

RENDER INITIAL LAYOUT

RESTful Secure Proxy (DataPower, WebSphere Portal, WebSphere Application Server)

Portal Server

HTTP(s)

HTTP(s)

HTTP(s)

RESTful Endpoint A

RESTful Endpoint B

RESTful Endpoint C

Figure 13 Design pattern

This design pattern describes the following information: WebSphere Portal supports portlets that are Ajax-enabled by using IBM Rational Application Developer or Portlet Factory to generate these portlets. This approach allows for select fragment updates. Dojo Dijit is used to render widgets within the portlet. The portlet is written to invoke a RESTful service.

20

Case Study: Web 2.0 SOA Scenario

Summary
JKHL implements solutions that are based on all three realizations of the Web 2.0 SOA scenario: RESTful Service Creation realization Rendering and Consuming RESTful Services realization UI Composition and Communication realization Using these realizations enabled JKHLE to build a better travel agency Web site that provides a fast architecture to deliver new products and consume new services, removes business silos, and exposes business data to the Internet in a consumable form.

IBM SOA Sandbox

Get hands-on experience at no cost with the IBM SOA middleware portfolio in a Cloud environment through the IBM SOA Sandbox at: http://www.ibm.com/developerworks/downloads/soasandbox/

Case Study: Web 2.0 SOA Scenario

21

The team who wrote this IBM Redpaper

This paper was produced by a team of specialists from around the world: Martin Keen is a Consulting IT Specialist, IBM International Technical Support Organization (ITSO). Roland Barcia is a Senior Technical Staff Member, IBM Software Service for WebSphere Web 2.0 Lead Architect. Karl Bishop is with Web Enablement and Support, IBM Software Services for WebSphere. Edward Delio is a Development Manager, IBM Optim Application Aware Products. Rashmi Kaushik is an SOA Scenarios Product Manager, SOA Portfolio Consumability. Matthew Perrins is an Executive IT Specialist, IBM SOA Strategy. Doug Phillips is an Advisory Software Engineer, IBM Software Services for WebSphere. Gregg Vay is a Software Engineer, IBM Business Partner Technical Strategy and Enablement.

22

Case Study: Web 2.0 SOA Scenario

Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright International Business Machines Corporation 2009. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

23

This document REDP-4555-00 was created or updated on September 17, 2009. Send us your comments in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an email to: redbook@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099, 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A.

Redpaper
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol ( or ), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: DataPower IBM Lotus Optim Rational Redpaper Redbooks (logo) WebSphere

The following terms are trademarks of other companies: EJB, Java, JavaScript, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

24

Case Study: Web 2.0 SOA Scenario