Service Oriented Architectures

1. Service Oriented Architectures Clemens Vasters (clemensv@newtelligence.com) newtelligence AG, Germany

2. Before we begin… • What is a Web Service? • Consensus: A communication endpoint through which an application receives data and service requests • There are many Web Service definition flavors… • "Is based on SOAP" • "Is based on XML" (XML-RPC, etc.) • "Is based on HTTP" (REST) • What I am talking about today: • Transport-agnostic, SOAP-based Web Services • SOAP, WSDL, UDDI • The IBM (IBM, BEA, Microsoft) Specification Stack

3. Some History • Hot stuff and its time • 1970s: Structured Programming • Getting order into the chaos • 1980s: Object Oriented Programming • Improve organization, increase productivity and reuse • 1990s: Component Oriented Programming • Enable collaboration across module boundaries • Battles Fought • DCE vs. ORPC, CORBA vs. COM, Java vs. Windows, Java vs. COM, DCE vs. SNA, Unix vs. Windows, etc. • The Internet-wave contributed little here • No winners, the customers are the losers • Fallout: Every increasing integration cost

4. Needs • There's little "green field" anymore • New stuff needs existing stuff • Existing stuff needs new stuff • Heterogeneous Systems • No single OS-family / HW-platform • Driven by business consolidation and business need • Even in pure Windows/Unix shops: • No synchronous OS upgrades, old vs. new issues • Deal with "Big Bang" Effect • Everything keeps drifting farther away from everything • Growing desire to access/manipulate data from anywhere

5. Wants • Reuse and organization of components • Across layers & applications • Across organization & trust boundaries • Implementation agnostic data flow • Standards-based interaction • Don't depend on language/platform • Dynamic grouping and regrouping of services • Near/Far clustering and distribution • Replication • Offline / Online capabilities

6. Service-Orientation • Introducing "Service Orientation" • What is a "Service" ? • Some functional block that deals with data • Location, Platform, Code shall be irrelevant • Implications • Location: Assume remote use • Platform: Assume cross-platform use • Code: Ignore service's inner implementation

7. Assumptions to Avoid • Don't think of a "Service" as … • Transactions, Objects, Functions • These are platform/tool terms • Synchronous or Asynchronous • These are contract terms • Stateless or Stateful • Statelessness doesn't exist at runtime, anyway • The actual invocation target • Intermediate services may be invoked

8. Basic Terminology • Message • Data exchanged between services • Not Objects. Code doesn't travel • Context / Session • Defines scope of action, conversation • Clothes-line for state and infrastructure • Destinations • Target service or service class. • Logical destination, not "http://somewhere/"

9. So… what is a Service? • A service is an autonomous processing unit • Everything explicitly communicated in messages • No hidden side-effects, no hidden dependencies • From far up, there are just two types of services • Message Producers • Act and add stuff to messages • Message Consumers • Take stuff from messages and act on it • Messages flow through "pipelines" • Pipeline is a sequence of services • Made up of consumers and producers • Message grows/shrinks as it passes

10. XML XML XML XML XML XML XML XML XML RM Sec UDDI ERP Sec RM Services in a Pipeline C Runtime A Runtime B C A B Proxy RMDecl. Security context prop. Digital Signing Rou-ting Signat. verifi-cation Authen-tication,Authz. RMVerify Dis-patch

11. Service examples • Base Infrastructure • Transport, Authentication, Authorization, Transactions, etc. • Monitoring and Operations • Statistics & performance tracking, Configuration services, Provisioning • Business Services • Order Process Integration, Logistics Tracking, Mobile Data Collection in Manufacturing, …

12. Message Producer Message Consumer Networked Pipelines

13. InvestmentManager Broker/Dealer Custodian Exchange(e.g. NYSE) CSD(e.g. DTCC) 1.The Investment Manager sends the Block Trade to the Broker/Dealer. 4.The Broker/Dealer send the Investment Manager an average Price. 2.The Broker/Dealer send the Block Trade to the Specialist on the Exchange. 6.The Broker/Dealer allocates the Trades according to the Invest Manager’s instructions and books them into individual client accounts. 5.The Investment Manager tells the Broker/Dealer how to allocate the Trade to individual clients. 3.The Specialist executes all the individual blocks and sends the result to the Dealer. 8.The CSD sends confirms to the Investment Manager and the Custody Bank. 7.The Broker/Dealer sends the Trade information to the CSD for confirmation and settlement. 9.The Custodian or the Investment Manager affirms that the Trade is good. 10.On settlement date, deliveries of shares and money are moved between the Client’s Custodian and the Broker/Dealer accounts at the CSD. Adapted from Sungard Inc. – Case of the Bungled Trade

14. Components domain axis Functional Layering Services infrastructure axis The Services Bus Presentation / External Interface Workflow Orchestration andBusiness Logic Customer DataUI Orders DataUI Shipping DataUI MessageDispatch Service Bus (Broker) Message"Servicing" Customer DataLogic Orders DataLogic Shipping DataLogic ServiceDiscovery Customer ServiceMy Company Orders ServiceMy Company Shipping ServiceFedEx/UPS Customer Service J2EE Customer DataData Access Orders Service .NET Orders DataData Access Shipping Service CICS Shipping DataData Access Customer ServiceLondon Orders ServiceParis Shipping ServiceDüsseldorf Customer Service(Provider) Orders Service(Provider) Shipping Service(Provider) ServiceRegistry

15. EndpointAddress EndpointAddress EndpointAddress EndpointAddress ShippingModule CustomerModule ShippingModule ShippingModule OrdersModule XSDWSDLMEP XSDWSDLMEP XSDWSDLMEP XSDWSDLMEP ServicePolicy ServicePolicy ServicePolicy ServicePolicy Web Service Technologies Registry(UDDI) Router EndpointAddress Taxo-nomy XSDWSDLMEP ServicePolicy XSDWSDLMEP

16. Publishing and Discovery • Need to make services available • Taxonomies, Classification • Developer and production clouds • Regional, legal, trust boundaries • Need to find services • At development time and runtime • Static and dynamic binding

17. Why UDDI? • UDDI: Universal Description Discovery and Integration • Platform agnostic access • Exposed via Web Service binding • Classifications (Categories) • Allow assigning any number of classifications to a business, business service, or service binding • Location, Purpose, etc. • Taxonomies (tModel) • Allow assigning any number of technical specifications to a service binding • Not limited to Web Services. Covers Fax, Phone and Carrier Pigeon based services as well

18. Policies • WS-Policy • Need to negotiate service capabilities • Various Security aspects • Contexts and Sessions • Transactional capabilities • Reliable Messaging Guarantees • Etc. • Supported Capabilities need to be communicated • WS-Policy enables this • Allows a service to express requirements and features

19. Addressing • WS-Addressing • Need to communicate service endpoints • WS-Addressing defines endpoint references • Useful as fragment or standalone • WS-Addressing enables dynamic addressing • Overrides aspects of WS-Routing • WS-Addressing isolates binding from contract • <service> element in WSDL is a horrible thing

20. Message Exchange Patterns (1) One-Way • In, In/Out or In/In via Backchannel – WSDL Dialog Request/Response

21. Message Exchange Patterns (2) Dialog Dialog Request/Response Dialog BPEL4WS

22. Contract • Strong Data Type definitions are important • And you should expect more <xsd:simpleType name="phoneNumberType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[0-9\+][0-9\-\(\)\s]*" /> <xsd:maxLength value="26" /> </xsd:restriction> </xsd:simpleType> <schema targetNamespace="http://people" xmlns="..."> <element name="person"> <complexType> <xs:sequence> <xs:any processContents="lax" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute processContents="lax"/> </complexType> </element> </schema>

23. Arrogance as design pattern If I send you a message that complies to your contract, you better take care of the message in a proper way! Errors? You better deal with them yourself! Queue Coordinator Coordinator Queue RM Queue RM WS-RM

24. Cooperation as design pattern If I send you a message that complies to your contract, but it still fails the operation, you can let me know and I'll try to fix what I can. Coordinator Coordinator WS-Transaction

25. Contract: What about WSDL? • Important elements of WSDL • <type>: Declaration/Import of types • Practically always expressed in XSD • <portType>: Definition of "interfaces" • Groups operations (set of in/out messages) • Covered elsewhere • <message> is redundant to begin with • <service> covered by WS-Addressing • <binding> is partially covered by WS-Policy • If everything was SOAP all the time, Policy would cover it completely

26. Summary • SOA is an evolutionary thing • No radically new thinking • Consolidates good things • The Message is the Message! • Think "message" instead of "call" • XML is better than binary • Asynchronous is good.