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: ENG.MOHAMEDZAKARYA@GMAIL.COM