Middleware. Adapted from Alonso, Casati, Kuno, Machiraju Web Services Springer 2004

Transcription

1 Middleware Adapted from Alonso, Casati, Kuno, Machiraju Web Services Springer 2004

2 Outline Web Services Goals Where do they come from? Understanding middleware Middleware as infrastructure Communication paradigms Middleware as a programming abstraction A quick overview of conventional middleware platforms Remote Procedure Calling (RPC) Transaction Processing (TP) Monitors Object brokers & Object Monitors 2

3 The road to Web Services 3

4 Name No. Zip State OK Cancel View in Browser Typical ASP Today Name No. Zip State OK Download on Demand Name No. Zip State OK Cancel Name No. Zip State OK Cancel Cancel Software as a Service Name No. Zip State OK Access Service Cancel Web Service source: CBDi forum

5 How did we get there? How did we get there: the evolution of the architecture of distributed information systems In order to understand Web services, we need to take a step back and look at the way middleware and Enterprise Application Integration technology has been evolving in the last decades We will then be able to understand Web services architectures 5

6 Outline Web Services Goals Where do they come from? Understanding middleware Middleware as infrastructure Communication paradigms Middleware as a programming abstraction A quick overview of conventional middleware platforms Remote Procedure Calling (RPC) Transaction Processing (TP) Monitors Object brokers & Object Monitors 6

7 Middleware as Infrastructure

8 Basic concepts and notation Client Application Logic Resource Manager Client Server Database Presentation layer Business rules Business objects Client Business processes Persistent storage Client is any user or program that wants to perform an operation over the system. To support a client, the system needs to have a presentation layer through which the user can submit operations and obtain a result. The application logic establishes what operations can be performed over the system and how they take place. It takes care of enforcing the business rules and establishing the business processes. The application logic can be expressed and implemented in many different ways: constraints, business processes, server with encoded logic... The resource manager deals with the organization (storage, indexing and retrieval) of the data necessary to support the application logic. This is typically a database but it can also be a text retrieval system or any other data management system (business objects) providing querying capabilities and persistence. 8

9 A game of boxes and arrows There is no problem in system design that cannot be solved by adding a level of indirection. There is no performance problem that cannot be solved by removing a level of indirection. Each box represents a part of the system. Each arrow represents a connection between two parts of the system. The more boxes, the more modular the system: more opportunities for distribution and parallelism. This allows encapsulation, component based design, reuse. The more boxes, the more arrows: more sessions (connections) need to be maintained, more coordination is necessary. The system becomes more complex to monitor and manage. The more boxes, the greater the number of context switches and intermediate steps to go through before one gets to the data. Performance suffers considerably. System designers try to balance the flexibility of modular design with the performance demands of real applications. Once a layer is established, it tends to migrate down and merge with lower layers. 9

10 One tier: fully centralized 1-tier architecture Server The presentation layer, application logic and resource manager are built as a monolithic entity. Users/programs access the system through display terminals but what is displayed and how it appears is controlled by the server. (These are dumb terminals). This was the typical architecture of mainframes, offering several advantages: no forced context switches in the control flow (everything happens within the system), all is centralized, managing and controlling resources is easier, the design can be highly optimized by blurring the separation between layers. 10

11 Two tier: client/server 2-tier architecture Server As computers became more powerful, it was possible to move the presentation layer to the client. This has several advantages: Clients are independent of each other: one could have several presentation layers depending on what each client wants to do. One can take advantage of the computing power at the client machine to have more sophisticated presentation layers. This also saves computer resources at the server machine. The resource manager only sees one client: the application logic. This greatly helps with performance since there are no client connections/sessions to maintain. It introduces the concept of API (Application Program Interface). An interface to invoke the system from the outside. It also allows designers to think about federating the systems into a single system. 11

12 API in client/server Client/server systems introduced the notion of service (the client invokes a service implemented by the server) Together with the notion of service, client/server introduced the notion of service interface (how the client can invoke a given service) Taken all together, the interfaces to all the services provided by a server (whether there are application or system specific) define the server s Application Program Interface (API) that describes how to interact with the server from the outside Many standardization efforts were triggered by the need to agree to common APIs for each type of server service interface service service interface service server s API service interface service resource management layer service interface service server 12

13 The main limitation of client/server Server A Server B If clients want to access two or more servers, a 2-tier architecture causes several problems: the underlying systems don t know about each other there is no common business logic the client is the point of integration (increasingly fat clients) The responsibility of dealing with heterogeneous systems is shifted to the client. The client becomes responsible for knowing where things are, how to get to them, and how to ensure consistency This is tremendously inefficient from all points of view (software design, portability, code reuse, performance since the client capacity is limited, etc.). There is very little that can be done to solve this problems if staying within the 2 tier model. 13

14 Three tier: the rising of middleware 3-tier architecture In a 3 tier system, the three layers are fully separated. The layers are also typically distributed taking advantage of the complete modularity of the design (in two tier systems, the server is typically centralized) A middleware based system is a 3 tier architecture. This is a bit oversimplified but conceptually correct since the underlying systems can be treated as black boxes. In fact, 3 tier makes only sense in the context of middleware systems (otherwise the client has the same problems as in a 2 tier system). 14

15 Middleware clients Middleware: global application logic Local application logic Local resource managers Server A middleware Server B Middleware is just a level of indirection between clients and other layers of the system. It introduces an additional layer of business logic encompassing all underlying systems. By doing this, a middleware system: simplifies the design of the clients by reducing the number of interfaces, provides transparent access to the underlying systems, acts as the platform for intersystem functionality and high level application logic, and takes care of locating resources, accessing them, and gathering results. But a middleware system is just a system like any other! It can also be 1 tier, 2 tier, 3 tier... 15

16 N-tier: connecting to the Web client Web browser Web server HTML filter application logic layer resource management layer information system N-tier architecture presentation layer middleware N-tier architectures result from connecting several three tier systems to each other and/or by adding an additional layer to allow clients to access the system through a Web server The Web layer was initially external to the system (a true additional layer); today, it is slowly being incorporated into a presentation layer that resides on the server side (part of the middleware infrastructure in a three tier system, or part of the server directly in a two tier system) The addition of the Web layer led to the notion of application servers, which was used to refer to middleware platforms supporting access through the Web 16

17 Communication Paradigms

18 Blocking or synchronous interaction Traditionally, information systems use blocking calls (the client sends a request to a service and waits for a response of the service to come back before continuing doing its work) Synchronous interaction requires both parties to be on-line : the caller makes a request, the receiver gets Answer the request, processes the request, sends a response, the caller receives the response. The caller must wait until the response comes back. The receiver does not need to exist at the time of the call, but the interaction requires both client and server to be alive at the same time client Call idle time Because it synchronizes client and server, this mode of operation has several disadvantages: connection overhead higher probability of failures difficult to identify and react to server failures it is a one-to-one system; it is not really practical for nested calls and complex interactions (the problems becomes even more acute) Receive Response 18

19 Overhead of synchronism Synchronous invocations require to maintain a session between the caller and the receiver. Maintaining sessions is expensive and consumes CPU resources. There is also a limit on how many sessions can be active at the same time (thus limiting the number of concurrent clients connected to a server) For this reason, client/server systems often resort to connection pooling to optimize resource utilization have a pool of open connections associate a thread with each connection allocate connections as needed Synchronous interaction requires a context for each call and a context management system for all incoming calls. The context needs to be passed around with each call as it identifies the session, the client, and the nature of the interaction. request() do with answer request() do with answer session duration Context is lost Needs to be restarted!! receive process return receive process return 19

20 Failures in synchronous calls If the client or the server fail, the context is lost and resynchronization might be difficult. If the failure occurred before 1, nothing has happened If the failure occurs after 1 but before 2 (receiver crashes), then the request is lost If the failure happens after 2 but before 3, side effects may cause inconsistencies If the failure occurs after 3 but before 4, the response is lost but the action has been performed (do it again?) Who is responsible for finding out what happened? Finding out when the failure took place may not be easy. Worse still, if there is a chain of invocations (e.g., a client calls a server that calls another server) the failure can occur anywhere along the chain. request() do with answer request() do with answer timeout try again do with answer receive process return receive process return receive process return

21 Two solutions ENHANCED SUPPORT Client/Server systems and middleware platforms provide a number of mechanisms to deal with the problems created by synchronous interaction: Transactional interaction: to enforce exactly once execution semantics and enable more complex interactions with some execution guarantees Service replication and load balancing: to prevent the service from becoming unavailable when there is a failure (however, the recovery at the client side is still a problem of the client) ASYNCHRONOUS INTERACTION Using asynchronous interaction, the caller sends a message that gets stored somewhere until the receiver reads it and sends a response. The response is sent in a similar manner Asynchronous interaction can take place in two forms: non-blocking invocation (a service invocation but the call returns immediately without waiting for a response, similar to batch jobs) persistent queues (the call and the response are actually persistently stored until they are accessed by the client and the server) 21

22 Middleware as Abstraction and Infrastructure

23 Understanding middleware To understand middleware, one needs to understand its dual role as programming abstraction and as infrastructure PROGRAMMING 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) 23

24 Outline Web Services Goals Where do they come from? Understanding middleware Middleware as infrastructure Communication paradigms Middleware as a programming abstraction A quick overview of conventional middleware platforms Remote Procedure Calling (RPC) Transaction Processing (TP) Monitors Object brokers & Object Monitors 24

25 Basic middleware: IP, TCP, UDP and RPC The most accepted standard for network communication is IP (Internet Protocol) which provides unreliable delivery of single packets to one-hop distant hosts IP was designed to be hidden behind other software layers: TCP (Transport Control Protocol) implements connected, reliable message exchange UDP (User Datagram Protocol) implements unreliable datagram based message exchanges TCP/IP and UDP/IP are visible to applications through sockets. The purpose of the socket interface was to provide a UNIX-like abstraction Yet sockets are quite low level for many applications, thus, RPC (Remote Procedure Call) appeared as a way to hide communication details behind a procedural call bridge heterogeneous environments RPC is the standard for distributed (client-server) computing SOCKETS RPC TCP, UDP IP 25

26 The basics of client/server services Imagine we have a program (a server) that implements certain services. Imagine we have other programs (clients) that would like to invoke those services. To make the problem more interesting, assume as well that: client and server can reside on different computers and run on different operating systems the only form of communication is by sending messages (no shared memory, no shared disks, etc.) some minimal guarantees are to be provided (handling of failures, call semantics, etc.) we want a generic solution and not a one time hack Ideally, we want the programs to behave like this: Machine A (client) Service request messages Service response messages Execution Thread Machine B (server) sounds simple? Well, this idea is only ca. 30 years old: http 26

27 Problems to solve How to make the service invocation part of the language in a more or less transparent manner. Don t forget this important aspect: whatever you design, others will have to program and use How to exchange data between machines that might use different representations for different data types. This involves two aspects: data type formats (e.g., byte orders in different architectures) data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers. The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors (QoS) in the service invocation in a more or less elegant manner: server is down, communication is down, server busy, duplicated requests... 27

28 Problems to solve How to make the service invocation part of the language in a more or less transparent manner. Don t forget this important aspect: whatever you design, others will have to program and use How to exchange data between machines that might use different representations for different data types. This involves two aspects: data type formats (e.g., byte orders in different architectures) data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers. The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors (QoS) in the service invocation in a more or less elegant manner: server is down, communication is down, server busy, duplicated requests... 28

29 Programming languages: support for Remote Procedure Calls In procedural languages, the basic module is the procedure. A procedure implements a particular function or service that can be used anywhere within the program. It seemed natural to maintain this same notion when talking about distribution: the client makes a procedure call to a procedure that is implemented by the server. Since the client and server can be in different machines, the procedure is remote. Client/Server architectures are based on Remote Procedure Calls (RPC) Once we are working with remote procedures in mind, there are several aspects that are immediately determined: data exchange is done as input and output parameters of the procedure call pointers cannot be passed as parameters in RPC. The server is responsible for providing distributed references. 29

30 RPC schema One cannot expect the programmer to implement a complete infrastructure for every distributed application. Instead, one can use an RPC system: 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 case it has a distributed name and directory service system CLIENT Client process call to remote procedure CLIENT stub procedure Bind Marshalling Send Communication module Communication SERVER stub procedure module Unmarshalling Return Dispatcher (select SERVER stub) 30 remote procedure Server process

31 IDL (Interface Definition Language) All RPC systems have a language that allows to describe services in an abstract manner (independent of the programming language used). This language has the generic name of IDL (e.g., the IDL of SUN RPC is XDR) The IDL allows to define each service in terms of their names, and input and output parameters (plus maybe other relevant aspects). An interface compiler is then used to generate the stubs for clients and servers (rpcgen in SUN RPC). It might also generate procedure headings that the programmer can then used to fill out the details of the implementation. Given an IDL specification, the interface compiler performs a variety of tasks: generates the client stub procedure for each procedure signature in the interface. The stub will be then compiled and linked with the client code Generates a server stub. It can also create a server main, with the stub and the dispatcher compiled and linked into it. This code can then be extended by the designer by writing the implementation of the procedures It might generate a *.h file for importing the interface and all the necessary constants and types 31

32 Middleware as infrastructure client code client process DCE development environment IDL server process server code RPC API RPC run time service library RPC protocols language specific call interface client stub security service IDL sources IDL compiler interface headers cell service language specific call interface server stub RPC API RPC run time service library distributed thread file service service 32 DCE runtime environment

33 RPC in perspective ADVANTAGES RPC provided a mechanism to implement distributed applications in a simple and efficient manner RPC followed the programming techniques of the time (procedural languages) and fitted quite well with the most typical programming languages (C), thereby facilitating its adoption by system designers RPC allowed the modular and hierarchical design of large distributed systems: client and server are separate entities the server encapsulates and hides the details of the back end systems (such as databases) DISADVANTAGES RPC is not a standard, it is an idea that has been implemented in many different ways (not necessarily compatible) RPC allows designers to build distributed systems but does not solve many of the problems distribution creates. In that regard, it is only a low level construct RPC was designed with only one type of interaction in mind: client/server. This reflected the hardware architectures at the time when distribution meant small terminals connected to a mainframe. As hardware and networks evolve, more flexibility was needed 33

34 Problems to solve How to make the service invocation part of the language in a more or less transparent manner. Don t forget this important aspect: whatever you design, others will have to program and use How to exchange data between machines that might use different representations for different data types. This involves two aspects: data type formats (e.g., byte orders in different architectures) data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers. The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors (QoS) in the service invocation in a more or less elegant manner: server is down, communication is down, server busy, duplicated requests... 34

35 Interoperability: data exchange When exchanging data between clients and servers residing in different environments (hardware or software), care must be taken that the data is in the appropriate format: byte order: differences between little endian and big endian architectures (high order bytes first or last in basic data types) data structures: like trees, hash tables, multidimensional arrays, or records need to be flattened (cast into a string so to speak) before being sent This is best done using an intermediate representation format The concept of transforming the data being sent to an intermediate representation format and back has different (equivalent) names: marshalling/un-marshalling serializing/de-serializing The intermediate representation format is typically system dependent. For instance: SUN RPC: XDR (External Data Representation) Java: Serialization Having an intermediate representation format simplifies the design, otherwise a node will need to be able to transform data to any possible format 35

36 Problems to solve How to make the service invocation part of the language in a more or less transparent manner. Don t forget this important aspect: whatever you design, others will have to program and use How to exchange data between machines that might use different representations for different data types. This involves two aspects: data type formats (e.g., byte orders in different architectures) data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers. The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors (QoS) in the service invocation in a more or less elegant manner: server is down, communication is down, server busy, duplicated requests... 36

37 Binding: service discovery A service is provided by a server located at a particular IP address and listening to a given port Binding is the process of mapping a service name to an address and port that can be used for communication purposes Binding can be done: locally: the client must know the name (address) of the host of the server distributed: there is a separate service (service location, name and directory services, etc.) in charge of mapping names and addresses. These service must be reachable to all participants With a distributed binder, several general operations are possible: REGISTER (Exporting an interface): A server can register service names and the corresponding port WITHDRAW: A server can withdraw a service LookUP (Importing an interface): A client can ask the binder for the address and port of a given service There must also be a way to locate the binder (predefined location, environment variables, broadcasting to all nodes looking for the binder) 37

38 Problems to solve How to make the service invocation part of the language in a more or less transparent manner. Don t forget this important aspect: whatever you design, others will have to program and use How to exchange data between machines that might use different representations for different data types. This involves two aspects: data type formats (e.g., byte orders in different architectures) data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers. The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors (QoS) in the service invocation in a more or less elegant manner: server is down, communication is down, server busy, duplicated requests... 38

39 Call semantics: QoS A client makes an RPC to a service at a given server. After a time-out expires, the client may decide to re-send the request. If after several tries there is no success, what may have happened depends on the call semantics: Maybe: no guarantees. The procedure may have been executed (the response message(s) was lost) or may have not been executed (the request message(s) was lost). It is very difficult to write programs based on this type of semantics since the programmer has to take care of all possibilities At least-once: the procedure will be executed if the server does not fail, but it is possible that it is executed more than once. This may happen, for instance, if the client re-sends the request after a time-out. If the server is designed so that service calls are idempotent (produce the same outcome given the same input), this might be acceptable. At most-once: the procedure will be executed either once or not at all. Re-sending the request will not result in the procedure executing several times 39

40 Problems to solve: also for WS How to make the service invocation part of the language in a more or less transparent manner. Don t forget this important aspect: whatever you design, others will have to program and use How to exchange data between machines that might use different representations for different data types. This involves two aspects: data type formats (e.g., byte orders in different architectures) data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers. The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors (QoS) in the service invocation in a more or less elegant manner: server is down, communication is down, server busy, duplicated requests... 40