Software Architecture University of Oviedo Integration School of Computer Science Jose E. Labra Gayo Course 2018/2019
Software Architecture Integration University of Oviedo Application Integration = Biggest challenge School of Computer Science
Software Architecture Integration University of Oviedo Integration styles File transfer Shared database Remote procedure call Messaging Event log Topologies Hub & Spoke, Bus Service Oriented Architectures School of Computer Science WS-*, REST Microservices Serverless
Software Architecture University of Oviedo File transfer Shared database Remote procedure call Messaging School of Computer Science
Software Architecture File transfer University of Oviedo An application generates a data file that is consumed by another One of the most common solutions Advantages Application A Independence between A and B exports Low coupling Easier debugging File School of Computer Science By checking intermediate files imports Application B
Software Architecture File transfer University of Oviedo Challenges Both applications must agree a common file format It can increase coupling Application A Coordination exports Once the file has been sent, the receiver could modify it 2 files! File It may require manual adjustments School of Computer Science imports Application B
Software Architecture Shared database University of Oviedo Applications store their data in a shared database Advantage Data are always available Everyone has access to the same information Consistency Application Application Application Familiar format A B C SQL for everything School of Computer Science Data Base
Software Architecture Shared database University of Oviedo Challenges Database schema can evolve It requires a common schema for all applications That can cause problems/conflicts External packages are needed (common database) Performance and scalability Database as a bottleneck Synchronization Distributed databases can be problematic School of Computer Science Scalability NoSQL ?
Software Architecture Shared database University of Oviedo Variants Data warehousing : Database used for data analysis and reports ETL: process based on 3 stages Extraction: Get data from heterogeneous sources Transform: Process data Load: Store data in a shared database School of Computer Science
Software Architecture Remote procedure call University of Oviedo An application calls a function from another application that could be in another machine Invocation can pass parameters Obtains an answer Lots of applications RPC, RMI, CORBA, .Net Remoting, ... Web services, ... School of Computer Science call procedure Skeleton Application Application Stub B A answer
Software Architecture Remote procedure call University of Oviedo Advantages Encapsulation of implementation Multiple interfaces for the same information Different representations can be offered Model familiar for developers It is similar to invoke a method School of Computer Science call procedure Skeleton Application Application Stub B A answer
Software Architecture Remote procedure call University of Oviedo Challenges False sense of simplicity Remote procedure procedure 8 fallacies of distributed computing Synchronous procedure calls Increase application coupling The network is reliable Latency is zero Bandwidth is infinite School of Computer Science The network is secure call Topology doesn't change procedure Skeleton There is one administrator Application Application Stub Transport cost is zero B A answer The network is homogeneous 8 fallacies of distributed computing http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Software Architecture Messaging University of Oviedo Multiple independent applications communicate sending messages through a channel Asynchronous communication Applications send messages a continue their execution Application Application Application School of Computer Science A B C Message channel
Software Architecture Messaging University of Oviedo Advantages Low coupling Applications are independent between each other Asynchronous communication Applications continue their execution Implementation encapsulation The only thing exposed is the type of messages School of Computer Science Application Application Application A B C Message channel
Software Architecture Messaging University of Oviedo Challenges Implementation complexity Asynchronous communication Data transfer Adapt message formats Different topologies Application Application Application School of Computer Science A B C Message channel
School of Computer Science University of Oviedo Software Architecture Bus Hub & Spoke
Software Architecture Hub & Spoke University of Oviedo Related with Broker pattern Hub = Centralized message Broker It is in charge of integration Application 2 Application 1 Hub or Broker Central integration School of Computer Science engine Application 3 Application 4
Software Architecture Bus University of Oviedo Each application contains its own integration machine Publish/Subscribe style Application 1 Application 2 Adapter and Adapter and Integration engine Integration engine School of Computer Science Message Bus Adapter and Adapter and Integration engine Integration engine Application 3 Application 4
Software Architecture Bus University of Oviedo ESB - Enterprise Service Bus Defines the messaging backbone Some tasks Protocol conversion Data transformation Routing Offers an API to develop services MOM (Message Oriented Middleware) School of Computer Science
School of Computer Science University of Oviedo Software Architecture REST WS-* SOA
Software Architecture SOA University of Oviedo SOA = Service Oriented Architecture Services are defined by an interface Service 2 Interface Service 1 Interface Internet School of Computer Science Interface Service 3
Software Architecture SOA University of Oviedo Elements Provider: Provides service Consumer: Does requests to the service Messages: Exchanged information Contract: Description of the functionality provided by the service Endpoint: Service location Policy: Service level agreements School of Computer Science Security, performance, etc.
Software Architecture SOA University of Oviedo Constraints Policy Adheres to Governed by Endpoint Exposes Binds to Service Service Serves Consumer Contracts Understands Implements School of Computer Science Describes Messages Sends/receives Sends /receives Fuente: SOA Patterns, A. Rottem Gal Oz
Software Architecture SOA University of Oviedo Challenges Advantages Independent of language Performance and platform E.g. real time systems Interoperability Overkill in very Use of standards homogeneous Low coupling environments Decentralized Security Reusability Risk of public exhibition of Scalability API to external parties one-to-many vs one-to-one DoS attacks School of Computer Science Partial solution for legacy Service composition and systems coordination Adding a web services layer
School of Computer Science University of Oviedo Software Architecture SOA Variants: REST WS-*
Software Architecture WS-* University of Oviedo WS-* model = Set of specifications SOAP, WSDL, UDDI, etc.... Proposed by W3c, OASIS, WS-I, etc. Goal: Reference SOA implementation School of Computer Science
Software Architecture WS-* University of Oviedo Web Services Architecture Base technologies: XML, DTD, Schema Base technologies: XML, DTD, Schema Processes Discovery, Aggregation, Choreography Descriptions M Web Services Description Language (WSDL S A E N Messages C A U G SOAP extensions R E Reliability, Correlation, Transactions I M T E School of Computer Science Y N SOAP T Communications HTTP, SMTP, FTP, JMS, IIOP, ...
School of Computer Science University of Oviedo Software Architecture
Software Architecture WS-* University of Oviedo UDDI HTTP SOAP request (XML) SOAP answer (XML) Web Service Web Service School of Computer Science Consumer Implementation
Software Architecture WS-* University of Oviedo Web Services ecosystems Billing SOAP SOAP XML Internet SOAP SOAP School of Computer Science User Users Application Management SOAP Currency converter
Software Architecture WS-* University of Oviedo SOAP Defines messages format and bindings with several protocols Initially Simple Object Access Protocol Evolution Developed from XML-RPC SOAP 1.0 (1999), 1.1 (2000), 1.2 (2007) Initial development by Microsoft Posterior adoption by IBM, Sun, etc. School of Computer Science Good Industrial adoption
Software Architecture WS-* University of Oviedo Message format in SOAP Envelope Header Header Key Header Key School of Computer Science Body
Recommend
More recommend
