CERN European Organization for Nuclear Research IT Department

CERN – European Organization for Nuclear Research IT Department – Administrative Information Services Service Oriented Architecture definition and main concepts Derek Mathieson IT Department CERN Some content from Peter Campbell, ANZ Banking Group Australia

Problem Statement l Promote reuse – Open architecture l Systems Integration – Link-up Enterprise Information Systems l Interface with other companies – B 2 B transactions and processes l Increase Agility – Acquisition and/or merger – Changing Business models CERN IT-AIS

SOA – A definition from the W 3 C Typical characteristics of a SOA: l Logical view – defined by what a service does l Platform neutral – often XML based l Description orientation – service description is machine-processable. l Message orientation – defined in terms of the messages exchanged between requester and provider l Granularity – Coarse-grained l Network orientation – not an absolute requirement. CERN IT-AIS

SOA Conceptual Architecture Find (UDDI Inquiry find_xxx) Service Consumer Client Service Broker (UDDI) Bind & invoke SOAP Register (UDDI Publish save_xxx) Service Provider Service Contract (WSDL) Service XML Binding Choices: l Static binding – Not loosely coupled as the consumer will fail if the service is offline l CERN IT-AIS Dynamic binding – Can allow runtime failover and load balancing – Service discovery at runtime can have serious performance issues – Less commonly used

What are Web Services? Application 2 Application 1 XML Applications communicating over the internet using an agreed message format – encoded as XML CERN IT-AIS

Packaging – Soap HTTP Post SOAP Envelope SOAP Header SOAP Body CERN IT-AIS

Packaging – Soap <s: Envelope xmlns: s="URN"> <s: Header> <s: Transaction xmlns: m="URN"> <m: Transaction. ID> 17389 </m: Transaction. ID > </s: Transaction> </s: Header> <s: Body> <n: purchase. Order xmlns: n=“URN”> <n: item>socks</n: item> <n: quantity>1</n: quantity> <n: unit. Price>3. 95</n: unit. Price> </n: purchase. Order> </s: Body> </s: Envelope> CERN IT-AIS

Description – WSDL l Web Services Description Language l “Web Services Description Language (WSDL) provides a model and an XML format for describing Web services. ” w 3 c. org CERN IT-AIS

Description – WSDL Types Messages Operations Encoding Endpoint CERN IT-AIS

Types <types> <schema target. Namespace="stockquote. xsd" xmlns="XMLSchema"> <element name="Trade. Price. Request"> <complex. Type> <all> <element name="ticker. Symbol" type="string"/> </all> </complex. Type> </element> <element name="Trade. Price"> <complex. Type> <all><element name="price" type="float"/> </all> </complex. Type> </element> </schema> </types> CERN IT-AIS

Messages <message name="Get. Last. Trade. Price. Input"> <part name="body" element="xsd 1: Trade. Price. Request"/> </message> <message name="Get. Last. Trade. Price. Output"> <part name="body" element="xsd 1: Trade. Price"/> </message> CERN IT-AIS

Operations <operation name="Get. Last. Trade. Price"> <input message="tns: Get. Last. Trade. Price. Input"/> <output message="tns: Get. Last. Trade. Price. Output"/> </operation> CERN IT-AIS

Encoding <binding name="Stock. Quote. Soap. Binding" type="tns: Stock. Quote. Port. Type"> <soap: binding style="document" transport="http: //schemas. xmlsoap. org/soap/http"/> <operation name="Get. Last. Trade. Price"> <soap: operation soap. Action="http: //example. com/Get. Last. Trade. Price"/> <input> <soap: body use="literal"/> </input> <output> <soap: body use="literal"/> </output> </operation> </binding> CERN IT-AIS

Endpoint <service name="Stock. Quote. Service"> <documentation>Stock service</documentation> <port name="Stock. Quote. Port" binding="tns: Stock. Quote. Soap. Binding"> <soap: address location="http: //example. com/stockquote"/> </port> </service> CERN IT-AIS

Discovery – UDDI l Universal Description, Discovery and Integration l A UDDI Server acts as a registry for Web Services and makes them searchable. CERN IT-AIS

Discovery – UDDI Inquiry Publish CERN IT-AIS UDDI Registry

Discovery – UDDI Inquiry Publish CERN IT-AIS UDDI Registry

SOA and Web services l – delivers key standards for implementing SOA XML l – Ideal candidate for loosely coupled inter-application data sharing The WS-* Standards Family l – EAI & B 2 B SOA “The architecture” Services architecture l Service contract l Message based l Service directory l Protocol independent l Coarse grained l l Web services specs l WSDL l SOAP & XML l UDDI l HTTP l Doc literal binding l RPC interactions l Binary XML l Web services “The plumbing” Process orchestration (WS-BPEL) CERN IT-AIS Author: Peter Campbell, ANZ Banking Group Australia

Web Services Framework l The Web Services Framework consists of the following technologies: Wire stack Technologies that determine how a message is sent from the service requestor to the service provider e. g. SOAP. Production usage. Evolving to cover advanced messaging functions Description stack Technologies that allow a common understanding between service requestor and service provider e. g. WSDL. Production usage. Evolving to cover security and other additional functions Technologies that allow a service requestor to discover a service provider e. g. UDDI. Production usage for static binding. Evolving to cover dynamic binding & discovery Discovery stack CERN IT-AIS

Service implementation l. A service is a component built for reuse by other components in different execution contexts. Service Interface Service Provides service identification, definition of parameters, and passing results back to the consumer Implementation details are hidden from the consumer Services might need to be able to distinguish messages from individual consumers and also be able to correlate those messages into meaningful conversations. CERN IT-AIS

Services and business processes l Services can be linked to form business processes using process orchestration “Open account for customer” Business Process Presentation – user interface Business Process Orchestration Business Services Get customer details Get account type Add account to customer Coarse Grained Service Orchestration (Process Orchestration) Technical Services CERN IT-AIS Locate customer record Check customer status Lookup account type table Retrieve account details Create Customer. Account record Fine Grained

Service Reuse l A service can be reused across multiple channels Business services Presentation layer Delivery Channels Customer Service Account Enquiry (staff assisted) Branch Get Account Balance Account Enquiry (self service) ATM Internet Account Enquiry (self service) CERN IT-AIS

Integration roadmap to SOA 2. Message-based middleware with integration broker 1. Point to point systems Partner App A (J 2 EE) App B (. Net) App C App D (J 2 EE) Legacy Application App D Sales Warehouse Sales App B Service Bus / MOM Adapter Shared System Legacy Application Adapter Legacy System Finance 3. Service Oriented Architecture & Enterprise Service Bus Custom applications CERN IT-AIS Services Business Process Orchestration Business Rules Engine Enterprise Service Bus HTTP Internet Package applications Adapter Legacy System Shared System Routing Transformation Service (Process) orchestration Warehouse

Integration – point to point systems Partner Advantages – Connectivity, some integration Issues: – – – – – CERN IT-AIS App A Sales Warehouse App B App C Tightly coupled Legacy Hard to change Application Lack of common interface standards Finance Security issues Limited integration and sharing of data Single points of failure can bring down whole system Not asynchronous – poor performance and scalability Silo-based systems aligned with specific business units Fine-grained services often not reused across the enterprise Different integration formats App D

Message Oriented Middleware Advantages – Common application interface (API) – Provides some abstraction between consumer and provider – Asynchronous Warehouse – Transformation Partner App B App D – Content-based routing App A – Reuse services & transactions Sales MOM App C Adapter Issues: Shared System – Proprietary service definition – Messages dependent on middleware – External (B 2 B) connectivity difficult – Some consumer-channel-message coupling – Limited service repository and manual registry CERN IT-AIS Adapter Legacy System Finance

Service Oriented Architecture & Enterprise Service Bus Custom applications Services Business Process Orchestration Business Rules Engine Enterprise Service Bus HTTP Internet Package applications Adapter Legacy System Shared System Routing Transformation Service (Process) orchestration Advantages – – – – CERN IT-AIS Service bus implementation Service definition Common application interface (API) Provides some abstraction between consumer and provider Asynchronous Transformation Content-based routing Reuse services & transactions – Integration broker – Standard service description (via WSDL) – External (B 2 B) connectivity simplified via Web services – Security and identity management provided by WS-Security standards – Support for Event Driven Architecture

What is ESB? l Enterprise Service Bus (ESB) helps manage large number of services by providing horizontal value-adds such as: – Security – Transactions – Reliability – Service Virtualization • Load Balancing • Message Distribution (Fan out and in) CERN IT-AIS

How does ESB Work? l ESB works by using the extension mechanisms built into SOAP: 1. Message syntax and semantics can be extended with headers 2. Messages can be intercepted and worked on by intermediaries l Headers are not just syntax as in Mail Headers – Semantics of who may/must process headers allows standardization of extensions. E. g. , WS-Security CERN IT-AIS

Event Driven Architecture (EDA) l Event Driven Architecture (EDA) – Event triggered messages – Sender & Receiver have no knowledge of each other – Queued messaging • Store-and-Forward • Events published to a topic may be sent to zero, one or many interested recipients. Publisher msg 1 Subscribe to: msg 1 & msg 2 CERN IT-AIS A msg 1 Subscriber msg 2 Broker X Publisher msg 2 Y

SOAP Interaction Patterns SOAP supports the following four interaction patterns: 1. Request-response (client to server and back) 3. One way (from client to server) Request Client Server Client One way Server Response 2. Notification-response (server to client and back) 3. Notification (from server to client) Notification Server Client Server Notification Client Response SOAP is able to support both remote procedure call (RPC) and document-style interactions, in either a synchronous or asynchronous fashion CERN IT-AIS

Conclusions l SOA – Is not a NEW idea • But the pieces are now in place – Facilitates • Modular design / architecture l Many implementations – Commercial & Open Source CERN IT-AIS

CERN IT-AIS

Thank You For More Information Browse to: http: //www. w 3. org/TR/ws-arch or Email: Derek. Mathieson@cern. ch CERN IT-AIS