soa_chapter 1 -uao

8/4/2019 Soa_chapter 1 -Uao

http://slidepdf.com/reader/full/soachapter-1-uao 1/72

Service Oriented Architecture

Juan Carlos Corrales, Ph.D.

Universidad del Cauca [email protected]

Sesión 01, 01/29/2011

Universidad Autónoma de Occidente

Introduction to Service Oriented Architecture



Agenda

• SOA evolution – SOA Story

– Service Oriented Architecture vs. Distributed Object Architecture

– XML - Extensible Markup Language

– Web Services

• What is SOA?

– A new Business Environment – A new Enterprise Environment

– Pressures on the business

– Web Services Vs. Business Processes

– SOA Definitions

– Legacy Business Process

– Architectural Choke Point

– SOA Business Process



Agenda

• SOA potential benefits – SOA shifts the way we think

– Why an Enterprise SOA Strategy is Important

– Improve quality of service Vs. Drive costs down

– Consequences of not having an Enterprise SOA Strategy

• Technology providers – Market Trends

– Technology Providers

– SOA Solution Types



SOA Story

• SOA is not a new concept. Software engineers

understand its principles mid 80's withdistributed computing and remote procedurecalls.

SOA Evolution What is SOA? Tec. ProvidersSOA Benefits

• Distributed Computing Architectures of the 90did not reach the expected acceptance:

– Open Software Foundation's (OSF's) DistributedComputing Environment (DCE)

– Object Management Group's (OMG's) Common ObjectRequest Broker Architecture (CORBA)

Source: http://www.gartner.com/resources/111900/111987/111987.pdf



In 2003, SOA finally goes fully into the enterprise IT

world, through web services

– Unlike CORBA and DCE, web services standards donot have detractors among manufacturers

SOA Story


Fuente: http://www.gartner.com/resources/111900/111987/111987.pdf

– e ex ty o e serv ces to support mu t c anneapplications

– The ability of SOAP to pass through firewalls,leveraging the ubiquity of HTTP

– Web services support application servers that hostbusiness logic

– The ESBs, which combine Web services withmessage-oriented middleware (MOM), plus someprocessing and routing capabilities



SOA Story


But why now?



Conceptual Relationship

• Several principles of service-orientation are related to and

derived from object-orientation principles.

– abstraction -- decomposition

– Encapsulation -- Reusability

Service Orientation Vs. Object Orientation


7

– --

– Composition -- Autonomy – Statelessness -- Discoverability

• Some object-orientation principles, such as inheritance, do

not fit into the service-orientation world.

• Some service-orientation principles, such as loose couplingand autonomy, are not directly promoted by object-

orientation.



Conceptual Differences

Loose coupling between

units of processing logic.

Based on predefined class dependencies,

resulting in more tightly bound objects.

Coarse-grained interfaces (service description)

-

Fine-grained interfaces (APIs), Communication

Service-Orientation Object-Orientation



.

Large unit of processing logic (service),

May vary significantly in scope.

Unit of logic (object) tend to be smaller and

More specific in scope.

Promotes the creation of activity-agnostic

units of processing logic (services) that are

driven into action by intelligent units of

communication (message).

Encourages the binding of processing logic

with data, resulting in highly intelligentunits (object).

Prefers that units of processing logic (services)

be designed to remain as stateless as possible.

Promotes binding of data and logic, resulting

In the creation of more stateful units (objects).



The Paradigm Shift

Simula

Smalltalk

Objective C

Programming

Language

UML

Modeling

OOAD

OO Framework

OODB

Technology &

Methodology

Object-Oriented

Concept &



Java

XMLUDDI

ebXML

WSDL

SOAP

OWL

Standard

Specification

BPEL

WSFL

XLANG

Modeling

OO Process model

MDA

SO Framework

Ontology / Service DB

SO lifecycle process

Technology &

Methodology

Architecture

Service-Oriented

Concept &

Architecture



• SOA is a radical departure from client-server architecture.Current SOAs still employ some of the technologies originallyused to build client-server applications. Though moresophisticated, SOAs introduce complexity that sharply

SOA Vs. DOA


Conceptual Relationship

contrasts the simplicity of a two-tier client-server architecture.

• Distributed Internet architecture has much in common withSOA, including a significant amount of its technology.

However, SOA has distinct characteristics relating to bothtechnology and its underlying design principles.



Distributed System Architecture

Client

Server

Data Management

Application Processing

PresentationTwo Tier withThin Client


Client

Server Data Management

Presentation

Application ProcessingTwo Tier with

Fat Client

Server

Application

Processing

Server

Data

ManagementClient

Presentation

Three Tier



Multi-Tier System Architecture

• RPC-based – Client and middleware server is tightly coupled

• Remote Object based


–

languages

– Object models: OMG CORBA, SUN Java RMI, MS DCOM

• Web based

– Browser + “Dynamic content generation” – Enabling techniques: CGI, Java Servlet/JSP, MS ASP



Distributed Object Computing

• Coupled with a powerful communications

infrastructure, distributed objects divide monolithicclient/server applications into self-managingcomponents, or objects, that can interoperate


. – SUN J2EE

• JavaTM 2 Platform, Enterprise Edition

– MS DCOM

• Distributed Component Object Model – OMG CORBA

• Common Object Request Broker Architecture



CORBA – A bit of history

• OMG Standard, “to allow applications to communicate withone another no matter where they are located or who has

designed them”


– , . , w t n an – 1994, CORBA interoperability & IIOP (Internet Inter-ORB

Protocol)

– 2002, CORBA Component Model



CORBA – Objectives

• Distributed object computing middleware that shieldsapplications from heterogeneous platform dependencies.

• To simplify development of distributed applications byautomating/encapsulating – Object location

–


.

– Parameter (de)marshaling – Event & request demultiplexing

– Error handling & fault tolerance

– Object/server activation

– Concurrency

– Security

• CORBA defines interfaces, not implementations



CORBA Application Structure

• Object Request Broker : enables objects to transparently make and

receive requests and responses in a distributed environment.

– The core of the reference model, “telephone exchange”

• Object Services: a collection of services (interfaces and objects) that


.

– e.g. Naming, Trading, and Life Cycle Service

• Common Facilities: a collection of services that many applications may

share, but which are not as fundamental as the Object Services

– e.g. e-mail facility

• Application Objects: products of a single vendor on in-house

development group that controls their interfaces.



ApplicationObjects DomainFacilities

Horizontal

CORBAFacilities

CORBA Application Structure


Object Request Broker

Domain Facilities



Interface

Repository

Implementation

Repository

IDL

Compiler

CORBA Middleware Architecture


en ec

Dynamic

Invocation

IDL

Stub

ORB

Interface

IDL

Skeleton

Dynamic

Skeleton Object

Adapter

ORB Core GIOP/IIOP/ESIOPS



Object Request Broker (ORB)

• A logical set of services

– Locates the remote object, communicates the request,waits for the results and when available communicates

the results back to the client


– Location transparency – Programming language independent: interface translation

and language binding

Client Object




Interface Definition Language (IDL)

• Language neutral, Language mapping

– Modularized object interface

– Operations and attributes that an object supports


–

– Data types of an operation return value, its parameters,

and an object’s attributes

Client


IDL

Stub

IDL

Skeleton

Object



Two-way Processing

In args

O eration

Implementation

Repository

1S

Activate server

3S


ORB CORE

. re .

Out args + return value

IDL

Stub

1C

Locate target object

3C 2CSend request to server Wait for

request to

complete

IDL

Skeleton

2S

Activate Object’s Servant

Process Request

4S

Return Request

4CReturn

Control to

Client



CORBA Services

Services Description

Object Life Cycle Define how CORBA objects are created, removed, moved and copied

Naming Define how CORBA objects can have friendly symbolic names

Events Decouple the communication between distributed objects

Relationships Provides arbitrary typed n-ray relationships between CORBA objects


Externalization Coordinates the transformation of CORBA objects to and from external

media

Transactions Coordinates atomic access to CORBA objects

Concurrency Control Provides a locking service for CORBA objects in order to ensure serialized

access

Property Supports the association of name-value pairs with CORBA objects

Trading Supports the finding of CORBA objects based on properties describing the

services offered by the object

Query Support queries on objects



J2EE

• A platform for developing applications

– Oct. 1994, Public introduction of Java

– Jan. 1996, JDK 1.0 released


– . ,

– Dec. 1998, Java 2, SDK 1.2 released

– Jun. 1999, J2EE announced

– Dec. 1999, J2EE platform released

– Sep. 2001, J2EE 1.3 released

– Nov. 2003, J2EE 1.4 released



PureHTML

Java

Browser

Client SidePresentation

Server SidePresentation

JSP

Web

Server

Server SideBusiness Logic

EJB

EJB

Container

EnterpriseInformation

System

n A r c h i

t e c t u r e


Java

Application

Desktop

J2EE

Client

Other Device

Java

Servlet

JSP

J2EE

platform

EJB

EJB

J2EE

platform J 2 E E A

p p l i c a t i o



J2EE Services

• HTTP/HTTPS

• JAAS – Java Authorization and Authentication Service• JTA – Java Transaction API

• JNDI – Java Naming and Directory Service


• -

• JDBC – Java DataBase Connectivity

• JMS – Java Message Service

• JavaMail

• JAXP – Java API for XML Parsing• Java IDL

•



Advantages of Distributed Object

Architecture

• It allows the system designer to delay decisions on

where and how services should be provided


• t s a very open system arc tecture t at a owsnew resources to be added to it as required

• The system is flexible and scalable

• It is possible to reconfigure the systemdynamically with objects migrating across the

network as required



Weakness of Distributed Object

Architecture

• Tightly coupled – Both ends of each distributed computing link had to agree

on the details of the API. A code change to a COM object,


for example, required corresponding changes to the codeaccessing that object.

• Proprietary – Microsoft controlled DCOM

– Implementing a CORBA architecture typicallynecessitated the decision to work with a single vendor'simplementation of the specification.



SOA -- Evolution vs. Revolution

• SOA is developed upon the weaknesses of distribute object computing technique.

– Standard-based


• Reliance upon universally accepted standards provides broadinteroperability among different vendors’ solutions

– loosely couples

• Separates the participants in distributed computing interactions so

that modifying the interface of one participant in the exchangedoes not break the other .




eXXtensibleMMarkupLLanguage (XML)

• Based on Standard Generalized Markup

Language (SGML)

• Version 1.0 introduced by World Wide Web

• Bridge for data exchange on

the Web



Authoring XML Elements

• An XML element is made up of a start tag, an end

tag, and data in between.• Example:

<director > Matthew Dunn </director >


<actor > Matthew Dunn </actor >

• XML tags are case-sensitive:

<CITY> <City> <city>

• XML can abbreviate empty elements, for example:<married> </married> can be abbreviated to

<married/>



XML Data Model: Example<BOOKS>

<book id=“123”

loc=“library”><author >Hull</author >

<title>California</title>

BOOKS

123 555

articlebook

ref

loc=“library”


<year > 1995 </year ></book>

<article id=“555”ref=“123”>

<author >Su</author ><title> Purdue</title>

</article>

</BOOKS>

Hull Purdue

California

Su

titleauthor

title

author year

1995



Document Type Definitions (DTD)

• An XML document may have an optionalDTD.

• DTD serves as grammar for the underlying


,

language.• DTDs are somewhat unsatisfactory, but no

consensus exists so far beyond the basic

DTDs.• DTD has the form:

<!DOCTYPE name [markupdeclaration]>



DTD (cont’d)

• Consider an XML document:<db><person><name>Alan</name>

<a e>42</a e>


<email>[email protected] </email></person>

<person></person>

.

</db>



• DTD for it might be:<!DOCTYPE db [

<!ELEMENT db erson* >


DTD (cont’d)

<!ELEMENT person (name, age, email)><!ELEMENT name (#PCDATA)>

<!ELEMENT age (#PCDATA)>

<!ELEMENT email (#PCDATA)>]>



Comparisons

• Extensible set of tags

• Fixed set of tags

XML HTML


• on en or en a e

• Standard Data

infrastructure

• Allows multipleoutput forms

• resen a on or en e

• No data validation

capabilities

• Single presentation



Web Services

“Web services” is an effort to build a


.

Yet another one!



Designing Web Services I

• Goals

– Enable universal interoperability.


,

• Compare with the good but still limited adoption of the OMG’sOMA.

– Enable (Internet scale) dynamic binding.

• Support a service oriented architecture (SOA).

– Efficiently support both open (Web) and more constrained

environments.



Designing Web Services II

• Requirements – Based on standards. Pervasive support is critical.

– Minimal amount of re uired infrastructure is assumed.


• Only a minimal set of standards must be implemented. – Very low level of application integration is expected.

• But may be increased in a flexible way.

– Focuses on messages and documents, not on APIs.



Web Services Model

Web service applications are


,

Web “components” that can bind

dynamically to each other

Video 1




Di s t r i b u t e d

C om

p u t i n g

VT3270

VT100

Client/Server

RPC

Stored Procedure

TCP/IP

CORBA

EAI

WWW

MQ

EJB

NFSWSDL

SOAP

S

P r o gr am

P ar a d i gm

1950 1960 1970 1980 1990 2000

Assembler

COBOL

SIMULA

Pascal

Modular2

Smalltalk

PROLOG

Ada

C++

Java

C#

A



Agenda



– XML - Extensible Markup Language – Web Services

• What is SOA? – A new Business Environment

– A new Enterprise Environment



– SOA Definitions

– Legacy Business Process

– Architectural Choke Point




A New Business Environment

Business outsource every non-essential function.

– Concentrate on core function and values.

Vertically integrated enterprises are being broken apart

–


.

– Applications that used to be internal are nowprovided by outside parties.

Corporate boundaries become fuzzier .

Does today’s IT models support the new businessenvironment? – Today it is vital to adapt the computing model to the

business interaction model.



Enterprises as IT Islands

Value added networksand proprietary protocolssupport most B2B

A New Enterprise Environment


Ad-hoc bridges supportinterorganizationalinteractions.

Most applicationinteractions take placeinside the enterprise.

Most applications belongto a single administrativedomain.

nteract ons



Fully Networked Enterprises

Web based interactions

become pervasive, basedon standard protocols



The frequency of externalinteractions and theirreach inside theenterprise increasesdramatically.

Internal applicationsseamlessly reach out of the enterprise.

Interacting applicationsnaturally belong tomultiple administrativedomains.



Fully Networked Business Interactions

The distinction between

internal and externalapplications and providerslooses importance



Many potential providerscan be found for eachrequired function.

SO SO SO f



IT for the New Enterprise: Business Components

Need to raise the level of IT abstractions.

– Concentrate on business function and requirements.

Need to encapsulate business function to make it available to partners:

service components.



– Different level granularity – coarse grained business services vs. fine

grained objects.

Services must be defined by explicit contracts to allow independent party

access.

– Consequence is automatic binding.

Core concern of business is to integrate business processes and functions.

– Business components are integrated creating service compositions.

– New value is created through integration/composition.

– New components are recursively created.

SOA E l ti Wh t i SOA? T P idSOA B fit



Pressures on the business

b j e c t i v e s

t s

New Demands

Growth, profit,

and value

Technology

Customer Supplier Partner


Continuous businesstransformation

E v o l v i n

g B u s i n e s s

C h a n g i n g M a

r k

Leadership

Customer

satisfaction

Innovation

Deregulation

Mergers &

acquisitions

Economy

CompetitionSatisfying Unpredictable

NeedsBusiness agility

SOA Evolution What is SOA? Tec ProvidersSOA Benefits



Web Services Vs. Web Processes Web Services

– Self-describing, modular software application

– Vehicle for cross-organizational integration of heterogeneous applications

– Network-connected application


OneOne of of thethe mostmost appealingappealing aspectsaspects of of WebWeb servicesservices isis

havinghaving thethe abilityability toto aggregateaggregate thethe functionalityfunctionality of of

individualindividual WebWeb servicesservices byby composingcomposing themthem toto createcreate

WebWeb processesprocesses

Aspects of Web processes – Standard descriptions

– Suitable WS discovery

– Dynamic binding WS




Web Process An Example

+Organization AOrganization B

Organization C


t 3

t 6 t 5

t 4

t 2

Prepare

Sample

Prepare Clones

and

Sequence

Get SequencesTest Quality

Assembly

t 7

Sequence

Processing

t 1

Setup

t 8

Process

Report

+




Web Process extended Definition

Web Processes are next generation workflowtechnology to facilitate the interaction of organizations

with markets, competitors, suppliers, customers etc.


-

– encompass the ideas of both intra and inter

organizational workflow.

– created from the composition of Web services – can use BPEL4WS to represent composition




Globalization of ProcessesB2B E-Services


Web ProcessesWorkflows Distributed

Workflows

GlobalEnterprise Inter-Enterprise

Processes driving the Networked Economy Video 2




What is Service-Oriented Architecture?

Service-Oriented Architecture (SOA) is an

architectural style. Applications built using an


52

s y e e ver unc ona y as serv ces a

can be used or reused when building

applications or integrating within the enterprise

or trading partners.




SOA

• Uses open standards to integrate software

assets as services

•

53

• Services become building blocks that formbusiness flows

• Services can be reused by other applications




Legacy Business Process

Business Process 1

Business Process 2

54

Business Process 3




Architectural Choke Point

• Monolithic

• Extremely complex

• Ver ti htl cou led

55

• Difficult to find clean integration points• Lack of standards makes it difficult to

integrate

• Rigid architecture makes even smallchanges complex and costly




SOA Business Process

Business Process

Shared Service

56

Information Framework

Supplier

Video 3

Agenda



Agenda





– A new Enterprise Environment



– SOA Definitions

– Legacy Business Process – Architectural Choke Point


Agenda



Agenda



– Improve quality of service Vs. Drive costs down – Consequences of not having an Enterprise SOA Strategy







SOA shifts the way we thinkTraditional Applications Service Oriented Architecture

Designed to last Designed to change

Tightly Coupled Loosely Coupled, Agile and Adaptive

Integrate Silos Compose Services

Detailed Abstracted

Long development cycle Interactive and iterative development

Cost, supply centered Business, demand centered

Middleware makes it work Architecture makes it work

Favors Homogeneous Technology Favors Heterogeneous Technology




Why an Enterprise SOA Strategy is Important• Create structure around federated SOA efforts – avoid IT mavericks

• Provide guidance and recommendations to Business and IT teams wanting

to implement SOA solutions

• Manage and govern the architectural landscape – planning, preparing, andapplying principles, techniques, and technologies to make the business

adapt to change.

• Manage semantic interoperability through Services

• Reduces integration expenses

– Web based SOA reduces integration expense through standardization• Increases Asset Reuse

– Helps eliminate duplicate functionality

– Reduces time to market

– Promotes consistency

• Reduces risk

– More control over business processes by business people

• Improves Business Agility

– Allows the business direct control of business processes to manage rapid

change

I lit f i V D iSOA Evolution What is SOA? Tec. ProvidersSOA Benefits



Improve quality of service Vs. Drive

costs down

Support rapid change Security Performance

Improve availabilityOutsourcing

Emerging

a lications

Drivecosts

down

Consumption-based costing Capacity

Deliver

servicesP&L contribution

Increase business relevanceMobility

Distributed

systems

Heterogeneity

Reduce complexity

Improve

qualityof

service




Before - After SOA




Consequences of not having an EnterpriseSOA Strategy

Within 2-3 years, we’ll have• Mishmashes implementations of non-cohesive SOAs

• Islands of architectures – fragmented business functionality &

Business Processes

Video 4

• Vendor-defined SOA landscapes (every vendor wants to be the

‘center of the universe’)

• IT will spend a lot of time in the future unwinding shortsighted

solutions

• Semantic mess – multiple applications exposing seemingly similar

functionality

• Lots of non-reusable, un-structured services that don’t enable

business processes

• Businesses struggle to react to change – reduced competitiveness

Agenda



g

• SOA evolution

• What is SOA?



– Improve quality of service Vs. Drive costs down

– Consequences of not having an Enterprise SOA Strategy







• Market development of software vendor integration / EAI

to SOA Suites• Market development of technology

providers MOM / JMS to ESB (Enterprise ServiceBus)

Market Trends

• Market development of applications softwarevendors Web / ApplicationServers / APS(Application Platform Suites) to SOA Suites

• Market convergence of technology provider Web Services

and SOA• Convergence / fusion providers EAI / MOM / BPM /

Integration / B2B / Application Servers / APS / Web




• Microsoft

• IBM

• BEA

• IONA

• Cape Clear

• Progress / SonicSoftware

Technology Providers

• Sun / SeeBeyond

• Oracle

• webMethods /Software AG

• SAP

• iWay• Fujitsu

• Fiorano• InterSystems

• PolarLake




Gartner Integration 2Q07

http://mediaproducts.gartner.com/reprints/microsoft/vol1/article1/article1.html




SOA Solution TypesEvolution of closed and monolithic applications to reusableservices architecture on layer distributed network

Access La er

Process Layer

Service Layer

Resource Layer




SOA Solution Types

Portal

BAMGovernance

ETL

BPM

ESB

B2B

Video 5

Agenda







– A new Enterprise Environment – Pressures on the business


– SOA Definitions

– Legacy Business Process – Architectural Choke Point


Agenda





– Improve quality of service Vs. Drive costs down – Consequences of not having an Enterprise SOA Strategy






Service Oriented ArchitectureJuan Carlos Corrales, Ph.D.

Universidad del Cauca

[email protected]

Sesión 01, 01/29/2011

Universidad Autónoma de Occidente

Introduction to Service Oriented Architecture

soa_chapter 1 -uao

Documents