principles of service orientation
TRANSCRIPT
PRINCIPLES
OF SERVICE
ORIENTATIONPROGRAMAÇÃO DE SISTEMAS
DISTRIBUIDOS
Paulo Gandra de Sousa
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
