Service-Oriented Architectures

1. Service-Oriented Architectures Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

2. outline • What is SOA. • Perspective, Evolution, SOA v/s Traditional Architecture • Key Concepts • Differences between SOA and UDDI (UDDI vs SOA) • Elements of SOA, SOA ERD Model • Service-Oriented Architecture (SOA) Style • What is a service, service characteristics, service interface, and service types • The Enterprise Service Bus ESB • Business Processes Management

3. What is SOA?A Business Perspective • SOA is the application of well-founded concepts which exploit the modern ability for system resources to • Collaborate independent of location • Across Heterogeneous technologies • A set of architectural principles backed by technology to tap into system resources to freely participate in a larger community • Provide tools and techniques to orchestrate the reuse of these newly available resources into processes that drive the business.

4. What is SOA?A Technical Perspective • A Service Oriented Architecture is a collection of self-contained services that can communicate with each other. • Key characteristics of services: • loosely coupled • coarse grained • typically published & available for invocation on a Service Bus • Defining services at a “business level” enables rapid composition of end-to-end business processes, delivering on the promise of greater IT flexibility and agility

5. The Evolution… From Three-Tier Applications Databases Presentation Layer Application Application Application Business Layer

6. The Evolution to:SOA-Based Applications Service Components Process #1 Databases Presentation Process #2 Process #3

7. Functionality Driven Process Oriented Service Oriented Architecture Traditional Architecture Designed to last Designed for change  Long development cycles Iterative development  Tightly Coupled Loosely Coupled  Application Specific Heterogeneous  Data Oriented Business Service Oriented   SOA v/s Traditional Architecture Calls for a Paradigm Shift But must be built on standards to enhance interoperability

8. Service-Oriented Architecture: Key Concepts

9. Differences between SOA and UDDI UDDI vs SOA • What is UDDI? • UDDI is a platform-independent framework for describing services, discovering businesses, and integrating business services by using the Internet. • UDDI stands for Universal Description, Discovery and Integration • UDDI is a directory for storing information about web services • UDDI is a directory of web service interfaces described by WSDL (Web Services Description Language) • UDDI communicates via SOAP (Simple Object Access Protocol, ) • UDDI is built into the Microsoft .NET platform

10. UDDI vs SOA • What is UDDI Based On? • UDDI uses World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) Internet standards such as XML, HTTP, and DNS protocols. • UDDI uses WSDL to describe interfaces to web services • Web Services Description Language (WSDL) is an XML grammar that defines the functionality offered by a Web service and the format of messages sent and received by a Web service. • Additionally, cross platform programming features are addressed by adopting SOAP, known as XML Protocol messaging specifications found at the W3C Web site.

11. UDDI vs SOA: UDDI Architecture Another View UDDI registry look for service in UDDI registry retrieve provider location and WSDL service description publish services in registry requester provider bind and send request via SOAP/http or other transport to provider create request from WSDL description It was assumed that fully automated agents (request entities) could perform lookups and use services thereby executing business tasks.

12. UDDI vs SOA:Why UDDI Could Not Work • central registries of service descriptions • independent automatic agents searching for services • machines understanding service descriptions • machines deciding on service use • machines being able to use a service properly • machines being able to construct advanced workflows (i.e., bussiness processes) from different services Even if you replace machines with human beings (e.g. for the service decision) UDDI does not work: Too much in services is ambiguous, undefined or expressed in different and incompatible terms – not to forget that the service interface use (order of calls, meaning of datatypes etc.) is undefined as well.

13. Security Quality of Service Management WS Stack based on UDDI Service Flow WSFL Service Discovery UDDI Service Publication UDDI Service Description WSDL XML-based Messaging SOAP HTTP, FTP, MQ Email, IIOP Network 6/3/2014 13

14. UDDI vs SOA: Missing Technology Behind UDDI Understanding and matching of constraints Meaning of data types and interfaces Ontologies policies Autonomous Agent Business Process Exectution Languages Meaning of actions Business Domain knowledge Trust Establishment Understanding Flows and Goals Risk create request from WSDL description Important to remember: business languages which standardize business terms like contract, sale, customer etc. Generally speaking a ton of meta-data where missing. Webservices (WSDL, SOAP) merely covered the mechanics of message exchange.

15. Elements of SOA • Services offer high-level, business type interfaces • Service Choreography (aka workflow) is performed outside services which allows the combination of services into larger business processes • A set of semantic standards and technologies allows agents to understand services and their interfaces (OWL, SAML, Semantic Web etc.) • Legacy applications will be wrapped through a service interface and become available to other companies • SOA will use Web Service technology as its base

16. SOA Elements Model This diagram from „Web Services Architecture“ shows internal and external elements of the SOA architecture. Action e.g. is not an externally visible element. Note the important roles of „policy“ and „semantics“

17. Another Simplified Model Policy Adheres to governed by End Point Binds to Exposes Serves Service Consumer Contracts Service Understands implements describes Key Component Messages Sends/Receives Sends/Receives Relation

18. outline • What is SOA. • Perspective, Evolution, SOA v/s Traditional Architecture • Key Concepts • UDDI vs SOA • Elements of SOA, SOA ERD Model • Service-Oriented Architecture (SOA) Style • What is a service, service characteristics, service interface, and service types • The Enterprise Service Bus ESB • Business Processes Management

19. Service Oriented Architecture (SOA) Style:An Architecture Style • Service-Oriented Architecture (SOA) is an architectural style. • Applications built using the SOA style deliver functionality as services that can be used or reused when building applications • SOA uses open standards to integrate software assets as services • It provides a standard form of interactions of services

20. Process Services Business Logic Orchestration System BPM A Map of SOA Components Web Portals Human Business Process Management (BPM) Security Manage and monitor Registry and Repository Enterprise Service Bus (ESB) Data Services Systems of Record Databases

21. Banking Examples of SOA Internet Banking Business Process: Stop Payment Registry and Repository: Find Stop Payment Service, Charge Fee service Security: Authenticate user Manage and monitor ESB: Routes to appropriate core system Data Services Process Services Business Logic: If Customer_Status = Gold Service_Fee = $8 else Service_Fee = $20 Orchestration: DDA / Current Account Fee database

22. Place customer orders: 1. Basic Data Service – access operations, 2. Composed Services - business logic, 3. Process Services – complex business logic

23. A Unified Patience Journal System

24. Service Oriented Architecture (SOA) Style: • SOA services become the building blocks that form business flows • Services can be reused by other applications • What is a service? • A service provides a discrete business function that operates on data. Its job is to ensure that the business functionality is applied consistently, returns predictable results, and operates within the quality of service required.

25. Service Oriented Architecture (SOA) Style: • What is a service? • A service is a reusable component that can be used as a building block to form larger, more complex business-application functionality. • A service may be as simple as “get me some person data,” or as complex as “process a disbursement.”

26. Service Oriented Architecture (SOA) Style: • Characteristics of a Service • Supports open standards for integration: Although proprietary integration mechanisms may be offered by the SOA infrastructure, SOA’s should be based on open standards. • Open standards ensure the broadest integration compatibility opportunities • Loose coupling: provides well defined interfaces to clients • Stateless: The service does not maintain state between invocations. If a transaction is involved, the transaction is committed and the data is saved to the database.

27. Service Oriented Architecture (SOA) Style: • Characteristics of a Service • Location agnostic: Users of the service do not need to worry about the implementation details for accessing the service. The SOA infrastructure will provide standardized access mechanisms with service-level agreements.

28. SOA Design Business Object Business Object Business Service Component Component Choreography Service Service This diagram is modelled after O.Zimmermann et.al. „Elements of a Service-Oriented Analysis and Design“. The paper also shows nicely how flow oriented a SOA really is and that a class diagram does not catch the essence of SOA. A state-diagram performs much better. The authors also note that SOA is process and not use-case driven design.

29. Interface Design • Object interface: accepts transactions, fast, Object references • Component interface: value objects, relatively fast. Mostly stateless. • Service interface: long running transactions with state in DB. Composable to larger services (choreography) or composed of smaller services (orchestration). Stateless. Only objects (classes) are programming language constructs. But a detailed look at the interfaces reveals that component and service type interfaces are just different types of the interface model.

30. SOA Blueprint Service Types • Basic Service: atomic operation on a simple object (e.g. DB-access) • Composite Service: atomic, uses several basic services (orchestration), stateless for caller. • Workflow Service: Stateful, defined state changes (state kept in persistent store) • Data Service: Information integration via message based request/response mechanism. • Pub/Sub Service: typical event service with callbacks and registration. • Service Broker: Intermediate, rule based message manipulation and forwarding • Compensation Service: revert actions (not rollback like)

31. Service Oriented Architecture (SOA) Style: Makes use of an Enterprise Service Bus ESBUsed in web-based systems and distributed computing The SOA Style Before SOA nodes make resources available to other participants in the system as independent services that the participants access in a standardized way using the ESB

32. Legacy Integration

33. SOA Integration

34. Service Oriented Architecture (SOA) Style: The Enterprise Service Bus ESB • An enterprise service bus is an infrastructure used for building compound applications Similar to the Software Bus in a CORBA based distributed application architecture • The enterprise service bus is the glue that holds the compound application together • The enterprise service bus is an emerging style for integrating enterprise applications in an implementation-independent fashion • An enterprise service bus can be thought of as an abstraction layer on top of an Enterprise Messaging System

35. Service Oriented Architecture (SOA) Style: The Enterprise Service Bus ESB • Characteristics of an ESB • Streamlines development • Supports multiple binding strategies • Performs data transformation • Intelligent routing • Real time monitoring • Exception handling • Service security

36. Service Oriented Architecture (SOA) Style: The Enterprise Service Bus ESB Functions • Invocation • Synchronous and asynchronous transport protocols, service mapping (locating and binding) • Routing • Addressability, static/deterministic routing, content-based routing, policy-based routing • Mediation • Adapters, protocol transformation, service mapping • Messaging • Message processing, message transformation and message enhancement

37. The ESB Boundaries The ESB (in its simplest form) is responsible for getting a message from point A to point B.

38. Get the Message on the Bus A binding component “speaks” the service’s protocol, which happens to be SOAP over JMS.

39. Perform the Person Read The request is now routed to the Get Person Data Service, which will perform the business logic.

40. Do the SSIM Lookup A call is made to the SSIM service to perform a lookup of the Student Identifier (SID). The SSIM service lives inside the bus. Note: The SSIM binding components are not shown so the diagram can remain simple.

41. Return the Person Data The process is reversed, returning the response to the requester.

42. Defining the Message • Web Services Description Language • Open Standard for describing Interfaces to Services (http://www.w3.org/TR/wsdl) • Characteristics • Describes data expected to be sent and received • Describes what the service can do • Describes how to reach the service • WSDL description is an XML document

43. Message-Exchange Patterns • One-way. The endpoint receives a message. • Request-response. The endpoint receives a message, and sends a correlated message. • Solicit-response. The endpoint sends a message, and receives a correlated message. • Notification. The endpoint sends a message.

44. The Ingredients The XSD is the XML schema definition For variables`

45. outline • What is SOA. • Perspective, Evolution, SOA v/s Traditional Architecture • Key Concepts • Differences between SOA and UDDI (UDDI vs SOA) • Elements of SOA, SOA ERD Model • Service-Oriented Architecture (SOA) Style • What is a service, service characteristics, service interface, and service types • The Enterprise Service Bus ESB • Business Processes Management • Business Processes Flow, Business Process Execution Language (BPEL), BPELJ, JBoss jBPM, jPDL • The IBM Rational Software Development Platform

46. Business Processes • Business processes are a set of activities, supported by services, that support a particular business activity. • Business processes are business services built using other business services. • Business Process Execution Language (BPEL) is a specification for describing business processes in a portable XML format. BPEL is widely supported in both commercial and open source products. • BPEL defines how services interact to form complex business process. It provides a unit of work context, fault handling, and compensation (transaction rollback).

47. Legacy Business Process

48. Example of a Business Process

49. The Shipping Workflow

50. Grouping services