Building Service-Oriented Architectures (Soas) With Web Services

Building Service-Oriented Architectures (SOAs)
with Web Services

OOPSLA 2006 Tutorial #16
Olaf Zimmermann
IBM Corporation
Updates available from: http://www.perspectivesonwebservices.de
Building SOAs with Web Services

Copyright is held by the author/owner(s). OOPSLA'06, October 22–26, 2006, Portland, Oregon, USA. 2006 ACM 06/0010
October 2003
1
Agenda
 Module 1: Introduction to SOA

 Defining principles
 SOA patterns: Enterprise Service Bus, Service Composition
 Module 2: Introduction to Web Services

 SOAP, WSDL, UDDI
 JAX-RPC and other Java standards
 Module 3: Developing Web Service Provider and Requestor Applications

 Java, PHP, and Ruby
 Module 4: SOA/Web Services Best Practices

 Key architectural decisions
 SOAP, WSDL, UDDI, and SOA best practices

7 Copyright is held by the author/owner(s). OOPSLA'06, October 22–26, 2006, Portland, Oregon, USA. 2006 ACM 06/0010
Building Service-Oriented Architectures
with Web Services
Module 1: Introduction to SOA
There have been other

distributed computing models,
but this time it’s serious.
This is just another reinvention
of the wheel, the most pointless
hype in years.

October 2003
8
Module 1: Agenda
 Motivation for service-oriented computing
 Defining principles
 Key SOA patterns and project examples
 SOA and Web services implementation options
 Summary

General challenges in enterprise application development
 Many users and backend systems interact with the system

 Numerous functional and technical entry channels
 Custom applications and software packages to be integrated
 Sophisticated Quality of Service (QoS) requirements and other

Non-Functional Requirements (NFRs), for example:
 Response times to be guaranteed, even under heavy load
 Transactional integrity in long-running workflow scenarios
 Hardly any green field

 Multiple technology stacks, stovepipe architectures, interface spaghetti
 Valuable data and business logic in systems that have been developed
under tight budget and scheduling constraints
 The only constant is change

 Requirements, technology, environment dynamics

Typical status quo in many enterprise IT architectures
 Functional and technical application monoliths ubiquitous

 Stovepipe architectures, application scope creep, redundant
implementations, data management and many other agility issues
 Architectural governance or guidance missing
 Development and integration projects costly and long running

 Proprietary point-to-point connections, often developed from scratch
 File transfer is a frequently used integration pattern with numerous
architectural drawbacks
 Roll-your-own philosophy works short term, but leads to maintenance
headaches
 As a result, horizontal initiatives are much harder to implement

than they have to be
 Example: single customer relationship management solution on top of
several line-of-business applications (packages and custom developed)

Solution: evolve and integrate former monoliths into a
Service-Oriented Architecture (SOA) ecosystem
Service-Oriented
Component-Based Architecture
Development Enterprise Application
Integration (EAI)
Messaging Backbone
 Integration and choreography of

services through an Enterprise
 EAI connects applications Service Bus
via a centralized hub  Flexible connections with well
 Easier to manage larger defined, standards-based
 Point-to-Point connection number of connections interfaces
between applications
 Simple, basic connectivity
Source: [IBM SOA]

SOA benefits: modularity, layering, and loose coupling
Business Process
Today Tomorrow
QoS, Security, Management & Monitoring

(Enterprise Service Bus)
(Infrastructure Services)
Services
Integration Architecture
Applications Services
Components
Discrete Applications Basket of Services
Example:
Cross-line of business customer relationship process can leverage logic
and data available as platform-independent services, provided by
components residing in three existing line-of-business applications.
Cross-cutting integration and infrastructure concerns are factored out and
form two separate vertical layers.
Source: [IBM SOA]

Module 1: Agenda
 Key SOA patterns and project examples for them
 Summary

What is a Service-Oriented Architecture (SOA)?
“SOA is different things to different people” Business

Executive,
Consultant
 a set of services that a business wants to expose to their
customers and partners, or other portions of the organization
Architect
 an architectural style which requires a service provider, requestor
and a service description
 a set of architectural principles, patterns and criteria which address
characteristics such as modularity, encapsulation, loose coupling,
separation of concerns, reuse, composability and single
implementation
Programmer
 a programming model complete with standards, tools and

technologies such as Web services
Source: [IBM SOA]

SOA building blocks on the three levels of abstraction
Business
Executive,
Business-Aligned Service Descriptions Consultant
(Interface Contracts)
Architect
Separation of Concerns Loose Coupling
and Modularity and Messaging
Service Repository/ Enterprise Service Bus

Service Composition
Registry (ESB)
Programmer
Development Execution Runtimes XML & Web Services Internet

Tools (e.g. J2EE) Standards Protocols

While SOA is an architectural style, Web services are enabling
technology standards. They are not the same thing.
Functions Quality of Service
Business Process
Service
Directory
Service
Service Registry
Management
1. Publish
Transaction
2. Find
Security
Policy
Service Description
UDDI WSDL
Service Communication Protocol
3. Use
Transport
Service Service
Consumer Provider
SOAP
 Simplified definition: SOA is an architectural style whose goal is to achieve loose coupling
among interacting software agents
 SOA proposes an advancement in the programming model
 It is the next evolution in software engineering from Object-Oriented Programming &
Component-Based Development – but can be layered on top of these approaches
 Web services and SOA are not the same thing:
 Many existing production SOAs do not primarily use Web services – they are built on
Message-Oriented Middleware (MOM)
 Not all deployed Web services-based systems necessarily embrace all the guiding
principles of SOA (e.g. loose coupling) Source: [IBM SOA]
Web services essence: service descriptions, service
invocations, etc. expressed as XML documents
UDDI
Registry
Service
Broker
find
publish
WSDL
WSDL Service Provider Service Requester
bind, invoke
Message
Ha
Service
AP
Service
nd
Provider Requester SO
le
r
SOAP
Service
Web SOAP Client Backend or Requester
Internet Handler
Service Application Legacy (Proxy) Application
Application
WSDL
Source: [IBM ITSO] WSDL description

is generated by
Code for handling
messages is
inspecting existing generated from
application Integrated Environment (IDE)
Development Environment
Integrated Development (IDE) WSDL description

Completing the Web services stack: secure, reliable,
transacted Web services
Source: [Ferguson]
 WS-Security suite
 WS-ReliableMessaging
 WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity
(currently under standardization at OASIS and WS-I)

SOA = Same Old Architecture?
 Separation of concerns and modularization:

 Key principle of modularization established by D. Parnas (1972)
 Design-by-contract as promoted in Eiffel, B. Meyer (~1988)
 Notion of interfaces: hardware design, many other domains
 Logical layering ... another well-established principle:
 Seven layer ISO OSI stack for networking (1980s)
 Architecture and design patterns literature [GoF], [POSA]
 Distributed computing environments with multi-platform support:
 DCE RPC (1980s/90s)
 CORBA (since the 1990s)
 Messaging, multiple transports and message exchange patterns:
 Message-Oriented Middleware (since the 1990s and earlier)
 EAI adapters and broker products (since the 1990s)

Object-Orientation (OO) vs. Service-Orientation (SO)
 OO and SO share many characteristics, but differences exist as well

 Encapsulation, information hiding through interfaces (OO and SO)
 Remote objects and call stack (OO) vs. document-centric messaging (SO)
 Name and type as linking element (OO) vs. bindings and contracts (SO)
 Rule of thumb: develop object-oriented and integrate service-oriented

(SO on macro level vs. OO on micro level):
 OO is a general-purpose programming paradigm
 SOA is an architectural style for enterprise application integration
 Web services consumers and providers (the enterprise systems to be
integrated) can be OO applications or other
 Service autonomy should be strived for, see [Ferguson]

Module 1: Agenda
 Summary

Layered SOA reference architecture and service modeling
An SOA is composed of multiple layers. At the heart of the SOA
is the Service Model that defines Services and Components that
realize them.
Presentation 5 6 7
Portlets
Consumer
Service
Monitoring (Infrastructure Service)

Business Process
QoS, Security, Management &

Service Modeling
(Enterprise Service Bus)

Integration Architecture
Service Composition
3
Services
Atomic Services
2
Components
Enterprise Components
Provider
Service
1
Custom Package
Custom
Application Package
Application
Existing Application Resources
Composite
service
Simple Source: [IBM SOA]

service

SOA Pattern: Enterprise Service Bus (ESB)
 Refinement of well-established broker pattern described in [POSA]

 Decentral hub-and-spoke architecture known from many EAI products,
providing many-to-many connectivity between loosely coupled parties
(the ‚B‘ in ESB)
 Plus explicit, formal service interface contracts (the ‚S‘ in ESB)
 Plus business alignment and high-end quality of service
(the ‚E‘ in ESB)
 Key capabilities (refer to [Keen] for details):

 Multiple transport layers and message exchange patterns (service
invocation styles)
• Synchronous communication
• Asynchrony (of service invocations) ... key for loose coupling!
 Mediations for content-based routing, format conversions,
housekeeping
 Descriptive, policy-based configuration and management

SOA Pattern: Service Composition
 Following well-established principles such as logical layering and

separation of concerns, the business logic layer of n-tiered
enterprise applications can be factored into two sub-layers:
 Role-based (work-)flow or process layer
 Atomic service layer (computations, validations, entity management)
 One implementation option for the process layer is the Web

Services Business Process Execution Language (WS-BPEL)
 Currently under standardization at OASIS
 Key issues:
 Where to draw the line between the two sublayers?
 How to interface with the presentation layer?
 What is a good atomic service?
 Integration of package and legacy workflows?

UML representation of ESB and BPEL Service Composition

OOPSLA 2004: ESB and Web services in real-world project
Platform WSDL Documentation

Java Client .NET Client Browser Office
independent
IBM generate
WebSphere® SOAP SOAP SOAP
(pSeries) Web
Application
generate
Web Services Adapter Layer
JavaTM API (Dynamic Interface)
Dynamic Interface
Java Backend Connectors (IBM WebSphere MQ, CICS®) Repository
Access Layer
Database generate
(IBM DB2®)
Business Function
IBM
CICS
(zSeries)

Multi-channel order management supporting a wholesaler-retailer business
model in the telecommunications industry (OOPSLA 2005)
 Functional domain:
Order entry management
Two business processes:
new customer, relocation
 Main SOA drivers:

Deeper automation grade
(e.g. compensation)
Services shared within
and between domains
 Service composition:
Top-down from retailer
interface and process
Bottom-up from existing
wholesaler systems

Module 1: Agenda
 Summary

Some industry incarnations of SOA (in alphabetical order)
Vendor Selected SOA/WS Offering (s)
BEA J2EE application server; SOA infrastructure management

offering: http://dev2dev.bea.com/soa
IBM J2EE application server; SOA is an inherent part on
demand business strategy, products and services. The
developer portal features an SOA and Web services zone:
http://www.ibm.com/developerWorks/webservices
IONA CORBA products, open source ESB recently announced:
http://www.iona.com/products
Microsoft .NET SDK, Web Services Extensions (WSE), Information
Bridge Framework (IBF):
http://msdn.microsoft.com/architecture/soa/default.aspx
SAP Enterprise Service Architecture (ESA), NetWeaver:
http://www.sdn.sap.com/irj/sdn/developerareas/esa
Various system integrators SOA practices evolving from EAI/J2EE/BPM base,
and consulting firms e.g. SOA white paper from [ThoughtWorks],
available from http://www.eaipatterns.com

A few of many Web services implementation assets
Language Web Services Support

Java Web services suppport is mandatory in J2EE 1.4
BEA WebLogic
IBM WebSphere
Other J2EE 1.4-compliant application servers
Other commercial offerings
Systinet WASP
Open source assets
Apache Axis2, Axis 1.2/1.3, Codehaus Xfire
Microsoft languages Native support in .NET 1.1, Web Services Extensions
(C#, VisualBasic) (WSE), Information Bridge Framework (IBF)
MS Office support via SOAP Toolkit (now deprecated)
Perl SOAP::Lite and others
PHP NuSOAP (SourceForge project)
PHP 5 SOAP Extension (native C implementation)
Ruby Basic support in Ruby on Rails via Action Web Service

Module 1: Agenda
 Summary

How do Web services-based SOAs help addressing common
enterprise application development and integration challenges?
Challenge Response
Flexibility and agility Logical layering

Separation of concerns
Matchmaking via bindings rather than name and type
Bridging business-IT gap Business-aligned service models
Business performance management and composition enabled
through WSDL contracts and BPEL
Evolve proprietary Standardized interface contracts (WSDL, semantics, policy)
monoliths into reusable Integration via ESB
components Split business logic layer into process and atomic service layer
Many legacy Document messaging rather than tightly coupled RPC
applications Interoperable protocols such as SOAP
(no green field) Patterns such as adapter and facade
Time-to-market Increase productivity through standardization and off-the-shelf
tool support

Module 1: Summary
 SOA is a state-of-the-art architectural style for crafting enterprise

applications of quality and longevity
 Benefits include agility, flexibility, reuse, productivity gains, openness
 SOA comprises many well-established software engineering

principles and patterns
 Some of which 30+ years old (nothing wrong with that!)
 SOA adopts them for one particular problem domain – enterprise
application development and integration
 Web services are a highly attractive implementation alternative for

SOA (but not the only one)
 Well-suited for connecting heterogeneous worlds
 Core specification are simple and well supported by tools and runtimes
 Higher layers of stack currently under standardization, e.g. [RAMP]

References
[CBDI] Sprott, D.: On SOA Methodology, Editorial March 2005 CBDI Journal,
http://www.cbdiforum.com/report_summary.php3?page=/secure/interact/2005-
03/editorial.php&area=bronze
[Ferguson] Ferguson D., Storey T., Lovering B., Shewchuk J., Secure, Reliable, Transacted Web
Services, http://www.ibm.com/developerworks/webservices/library/ws-securtrans/index.html
[GoF] Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns – Elements of Reusable Object-
Oriented Software. Addison-Wesley, 1995
[IBM SOA] Service-Oriented Architecture from IBM – Success Stories, Products, Services
http://www.ibm.com/software/solutions/webservices/soa
[IBM ITSO] Wahli U., Application Developer Version 6 Web Services, IBM ITSO Workshop 2005,
http://www.redbooks.ibm.com
[Keen] Keen M. et al, Patterns: Implementing an SOA using an ESB, IBM Redbook 2004
[POSA] Buschmann F., Meunier R., Rohnert H., Sommerlad P., and Stal M., Pattern-Oriented Software
Architecture – a System of Patterns. Wiley, 1996
[PoWS] Zimmermann O., Tomlinson M., Peuser S., Perspectives on Web Services – Applying SOAP,
WSDL and UDDI to Real-World Projects, Springer-Verlag, 2003
[RAMP], Reliable, Asynchronous Messaging Profle 1.0, IBM, Ford Motor Company, DaimlerChrysler,
http://www.ibm.com/developerworks/webservices/library/specification/ws-ramp
[SAP] ESA zone of SAP Developer Network (SDN), via http://www.sdn.sap.com/sdn/esa.sdn
[ThoughtWorks] Hohpe G., Developing Software in A Service-Oriented World, ThoughtWorks White
Paper January 2005, http://www.eaipatterns.com

with Web Services
Module 2: Web Services Concepts
Web services reuse well-

established and proven
concepts.
I’ve already skimmed through
This module is excerpted from the book “Perspectives on Web some WSDL, and I didn’t
services” by Olaf Zimmermann, Mark Tomlinson, and Stefan Peuser,
Springer-Verlag Berlin Heidelberg New York 2003, ISBN 3-540- understand a single line.
00914-0. This work is subject to copyright. © Springer Verlag 2003.
All rights reserved.

October 2003
40
Module 2: Agenda
 Building blocks for delivering SOA with Web services

 XML
 SOAP
 WSDL
 UDDI
 Security
 Interoperability
 Java and J2EE

Building blocks for delivering a service-oriented architecture
implemented with Web services
Interpretation of the core specifications and links through the WS-I Basic Profile 1.1

Building Blocks: XML

XML, XML Namespaces and XML Schema introduction
 XML [XML]
 Markup language composed of
tags and data
 Elements and attributes
 Read by an XML processor
 Requires grammar definition
 Valid and well-formed
XML instance document example
 XML Namespaces [XMLNS]

 Global naming mechanism for XML
 Qualified names: prefix and local parts
 Multiple namespaces in same document XML Schema, DTD
(XML Document
 XML Schema [XMLSch] Grammar) XML Instance,
valid Instance Document
 Provides grammar for XML instance docs Documents
 Built-in types
XML document grammar and valid XML instances
 Simple and complex custom data types

Building Blocks: SOAP

SOAP introduction
 SOAP message elements: Envelope, Headers, Message Body and Faults

 Two communication styles: Document style, RPC style
 Literal or SOAP encoding of message body plus attachments support
SOAP message containment

structure SOAP message example
Reference: [SOAP]

Building Blocks: WSDL

Web Services Description Language (WSDL) introduction
type  WSDL document elements

service binding portType
 Type definitions and imports
n binding n identical name attributes n
 Interface description (Port
operation
port
port
operation
operation
identical name attributes
operation Type, Operations, Messages)
or element names
 Extensible binding section
1 1
1 n 1 n
 Implementation description
fault fault
input output fault input output fault
(Ports)
message
message
 WSDL SOAP binding
Containment
message
 Defines header and fault
Relationship types message
Linked-to support
Relationship n n
element /
type
 Extensibility element for
“type
“type part
definition”
definition”
part addressing
 HTTP binding also defined
Logical relationships between WSDL elements
Reference: [WSDL]

Building Blocks: UDDI

Universal Description, Discovery and Integration introduction
 Provides a Web services directory business
Web Service Provider Information
businessKey
platform Entity
 Businesses and organisations providing businessKey

n Web Service Information
Containment
Web services business
business
Relationship
Service serviceKey Linked-to
Service
 Descriptions of the services provided Relationship
serviceKey n Web Service Access Information

 Information about technical interfaces binding
tModelInstanceDetails*
binding tModel
 Sophisticated taxonomy bindingKey Template
Template n m
tModel tModelKey
 Supports business identification systems

Containment and reference relationship of data structures
(D-U-N-S, GLNs etc.)
 Also supports business and product
classification systems tModel
(UNSPSC, NAICS etc.)

1 0..1
 Contains references to WSDL interfaces n 0..1 0..1
 Programmatic interface name

description
description overviewDoc
identifier
Bag
category
Bag
 Posting and requesting service information 0..1 n
 Global operator cloud description

Mandatory
Optional
WSDL overviewURL description
 Test and Production registries Interface Exclusive
and Binding Containment
 Private internal registry implementations Document Relationship
URI Reference
more frequently used
Reference: [UDDI] The tModel structure

Building Blocks: Security

Securing Web services with HTTPS (HTTP over SSL or TLS)
HTTPS
 Most Web services providers and Service Requestor Service Provider

requestors are able to support SOAP
over the HTTPS protocol Server Certificate
 This provides message-level integrity
and confidentiality and also provides Client Server
Trust File Key File
an authorisation model
 SSL certificates can be requested from
Server-side authentication
a certificate authority or self-certified
 Key file and trust file used HTTPS
Service Requestor Service Provider

 Password-protected certificates
shared between parties
 Easy to implement, but has several Server Certificate
limitations Client Client Server

Server
 Message cannot be processed by Key File Trust File Key File Trust File
intermediaries
Client Certificate
References: [SSL, TLS] Client- and Server-side authentication

WS-Security specifications
WS-Federation Reference: [WSS]
WS-
WS-Secure WS-
Authori-
Conversation Privacy
zation
WS-Security
SOAP
Application Layer
Policy
WS-Trust
WS-Policy
Envelope Extensions XML Token Extensions

WS-Security
XrML SAML
XML
XML XML Signature XML Encryption
Key Mgmt.
http, MQ, ftp …

Transport
Layer
SSL
TCP/IP
Web Service Foundation Security Extensions
 WS-Security is a building block for security token propagation,

message integrity and message confidentiality which can be
combined with other Web services extensions
 Implementations available today, vendors and open source

Building Blocks: Interoperability and WS-I.org
WS-I Basic
Profile 1.1,
Attachments WS-I Basic
Profile 1.0 and Security Profile
Simple SOAP (currently draft)
Binding Profile 1.0 Kerberos, REL,
and SAML
Token Profiles
Reference: [WSI]
Building Blocks: Java and Web services

Java Web services architecture – logical and process view
Stub-based Service Requestor Service Registry

(also a provider)
Database Registry Code
Client Code (File, RDBMS) (UDDI, WSIL)
1: Find
JAX-RPC/WS SOAP Engine Servlet Engine SOAP Engine JAXR
JAX-RPC/WS
HTTP Client (Tomcat, other) (Axis, other) UDDI4J
Stub
Stub (Axis, other)
Transport Infrastructure
Web (HTTP) Network Operating

2a: Bind Server (TCP/IP) System
Stubless Service Requestor Service Provider
Database Server Code

JAXR
Client Code 2b: Invoke (File, RDBMS) (POJO, EJB)
UDDI4J
SOAP Engine
(Axis, other)
Servlet Engine SOAP Engine JAXR
JAX-RPC/WS
HTTP Client (Tomcat, other) (Axis, other) UDDI4J
Stub

JAX-RPC 1.1 API (Java 1.4 and earlier)
J2SE J2EE Container

Client Side Server Side
JAX-RPC Runtime JAX-RPC Runtime
Service Endpoint
Service Service
Service
Endpoint Endpoint
Interface
Interface Interface
Service
Service Endpoint
Service Client
Object Implemen-
Client Stub
(Factory) tation
Transport
 Java XML API for Remote Procedure Calls (JAX-RPC) uses design
patterns such as proxy and factory to provide consumer (client) and
provider (server) side access to SOAP messaging
 Defines WSDL and XML Schema to Java mapping
Reference: [JAXRPC]

JAX-RPC 1.1 and Enterprise Web Services 1.1 (Java 1.4)
J2EE Container J2EE Container
Client Side Server Side

JAX-RPC Runtime JAX-RPC Runtime
Service Endpoint
JNDI
Service Service
Service
Endpoint Endpoint
Interface
Interface Interface
Service
Service Endpoint
Service Client
Object Implemen -
Client Stub
(Factory) tation
Transport
Web Web
Services  J2EE Extension of JAX-RPC: Services
Client DD Server DD
 Deployment Descriptors (DDs)
 EJBs as service endpoints
Reference: [EWS]

Java XML API for Web Services (JAX-WS) 2.0 (Java 5)
 Follow-up to JAX-RPC 1.1:

 Support for latest SOAP, WSDL, and WS-I specifications
• SOAP 1.2, WSDL 2.0 (continued support for 1.1 versions)
• WS-I Basic Profile 1.1
 Data binding related tasks now delegated to JAXB 2.0
 Annotations and Web services metadata – JSR 175, JSR 181

 JAX-WS 2.0 defines the use of Java annotations (JSR 175) to simplify
the most common development scenarios for both clients and servers,
and aligns with and complements the annotations defined by JSR 181
 Class level: @WebService(), method level: @WebMethod()
 Extension for Implementing Enterprise Web Services (JSR 109)

 The jaxrpc-mapping-info deployment descriptor (JSR 109) provides
deployment time Java-to-WSDL mapping functionality. In conjunction
with JSR 181, JAX-WS 2.0 complements this mapping feature with
development time Java annotations controlling the mapping
Reference: [JAXWS]

ESB and Service Composition in Java
 Implementing the Enterprise Service Bus pattern is straightforward:

 Java standards for Web services support provide basic ESB support
(loose coupling, location transparency, message routing, etc.)
 Support for advanced ESB features such as mediation in numerous
commercial products and open source assets
 Several alternatives for service composition:

 Write your own composition code
• Using JAX-RPC or JAX-WS for service invocation
 Business Process Execution Language (BPEL) support in Java
application/integration servers, both open source and commercial
• Use BPEL for programming-in-the-large and Java for
programming in-the-small
 Use jOpera, a composition framework developed by ETH Zürich
(not based on BPEL, but defining its own composition language)
• http://www.jopera.org

Module 2: Summary
Web services reuse well-
established and proven
concepts.
I’ve already skimmed through
some WSDL, and I didn’t
understand a single line.
 Having a solid XML background is halfway towards understanding

Web services
 The base Web services stack is now solid and well established
 The WS-I profiles are an important milestone on the way towards

real interoperability between implementations
 Basic security has been robust for several years, but more
sophisticated security standards are still emerging

References
[XML] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000,
http://www.w3.org/TR/2004/REC-xml-20040204/
[XMLNS] Namespaces in XML, W3C, 14 January 1999, http://www.w3.org/TR/REC-xml-names/
[XMLSch] XML Schema W3C Recommendation Parts 0-2, 2 May 2001, http://www.w3.org/XML/Schema
[SOAP] SOAP Version 1.2 W3C Recommendation Parts 0-2, June 2003, http://www.w3.org/2000/xp/Group/
[WSDL] WSDL Version 1.1 W3C Note, March 2001 (2.0 is Candidate Rec.), http://www.w3.org/2002/ws/desc/
[UDDI] UDDI Version 3.0.2 OASIS Draft, October 2004, http://uddi.org/pubs/uddi_v3.htm
[SSL] SSL Protocol Version 3.0, Netscape Communications, 1996, http://wp.netscape.com/eng/ssl3/
[TLS] Transport Layer Security 1.0, Internet Engineering Task Force, January 1999,
http://www.ietf.org/html.charters/tls-charter.html
[WSS] Web Services Security: SOAP Message Security 1.0 Specification, OASIS, March 2004,
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[WSI] Web Services Interoperability Profiles, WS-I.org, 2004-2005, http://www.ws-i.org/deliverables/index.aspx
[JAXRPC] Java API for XML Remote Procedure Calls 1.1 Specification, Java Community Process, October
2003, http://www.jcp.org/en/jsr/detail?id=101
[EWS] Enterprise Web Services 1.1, Java Community Process, November 2003,
http://www.jcp.org/en/jsr/detail?id=921
[JAXWS] The Java API for XML Web Services, (JAX-WS) 2.0, Proposed Final Draft, October 7, 2005

with Web Services
Module 3: Web Services Construction
Web services programming isn’t

fundamentally different from what I’ve
been doing with J2EE and XML.
I bet I can get some of these new
wizards and tools to do most of the
hard work.

October 2003
63
Module 3: Agenda
 Technology implementations
 Web services tools
 J2EE Web services implementations
 Other programming languages – PHP, Ruby
 End-to-end example using open source technologies
 Introduction and getting started
 WSDL definition
 Service provider creation from WSDL
 Test service implementation
 Web service publishing and discovery
 Create a Web service client from WSDL
 Secure communication with SOAP/HTTPS
Tutorial handouts contain complete source code for the example

under “Additional Materials” section

Eclipse-based Web services tools
 Eclipse SDK 3.1 Web Tools Project (WTP)
 Open source downloads from eclipse.org
 Web services wizards, WSDL editor,
WS-I validator
 Focus for today
 IBM Rational Application Developer

(RAD) 6.0
 Based on Eclipse and WTP
 Plus many more Web services tools

J2EE Web services implementations
 Apache Tomcat + Axis
 Open source download
 J2EE 1.4 Compliant Web container
plus JAX-RPC Web services engine
 Basic administration tools
 Integration with Eclipse + WTP
 Focus for today
 IBM WebSphere Application Server 6.0

 J2EE 1.4 compliant
 First class administration and
clustering support
 Integration with RAD
 WS-Security, WS-AtomicTransaction,
Service Gateway, SDO support
+ others

Axis / Tomcat / J2SE compatibility matrix
Tomcat 5.0.28 5.5.12
J2SE 1.4.x 5.0 (1.5)
Axis 1.2 1.3
 Tomcat 5.5.x requires J2SE 5.0

 Eclipse WTP 1.0 supports Axis 1.2, WTP 1.5 Axis 1.3
 jOpera supports J2SE 1.4.x, but not J2SE 5.0
 The combination we use in this tutorial is Tomcat 5.0.28,

J2SE 1.4.1 and Axis 1.2.1

PHP introduction
 PHP: Hypertext Processor

 Portable scripting language especially suited to Web development
 Open source implementation
 Embedded inline with HTML, Syntax similar to C / Java / Perl
 For simplicity, we have used the XAMPP implementation from

apachefriends.org
 Single distribution containing Apache, MySQL, PHP and Perl
 http://www.apachefriends.org/en/xampp.html
 SOAP support now native in PHP 5

 “Experimental” in latest release of PHP
 Implementation in C provides good performance
 Also NuSOAP 0.7 from sourceforge.net for PHP4 clients

Ruby introduction
 Ruby is a rather new object-oriented scripting language:

 Pure OO language, everything is an object
 Best of Smalltalk and Java, plus ideas from scripting languages
 Typically interpreted
 Ruby on Rails is a Web application development and runtime

framework on top of Ruby
 Popular for development of database-centric Web applications
 Basic Web services support in Ruby on Rails via Action Web Service
(message formats: rpc-encoded SOAP and XML-RPC in version 1.1.2)
 Links:
 Ruby language: http://www.ruby-lang.org
 Ruby on Rails: http://www.rubyonrails.org/docs
 Install rails package: http://instantrails.rubyforge.org/wiki/wiki.pl

Example introduction
 Taken from Perspectives on Web Services Chapter 4.11
 “Creating a document/literal Service from WSDL”
 Insurance scenario with a fictitious Insurer called
PremierQuotes
 Example shows how PremierQuotes generates a report on
the total risk under management by the company for a
government agency
Archie Tekt  Broken down by year
 XML schemas are defined to represent documents received

and returned from the service (standards body)
 WSDL created which references the schemas
Zippy Coder
 Java service implementation created from WSDL (top-down)
by PremierQuotes
 Java service requestor created from WSDL by government
agency
Ed U. Cate
 PHP service requestor and Ruby service provider created to
show interoperability
Web services architecture for example
Government Service Requestor (Java, Stub-Based) Premier Quotes Mid Office

Service Provider (Java)
Test JSPs
Browser Client Code Servlet Engine
(Eclipse WTP) SOAP Engine
(Tomcat) (Axis)
JAX-RPC/WS SOAP Engine

Invoke
HTTP Client JAXR
JAX-RPC/WS
Stub (Axis, other)
UDDI4J
Stub
Service
Server Code
Description
Transport Infrastructure (POJO)
(WSDL)
Bind Web (HTTP)

Server
Network
(TCP/IP)
Operating
System
External Risk Assessment

Service Provider (Ruby)
Public Service Requestor (PHP, Stubless)

Rails Action
Web Service
JAXR
Client
UDDI4J
Frontend Page
Invoke
PHP 5 SOAP
Support Service Server Code
Description (Controller)
HTTP Client
(WSDL)

Green thread through the development steps
 Step 1: Create WSDL service definition

 From scratch (top-down) or from existing asset (bottom-up)
 Step 2: Generate server-side implementation stub from WSDL

 WSDL port type mapped to Java interface and classes
 WSDL operations mapped to Java methods
 XML Schema (XSD) types mapped to Java value objects
 Step 3: Complete server-side implementation and test
 Step 4 (optional): register service into UDDI or other registry (publish)
 Step 5: Generate client-side invocation proxy from WSDL, write client

 Same WSDL to Java mapping steps as on server side
 Step 6 (optional): secure service on network, transport, message layer

Getting started with Eclipse Web Tools and Tomcat
 Switch to J2EE Perspective

 Create new Dynamic Web
project targeting Tomcat 5.0 /
J2EE 1.4
 Create new Tomcat v5.0
Server during project creation
 Define path to Tomcat
installation directory
 Server can be started and
stopped from Servers view

Configuring the Eclipse Web services tools
 Selection of Web Services

Preferences available for
customisation
 Window -> Preferences
Menu
Find Web Services entry
 Default setting for the WS-I
compliance is “Suggest
Compliance”
WS-I Attachments Profile
(WS-I AP)
WS-I Simple SOAP
Binding Profile (WS-I SSBP)

Step 1: WSDL definition

Graphical WSDL Editor
 Create a new WSDL file RiskReport.wsdl using WSDL Editor

Alternatively, you can import an existing file

WSDL input and output message contents
 Request contains two integer values to create report
 Response contains an array of annual reports, indexed by year

Step 2: Service provider creation from WSDL

Creating a WS-I compliant service in Java from WSDL
 Select WSDL
 Select Web Services -> Generate Java
bean skeleton context menu
 Wizard based on Axis WSDL2Java
command
 Can also be done on command line
 Define custom mappings

Generated code
 JAX-RPC Service Endpoint Interface

 Service Implementation Skeleton
 Value objects for message
parameters
 Axis deploy.wsdd and
undeploy.wsdd deployment scripts
 Axis config Server-config.wsdd
 Updated web.xml
 Classpath updates
include Axis 1.2 libraries
 Project deployed to server
 Server started

Complete service implementation
/**
* RiskReportSOAPBindingImpl.java
*/
 To simplify this package com.premierquotes.risk;

import com.premierquotes.risk.xml.response.*;
example we have import java.util.*;
stubbed out the service public class RiskReportSOAPBindingImpl implements com.premierquotes.risk.RiskReportPortType{

public com.premierquotes.risk.xml.response.RiskReportResponse
getRiskReport(com.premierquotes.risk.xml.request.RiskReportRequest riskReportRequestPart)
implementation with a throws java.rmi.RemoteException {
System.out.println("## Started MidOffice riskReportRequest");
random number int noOfYears = riskReportRequestPart.getRiskReportRequestData().getNoOfYears();
int firstYear = riskReportRequestPart.getRiskReportRequestData().getFirstYear();
generator Vector resultVec = new Vector();
 Use generated types // loop for each year requested

for (int i=0;i < noOfYears; i++) {
RiskRecordType rec = new RiskRecordType();
from Axis WSDL2Java rec.setYear(firstYear+i);
 Book example based RiskAssessmentResultType report = new RiskAssessmentResultType();

report.setClaimCount((int)Math.round(Math.random()*100.0));
report.setPolicyCount((int)Math.round(Math.random()*10000.0));
on Cloudscape / Derby report.setTotalClaimValue(Math.rint((Math.random()*1000000.0)*
DB report.getClaimCount()) / 100.0);
report.setTotalInsuredValue(Math.rint((Math.random()*10000000.0)*
report.getPolicyCount()) / 100.0);
rec.setReport(report);
 Note: Axis emitter }

resultVec.add(rec);
RiskRecordType[] resultArray = new RiskRecordType[resultVec.size()];

interface different in resultVec.toArray(resultArray);
RiskReportResponse resp = new RiskReportResponse();
IBM WAS/RAD resp.setRiskReportResponseData(resultArray);
System.out.println("## Completed MidOffice riskReportRequest");
return resp;
}}

Step 3: Test service implementation
Test
Client

Web Services Explorer
 Test service implementation from WSDL definition – no coding
 View Form or Source of results

TCP/IP Monitor
 Creates a new TCP/IP port
which listens on requests and
responses and forwards to
another address
 Local or remote
 Integrated WS-I Compliance
checking for SOAP messages
 Enable through Window ->

Show View -> Other menu
 Under Debug category

Step 4: Web service publishing and discovery

Publishing with WS-Inspection
 Generate and update WS-
Inspection Language (WSIL)
documents
 Browse and import services

Publishing with UDDI
 UDDI Publish feature in Eclipse

Web Tools includes references
to “Unit Test” UDDI Registry
 Local J2EE UDDI
Implementation
 Not shipping with WTP 1.0,
but packaged with WAS/RAD

Step 5: Creating a Web service client from WSDL

Creating a Web service client in Java
 Create Java JAX-RPC client from

WSDL into a Web project
 WSDL namespace to Java

package mapping

Generated client-side artefacts
 JAX-RPC Service Endpoint

Interface
 Service Proxy
 Value objects for message
parameters
 Classpath updates include

Axis 1.2 libraries
 Project deployed to server
 Server started

Creating a client
package com.government.risk;
import com.government.risk.xml.request.*;
import com.government.risk.xml.response.*;
public class RiskReportClient {

public static void main(String[] args) {
if (args.length != 2) {
System.out.println(
 Create a new Java client with "Usage: RiskReportClient <first year> <no of years>");
return;
a main() method called }
try {
RiskReportClient RiskReportPortService service = new RiskReportPortServiceLocator();
 Implement using the RiskReportPortType sei = service.getRiskReportPortService(new URL(

"http://localhost:8080/PremierMidOfficeWeb/services/RiskReportPortService"));
generated Service Endpoint // populate request with passed values
Interface and Service Locator RiskReportRequestType data = new RiskReportRequestType();
data.setFirstYear(Integer.parseInt(args[0]));
 Once complete, use data.setNoOfYears(Integer.parseInt(args[1]));
RiskReportRequest req = new RiskReportRequest();
Run -> Run … menu req.setRiskReportRequestData(data);
 Add program arguments // invoke the service

RiskReportResponse resp = sei.getRiskReport(req);
<first year> <no years> RiskRecordType[] records = resp.getRiskReportResponseData();
 e.g. 1999 5 // loop through each record printing results to console

for (int i=0; i < records.length; i++) {
System.out.println("REPORT FOR " + records[i].getYear() + " :");
 Note: Axis emitter interface System.out.println("----------------------------------------");
RiskAssessmentResultType result = records[i].getReport();
different in IBM WAS/RAD System.out.println("Total # policies
System.out.println("Total # claims
=" + result.getPolicyCount());
=" + result.getClaimCount());
System.out.println("Total value of policies =" + result.getTotalInsuredValue());
System.out.println("Total value of claims =" + result.getTotalClaimValue());
System.out.println("----------------------------------------");
}
} catch (Exception e) {
e.printStackTrace();
} } }

Creating a Web service client in PHP 5
 PHP SOAP extension provides a simple to use class called SoapClient
 Create a new instance, passing WSDL URL as a parameter
 Call the WSDL operation directly, passing in an array of parameters
 Extract data from returned structure and populate table
 Copy PHP file into XAMPP /htdocs directory – invoke from browser
 Check file permissions
<?php
/* Display Risk Report */
function displayRiskReport ($firstYear, $years) {
try {
$soapClient = new SoapClient(
"http://localhost:8080/PremierMidOfficeWeb/wsdl/RiskReportPortService.wsdl");
/* Retrieve the report */

$rrPart->firstYear = $firstYear;
$rrPart->noOfYears = $years;
$rrResponse = $soapClient->getRiskReport(array ('riskReportRequestData' => $rrPart));
$rrReturn = $rrResponse->RiskReportResponseData;
} catch (SoapFault $soapFault) {
echo $soapFault, "<br/>";
} }
?>

Implementing a service provider in Ruby on Rails (RoR)
 Declarative support for Web services in Action Web Service class
 WSDL generated on the fly
 Only supporting rpc/encoded SOAP communication (not compliant with WS-I BP)
 Controller and API classes to be developed and added to directories on server
 Follow the RoR naming conventions
class PowsController < ApplicationController

web_service_api :pows_risk
wsdl_service_name 'PowsRiskAssessment'
def doExternalRiskAssessment
# implementation code goes here
end
class PowsRiskAPI < ActionWebService::API::Base

inflect_names false
api_method :doExternalRiskAssessment, :returns => [RiskRecordCollectionType], :expects => [

{:noOfYears=>:int},
{:firstYear=>:int}
]
end

Step 6: Secure communication with SOAP/HTTPS

Securing a Web services implementation on Tomcat with SSL
 Use the J2SE keytool command to create a certificate keystore with a
self-signed certificate using the RSA algorithm
 The keystore contains certificates used by the server
 The truststore contains certificates trusted by the server
 <JAVA_HOME>/bin/keytool -genkey -alias tomcat -keyalg RSA
-keystore <TOMCAT_HOME>/conf/.keystore
 Complete questions when prompted
 Edit Tomcat configuration file in local workspace (not Tomcat install dir)
 Java Perspective: Servers -> Tomcat @ localhost-config -> server.xml
 Remove comments and specify as follows
<-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->

<Connector className="org.apache.coyote.tomcat5.CoyoteConnector"
port="8443" minProcessors="5" maxProcessors="75"
enableLookups="true" disableUploadTimeout="true" acceptCount="100"
debug="0" scheme="https" secure="true"; clientAuth="false"
sslProtocol="TLS" keystoreFile="/opt/tomcat-5.0.28/conf/.keystore"
keystorePass="your_password"/>
 Restart and open the Tomcat home page using https://localhost:8443

 Using http instead of https will send a BIN file to your browser

Updating the client for SSL communications
 Export generated server certificate from keystore

 keytool -export -alias tomcat -file tomcat-localhost.csr -keystore
/opt/tomcat-5.0.28/conf/.keystore -storepass <your_password>
 Import generated server certificate into truststore
 keytool -import -alias tomcat -file tomcat-local.csr -keystore
/opt/tomcat-5.0.28/conf/.truststore -storepass <your_password>
 Update RiskReportClient.java with the following:
RiskReport_SEIService service = new RiskReport_SEIServiceLocator();

String trustStorePath = "/opt/tomcat-5.0.28/conf/.truststore";
String trustStorePassword = "password";
System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
System.setProperty("javax.net.ssl.trustStore", trustStorePath);
System.setProperty("javax.net.ssl.trustStorePassword", trustStorePassword);
RiskReport_SEI sei = service.getRiskReportPort(new URL(

"https://localhost:8443/PremierMidOfficeWeb/services/RiskReportPort"));
 TCP/IP Monitor can be used to show encrypted request and response

 PHP Client can also be used if the published WSDL endpoint is updated

Module 3: Summary
Web services programming isn’t
fundamentally different from what I’ve
been doing with J2EE and XML.
I bet I can get some of these new
wizards and tools to do most of the
hard work.
 For both simple and sophisticated Web service development, you

now should now be able to rely on tools support plus some basic
Java programming skills
 The Eclipse Web Tools project provides all of the features you need
when using the basic Web services building blocks (SOAP, WSDL,
and UDDI)
 However, expect to have to pay for tools and runtimes if you want to
work with specifications like WS-Security or WS-BPEL

Building Service-Oriented Architectures with
Web Services
Module 4: SOA and Web Services Best Practices
We have to manage expectations so

that we can be sure to deliver in time
and on budget.
We don’t want to repeat all the
mistakes made by the very early
This module is excerpted from the book “Perspectives on Web adopters of this technology.
services” by Olaf Zimmermann, Mark Tomlinson, and Stefan Peuser,
Springer-Verlag Berlin Heidelberg New York 2003, ISBN 3-540-
00914-0. This work is subject to copyright. © Springer Verlag 2003.
All rights reserved.

October 2003
98
Module 4: Agenda
 Usage scenarios for Web services

 Business litmus test
 Technical litmus test
 Architectural decisions
 Addressing non-functional requirements
 Gaps and countermeasures
 Best practices
 SOAP, WSDL, UDDI
 SOA in general
 Questions and answers session

Usage scenarios
Service
Integration Complex
Level
Business
Processes
EAI B2B
Business
Functions
(Use Cases)
Technical
Functions
& Common Services (CS)
Information
Services
Simple
Intranet Extranet Internet
Service
Reach
 Plus: EDI replacement, portal adaptors, competency-focussed organisations,

mobile device communication, RMI/IIOP substitute, file transfer, grid computing …

Take the business litmus test – are Web services for you?
 If you answer “Yes” to any of the following business questions,

consider using Web services:
 Do you want to interact more tightly with your business partners?
 Is there a requirement to link internal stovepipe applications/packages?
 Do you want to make legacy assets available for reuse?
 Looking for a more flexible IT architecture that can easily adapt to
change? (agility / competitiveness / responsiveness)
 Is your system environment heterogeneous?
 Note that there is a place for both Web services and more
“traditional” EAI approaches. They also complement J2EE.

The technical litmus test
 If you answer “Yes” to any of the following technical questions,

consider using Web services:
 In your use case model, are other systems the primary actors in your
system?
 Do you have to support a heterogeneous or unknown client
environment?
 Do you plan to extend the reach of J2EE applications to application
clients?
 Do you already transfer XML documents via HTTP-GET or -POST?
 Do your rich application clients use proprietary communication
channels and are your firewall administrators unhappy about this?
 Does the number of service providers in your environment vary?
 Is your existing infrastructure capable of handling a rather verbose text-

based, self-describing message exchange format?

Key architectural decisions which must be made
Architectural Decisions
Service Service Service SOA

other
Modeling Messaging Matchmaking in general
XML
Parser
WSDL SOAP Agency Gateway,

Creation Runtime Type Provider other
Type
Transport Implemen- Security

Granularity Requestor
Protocol tation Architecture
Type
Comm. Management
Naming Modelling
Style Validation Operations
Accounting
Encoding Population Character Billing
Encoding
Session
Compression Access
Deployment Management
Client API System

Architecture

Handling non-functional requirements (NFRs)
 Performance
 Ensure that requirements are realistic
 Build a small prototype at start of project to check if criteria can be met
 Scalability
 Design your services to be as stateless as possible
 Normal J2EE scaling strategies can be applied
 Availability
 Normal J2EE availability strategies can be applied
 Robustness
 Create an effective error handling mechanism with SOAP fault handling
 The product building-blocks are now mature enough for prime-time
 Portability
 Stick to agreed industry standards/specifications such as JAX-RPC,
where they exist, and be prepared for changes (JAX-WS)

Gaps and countermeasures
 The XML language binding and encoding maze

 WSDL and SOAP do not define any language bindings
 Adhere to the WS-I Basic Profile 1.0, use (wrapped) document/literal
 Security solutions
 Network Layer security (IPSec, VPNs)
 Transport Layer and Application Server security (Basic vs. Keys)
 XML-based security (XML-Signature, XML-Encryption, SAML)
 WS-Security and it’s additional specifications (WS-Policy, WS-Trust etc.)
 Or Application Layer security if all else fails
 Web service management approaches
 Look for SOAP runtimes which have JMX instrumentation
 OASIS Web Services Distributed Management (WSDM)
 Transactional and context semantics plus orchestration
 Still emerging: WS-Coordination, transaction support, WS-BPEL

Best practice highlights I: WSDL and modelling
Follow a meet-in-the-middle WSDL
 Follow the design-by-contract principle
design approach
 Separate concerns and isolate interface from implementation
 Provide interoperable versions ofGenerating
your WSDLWSDL specifications
from server side Java
 Follow the bottom-up design approach
can beby a default
good idea, if you make sure no
 Expose coarse-grained interfacesprogramming language specifics make it
 Avoid complex operation signatures,
into stick
your with request-response
interface. This provides a
 Stick to standard XML schema data types for beginners.
jump-start
 Keep
Follow the service, method, parameter and type names small and simple
design-by-contract
 Apply general XML and XML schema best practices
principle
Always describe your services using

WSDL and XML schema. Add comments
for human consumption, and put the
documents on a Web server. Consider
developing your own WSDL generator if
many similar processes need to be
supported.

Best practice highlights II: SOAP and messaging
Carefully
 Use HTTP as the default transport, observe
but consider the messaging
alternative bindings
 Carefully observe the messagingoverhead
overhead
 By aware of the trade-off between security and performance
 Design your Web services to be Also known as
as stateless asSOAP verbosity. The
possible
overhead can
 Avoid custom mappings, write server-side be three
facades to 20 times,
instead
depending
 Include, but do not rely on the HTTP SOAP on the naming
action header conventions
 Be careful with message handlers and theother
and nesting levels of the document.
intermediaries
 Try to leverage existing transportUse TCP
layer monitors
or XML and try different
compression features
Include,but
Bedo not of
aware rely
theon, runtime
the HTTPbetween
differences parsers/engines.
JAX-RPC and Apache SOAP
SOAP action header
This should not be used for routing

purposes – this should be based on the
namespace attribute of the body element.
The feature is now deprecated, but
certain SOAP engines might still expect it
to be present.

Best practice highlights III: UDDI and matchmaking
 Carefully evaluation which type of UDDI registry (private vs. public)

is suited for your scenario
 Consider lightweight alternatives
Carefully evaluate which type of UDDI
to UDDI
 Obey the best practices already
registry is suitedbyfor
established your scenario
UDDI.org
Using UDDI on the Web is problematic not

for technical, but organisational reasons. For
these reasons, UDDI is most useful in
intranet and extranet scenarios where the
user groups are well known. Defining specific
tModels and UUIDs may relieve some of the
data consistency and trust issues.

Best practice highlights IV: SOA and project approach in general
 Clearly identify business need andApply standards

project scope pragmatically:
follow the
 Decide carefully whether Web services are 80-20 rule
the right technology for
your problem at hand
Do notthe
 Apply standards pragmatically: follow always
80-20useruleall of the features in
 Use stateless session EJBs are each andtype
provider every specification.
if EJBs Upgrade
exist in your
architecture to high specification levels only if there
is a concreteand
 Do not over-architect, do not under-architect need, not for its own sake
develop
Resist theincrementally
temptation to be over- (e.g. SOAP 1.1 vs. 1.2). The 80-20 or
“keep it simple” rule helps with
creative Resist the temptation to be over-creative
 Design for performance interoperability.
 Apply performance
Do not implement your own SOAP layer;
measurement best practices
 Test early(RYO)
any Roll-Your-Own approach
and often
 Leverage
compromises the Web services
already value
gained experience
proposition. Let the vendor labs and open
source community worry about the
runtime, otherwise RYO is likely to
become rewrite your own (every time).

Any questions?

October 2003
113
If you don‘t have questions for us... we have some for you
 Which business challenges does the demonstrated sample SOA/Web

services solution address?
 Which core Web services specifications were involved? And where?
 Where in the practical demonstration was the ESB?
 Same for service composition?
 Could you identify any familiar design patterns in the generated JAX-RPC
artefacts?
 Apart from function and parameter names, what does the interface contract
agreed between GovernmentOffice and PremierQuotes have to define?
 What information is required to get the Web services enablement project

started?

Optional Exercise: Customer Information (CI) Service
 Install Eclipse Web Tools Project
 Start from a Java class providing a customer information method:

 In parameter: name
 Out parameters: email address, areas of interest
 Apply Java-to-WSDL wizards to create Web service provider
 Apply WSDL-to-Java wizard to create invocation stub for test client
 Test the CI Web service with Web Services Explorer
 Compose risk report and customer information service into one

service
 Custom code or jOpera

Check out our Web site – www.perspectivesonwebservices.de

Additional Materials for Handouts

October 2003
117
Handout Material
Tomcat & Axis install
 Tomcat 5.0
 Extract Tomcat
 Add admin/manager user to XML configuration
 Tomcat homepage is http://localhost:8080
 Java Activation Framework (JAF) 1.0.2 and Java mail library
 Download JAF from Sun site might be required (Axis prerequisite)
 Copy mail.jar and activation.jar to tomcat/common/lib directory, and
add these libraries to client project build path
 Axis 1.2
 Ships with Eclipse WTP 1.0, so no need for additional installation steps
 Optional: run Axis validation to check if any dependencies are missing

Handout Material
Eclipse Web Tools install
 Install the J2SE SDK 1.4.1 or 1.4.2 (from Sun or IBM)

 Install Eclipse 3.1
 Launch ./eclipse
 Install Web Tools Project (WTP) Feature 1.0.1 via Eclipse update
manager:
 Select Help, then Software Updates, then Find And Install…
 Click on Search for new features to install, click on Next
 Create a New Remote Site… for WTP, pointing to
http://download.eclipse.org/webtools/updates
 Select WTP 1.0 and all required prerequisites
 Perform the installation
 Create workspace
 Create Tomcat 5.0 server configuration
 Start and stop server to check configuration

Handout Material
RiskReport.wsdl – WSDL used in example (1/4)

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="RiskReport"
xmlns:impl="http://premierquotes.com/ns/reports/risk"
xmlns:req="http://premierquotes.com/ns/reports/risk/req"
xmlns:resp="http://premierquotes.com/ns/reports/risk/resp"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://premierquotes.com/ns/reports/risk">
<wsdl:types>

<schema xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
targetNamespace="http://premierquotes.com/ns/reports/risk/req"
xmlns:req="http://premierquotes.com/ns/reports/risk/req"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<complexType name="RiskReportRequestType">
<sequence>
<element name="firstYear" type="xsd:int"/>
<element name="noOfYears" type="xsd:int"/>
</sequence>
</complexType>
<element name="RiskReportRequest">
<complexType>
<sequence>
<element name="riskReportRequestData" nillable="true" type="req:RiskReportRequestType"/>
</sequence>
</complexType>
</element>
</schema>

Handout Material


<schema xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
targetNamespace="http://premierquotes.com/ns/reports/risk/resp"
xmlns:resp="http://premierquotes.com/ns/reports/risk/resp"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<complexType name="RiskAssessmentResultType">
<sequence>
<element name="policyCount" type="xsd:int"/>
<element name="totalClaimValue" type="xsd:double"/>
<element name="claimCount" type="xsd:int"/>
<element name="totalInsuredValue" type="xsd:double"/>
</sequence>
</complexType>
<complexType name="RiskRecordType">
<sequence>
<element name="year" type="xsd:int"/>
<element name="report" nillable="true" type="resp:RiskAssessmentResultType"/>
</sequence>
</complexType>
<complexType name="RiskRecordCollectionType">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="RiskRecordTypeData" nillable="true"
type="resp:RiskRecordType"/>
</sequence>
</complexType>

Handout Material

<element name="RiskReportResponse">
<complexType>
<sequence>
<element name="RiskReportResponseData" nillable="true"
type="resp:RiskRecordCollectionType"/>
</sequence>
</complexType>
</element>
</schema>
</wsdl:types>


<wsdl:message name="riskReportRequestMsg">
<wsdl:part element="req:RiskReportRequest" name="riskReportRequestPart"/>
</wsdl:message>
<wsdl:message name="riskReportResponseMsg">
<wsdl:part element="resp:RiskReportResponse" name="riskReportResponsePart"/>
</wsdl:message>

<wsdl:portType name="RiskReportPortType">
<wsdl:operation name="getRiskReport">
<wsdl:documentation>Returns a collection of risk reports for the period specified
</wsdl:documentation>
<wsdl:input message="impl:riskReportRequestMsg" name="riskReportRequestMsg"/>
<wsdl:output message="impl:riskReportResponseMsg" name="riskReportResponseMsg"/>
</wsdl:operation>
</wsdl:portType>

Handout Material


<wsdl:binding name="RiskReportSOAPBinding" type="impl:RiskReportPortType">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getRiskReport">
<wsdlsoap:operation
soapAction="http://premierquotes.com/ns/reports/risk/getRiskReport"/>
<wsdl:input name="riskReportRequestMsg">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="riskReportResponseMsg">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>


<wsdl:service name="RiskReportPortService">
<wsdl:documentation>Example Risk Reporting Service from Perspectives on Web Services
</wsdl:documentation>
<wsdl:port binding="impl:RiskReportSOAPBinding" name="RiskReportPortService">
<wsdlsoap:address
location="http://localhost:8080/PremierMidOfficeWeb/services/RiskReportPortService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Handout Material
RiskReportPortType.java – JAX-RPC Service Endpoint Interface

/**
* RiskReportPortType.java
*
* This file was auto-generated from WSDL
* by the Apache Axis WSDL2Java emitter.
*/
package com.premierquotes.risk;
public interface RiskReportPortType extends java.rmi.Remote {

throws java.rmi.RemoteException;
}

Handout Material
RiskReportPortService.java – JAX-RPC Service Interface

/**
* RiskReportPortService.java
*
*/
public interface RiskReportPortService extends javax.xml.rpc.Service {

public java.lang.String getRiskReportPortServiceAddress();
public com.premierquotes.risk.RiskReportPortType getRiskReportPortService()

throws javax.xml.rpc.ServiceException;
public com.premierquotes.risk.RiskReportPortType
getRiskReportPortService(java.net.URL portAddress) throws javax.xml.rpc.ServiceException;
}

Handout Material
RiskReportSOAPBindingImpl.java – Service Skeleton

/**
*
*/
import java.util.*;
public class RiskReportSOAPBindingImpl implements com.premierquotes.risk.RiskReportPortType{

throws java.rmi.RemoteException {
return null;
}

Handout Material
deploy.wsdd – Axis configuration (1/3)








<deployment
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

<service name="RiskReportPortService" provider="java:RPC" style="document" use="literal">

<parameter name="wsdlTargetNamespace" value="http://premierquotes.com/ns/reports/risk"/>
<parameter name="wsdlServiceElement" value="RiskReportPortService"/>
<parameter name="schemaQualified" value="http://premierquotes.com/ns/reports/risk/req,
http://premierquotes.com/ns/reports/risk/resp"/>
<parameter name="wsdlServicePort" value="RiskReportPortService"/>
<parameter name="className" value="com.premierquotes.risk.RiskReportSOAPBindingSkeleton"/>
<parameter name="wsdlPortType" value="RiskReportPortType"/>
<parameter name="typeMappingVersion" value="1.2"/>
<parameter name="allowedMethods" value="*"/>

Handout Material

<typeMapping
xmlns:ns="http://premierquotes.com/ns/reports/risk/req"
qname="ns:>RiskReportRequest"
type="java:com.premierquotes.risk.xml.request.RiskReportRequest"
serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
encodingStyle=""
/>
<arrayMapping
xmlns:ns="http://premierquotes.com/ns/reports/risk/resp"
qname="ns:RiskRecordCollectionType"
type="java:com.premierquotes.risk.xml.response.RiskRecordType[]"
innerType="cmp-ns:RiskRecordType" xmlns:cmp-
ns="http://premierquotes.com/ns/reports/risk/resp"
encodingStyle=""
/>
<typeMapping
qname="ns:RiskRecordType"
type="java:com.premierquotes.risk.xml.response.RiskRecordType"
encodingStyle=""
/>

Handout Material

<typeMapping
qname="ns:>RiskReportResponse"
type="java:com.premierquotes.risk.xml.response.RiskReportResponse"
encodingStyle=""
/>
<typeMapping
xmlns:ns="http://premierquotes.com/ns/reports/risk/req"
qname="ns:RiskReportRequestType"
type="java:com.premierquotes.risk.xml.request.RiskReportRequestType"
encodingStyle=""
/>
<typeMapping
qname="ns:RiskAssessmentResultType"
type="java:com.premierquotes.risk.xml.response.RiskAssessmentResultType"
encodingStyle=""
/>
</service>
</deployment>

Handout Material
RiskReportPortSoapBindingImpl.java – implementation (1/2)

/**
*
*/
import java.util.*;
public class RiskReportSOAPBindingImpl implements com.premierquotes.risk.RiskReportPortType{

throws java.rmi.RemoteException {
System.out.println("## Started MidOffice riskReportRequest");
int noOfYears = riskReportRequestPart.getRiskReportRequestData().getNoOfYears();
int firstYear = riskReportRequestPart.getRiskReportRequestData().getFirstYear();
Vector resultVec = new Vector();
// loop for each year requested

for (int i=0;i < noOfYears; i++) {
RiskRecordType rec = new RiskRecordType();
rec.setYear(firstYear+i);
RiskAssessmentResultType report = new RiskAssessmentResultType();

Handout Material
RiskReportPortSoapBindingImpl.java – implementation (2/2)

report.setClaimCount((int)Math.round(Math.random()*100.0));
report.setPolicyCount((int)Math.round(Math.random()*10000.0));
report.setTotalClaimValue(Math.rint((Math.random()*1000000.0)*
report.getClaimCount()) / 100.0);
report.setTotalInsuredValue(Math.rint((Math.random()*10000000.0)*
report.getPolicyCount()) / 100.0);
rec.setReport(report);
resultVec.add(rec);
}
RiskRecordType[] resultArray =
new RiskRecordType[resultVec.size()];
resultVec.toArray(resultArray);
RiskReportResponse resp = new RiskReportResponse();
resp.setRiskReportResponseData(resultArray);
System.out.println("## Completed MidOffice riskReportRequest");
return resp;
} }

Handout Material
RiskReportClient.java – Java service client with SSL (1/2)

package com.government.risk;
import java.net.URL;
import java.security.Security;
import com.government.risk.xml.request.*;
import com.government.risk.xml.response.*;
public class RiskReportClient {

public static void main(String[] args) {
if (args.length != 2) {
System.out.println(
"Usage: RiskReportClient <first year> <no of years>");
return;
}
try {
RiskReportPortService service = new RiskReportPortServiceLocator();
String trustStorePath = "/opt/tomcat-5.0.28/conf/.truststore";
String trustStorePassword = "password";
System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
System.setProperty("javax.net.ssl.trustStore", trustStorePath);
System.setProperty("javax.net.ssl.trustStorePassword", trustStorePassword);
RiskReportPortType sei = service.getRiskReportPortService(new URL(

"https://localhost:8443/PremierMidOfficeWeb/services/RiskReportPortService"));

Handout Material
RiskReportClient.java – Java service client with SSL (2/2)

// populate request with passed values
RiskReportRequestType data = new RiskReportRequestType();
data.setFirstYear(Integer.parseInt(args[0]));
data.setNoOfYears(Integer.parseInt(args[1]));
RiskReportRequest req = new RiskReportRequest();
req.setRiskReportRequestData(data);
// invoke the service

RiskReportResponse resp = sei.getRiskReport(req);
RiskRecordType[] records = resp.getRiskReportResponseData().getRiskRecordTypeData();
// loop through each record printing results to console

for (int i=0; i < records.length; i++) {
System.out.println("REPORT FOR " + records[i].getYear() + " :");
RiskAssessmentResultType result = records[i].getReport();
System.out.println("Total # policies =" + result.getPolicyCount());
System.out.println("Total # claims =" + result.getClaimCount());
System.out.println("Total value of policies =" + result.getTotalInsuredValue());
System.out.println("Total value of claims =" + result.getTotalClaimValue());
}
} catch (Exception e) {
e.printStackTrace();
} } }

Handout Material
RiskReportClient.php – PHP service client (1/3)

<head><title>Government Risk Report Client</title></head>
<body>
<?php
/* Display Risk Report */
function displayRiskReport ($firstYear, $years) {
try {
$soapClient = new SoapClient(
"http://localhost:8080/PremierMidOfficeWeb/wsdl/RiskReportPortService.wsdl");
/* Debug use only - list functions and types

echo print_r($soapClient->__getFunctions(), true) . "<br/><br/>";
echo print_r($soapClient->__getTypes(), true) . "<br/><br/>";
*/
/* Retrieve the report */

$rrPart->firstYear = $firstYear;
$rrPart->noOfYears = $years;
$rrResponse = $soapClient->getRiskReport(array ('riskReportRequestData' => $rrPart));
$rrReturn = $rrResponse->RiskReportResponseData;
/* Display the results in a table */
echo "<table border=1 cellpadding=5>";
echo "<tr><th>Year</th><th>PolicyCount</th><th>TotalClaimValue</th>
<th>ClaimCount</th><th>TotalInsuredValue</th></tr>";
$rrArray = $rrReturn->RiskRecordTypeData;

Handout Material

foreach ($rrArray as $report) {
$reportElem = $report->report;
$policyCount = $reportElem->policyCount;
$totalClaimValue = $reportElem->totalClaimValue;
$claimCount = $reportElem->claimCount;
$totalInsuredValue = $reportElem->totalInsuredValue;
echo "<tr>" .
"<td>$report->year</td>" .
"<td>$policyCount</td>" .
"<td>$totalClaimValue</td>" .
"<td>$reportElem->claimCount</td>" .
"<td>$reportElem->totalInsuredValue</td>" .
"</tr>";
}
echo "</table>";
} catch (SoapFault $soapFault) {

echo $soapFault, "<br/>";
}
}
/* Has form data been entered? */

if (isset($_POST['submit'])) {
if (!is_numeric($firstYear = $_POST['firstYear']))
$firstYear = 2000;
if (!is_numeric($years = $_POST['noOfYears']))
$years = 3;

Handout Material

echo "<h1>Risk Report Results</h1>";
displayRiskReport ($firstYear, $years);
} else {
/* Display the form */
?>
<h1>Risk Report</h1>
<form method='post'>
<p>First Year<br/><input name='firstYear'/></ p>
<p>Number of Years<br/><input name='noOfYears'/></p>
<p><input type='submit' name='submit' value='Enter'></p>
</form>
<?php
/* What am I running on? */
echo "<br/>",$_SERVER['SERVER_SIGNATURE'];
}
?>
</body>

Handout Material
pows_controller.rb – Ruby on Rails Service Provider (1/2)

class PowsController < ApplicationController
web_service_api :pows_risk
wsdl_service_name 'PowsRiskAssessment'
def doExternalRiskAssessment
re1 = RiskRecordType.new
re1.year = 2006
rat = RiskAssessmentResultType.new
rat.policyCount = 2
rat.totalClaimValue = 42.12
rat.claimCount = 511
rat.totalInsuredValue = 99.99
re1.report = rat
result = RiskRecordCollectionType.new
result.shouldGetCredit = true
result.resultElements = [re1]
result
end
end

Handout Material
pows_risk_api.rb – Ruby on Rails Service Provider (2/2)

class RiskAssessmentResultType < ActionWebService::Struct
member :policyCount, :int
member :totalClaimValue, :float
member :claimCount, :int
member :totalInsuredValue, :float
end
class RiskRecordType < ActionWebService::Struct

member :year, :int
member :report, RiskAssessmentResultType
end
class RiskRecordCollectionType < ActionWebService::Struct

member :shouldGetCredit, :bool
member :resultElements, [RiskRecordType]
end
class PowsRiskAPI < ActionWebService::API::Base

inflect_names false
api_method :doExternalRiskAssessment, :returns => [RiskRecordCollectionType], :expects => [

{:noOfYears=>:int},
{:firstYear=>:int}
]
end

Handout Material
RiskReportPortService.wsil – WS-Inspection file

<?xml version="1.0" encoding="UTF-8"?>
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
xmlns:wsilwsdl="http://schemas.xmlsoap.org/ws/2001/10/inspection/wsdl/"
xmlns:wsiluddi="http://schemas.xmlsoap.org/ws/2001/10/inspection/uddi/"
xmlns:uddi="urn:uddi-org:api">
<service>
<abstract xml:lang="en-US">
</abstract>
<description referencedNamespace="http://schemas.xmlsoap.org/wsdl/"
location="RiskReportPortService.wsdl">
<wsilwsdl:reference endpointPresent="true">
<wsilwsdl:referencedService xmlns:impl="http://premierquotes.com/ns/reports/risk">
impl:RiskReportPortService
</wsilwsdl:referencedService>
</wsilwsdl:reference>
</description>
</service>
</inspection>

Trademarks
AmberPoint is a trademark of AmberPoint, Inc. OASIS is a registered trademark of OASIS Open
Amazon is a registered trademark of Amazon.com, Inc. and its OMG is a registered trademark of the Object Management Group, Inc.
affiliates
Apache Tomcat, Axis and Xerces are trademarks of The Apache Perl is a registered trademark of the Perl Foundation
Software Foundation PHP is a registered trademark of the PHP Group
BEA is a registered trademark of BEA Systems, Inc. Red Hat® is a registered trademark of Red Hat, Inc.
CBDI is a trademark of CBDI Forum Limited SAP and R/3 are trademarks or registered trademarks of SAP
CORBA is a registered trademark of the Object Management Group,
Inc. Aktiengesellschaft.
DCE is a trademark of The Open Group SourceForge is a trademark of the Open Source Technology Group
D-U-N-S® is a registered trademark of Dun & Bradstreet Sun, Sun Open Net Environment, Sun ONE, Solaris, Java and all Java-based
Corporation. trademarks (e.g. EJB, J2EE, J2SE, JavaBeans, Java Connector, JCA,
eBay is a registered trademark of eBay Inc.
Eclipse is a registered trademark of the Eclipse Foundation JDK, JVM) are trademarks or registered trademarks of Sun Microsystems,
GLN is a trademark of the Uniform Code Council Inc. Inc. in the United States, other countries, or both.
Google™ is a trademark of Google Technology Inc. Thoughtworks is a registered trademark of ThoughtWorks, Inc.
HP is a registered trademark of Hewlett-Packard Development UDDI is a trademark of OASIS Open
Company, L.P.
IBM, AIX, alphaWorks, CICS®, Cloudscape, Crossworlds®, DB2®, UNSPSC is a trademark of United Nations Development Programme (UNDP)
developerWorks, Domino, e-business on demand, eServer, and Dun & Bradstreet Corporation (D & B)
HACMP/6000, IMS, MQSeries®, Tivoli®, pSeries, Rational®, UML is a registered trademark of the Object Management Group, Inc
Rational Unified Process®, RUP®, Rational ClearCase®, UNIX® is a registered trademark of The Open Group in the United States and
Rational XDE, Redbooks, SOMA, VisualAge, WebSphere®, all
WebSphere based trademarks, zSeries and z/OS are other countries.
trademarks of International Business Machines Corporation in W3C® is a registered trademark of the Massachusetts Institute of
the United States, other countries, or both. Technology, European Research Consortium for Informatics and
IETF is a trademark of The Internet Society Mathematics, or Keio University on behalf of the World Wide Web
Iona is a registered trademark of IONA Technologies
Linux is a registered trademark of Linus Torvalds. Consortium.
Microsoft, .NET, Microsoft Office, Visual Basic, Win32, Windows®, WS-I is a trademark of The Web Services-Interoperability Organization
Windows® NT, and Windows® 2000 are either registered XAMPP is a registered trademark of Apache Friends
trademarks or trademarks of Microsoft Corporation in the United Yahoo! is a registered trademark of Yahoo! Inc.
States, other countries, or both.
NAICS was developed in cooperation with the US Economic
Classification Policy Committee, Statistics Canada, and Other company, product or service names may be trademarks or
Mexico's Instituto Nacional de Estadistica, Geografica e service marks of others
Informatica

Building Service-Oriented Architectures (Soas) With Web Services

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Building Service-Oriented Architectures (Soas) With Web Services

Hochgeladen von

Copyright:

Verfügbare Formate

Building Service-Oriented Architectures (SOAs)

with Web Services

Updates available from: http://www.perspectivesonwebservices.de

Building SOAs with Web Services

 Module 1: Introduction to SOA

 Module 2: Introduction to Web Services

 Module 3: Developing Web Service Provider and Requestor Applications

 Module 4: SOA/Web Services Best Practices

Building SOAs with Web Services

There have been other

Building SOAs with Web Services

 Motivation for service-oriented computing

 Key SOA patterns and project examples

 SOA and Web services implementation options

Building SOAs with Web Services

 Many users and backend systems interact with the system

 Sophisticated Quality of Service (QoS) requirements and other

 Hardly any green field

 The only constant is change

Building SOAs with Web Services

 Functional and technical application monoliths ubiquitous

 Development and integration projects costly and long running

 As a result, horizontal initiatives are much harder to implement

Building SOAs with Web Services

 Integration and choreography of

Source: [IBM SOA]

QoS, Security, Management & Monitoring

Discrete Applications Basket of Services

Building SOAs with Web Services

 Motivation for service-oriented computing

 Key SOA patterns and project examples for them

 SOA and Web services implementation options

Building SOAs with Web Services

“SOA is different things to different people” Business

 a programming model complete with standards, tools and

Source: [IBM SOA]

Building SOAs with Web Services

Service Repository/ Enterprise Service Bus

Development Execution Runtimes XML & Web Services Internet

Building SOAs with Web Services

Source: [IBM ITSO] WSDL description

Building SOAs with Web Services

Building SOAs with Web Services

 Separation of concerns and modularization:

Building SOAs with Web Services

 OO and SO share many characteristics, but differences exist as well

 Rule of thumb: develop object-oriented and integrate service-oriented

 Service autonomy should be strived for, see [Ferguson]

Building SOAs with Web Services

 Motivation for service-oriented computing

 Key SOA patterns and project examples for them

 SOA and Web services implementation options

Building SOAs with Web Services

Monitoring (Infrastructure Service)

QoS, Security, Management &

(Enterprise Service Bus)

Simple Source: [IBM SOA]

Building SOAs with Web Services

 Refinement of well-established broker pattern described in [POSA]

 Key capabilities (refer to [Keen] for details):

Building SOAs with Web Services

 Following well-established principles such as logical layering and

 One implementation option for the process layer is the Web