Software Architecture taxonomies - Integration patterns

Software ArchitectureS

Parte II. Architecture taxonomiesLesson 9: Integration patterns

Jose Emilio Labra Gayo

Software Architecture

ENEnglish

University of Oviedo

Integration

Application Integration = Biggest challenge in Computer

Science

Integration

Integration stylesFile transferShared databaseRemote procedure callMessaging

TopologiesHub & Spoke, Bus

Service Oriented ArchitecturesWS-*, REST

Integration stylesFile transferShared databaseRemote procedure callMessaging

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

ApplicationB

imports

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

ApplicationB

imports

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

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 ?

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

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

callprocedure

ton Applicatio

nBanswer

AdvantagesEncapsulation of implementationMultiple interfaces for the same information

Different representations can be offeredModel familiar for developers

It is similar to invoke a method

ApplicationA

callprocedure

ton Applicatio

nBanswer

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

callprocedure

ton Applicatio

nBanswer

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

Messaging

Multiple independent applications communicate sending messages through a channel

Asynchronous communicationApplications send messages a continue their

execution

ApplicationC

ApplicationA

ApplicationB

Message channel

Messaging

AdvantagesLow coupling

Applications are independent between each other

Asynchronous communicationApplications continue their execution

Implementation encapsulationThe only thing exposed is the type of messagesApplicatio

ApplicationA

ApplicationB

Message channel

Messaging

ChallengesImplementation complexity

Asynchronous communicationData transfer

Adapt message formatsDifferent topologies

ApplicationC

ApplicationA

ApplicationB

Message channel

Integration topologiesHub & SpokeBus

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

Each application contains its own integration machine

Publish/Subscribe style

Message Bus

Application 1

Application 3 Application 4

Application 2

Adapter and Integration engine

ESB - Enterprise Service BusDefines the messaging backbone

Some tasksProtocol conversionData transformationRouting

Offers an API to develop servicesMOM (Message Oriented Middleware)

Service Oriented Architectures

SOAWS-*REST

SOA = Service Oriented ArchitectureServices are defined by an interface

Internet

Service 2

Interface

Service 3

Interface

Service 1

Interface

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.

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

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

ChallengesPerformance

E.g. real time systemsOverkill in very homogeneous environmentsSecurity

Risk of public exhibition of API to external parties

DoS attacksService composition and coordination

Variants:WS-*REST

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

Web Services Architecture

ProcessesDiscovery, Aggregation, Choreography

DescriptionsWeb Services Description Language (WSDL

Messages

SOAP extensionsReliability, Correlation, Transactions

aCommunications

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

SECURITY

MANAGEMENT

publish W

SOAP request (XML)

SOAP answer (XML)Web ServiceImplementation

search

obtains WSDL

Web ServiceConsumer

SOAPSOAP

Internet

Currencyconverter

Billing

UsersManagement

SOAPXML

UserApplication

YearWeb Services ecosystems

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

Envelope

Header

Header Key

Message format in SOAP

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>

POST ?

AdvantagesSpecifications developed by community

W3c, OASIS, etc.Industrial adoption

ImplementationsIntegral view of web servicesNumerous extensions

Security, orchestration, choreography, etc.

ChallengesNot all specifications are mature

Over-specificationLack of implementations

RPC style abuseUniform interfaceSometimes, bad use of HTTP architecture

Overload of GET/POST methods

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.

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

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

REST - Representational State TransferDiagram

InternetHTTP

Resource 1

GET, PUT, POST, DELETE

Resource 2

Application

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

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)

REST uniform interfaceFixed set of operations

Method In databases Function Safe? Idempotent?

PUT Create/Update Create/update No Yes

POST Update Create/Update children

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

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

AdvantagesClient/Server

Separation of concernsLow coupling

Uniform interfaceFacilitates comprehensionIndependent development

ScalabilityImproves answer timesLess network load (cached)

Less bandwidth

ChallengesREST partially adopted

Just using JSON or XMLWeb services without contract or description

RPC style RESTDifficult to incorporate other requirements

Security, transaction, composition, etc.

REST as a composed style

LayersClientServer

Stateless

Replicated

UniformInterface

Cache Code on demand

(optional)

End of presentation

Software Architecture taxonomies - Integration patterns

Engineering

Transcript of Software Architecture taxonomies - Integration patterns

Enterprise Integration Patterns:Enterprise Integration Patterns ......1. Transport messages Channel Patterns 3. Route the message to Routing Patterns 2. Design messages Message Patterns

Integration Patterns With Spring integration

Integration Patterns and Anti-Patterns for Microservices Architectures

Enterprise Integration Patterns na nuvem com Spring Integration

«Spring Integration as Integration Patterns Provider»

Enterprise Integration Patterns

Cloud Integration Patterns

Enterprise Integration Patterns with Spring integration!

Kafka & Couchbase Integration Patterns

Mule esb integration patterns

Integration Patterns for Microservices Architectures

SOA Client - Access Integration Patterns

Вячеслав Блинов: "Spring Integration as an Integration Patterns Provider"

Software taxonomies Patterns, styles, tactics,

Semantic Integration Patterns

Jason K. Sokoloff. Search Patterns Through a …medical taxonomies, and the query-expansion process — all of which seem to suggest that complex taxonomies dependent on rich thesauri,

Salesforce Integration Patterns

Business Integration Patterns - IBM · Emergence of Patterns in Business Integration ƒProcess Integration – Understanding the basic building blocks ... Business Integration Patterns

Enterprise Integration Patterns (OSGi Container)

Integration Patterns