Service-Oriented Architectures

(1)

Service-Oriented Architectures

Service-Oriented Computing & Web Services

2009-11-06

P-O Östberg

Department of Computing Science, Umeå University

(2)

Today Service-Oriented Computing (SOC) Service-Oriented Architectures (SOA) Web Services Next

Service-Oriented Computing (SOC)

Service-Oriented Architectures (SOA)

Web Services

(3)

Service-Oriented Computing (SOC)

I A new computing paradigm revolving around the concept of software as a service

I Assumes that entire systems of software are built and deployed as network-accessible services

I Focus is placed on the utility of software components, rather than on mechanisms of software

I The value of an application is measured by it’s ability to integrate into it’s environment rather than it’s functional capabilities

Service-Oriented Architectures P-O Östberg

(4)

Software as a Service

I A service is a piece of well-defined functionality that is – available at some network endpoint

– accessible via various transport protocols and serialization formats

– always on (no construction & destruction semantics) I Focus is placed on the utility of services

(5)

SOC Software Requirements

I Technology neutral

– use widely available, standardized technology I Loosely coupled

– minimize formal knowledge required to use a service I Location transparent

– be publicly discoverable

– provide QoS regardless of location of service or clients

(6)

Service-Oriented Architectures (SOA)

I An architectural style used in Service-Oriented Computing

I SOA models service actors and relations & interactions between service actors

I Well-designed SOAs provide

– flexibility in design and deployment – adaptability and integrability in architecture – scalability in implementation and deployment I SOAs build complete systems using services as

distributed and modularized components without regard to service implementation

I (Composite) applications are built by discovering,

(7)

SOA Actors

I Service providers

– provide service implementations – supply service descriptions – provide service support I Service registries

– provide (publicly accessible) service information sources – houses service meta-information (service description,

service location, service cost metrics, etc) I Service clients

– use service functionality

– may be individual end-users, organizations, or services I Service aggregators

– aggregate services into new services – act as brokers and value-add providers

(8)

SOA Operations

I Publication of service description – construction of service descriptions

– publishment of service descriptions in service registry I Service selection

– location of service descriptions

– selection of a suitable subset of available services I Service invocation

– service invocation semantics establishment (from WSDL) – service invocation

(9)

SOA Operations

(10)

Services as a Virtualization Technology

I Services can be used without having to worry about – service discovery

– service selection – data exchange formats – service implementation details I Services can be aggregated

– similar services can be hidden behind a common (adapter) interface

– services can act as brokers to other services

(11)

Service Usage Patterns

I Service aggregation

– building applications and logical services by utilizing capabilities offered by services

– includes creating adapter interfaces to groups of services and service capability brokering

I Service composition

– constructing services by combining existing services I Service orchestration

– creating applications by coordinated use of services – focuses on message-level interactions and control flows

for individual services I Service choreography

– defines workflows for interactions between services – describes system-wide collaborations and interactions in

terms of message exchanges

(12)

Service Interfaces & Orchestration

(13)

Layered SOAs

I SOA projects are often large, involving multiple, disparate organizations and heterogeneous system views

I SOA deployments will often involve physical and virtual resources owned by multiple parties, and incorporation of various legacy systems

I To modularize designs and address these issues, SOA systems are often segmented into layers, where working groups collaborate to create limited functionality sets

I Layered designs work by principle of abstraction, hiding complex functionality and providing customized interfaces in higher layers

I Applications are typically integrated at high (interface) level rather than a low (implementation) level

(14)

Layered SOAs

(15)

Quality of Service (QoS)

I QoS refers to the ability of the Web Service to respond to expected invocations and to perform them at the level commensurate with the mutual expectations of both it’s provider and it’s customers.

I Delivering QoS on the Internet is a critical and significant challenge because of it’s dynamical and unpredictable nature.

(16)

Service-Level QoS

I Availability

I Accessability

I Conformance to standards

I Integrity

I Performance

I Reliability

I Scalability

I Security

I Transactionality

(17)

Service-Level Agreements (SLA)

I An SLA is a formal agreement (contract) between provider and client, formalizing the details of a service (e.g., content, price, delivery, quality, etc, usually in measurable terms) in a way that meets mutual understandings and expectations of all parties involved.

I SLAs can be static or dynamic, where the latter adapts to current service provisioning

(18)

Service-Level Agreements (SLA)

I Purpose

I Parties

I Validity

I Scope

I Restrictions

I Service-level objectives

I Penalties

I Optional services

I Exclusion terms

(19)

Service Interface vs Implementation

I Service interface

– describes the service operation semantics – (the only part) visible to clients

– should be language, platform, and technology neutral – may be designed and standardized by external parties I Service implementation

– realizes a concrete instantiation of a service – may be realized using any technology as long as it

adheres to the interface specification

– may be implemented by other organizations than the interface designers

(20)

Service vs Web Service

I Service: A software component accessed over a network that provides functionality to a service requester

I Web Service: A service which publishes a service interface in WSDL and uses a message-driven transport protocol (usually via SOAP / REST over HTTP)

I Web Services are built using a host of XML-based technologies

– XML (data exchanged)

– XML Schema (validation of data exchanged) – SOAP (XML-serialized transfer protocol)

– WSDL (Web Service interface description, XML Schema)

(21)

Web Service Characteristics

I Platform-independent

– Service implementations realized using any platform – Interfaces and data expressed in XML

I Loosely coupled

– Service implementations hidden behind interfaces – Services explicitly self-describing and discoverable I Self-contained

– Service dependencies abstracted by other services I Self-describing

– Interface description provides invocation data – - " - and service registries provide semantic metadata I Use wide-spread and reliable technology base

– XML, SOAP, WSDL, HTTP

I Designed to provide a universal IPC mechanism

(22)

Types of Web Services

I Simple services

– aka informational services

– provide service interfaces to software modules – tend to provide complete fine-grained operations – tend to be stateless

– tend to communicate using request-response patterns I Complex services

– aka business processes

– aggregate, compose, or invoke other services – tend to provide coarse-grained, multi-step service

operations (e.g., event / notification-based state updates) – tend to be stateful

(23)

Simple vs Complex Web Services

(24)

Service Properties

I Functional service properties

– details service operational characteristics – e.g., message syntax

– e.g., service location

– e.g., service invocation protocol I Non-Functional service properties – details service quality attributes – e.g., service performance metrics – e.g., security models supported

– e.g., service scalability meta-information

(25)

Loose Coupling

I Coupling is a measure of the degree of dependencies

I Tightly coupled systems

– require knowledge of how peers behave

– requires agreement and shared contexts for interoperation – ties interfaces into other system interfaces

– makes maintenance and development complex – small changes likely to affect other modules I Loosely coupled systems

– minimizes knowledge required for interoperation – focuses on autonomicity of software modules

– provides agility and ability to survive evolutionary changes – tend to use asynchronous communication models

(loose coupling in time)

– tend to have coarse-grained communication patterns (document style interaction)

(26)

Tight vs Loose Coupling

Tight coupling Loose coupling Interaction pattern Synchronous Asynchronous Message style RPC style Document style Message path Hard coded Routed

Underlying platform Homogeneous Heterogeneous Binding protocol Static Dynamic (late binding) Objective Reuse Flexibility, applicability

(27)

Web Services vs Component Models

Components Web Services Granularity fine-grained coarse-grained

Communication synchronous synchronous / asynchronous Endpoint coupling tight, API-based loose, interface-based Infrastructure homogeneous heterogeneous Interface object level wire format level Invocation explicit naming capability listing Request brokering static static / dynamic

(28)

Web Service Technology Stack

(29)