SOA White PaperSOA White PaperConceptsConcepts

February 20, 2009February 20, 2009

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

SOA – A Definition

• Service-Oriented Architecture (SOA) is an approach to Service-Oriented Architecture (SOA) is an approach to designing systems where IT resources are made available designing systems where IT resources are made available in a network as services that are accessed in a in a network as services that are accessed in a standardized waystandardized way

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

SOA Terms

• SOA – just like many other IT terms – often suffers from SOA – just like many other IT terms – often suffers from wide-spread ambiguity in the technology industry.wide-spread ambiguity in the technology industry.

• Terms defined in this section:Terms defined in this section:– ServiceService– Service contractService contract– Service definitionService definition– Service implementationService implementation– Service descriptionService description– Service providerService provider– Service consumerService consumer– Web serviceWeb service

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

What is a Service?

• Service: the most fundamental building block of a SOA is the Service: the most fundamental building block of a SOA is the serviceservice. A service . A service implements one or more related capabilities exposed via a formal contract that is implements one or more related capabilities exposed via a formal contract that is intended to be invoked and accessed by an external consumer. intended to be invoked and accessed by an external consumer.

• Service Contract: A Service Contract: A service contractservice contract is simply the terms for information is simply the terms for information exchange, providing the service’s technical constraints and requirements as well exchange, providing the service’s technical constraints and requirements as well as any semantic information needed to consume the serviceas any semantic information needed to consume the service

Servicecontract

Capability e.g. Logging

Service

ExternalConsumer

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

Anatomy of a Service

• 3 parts: 3 parts: service definition service definition service implementationservice implementationservice descriptionservice description

Service Descriptionor “Service”

Implementation

ServiceDefinition

Concrete portion

Abstract portion

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

Anatomy of a Service: Service Definition

• Contains the formal service contract Contains the formal service contract described above. It is comprised of two described above. It is comprised of two parts: parts: – Abstract portion: describes the functionality of Abstract portion: describes the functionality of

the service. It is described by a series of the service. It is described by a series of technology-independent elements, including technology-independent elements, including interface, operations and operation semantics, interface, operations and operation semantics, and data structure definitionsand data structure definitions

– Concrete portion: describes how to access the Concrete portion: describes how to access the service. It effectively acts as the intersection service. It effectively acts as the intersection between the abstract portion and the service between the abstract portion and the service implementation.implementation.

ServiceDefinition

Concrete portion

Abstract portion

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

Anatomy of a Service: Service Implementation and Description

• Service Implementation – the core logic in Service Implementation – the core logic in support of the service contract. A service’s support of the service contract. A service’s implementation is basically the code behind the implementation is basically the code behind the service, often written in an application language service, often written in an application language like Java, .Net or C++. like Java, .Net or C++.

•   • Service Description – the aggregate of the Service Description – the aggregate of the

service definition and the service implementation, service definition and the service implementation, represented by the dashed circle in the diagram represented by the dashed circle in the diagram below. The service description will be referred to below. The service description will be referred to as simply “service” throughout the rest of this as simply “service” throughout the rest of this white paper.white paper. Service

DefinitionAka “Service”

ServiceImplementation

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

SOA Design Principles

• Design principles are simply practices that are generally accepted Design principles are simply practices that are generally accepted within an industry. within an industry.

• Often derived from years of best practice, and in the context of building Often derived from years of best practice, and in the context of building IT system should be regarded as IT system should be regarded as guidelinesguidelines for the construction of the for the construction of the architecture and behavior of an IT system. architecture and behavior of an IT system.

• In SOA, just like in many of its predecessors e.g. Object-Oriented In SOA, just like in many of its predecessors e.g. Object-Oriented Analysis and Design (OOAD), there a number of key design principles Analysis and Design (OOAD), there a number of key design principles that are intended to guide how the logic of an IT system should be that are intended to guide how the logic of an IT system should be organized and composed into distributable services.organized and composed into distributable services.

• These design principles act as a means to help qualify services as These design principles act as a means to help qualify services as capable of supporting the goals of the SOA, but capable of supporting the goals of the SOA, but they are not a hard-they are not a hard-and-fast set of rules.and-fast set of rules.

• During systems design and implementation, there will be instances During systems design and implementation, there will be instances where combing certain principles will result in a conflict, and thus where combing certain principles will result in a conflict, and thus tradeoffs will need to be made.tradeoffs will need to be made.

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

8 Design Principles

• Reusable logic is divided into services: logic that is potentially reusable is represented by a separate Reusable logic is divided into services: logic that is potentially reusable is represented by a separate serviceservice

• Services share a formal contract - a formal contract is the only requirement for services to interact, Services share a formal contract - a formal contract is the only requirement for services to interact, which defines the terms for information exchange and supplemental service descriptionwhich defines the terms for information exchange and supplemental service description

• Services are loosely coupled - services must be designed to interact on a loosely coupled basis, Services are loosely coupled - services must be designed to interact on a loosely coupled basis, which means that should minimize dependencies between its service contract, its implementation which means that should minimize dependencies between its service contract, its implementation and its service consumers.and its service consumers.

• Services abstract underlying logic - only the service definition is visible to outside world. Everything Services abstract underlying logic - only the service definition is visible to outside world. Everything else is invisible and irrelevant to other services.else is invisible and irrelevant to other services.

• Services are composable - services may comprised other services, which allows logic to be Services are composable - services may comprised other services, which allows logic to be represented at different levels of granularity and promotes reuse and creation of abstraction layersrepresented at different levels of granularity and promotes reuse and creation of abstraction layers

• Services are autonomous - the logic governed by a service resides within and explicit boundary. A Services are autonomous - the logic governed by a service resides within and explicit boundary. A service has complete autonomy within this boundary, with no dependencies on other services to service has complete autonomy within this boundary, with no dependencies on other services to execute this governance.execute this governance.

• Services are stateless - services should be designed to manage state only when required, as it Services are stateless - services should be designed to manage state only when required, as it impairs their ability to remain loosely coupled and compromises availability and scalability potential.impairs their ability to remain loosely coupled and compromises availability and scalability potential.

• Services are discoverable – services should allow their human and machine discovery and Services are discoverable – services should allow their human and machine discovery and understanding of their descriptions.understanding of their descriptions.

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

From Service to SOA

• The end deliverable of a SOA is an The end deliverable of a SOA is an optimized technology optimized technology architecturearchitecture, which an implementable model consisting of a , which an implementable model consisting of a combination of technologies, products, APIs, and other combination of technologies, products, APIs, and other resources like compute, network and storage resources like compute, network and storage infrastructure.infrastructure.

• In a SOA, services must become the primary means by In a SOA, services must become the primary means by which enterprise capabilities and solution logic are which enterprise capabilities and solution logic are represented.represented.

• Not everything is a service!!! Good functional Not everything is a service!!! Good functional decomposition and service modeling techniques are criticaldecomposition and service modeling techniques are critical– Example: Patient Records vs. Time Zone service candidatesExample: Patient Records vs. Time Zone service candidates

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

SOA Actors

• 2 actors in a typical* SOA interaction2 actors in a typical* SOA interaction– Service Provider: exposes an external interface through which it can be invoked by Service Provider: exposes an external interface through which it can be invoked by

consumers of the service. That interface contains details of the operations, data type consumers of the service. That interface contains details of the operations, data type definitions, and access methods that are supported by that service.definitions, and access methods that are supported by that service.

– Service Consumer: responsible for initiating the request from the service provider. Service Consumer: responsible for initiating the request from the service provider. The specifics of this interaction depend on the type of service architecture in The specifics of this interaction depend on the type of service architecture in questionquestion

Service Consumer

Service Provider

Schema

Interface

PS_Impl.

+AddPatient+UpdatePatient+DeletePatient

Payload

soap:bindinghttps://myservice.com

Service Implementation

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

Services Acting in Dual Roles

• Services themselves can behave as both service consumers and service Services themselves can behave as both service consumers and service providers, depending on its utilization at runtime.providers, depending on its utilization at runtime.

•

• Interaction A: when a service receives and responds to request Interaction A: when a service receives and responds to request messages it is acting as a service provider. messages it is acting as a service provider.

• Interaction B: As part of processing that request, that same web service Interaction B: As part of processing that request, that same web service can invoke other services as part of its own internal logic, in which case it can invoke other services as part of its own internal logic, in which case it is also acting as a service consumer.is also acting as a service consumer.

Service Consumer Service Provider

Service Consumer

A

Service Provider

B

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

Characteristics of Successful SOA

• Business-alignedBusiness-aligned– Technology architecture aligned with the business and strategic Technology architecture aligned with the business and strategic

objectives of the organizationobjectives of the organization– Permits SOA to evolve in unison with the business architecture. Permits SOA to evolve in unison with the business architecture.

• Business process-drivenBusiness process-driven– Enterprise need to be able to assemble a set of services and configure Enterprise need to be able to assemble a set of services and configure

them as a new application, composite services or business processes. them as a new application, composite services or business processes. – Strong emphasis not only on designing reusable services, but also Strong emphasis not only on designing reusable services, but also

services that are able to be flexible deployed across a heterogeneous services that are able to be flexible deployed across a heterogeneous underlying infrastructure and still deliver predictable levels of underlying infrastructure and still deliver predictable levels of performance, reliability and scalability. performance, reliability and scalability.

• Minimize vendor dependenciesMinimize vendor dependencies– Designing around one specific vendor solution can lead to adoption of Designing around one specific vendor solution can lead to adoption of

proprietary technologies and techniques and lock an organization in to proprietary technologies and techniques and lock an organization in to vendor platform roadmaps. vendor platform roadmaps.

– Increases coupling and take away controlIncreases coupling and take away control

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

SOA and Interoperability

• Interoperability refers to a set of mechanisms in place that Interoperability refers to a set of mechanisms in place that guaranteeguarantee the sharing of data. the sharing of data.

• SOA and service-oriented design principles can foster SOA and service-oriented design principles can foster interoperability among services, but not intrinsically interoperability among services, but not intrinsically guarantee it. guarantee it.

• It is a goal of this white paper to further develop a set of It is a goal of this white paper to further develop a set of strategies for delivering interoperability by establishing how strategies for delivering interoperability by establishing how IHE profiles can provide the basis for interoperability in a IHE profiles can provide the basis for interoperability in a SOA.SOA.

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

SOA and Web Services

• Emphasis on web services standards and technologies because Emphasis on web services standards and technologies because it provides the most potential to apply the key principles of it provides the most potential to apply the key principles of service orientation.service orientation.

• This is due to the wide-scale convergence that has been This is due to the wide-scale convergence that has been delivered by the emergence of the Internet and its related delivered by the emergence of the Internet and its related technologies and standards as the most widely adopted medium technologies and standards as the most widely adopted medium for distributed computing today. for distributed computing today.

• By exposing a service as a web service one can significantly By exposing a service as a web service one can significantly increase reuse potential of a service because the service is increase reuse potential of a service because the service is accessible via a vendor-neutral communications framework, accessible via a vendor-neutral communications framework, making it available to a much broader set of service consumers.making it available to a much broader set of service consumers.

• However…the principles of service-orientation are not exclusive However…the principles of service-orientation are not exclusive to web services. In fact, as an architectural model, SOA is to web services. In fact, as an architectural model, SOA is agnostic to any one set of technologiesagnostic to any one set of technologies

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

SOA is Technology Agnostic

• Service-oriented solutions can be Service-oriented solutions can be constructed of services using constructed of services using technologies other than web services, technologies other than web services, like distributed object frameworks like distributed object frameworks CORBA or DCOM, or even common CORBA or DCOM, or even common Java or .Net components.Java or .Net components.

• It is increasingly common that SOAs It is increasingly common that SOAs are comprised of both web service and are comprised of both web service and other technologies, both new and old, other technologies, both new and old, where services are implemented as where services are implemented as combination of web services and combination of web services and proprietary componentsproprietary components

• Example: both have standardized Example: both have standardized service contracts and are subject to service contracts and are subject to SOA design principlesSOA design principles Service packaged as

a Component

Web Service

WSDL as a service contract

SOAP/HTTP

Java Interface as a service contract

Native instantiation