This document provides an overview of a 5-day course on service-oriented architecture (SOA). The course covers fundamental SOA concepts, SOA technology, design and architecture. It introduces SOA as a set of Lego blocks and discusses how SOA relates to enterprise architecture. The document outlines the course calendar and provides brief introductions to SOA certifications and reference materials.

2. Service Oriented Architecture
Certified Architect

3. “who are you ?
What you expect ☺

4. Course Calendar
Day 1 : Fundamental SOA & Service-Oriented Computing
Day 2 : SOA Technology Concepts
Day 3 : SOA Design & Architecture
Day 4 : Advanced SOA Design & Architecture
Day 5 : SOA Design & Architecture Lab

5. Quick Introduction
▷SOA As a Lego box
▷Arcitura Schools
▷SOA Certifications
▷SOA Architecture Certification Matrix
▷SOA Book Series

6. SOA As A Lego box

7. SOA & EA
▷Overall construction of the enterprise
▷Includes much more than IT than IT
▷Covers business operations, finance,
people, buildings and technology
▷Particular construction technique
to build enterprise IT
▷Part of the enterprise architecture
▷Major impact on the overall construction

8. Enterprise Architecture Overview – Togaf Framework

9. SOA Reference Model

10. Arcitura Schools
SOA
School
Cloud
School
Big Data
School

11. Soa certifications

12. Soa certifications Matrix

13. Soa Book Series

14. Soa Reference Sites
▷SOA School: https://www.arcitura.com/soa-school/
▷Book Series: https://www.arcitura.com/books/
▷SOA Glossary: http://serviceorientation.com/soaglossary/index
▷SOA Design Patterns: http://soapatterns.org/
▷Rest Portal : www.whatisrest.com
▷Service Technology Magazine: http://www.servicetechmag.com/

15. S90.01
Fundamental SOA &
Service-Oriented Computing

16. Session Agenda
1. Fundamental Service-Oriented Computing Terms
2. Strategic Goals of Service-Oriented Computing
3. SOA and service Orientation
4. Planning and Governing SOA
5. SOA Project Delivery Approaches and Planning
6. Primitive service modeling process

17. Fundamental Service-Oriented
Computing Terms
▷Service Oriented Computing
▷Service Orientation
▷Service Oriented Architecture
▷Service
▷Service Composition
▷Service Inventory

18. Service Oriented Computing
New generation distributed computing platform include:
▷Its own design paradigm (principles)
▷Design pattern catalogs
▷Pattern languages
▷ A distinct architectural model,
▷Related concepts, technologies, and frameworks.
Big umbrella in the
world of services
Builds upon past distributed computing platforms and adds :
▷New design layers
▷Governance considerations
▷Set of implementation technologies.

19. Service Oriented Computing

20. Service Oriented Computing elements
Service
Inventory
Solution
Logic
Service
Service
Composition
SOA
Service
Orientation

21. Service
1

22. Service
▷Independent software programswith distinct design characteristics
Service with
functional context
Solution
Logic
Is a Unit of
Goals
help attain of

23. Service - Capability
▷A service is a container for a collection of related functions.
These functions are called service capabilities
▷Capabilities exposed via a service contract establish a basic API by which the service
can be invoked.
▷Capabilities Useful during service modeling stages when physical design
of a service has not yet been determined.
Once it is known whether a service exists as a Web service
or as a component, the terms "service method" or “
service operation" can be used instead

24. Service Composition
2

25. Service Composition
▷An aggregateof services collectively composed to automate a particular task
or business process.
▷To qualify as a composition, at least two participating services plus
one composition initiator need to be present.
▷service naturally and repeatedly composed is fundamental
to attaining several of key strategic goals of
service-oriented computing.
▷Service-orientation design paradigm revolves around
preparingservices for effective participation
in numerous complex compositions.

26. Service Composition – Real World Example
Passport Check process in Airport

27. Solution Logic
3

28. Service Orientation Solution logic
▷The application of Service Orientation principles to the design of solution logic
results in service-oriented solution logic
▷Service-oriented solution logic is implemented as services and service compositions
Principles
Goals
Service
Composition
Service
Solution
Logic

29. Solution logic – Real World Example
MOI Electronic Service Solution (Absher)

30. Service Orientation
4

31. Service Orientation
Design paradigm comprised of a specific set of design principles.

32. Service Orientation Principles
Standardized
Service
Contract
Service
Reusability
Service
Composability
Service
Autonomy
Service
Loose
Coupling
Service
Statelessness
Service
Abstraction
Service
Discoverability

33. Service Orientation Principles
Service Reusability
Service contain agnostic logic that can be position as reusable enterprise resource.
Standardized Service Contract
Service in same inventory are in compliance of same design service contract standards.
Service Composition
Services are effective composition participants.
Service Discoverability
Service meta data available for discoverability and interpreted.

34. Service Orientation Principles – cont.
Service Loose Coupling
Contract decoupled from surrounding environment.
Service Autonomy
Services exercise a high level of control over underlying runtime execution environment.
Service Statelessness
Services minimize resource consumption , reduce state information.
Service Abstraction
Contract contains only essential information , that is published to consumers.

35. Service Oriented Architecture
5

36. Architecture Definition
Definition 2
Structureof components, their inter-relationships, and principles and
guidelines governingtheir design and evolution over time
Definition 1
Formal Description or Detailed plan Of system at component level
to guide its implementation

37. Service Orientated Architecture
▷SOA establishes an architectural model that aims to enhance the efficiency, agility, and
productivityof an enterprise
▷SOA Position services as primarymeans through which solution logic is represented in
support of realization of strategic goals associated with service-oriented computing.
▷Service-oriented computing revolves around service-orientation design paradigm
and its relationship with service-oriented architecture.

38. Service Orientated Architecture
SOA Implementation can consist of
▷Technologies
▷Products
▷APIs
▷Supportinginfrastructureextensions
▷Various other parts

39. Service Inventory
6

40. Service Inventory
▷collection of complementaryservices within a boundary that represents an
enterprise or a meaningful segment of an enterprise
▷Service inventories are typically created through top-down delivery processes that
result in the definition of service inventory blueprints.

41. Enterprise/Domain Service Inventory

42. Service Inventory (Blueprint)
Service Inventoryblueprints 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
Classification used to indicate that a service belongs to one of several predefined
types based on the nature of the logic it encapsulates

43. Service layers – Entity Service
▷Reusable service with an agnostic functional context
▷associated with one or more related business entities

44. Service Models – Utility Service
▷Reusable service with an agnostic functional context
▷Not retrieved from business encapsulates low-level
technology-centric functions
▷ such as notification, logging, and security processing.

45. Service Models – Task Service
▷A service with a non-agnostic functional context
▷Generally correspondsto single-purpose
▷A task service will usually encapsulate the compositionlogic

46. Service oriented computing Elements relations

47. Strategic Goals of Service-Oriented
Computing
▷Increased Intrinsic Interoperability
▷Increased Federation
▷Increased Vendor Diversification Options
▷Increased Business and Technology
Domain Alignment
▷Increased Return on Investment (ROI)
▷Increased Organizational Agility
▷Reduced IT Burden

48. Service Oriented Computing Goals

49. Service Oriented Computing Goals
Increased Intrinsic Interoperability
Service designed to be naturally compatible, no effort need for integration
Integration VS
Interoperability

50. Service Oriented Computing Goals
Increased Federation
Services establish a uniform contract layer hides underlying difference

51. Service Oriented Computing Goals
Increased Vendor Diversification Options
A vendor-neutral architectural model organization to evolve the architecture
without limited to proprietary vendor platform characteristics

52. Service Oriented Computing Goals
Increased Business and TechnologyDomain Alignment
services are designed with a business-centric functional context alignment with the business,
even as the businesschanges

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

54. Service Oriented Computing Goals
Increased Organizational Agility
Rapid delivery , New and changing business requirements can be fulfilled rapidly

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

56. 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 Interoperability
Service designed to be naturally compatible, no effort need for integration
Increased Business and TechnologyDomain Alignment
services are designed with a business-centric functional context alignment with the business,
even as the businesschanges
Reduced IT Burden
providing more value with less cost and less overall burden reduced waste and
redundancy, reduced size and operational cost
Increased Federation
Services establish a uniform contract layer hides underlying difference
Increased Vendor Diversification Options
A vendor-neutral architectural model organization to evolve the architecture
without limited to proprietary vendor platform characteristics

57. SOA and Service Orientation
▷SOA Characteristics
▷ Four Common Types of SOA

58. SOA Characteristics
Always align between technology
architecture and business needs
Business driven Vendor Neutral
Leveragingmultiple vendor
technology innovations
Composition centric
services capable of being pulled
into a variety of composition
Enterprisecentric
Enterpriseresource is simply
logic positioned as an IT asset

59. Business Driven
1

60. SOA Characteristics – Business Driven
Traditional technology architecture
For solutions delivered to fulfill tactical (short-term)business requirements
Result :
▷Technical environment, over time, falls out of
alignment with organization's business direction
and requirements
▷Increasingly difficult to adapt to
changing business needs

61. SOA Characteristics – Business Driven
Business driven technology architecture
Business vision, goals, and requirements are positioned as the basis for and
the primaryinfluence of the architectural model.
Result :
▷maximizes the potential alignment of
technology and business
▷continual increase in the value and life span of
the architecture.
▷constant sync with how the business evolves
over time.

62. Vendor Neutral
2

63. SOA Characteristics – Vendor Neutral
Vendor-centric technology architectures :
Bound to correspondingvendor platform Roadmaps
Result :
▷Reduce opportunities to leverage technology
innovations provided by other vendor platforms
▷Need to eventually replace the architecture
entirely with a new vendor implementation

64. SOA Characteristics – Vendor Neutral
neutral vendor platforms
Result :
▷freedom to diversify its implementation by
leveraging multiple vendor technology
innovations.
▷Increases the longevity of the architecture
▷Architecture evolve in response to changing
requirements

65. Enterprise Centric
3

66. SOA Characteristics – Enterprise Centric
Single-purpose services
Delivered to automate specific business processes
Result :
Can end up establishing silos within the enterprise.

67. SOA Characteristics – Enterprise Centric
Enterprisecentric services
Enterpriseresource is simply logic positioned as an IT asset
Result :
Extension of the enterprise that does not belong solely to any one application or solution

68. Composition Centric
4

69. SOA Characteristics – Composition Centric
▪ Service built as flexible resources
that plugged into different aggregate
structures
▪ services must be capable of being pulled
into a variety of composition designs,
regardless of whether or not they are
initially required to participate in a
composition when they are first delivered

70. Common Types of SOA

71. Four Common Types of SOA
▷Service-oriented technology architecture can exist at different scopes or levels of implementation
▷These implementation levels are referredto as SOA types.
1. Service Architecture : The architecture of a single service
2. Service Composition Architecture : the architecture of a
set of services assembled into a service composition

72. Four Common Types of SOA
▷These implementation levels are referredto as SOA types.
3. Service InventoryArchitecture : the architecture that
supports a collection of related services that are
independently standardized and governed
4. Service-Oriented EnterpriseArchitecture:
The architecture of the enterprise itself, to whatever
extent it is service-oriented

73. Planning and Governing SOA
▷Four Pillars of Service Orientation
▷Levels of organizational maturity

74. Planning and Governance of SOA
▷SOA adoption require a long-term commitment that can demand essential rethink of an
organization’s business and the culture, technology, and priorities of its IT enterprise
▷The following models and practices assist an organization in assessing its readiness and
maturity, and formalizing the manner in which the resources and assets produced by an SOA
project are regulated and evolved
1. Four Pillars of Service Orientation
2. Level of Organizational Maturity

75. Pillars of Service-Orientation

76. 1. Pillars of Service-Orientation
▷Teamwork : Cross-project teams and cooperation are required.
▷Education : Team members must communicate and cooperate based on common
knowledge and understanding.
▷Discipline : Team members must apply their common knowledge consistently.
▷Balanced Scope : The extent to which the required levels of
Teamwork, Education, and Discipline need to be realized is
represented by a meaningful yet manageable scope
Good understanding of how these pillars represent
foundational requirementsfor successful SOA adoption
enables an organization to properlyscope its adoption effort

77. SOA organizational maturity

78. 2. Levels of organizational maturity
▷Organization begins planning for the adoption of SOA
▷ Organization transition throughone or more of the following common evolutionary
levels:

79. Levels of organizational maturity
Service Neutral Level
No meaningful extent of teamwork, education, or discipline has been established
or yet identified

80. Levels of organizational maturity
Service Aware
Four pillars have been established, relevant business requirements and goals are
defined, and overall necessary organizational foundation for the SOA initiative is in place.

81. Levels of organizational maturity
Service Capable
Ability to deliver and govern services and service compositions in response to
business automation requirements

82. Levels of organizational maturity
Business Aligned
Organization has successfully aligned services and service compositions with the
current state of the business.
service inventory have been delivered and are in operation (mature service inventory)

83. Levels of organizational maturity
Business Driven
service-encapsulated technology resources are not just aligned with the current
state of the business, but have proven to remain in alignment with how business
requirements continue to change

84. Levels of organizational maturity
Service Ineffectual
IT enterprise delivers services as silo-based or bottom-up automation solutions
under the pretense that it is adopting SOA.
(most likely single-purpose software programslabeled as services)

85. Levels of organizational maturity
Service Aggressive
Generation of services that the business doesn't want or need , business may
not even be aware of their existence.
Due to lack of teamwork or education or discipline , the SOA initiative fails to
align its technology in support of the business.

86. SOA Project Delivery Approaches
and Planning
▷Top-down Approach
▷Bottom-up Approach
▷meet-in-the-middle Approach
▷Project and Lifecycle Stages
▷Service Oriented Analysis
▷Service oriented Design

87. Project Delivery Approaches

88. SOA Project Delivery
Choosing a delivery approach is a critical decision
point because it represents a decision an organization
will usually need to live with for quite some time.
There are different project delivery approaches :
▷Top-down Approach
▷Bottom-up Approach
▷Meet-in-the-middle

89. Bottom-up approach
▷Tactically focused in that it makes the fulfillment of immediate business requirements a
priorityand the prime objective of the project.
Pros and Cons :
▷Avoids extra cost, effort, and time required to deliver services via a top-down approach
▷Increased governance burden as bottom-up delivered services tend to have shorter
lifespans and require more frequent maintenance ,refactoring, and versioning.

90. Top-down approach
▷Represent Spectrum Strategyview for enterprise.
▷Advocates the completion of an inventory analysis priorto the physical design,
development, and delivery of services.
Pros and Cons :
▷ Demands more of an initial investment because it introduces an up-front analysis
stage focused on the creation of the service inventory blueprint.
▷Service candidates are individually defined as part of this blueprint so as to ensure
that subsequent service designs will be highly normalized , standardized ,and
aligned.

91. meet-in-the-middle Approach ( Agile Delivery)
▷Allows for an on-going analysis and definition of a service inventory blueprint, while
high-priorityservices are delivered in advance
▷At a later point, after the analysis efforts have sufficiently progressed,services that
have been previously deployed are revisited
Pros and Cons :
▷If necessary, they are then redeveloped and brought in alignment with the revised
blueprint.

92. Project lifecycle Stages

93. Project and Lifecycle Stages
1. SOA Adoption Planning
2. Service InventoryAnalysis
3. Service-Oriented Analysis (Service Modeling)
4. Service-Oriented Design (Service Contract)
5. Service Logic Design
6. Service Development
7. Service Testing
8. Service Deployment and Maintenance
9. Service Usage and Monitoring
10.Service Discovery
11.Service Versioning and Retirement
Common and primarystages related to SOA projects and the overall service lifecycle:
http://serviceorientation.com/soaproject/projectlifecycle

94. Service Oriented Analysis

95. Service Oriented Design

96. Primitive service modeling
process
▷Functional decomposition
▷service encapsulation
▷agnostic context
▷agnostic capability
▷non-agnostic context

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

98. Primitive Service modeling process
Service
encapsulation
2
Non – agnostic
context
5
Agnostic
capability
4
Functional
decomposition
1
Agnostic
Context
3

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

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

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

102. 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 resourcesalso 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)

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

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

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

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

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

108. process modeling [4. agnostic capability]
Relationships :
Considered a continuation of Agnostic Context

109. process modeling [4. agnostic capability]
After applying Entity Abstraction :

110. process modeling [4. agnostic capability]
After applying Utility Abstraction :

111. process modeling [4. agnostic capability] Sample
Service definitions, each with capabilities that address processing
requirements of specific business process
After furtherservice modeling, the definitions
are refined with agnostic capabilities.

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

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

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

115. process modeling [5. non-agnostic context]
After applying Process Abstraction :

116. Questions

117. Review Day 1
TERMS
Service oriented
computing
Service orientation Service oriented
architecture
Solution logic Service Service candidate
Service capability Service capability
candidate
Service composition
Service inventory Interoperability integration
Service model Entity service Utility service
Task service Business-centric Vendor-neutral
Enterprise-centric Composition-centric

118. Question-1
Which of the following statements is false?
A. A service is a unit of logic to which service-orientation has been applied to
a meaningful extent.
B. Services are designed to increase the need for integration.
C. Services are the fundamental building blocks of service-oriented solutions.
D. A service composition is comprised of services.
Answer : B

119. Question-2
A __________ can be part of a/an __________ which can be assembled from __________
within a/an
__________.
A. component, object, enterprises, service
B. service inventory, service, enterprises, service composition
C. service, service composition, services, service inventory
D. service inventory, service, service compositions, enterprise
Answer : C

120. Question-3
Services are ideally designed to be:
A. agnostic and reusable
B. unidirectional and semi-granular
C. linear and logistically decomposable
D. returnable and non-standardized
Answer : A

121. Question-4
Service Autonomy, Service Statelessness, and Service Loose Coupling are
examples of:
A. service-oriented architecture types
B. service-orientation design principles
C. service models
D. none of the above
Answer : B

122. Question-5
Service A invokes Service B. Service B invokes Service C. Service C
invokes both Service D and Service A.
In this runtime scenario, which services are acting as service consumers?
A. Service A, Service B, Service C
B. Service D, Service E
C. Service A
D. None, because a service cannot also be a service consumer.
Answer : A

123. “To Be continue
with SOA
☺

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

125. Thanks!
Any questions?
You can find me at:
eng.mohamedzakarya@gmail.com
Mohamed Zakarya Abdelgawad