This action might not be possible to undo. Are you sure you want to continue?
私の名前は、 Doug Tidwell です。 SOA のセミナーにお申込いただき、ありがとう ございます。
© 2005 IBM Corporation.
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.
A great book
• Written by Kyle Brown and other IBM experts • Based on realworld experience solving customer problems. • ISBN 032118579X
© 2005 IBM Corporation.
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
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
© 2005 IBM Corporation.
None of these are specific to Web services.
© 2005 IBM Corporation.com/developerworks/webservices IBM’s view of Web services • A Web service is described by WSDL – Doesn’t have to use SOAP or HTTP.ibm. can be synchronous or asynchronous. can be RPC. 6 . they don’t replace them.or document-style • Doesn’t require a radical redesign of your existing architecture – Web services complement other distributed technologies.
standards.com/developerworks/webservices IBM’s view of Web services • Start with good distributed design principles.ibm. especially layer design and layer placement • Enable your legacy systems for SOAs • Standards. so make sure your tools adhere to standards. standards – Interoperability is crucial. © 2005 IBM Corporation. 7 .
ibm.Web services antipatterns © 2005 IBM Corporation.com/developerworks/webservices .
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. .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.
• Don’t use these methods with a distributed Employee object! © 2005 IBM Corporation.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 .
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. 12 .ibm. whether you’re using Web services.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. EJBs. DCOM. etc. RMI.
Web services scenarios © 2005 IBM Corporation.com/developerworks/webservices . ibm.
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. • The most common business need addressed by Web services is integration. – Focus on business needs first. © 2005 IBM Corporation. technology second.ibm. 14 .
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 .ibm.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.ibm. 16 .
ibm.NET client COBOL client Perl client Python client Java service J2EE application Packaged apps B2B service COBOL system © 2005 IBM Corporation.com/developerworks/webservices Managing interoperability • With multiple clients and services. 17 . complexity becomes a big issue… – …we need something to simplify this. Java client .
com/developerworks/webservices The ESB • IBM’s vision is for the Enterprise Service Bus to handle message routing between Web services.ibm. 18 .NET client COBOL client Perl client Python client Enterprise Service Bus Java service J2EE application Packaged apps B2B service COBOL system © 2005 IBM Corporation. Java client .
19 .com/developerworks/webservices The ESB • With the ESB. © 2005 IBM Corporation. and so forth.ibm. this might use something other than SOAP. • The ESB’s job is to figure out how to get the request to the service. then get the response to the requestor. – Remember. the requestor’s job is to build a request according to the service’s WSDL. something other than HTTP.
complex Web front ends that changed often.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. 20 . • Lots of critical business logic was in mainframe CICS transactions and DB2 stored procedures. © 2005 IBM Corporation.
failover. they needed load balancing. The company wanted to eliminate them if possible. © 2005 IBM Corporation. and security. • As you’d expect.ibm. 21 .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.
com/developerworks/webservices The solution: Adding an ESB Application servers (SOAP clients) WS Gateway (WAS V5. 22 .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. • Data translation and the SOAP engine are now on the mainframe.ibm. © 2005 IBM Corporation.
ibm. and load balancing between the app servers and the mainframe were handled by the WS Gateway. standard security. metering. • Hardware costs and development time were reduced.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. 23 . © 2005 IBM Corporation. • Protocol translation (for SOAP over JMS).
Web services can replace costly EDI infrastructures. but work for Web services also. 24 . In a case study from the railroad industry: – Handling security was the biggest obstacle.com/developerworks/webservices B2B message exchange • In many simple B2B scenarios. © 2005 IBM Corporation. – The railroad industry has defined standards for data interchange.ibm. Those were originally used for EDI.
privacy.NET.ibm. . nonrepudiation 25 .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. legacy © 2005 IBM Corporation. integrity. Railroad Internet + WS-Security WAS Web Inventory service service Authentication.
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. and gives you a single point of authentication. © 2005 IBM Corporation. Local Portlet Portal server Local Portlet Local Portlet service • WSRP lets you use Web services to access remote portlets.ibm. Local Portlet WSRP service WSRP service WSRP service 26 .
” Design your services like forms. Provider says “yes” or “no.ibm. “Address?” 20-30 steps follow… 27 . Client fills in and returns form 4. API interface: 1. “Your name?” 5. “John Smith” 6. Client requests a form 2. conversations. Provider sends the form 3. “I’d like a mortgage” 4.com/developerworks/webservices Designing interfaces Service interface: 1. “Can I help you?” 3. not © 2005 IBM Corporation. Client calls provider 2.
ibm. © 2005 IBM Corporation. clients still work) • Again. business requirements are the driving factor. 28 .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.
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. 29 . don’t expose legacy interfaces and transactions – use the façade pattern instead.
CICS apps Everyday banking Customer info Mutual funds Adapter service Adapter service © 2005 IBM Corporation. 30 .com/developerworks/webservices Adapters for legacy • It’s not always possible to use a interfaces WebSphere Bank branch .ibm.NET client Call center Java client Internet WAS/Linux Adapter service façade. Use the adapter pattern to expose individual back-ends.
ibm. you’ll probably need more complicated Web service interfaces. Stateless Individual Web service transactio ns 31 . 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.com/developerworks/webservices Composable components • To use a language like BPEL.
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.” typically a stateless session bean – Function services – Web services access to core business functions © 2005 IBM Corporation. 32 .
loose coupling very important .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 .one change of business state or STP . svcs.collaborating apps encapsulated via Web services .collaborations to implement a single Web service .consumes one or more ent.ibm.performance more important than © 2005 IBM Corporation.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 . non-interactive .targeted level of service reuse . loose coupling Function Services Email Service Outpatient Service Patient Records Credit Verificatio n Office Scheduling Email System HR 33 .short term. .
com/developerworks/webservices Replaceable components • If multiple services standardize on a single interface. 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 . you can replace one service with another.ibm.
ibm. 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. • 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 .
36 JMS only .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.
com/developerworks/webservices Balancing J2EE protocols • You can add a Web service interface to an EJB. 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. Local EJB interface .ibm. but don’t remove the other interfaces.
ibm. © 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. 38 . SOAP/HTTP’s performance is approaching RMIIIOP’s.
but the performance cost is high and interoperability isn’t perfect yet. 39 .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.ibm. © 2005 IBM Corporation.
com/developerworks/webservices Between Java application • Looking servers at transactional context: – RMI-IIOP maintains transactional context – WS-Transaction has been proposed. but isn’t available yet.ibm. © 2005 IBM Corporation. 40 .
© 2005 IBM Corporation. • At runtime. – Clients will likely cache the endpoint.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. including the service endpoint. the client reads the endpoint information: – Services can register their implementation details.ibm. in a UDDI registry. 41 .
ibm.” .com/developerworks/webservices The delegate design • A useful pattern technique for protocol independence is John Crupi’s delegate design pattern.from the book Core J2EE Patterns 42 © 2005 IBM Corporation. . such as lookup and access mechanisms. “The Business Delegate hides the implementation details of the business service.
43 .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.
© 2005 IBM Corporation. – The gateway figures out how to connect to the service.com/developerworks/webservices The Web Services Gateway • WebSphere Application Server V6 (Network Deployment edition) comes with the Web Services Gateway. and returns the results to the client. 44 .ibm. the name of the method it wants to invoke. – A client application gives the gateway the URL of a WSDL file. invokes it. and the parameters for that method.
com/developerworks/webservices The Web Services Gateway SOAP Service Local Java Service Client Web Svcs. method name. method parameters © 2005 IBM Corporation. Gateway JMS Service WSDL URL.ibm. JCA Service protocol-specific details CICS Service 45 .
ibm. 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.com/developerworks/webservices SOAP headers and handlers • We’ve looked at SOAP headers and the handler architecture several times today.
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.ibm. 47 .
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.ibm. 48 . © 2005 IBM Corporation.
com/developerworks/webservices .ESB patterns © 2005 IBM Corporation. ibm.
com/developerworks/webservices Router patterns • There are three different variations of an ESB: – Router – Broker – Exposed gateway © 2005 IBM Corporation. 50 .ibm.
– The bus merely replaces the direct invocation of a particular service. © 2005 IBM Corporation. the bus sends a given request to a particular service. 51 .ibm. – This is the simplest case of an ESB.com/developerworks/webservices Router ESB • With a router ESB.
– If you used the ESB to invoke a service five times.com/developerworks/webservices Broker ESB • With a broker ESB. © 2005 IBM Corporation. the broker ESB might route those requests to five different services.ibm. 52 . the bus has rules that determine which service to invoke.
there is an external gateway in front of the ESB. which in turn brokers those requests to various services. 53 . © 2005 IBM Corporation.com/developerworks/webservices Exposed gateway ESB • With the exposed gateway ESB. – External clients send requests to the gateway.ibm.
ibm.Summary © 2005 IBM Corporation.com/developerworks/webservices .
com/developerworks/webservices Summary • We've looked at a number of best practices here. these patterns will make the transition easier. © 2005 IBM Corporation. As you implement this architecture. – We also looked at design patterns for SOAs. – Some of them apply to any type of distributed system.ibm. authentication and all the other common problems. 55 . An SOA still has to deal with security.
com/developerworks/webservices . ibm.ありがとうございまし た。 またお会いしましょ う！ developerWorks の WebSite をご覧 ください ! © 2005 IBM Corporation.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.