1 Introduction to SOA

2 The Service-Oriented Enterprise eXtensible Markup Language (XML) Web services XML-based technologies for messaging, service description, discovery, and extended features. Service-oriented architecture (SOA) A methodology for achieving application interoperability and reuse of IT assets. Business process management (BPM)

3 Service-Oriented Development A service is defined by the messages it exchanges with other services. Benefits of service-oriented development Reuse: services for reuse Efficiency: to quickly and easily create new services and applications Loose technology coupling: independent to execution environment Division of responsibility: separation of concerns between the business analysts and service developers

4 What is SOA? A style of design that guides all aspects of creating and using business services A way to define and provision an IT infrastructure to allow different applications to exchange data and participate in business process Business services are the key organizing principle Service orientation focuses on the description of the business problem Cleanly and completely separate, by interpreting a text file, a service description from its execution environment

5 Web Services Web services are pervasive, simple, and platform- neutral. The provider publishes a WSDL description of its Web service. The requester accesses the description using a UDDI registry and requests the service by sending a SOAP message. Registry RequesterProvider SOAP UDDI WSDL

6 Primary Service Characteristics Loosely coupled Interface coupling Technology coupling Process coupling A well-defined interface (or service contract) Define the service’s capabilities and how to invoke the service Separate the externally accessible interface from the implementation

7 Primary Service Characteristics (cont.) Meaningful to service requesters Capture the essence of the business service without restricting future reuse Use a business-oriented vocabulary Avoid exposing technical details Standards-based Services should be based on open standards as much as possible

8 Secondary Service Characteristics Predictable service-level agreements SLA defines response time, throughput, availability, etc. Dynamic, discoverable, metadata-driven Services can be discovered and consumed without intervention of the provider. The interface should use metadata to define service capabilities and constraints. The interface should be machine-readable so that they can be dynamically registered and discovered.

9 Secondary Service Characteristics (cont.) Design service contracts with related services in mind Design the service-level data model (or the XML Schema definition of the documents) and all of the related interfaces together Implementation independent of other services Consider the need for compensating transactions A compensating transaction can undone a completed transaction by canceling its results.

10 Secondary Service Characteristics (cont.) Design for multiple invocation styles If forced to choose one, choose asynchronous queuing Stateless Design services with performance in mind Service invocations should NOT be treated like local function calls Avoid fine-grained services

11 Object Reuse vs. Service Reuse Building objects is easy Building high-quality, reusable objects is hard Reusing object libraries and object frameworks is moderately hard Building Web services is easy Building high-quality, reusable business services is hard Reusing business services is relatively easy

12 Too Much Reuse? A highly reusable service The interface for the data access service accepts a SQL query as input and returns an XML structure as the result. It violates SOA’s loose-coupling principle The service requester needs to know about how the data is stored and the structure of data. Expensive maintenance problem.