ReactiveMachine

Introduction
Sources of inspiration
Design
Reactive communities and entities
Instants
Events and Messages
Agents
Agent facets
Conditional Events
ReactiveMachine, security
Key system
Create a community
Close it
Community board
Actions
DOM-like element based board
Touching elements
Saving and restoring a board
Actions on elements
Constraints on children elements
Action rejection
Packages
Package dependencies
Packages of package
Test
Installation
Trace system
Test program

Introduction

ReactiveMachine is a java-written reactive framework. It implements agents, which interact in a deterministic way, by using the reactive paradigm. This framework invites to experiment with something like collaborative programming. It is not sufficiently experienced for making depend your critical system on it but your return of experience would be appreciated.

The purpose of this document is to describe origins, design and use of the ReactiveMachine software. In order to get a good understanding of it, you should be familiar with object-oriented programming and Java.

Software version1.0
Documentation version1.0.1

Sources of inspiration

ReactiveMachine has mainly been inspired by reading publications around the Inria Mimosa project on reactive programming and more particularly on the Fair Threads framework. Like Fair Threads, ReactiveMachine installs an interaction system between threads, using event broadcasting. Synchronisations are realised by a community automata for the ReactiveMachine, which corresponds to a scheduler for the Fair Threads. Unlike Fair Threads, ReactiveMachine is not deterministic about thread execution order.

The community board seems to be an original proposition of the ReactiveMachine. The board idea comes from the blackboard (or whiteboard) that use scientists for sharing their theory. The board implementation design is not very surprising coming from an xmloperator project.

Design

Reactive communities and entities

At the centre of the ReactiveMachine is the ReactiveCommunity. A ReactiveCommunity accepts the connection of ReactiveEntities. Together, a ReactiveCommunity and its connected ReactiveEntities assume the reactive paradigm.

Both the ReactiveCommunity and the ReactiveEntity are associated to a Java thread but the ReactiveCommunity thread is an automata that belongs to the ReactiveMachine while a ReactiveEntity thread is developped for a specific ReactiveMachine application, by using Java as programming language.

At a given time, a ReactiveEntity is either connected or not connected to a community (we use community for ReactiveCommunity). It cannot be connected to more than one community. Connecting to another community imply first disconnecting from the first one. For connecting or disconnecting its entity (we use entity for ReactiveEntity), an entity thread uses respectively the connect() or the disconnect() entity method.

ConceptContractImplementation
ReactiveCommunity
org.xmloperator.reactive.
ReactiveCommunity
org.xmloperator.reactive.impl.
ReactiveCommunityImpl
ReactiveEntity
org.xmloperator.reactive.
ReactiveEntity
org.xmloperator.reactive.impl.
ReactiveEntityImpl

Instants

A community defines instants. An instant is characterized by a long value. The activity of the connected entities occurs during instants. One instant can end only when all connected entities have agreed to that. The community makes the observation of the end of an instant and begins a new one (by incrementing its long value).

Entity connection occurs during end-of-instant. if a connection to a community is initiated at a given instant of this community by the thread of an entity connected to this community then the connection will occur at the corresponding end-of-instant elsewhere there is no guaranty on which end-of-instant the connection will occur.

An entity thread declares to stop its activity for the current instant without condition by calling the stop() method of the entity. The call return will occur at the beginning of the next instant.

An entity thread declares to stop its activity for the current instant with the condition that all the other entity threads do the same, by calling the suspend() method of the entity. If all the other entity threads do the same then the call returns null at the beginning of the next instant. But if an Event without attachment (see next section) is broadcasted during this instant then the method returns this broadcasted event at this same instant.

Events and Messages

Events support reactive communication between the entities connected to a community. An Event belongs to its community. It has an identifier (its Object identifier) and, possibly, a name. If it has a name then this name is unique within the community.

Any connected entity (thread) can generate any event of its community. The event will be received by all the entities that are (or will be) suspended at the broadcasting instant, for an (any) event. If this event has no attachment then the broadcasting instant is the generation instant, as explained in the previous section.

An Event is or is not generated during a given instant. This is the reason why an event without attachment can be immediately broadcasted. Another entity (or the same) is allowed to generate the same event during the same instant but with no effect.

An Event with attachment cannot be broadcasted during the same instant because another entity can generate the same event with another attachment, which will be lost since event broadcasting already occurs during the instant. Broadcasting of an Event with attachment is differed to the begin of the next instant. The event is broadcasted with all the generated attachments.

The type of an Event is decided at instantiation : it will be always or never generated with attachment, but not sometimes. An Event with attachment is named a Message. A sender certified message is a message whose attachment is a CertifiedAttachment. A CertifiedAttachment contains in a certified way the identifier of the entity that has generated the message.

ConceptContractImplementation
Event
org.xmloperator.reactive.
Event
org.xmloperator.reactive.impl.
EventImpl
Message
org.xmloperator.reactive.
Message
org.xmloperator.reactive.impl.
MessageImpl
CertifiedAttachment
org.xmloperator.reactive.
CertifiedAttachment
org.xmloperator.reactive.impl.
CertifiedAttachmentImpl

Agents

An entity thread must have such an organisation than it can react to the events that are emited within its community. This is the purpose of Agents. An Agent is a thread attached to a ReactiveEntity and with a standard organisation. This looks like a framework. Life time of an Agent is composed of three phases : initialisation, reaction and termination.

The reaction phase of an Agent is a loop that terminates when a given condition occurs. Within the body of this loop the Agent waits for an event or a connection. The difference between waiting and being suspended is that, when no event is generated, being suspended makes the instant change but, waiting, it doesn't. A new connection to the community makes a new instant begin and interrupts the Agent waiting.

An Agent has a persistent identity. The persistent identifier of an agent is a String composed of it full class name and, possibly, of parameter(s) value(s). Each parameter value maps either to a long value or a String one.

ConceptContractAbstract implementationFramework implementation
Agent
org.xmloperator.reactive.
Agent
org.xmloperator.reactive.agent.
AgentImpl
org.xmloperator.reactive.impl.
AgentThread

Agent facets

An Agent may have to present several functionalities. It is useful that these functionalities be implemented separately in order to compose them freely. This is the purpose of Facets. A Facet is an agent component that assumes a part of the reaction behaviour of the agent. A Facet is attached to its Agent at agent initialisation or at a start-of-instant.

ConceptContractAbstract implementationFramework implementation
Facet
org.xmloperator.reactive.facet.
Facet
org.xmloperator.reactive.facet.
FacetImpl
org.xmloperator.reactive.agent.
FacetsAgent

A Facet is focused on processing messages whose attachment is a TermsAttachment. A TermsAttachment is a CertifiedAttachment that is composed of terms. A particular term of the attachment is the service descriptor, which specify the service provided by the facet. It is facultative. Service messages are drived to the facet that delivers the specified service. This is the purpose of services : allowing some optimisation.

ConceptContractImplementation
TermsAttachment
org.xmloperator.reactive.
TermsAttachment
org.xmloperator.reactive.impl.
TermsAttachmentImpl

Conditional Events

An example of facet is presented here.

At each instant, the ConditionalEventFacet is responsible of generating a particular event on the condition that some events occur and/or some others doesn't. Event generation is differed (one instant later) or not differed (at the same instant).

The condition is specified by a boolean expression, which is built using the following BoolConditions:

ConditionDescriptionImplementation
trueThe condition is true.
org.xmloperator.reactive.facet.event.
TrueBoolCondition
falseThe condition is false.
org.xmloperator.reactive.facet.event.
FalseBoolCondition
event eThe condition is true if the event e occurs.
org.xmloperator.reactive.facet.event.
PositiveEventBoolCondition
not event eThe condition is true if the event e doesn't occur.
org.xmloperator.reactive.facet.event.
NegativeEventBoolCondition
c1 and c2The condition is true if both conditions c1 and c2 are true.
org.xmloperator.reactive.facet.event.
AndBoolCondition
c1 or c2The condition is true if at least one of the conditions c1 and c2 is true.
org.xmloperator.reactive.facet.event.
OrBoolCondition

It must be noted that the conclusion (i.e. the event generation) is necessarily differed when the condition contains a negation (event not occurring).

FacetImplementation
ConditionalEventFacet
org.xmloperator.reactive.facet.event.ConditionalEventFacet

ReactiveMachine, security

The object that is responsible of launching Agents is the ReactiveMachine. The ReactiveMachine is unique within the Java virtual machine. A reference to a ReactiveMachine is obtained through a ReactiveFactory.

An agent is launched with a given profile, which it will conserve until its termination. The profile specify the operations (entity methods) that the agent can use. Any combination is possible. Standard ones are proposed, they are said restricted, standard and full. Profiles are an element for the security of the system. Launching is done by an Agent with a profile that includes the launching operation.

Another element for security is the prevention mechanism: an agent which appears to violate some given rules can be prevented to operate any more on the ReactiveMachine. Prevention is done by an Agent with a profile that includes the prevention operation. Prevention can be strong (any operation, including stop() and suspend() are prevented) or weak (only operations such as generateEvent() are prevented).

At launching, arguments are passed to the agent through a LaunchingContext. A LaunchingContext is a set of couple (name, value). Predefined argument names are defined by the Agent interface. They includes the reference to the ReactiveEntity attached to the agent and the reference to the ReactiveMachine.

There is no control on the agent persistent identifier (see the Agents section) at the ReactiveMachine level because identification is only meaningfull when participating to a particular community. Unicity of persistent identifier of the connected agents can be a rule of the community.

ConceptContractImplementation
ReactiveMachine
org.xmloperator.reactive.
ReactiveMachine
org.xmloperator.reactive.impl.
ReactiveMachineImpl
ReactiveFactory
org.xmloperator.reactive.
ReactiveFactory
org.xmloperator.reactive.impl.
ReactiveFactoryImpl

Key system

Most of the restrictions that are specified by an agent profile are implemented by the entity associated to the agent. For the others, the ReactiveMachine used a key system. A key protected method has a long key argument. Calling such a method requires to provide the good key value. Calling it with a bad key value throws a PrivilegiedAccessException. Following is the list of the ReactiveMachine methods that are protected by a key.

ReactiveMachine methodDescription
launchAgent()
Launches an Agent. This method is dedicated to the main thread since a connected Agent can use the corresponding method of its entity.
preventAgent()
Prevents an Agent. An Agent with a profile for preventing agents receives the corresponding key in its LaunchingContext.
done()
Terminates the ReactiveMachine. Call returns after all agents and all communities have terminated.

The three corresponding key values are delivered by the ReactiveFactory when creating the ReactiveMachine.

The ReactiveMachine object provides a newKey() method for generating key values.

Create a community

Communities are created by agents. An agent whose profile includes the community creation operation can, usually at initialisation, create its community. Usually, such an agent is the manager, for its full life, of the community that it has created. A community is said idle when no entity is connected to it.

At creation, a community usually receives a theme. This can be a name, which identify the community. Without theme, there is no difference between a community and another one. An agent that, at initialisation, wants to connect to a community with a given theme, asks for this theme to the ReactiveMachine.

At launching, an agent may also be directly connected to a given community. This is done by adding a DESTINATION_COMMUNITY argument to the LaunchingContext. In this case, a theme is not useful.

Close it

Only the agent that created it may close a community. Another agent would throw a CommunityOwnerException.

Closure is effective once the community is idle. Once closed, a community continues to respect its contract (such as broadcasting events), excepted that it accepts no connection.

Community board

The community board answers to these questions:

  1. A board is attached to a community and constitutes its shared memory.

  2. A board is data. This data is invariant during an instant but can change during end-of-instants.

ConceptContract
Board
org.xmloperator.reactive.Board

Actions

For making the board (or any other environment of the community) data change during end-of-instants, Actions are used. An Action describes the operation that will be executed by the community automata during an end-of-instant. An action is transmitted using an action message. An action message is a Message whose attachment is an ActionAttachment.

An action has three possible status: proposed, executable or executed. Following is a scenario that uses these three status:

  1. An agent generates an action message with a proposed action.

  2. The community automata changes the action status to executable before broadcasting the action message, at the beginning of the next instant.

  3. The community manager, an agent that is supposed to have a profile including the executable action message generation, receives the action message and regenerates it (it is supposed to accept the action), as it is.

  4. At the end-of-instant, the action is executed by the community automata and the action status is changed to executed. If an exception is thrown by the action execution then this exception is stored in the ActionAttachment.

  5. The action message is broadcasted, at the beginning of the next instant.

This scenario allows a full control of actions. An agent with a good profile can also directly generate an executable action message.

Reversing an action is not proposed because usually not deterministic.

ConceptContractImplementation
Action
org.xmloperator.reactive.
Action
org.xmloperator.reactive.impl.
ActionImpl
ActionAttachment
org.xmloperator.reactive.
ActionAttachment
org.xmloperator.reactive.impl.
ActionAttachmentImpl

DOM-like element based board

The ReactiveMachine proposes a concrete implementation of board. This is a hierarchical structure of elements that looks very like the Document Object Model (DOM) of the W3C. An advantage of such a structure is that it can be easily read or written as an XML content.

An Element is either a ParentElement, a DataElement or an empty element. A ParentElement can have children elements, a DataElement cannot, neither an empty one. Any Element has a local name and, possibly, a namespace URI.

A DataElement is a recipient for a data with a given data type, which corresponds to a Java type. Used data types are: long, double, string and object. An object data type corresponds to a TranslatableObject. A TranslatableObject is an Object with a method for translating it to an Element and another method that is used for instanciating an Object, called Rebuilder, which is able to rebuild the TranslatableObject from its representing Element.

Conformant to the board contract, all element attributes are readable (by any agent) but none are (directly) writable. TranslatableObjects have to respect the same contract.

ConceptContractImplementation
Element
org.xmloperator.reactive.element.
Element
org.xmloperator.reactive.element.impl.
ElementImpl
ParentElement
org.xmloperator.reactive.element.
ParentElement
org.xmloperator.reactive.element.impl.
ParentElementImpl
DataElement
org.xmloperator.reactive.element.
DataElement
org.xmloperator.reactive.element.impl.
[Long|Double|String|Object]DataElementImpl
TranslatableObject
org.xmloperator.reactive.element.
TranslatableObject
Rebuilder
org.xmloperator.reactive.element.
Rebuilder

Touching elements

The board implementation provides through the ElementWritingAccess interface a method that returns for any Element a corresponding RWElement with writing methods. This method requires a key value (see the Key system section) that doesn't depend on the Element. This key value is delivered to the ReactiveCommunity when setting its board. In that way, the community and only it is allowed to touch the board, during end-of-instants.

ConceptImplementation
Board
org.xmloperator.reactive.element.impl.
ElementBoardImpl

Saving and restoring a board

The board implementation is also a RootElement implementation. A RootElement is a ParentElement. Namespaces are managed at its level.

ConceptContractImplementation
RootElement
org.xmloperator.reactive.element.
RootElement
org.xmloperator.reactive.element.impl.
ElementBoardImpl

Saving and restoring a RootElement are respectively assumed by the DocumentWriter and DocumentReader objects.

ObjectImplementation
DocumentWriter
org.xmloperator.reactive.element.util.
DocumentWriter
DocumentReader
org.xmloperator.reactive.element.util.
DocumentReader

Actions on elements

The following Actions on Element are available:

ActionDescriptionImplementation
InsertA given element is inserted before a reference Element.
org.xmloperator.reactive.element.action.
ElementInsertAction
AppendA given Element is appended as last child of a reference ParentElement.
org.xmloperator.reactive.element.action.
ElementAppendAction
RemoveA reference Element is removed.
org.xmloperator.reactive.element.action.
ElementRemoveAction
ChildrenRemoveThe children of a reference ParentElement are removed.
org.xmloperator.reactive.element.action.
ChildrenRemoveAction
ChildrenSortThe children of a reference ParentElement are sorted using a Comparator of Element.
org.xmloperator.reactive.element.action.
ChildrenSortAction

Remarks

Constraints on children elements

Constraints can be set on the children elements of a ParentElement. The following ChildrenConstraints are available:

ConstraintDescriptionImplementation
DifferentNamesTwo children elements of a ParentElement cannot have the same name (local name and namespace URI).
org.xmloperator.reactive.element.constraint.
DifferentNamesChildrenConstraint
FixedNameAll the children elements of a ParentElement have the same given name (local name and namespace URI).
org.xmloperator.reactive.element.constraint.
FixedNameChildrenConstraint
ChildCountThe count of the children elements of a ParentElement cannot be less than a min value after a remove operation neither greater than a max value (-1 for no max value) after an insert/append operation.
org.xmloperator.reactive.element.constraint.
ChildCountChildrenConstraint

An ElementAction whose execution is contrary to a ChildrenConstraint returns a ChildrenConstraintException in the ActionAttachment.

ConceptContract
ChildrenConstraint
org.xmloperator.reactive.element.ChildrenConstraint

Action rejection

More flexible than ChildrenConstraint is Action rejection. At the contrary of ChildrenConstraint, Action rejection operates before Action execution, when the Action has yet the status proposed (see explanations on Action status in the Actions section). An ActionRejector decides if a given Action has to be rejected.

ConceptContract
ActionRejector
org.xmloperator.reactive.element.action.reject.
ActionRejector

Following are the available action rejectors on elements:

ActionRejectorDescriptionImplementation
Element modify rejectorAdding or removing children to any Element that conforms to a given ElementSpecification has to be rejected.
org.xmloperator.reactive.element.action.reject.
ElementTouchRejector
.newModifyRejector(ElementSpecification)
Element remove rejectorRemoving any Element that conforms to a given ElementSpecification has to be rejected.
org.xmloperator.reactive.element.action.reject.
ElementTouchRejector
.newRemoveRejector(ElementSpecification)

An ElementSpecification decides if an Element is conformant or not to it.

ConceptContract
ElementSpecification
org.xmloperator.reactive.element.spec.
ElementSpecification

Following are the available ElementSpecifications:

ElementSpecificationDescriptionImplementation
RootThe board root Element.
org.xmloperator.reactive.element.spec.
RootElementSpecification
ElementName( localName , namespaceURI )Any Element that has the given local name and namespace URI (which can be null).
org.xmloperator.reactive.element.spec.
ElementNameSpecification
Child( localName , namespaceURI , parentSpecification )Any Element that has the given local name (if not null) and namespace URI (which can be null) and is child of a parent that conforms to the given specification.
org.xmloperator.reactive.element.spec.
ChildElementSpecification
IncludingDescendance( elementSpecification )Any Element that conforms to the given specification plus any descendant Element.
org.xmloperator.reactive.element.spec.
IncludingDescendanceElementSpecification
And( elementSpecification1 , elementSpecification2 )Any Element that conforms to both the two given specification.
org.xmloperator.reactive.element.spec.
AndElementSpecification
AndNot( elementSpecification1 , elementSpecification2 )Any Element that conforms to the first given specification but does'nt conform to the second one.
org.xmloperator.reactive.element.spec.
AndElementSpecification

ActionRejectors and ElementSpecifications are TranslatableObjects (see the element based board section). An ActionRejector is stored in the community board as an ObjectDataElement, child of a ParentElement named "rejects". There can be several "rejects" ParentElement in the board. Also, in order to know what "rejects" ParentElements may contain the ActionRejectors that can be concerned by a given action, the following conventions are applied:

Action rejection is processed by a facet named ActionExecutionFacet. It is usually attached to the agent that manages the community. An ActionExecutionFacet regenerates the executable actions that no ActionRejector rejects.

FacetImplementation
ActionExecutionFacet
org.xmloperator.reactive.facet.
ActionExecutionFacet

An Agent whose a proposed action is rejected is not considered as violating a rule. It will not be prevented for that.

Packages

Package dependencies

-----------------
Dependent_package
Used_package
-----------------
org.xmloperator.reactive
org.xmloperator.reactive.exception
org.xmloperator.reactive.impl
org.xmloperator.reactive.exception
org.xmloperator.reactive
org.xmloperator.reactive.util
org.xmloperator.reactive
org.xmloperator.reactive.impl
org.xmloperator.reactive.facet
org.xmloperator.reactive.exception
org.xmloperator.reactive
org.xmloperator.reactive.util
org.xmloperator.reactive.facet.event
org.xmloperator.reactive.exception
org.xmloperator.reactive
org.xmloperator.reactive.facet
org.xmloperator.reactive.agent
org.xmloperator.reactive.exception
org.xmloperator.reactive
org.xmloperator.reactive.util
org.xmloperator.reactive.facet
org.xmloperator.reactive.element
org.xmloperator.reactive.exception
org.xmloperator.reactive.element.exception
org.xmloperator.reactive.element.impl
org.xmloperator.reactive.exception
org.xmloperator.reactive.element.exception
org.xmloperator.reactive.element
org.xmloperator.reactive.element.constraint
org.xmloperator.reactive.element.exception
org.xmloperator.reactive.element
org.xmloperator.reactive.element.spec
org.xmloperator.reactive.element.exception
org.xmloperator.reactive.element
org.xmloperator.reactive.element.impl
org.xmloperator.reactive.element.action
org.xmloperator.reactive
org.xmloperator.reactive.impl
org.xmloperator.reactive.element.exception
org.xmloperator.reactive.element
org.xmloperator.reactive.element.impl
org.xmloperator.reactive.element.action.reject
org.xmloperator.reactive
org.xmloperator.reactive.element
org.xmloperator.reactive.element.impl
org.xmloperator.reactive.element.spec
org.xmloperator.reactive.element.action
org.xmloperator.reactive.element.util
org.xmloperator.reactive.exception
org.xmloperator.reactive.element.exception
org.xmloperator.reactive.element
org.xmloperator.reactive.element.impl
org.xmloperator.reactive.element.constraint
org.xmloperator.reactive.test
org.xmloperator.reactive
org.xmloperator.reactive.impl
org.xmloperator.reactive.element
org.xmloperator.reactive.element.impl
org.xmloperator.reactive.element.constraint
org.xmloperator.reactive.element.spec
org.xmloperator.reactive.element.action
org.xmloperator.reactive.element.action.reject
org.xmloperator.reactive.element.util
org.xmloperator.reactive.util
org.xmloperator.reactive.facet
org.xmloperator.reactive.facet.event
org.xmloperator.reactive.agent

Packages of package

The following packages of package can be constitued (each package depends on the previous ones):

ReactiveMachine contains
org.xmloperator.reactive.exception
org.xmloperator.reactive
org.xmloperator.reactive.impl
ReactiveAgents contains
org.xmloperator.reactive.util
org.xmloperator.reactive.facet
org.xmloperator.reactive.facet.event
org.xmloperator.reactive.agent
ReactiveElements contains
org.xmloperator.reactive.element.exception
org.xmloperator.reactive.element
org.xmloperator.reactive.element.impl
org.xmloperator.reactive.element.constraint
org.xmloperator.reactive.element.spec
org.xmloperator.reactive.element.action
org.xmloperator.reactive.element.action.reject
org.xmloperator.reactive.element.util
org.xmloperator.reactive.element.facet
ReactiveTests contains
org.xmloperator.reactive.test

Test

Installation

The ReactiveMachine software is provided in source form exclusively. Its execution display needs a Java development platform, such as Eclipse.

In order to install the software with Eclipse you have to:

  1. create a new Java project (File / New / Project... / Java),
  2. give it a name,
  3. copy the provided source directory content into the project source directory,
  4. refresh the project hierarchy (File / Refresh).

The software uses any JRE System Library that includes an XML parser.

Running the software (Run / Run...) needs to specify its main class: org.xmloperator.reactive.test.Test

Trace system

A trace system is avalaible for debugging. It is activated by calling the setTrace() method of ReactiveFactoryImpl (see the ReactiveMachine section). Trace activation operates at the class level: if traces are on for a class then all the instances of this class will generate traces.

The classes that propose traces are the following:

Following are examples of traces:

TraceComments
A1 is [..]CommunityManagerAgent
The agent number 1 is launched. Its persistent identifier is the full class name with no parameter.
A2 is [..]SyracuseAgent/13
The agent number 2 is launched. Its persistent identifier is the full class name with an int parameter value.
A1 starts
Agent 1 starts.
C1 starts
The community number 1 starts.
C1 instant 1
Community 1 : instant 1 begins.
C1 A1 close
Agent 1 closes the community 1.
C1 idle
Community 1 has no connected entity.
C1 terminates
Community 1 is done because closed and idle.
A1 terminates
Agent 1 is done.
ReactiveMachine is done
All communities are closed and all agents terminated.
C1 A1 E1 is "clock"
Within community 1, agent 1 creates the event number 1, named "clock".
C1 A1 generate E1
Within community 1, agent 1 generates the event 1.
C1 broadcast E1
Event 1 is broadcasted within community 1.
A2 has processed E1
Agent 2 has received and processed event 1.
C1 A1 MC1 is "salutation"
Within community 1, agent 1 creates the certified message number 1, named "salutation".
C1 A1 generate MC1 A1("Hello")
Within community 1, agent 1 generates the certified message 1 with an attachment composed of the term "Hello".
C1 broadcast MC1
Certified message 1 is broadcasted with all its attachments within community 1.
C1 A2 generate MCA1 A2(P[.3]append<turtles>())
Agent 2 proposes, through the action message 1, to appending a child element named "turtles" to the third child element of the board root element.
C1 A1 generate MCA1 A1(E[.3]append<turtles>())
Agent 1 verifies the proposed action message 1 and regenerates it for execution.
C1 A1 action X[.3]append<turtles>() fails
  by [..]ChildrenConstraintException: D
Appending an element named "turtles" to the third child element of the board root element has failed because there is already a child element named "turtles". A ChildrenConstraint attached to the root third child element (whose name is "projects") specifies that its children must have different names.
A2 proposal E[]append<wiki>() is rejected
Proposal of appending a "wiki" element to the board root element has been rejected. The reason, not given in the trace, is that any adding or removing child to/from the board root element is rejected. This is specified by an ActionRejector located in the "rejects" child element of the board root element.

Test program

The test program Test.main() is a sequence of test procedures. Each test procedure executes the following instructions:

  1. A ReactiveMachine is instancied using the ReactiveFactoryImpl.REACTIVE_FACTORY.

  2. A first Agent is launched. It creates a ReactiveCommunity. The reference to this community is usually returned to the main thread through the DESTINATION_COMMUNITY argument of the LaunchingContext.

  3. Other agents may be launched and connected to this community. They interacts with the first one during some instants and terminate.

  4. The first agent close the community while terminating.

  5. The ReactiveMachine.done() method waits for any agent is terminated and any community closed before returning. The test procedure is terminated. A new one can begin.

A CrashingReport object stores data about Agent crashing. If no crash is detected then the following message is printed on System.out:

No agent crashes
ConceptContractImplementation
CrashingReport
org.xmloperator.reactive.
CrashingReport
org.xmloperator.reactive.test.
CrashingReportImpl

The subjects and sections concerned by the different test procedures are the following:

Test procedureSubject or classMethodsSection
test_3_stops_and_2_suspends
org.xmloperator.reactive.
ReactiveEntity
stop()
suspend()
Instants
org.xmloperator.reactive.
Agent
continues()
Agents
org.xmloperator.reactive.agent.
AgentImpl
newCommunity()
Create a community
test_globalExit
org.xmloperator.reactive.agent.
GlobalExitAgent
 
Events
Preventing an Agent that violates a rule or tries to do so
 
Security
test_clock
org.xmloperator.reactive.agent.
ClockAgent
 
Events
org.xmloperator.reactive.
Agent
processEvent()
Agents
test_conditionalEvent
org.xmloperator.reactive.
ReactiveEntity
createEvent()
searchEvent()
generateEvent()
Events
org.xmloperator.reactive.
Agent
init()
continues()
terminate()
Agents
org.xmloperator.reactive.facet.
ExitFacet
 
Facets
org.xmloperator.reactive.agent.
FacetsAgent
addFacet()
Facets
org.xmloperator.reactive.facet.event.
ConditionalEventFacet
 
Conditional Events
org.xmloperator.reactive.agent.
AgentImpl
newCommunity()
Create a community
test_Syracuse:
org.xmloperator.reactive.test.
SyracuseAgent
org.xmloperator.reactive.impl.
AgentImpl
addParameter()
Agents
org.xmloperator.reactive.
ReactiveEntity
launchAgent()
ReactiveMachine
test_board
org.xmloperator.reactive.
Agent
generateActionMessage()
Actions
org.xmloperator.reactive.element.impl.
ParentElementImpl
 
Element based board
Reading the board at initialisation and writing it at closure.
 
Saving and restoring a board
org.xmloperator.reactive.element.action.
ElementAppendAction
 
Actions on elements
org.xmloperator.reactive.test.
CommunityManagerAgent
 
Action_rejection

Last update: 2008-08-30 Copyright (c) 2008 The_xmloperator_project