Overview

1. Introduction
2. Network Structure and Communication Protocols
3. Modular Structure
4. Autonomic Computing
5. Problem Solving

1. Introduction

This page gives a more detailed overview of the system, paying particular attention to its modular construction. The licas system is an open source framework for building service-based networks. The framework comes with a server for running the services on, mechanisms for adding the services to the server, mechanisms for linking services with each other, and mechanisms for allowing the services to communicate with each other. The default communication protocol inside of licas itself is an XML-RPC mechanism, but REST-style messages can also be processed and Web Services invocation is also possible. The system is able to automatically decide on the message type and convert it accordingly.

 

The system also provides an implementation of an Autonomic framework, including the 'model-analyze-plan-execute' loop, behaviours and policy scripts. Only the framework is provided however, where you would be expected to write actual implementations of the main monitoring components yourself. Services are protected with passwords, where this can be one password for the whole service, or through a script, you can set passwords for different access levels and methods. Other scripts can be used as contracts or service-level agreements between services. There is also some basic search and metadata processing capabilities, to allow services to be found.

2. Network Structure and Communication Protocols

The system is designed to be peer-to-peer (p2p), where any service can both send (client) and receive (server) messages from any other service. Any remote message that is recieved, firstly passes through the base server, before being directed to the service that it is addressed to. The same communication process can also allow for direct invocation on an Object reference. The architecture is a typical hybrid p2p architecture and is also the sort of thing that the Cloud/SOA/Microservice computing systems might provide. Figure 1 shows the general architecture of what a distributed network would look like.

This diagram shows two servers running two different networks of services. The services can be structured in either network by permanent links, represented by the solid black arrows. Some services may have created dynamic links between each other, represented by the dashed red lines. The dynamic links can cross over networks as well. The server is more of an application server than a web server, where the services provide most of the functionality. Figure 2 shows the different communication protocols.

So internal communication in the licas system is by XML-RPC or direct reference, where service communication is done at the level of invoking a method on another service. A client can use either XML-RPC or RESTful-style messages to invoke a service running on a server, and either a client or a service can call an external Web Service or HTTP URIs dynamically, also through the licas classes.

3. Modular Architecture

The framework can be broken down into several modules, where not all of them might be required for a system. At the lowest level is a Service class. If you extend this with your own class, then you can add your own service to a network with all of the required licas functionality. The Auto class extends the Service class and is slightly more complex, providing for agent-like communications or continuous behaviour running on a separate thread. Note however that this is only a framework and the actual implementation still needs to be done by the programmer. Ontop of this there is the possibility for adding metadata to describe the service. All of the metadata is in XML format. The metadata can also be used to describe different security levels. The methods of a service can then be protected at different access levels, each requiring a different password. Figure 3 shows the modular architecture.

The server modules are shown in green. The HTTP server can manage metadata, linking and communication mechanisms. You do not have to link services, for example, but this is a way to provide some sort of structure. The dynamic linking mechanism is provided as a utility 'Link' service or module, that you add to your own service and then invoke, where there are built-in meshanisms for doing this. If passing complex Java objects, then you need to write a parser for those classes, but the basic types are parsed as default. Alternatively, you can also serialize your objects, or local calls can use direct references.

The Services that are loaded onto the network can be derived from the base licas 'Service' class. Alternatively, the 'Auto' class provides slightly more functionality. You can also load in your own class that is not derived from licas at all. It will be stored in a Wrapper before being loaded onto the network, where the wrapper provides most of the essential functionality.

4. Autonomic Computing

The system also protects any service with by a wrapper object. This makes it difficult to obtain a direct reference without the correct password. This wrapper is a 'ServiceWrapper' by default, or if the service is derived from 'Auto', it is an 'AutonomicManager' wrapper. The default autonomic manager allows the service to operate as normal and also provides a message queue for messages that the service receives. It calculates some server-level stats, such as number of calls, but does not do any monitoring.

The autonomic manager is made up of monitor, analyse, plan and execute modules that can be used to monitor the service in question and take action when there is a fault. Because this sort of activity is very application specific, it cannot be programmed completely and also lies outside of the scope of licas. Therefore, only a framework is in place to allow these modules to be loaded and work together. In the licas system, only the base service has an Autonomic Manager. Any service that is nested inside of any other service is taken to be a utility service to the base service and is not monitored at all.

The autonomic manager does not control the service's actions and would only monitor it based on scripts or policies that are passed in, as part of an admin document. However, when using the Auto-related classes, it is expected that a behaviour loop would be run that would periodically execute some behaviour and that mostly controls the service execution process and subsequent monitoring. Note that a behaviour can be any sort of action or evaluation. If there is an error, then this can be flagged and sent to the server, for example. The framework that is in place should be helpful for this process and so it would be worth looking at the code to see how it works if you are going to implement these modules yourself. Figure 4 shows the basic architecture of the autonomic manager. Note that the licas Service class now also has a contract manager for processing contract proposals for its service. These would be related to the stored metadata.

Figure 4. Autonomic Manager wrapper with stored object.

5. Problem Solving

The system can be used to execute distributed services, which can run ‘behaviours’ that have their own internal control algorithms. These features are also integrated with the problem solving, where a distributed network of autonomous services can send their information to a centralised problem solver, to perform other calculations. The default package provides some new clustering algorithms as well. One test option therefore, is to start a group of distributed services running that would autonomously interact with each other. The other option is to manage the AI in a more centralised component, where the services send their data to a central problem solver, it does the AI and sends the result back to the services. The centralised problem solver allows different base frameworks to be used, such as clustering with different distance metrics, or the centralised genetic or frequency ‘grid’ options. That sort of framework allows for a heuristic search over information that is sent from distributed sources to the centralised component. There is also basic hill-climbing, or even a SOM neural network and each algorithm can be extended or new ones added.

So a unique feature of this system is the fact that a solution to optimising information sources has been integrated with a service-based network, allowing both for services to organise themselves based on mutual communications, or from a more centralised control system. The framework can also be used simply as a general problem solving environment, without considering services or networks; but it would then have a more limited functionality. It is worth looking at the ‘ai_heuristic’ javadocs to see what algorithms are provided as default.

Figure 5 shows the basic architecture of the problem solver. An information mediator can be used to receive the information from the distributed sources. This is then sent to the problem solver which creates solutions of the specified type and clusters the sources, or solves the problem, as best it can. The resulting clusters can then be turned into dynamic links and used to update the network structure, for example. The information mediator can communicate directly with the services running on a network and the results viewed in the GUI.

Figure 5. Problem Solving Architecture for Organising Information Sources.