Introduction to Service Oriented Architecture (SOA)

Introduction to Service

Oriented Architecture (SOA)

Hari Rajagopal

Agenda

ƒ

Definitions

ƒ

Background

ƒ

SOA principles

ƒ

Case study

ƒ

Summary

Component

ƒ

Reusable unit of code, typically developed

for a specific project or app that has been

packaged in a way that it can be reused

ƒ

Typically a POJO (plain old Java object)

What Is a Service ?

ƒ

More generic than a ‘web service’ !

•

Although that is how the majority are deployed

ƒ

A well defined unit of software that

¾

Performs a specific function

¾

Complete in itself

Classic View of a Service

ƒ

Provided by a ‘provider’

ƒ

Exposed via

a ‘directory’

Service Discovery…

ƒ

Has not lived up to its promise

¾

XML is not 100% machine understandable

¾

RDF descriptions may be the key??

•

(Paul Giangarra devotes a section of his talk to this)

ƒ

Services are still ‘handed’ to clients with

documentation, API support groups handle

issues

Enterprise Service Bus

ƒ

Is a standards based messaging platform

that provides XML transforms, content based

routing

ƒ

Can be used as the basis for implementing

the transport layer of SOA

ESB Usage Patterns

ƒ

Router

ƒ

Broker

ƒ

Adapter

Router

ƒ

Content based

¾

Typically introspects into the message and

determines target endpoint

¾

Configurable using XSLT expressions

¾

Used for routing based on customer and/or

framework cues inserted in the message stream

•

Another case for keeping the pattern of interception

active within the framework

Service Oriented Architecture

ƒ

An architecture that emphasizes:

¾

Coupling of existing and new architectures

seamlessly

•

Moves components out of silos into the mainstream

¾

Responsive and agile architecture

Where Did It Come From ?

ƒ

SOA has been around in various guises

•

Implementation has become easier due to the advent

of WS-standards

ƒ

Some of these may sound familiar

¾

Object Brokers (ORB)

¾

RPC based brokers

Is a SOA Simply Web

Services?

Web Services are one possible means

of implementing a SOA

In the past, client-server SOAs have

been attempted

SOA Functionality

ƒ

Base functionality of a SOA implementation:

¾

Deploy services within its domain

¾

Integrate the services and make them available

¾

Orchestrate the integrated services

SOA Structure

ƒ

Basic unit of a SOA framework is a service

ƒ

Integration usually occurs through open

systems protocols (SOAP, JMS )

ƒ

Orchestration is accomplished using

Service Network

ƒ

A application level network that leverages

and implements a SOA

ƒ

Consists of various interacting applications

that are composed of services (facilities) that

are hosted within a SOA

ƒ

True enterprise integration and reuse

What Does a SOA Buy You?

ƒ

Reusable services

ƒ

Applications are composed of services

rather

than monolithic units

ƒ

Facilities provided by the SOA framework

leave the developer free to code business

logic

What Are the Participants?

ƒ

Servers (Web and application)

ƒ

Directories / registries

ƒ

Routers / brokers

ƒ

Enterprise Service Bus

Acronyms

ƒ

GDS – Global Distribution Service

ƒ

Service provider – in this case airlines, rental

car companies, hotel chains

ƒ

Vendors – see above, except now we have

SOA Implementations

The classic ‘build versus buy’

dilemma

Trade-offs

ƒ

Build

¾

Expensive

¾

In-house expertise

needed

¾

Proprietary

implementation

¾

Lack of input to

standards bodies

ƒ

Buy

¾

Expensive (long term)

¾

In-house expertise

needed to develop

against

¾

Tied to vendor

Some Travel Company

ƒ

Primary business focus is the housing and

supply of travel related information

¾

Air itineraries, hotel reservations, car rentals

ƒ

Question:

¾

How do we provide this information to different

Solution

ƒ

1

st

phase – expose traditional artifacts as

SOAP based web services that are easily

available to clients

ƒ

2

nd

phase – house these services within a

SOA framework such that they are reusable

across the enterprise

Phase1

ƒ

Put Web Service front ends on legacy assets

such as GDS data

¾

These are housed on ‘big-iron’ mainframes

¾

Expose these

via

XML based APIs

Flaws Revealed

ƒ

Data is still in the legacy format

ƒ

Scalability issues

ƒ

No way to bill for the transactions

Which Leads to the Following…

ƒ

What are some of the facilities provided by a

SOA ?

¾

Security

¾

Service lifetime management

¾

Reliability

SOA

ƒ

Design and develop a messaging core

ƒ

Use standard protocols to interface with

external entities

ƒ

Build with the philosophy of location

SOA

(Continued)

ƒ

Build an agile core that is merely a message

router (much like a bus)

ƒ

In the interests of scalability and security

partition the implementation between the

presentation and business tier (note: the

codebase running on every tier is the same,

Architectural Layout

SOA

framework

gateway

_broker

client

Service(s)

Building Blocks

ƒ

Apache Axis

ƒ

Fiorano ESB

ƒ

Tomcat

SOA Provides Services Too…

ƒ

Infrastructure services are provided to

developers

¾

Authentication of clients using the services

¾

Logging of transactions

¾

Security and DOS attack prevention

¾

Load based routing and balancing

Gateway Tasks

ƒ

In the previous slide, the gateway layer:

¾

Receives messages

¾

Verifies authenticity

¾

Performs format translation (more on this later)

¾

Routes to the appropriate service endpoint

Gateway Architecture

ƒ

Servlet based

ƒ

Uses filters to intercept and process

messages

Authentication

ƒ

In this case since most clients were coming

in using HTTPS and port 443 simple Basic

authentication was used

ƒ

Authentication information is carried in the

After Basic Authentication…

ƒ

A token is carried out of band with the

payload

ƒ

This ‘call-context’ also contains correlation

information for reconstituting audit info

ƒ

The token is re-asserted at various points

Service Broker

ƒ

The broker serves as a lookup agent

ƒ

It also initializes the services and brings

them into play

¾

Note: the services are dormant and waiting

since the SOA framework startup (lazy init)

Registry Information

ƒ

Service name

ƒ

Service version

ƒ

Service payload format

¾

Input type

¾

Output type

Payload Formats

ƒ

Object or XML ?

ƒ

XML – usable by diverse client platforms

ƒ

Object – performance gains

Transcoding

ƒ

SOAP – ‘lingua franca’

is XML

ƒ

Objects work best for performance

Long Running Transactions

ƒ

Typically web service transaction times span

more resources than we are used to

ƒ

ACID conditions may not be enforceable

ƒ

Can we relax any of these?

ƒ

Which ones?

¾

In some cases consistency is relaxable

¾

In others – atomicity

Business Domain Model

ƒ

A common representation of the assets of

the business

ƒ

Reusable across domains within diverse

development environments

ƒ

Language neutral model to base services

ƒ

Ease of service interoperability

How Are Services Used?

ƒ

Located by name and version

ƒ

Accessed by clients that generate interfaces

based on WSDL

ƒ

WSDL uses XML types that derive from the

BDM Based Approach

ƒ

Develop your business model (UML)

ƒ

Generate XSD schema from the model

ƒ

Compose service interfaces from these

Routing

ƒ

Typically, gateways route to brokers within

the framework

ƒ

This allows

¾

Load based routing

¾

Transparent routing to upgraded services

¾

Handling of version inconsistencies

Broker to Broker Call

ƒ

Client calls service A on a Service network

ƒ

Gateway authenticates the client

ƒ

Gateway determines whether the

appropriate service version exists at that

node

Alternate Scenario

ƒ

The version of the service requested by the

client (based on attribute in the payload) is

not found at this node

ƒ

Gateway:

¾

Looks up service info for that domain

¾

Finds an alternate

¾

Applies transform as needed (object –> XML)

¾

Routes to the appropriate node

Deployment Strategy

ƒ

A rack of inexpensive bladeservers

ƒ

Identical codebase on each blade

ƒ

A spare pool of blades

Summary

ƒ

Build a micro-broker routing core

ƒ

Build in SLA management from the get go

ƒ

Use COTS ESBs to build the transport

backbone and do your transcoding

So, Now That It’s Built…

$1 million question is –

Will they come ?

Service Level Agreements

ƒ

A Service Level Agreement (SLA) defines the

minimum level of service that a client will

tolerate or the business has contracted to

provide

Service Level Objectives

ƒ

The SLA with a client may be composed of

one or more Service Level Objectives (SLO)

ƒ

These include:

¾

Response time

¾

Availability and uptime of service

¾

Accuracy of data returned

Example of a SLA

ƒ

United airlines contracts with a website

provider that presents its fares to the public

¾

A customer shall have a mean response time of

5 seconds

¾

This shall be averaged over a month

¾

The accuracy (matching of quoted fares

vs

Backing Up Your Claims

ƒ

How do you deliver this level of service ?

¾

Manage your application dynamically

¾

Monitor it so you can prove response times,

Service Level Management

ƒ

Monitoring

¾

Is a service level threshold exceeded ?

ƒ

Management

¾

Taking corrective measures to restore the level

Back to Our Case Study

ƒ

A COTS – AmberPoint SLM manager

ƒ

Custom code to integrate the SLM manager

with the SOA framework

Business Process Control

ƒ

Now that services are built and available,

how are they to be reused within the

enterprise?

¾

Compose ‘Meta’ services of the more granular

services

Study…

ƒ

Finer grained services would be:

¾

Air availability or Flight Information lookup

¾

Booking service

¾

Travel codes translator

¾

Credit card authorization service

¾

…

¾

The finer grained services are rarely used

directly by web clients – exception being the

TCT

Orchestration of Services

ƒ

What happens when a vendor changes,

inventory is not available or a route to a GDS

is unavailable on the network ?

ƒ

Business rules defined in BPEL4WS

automatically route the service to other

resources to satisfy the request

Meta Service

ƒ

Trip Planner service

¾

Takes trip endpoints and returns an collated

response that displays trip choices, different

routes, schedules

•

Uses FLIFO to get a list of possible routes and

schedules

•

Uses the travel codes translator to decode industry

specific codes (DEN, LAX)

•

Uses Destination Resolution services to display

value-adds for the destination (golf packages, tours)

Orchestration

ƒ

Standards have jelled recently

ƒ

BPEL4WS is a joint effort of the following

companies

¾

IBM

¾

Microsoft

¾

HP

Orchestration

(Continued)

ƒ

BPEL4WS (the language) focuses on building

services that are composed of other services

ƒ

The language defines a process

in terms of a

number of activities

involving interacting

partnerlinks

When Should We Use SOA?

ƒ

Use SOA principles everywhere that flexibility

is desired

ƒ

ESB on the other hand is NOT a must have

in all projects

¾

Typically an architecture that is geographically

distributed can benefit from this

¾

As also – process flows that are very

What Next?

ƒ

Grids and autonomic computing

ƒ

Service network aggregation

ƒ

Dynamic discovery and request satisfaction

ƒ

…

ƒ

…

Related Presentations

ƒ

Two other sets of presentations, by

¾

Paul Giangarra

¾

Paul Freemantle

ƒ

If this presentation was interesting please

References

ƒ

http://www.serviceoriented.org

ƒ

http://www.ibm.com/developerworks

ƒ

http://builder.com.com/5100-6386-5064520.html

ƒ

http://www-136.ibm.com/developerworks/webservices

My Contact Info

ƒ

[email protected]