Chapter 2:MiddlewareWeb services: Concepts, Architectures and Applications - Chapter 2 2Contents - Chapter 2  Understanding middlewareÄ Middleware as a programming abstractionÄ Middleware as infrastructure A quick overview of conventional middleware platformsÄ RPCÄ TP MonitorsÄ Object brokers Middleware convergenceWeb services: Concepts, Architectures and Applications - Chapter 2 3Programming abstractions Programming languages and almost any form of software system evolve always towards higher levels of abstractionÄ hiding hardware and platform detailsÄ more powerful primitives and interfacesÄ leaving difficult task to intermediaries (compilers, optimizers, automatic load balancing, automatic data partitioning and allocation, etc.)Ä reducing the number of programming errorsÄ reducing the development and maintenance cost of the applications developed by facilitating their portability Middleware is primarily a set of programming abstractions developed to facilitate the development of complex distributed systemsÄ to understand a middleware platform one needs to understand its programming modelÄ from the programming model the limitations, general performance, and applicability of a given type of middleware can be determined in a first approximationÄ the underlying programming model also determines how the platform will evolve and fare when new technologies evolveWeb services: Concepts, Architectures and Applications - Chapter 2 4The genealogy of middlewareRemote Procedure CallsocketsTCP, UDPInternet Protocol (IP)Remote Procedure Call: hides communication details behind a procedure call and helps bridge heterogeneous platformssockets: operating system level interface to the underlying communication protocolsTCP, UDP:User Datagram Protocol (UDP) transports data packets without guaranteesTransmission Control Protocol (TCP) verifies correct delivery of data streamsInternet Protocol (IP):moves a packet of data from one node to anotherTransactionalRPCObject orientedRPC (RMI)AsynchronousRPCTP-MonitorsObject brokersMessagebrokersApplicationserversSpecialized forms of RPC, typically with additionalfunctionality or properties but almost always running on RPC platformsWeb services: Concepts, Architectures and Applications - Chapter 2 5And the Internet? And Java?  Programming abstractions are a key part of middleware but not the only one:Ä a programming abstraction without good supporting infrastructure (i.e., a good implementation and support system underneath) does not help Programming abstractions, in fact, appear in many cases in reaction to changes in the underlying hardware or the nature of the systems being developed Java is a programming language that abstracts the underlying hardware: programmers see only the Java Virtual Machine regardless of what computer they useÄ code portability (not the same as code mobility)Ä the first step towards standardizing middleware abstractions (since now the can be based on a virtual platform everybody agrees upon) The Internet is a different type of network that requires one more specialization of existing abstractions:Ä The Simple Object Access Protocol (SOAP) of Web services is RPC wrapped in XML and mapped to HTML for easy transport through theInternetWeb services: Concepts, Architectures and Applications - Chapter 2 6Middleware as infrastructureDCE runtime environmentRPCprotocolssecurityservicecellservicedistributed file servicethreadserviceIDLsourcesinterfaceheadersIDL compilerIDLclientcodeclient stubRPC run timeservice librarylanguage specificcall interfaceRPC APIservercodeserver stubRPC run timeservice librarylanguage specificcall interfaceRPC APIclient process server processDCE developmentenvironmentWeb services: Concepts, Architectures and Applications - Chapter 2 7Infrastructure As the programming abstractions reach higher and higher levels, the underlying infrastructure implementing the abstractions must grow accordinglyÄ Additional functionality is almost always implemented through additional software layersÄ The additional software layers increase the size and complexity of the infrastructure necessary to use the new abstractions The infrastructure is also intended to support additional functionality that makes development, maintenance, and monitoring easier and less costlyÄ RPC => transactional RPC => logging, recovery, advanced transaction models, language primitives for transactional demarcation, transactional file system, etc.Ä The infrastructure is also there to take care of all the non-functional properties typically ignored by data models, programming models, and programming languages: performance, availability, recovery, instrumentation, maintenance, resource management, etc.Web services: Concepts, Architectures and Applications - Chapter 2 8Understanding middlewarePROGRAMMING ABSTRACTION Intended to hide low level details of hardware, networks, and distribution Trend is towards increasingly more powerful primitives that, without changing the basic concept of RPC, have additional properties or allow more flexibility in the use of the concept Evolution and appearance to the programmer is dictated by the trends in programming languages (RPC and C, CORBA and C++, RMI and Java, Web services and SOAP-XML)INFRASTRUCTURE Intended to provide a comprehensive platform for developing and running complex distributed systems Trend is towards service oriented architectures at a global scale and standardization of interfaces Another important trend is towards single vendor software stacks to minimize complexity and streamline interaction Evolution is towards integration of platforms and flexibility in the configuration (plus autonomic behavior) To understand middleware, one needs to understand its dual role as programming abstraction and as infrastructureWeb services: Concepts, Architectures and Applications - Chapter 2 9Basic middleware: RPC One cannot expect the programmer to implement a complete infrastructure for every distributed application. Instead, one can use an RPC system (our first example of low level middleware) What does an RPC system do?Ä Hides distribution behind procedure callsÄ Provides an interface definition language (IDL) to describe the servicesÄ Generates all the additional code necessary to make a procedure call remote and to deal with all the communication aspectsÄ Provides a binder in