s soa design patterns and bes

8/8/2019 S Soa Design Patterns and Bes

http://slidepdf.com/reader/full/s-soa-design-patterns-and-bes 1/56

© 2005 IBMCorporation.

ibm.com/developerworks/webservices

SOA design patterns andSOA design patterns and

best practicesbest practices

私の名前は、 Doug Tidwellです。

SOAのセミナーにお申込いただき、ありがとうございます。



2


© 2005 IBM Corporation.

About this presentationAbout this presentation

• Much of this presentation was created byRachel Reinitz and Kyle Brown, both of whomare practicing consultants in IBM’s SoftwareServices for WebSphere team.

– A big thanks to Rachel and Kyle for sharingtheir experience and expertise.

• This material comes from their directexperience with customers and from theexperience of their teammates.



3



A great book A great book

• Written by KyleBrown and otherIBM experts

• Based on real-

world experiencesolving customerproblems.

• ISBN 032118579X



4



Another great book Another great book

• Written by IBMersfrom Germany andthe UK, it's alsobased on real-world

experiences.• Discusses Web

services from theperspective of a

developer, tester,and so forth.

• ISBN 3540009140



5



Distributed systemsDistributed systems

challengeschallenges• Performance• Scalability

• Management

• Granularity• Protocol

conversions

• Network

bandwidth

• Failover

• Achieving loosecoupling

• Versioning

• Security

• Maintainingcontext (sessionstate,transactions)

• Development, test,& integration costs

None of these are specific to Web

services.



6



IBM’s view of Web servicesIBM’s view of Web services

• A Web service is described byWSDL

– Doesn’t have to use SOAP or HTTP,can be synchronous or asynchronous,can be RPC- or document-style

• Doesn’t require a radical redesignof your existing architecture

– Web services complement otherdistributed technologies, they don’treplace them.





IBM’s view of Web servicesIBM’s view of Web services

• Start with good distributed designprinciples, especially layer designand layer placement

• Enable your legacy systems forSOAs

• Standards, standards, standards

– Interoperability is crucial, so makesure your tools adhere tostandards.





Web services anti-Web services anti-

patternspatterns





WS for integrationWS for integration

• Don’t use SOAP over HTTP or XMLbetween layers of an application:

• Do use them at the edge.

WebSphereApplicationServer

Modelmanagers

Data AccessObjects

Domainobjects

DB

Session

EJB

SOAP

engine

ASP

IIS

Result setconverted

to XML

XML

converted todomain XML

format

XML convertedto domain

objects





Object granularityObject granularity

• An Employee JavaBean would havea number of properties, along

with get and set methods for eachone.

• Don’t use thesemethods with adistributedEmployee object!





GranularityGranularity

• If you want to get the completeemployee record, that’s five Webservices calls:

• On the other hand, you can do thiswith one call if you create agetEmployeeRecord() method.

Client ServicegetEmployeeSerial()getFirstName()getLastName()getOfficePhone()getOfficeLocation()





LessonsLessons

• Don’t use SOAP over HTTP or XML just because they’re new and cool.

– SOAP over HTTP and XML work bestfor integration – use them at the edgeof the application server

• Fine-grained distributed objectsare never a good idea, whether

you’re using Web services, CORBA,EJBs, DCOM, RMI, etc.





Web services scenariosWeb services scenarios



14



Business valueBusiness value

• Assuming you don’t have unlimitedIT budgets, you’ll need to showbusiness value to get approval fora Web services project.

– Focus on business needs first,technology second.

• The most common business needaddressed by Web services isintegration.



15



Business valueBusiness value

• When architecting a Web servicessystem, some key considerationsare:

–Ensuring that Web services work wellwith your existing systems

– Quality of service (QoS) requirements

– Enterprise architecture directions

– Cost



16



Managing interoperabilityManaging interoperability

• You can get significant businessvalue from a point-to-point Webservice:

Java client Java service

J2EE application

Packaged apps

B2B service

COBOL systemBut what happenswhen you havemultiple services?



17



Managing interoperabilityManaging interoperability

• With multiple clients and services,complexity becomes a big issue…

– …we need something to simplify this.


.NET client J2EE application

Packaged apps

B2B service

COBOL system

COBOL client

Perl client

Python client



18



The ESBThe ESB

• IBM’s vision is for the EnterpriseService Bus to handle messagerouting between Web services.

EnterpriseService

Bus


J2EE application

Packaged apps

B2B service

COBOL system

.NET client

COBOL client

Perl client

Python client

/ /



19



The ESBThe ESB

• With the ESB, the requestor’s job isto build a request according to theservice’s WSDL.

– Remember, this might use somethingother than SOAP, something otherthan HTTP, and so forth.

• The ESB’s job is to figure out how

to get the request to the service,then get the response to therequestor.

/ /



20



A customer scenarioA customer scenario

• Our first scenario involves afinancial company focused ononline trading.

• Lots of critical business logic wasin mainframe CICS transactionsand DB2 stored procedures.

• The presentation layer was built onhigh-performance, complex Webfront ends that changed often.

ib /d l k / b i



21



Old architectureOld architecture

SNA

SOAP engineCICS

SOAP engineCICSCICS

Customprotocol

Applicationservers (100’s)

Translator(10’s)

• The bottleneck was the translators in themiddle. The company wanted to eliminatethem if possible.

• As you’d expect, they needed loadbalancing, failover, and security.

ib /d l k / b i



22



The solution: Adding anThe solution: Adding an

ESBESB

SOAP overHTTP or JMS

SOAP engineCICS

SOAP engineCICS

SOAP engineCICS

SOAP overHTTP or JMS

Applicationservers

(SOAP clients)

WS Gateway(WAS V5.x ND)

• The customer eliminated thetranslation servers by using

standard protocols.• Data translation and the SOAP

engine are now on the mainframe.

ib /d l k / b i



23



ESB with the WAS WSESB with the WAS WS

GatewayGateway• The customer used IBM developmenttools to wrap the transactions andstored procedures as Web services.

• Protocol translation (for SOAP over

JMS), standard security, metering,and load balancing between the appservers and the mainframe werehandled by the WS Gateway.

• Hardware costs and developmenttime were reduced.

ib /d l k / b i



24



B2B message exchangeB2B message exchange

• In many simple B2B scenarios,Web services can replace costlyEDI infrastructures. In a casestudy from the railroad industry:

– Handling security was the biggestobstacle.

– The railroad industry has defined

standards for data interchange. Those were originally used for EDI,but work for Web services also.

ibm com/de eloper orks/ ebser ices



25



B2B message exchangeB2B message exchange

• Our railroad case study:– Needed a peer-to-peer topology for

security reasons

– Used XML to XML transforms (onecharacteristic of an ESB)

WAS WAS

Railroadapplication

Internet +WS-Security

Webservice InventoryserviceWebservice

Railroad Railroad

Authentication,privacy,

integrity, non-

repudiation

Integration of J2EE, .NET,

legacy

ibm com/developerworks/webservices



26



Web Services for RemoteWeb Services for Remote

PortletsPortlets• You can use portalsto give users acommon front end tomultiple

applications.• WSRP lets you use

Web services toaccess remoteportlets, and givesyou a single point of authentication.

Portalserver

LocalPortlet

LocalPortlet

WSRPservice

WSRPservice

WSRPservice

WSRPservice

WSRPservice

LocalPortlet Local

Portlet




27



Designing interfacesDesigning interfaces

Service interface:1. Client requests a

form

2. Provider sends

the form

3. Client fills in andreturns form

4. Provider says“yes” or “no.”

API interface:1. Client calls

provider

2. “Can I help you?”

3. “I’d like amortgage”

4. “Your name?”

5. “John Smith”6. “Address?”

20-30 steps follow…Design your serviceslike forms, notconversations.




28



SOA design patternsSOA design patterns

• There are four approaches:– Unified logical view (façade

pattern)

– Adapters for legacy code

– Composable components (getready for BPEL)

– Replaceable components (change

the implementation, clients still work)

• Again, business requirements are the driving factor.




29



WAS Employee service implementation

Façade

Unified logical viewsUnified logical views

• If possible, don’t expose legacyinterfaces and transactions – usethe façade pattern instead.

SOAP

engine

JAX-RPCEmployee

SEI

Employeeservice

sessionEJB

Business

logic

CICSmapper

JCA

JDBC

mapper

Custom code

JDBC DB2

CICSapps

Othersystems




30



Adapters for legacyAdapters for legacy

interfacesinterfaces• It’s not always possible to use afaçade. Use the adapter pattern to expose individual back-ends.

Bank branch.NET client

WebSphere CICS apps

Everydaybanking

Customer

info

Mutualfunds

Adapter service

Adapter service

Adapter service

Call center

Java client

InternetWAS/Linux




31



Composable componentsComposable components

• To use a language like BPEL, you’llprobably need more complicatedWeb service interfaces.

Choreography (BPEL)

WSDL

StatelessWeb service

Activity 1 Activity 2 Activity 3

WSDL


WSDL


Sharedstateand

context

Public

Private

Individualtransactio

ns




32




• The patterns we’ve looked at so fartend to be used in three layers:

– Business processes – Manage tasksthat users would recognize. Will be

managed with BPEL, in IBM’s view…

– Business transactions – A “singlebusiness state change,” typically a

stateless session bean– Function services – Web services

access to core business functions




33




Business Process

Function Services

Member Requests anRx Refill (Call CenterIVR or Online)

RequestDenied

Rx DeptProcessesRefillPC Physician

Approves orDeniesRequest (WSor Email)

Member Informedthat Refill is Ready

Validate Memberis Authorized toMake Request

Determine Member’sCoverages and PrimaryCare Physician

Send RequestNotification topharmacy

Send RequestNotification to Notes

PatientRecords

Business Transaction

Member Informed thatRequest has beenDenied

RequestApproved

WSEnabled

Not WSEnabled

CreditVerificatio

n

OfficeScheduling

EmailSystem

Authorization Service Email Service

Outpatient Service

Masters Service

HR

- long running- one or more persons interacting- multiple valid BP states- alternative workflows for non-normal conds

- short term, non-interactive- one change of business state orSTP- consumes one or more ent. svcs.- targeted level of service reuse- loose coupling very important

- may require compensating xactns

- collaborations to implement asingleWeb service

- collaborating apps encapsulatedviaWeb services

- performance more important thanloose coupling




34



getQuote()

Replaceable componentsReplaceable components

• If multiple services standardize ona single interface, you can replaceone service with another.

Insurancebroker

PrivateUDDI

registry

Insurer Aadapter

Insurer Badapter

Insurer Cadapter

Insurer Xadapter

WSDLInterface forgetQuote()

Insurer C

Insurer A

Insurer B

Insurer X




35



Where to use Web servicesWhere to use Web services•

In SOA/ESBarchitectures

• Integratingheterogeneous

systems• B2B applications

• Adding flexibilityto business(WSRP,replaceablecomponents)

• Exposing legacyapplications

• Unified view andbusiness logic

• Hiding details of animplementation

• Loose coupling –defer the choice of

transport and/orservice untilruntime




36



Choosing a protocolChoosing a protocol

Message

queueing

HTTP

SMTP

RMI/IIOP

S yn c

A s yn c

Br o a d c a

st

Q u e u e d

(

l at en c y )

R el i a b l e

d el i v er y

O p en

s

t an d ar d

?

JMSonly




37



Balancing J2EE protocolsBalancing J2EE protocols

• You can add a Web serviceinterface to an EJB, but don’tremove the other interfaces.

JAX-RPC

SEI

Remote EJB

interface

Message-

driven bean

EJBimplementation

Local EJBinterface

Non-Javaclients

(SOAP/HTTP)

Java clients

in other JVMs(RMI-IIOP)

JMS-enabled

clients(XML/JMS)

Java clientsin the

same JVM




38

/ p /


Between Java applicationBetween Java application

serversservers• When considering performancebetween SOAP/HTTP and RMI-IIOP:

– RMI-IIOP gives the best performance(for now)…

– …but test SOAP/HTTP first

– For complex types, SOAP/HTTP’sperformance is approaching RMI-

IIOP’s.




39

/ p /



serversservers• Security considerations:– The security context is maintained

with little cost over RMI-IIOP

– HTTPS gets through firewalls muchmore easily than IIOP

– HTTPS has limitations for anythingbeyond point-to-point

– WS-Security bridges from SOAP toEJBs, but the performance cost is highand interoperability isn’t perfect yet.




40

/ p /



serversservers• Looking at transactional context:– RMI-IIOP maintains transactional

context

– WS-Transaction has been proposed,but isn’t available yet.




41

p


Location transparencyLocation transparency

• You want your clients to beunaware of the service endpoint

– Ideally they won’t know the bindingor protocol information either.

• At runtime, the client reads theendpoint information:

– Services can register their

implementation details, including theservice endpoint, in a UDDI registry.

– Clients will likely cache the endpoint.




42

p


The delegate designThe delegate design

patternpattern• A useful technique for protocolindependence is John Crupi’sdelegate design pattern.

“The Business Delegate hidesthe implementation details of the business service, such aslookup and access

mechanisms.”- from the book Core J2EE

Patterns




43© 2005 IBM Corporation.

The delegate designThe delegate design

patternpatternClient

Delegate

factory

Remote EJBdelegate

Delegate service(interface)

Local EJBdelegate

Web servicedelegate

Remote EJBinterface

Local EJBinterface

Service endpointinterface

Session EJBimplementation





The Web Services GatewayThe Web Services Gateway

• WebSphere Application Server V6(Network Deployment edition) comeswith the Web Services Gateway.

– A client application gives the gateway

the URL of a WSDL file, the name of themethod it wants to invoke, and theparameters for that method.

– The gateway figures out how to connectto the service, invokes it, and returnsthe results to the client.





The Web Services GatewayThe Web Services Gateway

ClientWeb Svcs.Gateway

SOAPService

Local JavaService

JMSService

JCAService

CICSService

WSDL URL,methodname,method

parameters

protocol-specificdetails





SOAP headers and handlersSOAP headers and handlers

• We’ve looked at SOAP headers andthe handler architecture severaltimes today. Some design points:

– Separate header processing from theapplication logic

– No application data in headers

– Define header processing rules

declaratively in configuration files– Make any custom handlers you write

configurable





Some more words about theSome more words about the

ESBESB• The ESB should provide:

– A consistent, location-transparent andprotocol-independent way to address services

– A consistent, location-transparentmeans to mediate and route servicerequests and responses based on that

address





Some more words about theSome more words about the

ESBESB• The ESB should provide:– The ability to communicate service

requests and responses throughwhatever combination of protocols

provide connectivity betweenendpoints

– The ability to apply handlers or

intermediaries to a service or a groupof services.





ESB patternsESB patterns





Router patternsRouter patterns

• There are three different variationsof an ESB:

– Router

– Broker

– Exposed gateway





Router ESBRouter ESB

• With a router ESB, the bus sendsa given request to a particularservice.

– This is the simplest case of an ESB.

– The bus merely replaces the directinvocation of a particular service.





Broker ESBBroker ESB

• With a broker ESB, the bus hasrules that determine which serviceto invoke.

– If you used the ESB to invoke aservice five times, the broker ESBmight route those requests to fivedifferent services.





Exposed gateway ESBExposed gateway ESB

• With the exposed gateway ESB,there is an external gateway infront of the ESB.

– External clients send requests to thegateway, which in turn brokers thoserequests to various services.




SummarySummary

• We've looked at a number of bestpractices here.

– Some of them apply to any type of distributed system. An SOA still has

to deal with security, authenticationand all the other common problems.

– We also looked at design patterns for

SOAs. As you implement thisarchitecture, these patterns will makethe transition easier.





ありがとうございまし

た。

またお会いしましょ

う！developerWorksのWebSiteをご覧

ください !

s soa design patterns and bes

Documents