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 company’s
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
1
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
Conversation
Feedback
Customer
Customers
Web 1.0
Contributions
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.
2
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 company’s 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
3
򐂰 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 company’s 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.
4
Case Study: Web 2.0 SOA Scenario
Enterprise
HTTP
Server
JSP
HTTP
HTTPS
Struts
Airline
Application
Server
Messaging
MQ
EMail
HTTPS
HTTPS
SOAP
Application
Server
HTTPS
HTTPS
SOAP
Struts
Hotel
HTTP Server
Java Application
J2EE Application
Client
Web Browser
Internet Service Tier
Messaging
MQ
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
JKHLE’s travel offerings from the company’s competitors.
򐂰 Similarly, third-party companies are having difficulty integrating with JKHLE’s
services, limiting the use of JKHLE’s travel services by external parties.
Case Study: Web 2.0 SOA Scenario
5
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.
6
Case Study: Web 2.0 SOA Scenario
Consumer Channel
Internet Service Domain
Service Integration Domain
Business Domain
Restful
Realization
Internet Service Tier
Weather
Application
Content
HTML, PNG, JS
Traffic
Messaging
MQ
Integration
HTTPS
JSON,
ATOM
HTTP
SOAP
ESB
RESTful
Realization
Service Proxy
3rd Parties
Hotel
HTTPS
JSON
RESTful
Realization
HTTPS
JSON
XML
ATOM
City
Info
WPS
Data Power ESB
Web Browser
HTTP Server
HTTP
JS,PNG,
HTML
Airline
Cruise
HTTPS
SOAP
RESTful
Realization
EMail
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 JKHLE’s 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
7
Client
Server
Client Runtime
Browser
HTTP request (GET, POST, PUT, DELETE)
RESTful Server
HTTP response
PAYLOAD(JSON,XML,ATOM,RSS)
Stateful application. Session
management, caching,
sufficient state for services
calls.
Stateless RESTful services.
Returns resource state and
supporting information (iscacheable, last-modified,
links to related resources).
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.
8
Case Study: Web 2.0 SOA Scenario
Build
Runtime
Targeting Developers (Dojo)
Targeting Business Users
Rational
Software
Architect
WebSphere
Application
Server
IBM Mashup
Center
WebSphere
sMash
WebSphere
sMash
WebSphere
DataPower
Web Service Provider
REST Consumer
REST Provider
Web Service Consumer
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
9
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
Service Integration Domain
Business Domain
Application
Content
HTML, PNG, JS
WPS
Hotel
HTTPS
JSON
XML
ATOM
HTTPS
JSON,
ATOM
HTTPS
SOAP
Messaging
MQ
Integration
Service Proxy
3rd Parties
RESTful
Realization
ESB
HTTPS
JSON
Data Power ESB
Web Browser
HTTP
JS,PNG,
HTML
HTTP Server
Internet Service Tier
Airline
Cruise
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
RESTful
Service
Adapter
DELETE
Each
operation
is an HTTP
method
Other Services
(SOAP, and others)
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
Web 2.0 Feature Pack
Java EE Application (EJB 3/Servlet)
Remote
System
HTTP(s)
expose Java EE Artifact as RESTful ...
HTTP(s)
X150
HTTP(s)
HTTP(s)
HTTP(s)
Browser
WebSphere Application Server
Web 2.0 Feature Pack
Java EE Application (EJB 3/Servlet)
expose Java EE Artifact as RESTful ...
HTTP(s)
Provides Web 2.0
Security for existing
RESTful/ Web 2.0
protocol endpoints.
Browser
HTTP(s)
Other
Provides security
and transformation
for non-Web 2.0
endpoints.
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
Service Integration Domain
Business Domain
Application
Content
HTML, PNG, JS
HTTPS
JSON,
ATOM
ESB
HTTPS
SOAP
Messaging
MQ
Integration
Service Proxy
3rd Parties
Hotel
HTTPS
JSON
RESTful
Realization
HTTPS
JSON
XML
ATOM
WPS
Data Power ESB
Web Browser
HTTP
JS,PNG,
HTML
HTTP Server
Internet Service Tier
Airline
Cruise
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
Ajax
Browser
Feed
Reader
JSON
Ajax
Proxy
Atom / RSS
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
Service Integration Domain
Business Domain
Restful
Realization
Internet Service Tier
HTTPS
JSON
XML
ATOM
Application
Content
HTML, PNG, JS
City
Info
WPS
Traffic
Hotel
HTTPS
JSON,
ATOM
HTTP
SOAP
ESB
Data Power ESB
HTTPS
JSON
Messaging
MQ
Integration
Service Proxy
3rd Parties
Web Browser
HTTP
JS,PNG,
HTML
HTTP Server
Weather
Airline
Cruise
HTTPS
SOAP
RESTful
Realization
EMail
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
Client
Architecture
Realization
DHTML
+
Mashups
Dojo
+
Mashups
Local
(light)
Server
Expeditor
Browser
Plug-in
Profile
Composite
Application
Shell
Expeditor
Desktop
Server
Client
Interaction
Services
UI artifacts,
data, etc.
REST
(or other)
Server
Infrastructure
Client Runtime
Eclipse, RAD,
Widget Factory,
Portlet Factory
+
Mashups,
Zero App Builder
Eclipse
+
RAD, Expeditor
CAE
+
RAD, Expeditor
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
Portlet
DOJO Dijit
Service A Consumer
DOJO Dijit
DOJO Dijit
Service B Consumer
Service C Consumer
DOJO Toolkit
HTTP(s)-AJAX
HTTP(s)-AJAX
RESTful Secure Proxy
(DataPower, WebSphere Portal, WebSphere Application Server)
HTTP(s)
RESTful Endpoint A
RENDER INITIAL
LAYOUT
HTTP(s)-AJAX
Portal Server
HTTP(s)
HTTP(s)
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