soa course : service process model
TRANSCRIPT
Next generation
SOA From knowledge To practice
SUBMITTED BY : MOHAMED ZAKARYA
AGENDA
What you expect SOA !
Arcitura schools (SOA School)
SOA certifications
SOA With EA
Fundamental SOA and Service Oriented Computing
Service Oriented Computing Goals
Primitive Service modeling process
Thanks
PART 5
PRIMITIVE SERVICE MODELING PROCESS
PRIMITIVE SERVICE MODELING PROCESS
Organize large amount of units of logic so that they can be reassembled into service-oriented solutions.
Group and categorize these units according to the nature of their logic.
Focus on following SOA principles 1. Service reusability2. Service composability
PRIMITIVE SERVICE MODELING PROCESS - DECOMPOSITION
Service encapsulation
2
Non – agnosticcontext
5
Agnostic capability
4
Functionaldecomposition
1
Agnostic Context
3
PROCESS MODELING [1. FUNCTIONAL DECOMPOSITION]
Purpose : How can a large business problem be solved without having to build a standalone body of solution logic?
Solution : To apply service-orientation, we first must break down a business process by functionally
decomposing it into a set of desirable actions Functional decomposition is Application of the separation of concerns theory.
PROCESS MODELING [1. FUNCTIONAL DECOMPOSITION]
Impacts : Require attention on interconnectivity, security, reliability, and maintenance between
distributed solution logics If the quality of the business process definition is poor, then the resulting concerns will
form a weak foundation for subsequent service definition.
Relationships : Functional Decomposition forms the basis for all of the patterns prepares the concerns that are subsequently addressed by solution logic that begins to
take shape with the application of Service Encapsulation
PROCESS MODELING [2. SERVICE ENCAPSULATION]
Purpose : How can solution logic be made available as a resource of the enterprise?
Solution : Solution logic can be encapsulated by and exposed as a service (positioned as enterprise resource) Solution logic capable of functioning beyond the boundary for which it is initially delivered enterprise where individual solutions use logic encapsulated as services and vice versa ( as shared services )
PROCESS MODELING [2. SERVICE ENCAPSULATION]
Application : ( identify solution logic that can be encapsulate) Does logic contain functionality useful to parts of the enterprise outside of the current application
boundary? ( if yes , logic increased value potential to be enterprise resources )
Does logic designed to leverage enterprise resources also have the potential to become an enterprise resource? ( after agnostic logic is initially separated , it will be clear if new logic can leverage existing enterprise resource , if so , some or all of its functionality can also be positioned as an enterprise resource)
Does implementation of logic require hard constraints that make it impractical or impossible to position logic as an effective enterprise resource? (may be real-world limitations prevent from beingencapsulated as a service)
PROCESS MODELING [2. SERVICE ENCAPSULATION]
If service-orientation design principles cannot be applied to a meaningful extent, then logic not likely justify for service encapsulation
Relationships : For encapsulated solution logic to become effective member of service inventory, it needs to be further
shaped by other patterns and principles Encapsulated solution logic subsequently grouped into• Single service ( non-agnostic context) [ entity – utility]• OR multi-purpose services ( Agnostic context) [ task – orchestration ]
PROCESS MODELING [3. AGNOSTIC CONTEXT]
Purpose : How can multi-purpose service logic be positioned as an effective enterprise resource?
Solution : Isolate logic that is not specific to one purpose into separate services with distinct agnostic contexts positions reusable solution logic at an enterprise level Apply service reusability principle
PROCESS MODELING [3. AGNOSTIC CONTEXT]
Application :
Subset of the solution logic being further decomposed and then distributed into services with specific agnostic contexts
Agnostic logic is defined and continually refined into a setof candidate service contexts.
form the basis of Entity Abstraction and Utility Abstraction
Impacts :
Increase quantity of services required to solve a given problem Leads to additional design considerations and performance
overhead associated with service compositions. The governance effort increased Also the governance of the overall architecture is also
impacted as the quantity of agnostic services within an inventory grows.
PROCESS MODELING [3. AGNOSTIC CONTEXT]
Relationships : Closest relationship is between Agnostic Context and Agnostic Capability Other patterns apply specialized variations on agnostic context such as
Entity Abstraction and Utility Abstraction
PROCESS MODELING [4. AGNOSTIC CAPABILITY]
Purpose : How can multipurpose service logic be made effectively consumable and composable ?
Solution : Agnostic service logic is partitioned into a set of well-defined capabilities that address common concerns not specific to any one problem
PROCESS MODELING [4. AGNOSTIC CAPABILITY]
Relationships :
considered a continuation of Agnostic Context
PROCESS MODELING [4. AGNOSTIC CAPABILITY]
After applying Entity Abstraction :
PROCESS MODELING [4. AGNOSTIC CAPABILITY]
After applying Utility Abstraction :
PROCESS MODELING [4. AGNOSTIC CAPABILITY] SAMPLE
Service definitions, each with capabilities that address the processing requirements of specific business process
After further service modeling, the definitions are refined with agnostic capabilities.
PROCESS MODELING [5. NON-AGNOSTIC CONTEXT]
Purpose : How can single-purpose service logic be positioned as an effective enterprise resource?
Solution :Non-agnostic solution logic suitable for service encapsulation can be located within services that reside as official members of a service inventory
PROCESS MODELING [5. NON-AGNOSTIC CONTEXT]
Application :
Non-agnostic service logic is shaped via the same governing design principles as agnostic Services
Most commonly applied in combination with Process Abstraction
No rules as to whether this pattern should be applied before or after Agnostic Context
Impacts :
Initial delivery will be more expensive and more time-consuming
The ultimate ROI can therefore be significantly lower than with agnostic services
PROCESS MODELING [5. NON-AGNOSTIC CONTEXT]
Relationships : Non-Agnostic Context is subsequent to Service Encapsulation Based on task-centric service models so major relation with process abstraction
and process centralization patterns
PROCESS MODELING [5. NON-AGNOSTIC CONTEXT]
After applying Process Abstraction :
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
