1. PRINCIPLES
OF SERVICE
ORIENTATION
PROGRAMAÇÃO DE SISTEMAS
DISTRIBUIDOS
Paulo Gandra de Sousa
pag@isep.ipp.pt

2. Principles of service design
2
ISEP/IPP
 Thomas Erl
 ISBN: 0132344823
 http://www.soaprinciples.com/
 http://www.soapatterns.org/

3. 3 Service Orientation

4. Service
6
ISEP/IPP
 Services are :
 Modules of business.
 Functionality of application.
 The service is successful implemented, when :
 reused.
 Takes part of compositions

5. Types of Service
8
 Entity Services
 Utility Services
 Task Services
 Orchestrated Task Services

6. Entity Services
9
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.

7. Utility Services
10
ISEP/IPP
 Cross-cutting functionality
 Typicaly not business logic related
 Sometimes intentionally designed to violate
Service principles

8. Task Services
11
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.

9. Orchestrated Task Services
12
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.

10. 13 Granularity

11. Service Granularity
14
ISEP/IPP
 the overall quantity of functionality
encapsulated by a service.

12. Capability Granularity
15
ISEP/IPP
 The quantity of functionality encapsulated by a
specific service capability

13. Data Granularity
16
ISEP/IPP
 the quantity of data exchanged by a specific
service capability

14. Constraint Granularity
17
ISEP/IPP

15. 18 The 4 tenets of SOA

16. The four tennets of SOA
19
ISEP/IPP
 Boundaries are explicit
 Share schema and contract not types
 Policy define service compatibility
 Services are autonomous

17. Boundaries are explicit
20
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

18. Share schema and contract not
types
21
ISEP/IPP
 Services expose schemas defining data
structures and contracts defining available
operations
 Contracts and schema may be independently
versioned over time

19. Policy define service
compatibility 22
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

20. Services are autonomous
23
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

21. Principles of Service Orientation
24
 Standardized Contracts
 Abstraction
 Reusability
 Autonomy
 Autonomy
 Coupling
 Statelessness

22. 25 Standardized Contracts

23. Standardized Contracts
26
ISEP/IPP
 Services within the same service inventory are
in compliance with the same contract design
standards
 Contract-first design
 Transfromation avoidance

24. Contract-First Design
27
ISEP/IPP

25. Avoid Transformation
 A fundamental goal
of this design
principle is
transformation
avoidance through
the standardization
of data
representation
across service
contracts.
28
ISEP/IPP

26. 29 Service Loose Coupling

27. Loose Coupling
30
ISEP/IPP
 Service contracts impose low consumer
coupling requirements and are themselves
decoupled from their surrounding environment

28. Service contract coupling
31
ISEP/IPP

29. Service contract coupling
 Logic-to-Contract
Coupling
 Contract-to-Logic
Coupling
 Contract-to-Technology
Coupling
 Contract-to-
Implementation Coupling
 Contract-to-Functional
Coupling
32
ISEP/IPP

30. Consumer coupling
33
ISEP/IPP
 Consumer-to-Contract Coupling
 Consumer-to-Implementation Coupling

31. Consumer coupling
 Ultimately, undesirable
forms of coupling can
proliferated to the
consumer.
34
ISEP/IPP

32. 35 Service Abstraction

33. Service Abstraction
36
ISEP/IPP
 Service contracts only contain essential
information and information about services is
limited to what is published in service
contracts

34. Hiding details
 Hide as much as
possible
 “hidden
composition” issue
 service consumer
are unaware that the
service they are
invoking
encapsulates an
entire composition.
37
ISEP/IPP

35. 38 Service Reusability

36. Service Reusability
39
ISEP/IPP
 Services contain and express agnostic logic
and can be positioned as reusable enterprise
resources.

37. 40 Service Autonomy

38. Service Autonomy
41
 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

39. Runtime Autonomy
42
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;

40. Design-Time Autonomy
43
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;

41. Service Contract Autonomy
 represents
independency of the
service contract from
the code.
 The code behavior
can change but it´s
signature on the
contract can not.
 To help create this,
the service contract
and code need to be
normalized.
45
ISEP/IPP

42. Shared Autonomy
 the way in which the
other components
access and compete
for resources of a
service with low or
non-existing
autonomy.
46
ISEP/IPP

43. 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
47
ISEP/IPP

44. 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.

45. Pure Autonomy
 Functional isolation  Absolute Isolation
49
ISEP/IPP

46. 50 Service Statelessness

47. Statelessness
51
 Services minimize resource consumption by
deferring the management of state information
when necessary

48. 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

49. Partially Deferred Memory
53
ISEP/IPP
 Reduced statefulness.
 Generic model of a Web Server.
 The service continues active while retaining
some state data.

50. Partial Deferral State
Management 54
ISEP/IPP
 Moderate statelessness.
 Takes advantage of stateless at certain times.
 Not designed to take advantage of every
possible opportunity to become stateless.

51. Internally Deferred State
Management
55
ISEP/IPP
 High statelessness
 Maximizes its opportunities to exist in a
stateless condition.
 Even when stateful, it defers state data when
possible.

52. 56 Service Discoverability

53. Service Discoverability
 Services are
supplemented with
communicative meta
data by which they
can be effectively
discovered and
interpreted
57
ISEP/IPP

54. 58 Service Composibility

55. Service Composibility
59
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.

56. 60
ISEP/I
PP

57. Service Composition
61
ISEP/IPP

58. Creating a composable
inventory 62
ISEP/IPP

59. 63 Closings

60. Service Principles Poster
64
ISEP/IPP
http://serviceorientation.com/static/pdf/SOA_Principles_Poster.pdf

61. Principles of service design
65
ISEP/IPP
 Thomas Erl
 ISBN: 0132344823
 http://www.soaprinciples.com/
 http://www.soapatterns.org/

62. References
66
 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

63. PROGRAMAÇÃO DE
SISTEMAS
DISTRIBUIDOS
Paulo Gandra de Sousa
pag@isep.ipp.pt