This document discusses principles of service-oriented architecture (SOA) and service statelessness. It defines service statelessness as services minimizing resource consumption by deferring state management when necessary. This improves scalability and potential for reuse. The document describes different types of state data and state management approaches services can take, ranging from non-deferred internal state management to full external deferral of state to other parts of the architecture like a database. Maximizing statelessness allows services to exist in more scalable stateless conditions as much as possible.

1. Principles OF
SOAFrom knowledge
To practice
SUBMITTED BY : MOHAMED ZAKARYA

2. AGENDA
 Service orientation principles
 Standardized Service Contract
 Service Reusability
 Service Discoverability
 Service Composability
 Service Loose Coupling
 Service Abstraction
 Service Autonomy
 Service Statelessness
 Thanks 

3. PART 1
INTRODUCTION

4. SERVICE ORIENTATION PRINCIPLES
Standardized
Service
Contract
Service
Reusability
Service
Composability
Service
Autonomy
Service
Loose
Coupling
Service
Statelessness
Service
Abstraction
Service
Discoverability

5. SERVICE ORIENTATION PRINCIPLES
Service Reusability
Service contain agnostic logic that can be position as reusable enterprise resource.
Standardized Service Contract
Service in same inventory are in compliance of same design service contract standards.
Service Composition
Services are effective composition participants.
Service Discoverability
Service meta data available for discoverability and interpreted.
Service Loose Coupling
Contract decoupled from surrounding environment.
Service Autonomy
Services exercise a high level of control over their underlying runtime execution environment.
Service Statelessness
Services minimize resource consumption , reduce state information.
Service Abstraction
Contract contains only essential information , that is published to consumers.

6. PART 1
SERVICE
STATLESSNESS

7. INTRODUCTION
Service Statelessness
Services minimize resource consumption , reduce state information.
Purpose :
To maximize service scalability ,
services and their surrounding architecture can be
designed to support the delegation and
deferral of state management responsibilities

8. EXAMPLE
State refers to general condition of something.
A car that is moving is in a state of motion ( active) ,
whereas a car that is not moving is in a stationary state ( passive)
Software program can also have and transition
through different states usually because of its involvement in a runtime activity.

9. STATE CONDITIONS / DATA TYPES
Each state can be represented and described by data that has lifespan
equivalent to duration at which program remains active
state management can be considered management of temporary, activity-specific data.

10. PRIMARY STATE ( ACTIVE / PASSIVE )
Two basic states a car was capable of having: in motion and stationary.
Active state
Service being invoked or executed and therefore entering an active state.
Passive state
Period during which service is not in use. Exists in a passive or [non-active] state.

11. PRIMARY STATE CONDITIONS ( STATEFUL , STATELESS )
There are types to represent specific state of active conditions [runtime condition of a service]
stateless state (idle condition)
Active service but may not be engaged in processing of state data
EX : http protocol when server respond to requested web page
stateful state
Service that is actively processing or retaining state data

12. TYPE OF STATE INFORMATION ( SESSION / CONTEXT / BUSINESS)
State data is information primarily associated with a current activity,
Business
 information related to business task currently executing.
 EX : records return from database query stored in memory
for future needs
Context
 Information about a particular service activity
 The larger complex a service composition, the more context
information will generally need to be managed
 Types : context data and context rules (work flow rules)
Session
 Represents information associated with retaining a connection made
between a program and its client program
 Ex : web site session

13. CONTEXT TYPES
Context rule
Protocols and constraints applied to the execution of a specific
[Service activity Workflow rules that govern processing of activity]
EX :
 Allowable duration of the service activity
 Allowable quantity of service activity instances
 Allowable quantity of participating services
Context data
Information beyond service and considered as part of a current service activity
EX :
 Quantity of services currently participating in an activity
 Which services are currently active and which were active in
the service activity
 The duration of the service activity
 How many instances of the activity are currently in execution

14. ORIGIN OF STATE MANAGEMENT (TWO-TIER)

15. ORIGIN OF STATE MANAGEMENT ( THREE TIER)

16. ORIGIN OF STATE MANAGEMENT ( THREE TIER)
Concurrently accessed server-side program becoming a performance bottleneck is very real

17. ORIGIN OF STATE MANAGEMENT
A separate database positioned as a state management deferral extension of the architecture

18. SERVICE ORIENTATION AND STATE MANAGEMENT
service-orientation places on reuse, state management becomes a greater concern.

19. DEFERRAL VS. DELEGATION
Deferral
The temporary relocation of state information is referred to as state deferral
Delegation
To accomplish state management deferral we temporarily delegate this responsibility
to another part of the architecture (such as a database).
Therefore, we achieve state management deferral through temporary and periodic
state management delegation.

20. ABOUT THE PRINCIPLE
Title
Services minimize statefulness
Description
Services minimize resource consumption by deferring the management of state information
when necessary.
Goals
Implementation requirements
Performance demands associated with runtime retrieval and interpretation of deferred state data.
Increase service scalability.
Improve the potential for service reuse.

21. STATE MANAGEMENT DEFERRAL SAMPLE TYPES
Non-Deferred State Management (low-to-no statelessness)
Partially Deferred Memory (reduced statefulness)
Partial Architectural State Management Deferral (moderate statelessness)
Full Architectural State Management Deferral (high statelessness)
Internally Deferred State Management (high statelessness)

22. 1. NON-DEFERRED STATE MANAGEMENT (LOW-TO-NO STATELESSNESS)
 Increased amount of state management processing can inhibit scalability
 Remain active for the duration of its participation in the overall activity
 Service does not require an external state deferral extension
 Service does not form a direct dependency on its surrounding architecture.

23. 2. PARTIALLY DEFERRED MEMORY (REDUCED STATEFULNESS)
 Service capability can be designed to defer state data without having to switch
between stateless and stateful conditions.
 Designed to off-load portions of this data during periods where the data is not required.
 Typically deferred business data , retain context data and session data

24. 3. PARTIAL ARCHITECTURAL STATE MANAGEMENT DEFERRAL
 During longer running activities,
 service will be transitioned into stateless modes during these gaps of inactivity
 service is not designed to take advantage of every possible opportunity to become stateless

25. 4. FULL ARCHITECTURAL STATE MANAGEMENT DEFERRAL
 The service capabilities are designed to maximize any reasonable opportunity to become stateless
 Off-load state information (primarily context and business data) while stateful whenever possible
is also leveraged

26. 5. INTERNALLY DEFERRED STATE MANAGEMENT
 Achieved the absolute isolation level of pure autonomy
[Service environment is isolated and firmly in our control] .. (isolated services)
 Internal state deferral option. This is commonly implemented via a dedicated database
that the service can use to store and retrieve temporary activity data
 Maximize its existence in a stateless condition.

27. REFERENCES
http://www.soaschool.com/
http://serviceorientation.com/index.php/soaglossary/index
http://soapatterns.org/
http://www.servicetechmag.com/
http://www.soaschool.com/certifications
http://www.servicetechbooks.com/

28. ANY QUESTIONS

29. THANKS
ENJOY SOA .. WAIT FOR NEXT
MAIL: ENG.MOHAMEDZAKARYA@GMAIL.COM