12 Web Services Best Practices

IBM Software Services for WebSphere
Web Services Best Practices
© 2003 IBM Corporation
12_WebServices_BestPractices.ppt Page 1 of 44
Agenda
What are WebServices?
How do they help?
What’s this “Service Oriented Architecture” Thing?
Architectural Best Practices
Design Best Practices
Interoperability Best Practices
Performance Best Practices
Web Services Best Practices © 2003 IBM Corporation
The IT-related problems facing business today

Drive down cost
ƒEliminate duplicate systems
ƒRe-use, don't re-build
ƒSimplify skills base
Reduce cycle time and costs for external business processes
ƒMove from manual transactions with suppliers towards automated transactions
ƒFacilitate flexible dealings with partners with minimal process or IT impact
Support an on-demand business model
ƒThe marketplace is changing - businesses need to change too
ƒMany existing IT systems are inhibitors to change: complex and inflexible
ƒExisting integrations can be inhibitors to change: multiple technologies, point-to-
point integration, inflexible models
Integrate across the enterprise
ƒIntegrate historically separate systems
ƒCompletion of mergers and acquisitions
ƒAcross physical and technology barriers
So, what has stopped us solving them?

A multitude of technologies and platforms support your business systems
Business process models are a mixture of people practises, application code and
interactions between people and systems or between systems and systems
Changes to one system tend to imply ripples of change at many levels to many other
systems
No single, fully functional, integration solution will talk to them all
Deployment of any single, proprietary integration solution across the enterprise is
complex, costly and time consuming
Will any one integration solution talk to your partners'? Your future partners'?
No single data / business / process model across (or beyond) the enterprise
Not all integration technologies work as well across a wide area network or the
internet as they do across a local area network
ƒExotic protocols
ƒDifficulties with firewalls
ƒNetwork bandwidth
Integration on a vast scale
Industry Finance Manufac- Dist-

Retail Telecom Gov't. ...
Solutions turing ribution
Customer Enterprise Project Value

Relationship Resource Lifecycle Chain
Management Planning Management Management
Suppliers &
Customers
Distributors
Infrastructure
Business Integration Employees (inter- & intra-enterprise)
Is Web Services the answer? Sort of ...
Web Services are part of the answer ... but mostly we'll get to that later
Service Oriented Architecture (SOA) is another part
The two are not the same thing:
ƒMost of today's production Web Services systems aren't service oriented
architectures - they're simple remote procedure calls or point-to-point messaging
via SOAP
ƒMost of today's production service oriented architectures don't primarily use Web
Services - many use existing mature technologies, such as XML, asynchronous
messaging etc.
To really achieve the promoted benefits of Web Services, you need both
And just what is a Service Oriented Architecture?

Service oriented architectures are intended to promote flexibility via clear definition and
loose coupling
All functions (that need to be used by more than one system) are defined as "services"
Service providers agree a defined, implementation-independent interface with service clients
There is only one instance of each service implementation, either at:
Runtime
ƒEach service, e.g. exchange rate calculation, is deployed in one place and one place only,
and is remotely invoked by anything that needs to use it
Deployment time
ƒEach service is built once, but re-deployed to be invoked semi-locally wherever it is needed
These concepts are intended to take "re-use" beyond the more usually achieved "design-time"
re-use, i.e. where function is built once, then deeply embedded, e.g. as a shared code library, in
whatever systems need it.
But, what is a service?

Any function ... but perhaps at several levels of granularity, e.g.:
Business Process Services:
ƒcreateStockOrder
ƒreconcileAccount
Business Transaction Services:
ƒcheckOrderAvailability
ƒcreateBillingRecord
Business Function Services:
ƒcalculateDollarValueFromYen
ƒgetStockPrice
Technical Function Services:
ƒauditEvent
ƒcheckUserPassword
There's value in thinking of all of these as "Services", i.e. with defined
interfaces and runtime, deploy-time (or perhaps design-time) re-use
Services – Some ground rules
A service encapsulates a well-defined invokable unit of business function, and

exists either to provide information or to facilitate a change of business data
from one valid and consistent state to another.
Services neither remembers the last thing they were asked to do nor care
what the next is, and are not dependent on the context or state of other
services.
Any dependencies between services should be defined in terms of common

business process, function and data models.
Services are defined using explicit interfaces that are independent of service
implementations, and that both service requestors and service providers
agree to.
Services should be invokable through defined communication protocols that

stress interoperability and location transparency.
From what SOA “is” to “what” it does for you:

Encapsulation enables re-use: each element of your business is captured
and implemented in only one place, so changing it is straightforward.
ƒThere are benefits in development and maintenance costs, but flexibility is the
primary goal in Service Oriented Architecture.
The use of implementation independent interfaces to describe this
encapsulation means that heterogenous systems can be integrated, and
changes to one lead to fewer knock-on effects.
ƒObject programming via interfaces has been common for years; now we're
moving up to integration via interfaces to realise the same benefits at the
enterprise level.
With clearly defined interfaces between all business systems, you can start
modelling (and changing) the business process captured by them at a level
above individual systems.
ƒService Oriented Architectures are an enabler for process modelling and
automation at a truly enterprise scale.
What's so special about these interfaces?

There are two important characteristics of interfaces within a service
oriented architecture:
SYSTEM 1
Interface by contract Internal code
ƒAn explicit interface definition or contract and
is used to bind a service requestor and a processs
service provider
ƒSpecifies explicitly only the mutual Interface Code
behaviour - specifies nothing about the
implementation of the requestor or the CONTRACT
provider
Shared process and
ƒAllows either to change implementation interface definitions
or identity freely
Interface granularity
Interface Code
ƒLarger grained
ƒLoosely coupled Internal code
and
processs
SYSTEM 2
"Service" Interfaces vs. "Component" Interfaces ...

Think of the difference between applying for a mortgage over the phone or by
post ...
By post: By phone:
•Client requests application form •Client calls provider
•Provider sends it •Provider says "Hello, how can we help"
•Client fills it in and returns it •"I'd like a mortgage please"
•Provider says "yes" or "no" •"What's your name"
•"John Smith"
•"What's the property address"
Service-like - the •"27 ..."
interaction is not
•etc.
dependent on the
Component-like - the •etc.
*identify* of the service
provider - i.e. the interaction is •etc.
completed application dependent on the •etc.
form can be returned to specific representative •etc.
a different branch than of the estate agent - •"... OK, your mortgage agreement
the one that provided it. i.e. the *identity* of the number is 12345, I'll post the rest of
service provider the details"
Recap: Rules for Service Oriented Architectures
Any function is implemented once and once only as a Service

Services can be runtime or deployment-time re-used
Service providers and requesters are loosely bound:
ƒEach service is defined by an implementation independent interface.
ƒServices are defined in terms of common business function and data
models.
ƒCommunication protocols that emphasise interoperability and
location transparency are used to mediate service interactions.
Value of Service Oriented Architectures

Build once, use often
ƒOne place to make one change - brings encapsulation from the Object world to the
Enterprise world
ƒLower development, operations and maintenance costs
Interface by contract
ƒLoosely couples requestor and provider so each can vary independently
ƒIntegration is explicitly defined and so better understood, at the application and
Enterprise level
Few, large-grained interactions, each commonly agreed
ƒAgain promotes looser coupling as small-grained state and process models are
independent
ƒSimplified, agreed, defined data and process flows - again, at the application and
Enterprise level
ƒLess variation and complexity to manage
ƒEasier to change large-grained processes if individual steps are well defined and
contain less complexity
Implications of Service Oriented Architectures
Note that there's nothing to do with specific technologies here

ƒSome technologies may help (e.g. CORBA provides interface
definitions)
ƒBut providing you implement these principles, anything will do -
particularly technologies that emphasise location independence and
interoperability, e.g. asynchronous messaging
And note the implication for business processes:
ƒThere is a strong synergy between Service Oriented Architecture and
consistency of business processes across the enterprise
ƒFull scale implementation will involve process re-engineering
ƒIt is important that this simplifies and streamlines business practises,
rather than removing any unique value or discriminator
Which problems do Service Oriented Architectures solve?

You have a multitude of technologies and platforms supporting your business
systems
Business process models are a mixture of people practises, application
code and interactions between people and systems or systems and
systems
Changes to one system tend to imply ripples of change at many levels
to many other systems
No single, fully functional integration solution will talk to them all
Deployment of any single, proprietary integration solution across the
enterprise is complex, costly and time consuming
Assuming you get past that, will your integration solution talk to your
partners'? Your future partners'?
No single data / business / process model across (or beyond) the
enterprise
Not all integration technologies work as well across a wide area network or
the internet as they do across a local area network
ƒExotic protocols
ƒNetwork bandwidth
We've answered some important and difficult points, but much remains
Let's see what Web Services brings to the party
The basics of Web Services – not that diagram again!

Directory / Namespace
Service Provider Service

ƒprovides e-business services Directory
ƒpublishes availability of these services through a registry
Service Directory 1. WSDL
2. Find
ƒprovides support for publishing and locating services UDDI Publish
ƒlike telephone yellow pages
Service Requestor
Service 3. Use
ƒlocates required services via the Service Broker Service
Requesto
ƒbinds to services via Service Provider Provider
r SOAP
Client Server
http://mygateway.com/services/createOrder
But so what? Why isn't <order>
<id>1234</id>
this just client/server? <customer id>AB35</customer id>
<line>
<item>
<part no>127.87A</part no>
<quantity>2</quantity>
Web Services Best Practices ... © 2003 IBM Corporation
Why Web Services is a revolution for integration inside and

outside the enterprise
The Web revolutionized the way people talk to systems:
ƒCustomers: new business models, extension of opportunity
ƒEmployees: new transparency, improved collaboration
ƒOperators: dramatic reduction in infrastructure costs and complexity
The key was a universal server-to-client model based on simple open

standards and industry support
Web Services promises to do the same thing for the way systems talk to
systems:
ƒIntegrate one business directly with another - don't wait for the people
ƒGet your own business talking to itself - joined up IT
ƒDramatic reduction in infrastructure costs and complexity
The key will be a universal program-to-program communication model based on

simple open standards and industry support
The core Web Services technologies
WSDL - Web Services Description Language

ƒXML-based interface definition language
ƒSeparate function from implementation - design by contract
SOAP - Simple Object Access Protocol / Service Oriented Architecture

Protocol
ƒAn XML messaging protocol that works over any transport
protocol - HTTP, SNMP, JMS / MQ, FTP etc.
UDDI - Universal Description, Discovery, Integration

ƒUDDI servers act as a directory of available services and service
providers
ƒSOAP can be used to query UDDI for WSDL definitions of services
Unified namespace based on URL technology

ƒNot dependent on proprietary routing and naming services
What's new? - We have got it right this time

A namespace, communication protocol and interface definition language based on
simple, existing, open standards
ƒTCP/IP, HTTP, XML, ...
ƒAvailable everywhere - don't need a monolithic integration solution - work with the Internet,
routers, load balancing, firewalls, web servers, ...
ƒAvailable already - most systems support basic TCP/IP, HTML, XML already, and many
support Web Services already
Broad industry support

ƒWeb Services Interoperability Group Founders: Accenture, BEA Systems Inc., Fujitsu Ltd.,
Hewlett-Packard Co., IBM Corp., Intel Corp., Microsoft Corp., Oracle Corp. and SAP AG
ƒMany members
We have learnt from the past

ƒLoose coupling - from EAI technologies
ƒIntegration by contract, implementation by whatever - from CORBA, OO
ƒKeep it simple, stupid - from the Web
ƒWork together on it - from J2EE, HTTP, HTML etc.
e-business is driving the merging of Web, IT & Object technologies to form the
foundation for Web Services
Web Services isn't just XML over HTTP ...

SOAP allows XML over any protocol
Different protocols have different qualities of service
Examples
ƒWS-ReliableMessaging - standard in development, preview of IBM's related HTTPR available
now
ƒSOAP over asynchronous messaging (MQSeries, JMS) available now
Gartner:
ƒBy 2004, more than 25 percent of all standard Web services traffic will be asynchronous,
using SMTP, FTP or message-oriented middleware for the transport (0.7 probability).
ƒBy 2006, more than 40 percent of the standard Web services traffic will be asynchronous (0.7
probability).
The reality of "loosely coupled" - we don't need connectivity to all the systems in a
transaction, all of the time
WS-ReliableMessaging
Send HTTP HTTP HTTP Receive

Client Server
Message Message
Tracking Tracking
Which of our problems do Web Services solve?

You have a multitude of technologies and platforms supporting your business
systems
Business process models are a mixture of people practises, application code and
interactions between people and systems or systems and systems
Changes to one system tend to imply ripples of change at many levels to many other
systems
No single, fully functional integration solution will talk to them all
Deployment of any single, proprietary integration solution across the enterprise
is complex, costly and time consuming
Assuming you get past that, will your integration solution talk to your partners'?
Your future partners'?
No single data / business / process model across (or beyond) the enterprise
Not all integration technologies work as well across a wide area network or the
internet as they do across a local area network
ƒExotic protocols
ƒNetwork bandwidth
Again, we've answered some important and difficult points, but much remains
Let's take a look at Web Services and Service Oriented Architectures combined ...
Web Service Oriented Architectures

(WS) You have a multitude of technologies and platforms supporting your
business systems
(SOA) Business process models are a mixture of people practises, application
code and interactions between people and systems or systems and systems
(SOA) Changes to one system tend to imply ripples of change at many levels
to many other systems
(WS) No single, fully functional integration solution will talk to them all
(WS) Deployment of any single, proprietary integration solution across the
enterprise is complex, costly and time consuming
(WS) Assuming you get past that, will your integration solution talk to your
partners'? Your future partners'?
(SOA) No single data / business / process model across (or beyond) the
enterprise
(WS) Not all integration technologies work as well across a wide area network
or the internet as they do across a local area network
ƒExotic protocols
ƒNetwork bandwidth
Bingo!
But ... Web Services are an immature technology. Are they up to this?
IBM's View of Web Services

A Web Services is described by WSDL New!
ƒnot limited to SOAP

ƒmultiple protocols New!
ƒboth synchronous and asynchronous New!
ƒboth RPC and document oriented

Evolutionary
ƒadd web service to your existing designs
ƒdoes not require a radical redesign
ƒWeb Services will not supplant other distributed technologies, it will supplement them
You have to start with a good, standard J2EE design
ƒProper layer design and layer placement is critical to success
ƒIf you are already doing XML, then Web Services provide a lot of benefit for little cost
ƒIf not doing XML currently, then you must plan for the overhead it introduces
Standards, Standards, Standards
ƒInteroperability is key
ƒUse open source and commercial tools wisely and adhere to standards
WebSphere Studio makes this easy…
So maybe everything is a Web Service…
And XML is the cargo between layers
Can you get too much of a good thing?
Scenario: Do NOT use XML/SOAP over HTTP between Layers

Backend
Presentation Systems
Tier Business Logic
Tier DB
WebSphere Application Server
Data
Model
Components
Managers
Session Data XML
SOAP Apache
ASP over EJB Java Xalan
HTTP SOAP Xerces
(app objects XSLT parser
WS KBML
control Xerces
Interface
IIS logic) parser
KBML
Open
Source Bad: XML/WS
between application
Domain layers with J2EE
Object server -
Good: WS for Model completely
Interoperability unnecessary
Lessons:
Do NOT use XML/Web Services where they are not needed
ƒno external interfaces being exposed
ƒXML not being flowed through the system
XML/Web Services parsing takes time and generates garbage - it is not free
Good place for Web Services is on the 'edge' of the application server
ƒpreferred strategy for interoperability situations
Do NOT use WS for Fine-Grained Interactions

Presentation Business
Layer Layer
Java Application WebSphere

Application Server
Swing
(view/controller) Apache SOAP
Bad: Fine-
grained
Web Service
WS calls.
Generated SOAP
stub SOAP
over EJB
HTTP
(controller/model)
Apache SOAP
Do NOT use SOAP over HTTP between Java

Application Servers
Presentation Business
Layer Layer
WebSphere WebSphere
Browser Application Server Application Server
JSPs SOAP Engine

Bad: Using WS
between WAS
application Web Service
servers (no Generated
firewall issues) SOAP stub SOAP
over EJB
HTTP
SOAP Engine
Where to Use Web Services

Interoperability between heterogeneous systems
Defer the choice of Transport
ƒAsynchronous messaging (MQ, SMTP)
ƒSynchronous (HTTP, RMI/IIOP, local)
Get through firewalls
To expose a common, language neutral interface and hide implementation details
Minimize impact of changes in one system effecting other systems
Service Oriented Architectures
Balancing J2EE protocols
If the application server may have Java as a service requester, have that
Java application make an RMI/IIOP call to an EJB instead of using SOAP
over HTTP.
Support both RMI/IIOP and web services interfaces
ƒSupport SOAP over MQ for asynchronous requests
Non-Java clients Java clients, Servlets/EJBs in JMS-enabled clients

other JVMs
SOAP/HTTP RMI-IIOP XML/JMS
JAX-RPC Service
Remote EJB IF MDB
IF
Java Servlets, EJBs

EJB Impl Local EJB IF
in the same JVM
Choose the Protocol based on the Requirements
Sync Async Broadcast Queued Reliable Open

(Latency) Delivery Standard
Message X X X X * (JMS – Jav

Queue only)
HTTP X X
SMTP X X X X
RMI-IIOP X X X*
Architecture for Firewall Challenges

Requirement was for a 'rich' client experience over the Internet and Intranet
ƒMost outside the firewall (using Network Address Translation)
ƒFirst attempt was to engineer a fully HTML-based solution
ƒDecided on an Applet client
ƒHowever the presence of multiple firewalls between client and server made the use of RMI/IIOP impossible
ƒSo, the client introduced a Web Services interface for their existing EJBs to allow client communication over HTTP and
SOAP
WebSphere Application
Applet
Application Server Client
Generated
EJB Client
SOAP stub
SOAP-HTTP
SOAP Engine
SOAP Engine RMI/IIOP
EJB
Firewall
When to use Web Services for Firewall Challenges

Client had to overcome skepticism about the maturity of the technology from both
outside consultants and internal I/T management
Web Services was the right choice even though Java ran on both ends of the
conversation
ƒOvercame limitations of RMI/IIOP with NAT firewalls
ƒSimple and easy to implement over existing EJBs
Large requests/data being sent
Although the Application client was 'snappier' than SOAP over HTTP, the Applet
had acceptable performance
The same architecture has been put in place in other customers as well
ƒWebSphere's EJB clients have a strong JDK dependency; using Web Services as a
communication mechanism allows more flexibility on the client end
Interoperability
.NET SOAP SOAP .NET

Requestor HTTP SOAP Service
HTTP
(provider)
WebSphere
Apache SOAP SOAP Service
Requestor SOAP
(provider to WebSphere
incoming requests JMS SOAP Service
WebSphere (provider)
Requestor requestor
sending requests)
SOAP
SOAP lite SOAP lite
Requestor
HTTP
SOAP Service
(provider)
Choosing the Granularity in SOA

Unified Logical View
ƒAn extension of the Facade pattern -- encapsulation of technology-specific details
Replaceable Component
ƒisolating requestors from change in the implementation
Composable component
ƒSo that you can create business process with the elements (BPEL4WS)
WSDL
WSDL
WSDL
Coordinator
Unified Logical View

WebSphere Application Server (WAS)
Facade Employee Service Implementation

Mainframe
CICS and
CICS CICS Java
JCA Gateway
Adapter
JAX- Business
Empl. logic
RPC
SOAP Service JDBC
Empl JDBC
Engine Session Adapter
DB2
Svc. (decides which

EJB backends to call
IF and merges data)
custom code 3rd

party
system
Replaceable Component
In one insurance application, the broker obtains policy quotes from several different
systems
Think of this as a large-scale application of the Strategy pattern
getQuote Insurer A
Broker Insurer A
Adapter
Insurer B Insurer
Adapter B
Internal
UDDI Insurer C
Registry Adapter
Insurer C
Insurer X
Adapter
Adapter WSDL
Design Best Practices

Web Services should be coarse-grained interfaces
Web Services should be stateless
ƒEven though it's possible to use transport state mechanisms they should be avoided
The fastest web service call is NO web service call
ƒCache Data on the requestor when reasonable
ƒMinimize the number of requests for the same information
ƒlogically group information into larger-grain requests when possible
Consider asynchronous messaging instead of synchronous RPC-style interaction
ƒasynchronous is a more loosely coupled interaction model
Business Stateless
Delegate Web Services Stateless
Stateless
Web
Proxy Web
Web
Service
Service
Service
Load
Client cache Balancer
Use Session EJBs for multiple protocols

In nearly all synchronous request/response cases, a stateless Session EJB should
be the preferred vehicle
ƒThe only way to have fine-grained security
ƒWhen a client can use RMI-IIOP the performance gains are significant but local calls are the
fastest
ƒConsider the Business Delegate Pattern
Client RemoteEJBDelegate RMI -IIOP

RemoteEJBInt erface
Java call
LocalEJBDelegate LocalEJBInterface SessionEJBImpl
SOAP/HTTP
WebServiceDelegate ServiceEndpointInterface
DelegateFactory
Delegate
<<interface>>
Performance - Approach
Do not get hung up on performance concerns until you know the 'cost' of the
web service
ƒoften the business processing takes more time than the Web Service processing
Be smart about designing your application
ƒcache data
ƒsend references
ƒsend the amount of data needed
ƒsupport multiple protocols (don't only use SOAP over HTTP)
Create a prototype and test it under load
Use the fastest SOAP Engine you are comfortable with
Use the fastest XML Parser available
ƒKeep your eye on the latest Apache releases
Specific Performance Results

Smaller messages are better
Fewer elements are better (less of an impact significant)
simple is better than complex messages
ƒavoid complex business objects
ƒVector of 256 Complex Objects
–256 * 4 * 100 = 100K – 13600 Elements or Tags
As messages get larger and more complex, the parsing time becomes a larger % of
the processing time
Use SAX instead of DOM for de-serializing XML into objects when you write custom
deserializers.
Code Practices
ƒFor transferred objects being created from XML
–Don’t initialize variables
–Don’t set values in the Default Constructor
–The values will be reset from XML
Resources
Tutorials, articles, technologies

WebSphere Developer Domain http://www7b.software.ibm.com/wsdd
ƒDeveloper Works Web Services http://www.ibm.com/developerworks/webservices
Web Services Interoperability organisation
ƒhttp://www.ws-i.org/
OASIS open standards organisation (ebXML etc.)
ƒhttp://www.oasis-open.org/
Specifications:
ƒBusiness Process http://www-106.ibm.com/developerworks/library/ws-bpel/
ƒTransactions http://www-106.ibm.com/developerworks/library/ws-transpec/
ƒSecurity http://www-106.ibm.com/developerworks/webservices/library/ws-secure/
ƒSOAP http://www.w3.org/TR/SOAP/
ƒWSDL http://www.w3.org/TR/wsdl
ƒUDDI http://www.uddi.org/specification.html (public directory at
https://uddi.ibm.com/ubr/registry.html)
ƒPreview Technology
ƒhttp://www.alphaworks.ibm.com/webservices

12 Web Services Best Practices

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

12 Web Services Best Practices

Uploaded by

Copyright:

Available Formats

IBM Software Services for WebSphere

Web Services Best Practices

© 2003 IBM Corporation

Web Services Best Practices © 2003 IBM Corporation

The IT-related problems facing business today

Web Services Best Practices © 2003 IBM Corporation

So, what has stopped us solving them?

Web Services Best Practices © 2003 IBM Corporation

Integration on a vast scale

Industry Finance Manufac- Dist-

Customer Enterprise Project Value

Business Integration Employees (inter- & intra-enterprise)

Web Services Best Practices © 2003 IBM Corporation

Is Web Services the answer? Sort of ...

Web Services Best Practices © 2003 IBM Corporation

And just what is a Service Oriented Architecture?

Web Services Best Practices © 2003 IBM Corporation

But, what is a service?

Web Services Best Practices © 2003 IBM Corporation

Services – Some ground rules

A service encapsulates a well-defined invokable unit of business function, and

Any dependencies between services should be defined in terms of common

Services should be invokable through defined communication protocols that

Web Services Best Practices © 2003 IBM Corporation

From what SOA “is” to “what” it does for you:

Web Services Best Practices © 2003 IBM Corporation

What's so special about these interfaces?

Web Services Best Practices © 2003 IBM Corporation

"Service" Interfaces vs. "Component" Interfaces ...

Web Services Best Practices © 2003 IBM Corporation

Recap: Rules for Service Oriented Architectures

Any function is implemented once and once only as a Service

Web Services Best Practices © 2003 IBM Corporation

Value of Service Oriented Architectures

Web Services Best Practices © 2003 IBM Corporation

Implications of Service Oriented Architectures

Note that there's nothing to do with specific technologies here

Web Services Best Practices © 2003 IBM Corporation

Which problems do Service Oriented Architectures solve?

Web Services Best Practices © 2003 IBM Corporation

The basics of Web Services – not that diagram again!

Service Provider Service

Why Web Services is a revolution for integration inside and

The key was a universal server-to-client model based on simple open

The key will be a universal program-to-program communication model based on

Web Services Best Practices © 2003 IBM Corporation

The core Web Services technologies

WSDL - Web Services Description Language

SOAP - Simple Object Access Protocol / Service Oriented Architecture

UDDI - Universal Description, Discovery, Integration

Unified namespace based on URL technology

Web Services Best Practices © 2003 IBM Corporation

What's new? - We have got it right this time

Broad industry support

We have learnt from the past

Web Services Best Practices © 2003 IBM Corporation

Web Services isn't just XML over HTTP ...

Send HTTP HTTP HTTP Receive

Web Services Best Practices © 2003 IBM Corporation

Which of our problems do Web Services solve?

Web Services Best Practices © 2003 IBM Corporation

Web Service Oriented Architectures

Web Services Best Practices © 2003 IBM Corporation

A service encapsulates a well-defined invokable unit of business function, and

Any dependencies between services should be defined in terms of common

Services should be invokable through defined communication protocols that

Any function is implemented once and once only as a Service

Note that there's nothing to do with specific technologies here

Service Provider Service

The key was a universal server-to-client model based on simple open

The key will be a universal program-to-program communication model based on

WSDL - Web Services Description Language

SOAP - Simple Object Access Protocol / Service Oriented Architecture

UDDI - Universal Description, Discovery, Integration

Unified namespace based on URL technology

Broad industry support

We have learnt from the past

And XML is the cargo between layers

Tutorials, articles, technologies