SOA Principles : 5. service abstraction
22
Principles OF SOA From knowledge To practice SUBMITTED BY : MOHAMED ZAKARY
-
Upload
mohamed-zakarya -
Category
Technology
-
view
13 -
download
2
Transcript of SOA Principles : 5. service abstraction
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
ABSTRACTION
REVIEW DAY 2
TERM
Service oriented computing Service orientation Service oriented architecture
Solution logic Service Service candidate
Service capability Service capability candidate Service composition
Service inventory domain service inventory Enterprise service inventory
integration Interoperability Service model
Entity service Utility service Task service
Service contract SLA WSDL – Schema
Data transformation Service reusability Tactical reusability
Target reusability Complete reusability Agnostic logic
Logic centralization Contract centralization Service provider / consumer
INTRODUCTION
Service AbstractionContract contains only essential information , that is published to consumers.
Achieving the right balance of information hiding
Hide information about a program not absolutely required for othersto effectively use that program.
WHY SERVICE ABSTRACTION IS NEEDED
Empower the service owner with the freedomto evolve the service implementationas required.
The more information made available to humans responsible for delivery of service consumers, The greater their awareness of underlying logic,
They may naturally make assumptions and judgments based on extra knowledge
ABOUT THE PRINCIPLE
TitleNon-essential service information is abstracted.
DescriptionService contracts only contain essential information and information about services is limited to what is published in service contracts.
Goals
Prevent unnecessary access to additional service details
Key the quantity and details of contract concise and balance
TYPES OF META ABSTRACTION
Technology InformationMeta data that describes technical implementation of underlying service logic.
Functional InformationMeta data that describes what the service is capable of
Programming logic informationMeta data that describes how the service carriesout its capabilities.
Quality of service informationMeta data that describes service behavior, limitations,and interaction requirements.
1. TECHNOLOGY INFORMATION ABSTRACTION
Hide details of technology used to build a software program sothat we retain freedom to make technical changes without affecting existing users.
Calculator development teamHave freedom as to how we can choose to evolve our program in the future
1. TECHNOLOGY INFORMATION ABSTRACTION
2. FUNCTIONAL INFORMATION ABSTRACTION
which of a program’s capabilities are made public through its technical contract.
3. PROGRAMMATIC LOGIC ABSTRACTION
Internal details about a program that are deliberately hidden from the outside world.
Typically represent low-level design details, such as algorithms,exception handlinglogging routines
3. PROGRAMMATIC LOGIC ABSTRACTION
Open source projects are a good example of environmentsin which access control and programmatic logic tend to be reduced.
4. QUALITY OF SERVICE ABSTRACTION
Umbrella term for a range of behavioral,rules-based, and reliability-related meta information about a service.
CONTRACT CONTENT ABSTRACTION LEVELS
Based on the quantity and detail of information in a contract, its measure of content abstraction can be classified
These levels are used specifically to measure functional abstraction
Detailed Contract The content within the contract is detailed, Service Abstraction has not been seriously applied.
Concise ContractBalance content with known usage scenarios , meta data that clearly not required will removed.
Optimized Contractundergone a formal audit , trimmed of unnecessary content and constraints
ACCESS CONTROL LEVELS
Ability of humans to learn about a service’s underlying logic and implementation(technology information and programmatic logic abstraction)
Open AccessDesign specification are openly availableAnd accessible
Controlled AccessSecurity measures are in placeto limit access to service designDocumentsLike open read-only access
No Accessoff limits , only service owner
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
