PRINCIPLES

OF SERVICE

ORIENTATIONPROGRAMAÇÃO DE SISTEMAS

DISTRIBUIDOS

Paulo Gandra de Sousa

pag@isep.ipp.pt

Principles of service design2

ISEP/IPP

Thomas Erl

ISBN: 0132344823

http://www.soaprinciples.com/

http://www.soapatterns.org/

Service Orientation3

Service6

ISEP/IPP

Services are :

Modules of business.

Functionality of application.

The service is successful implemented, when :

reused.

Takes part of compositions

Types of Service8

Entity Services

Utility Services

Task Services

Orchestrated Task Services

Entity Services9

ISEP/IPP

Responsible for processing business logic.

Always take part in automation of business

processes.

May need to compose other services to carry

out its capabilities.

Conventions need to extend to data

representation of business and context

information delivered by messages to ensure

steady interoperability.

Utility Services10

ISEP/IPP

Cross-cutting functionality

Typicaly not business logic related

Sometimes intentionally designed to violate

Service principles

Task Services11

ISEP/IPP

Task-centric services have a functional scope

centered around a business process.

Positioned as composition controllers, and for

significantly sized compositions.

Can be needed to defer context data in order

to alternate between stateful and stateless

conditions.

Orchestrated Task Services12

ISEP/IPP

Manage an activity during its entire lifespan.

Fully expected to remain stateful.

If the duration of process inactivity exceeds a

certain timeout period, state data is stored in a

database until it is needed to be revived.

Granularity13

Service Granularity14

ISEP/IPP

the overall quantity of functionality

encapsulated by a service.

Capability Granularity15

ISEP/IPP

The quantity of functionality encapsulated by a

specific service capability

Data Granularity16

ISEP/IPP

the quantity of data exchanged by a specific

service capability

Constraint Granularity17

ISEP/IPP

The 4 tenets of SOA18

The four tennets of SOA19

ISEP/IPP

Boundaries are explicit

Share schema and contract not types

Policy define service compatibility

Services are autonomous

Boundaries are explicit20

ISEP/IPP

Service boundaries are explicit and the cost of

crossing a boundary is “known”

A boundary is the border between the service

public interface and its internal implementation

Services interact intentionaly and explicitly by

exchanging messages

Share schema and contract not

types21

ISEP/IPP

Services expose schemas defining data

structures and contracts defining available

operations

Contracts and schema may be independently

versioned over time

Policy define service

compatibility22

ISEP/IPP

Policy is the statement of communication

requirements necessary for service interaction

Service capabilities and requirements are

expressed in terms of a policy expression

A policy can contain multiple assertions

Services are autonomous23

ISEP/IPP

Services are independently deployed,

versioned and managed

Topology of a system evolves over time

Unlike OO, services do not share behavior

Services gracefully handle failure

Principles of Service Orientation24

Standardized Contracts

Abstraction

Reusability

Autonomy

Autonomy

Coupling

Statelessness

Standardized Contracts25

Standardized Contracts26

ISEP/IPP

Services within the same service inventory are

in compliance with the same contract design

standards

Contract-first design

Transfromation avoidance

Contract-First Design27

ISEP/IPP

Avoid Transformation

A fundamental goal

of this design

principle is

transformation

avoidance through

the standardization

of data

representation

across service

contracts.

28ISEP/IPP

Service Loose Coupling29

Loose Coupling30

ISEP/IPP

Service contracts impose low consumer

coupling requirements and are themselves

decoupled from their surrounding environment

Service contract coupling31

ISEP/IPP

Service contract coupling

Logic-to-Contract

Coupling

Contract-to-Logic

Coupling

Contract-to-Technology

Coupling

Contract-to-

Implementation Coupling

Contract-to-Functional

Coupling

32ISEP/IPP

Consumer coupling33

ISEP/IPP

Consumer-to-Contract Coupling

Consumer-to-Implementation Coupling

Consumer coupling

Ultimately, undesirable

forms of coupling can

proliferated to the

consumer.

34ISEP/IPP

Service Abstraction35

Service Abstraction36

ISEP/IPP

Service contracts only contain essential

information and information about services is

limited to what is published in service

contracts

Hiding details

Hide as much as

possible

“hidden

composition” issue

service consumer

are unaware that the

service they are

invoking

encapsulates an

entire composition.

37ISEP/IPP

Service Reusability38

Service Reusability39

ISEP/IPP

Services contain and express agnostic logic

and can be positioned as reusable enterprise

resources.

Service Autonomy40

Service Autonomy41

Services exercise a high level of control over their underlying runtime execution environment

Services are independent to dominate there own code executions.

Take decisions independently of the external influences or involvement.

The objective is to:

increase reliability and behavioural predictability

increase reuse and composition of the service

Runtime Autonomy42

ISEP/IPP

the degree of control that a service has over is

own processes invocations and executions.

It affects:

Service execution performance;

Service degree of isolation, reliability and

security;

The prediction of how a service will act;

Design-Time Autonomy43

ISEP/IPP

the degree of freedom that a service owner

has to change the design or architecture, of his

service, over the time.

It helps on:

The scalability of the service;

The update of the “service´s hosting

environment”;

The update or replace the technology used by the

service;

The performance of the Runtime Autonomy;

Service Contract Autonomy

represents independency of the service contract from the code.

The code behaviorcan change but it´s signature on the contract can not.

To help create this, the service contract and code need to be normalized.

45ISEP/IPP

Shared Autonomy

the way in which the

other components

access and compete

for resources of a

service with low or

non-existing

autonomy.

46ISEP/IPP

Service Logic Autonomy

A.k.a. partially isolated services

Represents how isolated and independents services that use the same resources (databases, directories, etc) work with each other.

Issues associated: Difficult to implement

scalability;

Increases slow Runtime and unpredictable behavior

47ISEP/IPP

Pure Autonomy (full isolation)48

ISEP/IPP

represents the full isolation of the entire service that has the control of is own “internal” Runtime.

It has 3 types of isolation:

Functional Isolation – The services are separated, but are hosted in the same server with the same Runtime;

Absolute Isolation – The services are separated physically. Each has its server and Runtime;

Isolated Services at Design-Time – Pure Autonomy gives complete control on the service design, hosting environments and scalability.

Pure Autonomy

Functional isolation Absolute Isolation

49ISEP/IPP

Service Statelessness50

Statelessness51

Services minimize resource consumption by

deferring the management of state information

when necessary

Non-Deferred State

Management 52

ISEP/IPP

Low-to-no statelessness.

Remain active and stateful for continuous

periods.

Does not require an external state deferral

extension

Partially Deferred Memory53

ISEP/IPP

Reduced statefulness.

Generic model of a Web Server.

The service continues active while retaining

some state data.

Partial Deferral State

Management54

ISEP/IPP

Moderate statelessness.

Takes advantage of stateless at certain times.

Not designed to take advantage of every

possible opportunity to become stateless.

Internally Deferred State

Management55

ISEP/IPP

High statelessness

Maximizes its opportunities to exist in a

stateless condition.

Even when stateful, it defers state data when

possible.

Service Discoverability56

Service Discoverability

Services are

supplemented with

communicative meta

data by which they

can be effectively

discovered and

interpreted

57ISEP/IPP

Service Composibility58

Service Composibility59

ISEP/IPP

Services are effective composition

participants, regardless of the size and

complexity of the composition.

the ability to create and provision complex

value added services from other services

resulting in composite services.

60ISEP/I

PP

Service Composition61

ISEP/IPP

Creating a composable

inventory62

ISEP/IPP

Closings63

Service Principles Poster64

ISEP/IPP

http://serviceorientation.com/static/pdf/SOA_Principles_Poster.pdf

Principles of service design65

ISEP/IPP

Thomas Erl

ISBN: 0132344823

http://www.soaprinciples.com/

http://www.soapatterns.org/

References66

SOA Principles of Service Design, Thomas Erl.

Principles of Service design: service patterns

and anti-patterns. John Evdemon (2005)

http://msdn.microsoft.com/en-

us/library/ms954638.aspx

PROGRAMAÇÃO DE

SISTEMAS

DISTRIBUIDOSPaulo Gandra de Sousa

pag@isep.ipp.pt