emily's picture
From emily rss RSS  subscribe Subscribe

SOA design patterns and best practices 



 

 
 
Tags:  SOA  design 
Views:  4909
Downloads:  123
Published:  August 02, 2007
 
2
download

Share plick with friends Share
save to favorite
Report Abuse Report Abuse
 
Related Plicks
Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA)

From: babo
Views: 6806 Comments: 0
Service Oriented Architecture (SOA): Definition, Characteristics
Differences: SOA vs. existing Model Driven Architecture (MDA)
SOA Implementation Framework and Enterprise Service Bus (ESB) (more)

 
Energy and Entropy: Equilibrium to Stationary States

Energy and Entropy: Equilibrium to Stationary States

From: anon-390293
Views: 423 Comments: 0
Energy and Entropy: Equilibrium to Stationary States ,backstage library works, utempter library static, soa design patterns ebook torrent, media library album
 
Techweb State Of Soa Research

Techweb State Of Soa Research

From: bbridsa
Views: 620 Comments: 0
Techweb State Of Soa Research
 
Building on SOA Entry Point Successes

Building on SOA Entry Point Successes

From: emily
Views: 7765 Comments: 1

 
 enm2007week9chap6

enm2007week9chap6

From: lvgangqiang
Views: 1808 Comments: 0

 
A Practitioners Guide to Modern SOA Testing

A Practitioners Guide to Modern SOA Testing

From: manisha229249
Views: 110 Comments: 0
"Infosys Guide to Modern SOA Testing have resulted in businesses asking a new set of questions to test managers, consultants and architects, like how does one test these modern SOA systems? This paper
attempts to answer the (more)

 
See all 
 
More from this user
Java One 2005 Technical

Java One 2005 Technical

From: emily
Views: 3552
Comments: 0

NSDI - Poland

NSDI - Poland

From: emily
Views: 2780
Comments: 0

Welcome to the Minnesota SharePoint User Group

Welcome to the Minnesota SharePoint User Group

From: emily
Views: 6345
Comments: 0

Java One 2002 Overview

Java One 2002 Overview

From: emily
Views: 2944
Comments: 0

SQL Server 2005

SQL Server 2005

From: emily
Views: 3962
Comments: 1

CATPDG Quick Start Demo

CATPDG Quick Start Demo

From: emily
Views: 1808
Comments: 0

See all 
 
 
 URL:          AddThis Social Bookmark Button
Embed Thin Player: (fits in most blogs)
Embed Full Player :
 
 

Name

Email (will NOT be shown to other users)

 

 
 
Comments: (watch)
 
 
Notes:
 
Slide 1: SOA design patterns and best practices 私の名前は、 Doug Tidwell です。 SOA のセミナーにお申込いただき、ありがとうございます 。 © 2005 IBM Corporation. ibm.com/developerworks/webservices
Slide 2: 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
Slide 3: ibm.com/developerworks/webservices A great book • Written by Kyle Brown and other IBM experts • Based on real-world experience solving customer problems. • ISBN 032118579X © 2005 IBM Corporation. 3
Slide 4: 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
Slide 5: ibm.com/developerworks/webservices Distributed systems challenges • • • • • • • Performance Scalability Management Granularity Protocol conversions Network bandwidth Failover • Achieving loose coupling • Versioning • Security • Maintaining context (session state, transactions) • Development, test, & integration costs None of these are specific to Web services. © 2005 IBM Corporation. 5
Slide 6: ibm.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 synchronous or asynchronous, can be RPCor document-style • Doesn’t require a radical redesign of your existing architecture – Web services complement other distributed technologies, they don’t replace them. © 2005 IBM Corporation. 6
Slide 7: ibm.com/developerworks/webservices IBM’s view of Web services • Start with good distributed design principles, especially layer design and layer placement • Enable your legacy systems for SOAs • Standards, standards, standards – Interoperability is crucial, so make sure your tools adhere to standards. © 2005 IBM Corporation. 7
Slide 8: Web services anti-patterns © 2005 IBM Corporation. ibm.com/developerworks/webservices
Slide 9: ibm.com/developerworks/webservices WS for integration • Don’t use SOAP over HTTP or XML between layers of an application: • Do use them at the edge. Result set converted to XML WebSphere Application Server SOAP engine Session EJB Model managers XML converted to domain XML format Domain objects XML converted to domain objects Data Access Objects DB ASP IIS © 2005 IBM Corporation. 9
Slide 10: 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. • Don’t use these methods with a distributed Employee object! © 2005 IBM Corporation. 10
Slide 11: 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. © 2005 IBM Corporation. 11
Slide 12: ibm.com/developerworks/webservices Lessons • Don’t use SOAP over HTTP or XML just because they’re new and cool. – 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, whether you’re using Web services, CORBA, EJBs, DCOM, RMI, etc. © 2005 IBM Corporation. 12
Slide 13: Web services scenarios © 2005 IBM Corporation. ibm.com/developerworks/webservices
Slide 14: ibm.com/developerworks/webservices Business value • Assuming you don’t have unlimited IT budgets, you’ll need to show business value to get approval for a Web services project. – Focus on business needs first, technology second. • The most common business need addressed by Web services is integration. © 2005 IBM Corporation. 14
Slide 15: ibm.com/developerworks/webservices Business value • When architecting a Web services system, 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
Slide 16: ibm.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
Slide 17: ibm.com/developerworks/webservices Managing interoperability • With multiple clients and services, complexity becomes a big issue… – …we need something to simplify this. Java client .NET client COBOL client Perl client Python client Java service J2EE application Packaged apps B2B service COBOL system © 2005 IBM Corporation. 17
Slide 18: ibm.com/developerworks/webservices The ESB • IBM’s vision is for the Enterprise Service Bus to handle message routing between Web services. Java client .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
Slide 19: ibm.com/developerworks/webservices The ESB • With the ESB, the requestor’s job is to build a request according to the service’s WSDL. – Remember, this might use something other than SOAP, something other than 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 the requestor. © 2005 IBM Corporation. 19
Slide 20: ibm.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. • The presentation layer was built on highperformance, complex Web front ends that changed often. © 2005 IBM Corporation. 20
Slide 21: ibm.com/developerworks/webservices Old architecture Application servers (100’s) Translator (10’s) SNA SOAP engine SOAP engine CICS CICS CICS Custom protocol • The bottleneck was the translators in the middle. The company wanted to eliminate them if possible. • As you’d expect, they needed load balancing, failover, and security. © 2005 IBM Corporation. 21
Slide 22: ibm.com/developerworks/webservices The solution: Adding an ESB Application servers (SOAP clients) WS Gateway (WAS V5.x ND) SOAP engine SOAP engine CICS SOAP engine CICS CICS SOAP over HTTP or JMS SOAP over HTTP or JMS • The customer eliminated the translation servers by using standard protocols. • Data translation and the SOAP engine are now on the mainframe. © 2005 IBM Corporation. 22
Slide 23: ibm.com/developerworks/webservices ESB with the WAS WS Gateway • The customer used IBM development tools to wrap the transactions and stored procedures as Web services. • Protocol translation (for SOAP over JMS), standard security, metering, and load balancing between the app servers and the mainframe were handled by the WS Gateway. • Hardware costs and development time were reduced. © 2005 IBM Corporation. 23
Slide 24: ibm.com/developerworks/webservices B2B message exchange • In many simple B2B scenarios, Web services can replace costly EDI infrastructures. In a case study from the railroad industry: – Handling security was the biggest obstacle. – The railroad industry has defined standards for data interchange. Those were originally used for EDI, but work for Web services also. © 2005 IBM Corporation. 24
Slide 25: ibm.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 application Web service Internet + WS-Security Railroad WAS Web service Inventory service Integration of J2EE, .NET, legacy © 2005 IBM Corporation. Authentication, privacy, integrity, non-repudiation 25
Slide 26: ibm.com/developerworks/webservices Web Services for Remote Portlets • You can use portals to give users a common front end to multiple applications. WSRP service Local Portlet Portal server Local Portlet WSRP service • WSRP lets you use Web services to access remote portlets, and gives you a single point of authentication. Local Portlet WSRP service Local Portlet WSRP service © 2005 IBM Corporation. WSRP service 26
Slide 27: ibm.com/developerworks/webservices Designing interfaces Service interface: 2. Client requests a form 3. Provider sends the form 4. Client fills in and returns form 5. Provider says “yes” or “no.” Design your services like forms, not conversations. © 2005 IBM Corporation. API interface: 2. Client calls provider 3. “Can I help you?” 4. “I’d like a mortgage” 5. “Your name?” 6. “John Smith” 7. “Address?” 20-30 steps follow… 27
Slide 28: ibm.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, clients still work) • Again, business requirements are the driving factor. © 2005 IBM Corporation. 28
Slide 29: ibm.com/developerworks/webservices Unified logical views • If possible, don’t expose legacy interfaces and transactions – use the façade pattern instead. 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 JDBC DB2 Other systems Custom code © 2005 IBM Corporation. 29
Slide 30: ibm.com/developerworks/webservices Adapters for legacy interfaces • It’s not always possible to use a façade. Use the adapter pattern to expose individual back-ends. WebSphere Bank branch .NET client Call center Java client Internet WAS/Linux Adapter service CICS apps Everyday banking Customer info Mutual funds Adapter service Adapter service © 2005 IBM Corporation. 30
Slide 31: ibm.com/developerworks/webservices Composable components • To use a language like BPEL, you’ll probably need more complicated Web service interfaces. Choreography (BPEL) Activity 1 Activity 2 Activity 3 Shared state and context WSDL Stateless Web service WSDL Stateless Web service WSDL Stateless Web service Public Private Individual transactions 31 © 2005 IBM Corporation.
Slide 32: ibm.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. Will be managed with BPEL, in IBM’s view… – Business transactions – A “single business state change,” typically a stateless session bean – Function services – Web services access to core business functions © 2005 IBM Corporation. 32
Slide 33: ibm.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) Request Denied Member Informed that Request has been Denied Rx Dept Processes Refill Request Approved Member Informed that Refill is Ready - short term, non-interactive - one change of business state or STP - consumes one or more ent. svcs. - targeted level of service reuse - loose coupling very important - may require compensating xactns Business Transaction Validate Member is Authorized to Make Determine Member’s Coverages Request and Primary Care Physician WS Enabled Send Request Notification to pharmacy Not WS Enabled Authorization Service Masters Service Send Request Notification to Notes - collaborations to implement a single Web service - collaborating apps encapsulated via Web services - performance more important than loose coupling © 2005 IBM Corporation. Function Services Email Service Outpatient Service Patient Records Credit Verification Office Scheduling Email System HR 33
Slide 34: ibm.com/developerworks/webservices Replaceable components • If multiple services standardize on a single interface, you can replace one service with another. Insurance broker Private UDDI registry WSDL Interface for getQuote() © 2005 IBM Corporation. getQuote() Insurer A adapter Insurer B adapter Insurer C adapter Insurer X adapter Insurer A Insurer B Insurer C Insurer X 34
Slide 35: ibm.com/developerworks/webservices Where to use Web services • In SOA/ESB architectures • Integrating heterogeneous systems • B2B applications • Adding flexibility to business (WSRP, replaceable components) © 2005 IBM Corporation. • 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
Slide 36: ibm.com/developerworks/webservices Choosing a protocol Broadcast Open standard? Queued (latency) Reliable delivery Async Sync Message queueing HTTP SMTP RMI/IIOP © 2005 IBM Corporation. 36 JMS only
Slide 37: ibm.com/developerworks/webservices Balancing J2EE protocols • You can add a Web service interface to an EJB, but don’t remove the other interfaces. Non-Java clients (SOAP/HTTP) Java clients in other JVMs (RMI-IIOP) JMS-enabled clients (XML/JMS) JAX-RPC SEI Remote EJB interface Messagedriven bean Java clients in the same JVM 37 EJB implementation © 2005 IBM Corporation. Local EJB interface
Slide 38: ibm.com/developerworks/webservices Between Java application servers • When considering performance between SOAP/HTTP and RMI-IIOP: – RMI-IIOP gives the best performance (for now)… – …but test SOAP/HTTP first – For complex types, SOAP/HTTP’s performance is approaching RMI-IIOP’s. © 2005 IBM Corporation. 38
Slide 39: ibm.com/developerworks/webservices Between Java application servers • Security 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. © 2005 IBM Corporation. 39
Slide 40: ibm.com/developerworks/webservices Between Java application servers • Looking at transactional context: – RMI-IIOP maintains transactional context – WS-Transaction has been proposed, but isn’t available yet. © 2005 IBM Corporation. 40
Slide 41: ibm.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. • At runtime, the client reads the endpoint information: – Services can register their implementation details, including the service endpoint, in a UDDI registry. – Clients will likely cache the endpoint. © 2005 IBM Corporation. 41
Slide 42: ibm.com/developerworks/webservices The delegate design pattern • A useful technique for protocol independence is John Crupi’s delegate design pattern. “The Business Delegate hides the implementation details of the business service, such as lookup and access mechanisms.” - from the book Core J2EE Patterns © 2005 IBM Corporation. 42
Slide 43: ibm.com/developerworks/webservices The delegate design pattern Client Remote EJB delegate Local EJB delegate Remote EJB interface Local EJB interface Session EJB implementation Web service delegate Delegate factory Service endpoint interface Delegate service (interface) © 2005 IBM Corporation. 43
Slide 44: ibm.com/developerworks/webservices The Web Services Gateway • WebSphere Application Server V6 (Network Deployment edition) comes with the Web Services Gateway. – A client application gives the gateway the URL of a WSDL file, the name of the method it wants to invoke, and the parameters for that method. – The gateway figures out how to connect to the service, invokes it, and returns the results to the client. © 2005 IBM Corporation. 44
Slide 45: ibm.com/developerworks/webservices The Web Services Gateway SOAP Service Local Java Service Client Web Svcs. Gateway JMS Service WSDL URL, method name, method parameters JCA Service protocol-specific details CICS Service 45 © 2005 IBM Corporation.
Slide 46: ibm.com/developerworks/webservices SOAP headers and handlers • We’ve looked at SOAP headers and the handler architecture several times today. 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. 46
Slide 47: ibm.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, location-transparent means to mediate and route service requests and responses based on that address © 2005 IBM Corporation. 47
Slide 48: 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. © 2005 IBM Corporation. 48
Slide 49: ESB patterns © 2005 IBM Corporation. ibm.com/developerworks/webservices
Slide 50: ibm.com/developerworks/webservices Router patterns • There are three different variations of an ESB: – Router – Broker – Exposed gateway © 2005 IBM Corporation. 50
Slide 51: ibm.com/developerworks/webservices Router ESB • With a router ESB, the bus sends a given request to a particular service. – This is the simplest case of an ESB. – The bus merely replaces the direct invocation of a particular service. © 2005 IBM Corporation. 51
Slide 52: ibm.com/developerworks/webservices Broker ESB • With a broker ESB, the bus has rules that determine which service to invoke. – If you used the ESB to invoke a service five times, the broker ESB might route those requests to five different services. © 2005 IBM Corporation. 52
Slide 53: ibm.com/developerworks/webservices Exposed gateway ESB • With the exposed gateway ESB, there is an external gateway in front of the ESB. – External clients send requests to the gateway, which in turn brokers those requests to various services. © 2005 IBM Corporation. 53
Slide 54: Summary © 2005 IBM Corporation. ibm.com/developerworks/webservices
Slide 55: ibm.com/developerworks/webservices Summary • We've looked at a number of best practices here. – Some of them apply to any type of distributed system. An SOA still has to deal with security, authentication and all the other common problems. – We also looked at design patterns for SOAs. As you implement this architecture, these patterns will make the transition easier. © 2005 IBM Corporation. 55
Slide 56: ありがとうございました。 またお会いしましょう! developerWorks の WebSite をご覧ください ! © 2005 IBM Corporation. ibm.com/developerworks/webservices

   
Time on Slide Time on Plick
Slides per Visit Slide Views Views by Location