SOA ConceptsPouria Ghatrenabi

Based on IBM SOA Certificate Learning Objectives

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

The Concept of Service

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

Ref: Buecker et al. (2008), p394

SOA Architectural Concepts

Basic Service Validation Principles Loose Coupling

Encapsulation

Stateless

Technology Neutral

Ref: Keen (2007)

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)

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)

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)

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)

Technology Neutrality• Consumers on any platform must be able to invoke services provided

on any platform

Ref: Keen (2007)

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

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

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)

The Role of XML in SOA

• 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

Service Registry and Repository (BSRR)

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

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)

Ref: Carter (2007), Ch 5

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

BSRR CapabilitiesPublish 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

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

Business Processes in the Context of SOA

• 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

Ref: Buecker et al. (2008), p7

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

Connectivity using a service-oriented infrastructure

Ref: Buecker et al. (2008), p8

The Role of Web 2.0 in SOA

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

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

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

Ref: Carter (2007), Ch 8

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