Service Oriented Architecture Definitions Service SOA Classic View

Service Oriented Architecture • • • Definitions: Service & SOA Classic View of a Service Classic View of a SOA Characteristics SOA Principles Service Architecture Composition A Few Key SOA Protocols Steps to Build an SOA Web Service Model

Definitions: Service & SOA • A service is a reusable component that can be used as a building block to form larger, more complex business-application functionality. • Service-Oriented Architecture (SOA) is an architectural style. Applications built using an SOA style deliver functionality as services that can be used or reused when building applications or integrating within the enterprise or trading partners. • A set of components which can be invoked, and whose interface description can be published and discovered (W 3 C).

Classic View of a Service • Provided by a Provider • Exposed Via a Directory • Looked up and located by a Consumer

Classic View of a SOA

SOA Characteristics 1. 2. 3. 4. 5. 6. 7. 8. Based on open standards Foster inherent reusability Foster intrinsic interoperability Emphasizes extensibility Fundamentally autonomous Promotes dynamic discovery Promotes architectural composability Promotes loose coupling throughout the enterprise 9. Supports incremental implementation

SOA Principles 1. 2. 3. 4. 5. 6. 7. 8. Standardized Service Contracts Loose Coupling Abstraction Reusability Autonomy Statelessness Discoverability Composability

SOA Principles 1. Standardized Service Contracts • Services use standardized service contracts to – Express their purpose – Express their capabilities 2. Loose Coupling • Create specific types of relationships within and outside of service boundaries with a constant emphasis on reducing (“loosening”) dependencies between – Service contract – Service implementation – Service consumers

SOA Principles 3. Abstraction • Service contracts only contain essential information and information about services is limited to what is published in service contracts • Avoid the proliferation of unnecessary service information, meta-data. • Hide as much of the underlying details of a service as possible. 4. Reusability • Services contain and express agnostic logic and can be positioned as reusable enterprise resources

SOA Principles 5. Autonomy • Services exercise a high level of control over their underlying runtime execution environment. " • Represents the ability of a service to carry out its logic independently of outside influences 6. Statelessness • Services minimize resource consumption by deferring the management of state information when necessary

SOA Principles 7. Discoverability • Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted • Store meta data in a service registry or profile documents 8. Composability • Services are effective composition participants, regardless of the size and complexity of the composition • Related to Reusability principle

Service Architecture Composition • Service architectures are composed of 1. Services • • Units of processing logic Example: Credit card Service 2. Messages • • Units of communications between services Needed for services to do their job 3. Operations • • Units of Work Example: Determine Cost of Attendance 4. Processes • • Composed / orchestrated groups of services Example: Financial Aid Disbursement

A Few Key SOA Protocols 1. Universal Description, Discovery, and Integration, UDDI. Defines the publication and discovery of web service implementations. 2. The Web Services Description Language, WSDL, is an XMLbased language that defines Web Services. 3. SOAP is the Service Oriented Architecture Protocol. It is a key SOA in which a network node (the client) sends a request to another node (the server). 4. The Lightweight Directory Access Protocol, or LDAP is protocol for querying and modifying directory services. 5. Extract, Transform, and Load, ETL, is a process of moving data from a legacy system and loading it into a SOA application.

Eight steps to Build an SOA 1. Business needs come first (not services) What problem are we trying to solve? 2. What aspects can be implemented as services? Old services? New services? Legacy wrappers? 3. Track services with registries and repositories. 4. Govern the services. We need to encourage desired behavior at many levels, across enterprises, and at different stages. We need to monitor behavior, enforce policies & assess user satisfaction.

Eight steps to Build an SOA 5. Secure the services. Using established standards, we need privacy, identification, authentication, and authorization. This may need to be federated security (over more than one organization. ) 6. Manage the services. Are messages arriving on time? Is everything operating properly? 7. Virtualization through mediation. Are we free to move and change the services? Do we need an ESB that acts as a central hub for message routing and transformations? 8. Design for interoperability through the adoption of standards.

Web Service Model