1. SOA White Paper Concepts February 20, 2009

2. IT Infrastructure Planning Committee SOA – A Definition Service-Oriented Architecture (SOA) is an approach to designing systems where IT resources are made available in a network as services that are accessed in a standardized wayService-Oriented Architecture (SOA) is an approach to designing systems where IT resources are made available in a network as services that are accessed in a standardized way

3. IT Infrastructure Planning Committee SOA Terms SOA – just like many other IT terms – often suffers from wide-spread ambiguity in the technology industry.SOA – just like many other IT terms – often suffers from wide-spread ambiguity in the technology industry. Terms defined in this section:Terms defined in this section: –Service –Service contract –Service definition –Service implementation –Service description –Service provider –Service consumer –Web service

4. IT Infrastructure Planning Committee What is a Service? Service: the most fundamental building block of a SOA is the service. A service implements one or more related capabilities exposed via a formal contract that is intended to be invoked and accessed by an external consumer.Service: the most fundamental building block of a SOA is the service. A service implements one or more related capabilities exposed via a formal contract that is intended to be invoked and accessed by an external consumer. Service Contract: A service contract is simply the terms for information exchange, providing the service’s technical constraints and requirements as well as any semantic information needed to consume the serviceService Contract: A service contract is simply the terms for information exchange, providing the service’s technical constraints and requirements as well as any semantic information needed to consume the service Service contract Capability e.g. Logging Service External Consumer

5. IT Infrastructure Planning Committee Anatomy of a Service 3 parts: service definition service implementation service description3 parts: service definition service implementation service description Service Description or “Service” Implementation Service Definition Concrete portion Abstract portion

6. IT Infrastructure Planning Committee Anatomy of a Service: Service Definition Contains the formal service contract described above. It is comprised of two parts:Contains the formal service contract described above. It is comprised of two parts: –Abstract portion: describes the functionality of the service. It is described by a series of technology-independent elements, including interface, operations and operation semantics, and data structure definitions –Concrete portion: describes how to access the service. It effectively acts as the intersection between the abstract portion and the service implementation. Service Definition Concrete portion Abstract portion

7. IT Infrastructure Planning Committee Anatomy of a Service: Service Implementation and Description Service Implementation – the core logic in support of the service contract. A service’s implementation is basically the code behind the service, often written in an application language like Java,.Net or C++.Service Implementation – the core logic in support of the service contract. A service’s implementation is basically the code behind the service, often written in an application language like Java,.Net or C++. Service Description – the aggregate of the service definition and the service implementation, represented by the dashed circle in the diagram below. The service description will be referred to as simply “service” throughout the rest of this white paper.Service Description – the aggregate of the service definition and the service implementation, represented by the dashed circle in the diagram below. The service description will be referred to as simply “service” throughout the rest of this white paper. Service Definition Aka “Service” Service Implementation

8. IT Infrastructure Planning Committee SOA Design Principles Design principles are simply practices that are generally accepted within an industry.Design principles are simply practices that are generally accepted within an industry. Often derived from years of best practice, and in the context of building IT system should be regarded as guidelines for the construction of the architecture and behavior of an IT system.Often derived from years of best practice, and in the context of building IT system should be regarded as guidelines for the construction of the architecture and behavior of an IT system. In SOA, just like in many of its predecessors e.g. Object-Oriented 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 organized and composed into distributable services.In SOA, just like in many of its predecessors e.g. Object-Oriented 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 organized and composed into distributable services. These design principles act as a means to help qualify services as capable of supporting the goals of the SOA, but they are not a hard- and-fast set of rules.These design principles act as a means to help qualify services as capable of supporting the goals of the SOA, but they are not a hard- and-fast set of rules. During systems design and implementation, there will be instances where combing certain principles will result in a conflict, and thus tradeoffs will need to be made.During systems design and implementation, there will be instances where combing certain principles will result in a conflict, and thus tradeoffs will need to be made.

9. IT Infrastructure Planning Committee 8 Design Principles Reusable logic is divided into services: logic that is potentially reusable is represented by a separate serviceReusable logic is divided into services: logic that is potentially reusable is represented by a separate service 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 descriptionServices 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 description 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 and its service consumers.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 and its service consumers. Services abstract underlying logic - only the service definition is visible to outside world. Everything else is invisible and irrelevant to other services.Services abstract underlying logic - only the service definition is visible to outside world. Everything else is invisible and irrelevant to other services. 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 layersServices 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 layers 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 execute this governance.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 execute this governance. 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.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. Services are discoverable – services should allow their human and machine discovery and understanding of their descriptions.Services are discoverable – services should allow their human and machine discovery and understanding of their descriptions.

10. IT Infrastructure Planning Committee From Service to SOA The end deliverable of a SOA is an optimized technology architecture, which an implementable model consisting of a combination of technologies, products, APIs, and other resources like compute, network and storage infrastructure.The end deliverable of a SOA is an optimized technology architecture, which an implementable model consisting of a combination of technologies, products, APIs, and other resources like compute, network and storage infrastructure. In a SOA, services must become the primary means by which enterprise capabilities and solution logic are represented.In a SOA, services must become the primary means by which enterprise capabilities and solution logic are represented. Not everything is a service!!! Good functional decomposition and service modeling techniques are criticalNot everything is a service!!! Good functional decomposition and service modeling techniques are critical –Example: Patient Records vs. Time Zone service candidates

11. IT 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 consumers of the service. That interface contains details of the operations, data type definitions, and access methods that are supported by that service. –Service Consumer: responsible for initiating the request from the service provider. The specifics of this interaction depend on the type of service architecture in question Service Consumer Service Provider Schema Interface PS_Impl. +AddPatient +UpdatePatient +DeletePatient Payload soap:binding https://myservice.com Service Implementation

12. IT Infrastructure Planning Committee Services Acting in Dual Roles Services themselves can behave as both service consumers and service providers, depending on its utilization at runtime.Services themselves can behave as both service consumers and service providers, depending on its utilization at runtime. Interaction A: when a service receives and responds to request messages it is acting as a service provider.Interaction A: when a service receives and responds to request messages it is acting as a service provider. 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 is also acting as a service consumer.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 is also acting as a service consumer. Service Consumer Service Provider Service Consumer A Service Provider B

13. IT Infrastructure Planning Committee Characteristics of Successful SOA Business-alignedBusiness-aligned –Technology architecture aligned with the business and strategic objectives of the organization –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 them as a new application, composite services or business processes. –Strong emphasis not only on designing reusable services, but also services that are able to be flexible deployed across a heterogeneous underlying infrastructure and still deliver predictable levels of performance, reliability and scalability. Minimize vendor dependenciesMinimize vendor dependencies –Designing around one specific vendor solution can lead to adoption of proprietary technologies and techniques and lock an organization in to vendor platform roadmaps. –Increases coupling and take away control

14. IT Infrastructure Planning Committee SOA and Interoperability Interoperability refers to a set of mechanisms in place that guarantee the sharing of data.Interoperability refers to a set of mechanisms in place that guarantee the sharing of data. SOA and service-oriented design principles can foster interoperability among services, but not intrinsically guarantee it.SOA and service-oriented design principles can foster interoperability among services, but not intrinsically guarantee it. It is a goal of this white paper to further develop a set of strategies for delivering interoperability by establishing how IHE profiles can provide the basis for interoperability in a SOA.It is a goal of this white paper to further develop a set of strategies for delivering interoperability by establishing how IHE profiles can provide the basis for interoperability in a SOA.

15. IT Infrastructure Planning Committee SOA and Web Services Emphasis on web services standards and technologies because it provides the most potential to apply the key principles of service orientation.Emphasis on web services standards and technologies because it provides the most potential to apply the key principles of service orientation. This is due to the wide-scale convergence that has been delivered by the emergence of the Internet and its related technologies and standards as the most widely adopted medium for distributed computing today.This is due to the wide-scale convergence that has been delivered by the emergence of the Internet and its related technologies and standards as the most widely adopted medium for distributed computing today. By exposing a service as a web service one can significantly increase reuse potential of a service because the service is accessible via a vendor-neutral communications framework, making it available to a much broader set of service consumers.By exposing a service as a web service one can significantly increase reuse potential of a service because the service is accessible via a vendor-neutral communications framework, making it available to a much broader set of service consumers. However…the principles of service-orientation are not exclusive to web services. In fact, as an architectural model, SOA is agnostic to any one set of technologiesHowever…the principles of service-orientation are not exclusive to web services. In fact, as an architectural model, SOA is agnostic to any one set of technologies

16. IT Infrastructure Planning Committee SOA is Technology Agnostic Service-oriented solutions can be constructed of services using technologies other than web services, like distributed object frameworks CORBA or DCOM, or even common Java or.Net components.Service-oriented solutions can be constructed of services using technologies other than web services, like distributed object frameworks CORBA or DCOM, or even common Java or.Net components. It is increasingly common that SOAs are comprised of both web service and other technologies, both new and old, where services are implemented as combination of web services and proprietary componentsIt is increasingly common that SOAs are comprised of both web service and other technologies, both new and old, where services are implemented as combination of web services and proprietary components Example: both have standardized service contracts and are subject to SOA design principlesExample: both have standardized service contracts and are subject to SOA design principles Service packaged as a Component Web Service WSDL as a service contract SOAP/ HTTP Java Interface as a service contract Native instantiation