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.
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
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
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
27. Loose Coupling
30
ISEP/IPP
Service contracts impose low consumer
coupling requirements and are themselves
decoupled from their surrounding environment
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
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.
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.
53. Service Discoverability
Services are
supplemented with
communicative meta
data by which they
can be effectively
discovered and
interpreted
57
ISEP/IPP
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.
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
Anything that connects has coupling and coupled things can form dependencies on each other.
The primary focus of this principle is on the relationship between the service contract and whatever the service encapsulates.
Ultimately, any undesirable forms of coupling allowed into the service contract design end up being imposed on and proliferated through all consumers of the service.
A service can be active but may not be engaged in the processing of state data. In this idle condition, the service is considered to be Stateless.
(no direct dependency on its surrounding architecture).
