7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 1/35
LICAS AUTONOMIC USER GUIDE December 5, 2016
1
Licas Autonomic
Methods User
GuideVersion 1.7
[A guide to using the Autonomic Manager with
the licas Java software package]
Kieran Greer,
Email: [email protected].
http://licas.sourceforge.net
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 2/35
Licas Autonomic Methods User Guide V1.7
2
Table of Contents
1 Introduction ....................................................................................................................... 4
2 The Behaviour and Auto Classes ........................................................................................ 5
2.1 The Behaviour Class .................................................................................................... 5
2.2 The Auto Class ............................................................................................................. 5
2.3 The AutoSecure Class .................................................................................................. 6
2.4 Communication Conversations ................................................................................... 6
2.5 Invoking a Behaviour ................................................................................................... 6
2.5.1 Evaluating Data .................................................................................................... 7
3 Autonomic Manager .......................................................................................................... 8
3.1 When Monitoring Takes Place .................................................................................... 9
3.2 Autonomic Manager Actions....................................................................................... 9
3.3 Default Monitoring .................................................................................................... 10
3.3.1 Server Stats ........................................................................................................ 10
3.3.2 Quarantine Messages ........................................................................................ 10
3.4 Auto and Autonomic Manager Control loops ........................................................... 10
3.4.1 Admin Script Autonomic Manager Section ....................................................... 11
3.4.2 Autonomic Manager as a Wrapper .................................................................... 12
4 Autonomous Control Loops ............................................................................................. 14
4.1 Manage the Autonomous Behaviour ........................................................................ 15
4.1.1 Store Received Messages in the Autonomic Manager ...................................... 16
4.2 Monitoring of Messages............................................................................................ 16
4.3 Implementation Status .............................................................................................. 17
4.4 Policy Script ............................................................................................................... 17
5 Autonomic Scripts ............................................................................................................ 19
5.1 Autonomic Manager Scripts ...................................................................................... 19
5.1.1 Autonomic Manager Initialisation ..................................................................... 19
5.1.2 Server Notification Method ............................................................................... 19
5.2 MAPE Scripts ............................................................................................................. 20 5.2.1 MAPE Script Schema .......................................................................................... 21
5.2.2 Licas Script Keywords ......................................................................................... 22
5.2.3 VarMap............................................................................................................... 23
5.3 BPEL-Style Scripts ...................................................................................................... 24
5.3.1 Script Construction ............................................................................................ 25
5.3.2 Licas Language ................................................................................................... 25
5.3.3 BPEL Language ................................................................................................... 27
6 Server Notification ........................................................................................................... 28
7 Service Initialisation Script and the All-in-One GUI ......................................................... 29 8 Service Level Agreements and Contract Negotiation ...................................................... 30
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 3/35
Licas Autonomic Methods User Guide V1.7
3
8.1 Contract Description ................................................................................................. 30
8.2 Contract Manager ..................................................................................................... 30
8.3 Yes and No Contracts ................................................................................................ 31
8.4 Adding and Negotiating with Contracts .................................................................... 32
8.4.1 Adding Contracts ................................................................................................ 32 8.4.2 Retrieving Service Passwords ............................................................................ 33
8.4.3 Service Negotiations .......................................................................................... 33
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 4/35
Licas Autonomic Methods User Guide V1.7
4
1 Introduction
The software package licas (lightweight Internet-based communication for autonomic
services) has been developed to allow a user to build distributed service-based networks
that can also self-organise/self-optimise. Functionality is provided to allow for remote
communication and dynamic linking between services, where the architecture and adaptive
capabilities through dynamic linking, add something that is not available in other similar
systems. Autonomic monitoring of services in a network could be a valuable asset in today’s
internet environment and this document describes the programming details required to use
the autonomic components of the system. There are at least two different features here.
Firstly, there is the MAPE (monitor-analyse-plan-execute) control loop that autonomic
managers can use. This is typically configured by a policy script. Secondly, there is an
autonomic engine that can dynamically execute a process script, to invoke methods onservices and evaluate the results. This script is based on a subset of BPEL (BPEL4WS) with a
few new types, specifically to add variable instances to the script. For example, the script
can replace tagged variables with actual values, dynamically during the execution process.
Note that you can use most of licas without worrying about its autonomic features, as the
core package is only a framework without specific implementations. You can simply write
services in Java code and run them, making use of the distributed framework. Including
autonomous behaviours will require additional programming and so you only need to read
this document if that is specifically what you want to do. The advantage of licas is the factthat if you wish to write autonomic/autonomous services, then the control loops are already
in place, making it easier to add the implementation-specific code. Most other systems do
not offer this sort of framework and so you can create an autonomous system with a
minimal amount of effort.
The rest of the document is organised as follows: Section 2 describes the ‘Auto’ class, which
is the base service class for autonomous services and an Autonomic Manager. This is also
described in the ‘licasUserGuide’. Section 3 describes the default ‘Autonomic Manager’
classes and how to add your own specific functionality. Sections 4 to 7 give further detailson the control loops and feedback. Section 5.1, for example, describes the scripts that you
can use to initialise an Autonomic Manager. Section 8 then describes the scripts that can
represent contracts and be used for negotiations between services.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 5/35
Licas Autonomic Methods User Guide V1.7
5
2 The Behaviour and Auto Classes
Executing a behaviour in a service can now be carried out as part of a loop or as single
events. The control loop requires slightly more functionality and so the two methods can be
split up into a Behaviour class and a derived Auto class, as described next.
2.1 The Behaviour Class
This is strictly the first class to use to create a service, to execute a behaviour in. The class
itself extends DataService, which extends Service. DataService has been included so
that the base methods have access to more scientific structures for processing data. There is
no implementation of the run thread however and so only single invokeBehaviour callswould be expected. This still passes the message object through the standard method set,
but as there is no Autonomic Manager, the messages are not monitored at all.
2.2 The Auto Class
The Auto class is then derived from the Behaviour class. It is intended to be slightly more
autonomous, to allow for more agent-like behaviours. The idea behind an Auto class is that
it can execute its own behaviour, periodically inside of a loop, to allow it to perform more
independent activities. As with an agent-based philosophy, it does not need to wait to be
invoked before deciding to perform some sort of action, although, a passive or reactive
policy can also be used. The action would typically produce some sort of result and this can
be passed through the Autonomic Manager, for example, to check that it is safe. While that
is the theory, in practice, an Autonomic Manager is mostly implementation-dependent and
so only the framework is in place that stores empty methods. This can be enhanced with a
configurable policy script, for example, to give some evaluation rules. Any service that is
loaded is wrapped by a service wrapper for protection. An Auto-derived service is instead
wrapped with an empty Autonomic Manager. Any message that the service is sent through
the Auto-related methods is actually queued and stored in the Autonomic Manager and
then released when the control loop asks for the next message. A service method can also
be invoked directly through some methods, when the service replies would also be passed
through the Autonomic Manager for potential evaluation, but they do not get stored and
retrieved from the message queue.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 6/35
Licas Autonomic Methods User Guide V1.7
6
2.3 The AutoSecure Class
An Auto service is still very open and can be invoked through any of the public methods. The
AutoSecure class is an attempt to make this more secure by allowing method invocation
through a specific interface only, through the default invokeBehaviour, or by startingthe Thread. Some other general methods are also available, including messageReply.
2.4 Communication Conversations
Also in keeping with agent-like systems, the Auto class can store conversations, relating to
communication threads with other services. A communication thread can be tagged with a
communication ID, so that it can be retrieved and replied to when the same ID is
encountered again. The communications however do not follow the strict protocols ofagent-based systems, which will make any conversation more difficult to manage, but
allows for an easier implementation. Simply invoking a method on another service might not
require a strict protocol reply to an earlier request. One idea would be to configure this
further through the scripts or your own service-specific code, and so there is nothing to
prevent standard protocols from being added.
The communication process however would prefer to operate through the Auto class’s
messageReply method. The process is started by invoking ‘any’ method on a service and
include a communication ID in the calling MethodInfo message. The communication process
then saves the client ID with the communication ID automatically. The service can then
check for this if any subsequent messageReply methods are invoked, using the same
communication ID and retrieve related states or content for processing. The default system
ignores these additional entries, so again, only the framework is in place. So the base classes
for this sort of activity are still quite general, but application-specific implementations would
be required.
2.5 Invoking a Behaviour
When a service is added to a server, the server automatically adds an empty Autonomic
Manager to any Auto-derived service, as a wrapper object. If you start an Auto derived
class’s thread and execute behaviours; then if any of the monitoring modules have been
added, they can process the behaviour results. If you just want to use the more advanced
agent-based communications, you do not need to add anything else. The behaviour thread’s
run loop implements the main control loop that links with the empty MAPE slots and so
you can use them if needed, by adding specific functionality to the modules that you mightrequire. Looking at the Auto class should show what methods you need to implement
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 7/35
Licas Autonomic Methods User Guide V1.7
7
yourself to create your own autonomic service. Look at the example LinkService.
behaviourAction method, for example. The other option is to invoke the behaviour
directly through the invokeBehaviour method. In that case, the behaviour runs only
once when invoked and not in a loop. If the main service thread is running however, then
you cannot make an independent invocation, but can only allow the loop to execute.
2.5.1 Evaluating Data
The system is also intended to be used for more scientific applications and provides several
algorithms and metrics for evaluating information. The DataService class in fact stores
this functionality specifically and would be extended to provide it to any other service. To
try to add some configurability, two classes: EvaluateData and DataQuery are used.
EvaluateData evaluates the data in DataQuery. An evaluation is typically either on a data
object or between two data objects. Therefore, a ComparisonQuery object extends the
DataQuery one. The DataQuery object can be passed with values that include the object to
process and the method to invoke on the service that is evaluating it. It can therefore
include a dynamic link to the parent service that uses it. The ComparisonQuery extends this
with a comparison evaluator called ‘mathCompare’, operator type (GT, LT…) if required and
slots for a single dataset to compare with, or a list of parameter objects. The default
comparator for the whole system is ‘SimpleMathCompare.class.getName()’ and so this can
be used if there is nothing new. If you change the comparator, make sure that the
constructor does not require any parameters. These classes are therefore quite flexible in
their use, but provide the objects or slots for further dynamic configuration of the
evaluation processes.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 8/35
Licas Autonomic Methods User Guide V1.7
8
3 Autonomic Manager
The ‘licasArchitecture’ guide also describes the autonomic principles and how they relate to
the licas system, where a more detailed account can be found in [IBM]. Autonomic
computing is an Artificial Intelligence discipline that derived from agent-based systems,
whose ultimate aim is to create ‘self-managing computer systems’ to overcome their rapidly
growing complexity and to enable their further growth. With autonomic computing, the
system tries to realise the ‘self’ components, to allow it to manage itself. These can be
described as follows. As well as this you could add ‘self -aware’, where the system would be
aware of itself and its state:
Self-configuration – Self-configuring components will adapt and configure to their
environment using policies provided by an IT Professional.
Self-optimising – The components in the system must be able to tune themselves to the
users’ needs. Self -optimisation will help to maintain a standard of service to the user.
Self-healing – Self-healing components can detect system malfunctions and initiate
policy-based corrective action without disrupting the running environment.
Self-protection – Self-protecting components will detect attacks on the system and take
corrective measures.
An Autonomic Manager is automatically added to a service if the service extends the Auto
class and is a main or base service, not a utility service. If you do not add your own, thedefault manager is the AutonomicManagerDefault class. To add your own manager,
extend the abstract AutonomicManager base class in your code, and add the classname
to the admin script for the service, in the Autonomic_Manager section (see section
5.2.1). The default methods will try to read the admin script and load in a different manager
if one is specified. For a complete re-write of the service wrapper, you can look at the
createServiceWrapper method in the ESB class, for example.
The base AutonomicManager class is abstract, where the monitor method is the one that
would start the monitoring control loop. There is also a base abstract AM_Module class
that you can extend to implement one of the monitoring modules. Published documents on
autonomic computing describe these modules in more detail, where a summary is as
follows:
The ‘monitor’ part provides the mechanisms with which to collect, aggregate, filter,
manage and report details (metrics and topologies) collected from an element.
The ‘analyse’ part provides the mechanisms with which to correlate and model complex
situations (time-series forecasting and queuing models, for example). These mechanisms
allow the autonomic manager to learn about the IT environment and help predict futuresituations.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 9/35
Licas Autonomic Methods User Guide V1.7
9
The ‘plan’ part provides the mechanisms with which to structure the action needed to
achieve certain goals and objectives. The planning mechanism uses policy information to
guide its work.
The ‘execute’ part provides the mechanisms that control the execution of a plan, with
considerations for on-the-fly updates.
In the licas system, only the base service that is loaded directly onto the server has an
Autonomic Manager. Any service that is nested inside of another service is taken to be a
utility service and should be managed by the base service only. You must also derive your
class from the licas Auto class for it to be assigned an autonomic manager. The alternative
is a wrapper that has no functionality. The default autonomic manager only implements a
message queuing system that is only used for the conversations. The message system allows
messages, of type MessageInfo, to be retrieved by the service, either in the order that
they were submitted (FIFO is the default), or based on the communication ID or time stamp.
The messages also have variables slots for recording the state of the service transaction or
the service component itself. These can again be used as part of a specific implementation.
The monitoring modules are also not implemented, although the control loop framework is
in place. You therefore have the option to write your own monitoring modules and add
them to the autonomic manager, through the admin script and the addManagerModule
method. These monitoring modules would be passed the message objects that the service
receives (see the evaluateBehaviour method), where any implemented monitoring
module can then process message information.
3.1 When Monitoring Takes Place
You cannot use the autonomic manager to evaluate every method call on your service and it
occurs only when the message is added to the message queue, at two specific points:
Currently, when a message is received through the Auto class’s messageReply method,
it is added to the message queue and also passed through the monitor loop. This would be
an input message. Any result message from the evaluateBehaviour orinvokeBehaviour methods are also monitored, which it is the result of the service
behaviour itself, or an output message.
3.2 Autonomic Manager Actions
As well as the MAPE control loop the autonomic manager starts its own internal thread and
periodically checks if the parent service is idle or not. If the parent service does not run its
behaviour loop, then the messageReply method can build up a list of messages in the
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 10/35
Licas Autonomic Methods User Guide V1.7
10
queue that will not be processed. The autonomic manager periodically checks for this and if
the parent service is idle, asks it to process the next message in the queue. This request can
be made even if the parent service is not running its thread and is the same as an external
behaviour invocation call. In future, this type of action request could be added to, to make
the autonomic manager much more useful.
3.3 Default Monitoring
While there is no MAPE control loop implementation by the autonomic manager, it does
perform some basic monitoring of the messages that it receives. This is to generate some
general information that can be retrieved from the manager, but otherwise no action is
typically taken with it. So intelligent processing of the information is not included.
3.3.1 Server Stats
The autonomic manager it is able to calculate some very basic stats, similar to what the
server might store, but for the parent service only. The stats record the number of
messages, the overall size of those messages and if empty messages are received. This
information is available to the server through the ESB.autoManMetrics method.
3.3.2
Quarantine Messages
This is an important feature when using the messageReply method. As indicated by the
name, this method should be invoked in reply to some earlier request. The earlier request
must start a conversation and must include a communication ID to uniquely identify the
conversation. That communication ID is then saved and used to verify any future messages.
If messageReply is called without an earlier request, then if the communication ID in the
message is not recognised, the message is placed into quarantine instead of onto the
message queue. At the moment, the quarantine queue can be retrieved in full, but no other
action is taken.
3.4 Auto and Autonomic Manager Control loops
This section describes the relationship between the Auto class and the autonomic manager
in slightly more detail. The framework will link all of the default functionality for you.
Through the script, you can change the default autonomic manager class, or add your
implementation for a monitoring module (monitor-analyze-plan-execute). This section
describes what the main processing loops are and how they relate to each other.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 11/35
Licas Autonomic Methods User Guide V1.7
11
3.4.1 Admin Script Autonomic Manager Section
You can create a new autonomic manager by extending the base abstract
AutonomicManager class. You can add different classes dynamically, through the admin
document that is used to initialise a service. The ‘licasAdminGuide’ document describes the
XML-based description in detail, where there is a dedicated autonomic manager section
(3.5) that looks like the following. To load an autonomic manager or related module,
essentially you need to specify the type of class to load (1). If it is to be loaded from an
external jar file, then you also need to specify the jar file path (2):
<Autonomic_Manager><Class_Name>org.package.Your_AutoMan (1) </Class_Name><Jar_File>C:/abc/d/am.jar (2) </Jar_File><Monitor>
<Policy><Description here></Description here></Policy>
<Class_Name>org.package.Your_AM_Monitor</Class_Name><Jar_File>C:/abc/d/am.jar</Jar_File>
</Monitor><Analyze>
<Policy><Description here></Description here></Policy><Class_Name>org.package.Your_AM_Analyze</Class_Name><Jar_File>C:/abc/d/am.jar</Jar_File>
</Analyze><Plan>
<Policy><Description here></Description here></Policy><Class_Name>org.package.Your_AM_Plan</Class_Name><Jar_File>C:/abc/d/am.jar</Jar_File>
</Plan>
<Execute><Policy><Description here></Description here></Policy><Class_Name>org.package.Your_AM_Execute</Class_Name><Jar_File>C:/abc/d/am.jar</Jar_File>
</Execute></Autonomic_Manager>
Note that the script does not include constructor parameters and so the LoadObject
object should be able to create an instance with an empty constructor. In the above script,
the first set of values is for the autonomic manager itself. Each module is then contained
inside the related section – ‘Analyze’ for the analyser, for example. A policy document
description can also be added to any module, which should be in XML. Any of these modules
can be specified or can be missing. If they are missing, then they do not get created and the
message object is simply passed to the next module instead; or passed through the loop
without any processing if no modules are present. Each monitoring module should extend
the base AM_Module class however, so that it includes the correct interface for the licas
framework to use.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 12/35
Licas Autonomic Methods User Guide V1.7
12
3.4.2 Autonomic Manager as a Wrapper
This <Autonomic_Manager> XML script section is parsed along with the rest of the admin
document and stored as an XML fragment in the service’s AdminInfo object. When you
load the service onto the network (and initialise it with the document), it is stored inside a
wrapper object. This can be a basic wrapper with no additional functionality, or an extended
version that is the DefaultAutonomicManager wrapper. The addService method
that loads the service being created, contains the following code fragment:
aWrapper = createServiceWrapper(theService, serviceName, serviceType, jarFile,((Service)theService).getAutonomicManagerConfig(((Service)theService).passwordHandler.getAdminKey()));
The service constructor reads the admin script and parses any available entries. The above
method call creates the wrapper and is passed the autonomic manager config part. So when
the wrapper is created, if there is an autonomic manager config part that declares a
different class type (1), it is retrieved through the getAutonomicManagerConfig
method call. The createServiceWrapper method then creates the wrapper by
automatically loading whatever object is defined. Only the ESB server allows an autonomic
manager to be added, where utility services have the standard wrapper. It therefore uses a
different createServiceWrapper method as follows:
if (theService instanceof Auto){
if (adminXml != null){
nextElem = adminXml.getChild(Const.CLASSNAME);if (nextElem != null) className = nextElem.getText();nextElem = adminXml.getChild(Const.JARFILEXML);if (nextElem != null)amJarFiles.addElement(nextElem.getText());
if (className != null){
params = new Vector();params.addElement(theService);aWrapper = (Service)loadObject(amJarFiles, className, params);
}
else{aWrapper = new AutonomicManagerDefault(theService);
}
//parse the rest of the admin document to load in the modulesautoManParser = new AutonomicManagerParser();autoManParser.parse((AutonomicManager)aWrapper, adminXml);
}else{
aWrapper = new AutonomicManagerDefault(theService);}
}else{
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 13/35
Licas Autonomic Methods User Guide V1.7
13
aWrapper = new ServiceWrapper(theService);}
//finalise the configuration
After determining that the service being loaded is derived from Auto; if there is an admin
document, the class type and alternative jar file for the autonomic manager itself can be
retrieved, where getAutonomicManagerConfig in ‘Service’ retrieves the appropriate
‘admin Xml’ section. If these are present, then a new autonomic manager can be loaded
from a jar file, for example. The same process is then carried out for each monitoring
module, using an AutonomicManagerParser to parse the script. When the classes are
loaded, it really is possible to pass behaviour messages through each module and realise a
control loop.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 14/35
Licas Autonomic Methods User Guide V1.7
14
4 Autonomous Control Loops
This section describes in some more detail the sequence of methods that are used to
initialise and run the autonomous control loop. There is a Thread loop for the Auto service
behaviour methods and a different one inside the Autonomic Manager for monitoring the
messages. A default implementation of the Auto control loop originates in its run method
and is started by running its Thread. This starts the loop that periodically executes the
evaluateBehaviour method. This in turn executes other methods and so by changing
the code for any of these, you can change how the service works. If there is some sort of
exception, the service will try to stop the thread and shut-down the behaviour loop, where
once a thread is terminated, it cannot be started again. The default ‘run’ method therefore
performs the following:
public void run(){
try{
while (!shutDown){
try{
//retrieve and save the server password//if not already stored
try
{if (!shutDown) evaluateBehaviour();
}catch (Exception){
ExceptionHandler.handleException(…); shutDown = true;
}finally{
if (!shutDown) shutdown = (timer <= 0);Monitor.getMonitor().release();ThreadHandler.notifyEvents();
Thread.sleep(timer);}}catch (Exceptions) {}
if (!shutDown){
try {shutDown = HttpServer.getServerShutDown();
} catch (Exception ex) {shutDown = true;
}}
}}
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 15/35
Licas Autonomic Methods User Guide V1.7
15
There is a variable shutDown that can be set to true to stop the thread executing,
gracefully. There is also a Thread.sleep() call to prevent this service from executing
continuously, where a default setting of 100 milliseconds between each execution has been
added. You can change this in any of your own services however, by setting the timer
variable. The Monitor and ThreadHandler calls then wake-up any sleeping service,allowing one of them to run. Note the new line of code that automatically sets shutDown
to ‘true’ if the timer is less than or equal to 0. So the thread would be expected to pause and
sleep, but if only one iteration is required, the timer value can be set to 0. The behaviour
itself is executed by the evaluateBehaviour method call, as described next.
4.1 Manage the Autonomous Behaviour
The evaluateBehaviour method retrieves the next message that is on the autonomic
manager’s message queue. It passes this to the behaviourAction method to ask the
service to carry out the next evaluation. The LinkService service is the first full
implementation of the Auto class, while a DataService can process data without
autonomous behaviours. For the linking service, the AutoEngine has actually been used
to run the internal algorithm, where the engine script is read and executed, to process the
evaluation result and create each sets of links. The service therefore works off an auto
script. That can be retrieved by calling createPolicyScript .
If the behaviour action returns a reply, the global serviceState can be updated to
reflect this, or that value is typically ignored. The message result is also passed through the
autonomic manager loop, but the default implementation does nothing. As an example of
some code, the default evaluateBehaviour() method (no parameters) contains the
following implementation:
if (autoManager != null)
{
nextMessage = autoManager.getNextMessage(passwordHandler.getAdminKey());
messageReply = evaluateBehaviour(nextMessage);
//monitor reply
if (messageReply != null)
{
serviceState = messageReply.getServiceState();
autoManager.autoMonitor(messageReply, passwordHandler.getAdminKey());
}
}
else
{
evaluateBehaviour(null);}
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 16/35
Licas Autonomic Methods User Guide V1.7
16
There are some other default features not mentioned here, so it might be worth checking
what they are before implementing something more complex.
4.1.1
Store Received Messages in the Autonomic Manager
When one service passes a message to another one, through the messageReply method,
if it has an autonomic manager, the default implementation will automatically pass the
manager the message to store in its message queue. This will not invoke any other action,
but the service can then ask the manager for the next message in the queue to process. This
would also give an implemented autonomic manager full access to all of the messages that
have been received. The default implementation includes the following code:
if (autoManager != null){commID = this.lastAddedCommunicationID;messageState = getMessageState(commID, message);
autoManager.addMessage(commID, messageState, serviceState, message,passwordHandler.getAdminKey());
}
The last added communication ID is retrieved to identify the message thread. The
getMessageState method can be used to update the state associated with the current
message and communication thread. This is the ‘message’ state and not the ‘service’ state,
but again, this can be ignored and the command is included simply to complete the
framework. If using states, then all of the related actions need to be implemented in your
own derived code. The idea of storing two states is that one would be for the current
communication protocol with some service, while the other is for the service itself, over any
communication protocol. The message, with any or all fields filled in, is then added to the
message queue inside of the autonomic manager. This queue acts as a buffer, where each
message can then be retrieved in order, at a later date, for processing.
4.2 Monitoring of Messages
The autonomic manager does not control the loaded service, but only monitors it based on
policies that can be passed in as an admin document. The service itself also invokes each
monitoring operation, after it performs some action, by returning the result of a behaviour
execution to the manager. The manager then passes this to any of the monitoring modules
that might be present and would expect the module to take the appropriate actions if there
is a problem. So the service determines when the monitoring takes place, but the manager
then processes the information and takes the appropriate actions. It is not possible toimplement this sort of thing generically, but the framework that is in place should be helpful
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 17/35
Licas Autonomic Methods User Guide V1.7
17
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. The number of abstract classes has been
reduced to just 1, so it should be easier to implement your own Auto-derived class now.
Classes to look at include AutonomicManager , Auto, ContractManager andServiceLevel and should be extended where required.
The behaviourAction method must be implemented and getMessageState is
optional. They are the main ones that need implementing for your own specific
functionality. See the LinkService for an example.
The other default methods should work as is, or they can be updated for certain
application specific requirements as well.
4.3 Implementation Status
If tracing through the process, the following classes or methods have been implemented or
are abstract. You only need to implement the abstract ones:
Default Implementations:
Auto.run() - calls evaluateBehaviour
Auto.evaluateBehaviour(…) - calls behaviourAction (implement this).
Auto.messageReply - calls getMessageState, autoManager.addMessage
AutonomicManager.autoMonitor - calls each monitor_module.process method, if any are
included
AutonomicManager.addMessage
Abstract:
Auto.behaviourAction
Also:
Auto.sendInfoXML – is used for sending info to a central mediator. AM_Module - abstract base class for an autonomic monitoring module.
AM_Metrics - for some basic stats that are automatically saved.
AutoEngine – run an auto script and can be independent of the autonomic manager.
4.4 Policy Script
Even after you have added your own specific code to a service and loaded it onto the
network, you can still change the service behaviour dynamically, by changing the policyscript. You might, for example, change a Java class that is used to evaluate something, or the
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 18/35
Licas Autonomic Methods User Guide V1.7
18
monitor class that checks for something, or the order in which methods are invoked. If the
default interfaces are used, the framework itself will work with any derived classes and
invoke the appropriate methods as required, although loading a new script would still be
implementation dependent.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 19/35
Licas Autonomic Methods User Guide V1.7
19
5 Autonomic Scripts
The autonomic manager and the autonomic system in general can be controlled through
external scripts. They are used both to configure the manager and also to change the service
behaviour by executing in an auto engine. The advantage of using a script to change
behaviour is that you do not need to re-write any code and so a different script can be
uploaded during runtime, to change some aspect of the current behaviour. The
autonomic manager’s MAPE control loop requires one type of script to configure it and
another to define the policy of each MAPE module. The AutoEngine can then read a
different type of script that is more like a programming language, which dynamically defines
a set of instructions to execute. These are both described in this section.
5.1 Autonomic Manager Scripts
As well as defining the autonomic manager classes (section 3.4.1), the autonomic manager
components can be configured with XML-based scripts that describe what they will accept
as contracts or policies. This is limited or mostly missing in the default implementation, but
it can be changed by adding a script with real content. While the main focus of the system is
on generic solutions over specific functionality, there is still much that you can do with the
functionality that is provided.
5.1.1 Autonomic Manager Initialisation
As described previously, the class that gets loaded as the autonomic manager can be
changed in the admin script for the service. If the script does not indicate any classes, then
the default AutonomicManagerDefault is used. In addition to this, it is possible to
load utility services onto the autonomic manager, possibly as the sensors or effectors that it
uses to communicate with its environment. These can then be invoked to perform some
action, depending on some condition. See Appendix A for some example code and the
conditions that can be created.
5.1.2 Server Notification Method
If an autonomic manager finds a fault with the service it is monitoring, it can notify the
server about this through the following XML-based script part. This is a very basic
description which includes a command that the server can then execute. The actions are the
most basic at the moment – to shut down, block or unblock the service only, but they can
probably be executed in an autonomic manner.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 20/35
Licas Autonomic Methods User Guide V1.7
20
<Autonomic_Manager_Fault>
<UUID>service uuid</UUID>
<Type>fault type</Type>
<Description>fault description</Description>
<Action>Block, Unblock, Shutdown, ...</Action>
</Autonomic_Manager_Fault>
The script needs to be in the format specified above, for the default server to understand it.
The <UUID> element specifies the service that is faulty and the <Action> element
specifies a command that the server can try to execute. Default actions are currently:
Block: this specifies to block access to a service. It is placed on a blocked list when it
cannot be called or invoked through the calling mechanism.
Unblock: this specifies to unblock the service again. It is then removed from theblocked list.
Shutdown: this specifies to shut the service down. Its thread is stopped from running
and it is removed from the server completely.
5.2 MAPE Scripts
MAPE stands for monitor-analyse-plan-execute, which are the four standard autonomic
modules. The admin script can define what classes to load for these, but it can also definewhat the module should evaluate and what it should do in case of an error. The activity
could, for example, include loading a utility service onto the managed element (service) and
invoking some action through it. Think of the sensors and effectors of the standard
autonomic model [IBM]. As the autonomic manager could be a third-party module that is
simply controlled by the service administrator, there are probably still some privacy rules
that should not be broken. But the whole science is not fully worked out yet and so this is
just part of working with this type of system. You can use your own implementation-specific
rules when writing your system.
The autonomic manager has direct access to the service that it manages and can invoke
methods on it. It might be best to keep the autonomic manager for monitoring performance
and safety, but it does have a control loop that can be utilised for any type of behaviour and
so it depends on what policy script is loaded, as to how exactly it is used. So the script might
include the class type of the module itself, class types for additional utility services, some
sort of query or process to evaluate and some sort of action to carry out upon a matching
result. The example of section 5.2.1 is what is implemented as default, which is essentially
the framework to allow the information to flow from one component to the next and some
stats calculations.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 21/35
Licas Autonomic Methods User Guide V1.7
21
5.2.1 MAPE Script Schema
The following schema can be used to initialise the service, by loading in a particular
autonomic manager and related modules and then configuring the conditions under which
it will try to perform some action. See the ‘automanInitialise.xml’ script in the
docs/xmlSchemas folder. This is a whole admin script for configuring an Autonomic
Manager and also an email service to send notifications. The script allows you to initialise
your main service with some utility services, through the Services_to_Load section.
The Autonomic_Manager section is then as described in the ‘licasAdmin’ guide, where a
process might invoke a utility service of the managed element, as in a sensor or effector, for
example.
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Admin">
<xs:complexType>
<xs:all>
<xs:element name="Services">
<xs:complexType>
<xs:all>
<xs:element name="Services_To_Load" type="xs:ENTITY"/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="Autonomic_Manager">
<xs:element name="Class_Name" type="xs:ENTITY"/>
<xs:element name="Jar_File" type="xs:ENTITY"/>
<xs:element name="Module Name">
<xs:element name="Policy" type="xs:ENTITY"><xs:element name="Process">
<xs:complexType>
</xs:complexType>
</xs:element>
<xs:element>
<xs:element name="Class_Name" type="xs:ENTITY"/>
<xs:element name="Jar_File" type="xs:ENTITY"/>
</xs:element>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
</xs:schema>
You can also declare each autonomic module, defined by the module name, when a policy
script can include a Process section, to describe what the module should monitor and
also how it should react to the result. A licas ‘process’ is very close to a BPEL process and is
essentially a subset of that functionality. It is also what the AutoEngine reads and executes,
which is described in the next section. There is a Script_Factory class to help with
creating each type of element and a Script_Engine class to help to traverse the script,
to retrieve the next element in order. These are what AutoEngine and
AutoEngineInfo use. AutoEngineInfo is, if you like, the conversion from the BPEL-style
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 22/35
Licas Autonomic Methods User Guide V1.7
22
script to the licas-style description, as a Java object. The AutoEngine itself needs to know
what object is going to evaluate the problem, what method it is going to use, a
condition that the evaluation should match, an input variable and an output variable
slot. If the reply is true, then it also stores the events list, of methods (effectorList)
that should be subsequently invoked.
5.2.2 Licas Script Keywords
Some keywords are used by the licas system to recognise some standard objects, as follows.
These should not be used to define any other types of variable:
The keyword AiConst.This is used to ask the variable name to be replaced by the
executing service object itself.
The keyword AiConst.EFFECTOR is used to indicate the reply list of effector
methods.
The keyword Const.REPLY is used to indicate the output or reply itself.
The keyword AiConst.QUERYMEDIATOR refers to a query mediator object, where
the text package is used as the default one.
The keyword AiConst.QUERYMODEL refers to a query model object, where the text
package is used as the default one.
The keyword AiConst.QUERYREPLY refers to a query reply, where the text package
expects an XML element.
The keyword AiConst.METHOD refers to a method object, where a descriptionproduced by Java Reflection is the expected default.
The keyword AiConst.MESSAGEOBJECT refers to a ‘MessageInfo’ object, whatever
that might be.
The keyword Const.SERVICEPASSWORD refers to a licas service password, for accessing
through the calling mechanism.
There are three source types (two are new), defined as follows:
The keyword Const.OBJECT refers to a local Java object of any type that can be created
and instantiated dynamically. An object would also have a unique id and then theelement value is the full classname for creating an instance. Note that the constructor
should not require a list of parameters.
The keyword Const.LICASSERVICE refers to a licas-specific service reference. A
service can be a utility one to the parent, where only the ‘service name’ is required, or a
full ‘XML path’ description for a remote one. If using a service name, then the default
system will check if it is the base service or a utility service of that. It does not look any
deeper.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 23/35
Licas Autonomic Methods User Guide V1.7
23
The keyword Const.SERVICE refers to a web service reference. The value is then the
path to the related WSDL document. It can be local or remote, but must be able to form
a valid URI.
As well as this, the licas script includes some new BPEL sections, to describe its ‘local’ interactions with objects.
The sources section is used to define both remote and local objects. BPEL already uses
links to remote web service interfaces. In addition to this, the licas script allows types for
local objects, or licas-specific services that are then invoked through the calling
mechanism.
There is a variable_instances section to describe actual instances of parameters
that should be created to replace the key name in the method description.
There is a new reflection section that contains method descriptions created using
Java Reflection. Each method should be assigned a unique id so that it can be
referenced in other sections. The type element is probably default here, as all method
descriptions would probably be stored in XML.
The events section replaces the activity one. This is just a personal preference and
some other part might prefer event-rule-action types of instruction, as that is more of an
AI style. Inside the events section however, the BPEL list of elements are used.
Note: The AutonomicManagerDefault.monitor method adds a number of default
key-value pairs, related in particular to calling a licas service through the calling mechanism.
You might want to look at this if you intend to add the same functionality.
Warning: As the autonomic manager monitors both the messages received
(messageReply) and also the message results (evaluateBehaviour or
invokeBehaviour), it will act on either of these in the same way and so it is important
to make clear in the script what result is required before a particular type of action is carried
out.
5.2.3
VarMap
There is also a new variable instance type, which could be helpful with the web services
invocation. This gets read from the WSDL file from the script and so there is no structure in
the script to store values in. There is a Script_VarMap object in the script package that is
essentially a Hashmap of key-value pairs. It can be created calling something like:
varMap = (Script_VarMap)Script_Factory.createNewElement(Script_Const.VARMAP, "vm1",
null);
varMap.addValue("nCelcius", "100.0");
...scriptModel.addVariableInstance(varMap);
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 24/35
Licas Autonomic Methods User Guide V1.7
24
Where vm1 is then the instance name for any reference to it. You can then reference the id
as an Input variable for a web service invocation. The web service structure is created
from the wsdl document, but a check is made if the Input attribute has a value. If it is a
varmap, then an attempt is made to map the value to the createdWebServiceMethodInfo parameter list. This should be done automatically by the
AutoEngine, so you just need to write the script properly. It could even be a Sequence
statement with a single Invoke statement, referencing the web service. When adding, use
the variable name itself and not one of the other section (message, for example) names.
The VarMap values are static and so they are added only under certain conditions. If the
parameter to be updated already has a value, then that it not changed. They are also not
added to the general objects list of it already contains an entry, so resetting things before
each call might be important. So if a value is also set dynamically, it should have precedence
over one of these default values.
5.3 BPEL-Style Scripts
The AutoEngine is used to read and execute BPEL-style scripts. It is an integral part of the
autonomic manager, but it can also be used independently of that, to execute the script for
any particular purpose. An AutoEngine script can be loaded with rules, conditions and
objects to invoke. The instruction set is now based on the BPEL Business Process language.
For one thing, a service-based system would be related to business processes and the WSDL
or BPEL-style of tagging method or variable definitions, so that they can then be indexed any
number of times, helps with refactoring the script code and keeping it consistent. The licas
system uses a slightly modified subset of the BPEL language, as described here. It is however
so close to BPEL that it would be relatively easy to convert the script to an exact BPEL
match.
To show that it works, the AutoEngine, with a related script, is used as part of theLinkService autoEvent method. It evaluates the current best value against the new
value and updates the set of links based on this. This means that part of any service or
autonomous process can be programmed externally through a script. The
‘LinkService.createPolicyScript’ method is used to create the default functionality. This
returns a full admin script for the linking service, with only a single policy and process
contained inside of it. It is not part of the autonomic manager section and so is read
separately from that. You can run this method to return the XML-based description. While
the language is still quite basic, it has some control processes and a dynamic replacement of
tags with values in real-time, so some skill would be required in writing one, to make sure
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 25/35
Licas Autonomic Methods User Guide V1.7
25
that what is coded is assigned the correct key tag names. The service itself can match its
own variables to those in the script and thereby replace a tag or slot with an actual value.
5.3.1 Script Construction
Each element of the script is now modelled as a Java object. To create the script, you
therefore create the object instances in your code and assign them the correct value sets.
These can also be nested. You then use the parser to convert this into an XML-based
description. The XML script can then be read back into the Java objects. Most of the tasks
are included in the LinkService.createPolicyScript method. You would
probably start with the Script_Process object and then add to that. The script objects
have toXml methods, where the Script_Process one will convert the whole script back into
XML. You can use Script_Factory.elementFromScript to convert the XML back
into Java objects again. Each object is modelled as an extended element.
5.3.2 Licas Language
The language is quite limited, where the event process can only be based around a Switch
statement at the moment. But this is like an if-then-else decision maker and there are also
loops to allow the process to repeat. The licas functionality then extends BPEL, by
dynamically creating local objects and also method reflection. BPEL is more strongly focused
on remote invocation of web services and so the licas version needs to include some new
sections as its communication mechanism is also likely to invoke local objects. You can
declare local objects in the Sources section, as well as remote links. There is also a
completely new reflection section to store method descriptions based on Reflection,
again because that is how the communication mechanism works in licas. If any of the
parameter names are tagged, they can then be replaced by actual object instances during
execution, so you need to make sure that these key names are consistent.
Then, the BPEL-style language can allow for following element list, even if not all of the
attributes are available:
Sources, Variables, Variable_Instances, Switch, Case, Otherwise,
While, Sequence, Invoke, Target, Link, Delay, Recieve.
5.3.2.1 SOURCES
Each evaluation is carried out using a particular source and method. The sources can be
either Web Services, as in a BPEL script, licas services or local objects. Objects are assumed
to have direct references and can be of any type, including a licas service. In that case, the
this keyword relates to the service that is using the AutoEngine, or a value that is a
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 26/35
Licas Autonomic Methods User Guide V1.7
26
classname will create the class object through an empty constructor. Note that a source can
also have a username and password associated with it.
5.3.2.2
VARIABLES AND VARIABLE INSTANCES
The variables section allows a name or ID to be attached to a particular type. Each time thatid is used, the correct type can be retrieved. If it is a complex object, it can be created
through an empty constructor. A variable can also be used through a specific instance with a
specific value set. This is stored in the variable instances section and might include the
objects that can be parsed to or from XML, for example.
5.3.2.3
INVOCATIONS
These invoke methods on the sources. A source here would typically be defined by a Link,
typically a remote Web Service in BPEL, but it can be any of the other source types in the
licas script as well.
5.3.2.4 REFLECTION
This new section is required to define the local method descriptions. Reflection is then used
to realise the method object that gets invoked. You can replace parameter names with
keywords that can be updated with actual values, and so on. Or values can be declared in
the script itself, in the variable instances section. So the ID or name of each
element is very important and is always checked, to see if it relates to a real object and must
be replaced. Also, the reserved or keywords are checked again and should not be used for
any other type of variable.
5.3.2.5
CONDITIONAL ELEMENTS
The actual process set of instructions should start with a Sequence element that has any
number of events that are evaluated with the conditions. You can perform some lightweight
programming here, using the Switch or While elements.
A Switch statement adds sub elements of type Case or Otherwise. Each Case
statement has a boolean condition set with it, so that you can evaluate something and
return ‘true’ or ‘false’ as the result. A ‘null’ reply evaluates to false as well. If true, the
sub-elements of that statement are retrieved and executed, as the effector list. If false,
the next Case statement is evaluated, and so on. An Otherwise statement is a default
case. If used, it should be added at the end and will always be executed. It therefore sets
its condition to a default ‘true’ value that you cannot change through the code. So a
Switch statement is similar to an ‘If-Then-Else’ type of statement, as each condition can
be evaluated in turn.
A While loop allows the script to repeat a certain section, again based on a boolean
true-false evaluation of some condition. So there is some flexibility with what you can
program.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 27/35
Licas Autonomic Methods User Guide V1.7
27
5.3.2.6 AUTO-RELATED EXECUTABLES
The BPEL4WS language includes a Receive-Reply set of commands that are similar to an
agent-based Request-Response set of commands. The licas language includes a Receive
script element type, but it is maybe used slightly differently. The command is still to wait for
a message of a particular type, but it asks the autonomic manager if there is a message ofthat type in the message queue. If there is, the first one is returned and removed from the
queue. It is then executed as is, without any effectors or reply part. So an
invokeBehaviour is executed using the retrieved message, where the result of that is
what would have happened from a direct method call. If no messages are present, the script
will terminate, unless the command is put into a loop, for example. This element still needs
testing.
5.3.2.7 SELF-CONTAINED EXECUTABLES
This is another new category that might be useful. So far, a Wait element has been added.
The name used is so as to be similar to the BPEL4WS syntax. It extends an Execute-type of
element that is supposed to be self-contained and is invoked as is, through its’ execute
method. It always evaluates to true and so is automatically executed as well. The delay
element was added to help with long-running processes that might execute too often. So as
part of the script sequence, you can actually slow it down by adding a delay element, with a
time, specified in milliseconds. The script will then execute and go to sleep for the specified
time period, giving your computer a rest as well.
5.3.3 BPEL Language
While the intention is to provide a BPEL-style of language, it will probably only be developed
as it is used and so possibly not all of the BPEL attribute or element types will be present.
The structure is exactly as in BPEL however, even if it is limited. The process elements are
Events rather than Activity elements, but apart from that, are the same. The BPEL-
style script package is not open source, but if you go through all of the fields in each class
that is provided, it will tell you what attributes and variables are available. You will also need
some knowledge of BPEL itself.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 28/35
Licas Autonomic Methods User Guide V1.7
28
6 Server Notification
If an autonomic manager finds a fault, it may need to notify the server about it, if some sort
of action is required. A method called notifyOfFault has been added to the server, to
mark where this call can occur. This method can receive an XML-based description of the
fault in a standard format. It can then shut down the service completely or simply block
access to it, depending on what the script states. The format of the script is described in the
‘licasAdminGuide’ document. Because this functionality has been made part of the system,
the script needs to be standardised in this way for the system to be able to read it. It is likely
that this default implementation would need to be updated.
A blocked service is not allowed to be accessed. It is placed on a ‘blocked list’ and method
calls through the calling mechanism are not then allowed. There are methods on the server(ESB) to blockService and also to unblockService. So a blocked service can also
be unblocked at a later time, either through the autonomic manager or through a remote
call with the admin key. If a service is shut down, it is stopped from running and removed
completely. In that case, a new instance of the service needs to be loaded and started
before it can be used again.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 29/35
Licas Autonomic Methods User Guide V1.7
29
7 Service Initialisation Script and the All-in-One GUI
As described, it is now possible to initialise services with different script specifications. As
well as the auto-related scripts, there are scripts to describe a problem-solving specification,
which includes types of behaviour class. These will load different types of class or evaluator
onto the network and start them running. This means that different behaviours, or AI
activities, can be run, where the All-in-One GUI provides a kind of plug-in specification to do
this for you automatically. The AI classes are extensions of a base DataService class and
they try to make use of the autonomous or agent-like features of its parent Auto class. The
Auto class has the control loops as part of the framework and so if a different behaviour
class is specified, it can simply be loaded into the framework structure and run. There are
two scientific panels that allow you to manually configure an AI test and start it through the
GUI, where the ‘licasGui’ guide gives more details. The default classes are a LinkService and an InformationService. Some other classes now reside in an additional ‘Services’
package, which contains some of the default application services that are available and
proves that this functionality can be loaded in dynamically. For more details on how to write
or run an application service, see the ‘licasService’.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 30/35
Licas Autonomic Methods User Guide V1.7
30
8 Service Level Agreements and Contract Negotiation
The framework can also accommodate negotiations between services based on service
level agreements. These are yet another part of the script specification, where the
‘licasAdminGuide’ guide describes the related XML contracts further. Service Level
Agreements are essentially used to describe the terms or conditions under which a service
will be performed, in the form of a contract. The request for a piece of work by a service is
also presented in the form of a contract. This is another AI process that requires some level
of reasoning. The most basic and default option is for the contracts to simply match each
other. If there is a reasoning process, then if the service and client do not agree, the service
might not return its password and therefore, could be invoked. There can however be a
negotiation phase, where different contract versions can be sent and returned, until a
version is finally agreed upon. The negotiation phase requires service-specific intelligencehowever and so is not part of the licas framework. Therefore, a default implementation of
the logic of this process is in place, inside of the Service class and general framework; and
you only need to implement your own functionality in the derived classes. This should
reduce the amount of coding that is required. The default framework either always returns
a password or never returns a password, as is described later in this section. If there is no
contract however, then this process is ignored and default to true, but the rest of the AI
features are still used.
8.1 Contract Description
The contract description was originally passed as an XML element. There is now a dedicated
Contract object that acts essentially as a wrapper for the XML document, but also
provides some other functionality. The wrapped XML document is still arbitrary however
and does not have to conform to any particular structure. Default contracts created by the
licas framework do have a specific structure, but they are the only types of contract that are
processed automatically. So the licas framework will pass and process ‘Contract objects’
only now. A contract agreement results in the service returning a password that allows
access to one of its methods. Because the system is open, this method can then be invoked
any number of times by the client or calling service. This is probably a better default
situation. You can change this functionality in your own service classes as required, to add
other restrictions or passwords, for example.
8.2 Contract Manager
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 31/35
Licas Autonomic Methods User Guide V1.7
31
Any service that extends the licas services has a ContractManager added to it. For the
contract manager to do anything however, you also need contracts added to your service,
describing the conditions under which it will accept work. No contracts are added
automatically, when the default implementation always returns true for any contract
evaluation, meaning that any request for a password will always return the password.
The ContractManager stores the service level agreement objects in a list - one for each
service level that is specified. When that level is asked about, the related ServiceLevel
object is retrieved and invoked, to evaluate the contract proposal. A service level is
retrieved when the invocation of a method at that level is requested. The methods defined
at each service level are described in the admin document that initialises the service. If no
levels are defined, then the global password is required, but a SLA can still be added to the
admin document, for negotiation over retrieving the global password as well. The following
steps would then be used during a negotiation process:
1. Client invokes the getPassword method on a service with a proposed contract.
2. If OK, the service returns the appropriate password.
3. If not OK, the service replies with a null value.
3.1. Client then invokes the serviceNegotiate method, which should not require a
password and passes it the proposed new contract.
3.2. The service processes the new contract and replies.
4. This can continue until the service replies with OK, or the negotiation phase terminates.
5.
The client can then ask for the password again, with the agreed contract.
This description is expanded upon in the following sections.
8.3 Yes and No Contracts
The system comes with two default contract types. These are called ‘Yes’ and ‘No’. A ‘yes’
contract always returns the password, while a ‘no’ contract never returns a password. Theserver is actually initialised with one of these two contracts, but any services that are added
are not pre-configured this way. You can retrieve a default contract instance from a
Contract object using the static getYesContract or getNoContract methods. To
initialise a licas service of any type however, you need an admin document. This is the XML
script passed as a constructor parameter. It gets parsed to create the ServiceAdmin
object, which also stores the contract manager. For a full admin document with a default
contract only, you can use one of the two static ServiceAdmin methods called
createAdminOnlyContractYes or createAdminOnlyContractNo. These
create an admin document, but with only either a yes or a no contract description included.You can then initialise your service with the admin document. This is now the default setup
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 32/35
Licas Autonomic Methods User Guide V1.7
32
situation for the server, which is initialised with a ‘yes’ contract unless it is specified
otherwise. If either of these basic contracts are present, a service is not allowed to add any
other type of contract. Therefore, an open system can include a ‘yes’ contract (also the
default setup for the server), while a ‘no’ contract can be used to permanently password
protect access to your server. If you want to include levels of service, then you need othercontracts for each level and not one of these default ones. Always OK or always Not OK
cannot be overridden.
8.4 Adding and Negotiating with Contracts
The following steps are taken to add contract to your service and then to negotiate and
retrieve passwords using them.
8.4.1 Adding Contracts
Contracts can be added during the initialisation of the service using the admin document.
These contracts are called service level agreements. The XML-based admin document gets
passed to a method called parseAdminInfo and this contains the following code section:
if (adminXml != null){
parseAdminXml(adminXml);contractManager =
new ContractManager(adminInfo.getServicelevelContracts());}else{
contractManager = new ContractManager(null);}
If the admin document is present, it is firstly parsed and then the contract manager is
created and initialised with it. If it is not present, an empty contract manager is created
instead. The service level contracts are stored in the AdminInfo object, simply as the XML
section itself. It is not processed further there, but it is parsed again in the contract
manager. The contract manager then parses:
1. The related admin document section is stored under the
Service_Level_Contracts element name (see also the ‘licasAdminGuide’
document).
2. Each contract is still an arbitrary structure however that is stored under a
Service_Level_Contract element name.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 33/35
Licas Autonomic Methods User Guide V1.7
33
3. The contract sections are parsed and ServiceLevel objects created. These are then stored
in the service level agreements structure in the contract manager. You can also load in a
class type for a new service level object type.
4. If a licas ‘yes’ or ‘no’ contract is included, then that is the only contract which is allowed.
8.4.2 Retrieving Service Passwords
A service method can only be invoked if the password for the service is known. If you create
or load a service with no constructor parameters, then there is a default ‘anon’ value for
each password. If the service is not initialised with a different password, then it can always
be accessed with the default one. The request for the password starts by invoking the public
getPassword method on the service. This requires the calling service UUID and a
Contract object as parameters. The invoked service then evaluates the request as follows:
1. The contract manager object in the service is asked to evaluate the client contract.
2. If no contracts are stored, then true is returned.
3. If contracts are stored then their criteria must be met.
a. If a ‘yes’ contract is stored then it will always return true.
b. If a ‘no’ contract is stored then it will always return false.
c. Any other contract is arbitrary and needs to be implemented by the
programmer. The Servicelevel.contractIsOK() method needs to be
implemented to do this. The default version in the ServiceLevel class always
returns true and does not evaluate the contract. Note that the ServiceLevel
processThisContract method always returns a true ‘contract’ by default,
so the ServiceLevel class needs to be extended for any proper negotiation phase
to take place.
4. If the service level requirements are met, then the password for that level is retrieved
and returned.
5. If the requirements are not met, then the negotiation phase is required.
8.4.3
Service Negotiations
If the password is not automatically available, a negotiation phase may be required. This is
also a place where real intelligence can be programmed into the service, but it is not
provided for as standard. Only the framework for linking each stage of the process is
available. If the client is not allowed a password, it can then call the service’s
serviceNegotiate method with a new contract. The negotiation phase would possibly
start with the original contract again. The invoked service must then process the contract
and return a ‘contract’ reply that describes the problems or acceptance of the proposed
contract. The following sequence of steps might take place:
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 34/35
Licas Autonomic Methods User Guide V1.7
34
1. The contract manager’s processClientContract method is invoked with the client
contract as a parameter.
2. This retrieves a service level object for the contract and invokes the ServiceLevel object’s
contractReply method.
3.
That in turn calls either the contractIsOK or the processThisContract methods that both return true by default.
4. Therefore, for a negotiation phase to take place, these need to process and return more
intelligent information and the calling client needs to be able to do the same as well.
a. Possibly, both the client and the service know what elements are in the contract
and can try to match specific values for each important element type – cost or
time, for example.
b. If a contract is for one service invocation only, you would need to implement
another level of password protection in your derived service that always returns
a new password for any accepted service process.
c. If security is the main issue, then if the client and service know each other, this
might allow a password to be returned - simply as an access restriction password.
5. Note that the server is initialised with only a ‘yes’ or a ‘no’ contract, when there cannot
be a negotiation phase.
References
[IBM] IBM (2003). An Architectural Blueprint for Autonomic Computing, IBM and Autonomic
Computing.
7/18/2019 Licas Autonomic Manager User Guide
http://slidepdf.com/reader/full/licas-autonomic-manager-user-guide 35/35
Licas Autonomic Methods User Guide V1.7
Appendix A – Example Autonomic Manager Script Creation
A copy of the script can be found in the docs/xmlSchemas folder. The script can be
created from the MetaServiceAI class that is part of the services package. The code is
also downloadable from the licas web site – Knowledge Base page. Calling the
MetaServiceAI.adminAutoEmail() method returns a full admin script for loading
and initialising an email utility service for a parent service. Note that the constructor
parameters for the email initialisation, needs to be the same as what the parent service is
created with. The system and GUI can then easily obtain these passwords, for the
autonomic manager to invoke the email service with. A template however can be loaded
into the GUI and then edited, for example.
The policyWebServiceScript method returns a Policy script only, for invoking a
single method on a web service.
You would then add an Auto-derived service to the server as normal, using the constructor
with 3 parameters, where the third admin script parameter is the one created by the above
code. The default classes will then parse it and also try to create the script objects and store
the conditions under which it should work. See also section 5.2.
Alternatively, to simply invoke the web service locally, the following would work. This is for
the dae temperature conversion web service:
String wsdlAddress = "uri to/dae_TemperatureConversions.wsdl";
String operation = "CelciusToFahrenheit";
Hashtable varHash = new Hashtable();
varHash.put("nCelcius", "100.0");
Element policyXml = MetaServiceAI.policyWebServiceScript(wsdlAddress,
operation, varHash);
AutoEngine autoEngine = new AutoEngine();
autoEngine.setEventRuleAction(policyXml);
MessageInfo messageInfo = null; //not needed here
Vector replyObj = autoEngine.process(messageInfo);
Top Related