SOA Principles : 8. service statelessness
-
Upload
mohamed-zakarya -
Category
Technology
-
view
6 -
download
1
Transcript of SOA Principles : 8. service statelessness
Principles OF
SOA From knowledge To practice
SUBMITTED BY : MOHAMED ZAKARYA
AGENDA
Service orientation principles
Standardized Service Contract Service Reusability Service Discoverability Service Composability Service Loose Coupling Service Abstraction Service Autonomy Service Statelessness Thanks
PART 1
INTRODUCTION
SERVICE ORIENTATION PRINCIPLES
Standardized Service
Contract
ServiceReusability
ServiceComposability
ServiceAutonomy
Service Loose
Coupling
Service Statelessness
ServiceAbstraction
ServiceDiscoverability
SERVICE ORIENTATION PRINCIPLES
Service ReusabilityService contain agnostic logic that can be position as reusable enterprise resource.
Standardized Service ContractService in same inventory are in compliance of same design service contract standards.
Service CompositionServices are effective composition participants.
Service DiscoverabilityService meta data available for discoverability and interpreted.
Service Loose CouplingContract decoupled from surrounding environment.
Service AutonomyServices exercise a high level of control over their underlying runtime execution environment.
Service StatelessnessServices minimize resource consumption , reduce state information.
Service AbstractionContract contains only essential information , that is published to consumers.
PART 1
SERVICE
STATLESSNESS
INTRODUCTION
Service StatelessnessServices minimize resource consumption , reduce state information.
Purpose :
To maximize service scalability ,
services and their surrounding architecture can bedesigned to support the delegation anddeferral of state management responsibilities
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 transitionthrough different states usually because of its involvement in a runtime activity.
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.
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.
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 dataEX : http protocol when server respond to requested web page
stateful state Service that is actively processing or retaining state data
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
CONTEXT TYPES
Context ruleProtocols 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 dataInformation 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
ORIGIN OF STATE MANAGEMENT (TWO-TIER)
ORIGIN OF STATE MANAGEMENT ( THREE TIER)
ORIGIN OF STATE MANAGEMENT ( THREE TIER)
Concurrently accessed server-side program becoming a performance bottleneck is very real
ORIGIN OF STATE MANAGEMENT
A separate database positioned as a state management deferral extension of the architecture
SERVICE ORIENTATION AND STATE MANAGEMENT
service-orientation places on reuse, state management becomes a greater concern.
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.
ABOUT THE PRINCIPLE
TitleServices minimize statefulness
DescriptionServices minimize resource consumption by deferring the management of state information when necessary.
Goals
Implementation requirementsPerformance demands associated with runtime retrieval and interpretation of deferred state data.
Increase service scalability.
Improve the potential for service reuse.
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)
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.
2. PARTIALLY DEFERRED MEMORY (REDUCED STATEFULNESS)
Service capability can be designed to defer state data without having to switchbetween 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
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
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
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.
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/
ANY QUESTIONS
THANKSENJOY SOA .. WAIT FOR NEXT
MAIL: [email protected]