soa princples : 7. service autonomy

Post on 13-Apr-2017

15 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

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

AUTONOMY

INTRODUCTION

Service AutonomyServices exercise a high level of control over their underlying runtime execution environment.

Autonomy represents the ability to self-govern.

Something that is autonomous has the freedom and control to make its own decisions without the need for external approval or involvement.

Level of control = Level of autonomy.

ABOUT THE PRINCIPLE

TitleServices are autonomous.

DescriptionServices exercise a high level of control over their underlying runtime execution environment

Goals

Increase runtime reliability Increase predictability , performance

Increase control over runtime environment

Increase post-implementation control over the service

Implementation reequipments Distributable deployment environment, to allow service to be moved, isolated, or composed as required.

TYPES OF SERVICE AUTONOMY

Run-time autonomy (Execution)

Level of control a service has over its processing logic at the time the service is

invoked and executing

Objective : ( to service consumer) Consistently acceptable runtime execution performance Greater degree of performance reliability isolated in response to specific security, reliability, or performance requirements Greater level of behavioral predictability (especially when concurrently accessed)

TYPES OF SERVICE AUTONOMY

Design-time autonomy (Governance)

Level of freedom we, as service owners, have to make changes to a service over its lifetime

(Regardless of whether a service has control over its runtime execution environment)

Objective : ( to service consumer) Ability to scale a service in response to higher usage demands Option to further modify or enhance a service’s hosting environment Freedom to augment, upgrade, or replace the technology of a service in response

to new requirements or a desire to leverage new innovations

All of forms of design-time autonomy can be attained by applyingService Loose Coupling principle

MEASURING SERVICE AUTONOMY ( LEVELS OF AUTONOMY)

Service Contract Autonomy Shared Autonomy

Logic Autonomy Pure Autonomy

MEASURING SERVICE AUTONOMY ( LEVELS OF AUTONOMY)

1. SERVICE CONTRACT AUTONOMY

Service Contract Autonomyservices with normalized contracts

While building Service inventory we need to ensure that each service establishes a functional boundary that is its own.

The range of capabilities expressed by one service contract should not overlap with the capabilities expressed by others.

Even if the expressed functionality does not overlap, underlying serviceimplementations may still overlap ( other levels care about implementation)

1.1. SERVICE NORMALIZATION

Normalization : Data modeling term

Approach to reduce or even eliminate redundancyacross data entities and structures

Service Normalization : Minimizes the amount of functional redundancy across a service inventory

Objective :

• well aligned (and streamlined) service inventory• Reduce overall quantity of required services • Reduce overall size of inventory

1.2. CONTRACT DENORMALIZATION

In service , each capability establishes its own functional scope.

Often unrealistic for one capability to fully accommodate the requirements of all possible consumers

Intentional denormalization of a service contract.

2. SHARED AUTONOMY

For many organizations it is unrealistic to build all services from the ground up

some services can be custom programmed, whereas others must encapsulate older legacy technology

indicate that other parts of the enterprise are expected to access (and perhaps even compete for) whatever processing logic may fall within the service boundary

3. LOGIC AUTONOMY

indicates that underlying service components are dedicated and can be isolated

form of partial autonomy databases, directories, and other resources are still shared between services andother parts of the enterprise

Risks : Unpredictable levels of concurrent data access Record or page locking Long query execution times Inconsistent or unacceptable response times Occasional unpredictable behavior Less than optimum scalability

4. PURE AUTONOMY

Functional isolation

Functional pure autonomy :

Service components and physical data models are dedicated, but the service is hosted on a server with others

Services A, B, and C have separate dedicated databases but still share the system resources of a single server and runtime

4. PURE AUTONOMY

Absolute pure autonomy :

Service components and associated data models are on a dedicated server

Services A, B, and C each have their own,physically isolated hosting environments, providing the ultimate in autonomous computing

SERVICE AUTONOMY & SERVICE MODEL

SERVICE AUTONOMY & OTHER PRINCIPLES

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

top related