licas autonomic manager user guide

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



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




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




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.




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.




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

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.




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.




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




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.




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.




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{




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.




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;

}}

}}




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);}




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




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




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.




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.




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.




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




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.




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);




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




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




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.




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.




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.




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’.




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




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




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.




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:




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.




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);

licas autonomic manager user guide

Documents