IBM Software Group | Cross-brand Web Services Team ® October 2003 Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005 © Springer Verlag Heidelberg New York

IBM Software Group | Cross-brand Web Services Team

®

October 2003

Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005© Springer Verlag Heidelberg New York 2003

Building service-oriented architectures with Web services

Extracts from “Perspectives on Web Services – Applying SOAP, UDDI and WSDL to Real-World Projects”


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


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.


®

October 2003


Background to the book


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.

Stefan Peuser is an IBM Consulting IT Architect, working for IGS e-business Innovation and Integration services.

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.

… plus help from Frank Müller, Sven Milinski, Michael Pühlhöfer, Marc Pestel, Christoph Pürckhauer and many, many others


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


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


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

PMS

(D)COM

5 different Interfaces

400+ Banking Transactions

1 Central IT Infrastructure

CORBA

JAVA

Web ServicesWeb

Services


Sparkassen Informatik solution architecture

Java Client

Web Application

.NET Client BrowserOffice

Application

WEB SERVICES

Java Framework

Java Backend Connectors (IBM WebSphere MQ, CICS)

Control Logic

Business Logic

WSDL

generate

generateDatabase(IBM DB2)

Repository

generate

Documentation

IBMeServerzSeriespSeriesxSeries

IBMeServerzSeries

Platform Independent

TM

TM

TM

TM

CIC

SIB

M W

ebS

ph

ere®

SOAP


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 mid-office 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


®

October 2003


The Business Perspective

There have been other distributed computing models,

but this time it’s serious.

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.

This is just another reinvention of the wheel, the most

pointless hype in years.


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


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.


Usage scenarios

Plus: EDI replacement, portal adaptors, competency-focussed organisations, mobile device communication, RMI/IIOP substitute, file transfer, grid computing …


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


®

October 2003


The Training Perspective

Web services reuse well-established and proven

concepts.

Web services reuse well-established and proven

concepts.

I’ve already skimmed through some WSDL, and I didn’t understand a single line.

I’ve already skimmed through some WSDL, and I didn’t understand a single line.


Building blocks for delivering a service-oriented architecture

XML Foundation

XML SchemaXML Namespaces

WSDL

SOAP / HTTP or other Transports

ServiceRequestor

ServiceProvider

UDDI / SOAPInquiry API

UDDI / SOAPPublish API

UDDI / WSIL

interface

binding andimplementation

DiscoveryAgency

Interpretation of the core specifications and links through the WS-I basic profile 1.0


XML, XML Namespaces and XML Schema

An XML overview Valid and well-formed documents

XML processor, instance, application

The XML information set XML namespaces

The namespace concept

Qualified Names

Declaring XML namespaces

Examples XML schema

The structure of an XML schema

Simple and complex types

Instance attributes

Including and importing definitions

XMLSchema , DTD

XML InstanceXML Instance

XML Processor

XML Instance

XML Application

document

element

1

n

attribute

n

Propertychildren

characterdata

n

documenttype

declaration

0..1

Propertyattributes

Having a solid XML background is half-way towards understanding Web services.

A validating XML parser

Information item types of an XML information set


Understanding SOAP

The SOAP message format Message delivery and attributes

SOAP message body

SOAP message faults SOAP Section 5 encoding

Values and data types

Encoding process

Encoding ambiguity Communication styles

Document style

RPC style

Envelope

“body entry”“body entry”

Header Body

“header entry”“header entry”

10..1

nn

Mandatory

Optional

ContainmentRelationship

<Envelope><Header>

Header Entries</Header>

<Body><operationlName><inputAccessor_1><inputAccessor_2><inputAccessor_3> ...<inputAccessor_n>

</operationlName></Body>

</Envelope>

</inputAccessor_1></inputAccessor_2></inputAccessor_3>

</inputAccessor_n>

Value 1Value 2Value 3

Value n

<Envelope><Header>

Header Entries</Header><Body>

<operationNameReturn>

<outputAccessor_1><outputAccessor_2> ...<outputAccessor_m>

</operationNameReturn></Body>

</Envelope>

</outputAccessor_1></outputAccessor_2>

</outputAccessor_m>

Value 1Value 2

Value m

<return> </return>Return Value

Remote ProcedureCall

Remote ProcedureCall Response

SOAP message containment structure

A SOAP RPC style request and response


Understanding WSDL

The WSDL building blocks Interface description

Implementation description The containment structure of WSDL

Service-interface related elements

Binding-related elements

Network address information The SOAP binding

Operation extensibility element

Body extensibility element

Fault extensibility element

Header and Headerfault extensibility elements

Address extensibility element

“typedefinition”

faultfault

port


Linked-toRelationship

binding

operation

input output fault

operation

11

n

n

port

binding

service

n

message

operation

types

“typedefinition”

nelement /

type

message

part

n

part

input output fault

operation

11

n

messagemessage

portType

n

type

identical name attributes

identical name attributesor element names

The WS-I basic profile 1.0 is an important step towardstrue interoperability, especially in defining the link betweenSOAP and WSDL which was previously not clear.

Logical relationships between WSDL elements


Understanding UDDI

The UDDI registry structureIdentification of information entities

The identifier and category bags

UDDI binding template

UDDI tModel Linking WSDL to a UDDI registry

WSDL authoring for UDDI

Web service binding templates

tModels referring to WSDL A brief UDDI API overview

Inquiry API

Publication API Private vs. Public UDDI registries

businessEntity

businessServicebusinessService

n

bindingTemplate

bindingTemplate n


Linked-toRelationship

tModeltModel

tModelInstanceDetails*

Web Service Provider Information

Web Service Information

Web Service Access Information

businessKey

serviceKey

businessKey

serviceKey

tModelKeybindingKeym

n

description

tModel

descriptiondescription

n

name

1

overviewDoc

0..1

categoryBag

0..1

identifierBag

0..1

descriptionoverviewURL

0..1

WSDLInterface

and BindingDocument

n


URI Reference

Mandatory

Optional

Exclusive

Containment and reference relationship of data structures

The tModel structureUDDI is more likely to play a useful role in a private environment where you can come up more easily with a valuable category system.


®

October 2003


The Architecture Perspective

My standard way of thinking and decision-making will still work in

this only partially new environment.

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 …

I am also curious whether the classical –ility requirements and our performance demands can be met …


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?


W3C WSA solution architecture

Provider(Service Tier)

Provider (Database) Provider (Backend EIS)

HTTP Client

Requestor(Client)

HTTP Server

UDDI Discovery Agency

UDDI Database

UDDI Business Logic

SOAPServer

UDDI Web App

J2C Adapter

proprietaryAdapter

JDBC

HTTP ServerWeb Container

SOAP Server

SOAP Client

Discovery AgencyProxy (UDDI, WSIL)

Service Proxy

Web Service ImplementationBusiness Logic

Rich Client Application

UDDI Browser

WebApplication

RDBMS ERP RYO


Architectural building blocks for a J2EE solution

WSIL4J

WSDL4J

UDDI4J

Service Requestor (Client)

Service Provider(incl. Inspection Support)

WSIL(decentral)

SOAP/JAX-RPC(JSR 101)

SOA Core Components & Utilities(Wire and Description Stack Support)

UDDIWeb Application

Discovery Agency (incl. Publication Support)

UDDIDatabase

Deployment(JSR109)

XML ParserManagement

Support

General Purpose Utilities

J2SE/J2EE(JDBC, J2C, ...)

HTTP

other

SAAJ, JAXM(JSR 67)

WSIF


Some business and architectural patterns for SOAs

Common business patterns or “useful scenarios”:

Component wrap, AKA unique interface to existing system

Asynchronous EAI cloud

Shared B2B process

RMI/IIOP substitute Anti-patterns

Connecting layers within a single application

Low-level interactions facing extreme non-functional requirements

Common architectural patterns for assembling software components into reusable artefacts:

Microflow pattern

Intermediary pattern

Interceptors or pipeline pattern

Process choreography and service / microflow aggregation

Public-to-private process mapping

Note that these are equally applicable to service-oriented architectures which

don’t use Web services.


Key architectural decisions which must be made

Architectural Decisions

ServiceModeling

WSDL Creation

Granularity

Naming

ServiceMessaging

SOAPRuntime

TransportProtocol

Comm.Style

Encoding

Compression

ServiceMatchmaking

SOAin general

Client API

XMLParser

ProviderType

RequestorType

Validation

CharacterEncoding

Deployment

SystemArchitecture

otther

AgencyType

Implemen-tation

Modelling

Population

Access

Gateway,other

SecurityArchitecture

ManagementOperations

AccountingBilling

SessionManagement


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


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


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?


®

October 2003


The Development Perspective

Web services programming isn’t fundamentally different from what

I’ve been doing with J2EE and XML.

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.

I bet I can get some of these new wizards and tools to do most of the

hard work.


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


JAX-RPC usage scenario

Client Side JAX-RPC Runtime

Server Side JAX-RPC Runtime

ServiceInterface

ServiceEndpointInterface

ServiceClient

Transport

J2SE J2EE Container

ClientStub

ServiceObject

(Factory)

Service Endpoint

ServiceEndpoint

Implemen-tation



JAX-RPC and JSR 109 usage scenario

Client Side JAX- RPC Runtime

Server Side JAX- RPC Runtime

ServiceInterface


ServiceClient

Transport

J2EE Container

ClientStub

ServiceObject

(Factory)

Service Endpoint

ServiceEndpoint

Implemen-tation


J2EE Container

JNDI

Web ServicesClient DD

Web Services

Server DD


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


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


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!


®

October 2003


The Operational Perspective

Experience from previous projects shows that the operational aspects

make or break project success.

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.

We have to decide on the security policy - corporate audit always has an eye on first-of-a-kind solutions.


Standalone topology

Client Node(Service Requestor)

Firewall 1

HTTP Server Node

Web Application(Service Provider)

NodeDatabase

Firewall 3 (optional)

Intranet, Extranet

DMZ 2

Backend

Outside World

EIS/ERPNodes

Firewall 2

DMZ 1

Client Application & SOAP Proxy

SOAP Server Runtime incl.

Router Servlets

SOAPClient Runtime

Web Service Implementations

(Providers)

Database Node


Standalone topology with Web services-specific components

Client Node(Service Requestor)

Firewall

Web ApplicationNode

(Service Provider)Database

Node

Firewall (optional)

Intranet, Extranet

GatewayNode

UDDI Web Application

Node

EIS/ERPNodes

DMZ 1

Backend

Outside World

Web Services Gateway

ApplicationPrivate

UDDI Registry

HTTP Server Node

Firewall

DMZ 2

Database Node


Clustered and managed topology

Client Node (Service Requestor)

IP Sprayer 1, 2

HTTP Server &Web Application

Node 1(Service Provider)

Database Node 1

Firewall 1 (Network Protection)

Firewall 2 (Application Level Gateway)

Firewall 3 (Protocol Filter)

Reverse Authenticating Proxy Node 1

Reverse Authenticating Proxy Node 2

Acess Management

Node

DirectoryNode

Utility ServicesNode

Database Node 2

HTTP Server &Web Application

Node 2(Service Provider)

EIS/ERPNodes

DMZ 1

DMZ 2

Backend

Outside World

WWW, Extranet

Fir

ewal

l 4 (

Net

wo

rk S

egm

enta

tio

n)

ManagementNode

Support DMZ

Database Node 3, 4


IBM products which support Web services deployment

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

WebSphere Application Server

WebSphere Application Server, Network Deployment

WebSphere Application Server, Enterprise

WebSphere Application Server Express


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


Securing Web services with HTTPS and SSL Authentication can be performed against either WebSphere or the HTTP

ServerThe 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

AssessmentTestClient

PremierMidOfficeKeyFile.jks

PremierMidOfficeTrustFile.jks

AssessmentTestServlet

PremierWebserverKeyFile.kdb

PremierMidOffice

Service Requestor IBM HTTP Server

PremierWebserverCert.arm(Web Server Certificate)

PremierMidOfficeCert.arm(Client Certificate)

ClientKey File

ClientTrust File

WebServer

Key File

HTTPS

AssessmentService

PremierPolicy

Service Provider

WebSpherePlug-in

HTTP


Relationships between the WS-Security specifications

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

Tra

nsp

ort

L

aye

rA

pp

lica

tio

n L

ayer

TCP/IP

http, MQ, ftp …

XML

SOAP

XML Signature XML Encryption XML Key Mgmt.

WS-Security

SSL

Envelope Extensions

Web Service Foundation Security Extensions

WS-Policy

WS-SecurityPolicy

WS-Trust

WS-Privacy

WS-SecureConversation

WS-Authori-zation

XrML SAML

XML Token Extensions

WS-FederationT

ran

spo

rt

Lay

er

Ap

plic

ati

on

Lay

er

TCP/IP

http, MQ, ftp …

XML

SOAP

XML Signature XML Encryption XML Key Mgmt.

WS-Security

SSL

Envelope Extensions

Web Service Foundation Security Extensions

WS-Policy

WS-SecurityPolicy

WS-Trust

WS-Privacy

WS-Privacy

WS-SecureConversation

WS-Authori-zation

WS-Authori-zation

XrML SAML

XML Token Extensions

WS-Federation


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

HTTP Server

WebSphere Plug-in

Embedded HTTP Server

WebSphere Application Server

Web ServicesGatewayService

ClientServiceProvider

Channel

CustomFilters

(Optional Firewall) (Optional Firewall)

Binding 2, e.g.SOAP-HTTP

Binding 1, e.g.Java

WSDL 2With HTTP

Binding

WSDL 1With JavaBinding


®

October 2003


The Engagement Perspective

We have to manage expectations so that we can be sure to deliver in time

and on budget.

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.

We don’t want to repeat all the mistakes made by the very early

adopters of this technology.


Success factors, elements of risk and project structure

Critical success factorsProject scope

Management commitment

Requirements engineering

Architecture in place

Tool availability

Team setup

Other participants

Elements of riskHype vs. reality

Technology evolution

Competing specifications

Lack of skills

Open source involvement

Proprietary code


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


Best practice highlights I: WSDL and modelling

Follow the design by contract principle Separate concerns and isolate interface from implementation Provide interoperable versions of your WSDL specifications Follow the bottom-up design approach by default Expose coarse-grained interfaces Avoid complex operation signatures, stick with request-response Stick to standard XML schema data types Keep service, method, parameter and type names small and simple Apply general XML and XML schema best practicesFollow the design by contact 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.

Follow the design by contact 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.

Follow the bottom-up design approach by default

Generating WSDL from server side Java is generally a good idea, if you make sure no programming language specifics make it into your interface. This provides a jump-start for beginners.

Follow the bottom-up design approach by default

Generating WSDL from server side Java is generally a good idea, if you make sure no programming language specifics make it into your interface. This provides a jump-start for beginners.


Best practice highlights II: SOAP and messaging

Use HTTP as the default transport, but consider alternative bindings Carefully observe the messaging overhead By aware of the trade-off between security and performance Design your Web services to be as stateless as possible Avoid custom mappings, write server-side facades instead Include, but do not rely on the HTTP SOAP action header Be careful with message handlers and other intermediaries Try to leverage existing transport layer or XML compression features Be aware of the differences between JAX-RPC and Apache SOAPInclude, but do not rely on, the HTTP

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.

Include, but do not rely on, the HTTP 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.

Carefully observe the messaging overhead

Also known as SOAP verbosity. The overhead can be three to 20 times, depending on the naming conventions and the nesting levels of the document.Use TCP monitors and try different runtime parsers/engines.

Carefully observe the messaging overhead

Also known as SOAP verbosity. The overhead can be three to 20 times, depending on the naming conventions and the nesting levels of the document.Use TCP monitors and try different runtime parsers/engines.


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 to UDDI Obey the best practices already established by UDDI.org

Carefully evaluate which type of UDDI registry is suited for your scenario

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.

Carefully evaluate which type of UDDI registry is suited for your scenario

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 and project scope Decide carefully whether Web services are the right technology for

your problem at hand Apply standards pragmatically: follow the 80-20 rule Use stateless session EJBs are provider type if EJBs exist in your

architecture Do not over-architect, do not under-architect and develop

incrementally Resist the temptation to be over-creative Design for performance Apply performance measurement best practices Test early and often Leverage already gained experience

Resist the temptation to be over-creative

Do not implement your own SOAP layer; any RYO approach compromises the Web services value proposition. Let the vendor labs and open source community worry about the runtime, otherwise RYO is likely to become rewrite your own (every time).

Resist the temptation to be over-creative

Do not implement your own SOAP layer; any RYO approach compromises the Web services value proposition. Let the vendor labs and open source community worry about the runtime, otherwise RYO is likely to become rewrite your own (every time).

Apply standards pragmatically: follow the 80-20 rule

Do not always use all of the features defined in the W3C WSA. Upgrade to high specification levels only if there is a concrete need, not for its own sake (e.g. SOAP 1.1 vs. 1.2). The 80-20 or “keep it simple” rule helps with interoperability.

Apply standards pragmatically: follow the 80-20 rule

Do not always use all of the features defined in the W3C WSA. Upgrade to high specification levels only if there is a concrete need, not for its own sake (e.g. SOAP 1.1 vs. 1.2). The 80-20 or “keep it simple” rule helps with interoperability.


®

October 2003


The Future Perspective

The next wave of specifications will be so thick that no vendor can fully

implement it.

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.

A lot is going on under the semantic Web banner, initiated

by Tim Berners-Lee. A breakthrough can be achieved.


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


®

October 2003


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.

To demonstrate that Web services are truly interoperable, we show how to develop .NET

clients for our services.


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.


®

October 2003


Any questions?


®

October 2003


Summary


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


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

“Nice job. Good intro to the subject, without being dumb. I will be passing it on to the developers.”

IBM customer

“Great work, all three of you (authors) have helped the IBM Web services cause immensely.”

IBM executive

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


Check out our Web site – www.perspectivesonwebservices.de

Documents

IBM Software Group | Cross-brand Web Services Team ® October 2003 Olaf Zimmermann and Mark Tomlinson | OOPSLA 2005 © Springer Verlag Heidelberg New York