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

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

CERN IT-AIS Why Web Services? “The Web can grow significantly in power and scope if it is extended to support communication between applications, from one program to another.” - From the W3C XML Protocol Working Group Charter

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

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

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

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

CERN IT-AIS Packaging – Soap socks

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

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

CERN IT-AIS Types <schema targetNamespace="stockquote.xsd" xmlns="XMLSchema">

CERN IT-AIS Messages

CERN IT-AIS Operations

CERN IT-AIS Encoding

CERN IT-AIS Endpoint Stock service

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

CERN IT-AIS Discovery – UDDI UDDI Registry Inquiry Publish

CERN IT-AIS Discovery – UDDI UDDI Registry Inquiry Publish

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

CERN IT-AIS Web Services Framework The Web Services Framework consists of the following technologies: Wire stack Description stack Discovery stack 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 Technologies that allow a common understanding between service requestor and service provider Technologies that determine how a message is sent from the service requestor to the service provider e.g. WSDL. Production usage. Evolving to cover security and other additional functions e.g. SOAP. Production usage. Evolving to cover advanced messaging functions

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

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

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

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

CERN IT-AIS Integration – point to point systems Advantages –Connectivity, some integration Issues: –Tightly coupled –Hard to change –Lack of common interface standards –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 A Legacy Application Legacy Application App B App D Warehouse Finance Sales App C Partner

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

CERN IT-AIS Service Oriented Architecture & Enterprise Service Bus Enterprise Service Bus Routing Services Custom applications Package applications Business Process Orchestration Adapter Shared System Transformation Adapter Legacy System Service (Process) orchestration Internet Business Rules Engine Advantages –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 (B2B) connectivity simplified via Web services –Security and identity management provided by WS-Security standards –Support for Event Driven Architecture HTTP

CERN IT-AIS 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) What is ESB?

CERN IT-AIS How does ESB Work? 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 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) –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. Event Driven Architecture (EDA) A Subscriber X Y Publisher msg1 msg2 msg1 Subscribe to: msg1 & msg2 Broker

CERN IT-AIS SOAP Interaction Patterns Server Client 1. Request-response (client to server and back) Request Response Client Server 2. Notification-response (server to client and back) Notification Response Server Client 3. One way (from client to server) One way Client Server 3. Notification (from server to client) Notification SOAP supports the following four interaction patterns: 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 SOA –Is not a NEW idea But the pieces are now in place –Facilitates Modular design / architecture Many implementations –Commercial & Open Source

CERN IT-AIS

CERN IT-AIS Thank You For More Information Browse to: or

CERN IT-AIS WS-Security: initial specifications WS-Security: describes how to attach signature and encryption headers to SOAP messages. In addition, it describes how to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages. WS-Policy: will describe the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms, privacy rules). WS-Trust: will describe a framework for trust models that enables Web services to securely interoperate. WS-Privacy: will describe a model for how Web services and requesters state privacy preferences and organizational privacy practice statements. Today In progress WS- SecureConversation WS-FederationWS-Authorisation WS-PolicyWS-TrustWS-Privacy WS-Security SOAP Foundation

CERN IT-AIS WS-Security: follow-on specifications WS-SecureConversation: will describe how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys. WS-Federation: will describe how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities. WS-Authorization: will describe how to manage authorization data and authorization policies Today In progress WS- SecureConversation WS-FederationWS-Authorisation WS-PolicyWS-TrustWS-Privacy WS-Security SOAP Foundation