12 Web Services Best Practices

12_WebServices_BestPractices.ppt Page 1 of 44

IBM Software Services for WebSphere

© 2003 IBM Corporation

Web Services Best Practices



Web Services Best Practices © 2003 IBM Corporation

AgendaWhat are WebServices?

How do they help?What’s this “Service Oriented Architecture” Thing?

Architectural Best PracticesDesign Best PracticesInteroperability Best PracticesPerformance Best Practices




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

Business Integration (inter- & intra-enterprise)

CustomersSuppliers &Distributors

CustomerRelationshipManagement

EnterpriseResourcePlanning

ProjectLifecycle

Management

ValueChain

Management

. . .

Infrastructure

IndustrySolutions

Finance RetailDist-

ribution TelecomManufac-turing

Gov't.

Employees




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 clientsThere 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 itDeployment 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.




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.

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




What's so special about these interfaces?There are two important characteristics of interfaces within a service oriented architecture:

Interface by contractƒAn explicit interface definition or contract

is used to bind a service requestor and a service provider

ƒSpecifies explicitly only the mutual behaviour - specifies nothing about the implementation of the requestor or the provider

ƒAllows either to change implementation or identity freely

Interface granularityƒLarger grainedƒLoosely coupled

Interface Code

Interface Code

Internal code and processs

Shared process and interface definitions

CONTRACT

SYSTEM 1

SYSTEM 2

Internal code and processs




"Service" Interfaces vs. "Component" Interfaces ...Think of the difference between applying for a mortgage over the phone or by post ...By post:

•Client requests application form•Provider sends it•Client fills it in and returns it•Provider says "yes" or "no"

By phone:•Client calls provider•Provider says "Hello, how can we help"•"I'd like a mortgage please"•"What's your name"•"John Smith"•"What's the property address"•"27 ..."•etc.•etc.•etc.•etc.•etc.•"... OK, your mortgage agreement number is 12345, I'll post the rest of the details"

Service-like - the interaction is not dependent on the *identify* of the service provider - i.e. the completed application form can be returned to a different branch than the one that provided it.

Component-like - the interaction is dependent on the specific representative of the estate agent -i.e. the *identity* of the service provider




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.




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

Value of Service Oriented Architectures




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 systemsBusiness process models are a mixture of people practises, application code and interactions between people and systems or systems and systemsChanges to one system tend to imply ripples of change at many levels to many other systemsNo single, fully functional integration solution will talk to them allDeployment of any single, proprietary integration solution across the enterprise is complex, costly and time consumingAssuming you get past that, will your integration solution talk to your partners'? Your future partners'?No single data / business / process model across (or beyond) theenterpriseNot 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

We've answered some important and difficult points, but much remainsLet's see what Web Services brings to the party




Service Providerƒprovides e-business servicesƒpublishes availability of these services through a registry

Service Directoryƒprovides support for publishing and locating servicesƒlike telephone yellow pages

Service Requestorƒlocates required services via the Service Brokerƒbinds to services via Service Provider

The basics of Web Services – not that diagram again!

Service Provider

Service Requesto

r

Service Directory

1. Publish

2. Find

3. Use

SOAP

WSDLUDDI

http://mygateway.com/services/createOrder<order>

<id>1234</id><customer id>AB35</customer id><line>

<item><part no>127.87A</part no><quantity>2</quantity>...

Client Server

Directory / Namespace

But so what? Why isn't this just client/server?




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 timeA 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 protocolDifferent protocols have different qualities of serviceExamples

ƒWS-ReliableMessaging - standard in development, preview of IBM's related HTTPR available now

ƒSOAP over asynchronous messaging (MQSeries, JMS) available nowGartner:

ƒ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

Send

Message Tracking

HTTP Client

HTTP Server

Receive

Message Tracking

HTTP

WS-ReliableMessaging




Which of our problems do Web Services solve?You have a multitude of technologies and platforms supporting your business systemsBusiness process models are a mixture of people practises, application code and interactions between people and systems or systems and systemsChanges to one system tend to imply ripples of change at many levels to many other systemsNo single, fully functional integration solution will talk to them allDeployment of any single, proprietary integration solution across the enterprise is complex, costly and time consumingAssuming 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 enterpriseNot all integration technologies work as well across a wide area network or the internet as they do across a local area network


Again, we've answered some important and difficult points, but much remainsLet'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


Bingo!But ... Web Services are an immature technology. Are they up to this?




IBM's View of Web ServicesA Web Services is described by WSDLƒnot limited to SOAPƒmultiple protocolsƒboth synchronous and asynchronousƒ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

New!

New!

New!




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

DomainObjectModel

IIS

SessionEJB(app

controllogic)

ASPSOAPoverHTTP

WebSphere Application Server

Presentation Tier Business Logic

Tier

ApacheSOAPWS

Interface

Model Managers

BackendSystems

Data XML

XalanXSLT

Xercesparser

DataComponents

DB

Xercesparser

KBML

KBMLOpen

Source

Javaobjects

Good: WS forInteroperability

Bad: XML/WS between application layers with J2EE server -completelyunnecessary




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

Apache SOAP

Generated SOAP stub

EJB(controller/model)

Swing(view/controller)

Java Application

SOAPoverHTTP

WebSphereApplication Server

Presentation Layer

BusinessLayer

Apache SOAP

Web Service

Bad: Fine-grainedWS calls.




Do NOT use SOAP over HTTP between Java Application Servers

Browser

SOAP Engine

Generated SOAP stub

EJB

JSPs


SOAPoverHTTP


Presentation Layer

BusinessLayer

SOAP Engine

Web Service

Bad: Using WS between WAS application servers (no firewall issues)




Where to Use Web ServicesInteroperability between heterogeneous systemsDefer 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 systemsService 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

Remote EJB IFJAX-RPC Service IF MDB

Local EJB IFEJB Impl

Java clients, Servlets/EJBs in other JVMs

Non-Java clients JMS-enabled clients

Servlets, EJBsin the same JVM

RMI-IIOPSOAP/HTTP XML/JMS

Java




Sync Async Broadcast Queued (Latency)

Reliable Delivery

Open Standard

Message Queue

X X X X * (JMS – Javonly)

HTTP X X

SMTP X X X X

RMI-IIOP X X X*

Choose the Protocol based on the Requirements




Architecture for Firewall Challenges

Applet

SOAP Engine

Generated SOAP stub

Application Client

EJB Client

SOAP Engine

EJB

Firewall


RMI/IIOPSOAP-HTTP

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




When to use Web Services for Firewall ChallengesClient had to overcome skepticism about the maturity of the technology from both outside consultants and internal I/T managementWeb 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 sentAlthough 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

.NETRequestor

Apache SOAPRequestor

WebSphereRequestor

SOAP liteRequestor

WebSphereSOAP Service

(provider to incoming requests

requestorsending requests)

.NETSOAP Service

(provider)

WebSphereSOAP Service

(provider)

SOAP liteSOAP Service

(provider)

SOAPHTTP

SOAPHTTP

SOAPJMS

SOAPHTTP




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)

Choosing the Granularity in SOA

WSDL

WSDL

WSDL

Coordinator




Unified Logical ViewWebSphere Application Server (WAS)

DB2DB2

Mainframe

CICS and

CICS Java

Gateway

Employee Service Implementation

JCACICS

Adapter

JDBCJDBC

Adapter

3rdparty

system

custom code

Businesslogic

(decides which backends to call

and merges data)

Empl.ServiceSession

EJB

JAX-RPCEmplSvc.IF

SOAPEngine

Facade




Replaceable ComponentIn one insurance application, the broker obtains policy quotes from several different systemsThink of this as a large-scale application of the Strategy pattern

Insurer AAdapter

Insurer BAdapter

Insurer CAdapter

BrokergetQuote Insurer A

Insurer B

Insurer C

Insurer XAdapter

Adapter WSDL

InternalUDDI

Registry




Design Best PracticesWeb Services should be coarse-grained interfacesWeb 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

Client cache

Business Delegate Web Services

Proxy

Load Balancer

Stateless Web

Service

Stateless Web

Service

Stateless Web

Service




Use Session EJBs for multiple protocolsIn 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

DelegateFactory

RemoteEJBDelegate

LocalEJBDelegate

WebServiceDelegate

RemoteEJBInt erface

LocalEJBInterface

ServiceEndpointInterface

SessionEJBImpl

RMI -IIOP

Java call

SOAP/HTTP

Delegate<<interface>>




Performance - ApproachDo 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 loadUse the fastest SOAP Engine you are comfortable withUse the fastest XML Parser availableƒKeep your eye on the latest Apache releases




Specific Performance ResultsSmaller 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 TagsAs messages get larger and more complex, the parsing time becomes a larger % of the processing timeUse 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, technologiesWebSphere Developer Domain http://www7b.software.ibm.com/wsdd

ƒDeveloper Works Web Services http://www.ibm.com/developerworks/webservicesWeb 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

Documents