Service Oriented Architecture

Dr.S.Swamynathan
Department of Information Science and Technology
College of Engineering Guindy Campus
Anna University
Chennai, INDIA
Email: [email protected]
 Overview of the syllabus

 SOA characteristics
 Principles of service orientation
 Web service and its role in SOA
 Service oriented analysis
 Service oriented design
 SOA platforms
 SOA support in J2EE and .NET
 SOA standards
 Service composition (BPEL)
 Security in SOA
 Prerequisite for understanding SOA

Basic knowledge of object orientation

Understanding of web technologies
Basics of java programming
Basics of internet programming
Software Paradigms
 Overview of the content

Current trends
Software paradigms
Application architecture
Web based systems
2-tier and 3-tier architecture
Web based technologies
 component based systems
 Current trends …

 Internet based solution

 Complexity of the software
 Growth in hardware mobile and other smart
devices
 Demand for novel / customized services
 Software paradigms…

 Procedure oriented
 Object-oriented
 Component based
 Event-driven
 Logic based
 Aspect-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 applications
 Applications can share resources
 A single instance of functionality (service) can
be reused.
 Common user interfaces
 Bottom-up approach
 Real world scenario
 Web based systems …

 Client-server model
 Client side technologies
 Server side technologies
 Web client, Web servers
 Application servers
 Basic idea of Tiers

Request Web
Thick
client server
Response

Tier 1: GUI
interactions with the
user and basic
validations

Applicati Databas
on server e server

Tier 2: Application Tier 3: Database

logic, Transaction processing
Management, Calls to
the database server
 2-tier architecture

Presentation
Logic

Business Business Business

Logic Logic Logic

Database
Driver
Presentation / Business Layer
Tier Boundary

Data Layer

Database
 Two tier architecture

• Deployment costs are high

• Database driver switching costs are high
• Business logic migration costs are high
• The client have to recompile if the BL is
changed
• Network performance suffers
 N-Tier architecture

Presentation
Logic

Tier Boundary
Business Business Business
Logic Logic Logic

Database
Driver

Tier Boundary
Data Layer

Database
 N-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 technologies
At client or server? Property Microsoft Technology Sun Technology

Client HTTP (Web) based HTML browser HTML browser

(Internet Explorer) (Netscape Navigator)

    ActiveX Controls Java Applets

       

  Non-HTTP based COM clients CORBA clients

       

  Communication DCOM RMI, IIOP

Protocol between
client and server
       

Server For creating dynamic ISAPI, ASP NSAPI, Servlets, JSP

Web pages

       

  Other pages HTML, XML HTML, XML

 Business tier technologies

Purpose Microsoft Technology Sun Technology

Transaction handing, COM, MTS EJB (Session Beans)

Business Objects

Queuing and Messaging MSMQ IBM’s MQSeries, Java

Messaging Service (JMS)

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

Beans)
 Microsoft Web Technologies
Presentation Tier

HTML HTML
Browser Browser
COM ActiveX
Client Control
Firewall

ASP ISAPI
DCOM DCOM

HTML/XML pages

DCOM

Business Tier

MTS Transactional MSMQ Queuing ADO/OLE/ODBC

Components Services Database Access

Database Tier

Database Database
 Sun’s Web Technologies
Presentation Tier

HTML HTML
Browser Browser
CORBA Java
Client Applet
Firewall

Servlet JSP
RMI/IIOP RMI/IIOP

HTML/XML pages

RMI/IIOP

Business Tier

EJB Session Beans EJB Entity Beans JDBC / SQL/J

MQSeries/Java Messaging
Service (JMS)

Database Tier

Database Database
 Component World – Definition

A component is a nontrivial, nearly independent, and

replaceable part of a system that fulfills a clear
function in the context of a well-defined architecture.
A component conforms to and provides the physical
realization of a set of interfaces.

A runtime software component is a dynamically

bindable package of one or more programs
managed as a unit and accessed through
documented interfaces that can be discovered at
runtime.
 Component World – Definition

A software component is a unit of composition with

contractually specified interfaces and explicit
context dependencies only. A software component
can be deployed independently and is subject to
third-party composition.
4.
A business component represents the software
implementation of an “autonomous” business
concept or business process. It consists of the
software artifacts necessary to express, implement,
and deploy the concept as a reusable element of a
larger business system.
 Component World …

 Justification for component

 Interface
 Implementation
 Reusability
 standards
 Component World …

 Justification for component

 Interface
 Implementation
 Reusability
 standards
 Component World – A Holistic view

Application Integration Environment

Composition/Integration Tools
Component Repository
Component Contract/Metadata
Component Runtime Environment
Language
Platform Interconnecting Technology
Interface Resource Management
Granularity
Domain Component
 Component Environment

A component is tightly coupled to its native

environment.

Component Environment
 Component World – Major steps

Aspect Phase Actor

Interface Definition Designer

Assembly Assembly Architect

Implementation Implementation Developer

Lifecycle Packaging, Administrator

Deployment

Framework, Execution End User

run-time support
 Component World …

Iteractions with
traditional software Traditional
entities software
entities
Interactions
Interactions with
with other Components
other components
components
Component
Infrastructure
Interactions with
component
infrastructure
 Interface and Implementation

Eject Actual
implementation
External Skip in terms of
world (a user voltages,
of the audio - Volume + signals, currents
system) etc.
- Bass +

Interface Implementation
 Technologies for implementing
components

 RMI / EJB
 CORBA
 COM, DCOM, COM+
 Limitations
 Web services (XML based standards)
Basic model of distributed system

Service
Registry

find Publish

Service Service
Requestor provider
Bind
An Archetypal Distributed Objects System

o bje ct
re g is try

o bje ct clie n t o bje ct s e rv e r

clie n t s e rv e r
pro x y pro x y
ru n tim e ru n t im e
s u ppo rt s u ppo rt

n e two rk n e two rk
s u ppo rt s u ppo rt

ph y s ica l da ta pa th

lo g ica l da t a pa th
 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 architecture

Web
server
Client
Browse HTTP
r

Applets HTML
HTML pages

Java applets
Applicatio
n server

Object
Implementatio
n

Stub Skeleton
JRMP / IIOP
 CORBA architecture

Web
server
Client
Brows HTTP
er

Applets HTML
HTML pages

Java applets
Application
server

Object
Implementation

Client Server
ORB IIOP ORB
 DCOM architecture

Web
server
Client
Browse HTTP
r

ActiveX HTML
HTML pages

ActiveX
Controls Applicatio
n server

Object
Implementation

Proxy Stub
DCOM
 Limitations of Components

Tightly coupled
Cross language/ platform issues
Interoperability issues
Maintenance and management
Security issues
 Application Centric
Business
Narrow Consumers
scope
Limited Business Processes
Finance
Application
Application

Integration bound to EAI

Supply Application vendor
Architecture

Manufacturing Distribution Redundancy

Overlapped resources
Overlapped providers

EAI ‘leverage’ application silos

with the drawback of data and
Business functionality is duplicated in function redundancy.
each application that requires it.
Goal - Service Centric
 What are services?
 A service is
Autonomous unit of automated business
logic
Accessible to other systems
 A service represents
Business process
Sub process
Activity (process step)
(or multiple)
What is Service Architecture?
• A collection of services

services

• classified into types type type type

• arranged into layers

• Governed by architectural ic ati

o n
lar
i ty
d enc
y
if u n
t pe
patterns and policies id
en gran
de

source:TietoEnator AB, Kurts

Bilder
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
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

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 Relationships

This is not a use case orchestrate / are composed of

invokes
GUI Applications Serv ices
uses
participates exposes
in
Student Business
Applications

help users are realized

has achieve by (partially)

Goals Business

supported Processes

by
 Why SOA?

 Heterogeneous cross-platform
 Reusability at the macro (service) level rather
than micro(object) level
 Interconnection to - and usage of - existing IT
(legacy) assets
 Granularity, modularity, composability,
componentization
 Compliance with industry standards
SOA is an evolutionary step
 for architecture
SOA is an evolutionary step

in reusability and communication

SOA is an evolutionary step

in distributed communications

EAI Project-ware SOA

source:Sam Gentile
 Features of SOA

 Self- describing Interface (WSDL)

 Message communication via formally defined
XML
 Services are maintained in a registry
 Each service has a Quality Of Service
 Applications adapt to changing technologies
 Easy integration of applications with other
systems
 Leverage existing investments in legacy
applications
 Service Architecture Composition

 Service architectures are composed of

 Services
• 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 principles

 Service Encapsulation
 Service Loose coupling
 Service Contract
 Service abstraction
 Service Documentation
 Service reusability
 Service composability
 Service autonomy
 Service optimization and Discovery
 Service 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 Source: Thomas Erl

 Policy
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 Source: Thomas Erl
 Can be accessed concurrently
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
Source: Thomas Erl
problems
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 reuse
Source: Thomas Erl
Applying SOA - Governance
 Governance is a program that makes sure people
do what is ‘right’
 In conjunction with software, governance controls
the development and operation of software

Goal: Establish SOA organization governance (SOA

Board) that governs SOA efforts and breaks down
capabilities into non-overlapping services
Applying SOA - Governance

 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.)
Applying SOA - Governance

 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.)
Applying SOA - Governance

 Metrics
 Measurements of service reuse, compliancy
with policy, etc.
 Organization
 Governance program should be run by SOA
Board, which should have cross-functional
representatives
 Foundation

Applying SOA – Service Blocks

Governance Core APIs

I/CAD
Business
Capabilities

In
Serv
i ce

Software and IT
Architects

Service implementation
SOA and deployment
model
Board

St del
Po ar
an
Mo rns
Pat

lic ds
d
y
te
Enterprise
Architects

s
Service specification
Service model
Designers
Business service
model
Applying SOA - Challenges
Business functionality has to be made available as services.
 Service Orientation Service contracts must be fixed

 Reuse Implemented services must be designed with reuse in mind.

This creates some overhead.

 Sharing of Responsibilities
Potential service users must be involved in the design
 Increased complexity! process and will have influence on the service design
Applying SOA – Renovation
Roadmap

(Source: Enterprise SOA: Service Oriented Architecture Best Practices

by Dirk Krafzig, Karl Banke, and Dirk Slama, Prentice Hall 2004)
Service Oriented Architecture model
Before SOA – After SOA

source:IBM
 Why SOA?
To enable Flexible, Federated Business Processes
Enabling a virtual federation of Enabling alternative Enabling reuse of
participants to collaborate in an implementations Services
end-to-end business process

Service

Service Identification Ticket Collection

Service
Ordering
Ticket Sales
Service

Service
Service

Inventory Service
Logistics Service Service

Service
Availability
Manufacturing

Enabling virtualization of business resources Enabling aggregation from multiple

providers

source:TietoEnator AB, Kurts

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

BPM Expressed in
terms of Services
Provided/Consumed

Seamless End to End Process

Service to Customers Enterprise Service from Multiple Suppliers

Smart Clients
Stores POS
Mobile
3rd Party Agents
Portal

Internal Systems

source:TietoEnator AB, Kurts

Bilder SOA Pattern: Standardized Service
SOA Patterns: Single, Multi-Channel provided by multiple suppliers
Service for consistency
 Why SOA?
Enable Structural Improvement

ERP X Process Z Partner A Process Y

Standardizing capabilities Information Consistency

Policy Consistency
e.g. Single Customer Service
Details Service

Reducing impact Consolidation/ Encapsulating

of change Selection implementation
process complexity

CRM CRM Product e.g. Multiple

ERP Z
System 2 System 1 System Sources of
Customer Details

Policy Rationalization and Evolution

Resource Virtualization
 Service Architecture Organized by Layers

Example Layers
Reasons for Layering
Presentation
1. Flexible composition. & workflow

2. Reuse.
Composed Services
3. Functional standardization in
lower levels
Basic Services
4. Customization in higher
layers
Underlying
5. Separation of Concerns. API

6. Policies may vary by Layer

according to:TietoEnator AB,

Kurts Bilder
Different layers of SOA
 Service Composition Example

Aid
Disbursement
Process
Is Realized By

Aid Disburse Orchestrates

Service account info
Service
Interface Debit Account
Layer
FA
Registration
Award Loan Bursar
Service
Not Service Service Service
Physical

Are Executed In / Controlled By

App
Logic
FA System Registrar System Dept of Ed Bursar
Microsoft .NET Mainframe ??? Java on Linux
 Applying services to the problem

Monolithic
Before After

The System S1 S2 S3 S4

System composed of many logical service

System replacement is a total process units (decomposition)
System modules are tightly interdependent Underlying business logic decoupled as
making change difficult much as possible from other services
(autonomy and loose coupling)
 Goal of SOA

 Loosely coupled
 The 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 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,
e
ru e
ur
st vic

facades )
ct
fra er
In S

Data centric and logic

centric consistent services.
Highly reusable, stateless
servers

Foundation
Service Blocks

Core APIs
I/CAD

Business
Capabilities

In
Serv
i
 SOA 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
 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)
Conclusion and Summary

 If done correct, SOA is “not just another

architectural fad”
 SOA seeks to bridge the gap between business
and technology promoting business agility (its all
about managing change)
 SOA
 Is complex
 Requires governance
 Requires executive management buy-in
 Requires commitment with resources
 References
 Coyle, “XML, Web Servcies and Data
Revolution”, Pearson Education, 2002.
 Chatterjee and Webber, “Developing
Enterprise Web Services – An Architect’s
Guide”, Pearson Education, 2004.
 Liu, “Distributed Computing – Principles and
Applications”, Pearson Education, 2004.
 http://www.microsoft.comarchitecture/soa
 http://www.ibm.com/soa
 http://www.sun.com/products/soa
Questions ?
Thank You.