Thammanoon Kawinfruangfukul CSSE MS, ID: Middleware

Agenda  What is middleware?  Middleware Vs. Frameworks  Middleware requirements  Middleware categories  Examples of middleware  From architecture to Implementation  Resolving mismatches  Summary 2

What is middleware? Infrastructure that supports (distributed) component-based application development  independent software system  mechanisms to enable component communication  mechanisms to hide distribution information Examples: CORBA, COM/DCOM/COM+, Java Message Service (JMS), etc. 3

What is middleware? (cont.) Standard for constructing and interconnecting components  interchange  upgrade  adaptation  aggregation 4

What is framework? software structure supporting various types of application domain  application-level  embodies architectural styles  incomplete software system; Fill in the blank Examples: Symfony, MFC, etc. 5

Middleware Vs. Frameworks Similarity: Both provide developers with services not available in the underlying OS/language Difference:  Frameworks provide a software structure which embodies a software architectural design.  Middleware provides infrastructure to support application. helps application with lower-level facilities implemented outside of application 6

Middleware requirements  Network communication Helps different components in different hosts communicate with each other Provides data transformation  Coordination Provides synchronization when components communicate with each other.  Synchronous, deferred synchronous, and asynchronous communication. Provides activation policies and manages persistent storage of components’ state. Provides threading policies to control concurrent requests 7

Middleware requirements (cont.)  Reliability Communication between two components  Best-effort, at-most-once, at-least-once, and exactly-once Communication among group requests  K-reliability, time-outs, and totally-ordered requests Replicating component  Scalability Ability to accommodate a growing future load.  Access, location, migration, and replication transparency  Heterogeneity Supports interoperate between different hardware and operating system platforms, programming languages, and middleware 8

9 Middleware categories  Transactional two-phase commit for distributed transactions e.g., IBM’s CICS, BEA’s Tuxedo  Message-oriented (MOM) communication via message exchange e.g., MQSeries and Sun’s Java message queue  Procedural remote procedure calls as the foundation e.g., Sun RPC, DCE RPC  Object-based communication among and via distributed objects e.g., CORBA, COM, RMI  Component-based support for distributed components e.g., EJB

Examples of middleware Sun RPC CORBA IBM’s CICS MQSeries Prism-MW 10

SUN RPC 11  The caller process sends a call message and waits for the reply.  On the server side a process is dormant awaiting the arrival of call messages. Difference between RPCs and local procedure calls Use of global variables as the server Performance may be affected by the transmission times. User authentication may be necessary. Location of server must be known.

Remote Procedure Call Model 12

Portmap 13

CORBA Common Object Request Broker Architecture 14 A middleware platform that supports a standardized OO architecture for software applications  CORBA supports distributed object computing  CORBA does not require an underlying OO implementation  It uses a broker an intermediary handling requests in a system facilitates communication between clients and server objects separates a component’s interface from its implementation Communication  Invoke methods via RPCs  Both synchronous and deferred synchronous communication

Main CORBA Features 15  Object request broker (ORB)  OMG interface definition language (IDL)  Language mappings  Stubs and skeletons  Interface repository  Dynamic invocation and dispatch dynamic invocation interface dynamic skeleton interface  Object adapters

CORBA Architecture 16

IBM’s CICS Customer Information Control System 17

MQSeries (IBM WebSphere MQ) MQSeries at Run Time 18

MQSeries: Message Queues Message queues support both synchronous and asynchronous communication Header (ID and Control) + Data 19

MQSeries: Message Queue Manager Message queue manager provides the message queuing interface (MQI) for communication with applications 20

Prism-MW For programming-in-the-small-and-many setting 21  Architectural middleware for distributed, resource constrained, mobile, and embedded systems  Supports architecture-based software development Architecture-based software development is the implementation of a software system in terms of its architectural elements Enabling a direct mapping between an architecture and its implementation  Modular design

Prism-MW 22

23 Prism-MW’ Core

Prism-MW: Ports 24

Architecture - ARCH class Arch { static public void main(String argv[]) { Architecture arch = new Architecture (“ARCH"); // create components ComponentA a = new ComponentA ("A"); ComponentB b = new ComponentB ("B"); ComponentD d = new ComponentD ("D"); Component B Component A Component D // create connectors Connector conn = new Connector("C"); CConnector C // add components and connectors arch.addComponent(a); arch.addComponent(b); arch.addComponent(d); arch.addConnector(conn); Component BComponent A Component D CConnector C // establish the interconnections arch.weld(a, conn); arch.weld(b, conn); arch.weld(conn, d) } 25 Using Prism-MW

Component B handles the event and sends a response public void handle(Event e) { if (e.equals("Event_D")) {... Event e1= new Event("Response_to_D"); e1.addParameter("response", resp); send(e1); }... } Send (e1) Architecture - ARCH Component BComponent A Component D CConnector C Component D sends an event Event e = new Event ("Event_D"); e.addParameter("param_1", p1); send (e); Send (e) 26 Using Prism-MW (2)

From architecture to Implementation 27

28 Mapping an Architecture to an Implementation  Code generation  Middleware technology

Mapping an Architecture to an Implementation(2) 29 Comp 1 Comp 2 Async Event Comp 1 Comp 2 RPC (thread) Architecture Implementation 29

Resolving mismatches  A style is chosen first, but the middleware selected for implementation does not support (or contradicts) that style  A middleware is chosen first (or independently) and has undue influence on the architectural style used  Strategies  Change or adapt the style  Change the middleware selected  Develop glue code  Leverage parts of the middleware and ignore others  Hide the middleware in components/connectors Use the middleware as the basis for a framework

Summary  Middleware  Middleware requirements  Network communication, Coordination, Reliability, Scalability, and Heterogeneity  Middleware categories  Transactional, Message-Oriented, Procedural, and Object and Component middleware  Examples of middleware  From architecture to Implementation  Hiding middleware in connector 31

References Taylor, R.N; Medvidovic, N.; Dashofy, E.M.;, “Software Architecture: Foundations, Theory, and Practice,” Wiley, Emmerich, W.: “Software engineering and middleware: a roadmap”. In: Proceedings of the conference on The future of Software engineering (ICSE 2000) - Future of SE Track, Limerick, Ireland, ACM Press (2000) 117–129 D. Wackerow, "MQSeries Primer," IBM Redpaper, REDP , IBM Corporation (1999), ibm.com/abstracts/redp0021.html?Open. M.B Juric, I Rozman, M Hericko, “Performance comparison of CORBA and RMI”, Information and Software Technology, Volume 42, Issue 13, 15 September 2000, Pages CICS TransactionServer fromStart to Finish accessed on March 30, 2012 Remote Procedure Call (RPC) accessed on March 30, 2012 Malek, S.; Mikic-Rakic, M.; Medvidovic, N.;, "A style-aware architectural middleware for resource- constrained, distributed systems," Software Engineering, IEEE Transactions on, vol.31, no.3, pp , March 2005 Medvidovic, N.;,“On the Role of Middleware in Architecture-Based Software Development”. In 14th International Conference on Software Engineering and Knowledge Engineering (SEKE), pages 299–306,

IBM’s CICS Backup Slides

The CICS transaction flow 34

The CICS transaction flow (2) 35

The CICS transaction flow (3) 36