Service Oriented Architecture

Service Oriented ArchitectureService Oriented Architecture

Overview of the syllabusOverview of the syllabus

SOA characteristicsPrinciples of service orientation Web service and its role in SOAService oriented analysisService oriented designSOA platforms SOA support in J2EE and .NETSOA standardsService composition (BPEL)Security in SOA

Prerequisite for understanding SOAPrerequisite for understanding SOA

Basic knowledge of object orientationUnderstanding of web technologiesBasics of java programmingBasics of internet programmingSoftware Paradigms

Overview of the contentOverview of the content

Current trends Software paradigmsApplication architectureWeb based systems2-tier and 3-tier architectureWeb based technologies component based systems

Current trends …Current trends …

Internet based solutionComplexity of the softwareGrowth in hardware mobile and other smart

devicesDemand for novel / customized services

Software paradigms…Software paradigms…

Procedure oriented Object-orientedComponent based Event-drivenLogic basedAspect-oriented Service oriented

The monolithic mainframe application architecture

Separate, single-function applications, such as order-entry or billing

Applications cannot share data or other resources

Developers must create multiple instances of the same functionality (service).

Proprietary (user) interfaces

The distributed application architecture

Integrated applicationsApplications can share resourcesA single instance of functionality (service) can

be reused.Common user interfacesBottom-up approachReal world scenario

Web based systems …

Client-server model Client side technologiesServer side technologiesWeb client, Web serversApplication servers

Basic idea of TiersBasic idea of Tiers

Thick client

Database server

Tier 1: GUI interactions with the user and basic validations

Request

Response

Tier 3: Database processing

Web server

Tier 2: Application logic, Transaction Management, Calls to the database server

Application server

2-tier architecture2-tier architecture

DatabaseDriver

DatabaseDriver

DatabaseDatabase

Tier Boundary

BusinessLogic

BusinessLogic

BusinessLogic

BusinessLogic

BusinessLogic

BusinessLogic

PresentationLogic

PresentationLogic

Data Layer

Presentation / Business Layer

Two tier architectureTwo tier architecture

• Deployment costs are high

• Database driver switching costs are high

• Business logic migration costs are high

• The client has to recompile if the BL is changed

• Network performance suffers

N-Tier architectureN-Tier architecture

DatabaseDatabase

BusinessLogic

BusinessLogic

DatabaseDriver

DatabaseDriver

BusinessLogic

BusinessLogic

BusinessLogic

BusinessLogic

PresentationLogic

PresentationLogic

Data Layer

Tier Boundary

Tier Boundary

N-Tier architectureN-Tier architecture

• Deployment costs are low• Database switching costs are low• Business migration costs are low• A firewall can secure parts of the

deployment• Each tier can vary independently• Communication performance suffers• Maintenance costs are high

Presentation tier technologiesPresentation tier technologies

At client or server? Property Microsoft Technology Sun Technology

Client HTTP (Web) based HTML browser (Internet Explorer)

HTML browser (Netscape Navigator)

ActiveX Controls Java Applets

Non-HTTP based COM clients CORBA clients

Communication Protocol between client and server

DCOM RMI, IIOP

Server For creating dynamic Web pages

ISAPI, ASP NSAPI, Servlets, JSP

Other pages HTML, XML HTML, XML

Business tier technologiesBusiness tier technologies

Purpose Microsoft Technology Sun Technology

Transaction handing, Business Objects

COM, MTS EJB (Session Beans)

Queuing and Messaging MSMQ IBM’s MQSeries, Java Messaging Service (JMS)

Database access ADO, OLE, ODBC JDBC, J/SQL (via Entity Beans)

Microsoft Web TechnologiesMicrosoft Web Technologies

HTML Browser

HTML Browser

ASP ISAPI

HTML/XML pages

Firewall

COM Client

ActiveX Control

DCOM DCOM

DCOM

MTS Transactional Components

MSMQ Queuing Services

ADO/OLE/ODBC Database Access

Database Database

Database Tier

Presentation Tier

Business Tier

Sun’s Web TechnologiesSun’s Web Technologies

HTML Browser

HTML Browser

Servlet JSP

HTML/XML pages

Firewall

CORBA Client

Java Applet

RMI/IIOP

RMI/IIOP

EJB Session Beans

MQSeries/Java Messaging Service (JMS)

JDBC / SQL/J

Database Database

Database Tier

Presentation Tier

Business Tier

RMI/IIOP

EJB Entity Beans

Component World …Component World …

Justification for component Interface ImplementationReusability standards

Eject

Skip

- Volume +

- Bass +

Actual implementation in terms of voltages, signals, currents etc.

External world (a user of the audio

system)

Interface Implementation

Interface and ImplementationInterface and Implementation

Technologies for implementing Technologies for implementing componentscomponents

RMI / EJB CORBA COM, DCOM, COM+LimitationsWeb services (XML based standards)

Basic model of distributed systemBasic model of distributed system

Service Registry

Service Requestor

Service provider

find

Bind

Publish

An Archetypal Distributed Objects System

o bje ct c lie n t o bje ct s e rv e r

clie n tpro x y

s e rv e rpro x y

ru n t im es u ppo rt

n e two rks u ppo rt

n e two rks u ppo rt

ph y s ica l da ta pa th

lo g ica l da ta pa th

o bje ctre g is t ry

ru n t im es u ppo rt

Distributed Object Systems / Protocols Distributed Object Systems / Protocols

• The distributed object paradigm has been widely adopted in distributed applications, for which a large number of mechanisms based on the paradigm are available. Among the most well known of such mechanisms are: ~ Java Remote Method Invocation (RMI),

~ the Common Object Request Broker Architecture (CORBA) systems,~ the Distributed Component Object Model (DCOM), ~ mechanisms that support the Simple Object Access Protocol (SOAP).

RMI architectureRMI architecture

Client Browse

r

Web server

HTML

Java applets

Stub

Application server

Skeleton

Object Implementatio

n

HTML pages

JRMP / IIOP

HTTP

Applets

CORBA architectureCORBA architecture

Client Brows

er

Web server

HTML

Java applets

Client ORB

Application server

Server ORB

Object Implementation

HTML pages

IIOP

HTTP

Applets

DCOM architectureDCOM architecture

Client Browse

r

Web server

HTML

ActiveX Controls

Proxy

Application server

Stub

Object Implementation

HTML pages

DCOM

HTTP

ActiveX

Limitations of ComponentsLimitations of Components

Tightly coupledCross language/ platform issuesInteroperability issuesMaintenance and managementSecurity issues

Application Centric

Application

ApplicationFinance

DistributionManufacturing

Supply

Narrow Consumers Limited Business Processes

Overlapped resourcesOverlapped providers

Business scope

Application

Integration

Architecture

Business functionality is duplicated in each application that requires it.

EAI ‘leverage’ application silos with the drawback of data and function redundancy.

bound to EAI vendor

Redundancy

Goal - Service Centric

What are services?What are services?

A service is Autonomous unit of automated business

logicAccessible to other systems

A service representsBusiness processSub processActivity (process step)

(or multiple)

What is Service Architecture?

• A collection of services

• classified into types

• arranged into layers

• Governed by architectural patterns and policies

services

identi

ficati

on

gran

ularit

y

depe

nden

cy

type typetype

source:TietoEnator AB, Kurts Bilder

SOA is a software architecture model in which business functionality are logically grouped and encapsulated into self contained,distinct and reusable units called services that represent a high level business concept can be distributed over a network can be reused to create new business applications contain contract with specification of the purpose, functionality, interfaces (coarse grained), constraints, usage

SOA Defined

SOA is a software architecture model in which business functionality are logically grouped and encapsulated into self contained,distinct and reusable units called services that represent a high level business concept can be distributed over a network can be reused to create new business applications contain contract with specification of the purpose, functionality, interfaces (coarse grained), constraints, usage

SOA Defined

Services are autonomous, discrete and reusable units of business functionality exposing its capabilities in a form of contracts. Services can be independently evolved, moved, scaled even in runtime.

Services are autonomous, discrete and reusable units of business functionality exposing its capabilities in a form of contracts. Services can be independently evolved, moved, scaled even in runtime.

Big (outer) vs. Little (inner) SOA

Service RelationshipsService Relationships

GUI Applications

Student

This is not a use case

Goals Business Processes

Serv ices

Business Applications

uses

hashelp usersachieve

participatesin

invokes

supportedby

are realized by (partially)

exposes

orchestrate / are composed of

Why SOA?Why SOA?

Heterogeneous cross-platformReusability at the macro (service) level rather

than micro(object) level Interconnection to - and usage of - existing IT

(legacy) assetsGranularity, modularity, composability,

componentizationCompliance with industry standards

SOA is an evolutionary step for architecture

SOA is an evolutionary step

in reusability and communication

SOA is an evolutionary step

Project-ware SOAEAI

in distributed communications

source:Sam Gentile

Features of SOAFeatures of SOA

Self- describing Interface (WSDL)Message communication via formally defined

XMLServices are maintained in a registryEach service has a Quality Of ServiceApplications adapt to changing technologiesEasy integration of applications with other

systemsLeverage existing investments in legacy

applications

Service Architecture CompositionService Architecture Composition

Service architectures are composed ofServices

• Units of processing logic• Example: Credit card Service

Messages • Units of communications between services• Needed for services to do their job

Operations • Units of Work• Example: Determine Cost of Attendance

Processes• Composed / orchestrated groups of services• Example: Financial Aid Disbursement

SOA principlesSOA principles

Service EncapsulationService Loose couplingService ContractService abstractionService DocumentationService reusabilityService composabilityService autonomyService optimization and DiscoveryService statelessness

Encapsulation

Loose Coupling

“Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment."

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

Source: Thomas Erl

Standardized Service Contracts

“Services within the same service inventory are in compliance with the same contract design standards."

Services use service contract to Express their purpose Express their capabilities

Use formal, standardized service contracts

Focus on the areas of Functional expression Data representation Policy

Source: Thomas Erl

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. Enables and preserves the loosely coupled

relationships Plays a significant role in the positioning and

design of service compositions Source: Thomas Erl

Documentation

Reusability

“Services contain and express agnostic logic and can be positioned as reusable enterprise resources."

Reusable services have the following characteristics: Defined by an agnostic functional context Logic is highly generic Has a generic and extensible contract Can be accessed concurrently

Source: Thomas Erl

Composability

"Services are effective composition participants, regardless of the size and complexity of the composition."

Ensures services are able to participate in multiple compositions to solve multiple larger problems

Source: Thomas Erl

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

To achieve this, services must be more isolated

Primary benefits Increased reliability Behavioral predictability

Source: Thomas Erl

Discoverability

"Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted."

Service contracts contain appropriate meta data for discovery which also communicates purpose and capabilities to humans

Store meta data in a service registry or profile documents

Source: Thomas Erl

Statelessness

"Services minimize resource consumption by deferring the management of state information when necessary."

Incorporate state management deferral extensions within a service design

Goals Increase service scalability Support design of agnostic

logic and improve service reuseSource: Thomas Erl

Applying SOA - Governance

Goal: Establish SOA organization governance (SOA Board) that governs SOA efforts and breaks down capabilities into non-overlapping services

Governance is a program that makes sure people do what is ‘right’

In conjunction with software, governance controls the development and operation of software


Policies Codification of laws, regulations, corporate

guidelines and best practices Must address all stages of the service lifecycle

(technology selection, design, development practices, configuration management, release management, runtime management, etc.)


Processes Enforce policies System-driven processes (code check-in, code

builds, unit tests) Human-driven process (requests, design

reviews, code reviews, threat assessment, test case review, release engineering, service registration, etc.)


Metrics Measurements of service reuse, compliancy

with policy, etc. Organization Governance program should be run by SOA

Board, which should have cross-functional representatives

Business service model

ServiceDesigners

Foundation Service Blocks

Core APIs

I/CA

D

InService

Service specificationmodel

EnterpriseArchitects

SOABoard P

atternsM

odelsStandardsPolicy

Service implementation and deployment

model

Software and IT Architects

BusinessCapabilities

Applying SOA – Governance

Business functionality has to be made available as services. Service contracts must be fixed

Implemented services must be designed with reuse in mind. This creates some overhead.

Potential service users must be involved in the design process and will have influence on the service design

Applying SOA - Challenges

Service Orientation

Reuse

Sharing of Responsibilities

Increased complexity!

(Source: Enterprise SOA: Service Oriented Architecture Best Practices by Dirk Krafzig, Karl Banke, and Dirk Slama, Prentice Hall 2004)

Applying SOA – Renovation Roadmap

Service Oriented Architecture modelService Oriented Architecture model

Before SOA – After SOA

source:IBM

Why SOA?To enable Flexible, Federated Business Processes

Enabling a virtual federation ofparticipants to collaborate in anend-to-end business process

Enabling alternativeimplementations

Enabling reuse ofServices

Enabling virtualization of business resources Enabling aggregation from multipleproviders

Identification

Ticket Sales

Ticket Collection

InventoryLogistics

ManufacturingAvailability

Service

Service

Service

Service Service

Service

ServiceService Service

Service

Ordering


Why SOA? To enable Business Process Optimization and the Real Time Enterprise (RTE)

Seamless End to End Process

Internal Systems

SOA Pattern: Standardized Service provided by multiple suppliers

Service from Multiple Suppliers

SOA Patterns: Single, Multi-ChannelService for consistency

BPM Expressed in terms of ServicesProvided/Consumed

Enterprise


Smart Clients

Stores POSMobile

3rd Party Agents

Portal

Service to Customers

Why SOA? Enable Structural Improvement

ERP X Process Z Partner A Process Y

Service

Standardizing capabilities Information Consistency

Policy Consistencye.g. Single Customer

Details Service

Consolidation/Selection process

Reducing impactof change

Encapsulatingimplementation

complexity

ERP ZCRM

System 2CRM

System 1Product System

Policy Rationalization and Evolution

Resource Virtualization

e.g. Multiple Sources of Customer Details

Service Architecture Organized by Layers

Reasons for Layering

1. Flexible composition.

2. Reuse.

3. Functional standardization in lower levels

4. Customization in higher layers

5. Separation of Concerns.

6. Policies may vary by Layer

Example Layers

Presentation& workflow

Composed Services

Basic Services

Underlying API

according to:TietoEnator AB, Kurts Bilder

Different layers of SOADifferent layers of SOA

Service Composition ExampleService Composition Example

Aid Disbursement Process

FAAwardService

RegistrationService

LoanService

BursarService

FA SystemMicrosoft .NET

Registrar SystemMainframe

Dept of Ed???

BursarJava on Linux

Aid DisburseService

Is Realized By

Are Executed In / Controlled By

Orchestratesaccount info

Debit Account

ServiceInterfaceLayer

AppLogic

NotPhysical

Applying services to the problemApplying services to the problem

MonolithicBefore

The System

After

S1 S2 S4S3

System replacement is a total processSystem modules are tightly interdependent making change difficult

System composed of many logical service units (decomposition)Underlying business logic decoupled as much as possible from other services (autonomy and loose coupling)

Goal of SOAGoal of SOA

Loosely coupledThe goal for a SOA is a world wide mesh of

collaborating services, which are published and available for invocation on the Service Bus.

SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.

Major service types

Basic Services: Data-centric and logic-centric services Encapsulate data behavior and data model and

ensures data consistency (only on one backend).

Basic services are stateless services with high degree of reusability.

Represent fundamental SOA maturity level and usually are build on top existing legacy API (underlying services.

Major service types

Composed Services :

expose harmonized access to inconsistent basic services technology (gateways, adapters, façades, and functionality-adding services).

Encapsulate business specific workflows or orchestrated services.

Service Types

Foundation Service Blocks

Core APIs

I/CA

D

InService

Servic

e

Infra

struc

ture

SOA Management & Security service mediation, routing, trust enablement. ESB, Service Registry

Multi channel applications: Mobile, Smart, Thin, Thick clients, Portals.

Business centric services, orchestrated workflows. Intermediate services (gateways, facades )

Data centric and logic centric consistent services. Highly reusable, stateless servers

BusinessCapabilities

SOA Benefits SummarySOA Benefits Summary

Allow us to execute complex business processes by composing systems from small, less complex building blocks

Fosters collaborative business and technical environment through sharing and coordination of services

Create outward facing self-service applications not constrained by organizational boundaries

Enables creating adaptive, agile systems that are resilient to changes in the business environment

Conclusions Conclusions

SOA represents a fundamental change to the way information systems will designed in the future

Long term impact on IT portfolio management is dramatic

Adds a significant dimension to system evaluation process

Undertaking SOA requires commitment from all levels of the organization and significant investments (people, process, and tools)