primitive process model of SOA using set of design patterns in SOA design pattern

1. Next generation
SOAFrom knowledge
To practice
SUBMITTED BY : MOHAMED ZAKARYA

2. 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 

3. PART 5
PRIMITIVE SERVICE
MODELING PROCESS

4. 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 reusability
2. Service composability

5. PRIMITIVE SERVICE MODELING PROCESS - DECOMPOSITION
Service
encapsulation
2
Non – agnostic
context
5
Agnostic
capability
4
Functional
decomposition
1
Agnostic
Context
3

6. 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.

7. 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

8. 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 )

9. 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 being
encapsulated as a service)

10. 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 ]

11. 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

12. 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 set
of 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.

13. 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

14. 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

15. PROCESS MODELING [4. AGNOSTIC CAPABILITY]
Relationships :
considered a continuation of Agnostic Context

16. PROCESS MODELING [4. AGNOSTIC CAPABILITY]
After applying Entity Abstraction :

17. PROCESS MODELING [4. AGNOSTIC CAPABILITY]
After applying Utility Abstraction :

18. 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.

19. 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

20. 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

21. 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

22. PROCESS MODELING [5. NON-AGNOSTIC CONTEXT]
After applying Process Abstraction :

23. 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/

24. ANY QUESTIONS

25. THANKS
ENJOY SOA .. WAIT FOR NEXT
MAIL: ENG.MOHAMEDZAKARYA@GMAIL.COM