soa next generation
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
What next ! (SO-Principles)
Thanks
PART 1
WHAT YOU EXPECT
SOA!
WHAT YOU EXPECT
SOA !
PART 2
Arcitura schools SOA Certifications
ARCITURA SCHOOLS
SOA School Cloud School Big Data School
SOA CERTIFICATIONS
SOA CERTIFICATION – CERTIFIED SOA PROFESSIONAL
Exam S90.01: Fundamental SOA & Service-Oriented Computing
PLUS
Any one additional SOACP exam
SOA CERTIFICATION – CERTIFIED SOA ARCHITECT
SOA CERTIFICATION – BOOKS SERIES
PART 3
SOA WITH EA
FUNDAMENTAL SOA
SERVICE ORIENTED COMPUTING
Service Oriented Computing elements
SOA WITH ENTERPRISE ARCHITECTURE
Overall construction of the enterprise Particular construction technique to build enterprise IT
Part of the enterprise architecture
Major impact on the overall construction
Includes much more than IT
Covers business operations, finance, people, buildings and technology
SERVICE ORIENTED COMPUTING (SOC)
Include : its own design paradigm design principles design pattern catalogs pattern languages a distinct architectural model, and related concepts, technologies, and frameworks.
It’s builds upon past distributed computing platforms and adds : new design layers, governance considerations, set of implementation technologies.big umbrella in the
world of services
New generation of distributed computing
platform
SERVICE ORIENTED COMPUTING (SOC)
SERVICE ORIENTED COMPUTING ELEMENTS
ServiceInventory
Solution Logic
ServiceService
Composition
SOAService Orientation
SOC ELEMENTS [SERVICE ORIENTATION]
Comprised of Design Principles
Govern designingSolution Logic
SOC ELEMENTS [SERVICE ORIENTATION SOLUTION LOGIC]
There has been a common misunderstand that the use of Web services technology within an application shape a service-oriented solution
Principles
Apply
Goals
Service Composition
Service
Realize Implemented as
Implemented as
Solution Logic
SOC ELEMENTS [SERVICE ORIENTED ARCHITECTURE ]
form of technology architecture designed in support of service-oriented solution logic with distinct characteristics in support of realizing service-orientation and the strategic goals associated with service-oriented computing.
SOA Implementation can consist of a combination of technologies, products, APIs, supporting infrastructure extensions, and various other parts
SOA
technology architecture optimized in support of
services, service compositions, service inventories.
SOC ELEMENTS [SERVICE]
Independent software programs with distinct design characteristics
Solution Logic
Is a Unit of
Service with functional context
Goalshelp attain of
SOC ELEMENTS [SERVICE COMPOSITION]
Business Process
service naturally and repeatedly composed is fundamental to attaining several of key strategic goals of service-oriented computing.
Service-orientation design paradigm revolves around preparing services for effective participation in numerous complex compositions
SOC ELEMENTS [SERVICE INVENTORY ]
ServiceInventory
Service Inventory blueprints is a Collection of Candidate services in analysis phase that need to analyzed and refined as necessary before committing to the actual creation of a physical service inventory
SOC ELEMENTS [SERVICE INVENTORY ]
ServiceInventory
Entity ServiceReusable service with an agnostic functional context associated with one or more related business entities
Utility Servicereusable service with an agnostic functional context not retrieved from business encapsulates low-level technology-centric functions, such as notification, logging, and security processing.
Task ServiceA service with a non-agnostic functional context that generally corresponds to
single-purpose A task service will usually encapsulate the composition logic
SERVICE ORIENTED COMPUTING ELEMENTS RELATIONS
service-oriented computing platform revolves aroundservice-orientation design paradigm and its relationship with service-oriented architecture
PART 4
SERVICE ORIENTED COMPUTING GOALS
SERVICE ORIENTED COMPUTING GOALS
SERVICE ORIENTED COMPUTING GOALS
Increased Return on Investment (ROI)Services are delivered and viewed as IT assets expected to provide repeated value, that will cover exceed cost of delivery and ownership
Increased Organizational Agility Rapid delivery , New and changing business requirements can be fulfilled rapidly
Increased Intrinsic InteroperabilityService designed to be naturally compatible, no effort need for integration
Increased Business and Technology Domain Alignmentservices are designed with a business-centric functional context alignment with the business, even as the business changes
Reduced IT Burden providing more value with less cost and less overall burden reduced waste and redundancy, reduced size and operational cost
Increased FederationServices establish a uniform contract layer hides underlying difference
Increased Vendor Diversification OptionsA vendor-neutral architectural model organization to evolve the architecture without limited to proprietary vendor platform characteristics
SERVICE ORIENTED COMPUTING GOALS
Increased Intrinsic InteroperabilityService designed to be naturally compatible, no effort need for integration
Integration VSInteroperability
SERVICE ORIENTED COMPUTING GOALS
Increased FederationServices establish a uniform contract layer hides underlying difference
SERVICE ORIENTED COMPUTING GOALS
Increased Vendor Diversification OptionsA vendor-neutral architectural model organization to evolve the architecture without limited to proprietary vendor platform characteristics
SERVICE ORIENTED COMPUTING GOALS
Increased Business and Technology Domain Alignmentservices are designed with a business-centric functional context alignment with the business, even as the business changes
SERVICE ORIENTED COMPUTING GOALS
Increased Return on Investment (ROI)Services are delivered and viewed as IT assets expected to provide repeated value, that will cover exceed cost of delivery and ownership
SERVICE ORIENTED COMPUTING GOALS
Increased Organizational Agility Rapid delivery , New and changing business requirements can be fulfilled rapidly
SERVICE ORIENTED COMPUTING GOALS
Reduced IT Burden providing more value with less cost and less overall burden reduced waste and redundancy, reduced size and operational cost
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 :
PART 6
WHAT NEXT !
(SO-PRINCIPLES)
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.
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
