An Example of Implementing a Complex Function As an Agent . 22

Complex cross-application functionality also maps into agent. Section 3.1.2 contains a list of various functionality in Trinity. Figure 4.3, adapted from [19], shows the agent and the infrastructure it requires for the last function in that list, the model transformation into EMF format. The “Modeling UI” in Figure 4.3 means same as MMA in this thesis.

As before, the dashed line represents the route an agent travels during the model transformation. At first, the agent is created as a result from user input in MMA.

The agent then reads the desired model into its data container at stage two. Then, a language-independent agent transportation occurs at third stage. In stage four, the actual model transformation into EMF format happens. The transformation utilizes Eclipse API for creating EMF objects, and uses agent’s data container as input. Finally, at stage five, the testing and validation tool is started and EMF model is passed to it. After the tool completes, it will display results to the user.

More detailed description is provided in [19].

4. The Language-Independent Agent Architecture 23

Figure 4.3: The applications, agent architecture infrastructure, agent, and tasks of the EMF model transformation.

4.2 Language-Independent Definition of the Agent State 4.2.1 The Formal Definition of the Agent State

The different implementations, one for each language, of the agent architecture presented in this thesis must be compatible between language boundaries. Therefore, the full state of any agent must be defined in a language-independent fashion. First the basic components used throughout definitions concerning agent state are defined in Definition 4.2.1.

Definition 4.2.1. Let the set of all Unicode symbols [29] be Σ. Then 1. the set of all possibly usable task outputs isTO = Σ^∗,

2. the set of all possibly usable instance IDs isI = Σ⁺, and 3. the set of all possibly usable tags is T = Σ⁺×Σ⁺.

A function to retrieve agent state, when agent’s instance ID is given, is defined next. This function might return different results, depending at which point in lifecycle of agent the function is called, since the state of the agent most likely is changing as the agent is being executed. One way to map this function to reality is that this function is interpreted as the agent architecture. The function consumes the instance ID of the agent, and returns the state for such agent.

Definition 4.2.2 (The function to retrieve an agent state). To begin, a set of all possible execution states for any agent is defined to beES, and a set of all possible data states for any agent is defined to be DS. Let I be as in Definition 4.2.1 (2).

The function to retrieve an agent state with given agent instance ID is AS : I → {nil} ∪(ES ×DS). AS produces nil if the agent with given instance ID does not

4. The Language-Independent Agent Architecture 24

exist in agent architecture environment. However, if the agent exists, it will return the state of the agent as∈ES ×DS.

Next, constraints forES andDS are defined, so that results produced byAS are meaningful. First, the constraints for a set of all possible execution states ES are defined.

Definition 4.2.3 (Constraints for execution states). All elements of ES are of the form(V,E,v,ˆ VT,ET,EX), where

1. V is a set, and E ⊆V ×V. Together V and E are interpreted as a directed graph. This graph is called theagent task graph, since every vertex represents a single task to execute, and edges are transitions between tasks.

2. ˆv ∈ V is a root vertex of the task graph. It must hold that every vertex is reachable from the root vertex, that is,∀v ∈V : ˆv →^∗ v.

3. VT is a function such thatVT :V → P(T), whereT is as in Definition 4.2.1 (3), and ∀v ∈V : |VT(v)| <∞. The meaning of VT is that it returns a set of tags, which the agent task must have so that the task represented by this vertex gets executed.

4. ET is a function so thatET :E → P(TO), whereTO is as in Definition 4.2.1 (1), and ∀e ∈ E : |ET(e)| < ∞. The meaning of ET is that in order for the task represented by target vertex v_t to be executed, the task represented by source vertex v_s must return task output to_vs such thatto_vs ∈ET(v_s, v_t).

5. EX ∈ P(EP ×ST) is a set of the execution lifelines of the agent. The EP is a set of all possible paths starting at vˆ so that EP = {ep₀ep₁. . . ep_n | n ≥ 0∧ ep₀ = ˆv ∧ ∀i; 1 ≤ i ≤ n : (ep_i−1, ep_i) ∈ E}, and ST is a set of execution statuses such that ST = {executing,in_transition,stopped}. The meaning of EX is that it is a set of all current execution lifelines of the agent.

Additionally, the elements V,E,ˆv,VT, and ET are fixed for each agent. That is, given specific agent instance ID, they must always stay the same regardless of the call time of AS.

Each time the task completes, the vertex representing this task is added to the path of the current execution lifeline. Furthermore, for allep_i+1 in all paths, the task executed by ep_i returned task output to so that to ∈ ET(ep_i, ep_i+1). This means that execution path must traverse only those edges, for which there exist task output inET.

4. The Language-Independent Agent Architecture 25

If EX = ∅, then agent execution is considered to be stopped. If there are many execution lifelines with status other than stopped, then it means that the lifelines are executingconcurrently. Next, the constraints for all possible data statesDS are defined.

Definition 4.2.4 (Constraints for data states). All elements ofDS are of the form (aid, hlid,N,VN), where

1. aid ∈I, where I is as in Definition 4.2.1 (2), is the instance ID of the agent.

It must hold that AS(id)produces the state which has the instance IDaid of same value as id given to AS.

2. The hlid∈I is the instance ID of the home location of the agent,

3. N is a domain-specific set of names for domain-specific data contained by this agent. Formally,N ⊆Σ⁺ and |N|<∞.

4. VN is a function VN : N → LI. It returns the language-independent data structure for each name inN. All elements of LI are software objects.

Additionally, the elementsaid and hlid are constants for each agent.

4.2.2 Agent State During Transportation

In order to specify more concretely what sort of data is transported in agent trans-portation, a set of properties for agent state during transportation is defined. First, we decompose this state into two parts: the execution state, and the data state.

Additionally, we assume that all areas, locations, and agents have an ID unique in the scope of their type. This means that an area and an agent may have the same IDs.

Data state — agent architecture related Agent instance ID The ID of the agent.

Home location ID The ID of location, where agent was originally created.

History information An ordered list, in ascending order, of history infor-mation items. The order is determined by completion time of each task.

After execution of a task has been completed, the history information item is appended to this set. This item is composed of the tags of the task, the ID of location, and an UTC time of completion of the task.

Destination

Criteria for area tags A set of tags that area must have in order to execute the next task. Optional.

4. The Language-Independent Agent Architecture 26

Criteria for area ID The ID that area must have in order to execute the next task. Optional.

Criteria for location tags A set of tags that location must have in order to execute the next task. Optional.

Criteria for location ID The ID that location must have in order to execute the next task. Optional.

Criteria for agent history True if the location ID may be in history information of this agent. Falseotherwise.

Data state — domain-specific

Data container The contents of the data container of the agent.

Execution state Task graph

Vertices A set of task graph vertices. Each vertex represents a task to be executed, and has an ID, unique in scope of this graph, and a set of tags. The actual task must have all the tags of this vertex to be executed.

Edges All the transitions between vertices. Each transition has the pre-vious and next vertices, and the task output (a single string), which the previous task must return in order the transition to be used.

Next task The ID of the vertex in task graph, which will be used to search for the next task to execute.

In the execution state, there is only one vertex for the task to be executed next.

This is because transportation occurs one execution lifeline at a time. Thus, only one task at a time may be executing at any point in the lifeline. There is a possibility for execution lifelines to perform forks (where a single lifeline spawns at least one new lifeline) andjoins (where at least two lifelines merge into one). Hence, there is a need to define what exactly happens during such join. That is, what to do when two lifelines with different data container are merged? The answer for this question is not presented in this thesis, since the agent architecture is still in prototype stage.

4.3 Language-Independent Data Structures

4.3.1 Language-Independent Data Structure Types

In order to have a uniform way of handling the language-independent data in dif-ferent programming languages, we define here a set of language-independent data

4. The Language-Independent Agent Architecture 27

structure types. The types are further decomposed into atomic types and composed types. Each atomic type contains a single datum easily transformable and under-standable in a type systems of most programming languages. Correspondingly, each composed type is a container for other language-independent data structures, and also easily transformable and understandable in a type systems of most programming languages.

Next we list all language-independent data structure types required for agent architecture operation. Formally, we define types for the software objects in set LI defined in Definition 4.2.4.

Atomic types

Int32 and Int64: data structures representing signed 32-bit and 64-bit in-tegers, respectively.

Real32 and Real64: data structures representing 32-bit and 64-bit floating point values [4], respectively.

String: data structure representing a string of n characters, where n ≥0.

Boolean: data structure having two possible values, either true or false.

Binary: data structure representing sequence of n binary numbers, where n ≥0.

Composed types

List: data structure representing an ordered list of n other data structures, where n≥0.

Map: data structure representing an unordered list of named other data structures. Each name is unique in scope of a single Map.

These data structure types are enough to present data common to all program-ming languages. However, the user of the agent architecture is able to extend these types and provide her own custom types.

4.3.2 Serialization Rules for Language Independent Data Structures

Each language-independent data structure type has a serialization rule. This rule istwo-way in the sense that unambiguous deserialization must be possible from the serialized format without any loss of data. The serialization format is binary in order to be as compact as possible. The rules have two variations: one variation should be used when schema is available during serialization of data structure, and the other

4. The Language-Independent Agent Architecture 28

variation should be used when such schema is not available during serialization of data structure.

Now follows a list of serialization rules for all defined language-independent data structure types.

Int32 and Int64:

Serialized with schema: variable-length [2] ZigZag [1] encoding, in little-endian byte order.

Serialized without schema: serialized unique string value for the type of data structure, followed by same value as when serializing with schema.

Real32 and Real64:

Serialized with schema: 32 and 64-bit number, respectively, as defined in IEEE 754 [4], in little-endian byte order.

Serialized without schema: serialized unique string value for the type of data structure, followed by same value as when serializing with schema.

String:

Serialized with schema: amount of bytes of string encoded in UTF-8 for-mat [29], as per serializing Int64 with schema, followed by the encoded string.

Serialized without schema: serialized unique string value for the type of data structure, followed by same value as when serializing with schema.

Boolean:

Serialized with schema: for true, byte 1, and forfalse, byte 0.

Serialized without schema: serialized unique string value for the type of data structure, followed by same value as when serializing with schema.

Binary:

Serialized with schema: amount of bytes, as per serializing Int64 with schema, followed by the bytes.

Serialized without schema: serialized unique string value for the type of data structure, followed by same value as when serializing with schema.

List:

4. The Language-Independent Agent Architecture 29

Serialized with schema: amount of contained items, as per serializing Int64 with schema, then for each contained item, whether it matches any contained schema, as per serializing Boolean with schema, followed by, if needed, index of matched contained schema, as per serializing Int64 with schema, followed by serialized contained item.

Serialized without schema: serialized unique string value for the type of data structure, followed by same value as when serializing with schema.

Map:

Serialized with schema: for each named sub-schema, in ascending alpha-betical order, whether the corresponding contained item is present, as per serializing Boolean with schema, followed by serialized contained item, as with List. For all remaining contained items, amount of the remain-ing contained items, as per serializremain-ing Int64 with schema, then for each contained item, the name of item in Map, as per serializing String with schema, followed by serialized contained item, as with List.

Serialized without schema: serialized unique string value for the type of data structure, followed by same value as when serializing remaining con-tained items when serializing with schema, only using all of concon-tained items as remaining items.

The unique strings mentioned in the serialization rule list are listed in Table 4.1.

It is assumed that possible extensions to the language-independent data structures will not be using these same strings for their custom data structure types.

Table 4.1: Unique strings for each data structure type defined in this thesis.

Data structure type The unique string identifying the type

Binary bi

Boolean b

Int32 i

Int64 l

Real32 f

Real64 d

String s

List o

Map m

30

5. IMPLEMENTATION OF THE LANGUAGE-INDEPENDENT AGENT ARCHITECTURE

5.1 The Implementation of the Agent Architecture

5.1.1 The Data Content Definition of the Agent Architecture

The implementation of the agent architecture follows DCI pattern quite closely. The data model of the agent architecture itself is very static, as seen in Figure 5.1. The only extension point is LIObject, covered later. The LIObject represents the base type of all language-independent data structures.

Area

Figure 5.1: Data model for agent architecture.

The data model in Figure 5.1 shows that area, location, and agent all have in-stance IDs. This ID is some arbitrary string, and it should be unique in domain-specific scope, which may be anything from a single application on single computer to big cloud network. Area has zero or more locations, and zero or more tasks are available for execution on the area.

The agent contains an arbitrary amount of LIObjects, associated with manda-tory unique name, and optional schema to use when serializing the LIObject. All

5. Implementation of the Language-Independent Agent Architecture 31

information about the tasks of the agent, and the order of tasks to execute, is in TaskTransition and TaskNode objects. The transition has previous node, next node, and task output. When task described by previous node completes with transition’s task output, the task(s) described by the next node should be executed next. The in-formation about currently parallelly executing tasks of the agent is available through association between Agent and TaskNode. The other association between those two classes specifies the very first task to be executed by the agent.

5.1.2 Functionality of the Agent Architecture

In order to retrieve the methods for location and tasks for tags, the DCI pattern is used. The contexts, interactions, and creators for location method and task retrieving are seen in Figure 5.2 and in Figure 5.3, respectively. In the Figure 5.2 there exists a singleton object LocationMethodRetrieverService, marked withservice stereotype. The service contains the mapping used to look up the context creator for appropriate location based on the tags of the location itself and the area owning the location. This creator then creates an instance of the concrete subtype of the RetrieverContext containing the implementation for actually retrieving methods for this location.

RetrieverContextCreator

-Area ID : Taggable -Location ID : Taggable

LocationInfo

«create»

{Location info is unique}

+createContext(in : Location, in : AgentTask) : RetrieverContext

«service»

LocationMethodRetrieverService

+getMethods()

«context»

RetrieverContext 1

*

{Disjoint, Incomplete}

Location

Figure 5.2: Contexts and interactions related to retrieving location methods in the agent architecture.

The Figure 5.3 has TaskPool as service mapping context creators based on task tags. After looking up the context creator, the service creates context, which is actually AgentTask in this case. The task has Agent and Location as two required roles. The task may use the location to retrieve the methods using LocationMethod-RetrieverService. The agent architecture is responsible of maintaining the execution of agent and using TaskPool to retrieve correct tasks for the agent.

5. Implementation of the Language-Independent Agent Architecture 32

+getTask(in : Taggable, in : Agent)

«service»

Figure 5.3: Contexts and interactions related to retrieving tasks in the agent architecture.

5.1.3 An Example of Using the Agent Architecture Tasks

This section continues example of Section 4.1.2. Figure 5.4 shows the tags for agent architecture infrastructure defined in Figure 4.2. This figure has been extended from Figure 4.2 by specifying which tags each entity has. Agent architecture will automatically assign the IDs for each entity, if needed, so they are not required to be explicitly defined. Typically, the decision of what kind of tags things have is design-time decision.

InfrastructureAgent

Agent for opening a view Task (C#):

Figure 5.4: The agent architecture setup for the opening a view in Eclipse.

The tags are shown as a rectangle with dashed border line inside the boxes of the used areas, locations, and tasks. Inside the rectangle, each tag is on its own line.

5. Implementation of the Language-Independent Agent Architecture 33

The pattern for the text on each line is key = value. The tags of the Transporter are omitted from the picture for brevity.

Now that the tags has been decided, it is time to actually implement things. Let us assume that the MMA is written inC#, and the Eclipse plug-in is written inJava.

Two methods shown in Listing 5.1 contain the code required to construct the main area of MMA. This code uses theAreaFactory and TaskPool services to create area and set up the task pool, respectively. The AreaFactory is part of abstract factory design pattern used to create Areas. These services are singletons and obtained at run-time using suitable frameworks of the native language.

public c l a s s MMASetup {

public Area CreateTAArea ( A r e a F a c t o r y a r e a F a c t o r y ) {

return a r e a F a c t o r y.CreateSubArea (new MMAAreaArchetype ( ) ) ; }

public void DoMMATaskPoolSetup ( TaskPool t a s k P o o l ) {

t a s k P o o l.R e g i s t e r C o n t e x t C r e a t o r ( new D e f a u l t T a s k C r e a t o r (

new S t a r t A p p l i c a t i o n T a s k A r c h e t y p e ( ) ) );

} }

Listing 5.1: Setting up the agent architecture environment for the sub-area of MMA.

The MMAAreaArchetype is a simple class implementing the required interface specified in agent architecture. This interface has methods to extract the information about what kind of tags, tasks, and locations the area will have. Thus building an

The MMAAreaArchetype is a simple class implementing the required interface specified in agent architecture. This interface has methods to extract the information about what kind of tags, tasks, and locations the area will have. Thus building an

In document A Language-Independent Agent Architecture (sivua 29-0)