Chapter 2
Middleware Principles and Basic Patterns

2.1  Services and Interfaces

2.1.1  Basic Interaction Mechanisms

Figure 2.1: Some basic interaction mechanisms

Figure 2.2: Inversion of control

2.1.2  Interfaces

• the usage view: an interface defines the operations and data structures to be used for the provision of a service;
  
  
• the contract view: an interface defines a contract between the requester and the provider of a service.
  
  

Figure 2.3: Interfaces

• synchronous procedure or method call, with parameters and return value;
  
  
• access to an attribute, i.e. a data structure (this can be converted into the previous form by means of "getter" or "setter" functions on the elements of the data structure);
  
  
• asynchronous procedure call;
  
  
• event source or sink;
  
  
• data stream provider (output channel) or receiver (input channel);
  
  

2.1.3  Contracts and Interface Conformance

• Level 1 applies to the form of the operations, usually by defining types for the operations and parameters. This part of the contract can be statically verified.
  
  
• Level 2 applies to the dynamic behavior of the operations of the interface, by specifying the semantics of each operation.
  
  
• Level 3 applies to the dynamic interactions between the operations of an interface, by specifying synchronization constraints between the execution of these operations. If the service is composed of several interfaces, there also may exist constraints between the execution of operations belonging to different interfaces.
  
  
• Level 4 applies to the extra-functional properties, i.e. those that do not explicitly appear in the interfaces. The term "Quality of Service" (QoS) is also used for these properties, which include performance, security, availability, etc.
  
  

Syntactic Contracts

• Proc1 and Proc2 have the same number of parameters and return values (declared exceptions are considered as return values).
  
  
• For each return value R1 of Proc1, there is a matching return value R2 of Proc2 such that T(R2) \sqsubseteq T(R1) (this is called a covariant relationship).
  
  
• For each entry parameter X1 of Proc1, there is a matching entry parameter X2 of Proc2 such that T(X1) \sqsubseteq T(X2) (this is called a contravariant relationship).
  
  

Behavioral Contracts

Synchronization Contracts

Quality of Service Contracts

• Availability. The availability of a service is a statistical measure of the fraction of the time during which the service is ready for use. This depends both on the failure rate of (parts of) the system that delivers the service and on the time it takes to restore service after a failure.
  
  
• Performance. This quality covers several aspects, which are essential for real-time applications (applications whose correctness or usability relies on timing constraints). Some of these aspects are related to communication (bounds on latency, jitter, bandwidth); others apply to processing speed or data access latency.
  
  
• Security. Security covers properties related to the correct use of a service by its users, according to specified rules of usage. It includes confidentiality, integrity, authentification, and access rights control.
  
  

2.2  Architectural Patterns

2.2.1  Multilevel Architectures

Layered Architectures

Figure 2.4: Layered system organizations

Multitier Architectures

Figure 2.5: Multitier architectures

Frameworks

• The microkernel proper, which manages the hardware resources (processor, memory, I/O, network communication), and provides an abstract resource management API to the upper level.
  
  
• The kernel, which implements a specific operating system (a "personality") using the API of the microkernel.
  
  

• The kernel analyzes the call and downcalls the microkernel using the appropriate function of its API.
  
  
• The microkernel upcalls a server in the kernel. Upon return, the microkernel may interact with the hardware; this sequence may be iterated, e.g. if more than one server is involved.
  
  
• The microkernel returns to the kernel, which completes the work and returns to the application.
  
  

Figure 2.6: Framework architectures

2.2.2  Distributed Objects

Objects in Programming

• Encapsulation. An object has an interface, which comprises a set of methods (procedures) and attributes (values that may be read and written). The only way of accessing an object (consulting or changing its state) is through its interface. No part of the state is visible from outside the object, other than those explicitly present in the interface, and the user of an object should not rely on any assumption about its implementation. The type of an object is defined by its interface.
  As explained in 2.1.2, encapsulation achieves independence between interface and implementation. The interface acts as a contract between the user and the implementer of an object. Changing the implementation of an object is invisible to its users, as long as the interface is preserved.
  
  
• Classes and instances. A class is a generic description that is common to a set of objects (the instances of the class). The instances of a class have the same interface (hence the same type), and their state has the same structure; they differ by the value of that state. Each instance is identified as a distinct entity. Instances of a class are dynamically created, through an operation called instantiation; they may also be dynamically deleted, either explicitly or automatically (by garbage collection) depending on the specific implementation of the object model.
  
  
• Inheritance. A class may be derived from another class by specialization, i.e. by defining additional methods and/or additional attributes, or by redefining (overloading) existing methods. The derived class is said to extend the initial class (or base class) or to inherit from it. Some models also allow a class to inherit from more than one class (multiple inheritance).
  
  
• Polymorphism. Polymorphism is the ability, for a method, to accept parameters of different types and to have a different behavior for each of these types. Thus an object may be replaced, as a parameter of a method, by a "compatible" object. The notion of compatibility, or conformance (2.1.3) is expressed by a relationship between types, which depends on the specific programming model or language being used.
  
  

Remote Objects

• Heterogeneity is a dominant feature of these systems. Encapsulation is a powerful tool in a heterogeneous environment: the user of an object only needs to know an interface for that object, which may have different implementations on different locations.
  
  
• Dynamic creation of object instances allows different objects to be created with the same interface, possibly at different remote locations; of course middleware must again provide a mechanism for remote object creation, in the form of factories (2.3.2).
  
  
• Inheritance is a mechanism for reuse, as it allows a new interface to be defined in terms of an existing one. As such, it is useful for distributed applications developers, who are confronted with a changing environment and have to define new classes to deal with new situations. In order to use inheritance, a generic (base) class is first designed to capture a set of object features that are common to a wide range of expected situations. Specific, more specialized, classes are then defined by extending the base class. For example, an interface for a color video stream may be defined as an extension of that of a (generic) video stream. An application that uses video stream objects also accepts color video streams, since these objects implement the video stream interface (this is an instance of polymorphism).
  
  

Figure 2.7: Remote Method Invocation

2.3  Patterns for Distributed Object Middleware

2.3.1  Proxy

1. Context. This pattern is used for applications organized as a set of objects in a distributed environment, communicating through remote method invocation: a client requests a service provided by some possibly remote object (the servant).
   
   
2. Problem. Define an access mechanism that does not involve hard-coding the location of the servant into the client code, and does not necessitate deep knowledge of the communication protocols by the client
   
   
3. Desirable Properties. Access should be efficient at run time. Programming should be simple for the client; ideally there should be no difference between local and remote access (this property is known as access transparency).
   
   
4. Constraints. The main constraint results from the distributed environment: the client and the server are in different address spaces.
   
   
5. Solution. Use a local representative of the server on the client site. This representative has exactly the same interface as the servant. All information related to the communication system and to the location of the servant is hidden in the proxy, and thus invisible to the client.
   The organization of the proxy is shown on Figure 2.8.
   Figure 2.8: Proxy
   The internal structure of the proxy follows a well-defined pattern, which facilitates its automatic generation.
   • a pre-processing phase, which essentially consists of marshalling the parameters and preparing the request message.
     
     
   • the actual invocation of the servant, using the underlying communication protocol to send the request and to receive the reply.
     
     
   • a post-processing phase, which essentially consists of unmarshalling the return values.
     
     
   
   
   
6. Known Uses.
   In middleware construction, proxies are used as local representatives for remote objects. They do not add any functionality. Examples may be found in Chapter 5 .
   Some variants of proxies contain additional functions. Examples are client-side caching and client-side adaptation. In this latter case, the proxy may filter server output to adapt it to specific client display capabilities, such as low resolution. Such "smart" proxies actually combine the standard functions of a proxy with those of an interceptor (2.3.4).
   
   
7. References.
   Discussions of the PROXY pattern may be found in [Gamma et al. 1994], [Buschmann et al. 1995].
   
   

2.3.2  Factory

1. Context. Applications organized as a set of objects in a distributed environment (the notion of "object" in this context may be quite general, and is not limited to objects as defined in object-oriented languages).
   
   
2. Problem. Dynamically create families of related objects (e.g. instances of a class), while allowing some decisions to be deferred to run time (e.g. choosing a concrete class to implement a given interface).
   
   
3. Desirable Properties. The implementation details of the created objects should be abstracted away. The creation process should allow parameters. Evolution of the mechanism should be easy (no hard-coded decisions).
   
   
4. Constraints. The main constraint results from the distributed environment: the client (requesting object creation) and the server (actually performing creation) are in different address spaces.
   
   
5. Solution. Use two related patterns: an ABSTRACT FACTORY defines a generic interface and organization for creating objects; the actual creation is deferred to concrete factories. ABSTRACT FACTORY may be implemented using FACTORY METHODS (a creation method that is redefined in a subclass).
   Another way of achieving flexibility is to use a Factory Factory, as shown on Figure 2.9 (the creation mechanism itself is parameterized).
   A Factory may also be used as a manager of the objects that it has created, and may thus implement a method to look up an object (returning a reference for it), and to remove an object upon request.
   Figure 2.9: Factory
   
   
   
6. Known Uses.
   FACTORY is one of the most widely used patterns in middleware. It is both used in applications (to create remote instances of application objects) and within middleware itself (one example is binding factories, described in Chapter 3 ). Factories are also used in relation to components (Chapter 7 ).
   
   
7. References.
   The two patterns ABSTRACT FACTORY and FACTORY METHOD are described in [Gamma et al. 1994].
   
   

2.3.3  Adapter

1. Context. Service provision, in a distributed environment: a service is defined by an interface; clients request services; servants, located on remote servers, provide services.
   
   
2. Problem. Reuse an existing servant by providing a different interface for its functions in order to comply to the interface expected by a client (or class of clients).
   
   
3. Desirable Properties. The interface conversion mechanism should be run-time efficient. It should also be easily adaptable, in order to respond to unanticipated changes in the requirements (e.g. the need to reuse a new class of applications). It should be reusable (i.e. generic).
   
   
4. Constraints. No specific constraints.
   
   
5. Solution. Provide a component (the adapter, or wrapper) that screens the servant by intercepting method calls to its interface. Each call is prefixed by a prologue and followed by an epilogue in the adapter (Figure 2.10). The parameters and results may need to be converted.
   Figure 2.10: Adapter
   In some simple cases, an adapter can be automatically generated from the description of the provided and required interfaces.
   
   
6. Known Uses.
   Adapters are widely used in middleware to encapsulate server-side functions. Examples include the Portable Object Adapter (POA) of CORBA (Chapter 5 ), and the various adapters for reusing legacy systems, such as the Java Connector Architecture (JCA).
   
   
7. References.
   ADAPTER (also known as WRAPPER) is described in [Gamma et al. 1994]. A related pattern is WRAPPER FAçADE ([Schmidt et al. 2000]), which provides a high-level (e.g. object-oriented) interface to low level functions.
   
   

2.3.4  Interceptor

1. Context. Service provision, in a distributed environment: a service is defined by an interface; clients request services; servants, located on remote servers, provide services. There is no restriction on the form of communication (e.g. uni- or bi-directional, synchronous or asynchronous).
   
   
2. Problem. One wants to enhance an existing service with new capabilities, or to provide it by different means.
   
   
3. Desirable Properties. The mechanism should be generic (applicable to a wide variety of situations). It should allow static (compile time) or dynamic (run time) service enhancement.
   
   
4. Constraints. Services may be added or removed dynamically.
   
   
5. Solution. Create interposition objects (statically or dynamically). These objects intercept calls (and/or returns) and insert specific processing, that may be based on contents analysis. An interceptor may also redirect a call to a different target.
   Figure 2.11: Simple forms of Interceptor
   This mechanism may be implemented in a variety of forms. In the simplest form, an interceptor is a module that is inserted at a specified point in the call path between the requester and the provider of a service (Figure 2.11a and 2.11b). It may also be used as a switch between several servants that may provide the same service with different enhancements (Figure 2.11c), e.g. provision for fault tolerance, load balancing or caching.
   In a more general form (Figure 2.12, interceptors and service providers (servants) are managed by a common infrastructure and created upon request. The interceptor uses the servant interface and may also rely on services provided by the infrastructure. The servant may provide callback functions to be used by the interceptor.
   
   
6. Known Uses.
   Interceptors are used in a variety of situations in middleware systems.
   • to enhance existing applications or systems with new capabilities. An early example is the subcontract mechanism [Hamilton et al. 1993]. The CORBA Portable Interceptors (further described in Chapter 5 ) provide a systematic way to extend the functionality of the Object Request Broker by inserting interception modules at predefined points in the call path. Other uses include the support of fault tolerance mechanisms (e.g. providing support for object groups), as described in Chapter 9 .
     
     
   • to select a specific implementation of a servant at run time.
     
     
   • to implement frameworks for component-based applications (see Chapter 7 ).
     
     
   • to implement reflective middleware (see 2.4.1 and 2.4.3).
     
     
   Figure 2.12: General Interceptor
   
   
   
7. References.
   The INTERCEPTOR pattern is described in [Schmidt et al. 2000].
   
   

2.3.5  Comparing and Combining Patterns

• ADAPTER vs PROXY. ADAPTER and PROXY have a similar structure. PROXY preserves the interface, while ADAPTER transforms the interface. In addition, PROXY often (not always) involves remote access, while ADAPTER is usually on-site.
  
  
• ADAPTER vs INTERCEPTOR. ADAPTER and INTERCEPTOR have a similar function: both modify an existing service. The main difference is that ADAPTER transforms the interface, while INTERCEPTOR transforms the functionality (actually INTERCEPTOR may completely screen the initial target, replacing it by a different servant).
  
  
• PROXY vs INTERCEPTOR. A PROXY may be seen as a special form of an INTERCEPTOR, whose function is restricted to forwarding a request to a remote servant, performing the data transformations needed for transmission, and abstracting away the communication protocol. Actually, as mentioned in 2.3.1, a proxy may be combined with an interceptor, making it "smart" (i.e. providing new functionalities in addition to request forwarding, but leaving the interface unchanged).
  
  

Figure 2.13: Using patterns in an ORB

2.4  Achieving Adaptability and Separation of Concerns

2.4.1  Meta-Object Protocols

• The base level, which provides the functionalities defined by the system's specifications.
  
  
• The meta-level, which uses a representation of the entities of the base level in order to observe or modify the behavior of the base level.
  
  

1. The method call is reified into an object m, which contains a representation of meth and params. The precise form of this representation is defined by the MOP. This object m is transmitted to the meta-object, which executes Meta_Obj.meta_MethodCall(m).
   Figure 2.14: Performing a method call in a reflective system
   
   
   
2. The method meta_MethodCall(m) then executes any processing specified by the MOP. To take simple examples, it may print the name of the method (by calling a method such as m.methName.printName()) before actually executing it (for tracing) or it may save the state of the object prior to the method call (to allow undo operations), or it may check the value of the parameters, etc.
   
   
3. The meta-object may now actually execute the initial call⁷, by invoking a method baseMethodCall(m) which essentially performs Obj.meth(params)⁸. This step (the inverse of reification) is called reflection.
   
   
4. The meta-object then executes any post-processing defined by the MOP, and returns to the initial caller.
   
   

Figure 2.15: Object creation in a reflective system

2.4.2  Aspect-Oriented Programming

• Many different concerns (or "aspects") are usually present within an application (common examples include security, persistence, fault-tolerance, and other extra-functional properties).
  
  
• The code related to these concerns is usually tightly intermixed with the "functional" application code, which makes changes and additions difficult and error prone.
  
  

• The main part of the application (the base program), and the parts that deal with different additional aspects are written independently, possibly using specialized languages for the aspect code.
  
  
• All these pieces are integrated to form the global application, using a composition tool (aspect weaver).
  
  

AspectJ

public aspect MethodWrapping{

/* point cut definition */
    pointcut Wrappable(): call(public * MyClass.*(..));

/* advice definition    */
    around(): Wrappable() {
        /* prelude: a sequence of code to be inserted before the call */
           proceed (); /* performs the call to the original method    */
        /* postlude: a sequence of code to be inserted after the call */
    }
}

Footnotes: