Service Oriented Architecture

S
ervice
O
riented
A
rchitecture
overview by Alar Krist, nov 2006


Main sources:


Gartner Symposion materials 2006 nov


Oracle SOA day materials 2006 nov


SOA classic approach in WWW


http://en.wikipedia.org/wiki/Service
-
oriented_architecture


http://www
-
128.ibm.com/developerworks/webservices/library/ws
-
soa
-
term1/index.html?ca=drs
-


http://www
-
128.ibm.com/developerworks/webservices/newto/


...





S
ervice
O
riented
A
rchitecture levels


SL

-

System / application level



TL

-

Technology / standards level



CL

-

Component level

SL
-

Main model of system level SOA

SL
-

Main principles of system level SOA


A system built with an SOA consists of
subsystems that interact in a loosely coupled

and with a well
-
defined contract



the subsystems are fully

autonomous
:

each can

freely participate in interactions with a number of
other autonomous systems.



In addition, all interactions

are governed by the
same contract or formal interface description

SL
-

The power of system level SOA


SOA
allows

autonomous subsystems to be
assembled into entities (SOA applications) that
can be as cohesive externally

as applications
built with older architectural approaches (that is,
classic structured programming

modularization,
or object
-
oriented paradigm).



The benefit of SOA

s over these older
approaches is increased

agility and greater
tolerance for change throughout the life cycle of
a system



SL
-

Description of SOA: metadata mgmnt

SL
-

Metedata management


Managing metadata and semantic reconciliation are
critical to an enterprise information management

(EIM)
program.



EIM brings an organized approach to metadata
management,

enabling optimization, abstraction and
semantic reconciliation of disparate metadata to support
reuse, consistency,

integrity and shareability of
enterprise information assets.



Metadata is typically managed through

metadata
repositories

(centralized catalogs of metadata) and
metadata registries

(federated metadata sources).




TL
-

Technology level of SOA

TL
-

Main technology aspects


WOA

(e.g., IFaP, REST, POX, WS*,
modular,
embeddable, distributable),


Data
-
Driven

(e.g., XML, BPEL)


Rich Semantics (
Metadata
,
eRDF, RDFa, microformats,

Semantic Web, Semantic Reconciliation)


Mashable Applications (Remix and scripting, PHP,
Javascript)


Build by example (show source, cloning),


Rich Client (just fast enough just in time, Ajax,
OfflineAjax, Flex, Microsoft, etc.)


Persistent Web (Caching, streaming, managed client)





TL
-

Stracegic view
-

Gartner 2006 nov


Strategic Imperative: Information and process
should be embedded in the Web, not just

communicated by the Web.



Strategic Planning Assumption: By 2010, WOA
will account for 60% of SOA development in

the
enterprise (0.7 probability).


TL
-

Main concepts of WOA

TL
-

"Representational State Transfer"


how a well
-
designed Web

application behaves: a
network of Web pages forms a virtual state machine,
allowing a user to progress

through the application by
selecting a link or submitting a short data
-
entry form,
with each action resulting in

a transition to the next state
of the application by transferring a representation of that
state to the user



REST describes the Web as a full

blown application
architecture, not just a GUI architecture or a transport
architecture.



TL
-

Strategic Imperative: Move business volatility
into data, and move technology stability into

c
ode.

TL
-

Principles of SOA data driven approach


New focus is on modularizing data, not just

modularizing
code.



Fold knowledge into data so program logic can be stupid
and

robust



P
rocedural logic is hard for humans to verify, but quite
complex data structures are fairly

easy to model and

anderstand



Data is more tractable than program logic



TL
–

Important standards of SOA

ERP/

Legacy Apps

Custom Apps

& Services

Web services

WSDL/WSIF

XML/XML Schema

SOAP

JCA

JMS

BUS

SERVICES

Process Flow

Logic

XSLT/XQuery

BPEL
, B Rules

ORCHESTRATE

PORTAL JSR
-
168

INTERACT/ACCESS

ADF
/
Struts/JSF

Portal

Web Application

API

WS

WS
-
Security

GATEWAY
,
ESB

Security

Reliability

Logging

Failover

Dynamic Routing

WS
-
Policy, SAML

Web Services Mgmt

Monitoring

Optimization

BAM

MONITOR & OPTIMIZE

JMX

TL
–

Key problem areas by SOA layers!


Business services


Data models
(decomposition, redesign, data access, ...)


Service models


Substance, essence, nature, definition of servise


How to describe


Decomposition, Granuality


Integration

(interface models,
ESB
, security, service mgmnt, ...)


Business processes execution


BP modelling, analysis, design, BP as a service


BPEL

–

code and data decomposition, workflow models, ...


Business rules

–

BR description models, decomposition, ...


Interacition, access, UI
(analysis, design,
ADF
, redesign)


Monitoring & optimizing
(BP, services, SLA
-
s, components)



TL
-

Enterprise Service Bus

Enterprise Service Bus

–

Integrate services

Routing

QOS

BPEL

Transform

Rules

WSIF

–

platform independent interface

In Memory

REST

JCA

COM+

SOAP

Core Features of an ESB

–

Virtualizes

services

Connects

adapters, web services

Transports

over JMS, HTTP

Routes

based on content/header

Translates

protocols & formats

TL
–

ESB Pattern Summary


Point To Point


Adapter
-
> Transformation
-
> Adapter


Quick and Easy Integration


File to DB, Topic to Queue


Canonical Model


Integrate n+ Enterprise Applications


Domain Value Mapping


Dynamically Add New Subscribers


Routing Service


Decoupled Flexible Routing


Configurable in Rich Client


Services Visible to BPEL, BAM, WSM



TL
–

Introduction to BPEL


Markup language for composing a set of discrete
services into an end
-
to
-
end process flow


10+ years of research and development from Microsoft
(XLANG) and IBM (WSFL, FDML)


The best integration solution for XML and Web services
but also Java, JCA and JMS.


Rich support for async interactions, parallel processing
and exception management.


Leverages XML Schema, XSLT, XML Query,

WS
-
Security, WS
-
Addressing and WSIF.


Composability: A process flow is automatically

a service.


?

BPEL

TL
-

BPEL, The Orchestrator

IU

PORTAL

J2EE

TOMCAT

Web Service

Java Service

ERP

SAP, Oracle, etc.

User Tasks

Database

Stored Procedures

TL
-


Business Rules


Rules specify conditional actions or policies

If salary is less than $10,000 then deny loan application

If miles flown is greater than 50,000 then grant gold
status


Rules

Can be represented as simple if
-
then statements

Are declarative, not procedural

Often generated by GUI programs


Rules executed on Rules Engines

Facts are input

Facts analyzed per Rules

Actions conditionally executed or results returned

results

facts

Rules


Engine

Application

TL
-

Rules Features
: d
ynamic Fact Generation


Rules are conceptually simple


Facts:

Data concerning the world


Rules:

if (<condition involving Facts>) then <Actions>


Actions:

Simple returns or direct action calls


Example:

If (quantity >= 12) then



give 20% discount


An action can be the generation of a new fact


This is called inferencing


Example:

If (GPA > 3.5 and SAT > 1400) then



create scholarship
-
eligible Fact

Rules

Engine

results

facts

facts

TL
-

Rules Features
: r
ules Programming Models


Rules "consulted" by applications


Procedural logic asserts facts to Rules engine


Results engine returns results


Procedural logic calls actions


Rules can call actions directly


Procedural logic asserts

facts to Rules engine


Rules engine calls

actions directly


Especially attractive for notifications


Can access database info, etc.


Application

Logic

results

facts

Rules


Engine

Claim

Don't

pay

fraud

alert

TL
–

A
ppl
D
ev
F
ramework model

TL
–

ADF model:


Unifies platform dependent BS



Enables you to work the

same way with any UI and

any
business service



Decouples UI

from back
-
end

business

services



Uses EL to bind a component

to a data control



Provides drag

and drop

data

binding


TL
–

Example: Oracle SAO suite

Application Server

J2EE, WS
-
*, Event Services

Enterprise Service Bus

Routing

Adapters

UDDI

Registry

BPEL Process Manager

Native

BPEL

Human

Workflow

Business

Rules

Web Services


Manager

Security

BAM

Monitoring

Events

Analytics

JDeveloper


Integrated

Services

Environment

App Dev

Framework

XSLT

Transform

B2B

CL
–

Component level SOA
-

Service


Services are obviously at the heart of Service
-
oriented architecture, and the term
service

is
widely used.



However, it means different things to different
people



“
A service is a discoverable resource that
executes a repeatable task, and is described by
an externalized service specification."


by IMB


CL
-

key concepts behind services



Business alignment
: Services are not based on IT capabilities, but
on what the business needs. Services business alignment is
supported by service analysis and design techniques.


Specifications
: Services are self
-
contained and described in terms
of interfaces, operations, semantics, dynamic behaviors, policies,
and qualities of service.


Reusability
: Services reusability is supported by services
granularity design decisions.


Agreements
: Services agreements are between entities, namely
services providers and consumers. These agreements are based on
services specification and not implementation.


Hosting and discoverability
: As they go through their lifecycle,
services are hosted and discoverable, as supported by services
metadata, registries and repositories.


Aggregation
: Loosely
-
coupled services are aggregated into intra
-

or
inter
-
enterprise business processes or composite applications.


Analysis techniques such as IBM's Service
-
Oriented Modeling and
Architecture (SOMA) exist to identify the list of appropriate services
based on the concepts listed above



CL
-

Architecture


The Open Group Architecture Forum (TOGAF) provides two
definitions for architecture, based on context:



"A formal description of a system, or a detailed plan of the
system at component level to guide its implementation.




The structure of components, their interrelationships, and the
principles and guidelines governing their design and evolution
over time."



Basic concepts of architecture:


Structure


Component


relationship


CL
-

architecture is necessary

to do


Design and model at different levels of
abstractions


Separate specification from implementation


Build flexible systems


Make sure business requirements are
addressed


Analyze the impact of a change in requirements


Ensure principles are followed

CL
–

SOA definition


"Service
-
Oriented Architecture (SOA) is an
architectural style for creating an
enterprise IT architecture that exploits the
principles of service
-
orientation to achieve
a tighter relationship between the business
and the information systems that support
the business."

CL
-

SOA characteristics



It enhances the relationship between
enterprise architecture and the business.




It allows the building of composite
applications as a set of integrated
services.



It provides flexible business processes.

CL
-

SOA layered architecture


CL
–

WEB services
(one implementation of services)


What the Web did for program
-
to
-
user interactions,

Web Services are poised to do for program

to

program
interactions.


common program
-
to
-
program communications model,
built on existing and

emerging standards
:


HTTP


XML


Simple Object Access

Protocol (SOAP)


Web Services Description Language (WSDL)


Universal Description,


Discovery and Integration (UDDI).



CL
-

Definition of Web Services


A Web service is an interface that describes a collection of
operations that are network

accessible

through standardized XML
messaging


A Web service is described using a standard, formal XML notion,
called its service description


It covers all the details necessary to interact with the service,
including message formats (that detail the operations), transport
protocols and location


The interface hides the implementation details of the service,
allowing it to be used independently of the hardware or software
platform


It allows
loosely coupled, component
-
oriented,

cross
-
technology
implementations


CL
-

The Web Services Model

CL
-

Roles in a Web Services Archit


Service provider
. From a business perspective, this is the owner of
the service. From an

architectural perspective, this is the platform
that hosts access to the service.


Service requestor
. From a business perspective, this is the
business that requires

certain functions to be satisfied. From an
architectural perspective, this is the application

that is looking for
and invoking or initiating an interaction with a service. The service

requestor role can be played by a browser driven by a person or a
program without a

user interface, for example another Web service.


Service registry.

This is a searchable registry of service
descriptions where service

providers publish their service
descriptions. Service requestors find services and obtain

binding
information (in the service descriptions) for services during
development for

static binding or during execution for dynamic
binding. For statically bound service

requestors, the service registry
is an optional role in the architecture, because a service

provider
can send the description directly to service requestors.




CL
-

Operations in a Web Service Archit


Publish
. To be accessible, a service description needs to be
published so that the

service requestor can find it. Where it is
published can vary depending upon the

requirements of the
application



Find
. In the find operation, the service requestor retrieves a service
description directly

or queries the service registry for the type of
service required.

The find operation can be involved in two different
lifecycle phases for

the service requestor: at design time to retrieve
the service’s interface description for

program development, and at
runtime to retrieve the service’s binding and location

description for
invocation.



Bind
. Eventually, a service needs to be invoked. In the bind
operation the service

requestor invokes or initiates an interaction
with the service at runtime using the binding

details in the service
description to locate, contact and invoke the service.


CL
-

Artifacts of a Web Service


Service
. Where a Web service is an interface described by a
service description, its

implementation is the service.
A service is a
software module

deployed on network

accessible

platforms provided
by the service provider. It exists to be invoked by or to

interact with a
service requestor. It can also function as a requestor, using other
Web

Services in its implementation.



Service Description
. This includes its data types, operations,
binding

information and network location. It could also include
categorization and other metadata

to facilitate discovery and
utilization by service requestors. The service description

might be
published to a service requestor or to a service registry.


CL
–

benefits of SOA


Greater alignment of business and IT


Component
-
based systems


Loosely coupled components and systems


A network
-
based infrastructure, enabling
geographically and technologically diverse
resources to work together


On
-
demand, built
-
on
-
the
-
fly
-
applications


Greater code reuse


Better process standardization throughout the
enterprise


Easier centralization of corporate control

Missing levels of SOA

(in this presentation)


BL
–

Business level



SL
-

System / application level


TL
-

Technology / standards level


CL
-

Component level



ML
–

Mathematical / theorethical level