Comparison and Evaluation of Middleware and Architecture

This view is concerned about how the system as a complex heterogeneous entity can be decomposed into interacting parts. The patterns in this view are:

• LAYERS - is used when one needs to decouple components in a vertical manner in order to support modifiability, portability and reusability. Within the same layer all constituent components work at the same level of abstraction. Between two adjacent layers clearly defined interfaces are provided. In the pure form of layers patterns, adjacent layers should not be by-passed to access other layers. It is useful to decouple high level from low responsibilities.An example for a layered app. is MICROKERNEL architecture with 3 Layers: external servers, the microkernel and internal servers.

• INDIRECTION LAYER - when a sub-system needs to be accessed by components, but the direct access is difficult to achieve and hard wiring is not favored. The similar situation may arise when two components written in different languages, in different systems try to access each other. In such situations INDIRECTION LAYER comes handy. It is the layer between accessing components and the instructions(API, interfaces) of a system to be accessed. It wraps all the accesses relevant to the system and should not be bypassed. It can also perform other tasks as converting and tracing invocations. This style can be implemented either as a part of sub-system (as in virtual machine) or be an independent entity (as in ADAPTER or FACEDE style). Basically the INDIRECTION LAYER hides sub-system providing services from the external world.

This view is concerned about how the system adapts itself during its lifecycle/evolution. In this architectural style system is viewed as being composed of two main parts - the core invariable component which mostly remains unchanged over the time and adaptable component/components which tend to be modified often. The patterns in this view are:

• MICROKERNEL - is handy when there is a range of systems with similar attributes/architecture as well as retaining specific features system per se. The microkernel realizes common/routine services (e.g. for OS it is scheduling, memory management) that all systems need. Apart from the core services system specific features are implemented as plug-in-play infrastructure/referred to as internal servers. In this sense the microkernel play the role of proxy between system specific internal servers and external servers which themselves serve as the mediators between user client applications and microkernel/internal servers. Clients can only access microkernel services through external server APIs. The microkernels are often structured in layers (abstract machine).

• REFLECTION - in this architectural style structural and behavioral aspects of a system are stored into meta-objects. The meta-objects are separated from the application logic components. To perform required functionality application logic components query meta-objects which provide required info about selected system properties, thus making the software self-aware. This provides a mechanism for changing structure and behavior of software systems dynamically. This style is useful in systems which often undergo unanticipated changes over their life cycle.This style can be viewed as an abstract machine of two layers: Meta object level and application logic level. The communication between layers can be in both directions. This architectural style can be build using INDIRECTION LAYER, for instance.

• INTERCEPTOR - this pattern is useful in situations when one needs to accomadate future changes into a software framework. It provides a mechanism to transparently update the services provided by the framework at runtime. An application can register any number of interceptors implementing new services. The pattern also allows external entities to monitor what is going inside the system.

This view is concerned with how systems offer an abstraction layer to the computation infrastructure. In this architectural style a system is viewed as the combination of components part native to the system environment(it can be hardware/software env.) and component which is not, e.g. a compiler. These two components can communicate indirectly with each other through another component which translates requests from non-native component to native one. The patterns in this category are:

• INTERPRETER - is used when the convertion is required at runtime. Requests are often parsed and executed within the same environment, Interpreter application. This provides good portability across many different systems (if those have implementation for the given interpreter). Interpreter also should be able to represent non-system/program state. Common programming languages using interpretation are Python, TCL, Perl, BASIC. Though interpreter and virtual machine perform similar tasks, they differ in that the former offers runtime execution.(Note that there are no interpreted languages but rather implementation. So when one says a language is interpreted, it is meant about its implementation, the same language can have compiled implementation).

• VIRTUAL MACHINE - can basically be considered as an abstract computer system on top of the real computer hardware. It performs similar task as the real hardware does but it is done in software. Unlike real hardware system, virtual machine executes intermediate code, byte-code, rather than a machine code (byte-code then translated into machine code, this is also done by VM). A program written in a particular language is compiled into byte-code by a byte-code compiler. This architectural style also offers portability across many platform for which virtual machine implementation exist. Examples of such systems are Java VM, Parrot/Perl VM, Python VM, Microsoft VM etc.

• RULE-BASED SYSTEM - an alternative to VM and interpreters are Rule-based systems which are required when rule-based/logical programming languages are used. Such a system does mainly consist of: facts, rules, and an engine that acts on them. Here rules represent knowledge in the form of condition and associated action, and facts represent data. Rules are applied to facts, which may lead to new facts and so on. Examples are Prolog language family systems/VMs.

These three architectural styles can be realized using INDIRECTION LAYER style.

This view is concerned with how individual components exchange data, while retaining their autonomy. Here a system is viewed as a number of independent components interacting with each other. The patterns in this category are:

• COMMUNICATION MODES - interaction between components can be established in two modes asynchronous and synchronous. In former client makes request and returns immediately to continue its work. In latter client makes request but blocks/waits till it receives a result of invocation from the server.
  • Asynchronous - in this mode the communication between client and server can have the following semantics:
    • Fire and Forget - describes best effort delivery and deoes not return any results or acknowledgements from the server.
    • Sync with Server - describes semantics where server sends acknowledgement to the client once it receive the request.
    • Poll Object - describes semantics where client periodically queries server for the result of the invocation.
    • Result Callback - contrary to the Poll object, it describes semantics where server notifies client of the results. So the communication is in opposite direction.

Both of these modes are applicable with Explicit and Implicit invocations.

• INVOCATION METHODS/PATTERNS
  • Explicit invocation - allows the client to invoke operation on the server. The client should provide information on how to locate and invoke operation explicitly through operation "name" and "parameters". In distributed object systems, this is usually is achieved through OBJECT IDs or ABSOLUTE OBJECT REFERENCES. With respect to the tasks of the applications in the system. Explicit invocation has the following variations.
    • Client-Server - in this pattern interacting components are not equal but organized as the service provider, server, and service consumer, client. Often several clients may request the same server at the same time, thus imposing the constraint on the server to be able to handle several clients simultaneously. Most of the modern distributed applications are organized as client-server.
    • Peer-to-Peer - in this pattern interacting components can both be a client and server. Here each component has equal standing. Since there is not a fixed relationship among components all components must be able to resolve information about each other and services. This is can be achieved by broadcasting or accessing a database where such information is contained. e.g. in ORCA2 it is achieved using ICE middleware IceGrid Registry service(naming service which resolves component names to their addresses).
  • Implicit invocation - in contrast to the explicit invocation in this method client does not invoke operation explicitly on the server but rather through some other mechanism(e.g. message broadcasting, publisher-subscriber) or component. This type of invocation is useful when side operations, which client is not aware of or doesn't need to handle explicitly, are performed. These can be such operations as dynamic removal/addition of other components, when the client doesn't know about server details, when server goes down and the state of the request should be saved until it is up etc.
    • Publisher-subscriber - is one of the mechanisms broadly used to implement implicit invocation. It allows components to interact based on the specific runtime events. This allows complete decoupling of components (this is not true for client-server) through the third proxy component. The proxy component is responsible for channeling specific events only to interested components. It is triggered by event producer (publisher) and automatically executes result callback to the consumer (subscriber). The main disadvantages of this pattern is that it does not make any assumption on the order of event processing (this can be resolved by MESSAGE QUEUING, though). The other issue is that consumers must register for specific events. This process is often more complex than, for instance, client-server coupling through RPC.

Main differences between explicit and implicit invocations are - (1) In explicit invocation, the operation is always initialized fromthe client to the server whereas it is not necessarily true in implicit invocation. (2) Among the types of invocation in either mode, only synchronous explicit invocation allows to align results of the invocation unambiguously. For all other cases it is not true.But one can achieve it through ASYNCHRONOUS COMPLETION TOKEN pattern.

• COMMUNICATION PERSISTENCE -
  • Persistent communication -
  • Transient communication -

This view is concerned about disseminating components over a distributed environment. It considers how distributed components interact with and how they are decoupled from each other. The following are architectural styles in this view:

• BROKER - it would be hard and not efficient to program both communication and application logic within one component. Imagine doing the same thing for a distributed network of components. This will also deteriorate portability, reusability attributes of the components. That is where BROKER patterns comes in. It decouples communication and application function functionalities of the distributed components. It hides all the communication primitives within a separate component. Broker component itself is composed of several other components which are responsible for request handling, invocation, request, marshaling of the requests, client-proxy etc. This distribution model is often used with CLIENT-SERVER interaction model but not limited to it. Additionally, it is common in Remote Object Invocation (ROI) oriented systems (but there are also for instance Message Brokers). Examples for such systems are CORBA implementations. In robotics the examples are systems using CORBA implementation, such as SmartSoft, OROCOS, MIRO.

• REMOTE PROCEDURE CALL - similar functionality to that of the BROKER pattern is provided by RPC pattern. RPC is the extension of standard program local procedure call to a distributed environment. It aims at abstracting all tricky details of network programming and allowing invocations behave as if they were local to a process. A similar mechanism is provided by Java RMI, XML-RPC, Microsoft .Net remoting.

• MESSAGE QUEUING - additionally to ROI and RPC based systems communication maybe message oriented. This is often useful when one of the involved sides undergoes temporal outages, heterogeneous system be integrated or when the receiver system is busy executing some operation when the client invokes an operation on it. Messages sent from the client are not directly forwarded to the server but rather go through message queue where they are temporarily stored. This ensures decoupling of the client from the server.

• Object Oriented Application Frameworks (classification according to the application Scope)
  • System infrastructure frameworks
  • Middleware integration frameworks
  • Enterprise application frameworks
• Object Oriented Application Frameworks (classification according to the Techniques used)
  • Whitebox frameworks
  • Blackbox frameworks

• Software architecture evaluation methodologies:some words on what is this all about
  • ATAM
  • SAAM
  • Scenario based (This is an important one for robotics): we were thinking of evaluating robotic software in three cases - mobile platform, mobile platform with manipulation capabilities and stand alone manipulation platform.
  • Questionnaire based
• Architecture description languages: some words on what is this all about
  • Acme
  • AADL
  • C2
  • Darwin
  • Wright