This presentation will cover first exam of SOA , by introducing terms related to Service oriented Computing umbrella to start your knowledge base about Service Orientation world.

2. Service Oriented Architecture
Certified Architect

3. “who are you ?
What you expect 

4. Course Calendar
Exam 1 : Fundamental SOA & Service-Oriented Computing
Exam 2 : SOA Technology Concepts
Exam 3 : SOA Design & Architecture
Exam 4 : Advanced SOA Design & Architecture
Exam 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. Arcitura Schools
SOA
School
Cloud
School
Big Data
School

9. Soa certifications

10. Soa certifications Matrix

11. Soa Book Series

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

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

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

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

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

17. Service Oriented Computing

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

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

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

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

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

23. 3. Service Orientated Architecture
▷ Architectural model aims to enhance efficiency, agility, and productivity of an enterprise.
▷ Position services as primary means 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.
▷ SOA Implementation can consist of
▷ Technologies
▷ Products
▷ APIs
▷ Supporting infrastructure extensions
▷ Various other parts

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

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

26. 5. Service Composition
▷ An aggregate of 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
preparing services for effective participation
in numerous complex compositions.

27. 6. Service Inventory
▷ collection of complementary services 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.

28. 6. Enterprise/Domain Service Inventory

29. 6. Service Inventory (Blueprint)
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

30. 6. Service Inventory (Service Models)
Classification used to indicate that a service belongs to one of several predefined types
based on the nature of the logic it encapsulates
Entity Service
▷ Reusable service with an agnostic functional context
▷ associated with one or more related business entities
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.
Task Service
▷ A service with a non-agnostic functional context
▷ Generally corresponds to single-purpose
▷ A task service will usually encapsulate the composition logic

31. Service oriented computing Elements relations

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

33. Service Oriented Computing Goals

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

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

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

37. Service Oriented Computing Goals
Increased Business and Technology Domain Alignment
services are designed with a business-centric functional context alignment with the business,
even as the business changes

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

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

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

41. 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 Technology Domain Alignment
services 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 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

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

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

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

45. 1. SOA Characteristics – Business Driven
Business driven technology architecture
Business vision, goals, and requirements are positioned as the basis for and
the primary influence 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.

46. 2. SOA Characteristics – Vendor Neutral
Vendor-centric technology architectures :
Bound to corresponding vendor 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

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

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

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

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

51. Four Common Types of SOA
▷ Service-oriented technology architecture can exist at different scopes or levels of implementation
▷ These implementation levels are referred to 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
3. Service Inventory Architecture : the architecture that
supports a collection of related services that are
independently standardized and governed
4. Service-Oriented Enterprise Architecture:
The architecture of the enterprise itself, to whatever
extent it is service-oriented

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

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

54. 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 requirements for successful SOA adoption
enables an organization to properly scope its adoption effort

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

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

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

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

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

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

61. 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 programs labeled as services)

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

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

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

65. Bottom-up approach
▷ Tactically focused in that it makes the fulfillment of immediate business requirements a
priority and 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.

66. Top-down approach
▷ Represent Spectrum Strategy view for enterprise.
▷ Advocates the completion of an inventory analysis prior to 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.

67. meet-in-the-middle Approach ( Agile Delivery)
▷ Allows for an on-going analysis and definition of a service inventory blueprint, while
high-priority services 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.

68. Project and Lifecycle Stages
1. SOA Adoption Planning
2. Service Inventory Analysis
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 primary stages related to SOA projects and the overall service lifecycle:
http://serviceorientation.com/soaproject/projectlifecycle

69. Service Oriented Analysis

70. Service Oriented Design

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

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

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

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

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

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

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

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

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

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

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

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

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

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

85. Questions

86. “To Be continue
with SOA


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

88. Thanks!
SOA Architecture Certification
You can find me at:
@MohamedZekus
eng.mohamedzakarya@gmail.com