SOA design patterns and best practices

私の名前は、 Doug Tidwell です。 SOA のセミナーにお申込いただき、ありがとう ございます。
© 2005 IBM Corporation.

ibm.com/developerworks/webservices

ibm.com/developerworks/webservices

About this presentation
• Much of this presentation was created by Rachel Reinitz and Kyle Brown, both of whom are practicing consultants in IBM’s Software Services for WebSphere team.
– A big thanks to Rachel and Kyle for sharing their experience and expertise.

• This material comes from their direct experience with customers and from the experience of their teammates.

© 2005 IBM Corporation.

2

ibm.com/developerworks/webservices

A great book
• Written by Kyle Brown and other IBM experts • Based on realworld experience solving customer problems. • ISBN 032118579X

© 2005 IBM Corporation.

3

ibm.com/developerworks/webservices

Another great book
• Written by IBMers from Germany and the UK, it's also based on real-world experiences. • Discusses Web services from the perspective of a developer, tester, and so forth. • ISBN 3540009140
© 2005 IBM Corporation. 4

ibm.com/developerworks/webservices

Distributed systems • Achieving loose • Performance challenges
• • • • Scalability Management Granularity Protocol conversions • Network bandwidth • Failover
• • •

coupling Versioning Security Maintaining context (session state, transactions) Development, test, & integration costs
5

© 2005 IBM Corporation.

None of these are specific to Web services.

can be synchronous or asynchronous. they don’t replace them.ibm.or document-style • Doesn’t require a radical redesign of your existing architecture – Web services complement other distributed technologies. 6 .com/developerworks/webservices IBM’s view of Web services • A Web service is described by WSDL – Doesn’t have to use SOAP or HTTP. can be RPC. © 2005 IBM Corporation.

standards. especially layer design and layer placement • Enable your legacy systems for SOAs • Standards. standards – Interoperability is crucial. so make sure your tools adhere to standards.com/developerworks/webservices IBM’s view of Web services • Start with good distributed design principles. 7 . © 2005 IBM Corporation.ibm.

ibm.Web services antipatterns © 2005 IBM Corporation.com/developerworks/webservices .

Result set converted to XML WebSphere Application Server SOAP engine Session EJB Model managers Data Access Objects ASP IIS XML converted to domain XML format Domain XML converted objects to domain objects 9 © 2005 IBM Corporation.ibm.com/developerworks/webservices WS for integration • Don’t use SOAP over HTTP or XML between layers of an application: DB • Do use them at the edge. .

ibm.com/developerworks/webservices Object granularity • An Employee Java Bean would have a number of properties. along with get and set methods for each one. 10 . • Don’t use these methods with a distributed Employee object! © 2005 IBM Corporation.

ibm.com/developerworks/webservices Granularity • If you want to get the complete employee record. that’s five Web services calls: Client getOfficeLocation() getEmployeeSerial() getOfficePhone() getFirstName() getLastName() Service • On the other hand. you can do this with one call if you create a getEmployeeRecord() method. 11 . © 2005 IBM Corporation.

CORBA. © 2005 IBM Corporation.ibm.com/developerworks/webservices Lessons • Don’t use SOAP over HTTP or XML just because they’re new and cool. RMI. 12 . EJBs. whether you’re using Web services. etc. – SOAP over HTTP and XML work best for integration – use them at the edge of the application server • Fine-grained distributed objects are never a good idea. DCOM.

com/developerworks/webservices . ibm.Web services scenarios © 2005 IBM Corporation.

– Focus on business needs first. • The most common business need addressed by Web services is integration. you’ll need to show business value to get approval for a Web services project.com/developerworks/webservices Business value • Assuming you don’t have unlimited IT budgets. 14 . technology second.ibm. © 2005 IBM Corporation.

ibm. some key considerations are: – Ensuring that Web services work well with your existing systems – Quality of service (QoS) requirements – Enterprise architecture directions – Cost © 2005 IBM Corporation. 15 .com/developerworks/webservices Business value • When architecting a Web services system.

com/developerworks/webservices Managing interoperability • You can get significant business value from a point-to-point Web service: Java client Java service J2EE application Packaged apps B2B service COBOL system But what happens when you have multiple services? © 2005 IBM Corporation. 16 .ibm.

complexity becomes a big issue… – …we need something to simplify this. 17 .com/developerworks/webservices Managing interoperability • With multiple clients and services.ibm. Java client .NET client COBOL client Perl client Python client Java service J2EE application Packaged apps B2B service COBOL system © 2005 IBM Corporation.

com/developerworks/webservices The ESB • IBM’s vision is for the Enterprise Service Bus to handle message routing between Web services.ibm.NET client COBOL client Perl client Python client Enterprise Service Bus Java service J2EE application Packaged apps B2B service COBOL system © 2005 IBM Corporation. 18 . Java client .

then get the response to the requestor.ibm. 19 . © 2005 IBM Corporation. – Remember. and so forth. this might use something other than SOAP.com/developerworks/webservices The ESB • With the ESB. something other than HTTP. the requestor’s job is to build a request according to the service’s WSDL. • The ESB’s job is to figure out how to get the request to the service.

complex Web front ends that changed often. 20 .ibm. • The presentation layer was built on high-performance.com/developerworks/webservices A customer scenario • Our first scenario involves a financial company focused on online trading. • Lots of critical business logic was in mainframe CICS transactions and DB2 stored procedures. © 2005 IBM Corporation.

© 2005 IBM Corporation. they needed load balancing. 21 .ibm. failover. The company wanted to eliminate them if possible. and security.com/developerworks/webservices Old architecture Application servers (100’s) Custom protocol Translator (10’s) SOAP engine SOAP engine CICS CICS CICS SNA • The bottleneck was the translators in the middle. • As you’d expect.

com/developerworks/webservices The solution: Adding an ESB Application servers (SOAP clients) WS Gateway (WAS V5. © 2005 IBM Corporation.x ND) SOAP over HTTP or JMS SOAP engine SOAP engine CICS SOAP engine CICS CICS SOAP over HTTP or JMS • The customer eliminated the translation servers by using standard protocols. 22 .ibm. • Data translation and the SOAP engine are now on the mainframe.

© 2005 IBM Corporation. 23 . • Hardware costs and development time were reduced. • Protocol translation (for SOAP over JMS). standard security. metering.com/developerworks/webservices ESB with the WAS WS • The customer used IBM development Gateway tools to wrap the transactions and stored procedures as Web services.ibm. and load balancing between the app servers and the mainframe were handled by the WS Gateway.

– The railroad industry has defined standards for data interchange. Those were originally used for EDI.ibm. but work for Web services also. Web services can replace costly EDI infrastructures. In a case study from the railroad industry: – Handling security was the biggest obstacle. 24 .com/developerworks/webservices B2B message exchange • In many simple B2B scenarios. © 2005 IBM Corporation.

integrity.ibm. . Railroad Internet + WS-Security WAS Web Inventory service service Authentication. nonrepudiation 25 . legacy © 2005 IBM Corporation.com/developerworks/webservices B2B message exchange • Our railroad case study: – Needed a peer-to-peer topology for security reasons – Used XML to XML transforms (one characteristic of an ESB) Railroad WAS Railroad Web application service Integration of J2EE.NET. privacy.

Local Portlet WSRP service WSRP service WSRP service 26 . and gives you a single point of authentication. Local Portlet Portal server Local Portlet Local Portlet service • WSRP lets you use Web services to access remote portlets.com/developerworks/webservices Web Services for Remote • You can use Portlets portals WSRP WSRP service to give users a common front end to multiple applications. © 2005 IBM Corporation.ibm.

“Your name?” 5.com/developerworks/webservices Designing interfaces Service interface: 1. not © 2005 IBM Corporation. conversations.ibm. Provider says “yes” or “no. “John Smith” 6. “I’d like a mortgage” 4. Client calls provider 2. Client requests a form 2. “Can I help you?” 3.” Design your services like forms. Client fills in and returns form 4. Provider sends the form 3. API interface: 1. “Address?” 20-30 steps follow… 27 .

business requirements are the driving factor.com/developerworks/webservices SOA design patterns • There are four approaches: – Unified logical view (façade pattern) – Adapters for legacy code – Composable components (get ready for BPEL) – Replaceable components (change the implementation.ibm. clients still work) • Again. © 2005 IBM Corporation. 28 .

29 .com/developerworks/webservices Unified logical views • If possible.ibm. WAS Façade Employee JAX-RPC SOAP Employee service Business session logic engine SEI EJB Employee service implementation CICS mapper JDBC mapper JCA CICS apps DB2 Other systems JDBC Custom code © 2005 IBM Corporation. don’t expose legacy interfaces and transactions – use the façade pattern instead.

Use the adapter pattern to expose individual back-ends.com/developerworks/webservices Adapters for legacy • It’s not always possible to use a interfaces WebSphere Bank branch . 30 .NET client Call center Java client Internet WAS/Linux Adapter service façade. CICS apps Everyday banking Customer info Mutual funds Adapter service Adapter service © 2005 IBM Corporation.ibm.

Choreography (BPEL) Activity 1 Activity 2 Activity 3 Shared state and context WSDL Stateless Web service WSDL Stateless Web service WSDL Public Private © 2005 IBM Corporation. you’ll probably need more complicated Web service interfaces.ibm.com/developerworks/webservices Composable components • To use a language like BPEL. Stateless Individual Web service transactio ns 31 .

” typically a stateless session bean – Function services – Web services access to core business functions © 2005 IBM Corporation. 32 . in IBM’s view… – Business transactions – A “single business state change.ibm. Will be managed with BPEL.com/developerworks/webservices Composable components • The patterns we’ve looked at so far tend to be used in three layers: – Business processes – Manage tasks that users would recognize.

consumes one or more ent.short term.com/developerworks/webservices Composable components Business Process long running one or more persons interacting multiple valid BP states alternative workflows for nonnormal conds Member Requests an Rx Refill (Call Center IVR or Online) PC Physician Approves or Denies Request (WS or Email) Reques t Denied Member Informed that Request has been Denied Rx Dept Processes Refill Member Informed that Refill is Ready Request Approve d Send Request Notification to pharmacy Business Transaction .loose coupling very important .ibm.may require compensating xactns Validate Member is Authorized to Determine Member’s Make Request Coverages and Primary Care Physician Not WS Enabled Authorization Service Masters Service WS Enabled Send Request Notification to Notes .targeted level of service reuse . .one change of business state or STP .collaborating apps encapsulated via Web services .performance more important than © 2005 IBM Corporation.collaborations to implement a single Web service . svcs. loose coupling Function Services Email Service Outpatient Service Patient Records Credit Verificatio n Office Scheduling Email System HR 33 . non-interactive .

getQuote() Insurer A adapter Insurer B adapter Insurer C adapter Insurer X adapter Insurer A Insurer B Insurer C Insurer X 34 .ibm. Insurance broker Private UDDI registry WSDL Interface for getQuote() © 2005 IBM Corporation. you can replace one service with another.com/developerworks/webservices Replaceable components • If multiple services standardize on a single interface.

replaceable components) © 2005 IBM Corporation.com/developerworks/webservices Where to use Web services • In SOA/ESB architectures • Integrating heterogeneous systems • B2B applications • Adding flexibility to business (WSRP.ibm. • Exposing legacy applications • Unified view and business logic • Hiding details of an implementation • Loose coupling – defer the choice of transport and/or service until runtime 35 .

ibm.com/developerworks/webservices Choosing a protocol Open standard ? Queued (latency) Broadca st Reliable delivery Async Sync Message queueing HTTP SMTP RMI/IIOP © 2005 IBM Corporation. 36 JMS only .

Non-Java clients (SOAP/HTTP) JAX-RPC SEI Java clients in other JVMs (RMI-IIOP) JMS-enabled clients (XML/JMS) Remote EJB interface Messagedriven bean Java clients in the same JVM 37 EJB implementation © 2005 IBM Corporation. but don’t remove the other interfaces.com/developerworks/webservices Balancing J2EE protocols • You can add a Web service interface to an EJB.ibm. Local EJB interface .

SOAP/HTTP’s performance is approaching RMIIIOP’s. © 2005 IBM Corporation.com/developerworks/webservices Between Java application • When servers considering performance between SOAP/HTTP and RMI-IIOP: – RMI-IIOP gives the best performance (for now)… – …but test SOAP/HTTP first – For complex types.ibm. 38 .

com/developerworks/webservices Between Java application • Security servers considerations: – The security context is maintained with little cost over RMI-IIOP – HTTPS gets through firewalls much more easily than IIOP – HTTPS has limitations for anything beyond point-to-point – WS-Security bridges from SOAP to EJBs. but the performance cost is high and interoperability isn’t perfect yet.ibm. 39 . © 2005 IBM Corporation.

40 .com/developerworks/webservices Between Java application • Looking servers at transactional context: – RMI-IIOP maintains transactional context – WS-Transaction has been proposed. © 2005 IBM Corporation.ibm. but isn’t available yet.

com/developerworks/webservices Location transparency • You want your clients to be unaware of the service endpoint – Ideally they won’t know the binding or protocol information either. © 2005 IBM Corporation. the client reads the endpoint information: – Services can register their implementation details. – Clients will likely cache the endpoint. including the service endpoint. 41 . in a UDDI registry.ibm. • At runtime.

from the book Core J2EE Patterns 42 © 2005 IBM Corporation. “The Business Delegate hides the implementation details of the business service.” .com/developerworks/webservices The delegate design • A useful pattern technique for protocol independence is John Crupi’s delegate design pattern. such as lookup and access mechanisms.ibm. .

com/developerworks/webservices The delegate design pattern Remote EJB Remote EJB Client delegate Local EJB delegate interface Local EJB interface Session EJB implementation Web service delegate Delegate factory Service endpoint interface Delegate service (interface) © 2005 IBM Corporation. 43 .ibm.

ibm. 44 .com/developerworks/webservices The Web Services Gateway • WebSphere Application Server V6 (Network Deployment edition) comes with the Web Services Gateway. – The gateway figures out how to connect to the service. invokes it. and the parameters for that method. the name of the method it wants to invoke. © 2005 IBM Corporation. and returns the results to the client. – A client application gives the gateway the URL of a WSDL file.

com/developerworks/webservices The Web Services Gateway SOAP Service Local Java Service Client Web Svcs.ibm. JCA Service protocol-specific details CICS Service 45 . method parameters © 2005 IBM Corporation. Gateway JMS Service WSDL URL. method name.

ibm.com/developerworks/webservices SOAP headers and handlers • We’ve looked at SOAP headers and the handler architecture several times today. 46 . Some design points: – Separate header processing from the application logic – No application data in headers – Define header processing rules declaratively in configuration files – Make any custom handlers you write configurable © 2005 IBM Corporation.

location-transparent means to mediate and route service requests and responses based on that address © 2005 IBM Corporation. 47 .com/developerworks/webservices Some more words about the ESB • The ESB should provide: – A consistent. location-transparent and protocol-independent way to address services – A consistent.ibm.

48 . © 2005 IBM Corporation.ibm.com/developerworks/webservices Some more words about the ESB • The ESB should provide: – The ability to communicate service requests and responses through whatever combination of protocols provide connectivity between endpoints – The ability to apply handlers or intermediaries to a service or a group of services.

com/developerworks/webservices .ESB patterns © 2005 IBM Corporation. ibm.

50 .ibm.com/developerworks/webservices Router patterns • There are three different variations of an ESB: – Router – Broker – Exposed gateway © 2005 IBM Corporation.

com/developerworks/webservices Router ESB • With a router ESB. © 2005 IBM Corporation. – The bus merely replaces the direct invocation of a particular service. – This is the simplest case of an ESB. the bus sends a given request to a particular service.ibm. 51 .

the bus has rules that determine which service to invoke. – If you used the ESB to invoke a service five times.com/developerworks/webservices Broker ESB • With a broker ESB.ibm. © 2005 IBM Corporation. the broker ESB might route those requests to five different services. 52 .

com/developerworks/webservices Exposed gateway ESB • With the exposed gateway ESB. – External clients send requests to the gateway. 53 . which in turn brokers those requests to various services. © 2005 IBM Corporation.ibm. there is an external gateway in front of the ESB.

ibm.Summary © 2005 IBM Corporation.com/developerworks/webservices .

authentication and all the other common problems. – We also looked at design patterns for SOAs. © 2005 IBM Corporation. An SOA still has to deal with security. – Some of them apply to any type of distributed system. As you implement this architecture.com/developerworks/webservices Summary • We've looked at a number of best practices here. 55 . these patterns will make the transition easier.ibm.

com/developerworks/webservices .ありがとうございまし た。 またお会いしましょ う! developerWorks の WebSite をご覧 ください ! © 2005 IBM Corporation. ibm.

Sign up to vote on this title
UsefulNot useful