SEcS is a project whose purpose is to provide a scalable and dynamic framework for developing remote intermediary applications that provides advanced Edge-computing Services by using a cluster of heterogeneous machines. The architecture proposed allows both service composition and configuration by each single user as well as a deployement setting that ensures high availability and tolerance to faults and load peaks. SEcS is written in Java and is based on IBM's Web Based Intermediares (WBI) developed at IBM Almaden Research Center.
While caching proxies are important elements of the Web architecture and contribute to the scalability and efficiency of the services provided to the end-user, it is now becoming clear that the Edge of the network is an important component that can be used as a platform to deploy additional services that cannot be provided neither client- nor server-side. The recent hype on ``Edge Computing'' emphasizes the role of ``intermediaries''on the information flow as an ideal place to add value to the traditional client-server interaction.
The first characteristic of an Edge-computing Service (EcS) is its dynamic reconfigurability and its interaction with other EcSs. In fact, since an EcS acts on the information flow between the Web server and the browser, it can be cascaded with other services. Therefore, a crucial capability is allowing the service user to (re)configure the EcS that is actually used, by changing some parameters and/or placing it in a pipeline with other EcS.
Full configurability of EcSs imply another important characteristic: the personalization, i.e., personalized services are provided to each user, once he/she is recognized by the system after an initial authentication. This is realized by using the Proxy Authorization HTTP header Proxy-Authorization. In this way each user has the full control and can manage the configuration of EcSs he/she needs.
Finally, given their heterogeneity, the ``natural'' platform for providing EcSs is a cluster of heterogeneous machines that also ensure important requirements such as scalability and high availability.
- A platform for Scalable EcSs:
Scalable Edge-computing Services (SEcS) is based on IBM Web-Based Intermediaries (WBI) by adding support for the execution on a cluster of workstations (by providing a communication infrastructure among remote WBI components and a distributed dispatcher to balance dynamically the load) and a support for personalization and configuration of the services required on a per-user basis.
SEcS allows to build scalable services that enhance the simplicity and the ubiquity of the WWW: additional, complex and advanced services can be placed on the Edge of the network in order to intercept and deal with HTTP information flows. Services built with SEcS lays on top of the three foundational standards of the Web (mainly HTTP) and have minimum impact on the users. SEcS makes possible to envision the ``Edge'' of the network as a real computing platform where services can be assembled and personalized.
SEcS architecture is illustrated by the follow figure where we show the relationships among the three basic components: Dispatcher, Remote Proxy and Distributed Registry.
The architecture consists of several Dispatchers (i.e. the ``local'' proxies that deal directly with the clients' requests) and several Remote Proxies (i.e. proxies whose components (MEGs) can be invoked and used by any Dispatcher).
In a nutshell, the Dispatchers act as ``proxy'' (in the HTTP context) and can either provide the service by themselves or invoke remote MEGs that are placed on the Remote Proxies. Each Dispatcher/Remote Proxy is executed within a separate WBI session as a plugin. The Distributed Registry allows to keep the internal status in terms of addresses (i.e. hosts) of available Services. Load information (to balance the workload) are sent with the responses to the remote invocations to each Dispatcher. It should be emphasized that a Dispatcher and a Remote Proxy can also be run jointly on the same (Java Virtual) machine, in a common WBI session as two separate plugins.
This concise description (shown in the next figure) is meant to smoothly introduce the functionalities of the components that will be later fully described for a complete round-trip of the HTTP request.
Since the browser has been configured to use the Client Autoconfiguration file, when the client issue an HTTP request (1) the script decides (based on the hash function that uses the client hostname (or its IP address)) what Dispatcher is going to be used as HTTP proxy (2). The designated Dispatcher, then, checks if the user is already authenticated and, if not, authenticates him/her by the ordinary challenge-response mechanism http-authentication. Once the user is recognized, the Dispatcher accesses the local users database and then reads the services configuration (3) chosen by the user and begins the execution of the services taking the first one in the list. Consulting its (local) Services table (that is kept updated by Distributed Registry) (4) the Dispatcher can get the list of all the Remote Proxies that implement the first service to be activated. By using its (local) Loads table (that contains the workloads evaluated during the transactions) the Remote Proxy with the smallest load (from the list built at the previous step) is chosen by the Dispatcher that, then, instantiates the Stubfor the remote communication (5). The Stub gets from the rmiregistry (tool provided within the JAVA RMI package and provides remote references to remote objects so that their remote methods can be invoked) the remote reference of the ``entry point'' MEG of remote service (6) so that it can successfully execute the calls of the remote service. When the Remote Proxy has finished the elaboration (7), the control passes again to the Dispatcher that checks if others services are requested in the current configuration of the users and, if that is the case, the steps (4), (5), (6) and (7) are repeated, otherwise the response is returned to the client.
- The Client Autoconfiguration File
CAF, also, is a way to guarantee fault-tolerance of the Edge-computing Services. Infact, if the proxy chosen by the script is no longer available, then the browser automatically chooses the next proxy (designated by the script) and, as last option, it chooses the DIRECT option i.e. direct connection with no use of services at all.
- The Dispatcher
The Dispatcher is the component of the architecture that interacts directly with the browser for the execution of all the HTTP requests.
First of all, when the client issues an HTTP request, the Dispatcher identifies the user (or provides to initiate a challenge-response authentication), and then loads the configuration of the services that the user selected during the configuration.
Once that the client is identified by the Dispatcher, the "personalized" navigation begins: the services selected by the users will be applied to the HTTP flow of requests/responses. The Dispatcher reads from the Services table the services required by the client, and begins executing them. By the Distributed Registry the Dispatcher can choose, among the Remote Proxies that implement the service, the one with minimum load. Then it istantiates the Stub (more details on the structure of the implementation of services are given in the next Subsections) to establish a communication with the MEGs that implement the service. Since each service can consists of several MEGs, the Dispatcher will call the MEGs until the service is completed. Then it can select the next service and keep applying all the services to the flow as requested by the user during the configuration.
In any case, however, the Dispatcher also takes from the transaction data (in WBI, are sent within each request as it flows through the MEGs) the information about the load of the remote machines where the remote MEGs were executed. More details on the monitoring and load balancing information are presented later.
Finally, the Dispatcher is in charge of being the interface toward the users. Each user can, in fact, configure the services as preferred by accessing a particular URL that is intercepted by the Dispatcher. The user can choose the services and configure the parameters (internal to each service) by a personalized homepage.
- The Remote Proxy
Each Remote Proxy is a (plugin of a) WBI session that istantiates (remotely used) MEGs as well as local (i.e. standard) MEGs that can be used locally. A service can consists of a single MEG as well as many of them.
All the remote MEGs (corresponding to the remote services) that are istantiated by the Remote Proxy are registered on an rmiregistry listening on a fixed (read from a configuration file) port. Once istantiated, each remote MEG communicates with the Distributed Registry that they are ready to offer their service i.e. being (remotely) invoked by the Dispatcher.
Remote MEGs in a Remote Proxy are invoked by the Dispatcher via a (remote) call of their method RemotehandleRequest(STUB ref) on the remote reference that is provided by the rmiregistry. Following WBI standards, each remote MEG also offers the method handleRequest(Request e) to be used locally (i.e. from other MEGs in the same Remote Proxy.
- The Distributed Registry
The Distributed Registry represents a central component of SEcS. It is a Java application that may be located on any machine in the network. Its main task is to keep updated the Services table (that is stored on each Dispatcher) of the available services i.e. a list of the MEGs that offer each service and where (i.e. on which machine) they are located. It must be noticed that the Distributed Registry represents the only centralized point in the architecture but it is not subjected to substantial workload since it is contacted by each MEG within a Remote Proxy (at startup) for the registration. Then, the updated version of the Services table is broadcast to each Dispatcher.
Currently under development is the configuration of services (see Subsection Services): the Distributed Registry is being modified so that it also provides to broadcast to all the services of a given kind the changes in configuration parameters that is done by a user.
In order to keep the workload evenly distributed among the machines, it is necessary to provide a (programmable) mechanism to balance the load. It becomes important to measure the load of the machines involved by SEcS since a natural environment for SEcS is a cluster of heterogeneous machines, that can be also used to other purposes and that can be added ``on the fly'' to offer scalability and fault-tolerance. Therefore, we now, first sketch the mechanism and then describe how a load balancing policy can be defined.
The load of each machine involved in providing Edge-computing Services is monitored by a thread. The values are added into each request that passes through the MEGs running on that machine (piggy-backing). In this way, the Dispatcher takes the information from the requests as they are sent back to it.
Since we want to offer the developer a tool to change the way the load is measured and how the best proxy is selected, we provide two classes, Balancer and Policy that perform the balancing of the client requests. The Balancer acts accordingly to a Policy so that it is possible to select (the identifier of) the Remote Proxy with the minimum load among those that can be considered for the request (i.e. that offer the requested service).
In its current version, SEcS support the load monitoring on the Linux operating system. In fact, the load of a machine can easily can be represented by accessing the directory /proc and reading the contained information in the files.
Structure of a Service in SEcS
A Proxy Service is a MEG or a group of MEGs sequentially invoked by the Dispatcher. The sequence is automatically created through the information that each MEG inserts inside the current request. It should be noticed that each MEG can be part of different services and, therefore, it can be invoked in different contexts, i.e., by two (or more) different MEGs. In both cases the invocation happens through the Dispatcher.
At the end of the execution of a remote MEG the control returns to the Dispatcher which can continue the transaction (either by forwarding to the next remote MEG of the service or to the next service) and, at the end, can return the output to the client.
Each service has an ``entry'' MEG, i.e. the first MEG to be invoked, that has the same name as the service.
The configuration of each service is done by accessing a configuration MEG (provided for each service) that allows to change the parameters (on a per user basis) and forward the changes to the Distributed Registry that takes care of broadcasting the configuration changes of the user to all the Remote Proxies that offer Services of the same kind. This last part of the configuration is yet to be implemented and will be accessible by the user via the same configuration page used to select the services.
Communications between local MEGs and Remote MEGs occur through Remote Method Invocation (RMI) and, therefore, a registry is necessary to allow dealing with remote references. The architecture allows a local MEG to:
- invoke a remote MEG passing the input.
- get the output produced by the remote MEG.
- return in possession of the control of the execution
Unlike a totally local WBI transaction, a remote transaction (i.e. one that involves also remote MEGs) is characterized by a sequence of control transfer between local and remote MEGs.
The logical architecture of RemWBI compared to WBI is described in the figures below: in, the standard WBI architecture is described with the request flowing among MEG of different Plugins. In we describe RemWBI architecture that makes the requests flow (possibly) among different machines.
The communication between a local (i.e. the Dispatcher) and a remote MEG (in a Remote Proxy) occur through a Stub on the local machine. The local MEG, first, instantiates the proper Stub that gets the remote reference of the Remote MEG from the rmiregistry.
The Stub is then used by the Remote MEG to exchange data: the Stub establishes a connection with the remote MEG sending its own reference. In this way, the remote MEG can use Stub's methods read() and write() to take the input flow and return the output flow after performing its own computation (possibly with other MEGS). Other methods are also offered by the Stub for accessing the details of the HTTP request and response.
The importance of Edge Computing is growing at least as fast as the amount of resources available on the Web nowadays: placing services on the edge of the network permits to offer ``orthogonal'' services (i.e. general-use services, applied to existing Web resources) such as translation, transcoding and accessibility services, as well as services based on assembling and composing resources on the Web based on the nature of the client and the nature of the accessed resources such as groupware, localization and personalization.
Since the complexity of Edge-computing Services is growing, our proposal aims at establishing a framework to deploy services on a cluster of heterogeneous machines obtaining fault-tolerance and scalability while preserving easy programming and assembling. Moreover, our framework allows an easy, ``on-the-fly'' and per-user configuration of services.
The project is a modification of WBI so that it becomes a framework to build and deploy complex Scalable Edge-computing Services, defines a programming framework that fits naturally into the architecture that is coming out from the most recent activities of OPES Working Group. Therefore, an important future work will be to lead our project into the OPES standard once it becomes an accepted standard. In particular, the next steps of the project will be to implement OPES rulesets and add a OPES Callout Protocol to the communication between Dispatcher and MEGs.
SECS INSTALL - installation instructions
This section explains how to install SECS on Unix. Also included are running and browser configuration instructions.
Download the WBI DK 4.5 (downloaded from http://www.alphaworks.ibm.com/tech/wbidk ).
Decompress the package and install it into an appropriate directory.
Move the SECS package "SECS.tar" in the WBI directory.
Decompress the package from the WBI directory.
Set the CLASSPATH to the classes directory. The default is $HOME/wbij45/it/unisa/dia/ProxyServices.
Under the 'wbij45' directory you cann find the script "Run.sh" to start the WBI session. Be careful about what ports are set for the proxy. WBI typically use port 8088, 8089, 8090 and they are specified in the configuration file "etc/sublayers/ibm/HttpSublayer/home.prop" from the WBI directory. You must edit the file if you want use some one else.
If you want to use the base SECS system you need to run two WBI sessions and a Distributed Registry. The Distributed Registry properties must be written in the configuration file "it/conf/registry.conf" to make they available for the SECS entities.
One of the session must register the dispatcher and the second the remote proxy. Using the GUI is possible to make the registration easly.
It is possible also to run three or four WBI session. In the first case there will be one dispatcher and two remote proxies; in the second case there will be two dispatchers and two remote proxies. Make sure that the session if on the same computer, are started on different ports.
Finally to use this platform you need to edit some configuration file to tell to the proxies which ports to use and which rmiregistry contains object's references. For this reason it is necessary edit for each remotre proxy a configuration file (i.e. Mess0.config, Mess1.config) with information on host and rmiregistry port. For examples:
In this case you must run rmiregistry on port number 5000 on the same computer. The command is 'rmiregistry 5000&'
In any case it is necessary to run the default rmiregistry on the computer where is running the Dispatcher. The command is 'rmiregistry&'
Web browsers need to be configured to use SECS as a HTTP proxy server. Proxy configuration is usually found within network preferences. Set the HTTP proxy host to the name (or IP) of the host SECS is running on and set HTTP proxy port to.
Start the browser and find out how to configure the Proxy servers (use browser's Help menu if necessary).
There are two way to set the Browser on the base of the number of dispatchers are running.
* If there is one dispatcher then:
For Netscape 4.0 and 5.0, proxy server can be set at Edit/Preferences/Advanced/Proxy. For IE 4.0, the proxy server configuration is at View/Option/Proxy.
* if there are more Dispatchers set the autoConfiguration file For Netscape/IE set the field Automatic Proxy Configuration to the url saved in the "config/SuperProxy.config"
After starting SECS, you can access "http://_Register/" to obtain a login and then "http://_Chooser/" to choose a service to apply to the request.