Software Architecture taxonomies - Integration patterns

Software ArchitectureS

ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Parte II. Architecture taxonomiesLesson 9: Integration patterns

Jose Emilio Labra Gayo

2014

Software Architecture

ENEnglish

University of Oviedo


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Integration

Application Integration = Biggest challenge in Computer

Science


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Integration

Integration stylesFile transferShared databaseRemote procedure callMessaging

TopologiesHub & Spoke, Bus

Service Oriented ArchitecturesWS-*, REST


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Integration stylesFile transferShared databaseRemote procedure callMessaging


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

File transfer

An application generates a data file that is consumed by anotherOne of the most common solutions

AdvantagesIndependence between A and BLow couplingEasier debugging

By checking intermediate files

ApplicationA

exports

File

ApplicationB

imports


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

File transfer

ChallengesBoth applications must agree a

common file formatIt can increase coupling

CoordinationOnce the file has been sent, the

receiver could modify it 2 files!It may require manual

adjustments

ApplicationA

exports

File

ApplicationB

imports


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Shared database

Applications store their data in a shared database

AdvantageData are always availableEveryone has access to the same informationConsistencyFamiliar format

SQL for everything

ApplicationC

DataBase

ApplicationA

ApplicationB


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Shared database

ChallengesDatabase schema can evolve

It requires an common schema for all applicationsThat can cause problems/conflicts

External packages are needed (common database)

Performance and scalabilityDatabase as a bottleneck

SynchronizationDistributed databases can be problematicScalabilityNoSQL ?


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Shared database

VariantsData warehousing: Database used for data

analysis and reportsETL: process based on 3 stages

Extraction: Get data from heterogeneous sources

Transform: Process dataLoad: Store data in a shared database


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Remote procedure call

An application calls a function from another application that could be in another machineInvocation can pass parametersObtains an answer

Lots of applicationsRPC, RMI, CORBA, .Net Remoting, ...Web services, ...

ApplicationA

Stu

b

callprocedure

Skele

ton Applicatio

nBanswer


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo


AdvantagesEncapsulation of implementationMultiple interfaces for the same information

Different representations can be offeredModel familiar for developers

It is similar to invoke a method

ApplicationA

Stu

b

callprocedure

Skele

ton Applicatio

nBanswer


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo


ChallengesFalse sense of simplicity

Remote procedure procedure8 fallacies of distributed computing

Synchronous procedure callsIncrease application coupling

The network is reliableLatency is zeroBandwidth is infiniteThe network is secureTopology doesn't changeThere is one administratorTransport cost is zeroThe network is homogeneous

8 fallacies of distributed computing

ApplicationA

Stu

b

callprocedure

Skele

ton Applicatio

nBanswer

http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Messaging

Multiple independent applications communicate sending messages through a channel

Asynchronous communicationApplications send messages a continue their

execution

ApplicationC

ApplicationA

ApplicationB

Message channel


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Messaging

AdvantagesLow coupling

Applications are independent between each other

Asynchronous communicationApplications continue their execution

Implementation encapsulationThe only thing exposed is the type of messagesApplicatio

nC

ApplicationA

ApplicationB

Message channel


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Messaging

ChallengesImplementation complexity

Asynchronous communicationData transfer

Adapt message formatsDifferent topologies

ApplicationC

ApplicationA

ApplicationB

Message channel


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Integration topologiesHub & SpokeBus


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Hub & Spoke

Related with Broker patternHub = Centralized message Broker

It is in charge of integration

Hub or BrokerCentral integration

engine

Application 4

Application 3

Application 2

Application 1

adapteradapter

adapter adapter


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Bus

Each application contains its own integration machine

Publish/Subscribe style

Message Bus

Application 1

Application 3 Application 4

Application 2

Adapter and Integration engine





ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Bus

ESB - Enterprise Service BusDefines the messaging backbone

Some tasksProtocol conversionData transformationRouting

Offers an API to develop servicesMOM (Message Oriented Middleware)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Service Oriented Architectures

SOAWS-*REST


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

SOA

SOA = Service Oriented ArchitectureServices are defined by an interface

Internet

Service 2

Interface

Service 3

Interface

Service 1

Interface


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

SOA

ElementsProvider: Provides serviceConsumer: Does requests to the serviceMessages: Exchanged informationContract: Description of the functionality

provided by the serviceEndpoint: Service locationPolicy: Service level agreements

Security, performance, etc.


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

SOA

Constraints

ServiceConsumer

Service

Policy

Endpoint

Contracts

Messages

Adheres to

Binds to

Understands

Sends/receives

Governed by

Exposes

Implements

Sends /receives

Fuente: SOA Patterns, A. Rottem Gal Oz

Serves

Describes


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

SOA

ChallengesIndependent of language and platformInteroperability

Use of standardsLow couplingDecentralizedReusabilityScalability

one-to-many vs one-to-onePartial solution for legacy systems

Adding a web services layer


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

SOA

ChallengesPerformance

E.g. real time systemsOverkill in very homogeneous environmentsSecurity

Risk of public exhibition of API to external parties

DoS attacksService composition and coordination


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

SOA

Variants:WS-*REST


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

WS-* model = Set of specificationsSOAP, WSDL, UDDI, etc....Proposed by W3c, OASIS, WS-I, etc.Goal: Reference SOA implementation


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

Web Services Architecture

ProcessesDiscovery, Aggregation, Choreography

DescriptionsWeb Services Description Language (WSDL

Messages

SOAP extensionsReliability, Correlation, Transactions

SOAP

Base

tech

nolo

gie

s: XM

L, D

TD

, Sch

em

a

Base

tech

nolo

gie

s: XM

L, D

TD

, Sch

em

aCommunications

HTTP, SMTP, FTP, JMS, IIOP, ...

SECURITY

MANAGEMENT


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

HTTP

UDDI

reco

rds

publish W

SDL

SOAP request (XML)

SOAP answer (XML)Web ServiceImplementation

search

obtains WSDL

Web ServiceConsumer

2001

Year


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

SOAP

SOAPSOAP

SOAP

Internet

Currencyconverter

Billing

UsersManagement

SOAPXML

UserApplication

2001

YearWeb Services ecosystems


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

SOAPDefines messages format and bindings with several

protocolsInitially Simple Object Access Protocol

EvolutionDeveloped from XML-RPCSOAP 1.0 (1999), 1.1 (2000), 1.2 (2007)Initial development by MicrosoftPosterior adoption by IBM, Sun, etc.Good Industrial adoption


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

Envelope

Body

Header

Header Key

Header Key

Message format in SOAP


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

Example of SOAP over HTTP

POST /Suma/Service1.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: longitod del mensaje SOAPAction: "http://tempuri.org/suma" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <sum xmlns="http://tempuri.org/"> <a>3</a> <b>2</b> </sum> </soap:Body> </soap:Envelope>

2001

Year

POST ?


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

AdvantagesSpecifications developed by community

W3c, OASIS, etc.Industrial adoption

ImplementationsIntegral view of web servicesNumerous extensions

Security, orchestration, choreography, etc.


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

ChallengesNot all specifications are mature

Over-specificationLack of implementations

RPC style abuseUniform interfaceSometimes, bad use of HTTP architecture

Overload of GET/POST methods


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

WS-*

ApplicationsLots of applications have been using SOAPExample: eBay (50mill. SOAP

transactions/day)Other examples: thetrainline.com, Hyatt,

Microsoft live, etc.Some popular web services ceased to offer

SOAP supportExamples: Amazon, Google, etc.


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST

REST = REpresentational State Transfer Architectural styleSource: Roy T Fielding PhD dissertation

(2000)Inspired by Web architecture (HTTP/1.1)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST

REST - Representational State TransferDiagram

InternetHTTP

Resource 1

GET, PUT, POST, DELETE

URI

Resource 2


URI

Application


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST

Set of constraintsResources with uniform interface

Identified by URIsFixed set of actions: GET, PUT, POST, DELETE

Resource representations are returnedStateless

REST = Architectural styleSome levels of adoption:

RESTfulREST-RPC hybrid


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST as a composed styleLayersClient-Server

StatelessCachedReplicated server

Uniform interfaceResource identifiers (URIs)Auto-descriptive messages (MIME types)Links to other resources (HATEOAS)

Code on demand (optional)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST uniform interfaceFixed set of operations


Method In databases Function Safe? Idempotent?

PUT Create/Update Create/update No Yes

POST Update Create/Update children

No No

GET Retrieve Query resource info Yes Yes

DELETE Delete Delete resource No Yes

Safe = Does not modify server dataIdempotent = The effect of executing N-times is the same as executing it once


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST

Stateless client/server protocolState handled by client

HATEOAS (Hypermedia As The Engine of Application State)

Representations return URIs to available options

Chaining of resource requestsExample: Student management1.- Get list of students

GET http://example.org/studentReturns list of students with each student URI

2.- Get information about an specific studentGET http://example.org/student/id2324

3.- Update information of an specific studentPUT http://example.org/student/id2324


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST

AdvantagesClient/Server

Separation of concernsLow coupling

Uniform interfaceFacilitates comprehensionIndependent development

ScalabilityImproves answer timesLess network load (cached)

Less bandwidth


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST

ChallengesREST partially adopted

Just using JSON or XMLWeb services without contract or description

RPC style RESTDifficult to incorporate other requirements

Security, transaction, composition, etc.


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

REST as a composed style

LayersClientServer

Stateless

REST

Replicated

UniformInterface

Cache Code on demand

(optional)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

End of presentation

Software Architecture taxonomies - Integration patterns

Engineering

Transcript of Software Architecture taxonomies - Integration patterns