Software Architecture taxonomies - Integration patterns
-
Upload
jose-emilio-labra-gayo -
Category
Engineering
-
view
516 -
download
6
description
Transcript of 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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Integration
Application Integration = Biggest challenge in Computer
Science
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Integration stylesFile transferShared databaseRemote procedure callMessaging
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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 ?
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Remote procedure call
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Remote procedure call
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Integration topologiesHub & SpokeBus
Software ArchitectureS
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
Software ArchitectureS
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
Adapter and Integration engine
Adapter and Integration engine
Adapter and Integration engine
Software ArchitectureS
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)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Service Oriented Architectures
SOAWS-*REST
Software ArchitectureS
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
Software ArchitectureS
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.
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
SOA
Variants:WS-*REST
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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 ?
Software ArchitectureS
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.
Software ArchitectureS
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
Software ArchitectureS
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.
Software ArchitectureS
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)
Software ArchitectureS
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
GET, PUT, POST, DELETE
URI
Application
Software ArchitectureS
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
Software ArchitectureS
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)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
REST uniform interfaceFixed set of operations
GET, PUT, POST, DELETE
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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.
Software ArchitectureS
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)
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
End of presentation