Transcript Web Services Surviving the Midlife Crisis

®
IBM Software Group | Cross-brand Web Services Team
Building service-oriented architectures with Web services
Extracts from “Perspectives on Web Services –
Applying SOAP, UDDI and WSDL to Real-World Projects”
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
readme.txt
Terms and Conditions of Reuse
 Feel free to use these charts with your customers
 However, please note that this material is still intellectual property
belonging to Springer Verlag and we would appreciate it if you left
the relevant copyright statements in place
Request for Feedback and Volunteers
 We welcome feedback – good or bad - on the contents of the
presentation. Drop us a note at [email protected]
Thanks! Olaf, Mark and Stefan
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Agenda
 Background to the book
 Chapter-by-chapter overview
 The Business Perspective
 The Training Perspective
 The Architecture Perspective
 The Development Perspective
 The Operational Perspective
 The Engagement Perspective
 The Futures Perspective
 Q&A and Summary
Note: I assume that you already have a basic knowledge of Web services
This presentation contains excerpts from the book “Perspectives on Web 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 Berlin Heidelberg 2003. All rights reserved. This material must not be published as a whole
or in part without permission.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
Background to the book
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
The authors
 Olaf Zimmermann is an IBM IGS Consulting IT Architect,
who is now part of the World-wide Applied Web Services
team in the Software Group.
 Mark Tomlinson is an IBM Consulting IT Specialist for the
WebSphere team in the Software Group. He now chairs the
region’s Cross-brand Web Services team.
 Stefan Peuser is an IBM Consulting IT Architect, working
for IGS e-business Innovation and Integration services.
… plus help from Frank Müller, Sven Milinski, Michael Pühlhöfer,
Marc Pestel, Christoph Pürckhauer and many, many others
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
From Redbook to “Real Book”
 September 2001:
Completed first IBM
Redbook on Web
services
 March 2002: Research
paper on using Web
services to support
incremental file upload
 July 2003: Perspectives
on Web Services
published by Springer
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Our objectives for the book
 Focus on “Real world projects”
 Many IBM Global Services and jStart customer engagements
 Try to document and answer all the hard questions we get asked in the
field by you!
 Software Group engagements
 Best practices, checklists & honest advice rather than product features
 Have some sections suitable for everyone in a project team
 Should complement a Web services primer book
 Hands-on focus on IBM solutions with an end-to-end example
 New implementations vs. reliable older ones
 Short and concise
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Based on many experiences, including Sparkassen Informatik
 IBM’s largest Web Service reference to date:
 Provides IT solutions and services for 270 German savings banks (“Sparkassen”)
 137,000 Terminals / PCs and 25,000 self-service systems
 Heterogeneous integration to transactional core banking solution required
 Over 400 CICS Transactions on z/OS
 Typical non-functional requirements
270
Sparkassen
5 different
Interfaces
1 Central IT
Infrastructure
PMS
(D)COM
400+ Banking
Transactions
CORBA
JAVA
Web
Services
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Sparkassen Informatik solution architecture
Platform
Independent
Java Client
.NET Client
Browser
Office
Application
WSDL
Documentation
IBM
eServer
zSeries
pSeries
xSeries
TM
TM
IBM WebSphere®
generate
Web
Application
SOAP
generate
WEB SERVICES
Java Framework
TM
CICS
IBM
eServer
zSeries
Repository
Java Backend Connectors (IBM WebSphere MQ, CICS)
TM
Control Logic
Database
(IBM DB2)
generate
Business Logic
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Providing a (slightly cheesy) fictional end-to-end case study
 PremierQuotes Inc. is a fictitious insurance company specialising in
the high-end of the home insurance market. In order to fulfil growth
expectations it acquires DirtCheap Insurance.
 One year after the purchase, it decides to implement two new midoffice systems:
 A risk management application, which reports on the total insured
value and number of claims made broken down by postcode
 A fraud management application which searches across both division’s
policy management systems to identify if previous claims have been
made against the property
 The book follows various characters at PremierQuotes as they get to
grips with Web services to implement the systems, including:
Archie Tekt
Zippy Coder
Ed U. Cate
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
The Business Perspective
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.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
Web Services - Holy Grail or Déjà Vu?
 Typical responses range from euphoria to rejection via uncertainty
 Common requirements include:
 Automation through application clients
 Connectivity for heterogeneous worlds
 Information and process sharing
 Reuse and flexibility
 Dynamic discovery of service interfaces and implementations
 Business process orchestration without programming
 Additional advantages include:
 Non-invasiveness
 Productivity boost and industry momentum
 Standardisation and openness
 Low project risk
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
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.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Usage scenarios
Service
Integration
Level
Complex
Business
Processes
B2B
EAI
Business
Functions
(Use Cases)
Technical
Functions
&
Information
Services
Simple
Common Services (CS)
Intranet
Extranet
Internet
Service
Reach
 Plus: EDI replacement, portal adaptors, competency-focussed organisations,
mobile device communication, RMI/IIOP substitute, file transfer, grid computing …
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Addressing potential inhibitors
 The following are the most typical inhibitors to adoption. Most can be
overcome:
 Over-enthusiastic expectations
 Goal conflicts
 General scepticism regarding maturity of new technology
 Security and performance concerns
 Logistical and organisational issues
 Skill deficiencies
 Roll-your-own temptation
 You will not be able to convince everybody, just focus on the right
people
 The exact ROI and TCO is often difficult to determine up-front
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
The Training Perspective
Web services reuse wellestablished and proven
concepts.
I’ve already skimmed through
some WSDL, and I didn’t
understand a single line.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
Building blocks for delivering a service-oriented architecture
Discovery
Agency
UDDI / SOAP
Inquiry API
UDDI / WSIL
WSDL
UDDI / SOAP
Publish API
interface
Service
Requestor
Service
Provider
binding and
implementation
SOAP / HTTP or other Transports
XML Namespaces
XML Schema
XML Foundation
Interpretation of the core specifications and links through the WS-I basic profile 1.0
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
XML, XML Namespaces and XML Schema
 An XML overview
XML Application
 Valid and well-formed documents
XMLSchema , DTD
XML Processor
XML Instance
XML Instance
 The XML information set
XML Instance
 XML namespaces
 The namespace concept
A validating XML parser
Having a solid XML background is half-way
towards understanding Web services.
n
element
Property
children
Property
attributes
n
character
data
 Declaring XML namespaces
 XML schema
1
document
type
declaration
 Qualified Names
 Examples
document
0..1
 XML processor, instance, application
n
attribute
 The structure of an XML schema
 Simple and complex types
 Instance attributes
 Including and importing definitions
Information item types of an XML information set
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Understanding SOAP
Envelope
 The SOAP message format
 Message delivery and attributes
0..1
Mandatory
Optional
Body
Header
 SOAP message body
 SOAP message faults
1
Containment
Relationship
n
n
“header
entry”
“header
entry”
“body
entry”
“body
entry”
 SOAP Section 5 encoding
 Values and data types
SOAP message containment structure
 Encoding process
<Envelope>
<Header>
Header Entries
</Header>
<Body>
<operationlName>
<inputAccessor_1>
<inputAccessor_2>
<inputAccessor_3>
 Encoding ambiguity
 Communication styles
 Document style
 RPC style
Remote Procedure
Call
<inputAccessor_n>
</operationlName>
</Body>
</Envelope>
<Envelope>
<Header>
Header Entries
</Header>
<Body>
<operationNameReturn>
<return>
Return Value
</return>
<outputAccessor_1>
Value 1
</outputAcce ssor_1>
<outputAccessor_2>
Value 2
</outputAcce ssor_2>
Value 1
Value 2
Value 3
</inputAcce ssor_1>
</inputAcce ssor_2>
</inputAcce ssor_3>
Value n
</inputAcce ssor_n>
...
Remote Procedure
Call Response
...
<outputAccessor_m>
</operationNameReturn>
</Body>
</Envelope>
Value m
</outputAcce ssor_m>
A SOAP RPC style request and response
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Understanding WSDL
 The WSDL building blocks
type
binding
service
n
binding
portType
identical name attributes
n
 Implementation description
operation
operation
operation
operation
port
port
 Interface description
n
 The containment structure of WSDL
identical name attributes
or element names
1
1
input
output
 Service-interface related elements
1
n
1
fault
fault
input
n
fault
fault
output
message
 Network address information
message
Containment
Relationship
types
Linked-to
Relationship
n
“type
“type
definition”
definition”
message
message
n
element /
type
 Binding-related elements
part
part
Logical relationships between WSDL elements
 The SOAP binding
 Operation extensibility element
 Body extensibility element
 Fault extensibility element
 Header and Headerfault extensibility
elements
The WS-I basic profile 1.0 is an important step towards
true interoperability, especially in defining the link between
SOAP and WSDL which was previously not clear.
 Address extensibility element
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Understanding UDDI
 The UDDI registry structure
Web Service Provider Information
business
Entity
Identification of information entities
The identifier and category bags
 Linking WSDL to a UDDI registry
WSDL authoring for UDDI
Web Service Information
business
business
Service
Service
UDDI binding template
UDDI tModel
n
businessKey
businessKey
n
serviceKey
bindingKey
binding
binding
Template
Template
serviceKey
Web Service Access Information
tModel
tModel
n
tModel
1
 A brief UDDI API overview
0..1
n
name
description
description
0..1
0..1
0..1
overviewDoc
Publication API
UDDI is more likely to play a useful role in a private
environment where you can come up more easily
with a valuable category system.
tModelKey
m
Containment and reference relationship of data structures
tModels referring to WSDL
 Private vs. Public UDDI registries
Linked-to
Relationship
tModelInstanceDetails*
Web service binding templates
Inquiry API
Containment
Relationship
identifier
Bag
category
Bag
n
Mandatory
WSDL
Interface
and Binding
Document
overviewURL
description
description
Optional
Exclusive
Containment
Relationship
The tModel structure
URI Reference
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
The Architecture Perspective
My standard way of thinking and
decision-making will still work in this
only partially new environment.
I am also curious whether the classical
–ility requirements and our
performance demands can be met …
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
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 textbased, self-describing message exchange format?
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
W3C WSA solution architecture
Requestor
(Client)
Rich Client
Application
Web
Application
UDDI
Browser
Service
Proxy
HTTP
Client
Provider
(Service Tier)
Discovery Agency
Proxy (UDDI, WSIL)
SOAP
Client
HTTP Server
Web Container
UDDI Discovery Agency
SOAP Server
HTTP
Server
Web Service Implementation
Business Logic
SOAP
Server
JDBC
J2C
Adapter
UDDI
Web App
proprietary
Adapter
UDDI
Business Logic
Provider (Database)
Provider (Backend EIS)
UDDI
Database
RDBMS
ERP
RYO
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Architectural building blocks for a J2EE solution
Discovery Agency (incl. Publication Support)
UDDI
Web Application
Service Requestor
(Client)
UDDI
Database
other
Service Provider
(incl. Inspection
Support)
SOA Core Components & Utilities
(Wire and Description Stack Support)
UDDI4J
SOAP/JAX-RPC
(JSR 101)
WSDL4J
SAAJ, JAXM
(JSR 67)
Deployment
(JSR109)
WSIL
(decentral)
WSIL4J
WSIF
General Purpose Utilities
XML Parser
HTTP
J2SE/J2EE
(JDBC, J2C, ...)
Management
Support
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Some business and architectural patterns for SOAs
 Common business patterns or
“useful scenarios”:
 Component wrap, AKA unique
interface to existing system
 Common architectural patterns for
assembling software components
into reusable artefacts:
 Microflow pattern
 Asynchronous EAI cloud
 Intermediary pattern
 Shared B2B process
 Interceptors or pipeline pattern
 RMI/IIOP substitute
 Process choreography and service
/ microflow aggregation
 Anti-patterns
 Connecting layers within a single
application
 Public-to-private process mapping
 Low-level interactions facing
extreme non-functional
requirements
Note that these are equally applicable
to service-oriented architectures which
don’t use Web services.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Key architectural decisions which must be made
Architectural Decisions
Service
Modeling
Service
Messaging
Service
Matchmaking
SOA
in general
otther
XML
Parser
WSDL
Creation
SOAP
Runtime
Agency
Type
Granularity
Transport
Protocol
Implementation
Naming
Comm.
Style
Modelling
Encoding
Population
Compression
Access
Provider
Type
Requestor
Type
Validation
Character
Encoding
Deployment
Client API
Gateway,
other
Security
Architecture
Management
Operations
Accounting
Billing
Session
Management
System
Architecture
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
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 IBM building-blocks are now mature enough for prime-time
 Portability
 This is an API (rather than interface) issue. Stick to agreed industry
standards/specifications such as JAX-RPC and JSR 109
 Microsoft’s .NET SOAP language binding will always be proprietary
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Gaps and countermeasures
 The XML language binding and encoding maze
 WSDL and SOAP do not define any language bindings
 If you use rpc/encoded services, stick to the interoperable types
 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
 Many vendors are now entering this space, e.g. Amberpoint, HP (WSMF)
 Transactional and context semantics plus orchestration
 Still emerging: WS-Coordination, WS-Transaction, BPEL4WS
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Some FAQs which we answer … but won’t do in detail today














What if my backend systems lack modularity?
How about service versioning?
Should I cache anywhere?
How do I transfer object identities?
How should I handle large result sets?
Can you comment on asynchronous communication?
How useful are stateful services?
How should I transfer binary data?
Where are custom SOAP headers useful?
Can true interoperability be achieved?
How do I know whether two services are semantically equivalent?
How do I implement cross-provider security?
Are Web services suitable for pervasive scenarios?
How about reliable messaging?
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
The Development Perspective
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.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
IBM products which support Web services development
 The IBM WebSphere Studio Family
 Based on Eclipse
 WebSphere Studio Application Developer (WSAD)
 WebSphere Studio Application Developer Integration Edition (WSAD-IE)
 The free IBM WebSphere SDK for Web Services (WSDK)
 Command-line environment with new Eclipse tooling in v5.1
 The IBM Emerging Technologies Toolkit (ETTK) from alphaWorks
 Emerged from the IBM Web Services Toolkit (WSTK)
 The book focuses on the use of WSAD and the WSDK with two IBM
Web service implementations:
 The IBM JAX-RPC/JSR 109 implementation which is in the WSDK and
now WSAD 5.1.1/WAS 5.1 – recommended platform for new WAS apps
 Apache SOAP 2.3 + IBM extensions – good for back-level WAS users
 Axis is also covered, but not in detail as this is not likely to form part of
our supported platform in the products
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
JAX-RPC usage scenario
J2EE Container
J2SE
Server Side
JAX-RPC Runtime
Client Side
JAX-RPC Runtime
Service Endpoint
Service
Interface
Service
Client
Service
Object
(Factory)
Service
Endpoint
Interface
Service
Endpoint
Interface
Service
Endpoint
Implementation
Client
Stub
Transport
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
JAX-RPC and JSR 109 usage scenario
J2EE Container
J2EE Container
Server Side
JAX-RPC Runtime
Client Side
JAX-RPC Runtime
Service Endpoint
JNDI
Service
Interface
Service
Client
Service
Object
(Factory)
Service
Endpoint
Interface
Service
Endpoint
Interface
Service
Endpoint
Implemen tation
Client
Stub
Transport
Web
Services
Client DD
Web
Services
Server DD
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Development tasks which are detailed












Building rpc/encoded services from Java
Building Web service clients
Building rpc/encoded services from WSDL
Programmatic access to WSDL - JWSDL
Using WS-Inspection to build service indices
Using UDDI and UDDI4J
Using other Web services bindings - WSIF
Creating a document/literal service from WSDL
Creating a document/literal service client
Orchestrating Web services
Using attachments with SOAP - SAAJ
Using SOAP headers
 The tasks are based on the case study, and each incremental solution
can be downloaded from our FTP server
 Each task is also covered for both JAX-RPC/JSR 109 and Apache SOAP
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Some of our conclusions
 The tools will hopefully remove the need to code against either the
JAX-RPC or Apache SOAP APIs directly – use generated proxies
 Be very careful with Java package names and XML schemas –
establish conventions and expect to refactor all of the generated
source / documents
 Split WSDL is desirable (especially for WS-I compliance), but also
consider inline XML schemas
 The endpoint URL conventions between the implementations are
very different (generic vs. specific)
 IBM’s Apache SOAP 2.3 implementation is extended and is not the
same as the open-source version
 Using JWSDL is much easier than a JAX-P parser for
programmatically traversing WSDL documents, but always search
on the service binding, not the service interface
 WS-Inspection is a much simpler, distributed service index
mechanism than UDDI, but is still in its infancy and will hopefully be
auto-generated in the future
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Some of our conclusions (cont’d)
 UDDI4J is reasonably mature, very complex, but slightly flawed API.
JAXR will hopefully provide a single API in the future
 The open-source WSIF does a good job of addressing concerns
about the SOAP overhead when using Web services. However, it’s
current incarnation doesn’t support document/literal or SOAP
attachments, which is a big limitation
 Developing document/literal services typically involves more
programming effort than rpc/encoded, especially with Apache SOAP.
(Note, WSAD 5.1.1 now addresses this with better support for
document and rpc/literal)
 Process Choreographer in WSAD-IE provides a flexible approach for
orchestrating components into large-grained services, but is still
based on Apache SOAP and WSIF, with all of their limitations
 Creating services with attachments is easy when using the JAF
DataHandler class in your service interface.
 Support for SOAP headers in Apache SOAP is very poor. Don’t even
bother trying!
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
The Operational Perspective
Experience from previous projects
shows that the operational aspects
make or break project success.
We have to decide on the security
policy - corporate audit always has an
eye on first-of-a-kind solutions.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
Standalone topology
Outside World
Client Node
(Service Requestor)
Client Application
& SOAP Proxy
SOAP
Client Runtime
Intranet, Extranet
Firewall 1
DMZ 1
HTTP Server Node
Firewall 2
DMZ 2
Web Application
(Service Provider)
Node
SOAP Server
Runtime incl.
Router Servlets
Database
Firewall 3 (optional)
Web Service
Implementations
(Providers)
Backend
EIS/ERP
Nodes
Database
Node
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Standalone topology with Web services-specific components
Outside World
Client Node
(Service Requestor)
Intranet, Extranet
Firewall
DMZ 1
HTTP Server Node
Firewall
DMZ 2
Web Services
Gateway
Application
Gateway
Node
Private
UDDI Registry
UDDI
Web Application
Node
Web Application
Node
(Service Provider)
Database
Node
Firewall (optional)
Backend
EIS/ERP
Nodes
Database
Node
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Clustered and managed topology
Outside World
Client Node (Service Requestor)
WWW, Extranet
Support DMZ
DMZ 1
IP Sprayer 1, 2
Reverse
Authenticating
Proxy Node 1
Reverse
Authenticating
Proxy Node 2
Firewall 2 (Application Level Gateway)
DMZ 2
HTTP Server &
Web Application
Node 1
(Service Provider)
HTTP Server &
Web Application
Node 2
(Service Provider)
Database
Node 1
Database
Node 2
Firewall 4 (Network Segmentation)
Firewall 1 (Network Protection)
Acess
Management
Node
Directory
Node
Utility Services
Node
Management
Node
Firewall 3 (Protocol Filter)
Backend
EIS/ERP
Nodes
Database
Node 3, 4
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
IBM products which support Web services deployment
WebSphere Application Server, Enterprise
WebSphere Application Server, Network Deployment
WebSphere Application Server
WebSphere Application Server Express
 5.1 is the latest edition of WAS, which now supports JAX-RPC, JSR
109, WS-I basic profile 1.0 and WS-Security
 Express is not licensed for service providers – only consumers, and
only includes a subset of JSR 109 (no EJB container)
 Network Deployment includes the IBM Web Services Gateway and
Private UDDI registry
 Enterprise contains the Process Choreographer engine and a
slightly enhanced Gateway
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Deployment approaches
 EAR packaging structure still holds
 JSR 109 adds additional deployment descriptors – webservices.xml
and webservicesclient.xml which are picked up by the container
 Deployment can be through a number of approaches
 WebSphere Admin GUI
 wsadmin command line tool
 ANT scripts using the WebSphere extensions, e.g. wsInstallApp
 No problems in deploying in a multiple-node configuration through
the WebSphere v5 Deployment Manager and Node Agent hierarchy
 However, note that IBM Cloudscape databases can only be used in
a single-node configuration
 This is a key consideration when using the IBM Private UDDI registry
 Switching to DB2 or buying the full-function Cloudscape product avoids
this issue
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Securing Web services with HTTPS and SSL
 Authentication can be performed against either WebSphere or the HTTP
Server
The key management process is subtly different for each
Supports both client and server authentication
The client then uses JSSE – either IBM or Sun implementation
Sun has better tracing, but will not run inside the WebSphere Web container
Service Requestor
Service Provider
IBM HTTP Server
PremierMidOffice
PremierPolicy
HTTPS
Assessment
TestClient
HTTP
WebSphere
Plug-in
Assessment
Service
Assessment
TestServlet
PremierWebserverCert.arm
(Web Server Certificate)
Client
Key File
Client
Trust File
PremierMidOffice PremierMidOffice
KeyFile.jks
TrustFile.jks
Web
Server
Key File
PremierWebserver
KeyFile.kdb
PremierMidOfficeCert.arm
(Client Certificate)
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Relationships between the WS-Security specifications
WS-Federation
WS-Secure
Conversation
Application Layer
SOAP
WS-Trust
WSPrivacy
WSAuthorization
WS-Security
Policy
WS-Policy
Envelope
Extensions
XML
WS-Security
Transport
Layer
XML
XML Signature
XML Encryption
Token
Extensions
XrML
SAML
XML
Key Mgmt.
http, MQ, ftp …
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 (future) Web services extensions.
 WAS usage typically not programmatic (edit DDs) – unlike .NET
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
The IBM Web Services Gateway
 Described as an administered, configurable proxy
 Delivered on top of WSIF, and inherits its current limitations
 Really only supports SOAP over HTTP in the WAS ND/EE releases
 Need to buy WBI Connect for SOAP over JMS support + other channels
 Logging and custom filters difficult to set up & not well documented
 Good at concealing final service endpoints for public services
 But significant overhead – consider usage/requirements carefully
Embedded
HTTP Server
Binding 2, e.g.
SOAP-HTTP
Web Services
Gateway
HTTP Server
Service
Client
WebSphere
Plug-in
WSDL 2
With HTTP
Binding
(Optional Firewall)
Channel
Custom
Filters
WebSphere
Application Server
Binding 1, e.g.
Java
Service
Provider
WSDL 1
With Java
Binding
(Optional Firewall)
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
The Engagement Perspective
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
adopters of this technology.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
Success factors, elements of risk and project structure
 Critical success factors
 Elements of risk
Project scope
Hype vs. reality
Management commitment
Technology evolution
Requirements engineering
Competing specifications
Architecture in place
Lack of skills
Tool availability
Open source involvement
Team setup
Proprietary code
Other participants
Time
P1: Feasibility Study
P2: Proof of Concept
P3: Production Project
Step 1: Identify
Step 2: Outline
Step 3: Plan
Step 4: Run
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Lessons learned from our projects
 Good news
 Web services are ready for production use in real-life
 Three phased project approach is useful
 Over-optimism and scepticism are manageable
 Tools speed up the project tremendously
 Performance is typically acceptable to good
 Web services has achieved more interoperability in 2 years than
CORBA managed in a decade
 Less entertaining results
 SOAP section 5 encoding has a lot of value-add, and its removal from
the WS-I basic profile 1.0 is disappointing (but justified)
 Be careful with Null values: xsd:nillable and xsi:isNull
 Case sensitivity issues and JavaBean decapitalisation algorithm
 Open source vs. vendor supported APIs and their mismatches
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Best practice highlights I: WSDL and modelling
Follow the bottom-up design
 Follow the design by contract principle
approach by default
 Separate concerns and isolate interface from implementation
 Provide interoperable versions ofGenerating
your WSDLWSDL
specifications
from server side Java
 Follow the bottom-up design approach
by default
is generally
a good idea, if you make
 Expose coarse-grained interfacessure no programming language
 Avoid complex operation signatures,
stick with
specifics
makerequest-response
it into your interface.
 Stick to standard XML schema data
Thistypes
provides a jump-start for beginners.
 Keep service, method, parameter and type names small and simple
Follow the
design
by contact
principle
Apply
general
XML and
XML schema best practices
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.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Best practice highlights II: SOAP and messaging
Carefully
observe
the messaging
 Use HTTP as the default transport,
but consider
alternative
bindings
 Carefully observe the messagingoverhead
overhead
 By aware of the trade-off between security and performance
known as
verbosity. The
 Design your Web services to be Also
as stateless
asSOAP
possible
overhead can
be three
to 20 times,
 Avoid custom mappings, write server-side
facades
instead
depending
the naming
 Include, but do not rely on the HTTP
SOAP on
action
header conventions
and
theother
nesting
levels of the document.
 Be careful with message handlers
and
intermediaries
TCP
monitors
and try different
 Try to leverage existing transportUse
layer
or XML
compression
features
runtime
parsers/engines.
Include,but
not of
rely
the HTTPbetween
Bedo
aware
theon,
differences
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.
This will be deprecated in the future, but
certain SOAP engines might still expect it
to be present.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Best practice highlights III: UDDI and matchmaking
 Carefully evaluation which type of UDDI registry (private vs. public)
is suited for your scenario
Carefully
evaluate which type of UDDI
 Consider lightweight alternatives
to UDDI
registry
is suitedbyfor
your scenario
 Obey the best practices already
established
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.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Best practice highlights IV: SOA and project approach in general
Apply
standards
 Clearly identify business need and
project
scope pragmatically:
follow the
rule
 Decide carefully whether Web services
are 80-20
the right
technology for
your problem at hand
Do notthe
always
 Apply standards pragmatically: follow
80-20use
ruleall of the features
the ifW3C
 Use stateless session EJBs are defined
providerintype
EJBsWSA.
exist Upgrade
in your to
high specification levels only if there is a
architecture
concrete need,
for its own sake (e.g.
 Do not over-architect, do not under-architect
andnot
develop
SOAP 1.1 vs. 1.2). The 80-20 or “keep it
Resist theincrementally
temptation to be oversimple” rule helps with interoperability.
creative Resist the temptation to be over-creative
 Design for performance
Do not implement
your own SOAP
layer;
 Apply performance
measurement
best practices
any RYO approach
the
Test earlycompromises
and often
Web services
value proposition.
Let experience
the
 Leverage
already gained
vendor labs and open source community
worry about the runtime, otherwise RYO
is likely to become rewrite your own
(every time).
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
The Future Perspective
The next wave of specifications will be
so thick that no vendor can fully
implement it.
A lot is going on under the
semantic Web banner, initiated by
Tim Berners-Lee. A breakthrough
can be achieved.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
Introducing the Web services-based world of the future
 Emerging specifications
 SOAP version 1.2
 WSDL version 1.2
 UDDI version 3.0
 J2EE and Web Services
 J2EE 1.4 (now final) – includes JAX-RPC, SAAJ, JAXR
 Plus JSRs 104, 105, 106, 155, 172, 181, 183 and 207 …
 Other specifications
 BPEL4WS
 WS-ReliableMessaging, WS-Addressing
 WSMF
 Grid computing, OGSI/OGSA and the Globus toolkit
 The semantic Web
 Resource Description Framework (RDF) and Web Ontology Language (OWL)
 Service modelling
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
Appendix C#
(At the back, where it deserves to be)
To demonstrate that Web services
are truly interoperable, we show
how to develop .NET clients for
our services.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
Overview to building .NET Web service clients
 Our focus was only on the client-side
 Uses free command-line Microsoft .NET Framework SDK 1.1
 Same tools which are used by Visual Studio .NET
 Also check out the free SharpDevelop and Eclipse-based Improve C#!
 Both rpc/encoded and document/literal services generated by the
JAX-RPC and Apache SOAP tools work fine
 Key findings:
 Their tooling doesn’t support local file includes in WSDL documents
 Target namespace of the imported document must be different to that
of the importing document. Define all of your own type definitions within
one single XSD file.
 Make sure you update the .NET framework security settings
 Be careful with version 1.0 of the SDK – we experienced
deserialisation errors which meant no meaningful results were
displayed.
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
®
IBM Software Group | Cross-brand Web Services Team
Any questions?
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
®
IBM Software Group | Cross-brand Web Services Team
Summary
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
October 2003
Our objectives for the book
 Focus on “Real world projects”
 Many IBM Global Services and jStart customer engagements
 Try to document and answer all the hard questions we get asked in the
field by you!
 Software Group engagements
 Best practices, checklists & honest advice rather than product features
 Have some sections suitable for everyone in a project team
 Should complement a Web services primer book
 Hands-on focus on IBM solutions with an end-to-end example
 New implementations vs. reliable older ones
Not short, but still concise
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Fantastic reviews!
“Over the past couple of years, I’ve been helping a handful of projects make the move to
Web service-oriented architectures, and I certainly wish that I’d had this book at my
disposal, for it definitely would have made my life a whole lot easier.”
From the foreword by Grady Booch, Chief Scientist, IBM Rational
“This book covers all the important aspects
for a successful Web service project and I
strongly recommend it if you are going to
start one.”
Amazon reviewer
“The title of this book promises a lot.
To make it short, it holds what it
promises… Five stars for a great
book about the Web services world.”
Amazon reviewer
"The real-world experience and best practices presented
by the authors are worth their weight in gold!"
Steve Graham, Author of "Building Web Services with
Java: Making Sense of XML, SOAP, WSDL and UDDI"
“Great work, all three of you (authors) have
helped the IBM Web services cause immensely.”
IBM executive
“Nice job. Good intro to the subject, without
being dumb. I will be passing it on to the
developers.”
IBM customer
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003
Check out our Web site – www.perspectivesonwebservices.de
Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005
© Springer Verlag Heidelberg New York 2003