SOA White Paper Concepts

1. SOA White PaperConcepts February 20, 2009

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

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

4. 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 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 Capability e.g. Logging Service contract External Consumer Service

5. Anatomy of a Service • 3 parts: service definition service implementation service description Abstract portion Implementation Service Definition Service Description or “Service” Concrete portion

6. Anatomy of a Service: Service Definition Service Definition • 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. Abstract portion Concrete portion

7. 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 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 Implementation Service Definition Aka “Service”

8. SOA Design Principles • 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. • 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. • 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. 8 Design Principles • Reusable 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 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 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 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 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.

10. 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. • 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 critical • Example: Patient Records vs. Time Zone service candidates

11. SOA Actors • 2 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 Schema Payload Interface PS_Impl. +AddPatient +UpdatePatient +DeletePatient Service Implementation soap:binding https://myservice.com Service Consumer Service Provider

12. Services Acting in Dual Roles • 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 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 Provider Service Consumer A B Service Consumer Service Provider

13. Characteristics of Successful SOA • Business-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-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 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. SOA and Interoperability • 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. • 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. 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. • 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. • 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 technologies

16. SOA is Technology Agnostic WSDL as a service contract • 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 components • Example: both have standardized service contracts and are subject to SOA design principles SOAP/HTTP Web Service Java Interface as a service contract Native instantiation Service packaged as a Component