Service Oriented Architecture (SOA) is the secret sauce of many software integration and internet technologies. The SOA Series includes five presentations based on IBM SOA Associate Certificate. It gives a very concise, practical overview of SOA concepts. The second presentation discusses SOA fundamentals, service, architectural concepts used in SOA, role of XML in SOA, role of a service registry and/or repository, business processes in the context of SOA, role of technology standards (such as SOAP, WSDL, WS-Security, BPEL, and WS-I), and role Web 2.0 in SOA.

1. SOA Concepts
Pouria Ghatrenabi
Based on IBM SOA Certificate Learning Objectives

2. Learning Objectives
• Define the concept of a service in SOA.
• Describe the architectural concepts used in SOA (for example: loose coupling and separation of
concerns.)
• Describe the roles that XML plays in SOA.
• Describe the role of a service registry and/or repository in SOA.
• Explain what a business process is in the context of SOA (including business process management
and automation) and how it facilitates business flexibility.
• Determine the role that technology standards (SOAP, WSDL, WS-Security, BPEL, WS-I, ) play in
SOA.
• Describe the role that Web 2.0 and its related technologies play in SOA (for example: REST and
AJAX.)

3. The Concept of Service

4. A service is representative of a repeatable business task
business service can be made up of sub-processes
Using a top-down methodology, you identify a business process and
then, within that process, the set of tasks that are performed.
The tasks in a business process are services and the business
process is a composition of services.
Ref: Keen, (2007), p5

5. Ref: Buecker et al. (2008), p394

6. SOA Architectural Concepts

7. Basic Service Validation
Principles Loose Coupling
Encapsulation
Stateless
Technology
Neutral
Ref: Keen (2007)

8. Loose Coupling
• Loosely coupling between a service provider and consumers means
minimizing the number of things that a consumer needs to know
about the provider or vice versa.
• If a change is made by any party (the consumer, provider, or
mediating infrastructure) to any aspect of a service that is decoupled,
there should be no need to make subsequent changes in the other
parties.
Ref: Keen (2007)

9. Loose Coupling (continued)
• Reduces support costs, the impact of changes in business processes,
and IT applications, and enhances adaptability
• Reduces dependencies between applications to improve availability
and manageability of user applications
• Location transparency is a technical aspect of loose coupling. The
consumer does not require explicit knowledge of where the service is
executed.
Ref: Keen (2007)

10. Encapsulation
• Access to functions and data must be through a well-defined interface
that forms a contract between the service provider and the service
consumer.
• Encapsulation hides any data or behavior in the service
implementation that is specific only to the internal working of the
service and irrelevant to the service consumer.
Ref: Keen (2007)

11. Statelessness
• The expectation that a service provider remembers a transient state
relevant to a particular consumer adds complexity to service
providers.
• Avoidance of complexity promotes the opportunity to provide more
readily scalable and highly available service providers at a lower unit
cost.
Ref: Keen (2007)

12. Technology Neutrality
• Consumers on any platform must be able to invoke services provided
on any platform
Ref: Keen (2007)

13. Service Granularity
• Before SOA, the focus was on narrow, technical subtasks. It is called a
fine “level of granularity” or low “degree of abstraction.”
• Granularity is the amount of function a service exposes.
• A fine-grained service provides smaller units of a business process,
• A coarse-grained service provides a larger business task that contains a higher
number of substeps.
• Every company has a different view of how granular it requires its
service to be, based on its business design. Services cannot be too big
or too small, but must be just right.
Ref: Carter (2007), Ch 5

14. Service Granularity (continued)
• If the service is too big, that yields less reuse. If the service is too
small, you end up with performance hits and poor mapping between
business tasks and the services that support them.
• granularity is always a function of business process decomposition—
the more detailed the business process, the more finely grained the
services.
Ref: Carter (2007), Ch 5

15. Separation of Concerns
• In SOA, the business process controls the flow of services. The business
process drives the flow of events, calls and coordinates services, and
creates a context for them to intercommunicate.
• Business processes represent the business abstraction; decoupled from the
implementation of services, a process cares about the flow of business.
• This separation of concerns not only allows more focus on process
creation, it makes it easier to edit processes according to need without
having to edit the underlying service implementations.
Ref: Mabrouk, (2008)

16. The Role of XML in SOA

17. • XML is a common data representation that can be used as the medium of
exchange between programs that are written in different programming
languages and execute different kinds of machine instructions.
• XML is the basis for all web services technologies and the key to
interoperability; every web services specification is based on XML.
• In particular, SOAP formalizes the exchange of information written in XML,
and WSDL describes the SOAP details in an XML vocabulary.
Ref: Carter (2007), Ch 5

18. Service Registry and Repository
(BSRR)

19. BSRR
• BSRR is a place where you store information about services in your
systems that you already use, that you plan to use, or that you want
to be aware of.
• BSRR enables centralized management of business services and
interactions among SOA infrastructure elements
• BSRR enforces standards and policies that govern interactions among
service providers, users, and assets.
Ref: Carter (2007), Ch 5

20. BSRR
• BSRR promotes closer alignment to business objectives, reuse of IT
assets, and incremental adoption of SOA
• The right BSRR supports interoperability via standards (such as WSDL,
XML, XSD, BPEL, SCA) to leverage existing investments and
infrastructure and support true interoperability.
• A service registry can step into the role of governing services by
enforcing compliance for subscribing services. This helps ensure the
integrity of service governance and policies.
Ref: Carter (2007), Ch 5 and Mabrouk, (2008)

21. Ref: Carter (2007), Ch 5

22. Role of BSRR in SOA Lifecycle
Ref: Carter (2007), Ch 8
Service Modeling
• A registry and repository can be used to create or reuse service taxonomies,
vocabularies, and XML schemas
Service Development or Assembly
• A registry and repository can be used to locate services for reuse and to enable
service composition
Service Deployment
• Service descriptions stored in a registry and repository are used by runtimes such
as an ESB to enable dynamic interaction between services

23. BSRR Capabilities
Publish and Find Services
• Publishing the services from different sources,
• The capability to find the services is the heart of reuse,
• Identify common services to avoid duplication and foster reuse,
• Needs also to manage metadata, classify services, subscribe to changes and updates, and
send change notifications.
Govern
• Enable the management of your SOA assets through the full production lifecycle
(development, test, production, and retirement),
• This capability is needed throughout the lifecycle to control by user, by user type, and by
where a service is on the governance lifecycle.
Ref: Carter (2007), Ch 5

24. BSRR Capabilities (continued)
Enrich
• Enhance connectivity by enabling dynamic and efficient interactions between
services at runtime,
• By leveraging dynamic linkage, it enables ESB to find the best-fitting endpoint
when the request is received, supporting loose coupling.
Manage
• Enable policy enforcement and conduct impact analysis to help optimize service
performance,
• Enable the measurement of services metrics,
• Understanding of the services performance can assist the business with its SLAs.
Ref: Carter (2007), Ch 5

25. Business Processes in the Context
of SOA

26. • Existing business processes are decomposed into discrete units of
business function termed services.
• These services are then recombined into business processes in a
more flexible manner. Such decomposition has led to the emergence
of collaborative eco-systems.
• In Service-oriented approach to BPR, a common business logic is
available in reusable services that can be performed where it is most
appropriate, regardless of organizational boundaries.
Ref: Buecker et al. (2008), p6

27. Ref: Buecker et al. (2008), p7

28. Business Processes and Agility
• Tight coupling between services makes the resulting business process
fragile and difficult to change to meet the evolving needs of the business.
• By moving functionality, (e.g. flow control, translation of data formats and
protocols, and identity propagation) between services out of the
application logic and into the services infrastructure, flexibility can be
improved greatly.
• In this case, each service only needs to know how to connect to the service
infrastructure.
Ref: Buecker et al. (2008), p8

29. Connectivity using a service-oriented infrastructure
Ref: Buecker et al. (2008), p8

30. The Role of Web 2.0 in SOA

31. The value proposition
of Web 2.0 is similar to
that of SOA—allowing
change to occur
without a lot of pain.
Also similar to SOA,
Web 2.0 requires a
cultural change.
Together, SOA and
Web 2.0 fulfill the
promise of flexibility
and agility for a
business process.
Ref: Carter (2007), Ch 8

32. Mashups and SOA
• Mash-ups represent the practical bridge between SOA and Web 2.0.
• If a Web 2.0 mash-up represents the coming together of information
from disparate sources, SOA infrastructure provides those
information sources.
• Scalable, dynamic, and accessible over the Web, SOA services are the
raw material for Web 2.0 mash-ups.
Ref: Carter (2007), Ch 8

33. REST, AJAX, and SOA
• Both AJAX and REST are enablers for SOA
• REST can be used to expose services, and AJAX is used to build front
ends.
• REST is a lightweight approach to interconnecting front-end and
public Internet services, and the use of more structured services in
back-end systematic services is advised.
Ref: Carter (2007), Ch 8

34. Ref: Carter (2007), Ch 8

35. References
• Buecker, A., Ashley, P., Borrett, M., Lu, M., Muppidi, S., Readshaw, N., &
others. (2008). Understanding SOA Security Design and Implementation.
IBM Redbooks.
• Carter, S. (2007). The new language of business: SOA & Web 2.0. Pearson
Education.
• Keen, M. (2007). Implementing Technology to Support SOA Governance and
Management. IBM, International Technical Support Organization.
• Mabrouk, M. I. (2008, September 5). SOA fundamentals in a nutshell.
Retrieved December 12, 2015, from
http://www.ibm.com/developerworks/webservices/tutorials/ws-soa-
ibmcertified/ws-soa-ibmcertified.html