Modeling of Pattern-Based Customizable Middleware
ProblemStatement:
To design a Domain Specific Modeling Language (DSML) which would enable:
•Modeling of the composition and assemblies of middleware building blocks
•Modeling of QoS Features
•Modeling of input workloads for system validation
Motivation:
Run-time decisions on middleware composition can be expensive both in terms of validation of the composed system as well as the reworking effort incurred due to incorrect composition and configuration decisions. Moreover, fine tuning the performance of the assembled system using ad hoc means of selecting the right configuration and customization options incur numerous accidental complexities, and do not provide the system integrators with any intuitive means of reasoning about the assembled system. Therefore, there is a need to address this problem at design-time by raising the level of abstraction at which system integrators can reason about the system using domain artifacts they are conversant with, and drive the platform composition and configuration using domain-imposed QoS and functional requirements.
Our solution:
Model-integrated computing (MIC) provides an ideal solution to address the challenges of middleware composition and configuration outlined above. An MIC solution to address these challenges will require a modeling language, which will enable the system integrators to compose middleware platforms by modeling the compositions and assemblies of different middleware building blocks. Additional modeling elements in the form of QoS (and functional) features can decorate these models, and serve to identify the appropriate configurations and customizations. Generative techniques associated with such a modeling tool can be used to validate if the composed system can guarantee the desired performance for a given set of input workloads.
Project Description:
The project will entail the following:
•A modeling paradigm that will provide the means to model three views of a composable system:
–Pattern-based building blocks,
–Features that customize these building blocks,
–Workload description for performance evaluation of system
•Interpreters to generate:
–Configuration & Script File: These files will be used by middleware to select different knobs to customize the end system of building blocks.
–Benchmarking Parameter File: These parameters will be used by the benchmarking code library for testing the performance of the end system.
Our DSML therefore has three paradigms:
- The Pattern Paradigm
Our PatternParadigm consists of two patterns – the Reactor Pattern and the Acceptor-Connector Pattern.
- The Feature Paradigm
- The Benchmarking Paradigm
The Pattern Paradigm:
The Pattern Paradigm can be seen in the Pattern Aspect. This is where the modeler would actually construct middleware using the different pattern-based building blocks. Using the Pattern Aspect, the modeler can model the inter-pattern as well as intra-pattern relationships. As of now, we have the ability to model the Reactor and the Acceptor-Connector building blocks. These blocks are visible in the feature and benchmarking aspects, but they can be added only in the pattern aspect.
The Reactor Pattern:
The Reactorarchitectural pattern allows event-driven applications to demultiplex and dispatch service requests that are delivered to an application from one or more clients. The Reactor pattern inverts the flow of control in a system during event handling.
The structure of the Reactor pattern, as given in [1] is shown in Fig. 1.
Fig. 1: The Reactor Pattern
The following is a brief description of the reactor pattern:
In the initialization phase, each Event Handler registers itself with the Reactor by passing its Handle to the Reactor. The Handle uniquely identifies an Event Handler. The Reactor collects all the registered handlers into a set called the Handle Set. It then waits for the Synchronous Event Demultiplexer to notify it when an event occurs. During the event handling phase, the Synchronous Event Demultiplexer channels the handle of the event to the Reactor. The reactor searches through the Handle Set, and if the Handle has an Event Handler registered for it, it dispatches that Event Handler. The Event Handler, upon receiving the dispatch call, process the event and then returns. Thus the Reactor has inverted the flow of control, i.e. the Event Handler does not have to poll for an event to occur; the reactor notifies it if that happens.
The Reactor Meta-Model:
Our meta-model follows the structure of the Reactor detailed in the book Pattern Oriented Software Architecture Vol. II. Fig. 2 shows the meta-model for the reactor pattern.
Fig.2: The Reactor Meta-Model
The Reactor Pattern meta-model consists of the following participants:
1.Reactor: The reactor dispatches the Event Handlers.
2.Synchronous Event Demultiplexer: The Reactor uses the Synchronous Event Demultiplexer for event notification.
3.Handle Set: The handle set is the set of all registered event handles.
4.Event Handler: The event handler owns a handle which is registered with the Reactor.
5.Handle: The handle uniquely identifies an Event Handler and the event that the event handler handles.
The modeler can model the number of event handlers present in the system, and also which of these handlers can be registered with the reactor. Along with this, the modeler also sets the following attributes:
Event Handler Type: This is the type of event that the Event handler is prepared to handle. It can be read, write or accept.
Handle Name: This is the unique handle ID.
Ready: This is a Boolean value which indicates whether a handle is ready (i.e. whether an event has been generated for that handle).
The Acceptor Connector Pattern:
It is a design pattern that decouples connection establishment and service initialization in a distributed system from subsequent processing performed by the two end points of a service once they are connected and initialized [2]. Fig. 3[1] shows the structure of the Acceptor-Connector Pattern. Our meta-model for this pattern is shown in Fig. 4.
Fig.3: The Acceptor-Connector Pattern
Participants:
Acceptor: It is a factory that implements passive strategy to establish a connection and initialize the associated Service Handler. It creates a passive mode endpoint transport factory (transport handle) that has necessary endpoints needed by the Service Handlers.
Connector: Is a factory that implements the active strategy to establish a connection and initialize the associated Service Handler. It initiates the connection with a remote Acceptor. It hassynchronous (using reactor pattern) and asynchronous mode (using proactor pattern) of connections
Dispatcher: Is in charge of registering, removing and dispatching the events that occurs on the registered handles by calling back application-specific Event Handlers. Dispatcher is for management of registered Event Handlers.
Service Handler: Implements an application service, typically playing the client role, server role or both roles. It provides a hook method that is called by an Acceptor or Connector to activate the application service when the connection is established. The Service Handler uses the Handle component referencing to its peer for data-mode exchange with its connected peer Service Handler. So once the Service Handler is complete initialized by Acceptor and Connector factory it typically does not interact with these component any further.
Collaborations:
In Acceptor- Connector pattern the collaboration between server and client among different participants discussed above will be as follows [3]:
Server side:
- Initialization phase
Server creates Dispatcher that will handle the events associated with it. It has then to create one Acceptor for each type of service it is offering to its clients. Each Acceptor registers itself to the Dispatcher so that it can handle events coming from a client on the Transport Handle. Dispatcher can then handle all the registered events by listening to the associated Handles.
- Service initialization
Dispatcher detects some event on the Handle of some Acceptor. It then calls the handle event method of this Acceptor for him to handle this particular event. The Acceptor creates a new service handler that will be in charge of processing the requests of the client. This Service Handler registers itself to the Dispatcher
- Service use
After this stage Dispatcher will directly initiate server client communication using Service Handlers.
- Service closure
After whole process is done, Service Handler will call the remove handler method of the Dispatcher to make it stop listening on its Transport Handle for the events he had registered before.
Fig. 4: Meta-Model of the Acceptor-Connector Pattern
Client side: Connector pattern contains options to have synchronous or asynchronous type of connection but because for the scope of this project we are supporting only synchronous mode of connection.
- Initialization phase
The client creates a Dispatcher that will handle the events associated with this client. Then it has to create one Connector and one Service Handler (that will be in charge of requesting the server peer service handler) for each type of service needed. For this, the Connector generates an event and sends it on the Handle of the server Acceptor in charge of the desired service. In return, the Connector gets a connection end point that corresponds to theHandle of the peer Service Handler. It can then open the client Service Handler. This one can then register itself to the Dispatcher.
- Service use
When the Dispatcher detects an event on the Handle of the client Service handler, it calls the handle event method of this Service Handler. When the Dispatcher detects a ready event on the client Service Handler, it calls its Handle event method. The Service Handler then gets the results from server.
- Service closure
If a client Service Handler wants to close the service, it generates a close event on its server Service Handler’s Handle. Then it is removedfrom the list of Dispatcher by calling the remove handler method.
The Feature Paradigm:
Feature modeling allows model users to use domain-specific artifacts to model a system in contrast to using low-level platform-specific artifacts. The feature modeling in our modeling paradigm will provide structural representation of different possible middleware pattern properties. In our case the feature modeling comprise modeling several non functional and QoS requirements, such as the choice of network transport, listening end points, multithreaded requirements, periodicity of request etc, all represented as higher-level artifacts. This will enable system integrators to select various strategies, resources, settings and factories that can be parameterized according to user needs by driving it from a very high level feature modeling. Fig. 5 shows the meta-model for the Feature Aspect.
Following are the pattern specific features that can be modeled using our modeling language:
Reactor Pattern:
Concurrency: It is important to develop ORB’s that manage concurrent processing efficiently. Concurrency allows long-running operations to execute simultaneously without impeding the progress of other operations.
Default server strategy factory provided by ACE/TAO [4] supports two types of concurrency (-ORBConcurrency) strategies:
- Reactive: This is a default type. It registers the connections transport end points with Reactor. When events occur, it starts dispatching these events to the reactive connections in order. Reactive connections are single-threaded which is why it is scalable but is not good for concurrency.
- Thread per connection: The ORB handles new connections by spawning a new thread whose job is to service requests coming from the connection.
Reactor Type: This option (-ORBReactorType) [4] helps to specify what type of reactor to use
•Thread pool (tp): It uses the ACE_TP_Reactor, a select based thread pool reactor which is the default.
•Multi threaded (select_mt): It uses the multi-thread select based reactor.
•Single threaded (select_st): It uses single-thread select based reactor.
•Wait for multiple objects (wfmo): It uses WFMO reactor and can be used only for windows.
•Message Wait for multiple objects (msg_wfmo): It uses Msg WFMO reactor. It is used only for windows.
Thread Queue: This option (–ORBThreadQueue) helps to specify what type of thread queue to use.This feature applies only to the ACE_TP_Reactor, i.e., when reactor type is thread pool. And it specifies the order, last-in-first-out (LIFO), the default, or first-in-first-out (FIFO), in which waiting threads are selected to run by the ACE_Select_Reactor_Token.
Acceptor-Connector:
End points: This option instructs a server ORB to listen for requests on the interface specified by endpoint. ACE/TAO endpoints are specified using a URL style format. There are many options to specify end points such asORBListenEndpoints and ORBEndpoints. Following are the endpoints that can be modeled:
•Listening ports
•Host Name
•Protocol (TCP, UDP or Shared Memory)
Fig. 5: The Features Meta-Model
Configurator Interpreter:
Configurator Interpreter generates service configurator file (svc.conf) and a script file.
Service Configurator file is used by applications. It has different options that control the behavior of strategies and resources used by middleware framework. This file allows application to configure service objects statically and dynamically configuring middleware.
Options in svc.conf file can represents either the components provided by middleware framework or customized components developed by users. If this configurator file is not available, ACE/TAO middleware framework [6] selects all default configurations.
Following are the different factories that can be configured:
- Advance Resource Factories: This factory controls the creation of configurable resources used by ACE/TAO's ORB core. The resource factory is responsible for constructing and providing access to various resources used by the ORB irrespective of whether they perform client or server roles.
- Server Strategy factory:This factory creates various strategies of special utility to the ORB that is useful for controlling the behavior of servers. This factory is responsible for creating strategies useful for server objects like the concurrency strategy and the request demultiplexing strategies used by the POA.
- Client Strategy factory:This factory creates various strategies of special utility to the ORB, useful for controlling the behavior of clients. This factory is responsible for creating strategies useful for clients such as request multiplexing strategies, wait strategies, connect strategies etc.
Svc.conf will contain strategies like this:
static Advanced_Resource_Factory "-ORBReactorType tp –ORBReactorThreadQueue LIFO"
static Server_Strategy_Factory "-ORBConcurrency reactive"
Script file has inputs to run any application like Naming service or benchmarking evaluation tool with proper end points like listening ports, protocol and host name.
benchmark_test -ORBEndpoint iiop://127.0.0.1:9000
The BenchmarkingParadigm:
The benchmarking paradigm allows a modeler to model the system workload for the purposes of verification. Fig. 6 shows the Benchmarking meta-model.
The meta-model consists of the following participants:
1. The proxy of reactor pattern which has been defined in the Patterns Aspect.
2. Threads, which are the number of client connections or threads.
3. The metric which is to be measured. It can be either
a. The round-trip latency
b. The throughput
For each of these metrics to be measured, the modeler can specify:
- The number of test runs (given by the number of data exchanges)
- The data which is to be used for the test.
4. The service time, which is the time taken by an event handler to service an event. It can follow either a uniform or an exponential distribution.
Fig. 6: The Benchmarking Meta-Model
The Benchmarking Interpreter:
The benchmarking interpreter is used to generate an output XML file containing the benchmarking parameters. This XML file is used as input to an existing benchmarking code library.
A sample generated XML file is given below:
benchmark_inputs
connections10</connections
dataABCDEF</data
data_exchanges200</data_exchanges
reactor_inputs
reactor_typewfmo</reactor_type
handlers2</handlers
service_timeUniform</service_time
</reactor_inputs
</benchmark_inputs
The interpreter extracted the data in the following manner:
The number of connections, data exchanges, the data to be sent and the handler service time were extracted from the Benchmarking aspect. The reactor type (wfmo) was taken from the Features aspect. The number of handlers was extracted from the Pattern Aspect for the Reactor block.
Future Work:
•We planto model other pattern-based building blocks of middleware and their relationships with each other, as shown in Fig. 7 [5].
Fig. 7 Patterns in Middleware
•The features model could be enhanced to include more features for each building block.
•As a long-term goal, we envision that a modeler would be able to generate middleware code automatically through our DSML and associated interpreters
•Right now the configurator interpreter generated configuration files specific to thecae middleware. We plan to enhance this interpreter for other platforms as well.
•The structural model in GME could be mapped on to a simulation model in a discrete event simulator such as OMNeT++. This would enable the modeler to simulate analyze the performance of the entire composable system for different configurations.
References:
1.Schmidt D., Stal M., Rohnert H., and Buschmann F., “Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects”, Addison-Wesley, 2000.
- Schmidt, D., “Acceptor-Connector: An Object Creational Pattern for Connecting and InitializingCommunication Services”, In: Pattern Languages of Program Design 3, ed.