Distributed Embedded Systems

Distributed Embedded Systems Computer Architecture and Operating Systems 2

Literature 1) George Coulouris, Jean Dollimore, Tim Kindberg: Distributed Systems: Concepts and Design. Addison-Wesley Longman, Amsterdam; Auflage: 4th rev. ed. (14. Juni 2005) 2) Andrew S. Tanenbaum, Maarten van Steen: Distributed Systems: Principles and Paradigms. Prentice Hall International; Auflage: 2nd rev. ed. (10. April 2008) 3) Tammy Noergaard: Embedded Systems Middleware: Understanding File Systems, Databases, Virtual Machines, Networking and More!. Butterworth Heinemann (12. September 2008) 4) http://www.autosar.org/ 5) http://www.omg.org/

Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages

Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages

Introduction Definitions Definition Distributed System: A distributed system is an set of communicating execution platforms which work together to solve a problem. Definition Embedded System: An embedded system is a computer system which is not used as a generic computation platform but which is used for a specific set of applications. Embedded systems often have limited resources (memory, processing power,...).

Embedded Systems Software Development for Embedded Systems: 290.000 employees in Germany 18,7 Mrd. Euro turn-around in Germany alone 60 Mrd. Euro world-wide turn-around in 2008 Telecommunication Industrial IT

Embedded Systems Examples Application domains: vehicles, factory automation, robotic, avionic, mobil phones,.. 2005: ca. 50% of computer business in Germany was in embedded systems

Embedded Systems Examples Application domains: vehicles, factory automation, robotic, avionic, mobil phones,.. 2005: ca. 50% of computer business in Germany was in embedded systems

Embedded System Example Automotive Systems Modern vehicles up to 80-90 electronic control units (ECUs) 3-5 communication buses > 1GB Software

Embedded System Example Automotive Systems ECUs are typical embedded systems

Embedded System Example Automotive Systems

Embedded System Example Automotive Systems

Embedded System Example Automotive Systems ACC ECU ESP ECU CAN Gateway CAN Engine ECU Central ECU

Embedded System Example Automotive Systems Sensors Objects Objects Objects Objects Objects <<Block>> SensorObjectProcessing VehicleState <<Block>> SensorFusion VehicleState <<Block>> FollowControl VehicleState Objects Objects Objects Objects <<Block>> VehicleStateObserver VehicleState <<Block>> TargetSelection VehicleState <<Block>> CruiseCtrl BrakeCtrl Acceleration Acceleration Acceleration ACC Functional Network (SysML Notation) <<Block>> LongitudinalCtrl <<Block>> ACCArbitration Acceleration

Embedded System Example Automotive Systems CAN-Bus

Embedded System Example Automotive Systems Software is distributed over several ECUs TCM SRM PDM ECM CIM DDM UEC REC DIS

Embedded System Example Automation Systems Factories, buildings, plants are today controlled by programmable logical controllers (PLCs) or by other embedded platforms. The PLCs are connected by networks. Source of Pictures: Wiki

Embedded System Example Automation Systems Factories, buildings, plants are today controlled by programmable logical controllers (PLCs) or by other embedded platforms. The PLCs are connected by networks. Source of Pictures: Wiki Commons

Mechanical Engineering and Plant Construction 230 000 European manufacturing enterprises with 34 million jobs. 2004: value added by manufacturing 1500 billion. Largest german industry sector (873.000 employees, 6000 companies) Europe is the leading region in this field Quelle: Maschinenbau in Zahl und Bild, VDMA, 2007

Mechanical Engineering and Plant Construction The development of automation systems and the respective software is a key challenge in this field. Quelle: Maschinenbau in Zahl und Bild, VDMA, 2007

Mechanical Engineering and Plant Construction Titel The development of automation systems and the respective software is a key challenge in this field: World-wide market for automation systems: 228 Mrd. EUR (Stand 2006). In Germany: 32 Mrd. EUR (2006, invest) Annual growth rate in Germany: 6 und 15 % (2003 2008) 234.000 employees in Germany

Embedded System Example Avionics Systems

Embedded Distributed Systems Main Topics Process IPC Process IPC Process IPC Process } Topic 3: Applications Middleware Middleware } Topic 2: Middleware Communication Driver Processor Communication Driver Processor Communication System Topic 1: Communication Systems The development of embedded distributed systems comprises different topics: How can communication systems (i.e. networks) be build (topic 1)? How can parallel processes communicate with each other independent of their location in the network (topic 2)? How can applications be developed that exploit the power of parallelism (topic 3)?

Embedded Distributed Systems Communication Systems Process IPC Process IPC Process IPC Process Middleware Middleware Topic 1: Com.- Systems } Communication Driver Processor Communication Driver Processor Communication System Distributed system can use different types of execution platforms: computers in a LAN computers connected by the Internet multi core processors parallel computers

Embedded Distributed Systems Execution Platforms source: wiki commons Computers in a LAN: medium-high latencies cheap solution very scalable solution

Embedded Distributed Systems Execution Platforms Computers connected by the Internet: very high latencies cheap solution very scalable solution Example seti@home: http://setiathome.berkeley.edu/ 3.9.09: 2,660,803 results in the field

Embedded Distributed Systems Boinc project: http://boinc.berkeley.edu/ Open source platform for distributed computing in the Internet Execution Platforms

Embedded Distributed Systems Execution Platforms Grid computing: computation centers offer computation capabilities to users the computation is done in the internet often highly optimized computers are used in dedicated computation centers (e.g. massive parallel computers) applications have to use a special API/middleware typical applications are scientific and mathematical problems such as simulation (e.g. climate), number theory (e.g. prime number identification) or biology (e.h. protein structures) resources are managed (and often have to be paid for!)

Embedded Distributed Systems Execution Platforms source: wiki commons Multi core processors: very low latencies cheap solution no scalable solution

Embedded Distributed Systems Execution Platforms source: wiki commons Parallel computers: very low latencies expansive solution scalable solution

Embedded Distributed Systems Execution Platforms Currently (2.9.2009) fastes computer (according to top500.org): Roadrunner at Los Alamos IBM Cluster with PowerXCell 8i 3200 Mhz (http://www-03.ibm.com/technology/resources/technology_cell_pdf_powerxcell_pb_7may2008_pub.pdf) Infiniband network Linux OS 129600 cores 1456704 GFlops http://www.lanl.gov/videos/roadrunner_supercomputer_video source: wiki commons

Embedded Distributed Systems Execution Platforms source: wiki commons Distributed hardware platforms are the subject of specialized lectures and are not a subject of this lecture.

Embedded Distributed Systems Communication Systems Process IPC Process IPC Process IPC Process 7. Application Layer Middleware Middleware 6. Presentation Layer Topic 1: Com.- Systems } Communication Driver Processor Communication Driver Processor Communication System 5. Session Layer 4. Transport Layer 3. Network Layer 2. Data Link Layer 1. Physical Layer Communication hardware, drivers and the ISO/OSI standard are the subject of specialized network lectures and are not a subject of this lecture.

Embedded Distributed Systems Middleware Topic 2: Middleware } Process IPC Process Middleware Communication Driver IPC Process IPC Process Middleware Communication Driver Processor Processor Communication System Applications (i.e. processes) can be distributed over cores and computers. The source code of the applications should be independent of the execution platform in order 1. to enable the transfer of processes between execution platforms and 2. to enable the dynamic addition/removal of processes. This would support software reuse and would make hardware upgrades easier. Middleware layers abstract therefore execution platforms, hardware, drivers, and specific communication means.

Embedded Distributed Systems Middleware Topic 2: Middleware } Process IPC Process Middleware Communication Driver IPC Process IPC Process Middleware Communication Driver Processor Processor Communication System Middleware layers should support: abstraction of execution platforms, basic software, and communication means transparant communication between processes guarantee of Quality of Services (QoS) such as communication latencies/bandwidth, reliability and processor performance management services such as starting/stopping of processes or monitoring

Embedded Distributed Systems Applications Topic 3: Applications } Process IPC Process IPC Process IPC Process Middleware Middleware Communication Driver Communication Driver Processor Processor Communication System Application/Software development for distributed system is different from standard software development. Applications must be split into parallel processes. Communication latencies and distributed data management must also be taken into consideration.

Embedded Distributed Systems Flynn s taxonomy: Applications Single Data Multiple Data Single Instruction SISD SIMD Multiple Instruction MISD MIMD SISD: One instruction set working on one data set. This is the classical sequential programming approach SIMD: One instruction is executed in parallel on several data. Also called vector computing. Example are graphic processors. MISD: Several programs work in parallel on one datum. Usually used for redundancy. MIMD: Several programs work on different data.

Embedded Distributed Systems Applications Today the Single Program Multiple Data (SPMD) strategy is often used in parallel computing: SPMD is a special type of MIMD: One set of instruction (i.e. program) is executed on several platforms (i.e. in form of several processes). Each process can be at a different point in the program.

Embedded Distributed Systems Applications How applications can be written as distributed programs and how parallel algorithm work is the subject of lectures about parallel algorithm or distributed programming. It is not the main subject of this lecture.

Embedded Distributed Systems Focus of lecture Topic 2: Middleware } Process IPC Process Middleware Communication Driver IPC Process IPC Process Middleware Communication Driver Processor Processor Communication System The focus of this lecture is on middleware issues.

Terminology System Architecture Platform 1 SW Module SW Module Network Platform 2 Platform 3 SW Module SW Module We call the model comprising software, hardware, execution platforms, networks, etc. and the dependencies between these element system architecture.

Terminology Hardware Topology Platform 1 Network Platform 2 Platform 3 We call the model comprising only hardware, execution platforms, networks, etc. hardware topology.

Terminology Software Architecture SW Module SW Module SW Module SW Module We call the model comprising only software and the communication relations between software modules software architecture.

Terminology System Architecture Platform 1 SW Module SW Module Network Platform 2 Platform 3 SW Module SW Module Mapping Platform 1 SW Module SW Module Network Platform 2 Platform 3 SW Module SW Module The system architecture is created by mapping the software architecture onto the hardware topology.

Terminology System Architecture Platform 1 SW Module SW Module Network Platform 2 Platform 3 SW Module SW Module Mapping Platform 1 SW Module SW Module Network Platform 2 Platform 3 SW Module SW Module Mapping means: Assigning software modules to execution platforms Assigning software modules/functions to tasks Mapping communication relations to inter-process communication means. Communication means are e.g. global variables (within on execution platform) or networks signals (if software modules habe been mapped onto different execution platforms). Connecting software modules to I/O drivers

Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages

Middleware Discussion Is a middleware really needed? Process IPC Process IPC Process IPC Process Middleware Middleware Communication Driver Processor Communication Driver Processor Communication System All architectures described here could be implemented directly by coding the communication into the application code. But this approaches has some drawbacks...

Middleware Idea A (software) component (SWC) is a reusable software module. A SWC is reusable if it neither directly calls or is called from basic software modules and other application software modules.

Middleware Reusability A software module is a not reusable if it directly communicates with another software module: Software Module 1 int g; void foo() {... g = 42;... } Software Module 2 extern int g; void moo() { int x;... x = g;... } Communication via global variables Software Module 1 void foo() {... moo();... } Software Module 2 void moo() {... } Communication via function calls But what happens if a software module must be used in a different context?

Middleware Reusability Software Module 1 int g; void foo() {... g = 42;... } Platform Software Module 2 extern int g; void moo() { int x;... x = g;... }? Platform 1 Platform 2 Software Module 1 int g; void foo() {... g = 42;... } Network Software Module 2 extern int g; void moo() { int x;... x = g;... } Now the application source code must be adapted. This also means that all tests must be repeated.

Middleware Reusability Software modules are also not reusable if their correct behavior depends heavily on the processor performance, other assumptions about the hardware are made in the application code (e.g. direct access to processor registers) or assumptions about compilers are mades (e.g. pragmas).

Middleware Reusable software modules are called software components. Software Components They achieve this: 1. by forbidding any hardware and compiler dependencies in the application code and 2. by allowing software components only to communicate with the outside via so-called ports. Ports are typed by offered and/or required interfaces. Offered Interface Required Interface Port1 Port2 Component

Middleware Two components are connected by connecting matching ports. Software Components Port A matches port B if each required interface from A finds a offered interface in B (and vice versa). Component 1 Component 2 PortA PortB Port3 I/F 1 I/F 2 I/F 1 I/F 2 I/F 3 I/F 4 Connection Port1 Port2 Component 3

Middleware Components and Ports A port is a proxy for that component that is later on connected to the port. E.g. below, PortA of Component1 is a proxy for Component3. So in the source code, other software components are only referred to via proxies. void foo() {... PortA_IF1_x = 2;... } Component 1 PortA PortB Exemplary Syntax! void g() {... } void moo() {... Port1_IF2_f();... x = Port1_IF1_x;... } I/F 1 I/F 2 I/F 1 I/F 2 Port1 Port2 Component 3 <<Interface>> I/F 1 int x; <<Interface>> I/F 2 void f();

Middleware Components and Ports The middleware now 1. implements the communication relations between SWCs (i.e. ports) 2. triggers the application code (i.e. connects the code to the scheduler of the operating system) A middleware can be generated for a specific system architecture. This is called a dynamic middleware. Exemplary Syntax! void foo() {... PortA_IF1_x = 2;... } void g() {... } int gx; void g(); #define PortA_IF1_x gx #define Port1_IF1_x gx #define Port1_IF2_f g void moo() {... Port1_IF2_f();... Or the middleware can be static. Port1 Static middleware provide static x = Port1_IF1_x; Component 3 communication APIs.... } I/F 1 Component 1 PortA I/F 2 I/F 1 I/F 2 PortB Port2 <<Interface>> I/F 1 int x; <<Interface>> I/F 2 void f(); Dynamic Middleware

Middleware Components and Ports Dynamic middlewares need less space and processing power. But the system architecture must be fixed as design time. Static middlewares are less optimized but components may be added, modified and removed at a system s runtime. Exemplary Syntax! void foo() {... Write(PortA_IF1_x, 2);... } void g() {... } bool Call(int funcid, params); int Read(ID); bool Write(ID, int value); I/F 1 Component 1 PortA I/F 2 PortB <<Interface>> I/F 1 int x; <<Interface>> I/F 2 void f(); Static Middleware void moo() {... Call(Port1_IF2_f);... x = Read(Port1_IF1_x);... } I/F 1 I/F 2 Port1 Component 3 Port2

Middleware Reusability So without middleware approaches, the architectures from above must be directly coded into the application code. This would prevent the migration to other execution platforms (e.g. more or faster processors), the increase/decrease of the number of processes (i.e. higher degree of parallelism, load balancing) or the usage of software modules within other applications. We will therefore assume that a middleware is used.

Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages

Message-Based Architectures Idea Message 1 (e.g. here "int x=42") Process 1 Process 2 Message 2 (e.g. here "int x=43") Processes communicate via messages. A message is defined by: sender/receiver data type value

Message-Based Architectures Synchronized Messages Synchronized messages: The sender waits until a message has been received, i.e. the program is blocked during the waiting. The receiver waits until a message has been sent, i.e. the program is blocked during the waiting. There is a potential danger here...

Message-Based Architectures Synchronized Messages sender sendmessage receiver Wait time receivemessage sender receiver receivemessage Wait time sendmessage

Message-Based Architectures Asynchronous Messages Asynchronous messages: The sender sends the messages und continuous with its program. The receiver checks for new messages. If a message has arrived it is returned, otherwise a no new message signal is returned. In both cases, the receiver continues immediately.

Message-Based Architectures Asynchronized Messages sender sendmessage receiver time Continues receivemessage sender receiver receivemessage time sendmessage Continues

Message-Based Architectures Buffered Architectures In buffered architectures, messages are stored on the sender and/or on the receiver side in buffers. For a bidirectional communication at least 4 buffers are used. Output Buffer Process 1 sendmessage Platform 1 Communication Platform 2 Input Buffer Process 2 receivemessage

Message-Based Architectures Buffered Architectures Buffered architectures allow for a temporal and architectural decoupling of the processes. The buffer size is an important parameter. BTW: A buffer size of 1 makes in some cases a lot of sense! Output Buffer Process 1 sendmessage Platform 1 Communication Platform 2 Input Buffer Process 2 receivemessage

Message-Based Architectures Pros and Cons Message-based architectures are easy to implement and well suited to reactive systems. Complex protocols (i.e. message sequences) are difficult to implement and to verify. If the overall system behavior depends on the correct order of a huge number of events between a large set of processes, one tends to loose the overview, i.e. errors and race conditions occur (event hell).

Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages

Service-Based Architectures Idea In service-based architectures, software modules use services offered by other software modules. A service is a collection of software interfaces (e.g. methods, data or events) and a protocol defining the usage of those service interfaces. Services can be used without knowing anything about a service s implementation and location. E.g. if a service is used twice, different implementations on different computers can be used.

Service-Based Architectures Typical Usage ➀ send service description SW Module Broker ➁ get service handle ➂ use service Interface To use a service, software module send a request for a service (comprising a service description) to a service broker which returns a suited service.

Service-Based Architectures Example <<Interface>> securityinterface key getkey(id) decrypt (key, message) Component ➀ k = getkey(4) ➁ t = decrypt(k, message) Service Interface Service Implementation A service offers one or several methods to the other software modules. One implementation may implement several services. Please note: Several components may be using a service in parallel.

Service-Based Architectures Synchronous Methods A interface may comprise event, data and methods. Events and methods might be asynchronous and synchronous. For events, the differences have already be outlined ( see Event-based Architectures ). Synchronous methods: The calling software module waits until the called method is finished and the results have been returned. Caller SWC Service SWC Service.foo() time Wait foo() Execution

Service-Based Architectures Asynchronous Methods Asynchronous methods: The calling software does not waits until the called method finishes. The result is returned by calling a callback-function. The callback-function is normally part of the caller software module. Caller SWC Service.foo() Service SWC foo() Continues callback_fct() Execution Execution time

Service-Based Architectures State Freeness <<Interface>> securityinterface key getkey(id) decrypt (key, message) Component ➀ k = getkey(4) ➁ t = decrypt(k, message) Service Interface Service Implementation Because services may be used be used by several software modules in parallel and because the implementation behind a service may change between different service usages, a service must always behave similarly. I.e. it must be state free (transient).

Service-Based Architectures State Freeness In such state-free systems, each service call may be answered by a new implementation of the service (or a new instance of a service method). Of course, this is only one possible implementation. In practice, often only one specific instance of the service is used. <<Interface>> securityinterface Component key getkey(id) decrypt (key, message) ➀ k = getkey(4) Service Interface Service Implementation ➁ t = decrypt (k, message) «instance» Service Instance for "getkey" «instance» Service Instance for "decrypt" Meta-Level Instance-Level A subset X of a model is called a meta-model of a subset Y iff for each element relation R(x, y), x X, y Y the relation R defines an instantiation ( y is a an instance of x ).

Service-Based Architectures Example: State Freeness <<Interface>> bankaccount accountid openaccount(name) addmoney (accountid, amount) closeaccount (accountid) ➀ id=openaccount("peter Müller") Component ➁ addmoney(id, 42) ➂ closeaccount(id) Service Interface Service Implementation ➀ pid = findperson ("Peter Müller") ➁ debts = checkdebts(pid) Service Interface Service Implementation <<Interface>> checkfinancestatus personid findperson(name) float checkdebts(personid) Please note: State freeness talks about the state of services, not about the state of further databases, devices, etc. And in practice, services often allow for the storing of additional information (which may destroy the advantage of the service-based architecture ).

Service-Based Architectures Pros and Cons The state freeness make the handling and understanding of complex systems easier (since other module s states need not be taken into consideration at development time). But this forces calling software modules to remember everybody s state, i.e. much information must be transfered to services.

Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages

Subscribe-Based Architectures Idea Data-centric approach, i.e. all communication is with data objects. Data objects have a type, a value and further describing attributes (update timing, redundancy, etc). No direct communication between software modules. Components can write and read data values. Furthermore, components may be notified about value changes, e.g. by calling a callback function in the component. Component Component Component read current value set new value notify about new value set new value Temperature1:Double updatetime = "100ms" velocity:double updatetime = "10ms"

Subscribe-Based Architectures Constraints Constraints may be modeled between data. Constraints verify the consistency of missing data or they allow for the computation of value ranges for missing data values. Umsatz:Euro Umsatz > Gewinn Gewinn:Euro Bonus = Gewinn* 0.1 Bonus:Euro

Subscribe-Based Architectures Pros and Cons In many domains data-centric approaches are rather natural. E.g. systems using bus communication networks (automotive, avionics). Contradicts to some extend the OO paradigm. Constraints may lead to time-consuming value updates. If application behavior depends on too many data values, the application becomes hard to test and to understand.

Content 1. Motivation 2. An Overview of Distributed Software Architecture Approaches 2.1 Pro & Contra Middleware 2.2 Message-Based Architectures 2.3 Service-Based Architectures 2.4 Subscribe-Based Architectures 2.5 Component-Based Architectures 3. Inter-Process-Communication (IPC) in Unix 4. Example: MPI 5. Example: Web Services 6. Example: OPC UA 7. Critical Sections and Deadlocks 8. Example: DDS 9. Example: OSGi 10. Redundancy and Consistency 11. MultiCore Programming and Synchronous Languages

Component-Based Architectures Idea In component-based architectures, the overall application consists of communicating software components. Unlike in service-oriented architecture, the SWCs have states. I.e. when developing such systems, one needs precise information about the side-effects of operations. Platform 1 Component 1 Component 2 PortA PortB Port3 Network Platform 2 Platform 3 Port1 Port2 PortA PortB Component 3 Component 4

Component-Based Architectures Idea Interfaces are similar to interfaces used for service-oriented architectures. Again, synchronous and asynchronous calls are possible. Platform 1 Component 1 Component 2 PortA PortB Port3 Network Platform 2 Platform 3 Port1 Port2 PortA PortB Component 3 Component 4

Component-Based Architectures SWCs and States So in such software architectures, all communication is defined between SWCs on the instance level. Please remember: In service-oriented architecture the communication was between SWCs on instance level and services on the meta-level. Of course, several SWCs can be instances of the same meta classes. «Meta-Class» Class A «instance» Component 1 PortA PortB «instance» «Meta-Class» Class B «instance» Component 2 Port3 «Meta-Class» Class C «instance» Meta-Level Instance-Level Port1 Port2 PortA PortB Component 3 Component 4

Component-Based Architectures Multiple-Instantiation & Roles In the software architecture below, the meta-class blinker is instantiated twice. These usages in one architecture are called roles. Role 1 is Blinker Left, the second one is Blinker Right. «instance» «Meta-Class» Class Blinker «instance» Blinker Left Blinker Right Input PortB PortB Input Light Port2 DiagPort Blinker Control Blinker Diagnosis

Component-Based Architectures Multiple-Instantiation & Roles Now 4 roles exists. A role is defined by its context of usage, i.e. its position in a specific software architecture. Components often can be hierarchical. Such components have delegate ports and delegate connections which relay ports within the software components to ports of the hierarchical component. «instance» «instance» «Meta-Class» Class Blinker «instance» «instance» Blinker Left Blinker Right Blinker Left Blinker Right Input PortB PortB Input Input PortB PortB Input Light Port2 DiagPort Light Port2 DiagPort Blinker Control Blinker Diagnosis Blinker Control Blinker Diagnosis <<delegate>> Hierarchical Component Blinker Front <<delegate>> Hierarchical Component Blinker Rear Light Control

Component-Based Architectures Client-Server & n-tier Arch. A client-server architecture is a special kind of component-based architecture: There is a set of SWCs on one or several execution platforms that does the majority of computations. These execution platforms are called servers, the SWCs are called server components. There is another set of SWCs on separat execution platforms which mainly uses server components to implement their application. This execution platform is called the client, the SWCs are called client components. Typical server applications are: databases booking and reservation systems web server application. Typical client applications are: GUI frontends web browsers.

Component-Based Architectures 2-Tier Architectures Client-server architectures can have a 2-tier structure: Client Platform Client Component PortA Frontend: GUI visualization... Network Server Platform Port1 Server Component Backend: majority of computations and processing databases

Component-Based Architectures 3-Tier Architectures Client-server architecture normally have a 3-tier structure: Presentation Tier Presentation Component PortA Presentation Tier: GUI visualization... Network Application Tier Port1 Application Component Port2 Application Tier: majority of computations and processing also called Business Logic Tier Network PortX Data Component Data Tier Data Tier: databases

Component-Based Architectures 2-Tier vs. 3-Tier 3-Tier approaches are preferred because separation between application logic and data (separation of concerns) tiers can be easily replaced no dependencies between presentation tier and data tier higher software reuse better load balancing between execution platforms Client Platform Server Platform Port1 Client Component PortA Server Component Network Presentation Tier Presentation Component PortA Application Tier Port1 Application Component Port2 Network Network Data Tier PortX Data Component