Connection Machine usage patterns
Contents
- 1 Build your cloud applications directly (Network Applications)
- 2 How to control Data Visibility at Network level with signals
- 3 How to Silence Already active network wide Signals
- 4 How to securely move data with privacy by using channels
- 5 Building 1 to Many Relationships
- 6 Building Many to Many Relationships
- 7 Complex Role based business process
- 8 How is Security by Design Accomplished
- 9 How is Privacy by Design Accomplished
- 10 How is Micro services Accomplished
- 11 How is Secure persistent channels Accomplished
- 12 How can i achieve cascading arithmetic operations
- 13 How can i achieve Decisions in MaterKube Connection Machine?
- 14 Creating pathways with Connection Machine
- 15 Workflows with Connection Machine (Some examples)
- 16 Smart Agents with Connection Machine
- 17 Looping with Connection Machine
- 18 How is horizontal performance scaling achieved with Connection Machine
- 19 How is Network performance scaling achieved with Connection Machine
Build your cloud applications directly (Network Applications)
The two of Applications types are 1. "stand alone application" and 2. "Network based application". Applications on PC's, mainframe and the new age cloud implementations are stand alone applications. I.e the programmer is provided a single machine view (Drawing1 – Single Machine view). Programmer is given a single thread of control which he or she can manipulate in his program and there turn the control back to the caller thread. It is possible that the program spins many threads and does specific tasks on many threads. But the overall control, i.e the caller always sees one main thread (single machine) which hands over control to the calling routine, after it is completed. The program is moved forward by the program counter in the processor or Machine
In this model, even distributed computing is accomplished by controlling it with a single machine view. One of the earliest approach to distributed computing in this model is accomplished by standards like CORBA. Here the distributed object publishes a client version of the method which is then added into the application. During the compile process, the appropriate client libraries are linked to complete the application. So when this program executes the method, the local client library of the ORB implementation gets control. It manages the marshalling of the method and then transfers control to the target machine. It also marshals the answer back to the current application. Notice, how ORB based distributed computing is using one single machine view. Simply put, the stand alone application always does Remote procedural call. Even the SOA implementation of SOAP follows this method.
The network based application (Drawing1 – Network view) is different. In a Network based application, the application control does not work with synchronization from a program counter of a machine, rather it advances when the different components of the program interact with each other.
As depicted in the picture, the network view of application is that it consists of components that needs to be coordinated. In the networked view, the Main application, with the 3 components a.k.a Agents, are placed connected by a Hyperspace (represented by cloud). These agents communicate through this space. The different arrows give the flow of control. The colors depict the complementary interactions. For example, the main agent, is triggered by the triggering action on the inbound arrow (Ask signal in blue represented by 1 ). This is triggered by the outbound arrow (Tell signal in blue represented by 1) from Caller agent. The numbers in the arrow show the sequence in which these interactions happen. Interaction oriented programming, is setting up these potential interactions in complex sequences. MasterKube Connection Machine provides facilities and language to make these networked based applications possible.
There are three fundamental reasons why a new programming paradigm is required:
- With the increasing network and hyperconnected nature of economy it is now mandatory that applications demands are moving away from simple record keeping to coordination of many autonomous entities in the economy (like Digital Supply network, Smart city, Smart factory etc). This calls for new ways of software which can model interactions directly.
- Current programming speeds up when the number of instructions that can be executed per second can increase. But increasingly, due to the physical limitations of semiconductor technology, the clock speed of the processor cannot increase. So the processors are now coming up with multiple cores. But our present programming paradigm i.e standalone application does not have a good way specifying how to coordinate many parallel cores.
- Also with internet and AI(movement from neural network to synaptic network), the applications are increasingly not algorithmic but networked or connected in nature.
How to control Data Visibility at Network level with signals
MasterKube Connection Machine facilitates creation of cloud based network application, by providing facilities to create the TELL and ASK signals. MasterKube connection machine, senses complementary TELL and ASK signals (with the same action name), it will react the two. During this reaction, the values from the TELL goes to the ASK side and the signals disappear. Connection Machine Programming is setting up potential signal interactions , and what further signals follow a interaction.
The two main components of connection machine programming are signal operator and configuration operator. The signal operator , like ASK and TELL sets up the the two potential signals. The Configuration operator, sets up the order in which signal operators become active on a signal interaction. Internal Ask and Internal Tell signals cannot be viewed by an observer. It can only be experienced, if the particular signal instance name is available in an action observed by the user. By hiding signal in an agent, and passing the name pointing to this signal to another agent, visibility of this information. This property of manipulating agent visibility by passing signal names is defined as Name scoping.
Data visibility and control, is illustrated by taking an instance of a customer agent. Agent in MasterKube is the basic unit of information hiding and reuse. In the figure, instances of customer agent are shown. They are identified by two avatars which give identity. In the case of customer agent John Doe, it contains 5 elements and in the case of the other agent Antony it has 4 elements. For these elements to be exposed, the data has be exposed as signals which can be viewed by the observer. Notice the Companyname, in agent JohnDoe. It is still hidden as there are no signals to publish this element.
In the example in the figure, there are 3 actions that are defined. Each of these actions exposes the elements that are in the table. For example, the "BalanceException" action publishes CustomerName and Balance. This is now available to be viewed only for the agent JohnDoe. As the customer agent Antony does not have this action, it cannot be viewed by external applications. Infact the "BalanceException" can be organized as an agent so that it can be made available and disappear on trigger. This creates dynamic behavior, a feature that needs to be programmed with present systems. The code for this is given below
first step is to define all the elements for the system
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<Elements>
<Element><elementName>CustomerName</elementName><type>string</type> </Element>
<Element><elementName>CompanyName</elementName><type>string</type> </Element>
<Element><elementName>Address</elementName><type>string</type> </Element>
<Element><elementName>Shiptoaddress</elementName><type>string</type> </Element>
<Element><elementName>Balance</elementName><type>number</type></Element>
</Elements>
Next is to define all the actions
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Actions>
<Action>
<Element>CustomerName</Element>
<Element>Balance</Element>
<ActionName>BalanceExceptions</ActionName>
</Action>
<Action>
<Element>CustomerName</Element>
<Element>Shiptoaddress</Element>
<ActionName>CustomerInfo</ActionName>
</Action>
<Action>
<Element>CustomerName</Element>
<Element>address</Element>
<ActionName>BillToInfo</ActionName>
</Action>
</Actions>
Next is to define all the dynamic piece of the code. This agent takes input CustomerName CompanyNameCompanyNameAddressShiptoaddress. Uses the CustomerName to identify the agent instance. And also exposes signal CustomerInfo,BillToInfo,BillToInfoandBalanceExceptions.
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>CustomerAgent</AgentName>
<ProcessName>CustomerAgent</ProcessName>
<AvatarName>CustomerName</AvatarName>
<Element>CustomerName</Element>
<Element>CompanyName</Element>
<Element>Address</Element>
<Element>Shiptoaddress</Element>
<Element>Balance</Element>
<Compose>
<!-- Tells the Customer Info Action ----->
<Tell> <action> <actionName>CustomerInfo</actionName> </action> </Tell>
<!-- Tells the Billto Info Action ----->
<Tell> <action> <actionName>BillToInfo</actionName> </action> </Tell>
<!-- The balance is greater < 0 then it is an Balance Exception -->
<Decision>
<Expression>Balance < 0</Expression>
<TrueEvent>
<Tell> <action> <actionName>BalanceExceptions</actionName> </action> </Tell>
</TrueEvent>
</Decision>
</Compose>
</Agent>
In the case above the Balance is completely private and will be published only when the balance is less than zero. By judiciously using the signal operators information can be dynamically published on the network.
How to Silence Already active network wide Signals
The ASK signal, allows data to be inputted into the agent. At the time of the ASK, it gives all the value that is available and lets the observer to change the values. Basic checks for the data would be undertaken to ensure that the data input into the system is valid
Besides the way to accept values into the agent, the ASK signal can also be used to turn off transition of state by a TELL signal. To illustrate, use the CustomerAgent as reflected in the Drawing Drawing-2. Here the CustomerAgent with the avatarname "JohnDoe" has an action "CustomerInfo". This is turned on by default when the agent is initiated. Now, silencing of this is accomplished by turning on TELL signal with the name "CustomerInfo". Due to the complementary nature of ASK and TELL, raising ASK signal of "CustomerInfo", makes "CustomerInfo" unobservable. This is because TELL and ASK of "CustomerInfo" reacts making it disappear.
The code in this section shows how this is accomplished. When the customeragent is activated, it has a new action "RemoveCustomerInfo". This happens because the agent composes of 4 concurrently active components. They are 2 Tell signals, a Sequence operation and a decision agent. Because of this the MasterKube engine makes the first action in the Sequence observable. Once the RemoveCustomerinfo is interacted with it will silence "CustomerInfo" signal, because of the turning of the TELL CustomerInfo with the complementary ASK Customerinfo.
Define Elements
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<Elements>
<Element><elementName>CustomerName</elementName><type>string</type> </Element>
<Element><elementName>CompanyName</elementName><type>string</type> </Element>
<Element><elementName>Address</elementName><type>string</type> </Element>
<Element><elementName>Shiptoaddress</elementName><type>string</type> </Element>
<Element><elementName>Balance</elementName><type>number</type></Element>
</Elements>
Define Actions
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Actions>
<Action>
<Element>CustomerName</Element>
<Element>Balance</Element>
<ActionName>BalanceExceptions</ActionName>
</Action>
<Action>
<Element>CustomerName</Element>
<Element>Shiptoaddress</Element>
<ActionName>CustomerInfo</ActionName>
</Action>
<Action>
<Element>CustomerName</Element>
<Element>address</Element>
<ActionName>BillToInfo</ActionName>
</Action>
</Actions>
Define Agents
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>CustomerAgent</AgentName>
<ProcessName>CustomerAgent</ProcessName>
<AvatarName>CustomerName</AvatarName>
<Element>CustomerName</Element>
<Element>CompanyName</Element>
<Element>Address</Element>
<Element>Shiptoaddress</Element>
<Compose>
<!-- Tells the Customer Info Action ----->
<Tell> <action> <actionName>CustomerInfo</actionName> </action> </Tell>
<!-- Turnsoff CustomerInfo by pressing RemoveCustomerInfo ----->
<Sequence>
<Ask> <action> <actionName>RemoveCustomerInfo</actionName> </action> </Ask>
<Ask> <action> <actionName>CustomerInfo</actionName> </action> </Ask>
</Sequence>
<!-- Tells the Billto Info Action ----->
<Tell> <action> <actionName>BillToInfo</actionName> </action> </Tell>
<!-- The balance is greater < 0 then it is an Balance Exception -->
<Decision>
<Expression>Balance<0</Expression>
<TrueEvent>
<Tell> <action> <actionName>BalanceExceptions</actionName> </action> </Tell>
</TrueEvent>
</Decision>
</Compose>
</Agent>
How to securely move data with privacy by using channels
Mobile scope is a unique feature of MasterKube Connection machine. It can be used to safely send information across many agents without the information being used by those agents. This is illustrated in this section with code.
Define elements
This defines all the elements in this system. The most important element is SalaryInfo and GetSalaryDetail. It defines the two elements as of type name for defining the scope. It defines to the system that interactions of type SalaryInfo and GetSalaryDetail are able to be transported from agent to agent thru signals. Absence of this in the elements and being used in the code will make the Agent non-operational.
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<Elements>
<Element><elementName>DateApproved</elementName><type>date</type> </Element>
<Element><elementName>Name</elementName><type>string</type> </Element>
<Element><elementName>Salary</elementName><type>number</type> </Element>
<Element><elementName>SalaryInfo</elementName><type>name</type> </Element>
<Element><elementName>GetSalaryDetail</elementName><type>name</type> </Element>
</Elements>
Define Actions
The signals define how the agents talk to each other and how agents are linked in this signal fabric. The action defines the signal type. It defines what elements will be carried through the signal when complementary signals interact with each other. When an action is received from outside the system, then the values are automatically type checked. This ensures that the values entered are of the right type, there by ensuring system integrity. So for example in the following example, the signal ApprovePayroll ensures the data entered is always of date data type.
In the case of the signal BeginPayroll only Agents that have SalaryInfo will be allowed to be able to be bound to this signal. By ensuring this the system ensures system referential integrity without any programming done for the same.
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<Actions>
<Action> <Element>Name</Element><Element>Salary</Element> <ActionName>GetSalaryDetail</ActionName></Action>
<Action> <Element>GetSalaryDetail</Element> <ActionName>SalaryInfo</ActionName></Action>
<Action> <Element>DateApproved</Element> <ActionName>ApprovePayroll</ActionName></Action>
<Action> <Element>GetSalaryDetail</Element> <ActionName>IntitatePayroll</ActionName></Action>
<Action> <Element>GetSalaryDetail</Element> <ActionName>ApprovedPayroll</ActionName></Action>
<Action> <Element>SalaryInfo</Element> <ActionName>BeginPayroll</ActionName> </Action>
<Action> <Element>SalaryInfo</Element> <ActionName>GenerateNames</ActionName></Action>
</Actions>
Define Employee
Employee autonmous agent define behaviour of an employee i.e what are the signals that this employee autonmous agent exhibit and what happens when an interaction happens. In this code, it publishes the signal GetSalaryDetail and SalaryInfo At the same time there is an Interaction on GenerateNames. Since the signal GenerateNames carry thru it SalaryInfo and it is of type name then it will generate that name of the latest Signal for SalaryInfo which is the last tell in line no 10. This will be communicated through the signal SalaryInfo when it is bound on this.
<?xml version="1.0" encoding="UTF-8"?> 1 <Agent> 2 <AgentName>EmployeeAgent</AgentName> 3 <!--to create an Employee agent-> 4 <ProcessName>Employee</ProcessName> 5 <AvatarName>Name</AvatarName> 6 <Element>Name</Element> 7 <Element>Salary</Element> 8 <Compose> 9 10 <Tell> <action> <actionName>GetSalaryDetail</actionName> </action> <internal>true</internal> </Tell> 11 <Tell> <action> <actionName>SalaryInfo</actionName> </action> </Tell> 12 13 <Tell> <action> <actionName>GenerateNames</actionName> </action> <internal>true</internal> </Tell> 14 <Ask> <action> <actionName>GenerateNames</actionName> </action> <internal>true</internal> </Ask> 15 16 </Compose> 17 18 </Agent>
Define Human Resources personnel
This agent defines the role of Human resources personnel. The agent is started by passign with name into it. This autonomous agent will be identified as HR as specified in the Processname tag (line 02). On the console it will be shown as avatarname in line 03. The body of the agent is composed of a sequence of signals and an agent. The agent is creation of the payroll autonmous agent on hyperspace. At first only signal BeginPayroll will be visible to the outside in this agent. This is because the signal ApprovedPayroll, even though it is active, is hidden. The BeginPayroll will only force bind on employee agent as it has the signal SalaryInfo. The SalaryInfo will move into HR agent. Next it will move the value of GetSalaryDetail into HumanResourcesAgent thru SalaryInfo. Then it will move on to ApprovePayroll and then it will trigger ApprovedPayroll, which will trigger the creation of new payroll agent by passing GetSalaryDetail into it.
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<!--An HR->
01 <AgentName>HR-Agent</AgentName>
02 <ProcessName>HR</ProcessName>
03 <AvatarName>Name</AvatarName>
04 <Element>Name</Element>
05
06 <Compose>
07 <Sequence>
08 <Ask> <action> <actionName>BeginPayroll</actionName> </action> </Ask>
09 <Ask> <element> <elementName>SalaryInfo</elementName> </element> </Ask>
10 <Ask> <action> <actionName>ApprovePayroll</actionName> </action> </Ask>
11 <Tell> <action> <actionName>ApprovedPayroll</actionName> </action> <internal>true</internal> </Tell>
12 </Sequence>
13
14 <AgentCommand>
15 <AgentName>PayrollAgent</AgentName>
16 <Ask> <action> <actionName>ApprovedPayroll</actionName> </action> <internal>true</internal> </Ask>
17 </AgentCommand>
18
19 </Compose>
20 </Agent>
Define Payroll Agent
The purpose of this is not to show case payroll, but is to showcase how the name and salary are confidentially transfered from the employee agent to the payroll agent through the HR agent. All this is accomplished by the passing the channel GetSalaryDetail thru different interactions and finally arriving at the payroll agent.
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<!--Payroll->
01 <AgentName>PayrollAgent</AgentName>
02 <ProcessName>HR</ProcessName>
03 <AvatarName>Name</AvatarName>
04 <Element>GetSalaryDetail</Element>
05
06 <Sequence>
07 <Ask> <element> <elementName>GetSalaryDetail</elementName> </element> </Ask>
08 </Sequence>
09 </Agent>
Building 1 to Many Relationships
Systems in MasterKube connection machine is a hyperspace of autonomous agents suspended in connective fabric. These agents are autonomous and the links may appear and disappear at runtime, as specified by the agent code. For eg. It is possible to code smart customer autonomous agents that simply withdraw (because of say outstanding balances), from being binding with order autonomous agent. Or better yet, the order will be taken but the customer autonomous agent will be able to tell the order autonomous agent to grow a signal/synapse to identify this particular order autonomous agent as on hold due to credit reasons. This way orders that are on hold for credit reasons can be identified easily and addressed. All these different possibilities can be expressed with Autonomous agent based system.
In this section,1 to many relationships is explained. The picture is on the right is illustrating an example of a Course-instructor relationship. In this case, the relationship between the English and Maths courses is connected to instructor John. This relationship is indicated by the signal/synapse/channel TeacherInfo.The channel TeacherInfo is the way information like name and age is shared by the Instructor agent. When the TaughtBy synapse is interacted with in English and Maths courses, it responds with Teacherinfo. In the picture above, both Maths and English course points to the same instructor i.e John, it indirectly points to Teacherinfo thru PtrForTeacherinfo. Notice that the Agent Mary and antony is not connected to anything yet.
The code and how the Autonomous agent fabric code configuration and its exact working is listed below:
Define Elements:
This defines all the elements in the system. Elements of type name Teacherinfo and canTeach define channel names it is used to send signals across agents. It also keeps relationships between agents.
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<Elements>
<Element><elementName>name</elementName><type>string</type> </Element>
<Element><elementName>age</elementName><type>number</type> </Element>
<Element><elementName>Teacherinfo</elementName><type>name</type> </Element>
<Element><elementName>PtrForTeacherinfo</elementName><type>name</type> </Element>
<Element><elementName>canTeach</elementName><type>name</type> </Element>
</Element>
Define Actions:
The actions define what the signal types are going to be. for example the action TeacherInfo will carry through it Name and Age. It will make sure that when a bind happens on this signal these values are available thru this signal, ensuring the atomic nature of signal interactions. In the case below
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Actions>
<Action><Element>PtrForTeacherinfo</Element><ActionName>CanTeach</ActionName></Action>
<Action><Element>PtrForTeacherinfo</Element><ActionName>TaughtBy</ActionName></Action>
<Action><Element>Teacherinfo</Element><ActionName>PtrForTeacherinfo</ActionName></Action>
<Action><Element>Name</Element><Element>age</Element><ActionName>Teacherinfo</ActionName></Action>
<Action><Element>canTeach</Element><ActionName>Teaches</ActionName></Action>
</Actions>
The Ask signals of type CanTeach and TaughtBy will make sure it always bind atomically with a agent that has the PtrForTeacherinfo synapse. The Tell signals of the same will point to an agent that has Teacherinfo synapse. This way the tell signal does relationships.
Define CourseAgent:
This is the agent that manages the course. When it is created the course is passed to it. The course gives the name of the course which is assigned when the course is created. It consist of an agent which repeats to add many Instructors for this course. The agent can repeat many times leading to one to many reference.
<?xml version="1.0" encoding="UTF-8"?> 01 <Agent> 02 <AgentName>CourseAgent</AgentName> 03 <ProcessName>CourseAgent</ProcessName> 04 <AvatarName>Course</AvatarName> 05 <Element>Course</Element> 06 <Compose> 07 <AgentCommand> <AgentName>AddInstructorAgent</AgentName> </AgentCommand> 08 </Compose> 09 </Agent>
Define AddInstructorAgent:
This agent adds instructors for this course. The teaches action, binds to the signal canteach. Since this signalcanteach is available only in Instructor agent. It will always bind to this agent. On binding, this will grow a signal TaughtBy. This TaughtBy points to a pointer to TeacherInfo by indirectly pointing to PtrForTeacherinfo. This agent repeats many times leading to the growth of many TaughtBy there by giving 1 to many relationships.
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>AddInstructorAgent</AgentName> <?xml version="1.0" encoding="UTF-8"?>
01 <Sequence>
02 <Replicate>
03 <Compose>
04 <Sequence>
<!-- It shows the action Teaches. Remember this is in a replicate and hence it create
multiple instances of the same agent. having its own private space On recieving
Teaches Interaction it triggers AddTaughtbyLink and it creates a TaughtBy action.
There by establishing the link to action TeacherInfo -->
05 <Ask> <action> <actionName>Teaches</actionName> </action> </Ask>
06 <Tell> <action> <actionName>AddTaughtByLink</actionName> </action> <internal>true</internal> </Tell>
07 </Sequence>
08 <Sequence>
09 <Ask> <action> <actionName>AddTaughtByLink</actionName> </action> <internal>true</internal> </Ask>
10 <Ask> <element> <elementName>canTeach</elementName> </element> <internal>true</internal> </Ask>
11 <Tell> <action> <actionName>TaughtBy</actionName> </action> </Tell>
12 </Sequence>
13 </Compose>
14 </Replicate>
15 <Compose>
<!-- Because the sequence are in compose the whole node collapses into one node.
This triggers this node as it is in compose and it triggers the same agent again.
There by displaying the action Teaches in a persistent manner. But this time
it is creating a new instance. So when a new teach is taken it creates a new agent and
a new storage private storage structure. There by creating two instances there by
establishing the 1:m relationship. -->
16 <Tell> <action> <actionName>AddNextInstructor</actionName> </action> <internal>true</internal> </Tell>
17 <AgentCommand>
18 <AgentName>AddInstructorAgent</AgentName>
19 <Ask> <action> <actionName>AddNextInstructor</actionName> </action> <internal>true</internal> </Ask>
20 </AgentCommand>
21 </Compose>
22 </Sequence>
23 </Agent>
Define Instructor Agent:
This defines the course. Each time a course is added, it is passed the CourseName to the Instructor. It publishes the signal TeacherInfo as given in line 08.
01 <?xml version="1.0" encoding="UTF-8"?> 02 <Agent> 03 <AgentName>InstructorAgent</AgentName> 04 <ProcessName>Instructor</ProcessName> 05 <AvatarName>CourseName</AvatarName> 06 <Compose> 07 <!-- Publishes the Teacherinfo action. This contain informaiton about instructor--> 08 <Tell> <action> <actionName>Teacherinfo</actionName> </action> </Tell> 09 <!-- This is a server agent that publishes the name Teachinfo through the canTeach channel --> 10 <AgentCommand> <AgentName>ServeTeachInfoAgent</AgentName> </AgentCommand> 11 </Compose> 12 </Agent>
Define ServeTeachInfoAgent:
This is a Agent that is running in parallel in InstructorAgent and it offers the signal canTeach. It continues to serve this one after the other. This is because canTeach signal interaction is in sequence with AddInstructorAgent. The canTeach does not directly point to TeacherInfo but points to it thru PtrForTeacherinfo. There are two advantages by doing it indirectly 1) It simplifies coding in ServeTeachInfoAgent by avoiding Replicate in this agent to store it in the Connection Machine. 2) It is simple to turn off PtrForTeacherinfo and there by adding easily the GDPR forgetful features and 3) The link between PtrForTeacherinfo and TeacherInfo is fixed and hence can be cached at the browser or at intermediate cache there by reducing the network latency of your application.
<?xml version="1.0" encoding="UTF-8"?>
01 <Agent>
02 <AgentName>ServeTeachInfoAgent</AgentName>
03 <Compose>
04 <Tell> <action> <actionName>PtrForTeacherinfo</actionName> </action> <internal>true</internal></Tell>
05 <Sequence>
06 <!--- The canTeach action contains Teacherinfo. By serving the action canTeach, it is sharing
07 the Teacherinfo with the course agent -->
08 <Tell> <action> <actionName>canTeach</actionName> </action> </Tell>
09 <AgentCommand> <AgentName>AddInstructorAgent</AgentName> </AgentCommand>
10 </Sequence>
11 </Compose>
12 </Agent>
In MasterKube Connection machine, relationships are built by growing a signal or synapse to illustrate the relationships.
Building Many to Many Relationships
The Many to many relationships can be directly modelled on the Connection machine. How this is done is explained with a author and book relationship.
The different agents and the interactions which make this possible are given in the picture to the right. 1 to many relationship from both sides of the entities, will result in a many to many relationship. In the above case of a book to author relationship, it is natural to have many books written by one author or one book written by many authors. The dotted arrow line represents the relationship. The red dotted lines represent a single author who has many books and the orange line represents many authors for a single book. The channel based relationship builder championed by MasterKube makes this easily achievable.
The books "Bourne Identity" and "Bourne Supremacy" have one author i.e Robert Ludlum. But the book Design Patterns" have 4 authors. Growing signal/synapse AuthorInfo at the right books makes the connection to the authors. For example in the case of books, navigating the Authors synapes/signals of "Bourne Identity" and "Bourne Supremacy" responds back with the connection to the Robert Ludlum AuthorInfo synapse. Navigating the AuthorInfo synapse/channel/signal will lead to more information on the author Name and Age. I,e it represents 1 to many relationship. The book "Design Pattern" has 4 authors, so when navigating the Authors signal, it will lead to 4 instances of AuthorInfo which will point back to all the four authors.
The Autonomous agent fabric code configuration that grows this many to many relationship synapse is given below:
Define Elements:
This defines all the elements in the system. Elements of type name AuthorInfo and ActiveAuthor define channel names it is used to send signals across agents. It also keeps relationships between agents.
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<Elements>
<Element><elementName>name</elementName><type>string</type> </Element>
<Element><elementName>age</elementName><type>number</type> </Element>
<Element><elementName>AuthorInfo</elementName><type>name</type> </Element>
<Element><elementName>PtrToAuthorInfo</elementName><type>name</type> </Element>
<Element><elementName>ActiveAuthor</elementName><type>name</type> </Element>
</Element>
Define Actions:
The actions define what the signal types are going to be. for example the action AuthorInfo will carry through it Name and Age. When navigation is done on this signal these values will be returned. Each signal is defined by the action tag. So when an interaction is done on a signal, the Connection machine will ensure that on that signal only values that are mentioned in Action is inputed. This makes the complete system observes type safe behavior. For example when the signal AddAuthor is taken it will make sure only authors are inputted thru this.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Actions>
<Action>
<Element>AuthorInfo</Element>
<ActionName>PtrToAuthorInfo</ActionName>
</Action>
<Action>
<Element>PtrToAuthorInfo</Element>
<ActionName>ActiveAuthor</ActionName>
</Action>
<Action>
<Element>ActiveAuthor</Element>
<ActionName>AddAuthor</ActionName>
</Action>
<Action>
<Element>ActiveAuthor</Element>
<ActionName>Authors</ActionName>
</Action>
<Action>
<Element>Name</Element> <Element>age</Element>
<ActionName>AuthorInfo</ActionName>
</Action>
</Actions>
The Ask signals of type AddAuthor will make sure it always bind atomically with a agent that has the ActiveAuthor synapse. The Tell signals on Authors will point to an agent that has AuthorInfo synapse. This way the tell signal does relationships.
Define BookAgent:
This is the agent that manages the Book Information. Each entity of the book will have an agent. When it is created the Book is passed to it. The BookName gives the name of the Book which is assigned when the Book is created. It consist of an agent which repeats to add many Authors for this Book. The agent can repeat many times leading to one to many reference.
01 <?xml version="1.0" encoding="UTF-8"?> 02 <Agent> 03 <AgentName> BookAgent</AgentName> 04 <ProcessName>BookAgent</ProcessName> 05 <AvatarName>BookName</AvatarName> 06 <Element>BookName</Element> 07 <Compose> 08 <AgentCommand> <AgentName>AddAuthorAgent</AgentName> </AgentCommand> 09 </Compose> 10 </Agent>
Define AddAuthorAgent:
This agent adds Auhors for this Book. The AddAuthor action, binds to the signal ActiveAuthor. Since this signal ActiveAuthor is available only in Author agent. It will always bind to this agent. On binding, this will grow a signal Authors. This Authors points to a pointer to AuthorInfo by indirectly pointing to ActiveAuthor. This agent repeats many times leading to the growth of many Authors there by giving Many to many relationships.
01 <?xml version="1.0" encoding="UTF-8"?> 02 <Agent> 03 <AgentName>AddAuthorAgent</AgentName> 04 <Sequence> 05 <Replicate> 06 <Compose> 07 <Sequence> 08 <!-- It shows the action Author. Remember this is in a replicate and hence it create 09 multiple instances of the same agent. having its own private space On recieving 10 A Interaction it triggers AddAuthorLink and it creates a Authors action. 11 There by establishing the link to action AuthorInfo --> 12 <Ask> <action> <actionName>AddAuthor</actionName> </action> </Ask> 13 <Tell> <action> <actionName>AddAuthorLink</actionName> </action> 14 <internal>true</internal> </Tell> 15 </Sequence> 16 <Sequence> 17 <Ask> <action> <actionName>AddAuthorLink</actionName> </action> 18 <internal>true</internal> </Ask> 19 <Ask> <element> <elementName>ActiveAuthor</elementName> </element> 20 <internal>true</internal> </Ask> 22 <Tell> <action> <actionName>Authors</actionName> </action> </Tell> 23 </Sequence> 24 </Compose> 25 </Replicate> 26 <Compose> 27 <!-- Because the sequence are in compose the whole node collapses into one node. 28 This triggers this node as it is in compose and it triggers the same agent again. 29 There by displaying the action Authors in a persistent manner. But this time 30 it is creating a new instance. So when a new AddAuthor is taken it creates a new agent 31 and a new storage private storage structure. There by creating two instances there by 32 establishing the m:m relationship. --> 33 <Tell> <action> <actionName>AddNextAuthor</actionName> </action> 34 <internal>true</internal> </Tell> 35 <AgentCommand> 36 <AgentName>AddAuthorAgent</AgentName> 37 <Ask> <action> <actionName>AddNextAuthor</actionName> </action> <internal>true</internal> </Ask> 38 </AgentCommand> 39 </Compose> 40 </Sequence> 41 </Agent>
Define AuthorAgent:
This agent Defines the Authors. The AddAuthor action, binds to the signal ActiveAuthor. Since this signal ActiveAuthor is available only in Author agent. It will always bind to this agent. On binding, this will grow a signal Authors. This Authors points to a pointer to AuthorInfo by indirectly pointing to ActiveAuthor. This is accomplished by the agent AddAuthorAgent
01 <?xml version="1.0" encoding="UTF-8"?> 02 <Agent> 03 <AgentName>AuthorAgent</AgentName> 04 <ProcessName>Author</ProcessName> 05 <AvatarName>Name</AvatarName> 06 <Compose> 07 <!-- Publishes the Authorinfo action. This contain informaiton about Author -> 08 <Tell> <action> <actionName>Authorinfo</actionName> </action> </Tell> 09 <!-- This is a server agent that publishes the name Authorinfo through the canTeach 10 channel --> 11 <AgentCommand> <AgentName>AddAuthorAgent</AgentName> </AgentCommand> 12 </Compose> 13 </Agent>
Define AddAuthorAgent:
This agent serves the a reference PtrToActiveAuthor on demand. The request is demanded by the agent that Defines the Authors. The AddAuthor signal in BookAgent, binds to the signal ActiveAuthor to Author as this signal ActiveAuthor is available only in Author agent. On binding, this will grow a signal Authors. This Authors points to a pointer to AuthorInfo by indirectly pointing to PtrToAuthorInfo. This is accomplished by the agent AddAuthorAgent
<?xml version="1.0" encoding="UTF-8"?> 01 <Agent> 02 <AgentName>AddAuthorAgent</AgentName> 03 <Compose> 04 <Tell> <action> <actionName>PtrToActiveAuthor</actionName> </action> </Tell> 05 <Sequence> 06 <!--- The ActiveAuthor action contains Authorinfo. By serving the action ActiveAuthor, it is 07 sharing the Authorinfo with the Bookagent --> 08 <Tell> <action> <actionName>ActiveAuthor</actionName> </action> </Tell> 09 <AgentCommand> <AgentName>AddAuthorAgent</AgentName> </AgentCommand> 10 </Sequence> 11 </Compose> 12 </Agent>
The explanation of how the agents in above code interact to create many to many relationships is given below:
| Interaction Steps | Emitter Synapses (Tell) | Receptor Synapses (Ask) |
BookAgent' & 'AuthorAgent' is active for first time. |
Authorinfo |
AddAuthor |
After interacting on AddAuthor. |
|
|
. |
Authorinfo, ActiveAuthor |
AddAuthorLink(hidden) |
AddAuthorLink(hidden) & Node Collapse |
||
Authorinfo |
AddAuthor, | |
AddNextAuthor interaction |
||
Authorinfo |
AddAuthor |
When the BookAgent and AuthorAgent is activated, the signals in step-1 as above will be grown on the agent. The BookAgent, consists of an agent AddAuthorAgent, which happens persistently. The signal AddAuthor, will show all the agents that have the signal activeauthor. When an interaction happens in the signal AddAuthor, MasterKube ensures that the link is established between BookAgent and AuthorAgent. The instance of type ActiveAuthor is communicated to the BookAgent. The bookagent, thru the ActiveAuthor, grows Authors synapse, which points to Authorinfo thru the intermediary signal PtrToAuthorInfo.
In MasterKube Connection machine, many to many relationships are built by growing synapses.
Complex Role based business process
Business process coordinates behavior of People, Systems, things and devices to produce a business outcome. Business process, is a synaptic network of process components (agents), where these agents, communicate with each other to move process forward.
The picture to the right show how this is accomplished and how the interaction channel (a.k.a synapse) plays a key role in making the process happen. The Leave process is an agent that is spawned, when the leave request synapse in employee node is interacted with. The Leave Management process coordinates HR, Approval and Employee nodes by wiring (represented in the picture by arrows) them in pre-determined fashion through interaction channel (also known as synapse).
In MasterKube, every entity or agent, in this case the leave process, approver, employee and HR are nodes linked together in hyperspace. This inter-agent coordination is achieved by interaction channels (a.k.a synapses) telling different agents to move forward. Each signal in the process, is a hypertext and hence runs on top of the network. Devices can get plugged into this space thru these synapses.
When leaveEntry is interacted with, it allows the user to pick from list of approvers. This is accomplished by showing all agents which have the name ApproverChannel as an active synapse. The selected synapse/channel is sent along with the LeaveEntry to begin the Leave management process. On LeaveEntry interaction, the selected ApproverChannel synapse disappears from the selected approver so it cannot be seen by other LeaveEntry synapses.
The first step of the newly created leave management process agent is to trigger the approval process. This is achieved by signaling the selected approver node, through the ApproverChannel synapse. Through the ApproverChannel synapse, leave particulars and LvApprove and LvDeny synapses travel. The leave management process is waiting on LvApprove and LvDeny synapses to continue with the leave management process. Depending on the selection taken by the approver, either the LvApprove synapse or LvDeny synapse is chosen to move the process forward. The LvApprove is the first synapse in the approval path. The next two synapses (EmpApprove and ApproveHR ) in the approval path of leave management process node, tells the HR and Employee node to continue.
Components in the Business Process Realization
In a typical MasterKube implementation everything is an agent. These agents operate autonomously communicating through the synapses/channels. In the case of leave management process. There are 4 agents. The different agents are AnnualLeaveAgent, EmployeeRoleAgent, ApprovalAgent, and HRAgent. The EmployeeRole, ApprovalAgent and HRAgent are agents that can be turned on depending on the role a particular person is playing. When a user is created, the administrator turns on the different roles so the different services are turned on. The employee role is automatically turned on and its job is to give the capability to request for leave. The whole leave management functionality is the relationships between these agents. Briefly, the different agents and thier role is given below:
This functionality gives the capability to submit leave requests. On completing a leave request, it spawns AnnualLeaveAgent, offering leave request functionality persistently.
This Agent gives the context of a particular leave instance. After the leave is approved or denied this does not have any purpose and hence it disappears. It also has an action which triggers an email or mobile notification. A mobile notification agent listening on this action turns on the notifications.
This agents job is to is to show the capability of a person to be an approver. When an requestor requests all people who have HODRoleAgent turned on will be shown and the leave requests will be routed to this agent. On receivingleave approval requests, this agents job is to show a approve/deny choice option and on pressing one request, the HR and the user is notified.
The functionality of the HR agent is to keep track of all the approved requests. It constantly listens for HR approval requests and then shows it as a list.
MasterKube Code implementation
The different code components are the UserProcess, Agents, Actions and Elements.
Define Elements
The different elements are as follows
<?xml version='1.0' encoding='UTF-8' standalone='yes'?> <Elements> <Element><elementName>EmployeeName</elementName><type>string</type> </Element> <Element><elementName>Age</elementName><type>number</type> </Element> <Element><elementName>LeaveFromdate</elementName><type>date</type> </Element> <Element><elementName>DateOfJoining</elementName><type>date</type> </Element> <Element><elementName>LeaveTodate</elementName><type>date</type> </Element> <Element><elementName>NumberOfDays</elementName><type>number</type> </Element> <Element><elementName>AcceptAnnualLeaveApproval</elementName><type>name</type> </Element> <Element><elementName>NotifyAnnualLeaveApproved</elementName><type>name</type> </Element> <Element><elementName>NotifyAnnualLeaveDenied</elementName><type>name</type> </Element> <Element><elementName>NotifyAnnualLeaveApprovalHR</elementName><type>name</type> </Element> <Element><elementName>ApproveSignal</elementName><type>name</type> </Element> <Element><elementName>DenySignal</elementName><type>name</type> </Element> <Element><elementName>ApproveAnnualLeave</elementName><type>name</type> </Element> <Element><elementName>DenyAnnualLeave</elementName><type>name</type> </Element> <Element><elementName>ShutOffAnnualLeaveApprovals</elementName><type>name</type> </Element> </Elements>
Define Actions
The different actions are as follows
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Actions>
<Action> <Element>LeaveFromdate</Element> <Element>LeaveTodate</Element> <Element>NumberOfDays</Element>
<Element>LeaveReason</Element <Element>ContactNumber</Element>
<Element>AcceptAnnualLeaveApproval</Element>
<ActionName>AnnualLeaveRequest</ActionName>
</Action>
<Action> <Element>EmployeeName</Element> <Element>DepartmentName</Element> <Element>HeadOfDepartmentEmailAddress</Element
<Element>LeaveFromdate</Element> <Element>LeaveTodate</Element> <Element>NumberOfDays</Element>
<Element>LeaveReason</Element> <Element>ContactNumber</Element> <Element>EmployeeInformation</Element>
<Element>ApproveSignal</Element> <Element>DenySignal</Element>
<ActionName>AcceptAnnualLeaveApproval</ActionName>
</Action>
<Action> <Element>LeaveFromdate</Element> <Element>LeaveTodate</Element> <Element>NumberOfDays</Element>
<Element>LeaveReason</Element> <Element>ContactNumber</Element>
<ActionName>NotifyAnnualLeaveDenied</ActionName>
</Action>
<Action> <Element>LeaveFromdate</Element> <Element>LeaveTodate</Element> <Element>NumberOfDays</Element>
<Element>LeaveReason</Element> <Element>ContactNumber</Element>
<ActionName>NotifyAnnualLeaveApproved</ActionName>
</Action>
<Action> <Element>EmployeeName</Element> <Element>DepartmentName</Element> <Element>LeaveFromdate</Element
<Element>LeaveTodate</Element> <Element>NumberOfDays</Element> <Element>LeaveReason</Element>
<Element>ContactNumber</Element>
<ActionName>NotifyAnnualLeaveApprovalHR</ActionName>
</Action>
<Action> <Element>EmployeeName</Element> <Element>DepartmentName</Element>
<Element>LeaveFromdate</Element> <Element>LeaveTodate</Element> <Element>NumberOfDays</Element>
<Element>LeaveReason</Element> <Element>ContactNumber</Element>
<ActionName>SendToPayroll</ActionName>
</Action>
<Action>
<Element>LeaveFromdate</Element> <Element>LeaveTodate</Element> <Element>NumberOfDays</Element>
<Element>LeaveReason</Element> <Element>ContactNumber</Element> <Element>NotifyAnnualLeaveDenied</Element>
<ActionName>DenyAnnualLeave</ActionName>
</Action>
<Action>
<Element>LeaveFromdate</Element> <Element>LeaveTodate</Element> <Element>NumberOfDays</Element>
<Element>LeaveReason</Element> <Element>ContactNumber</Element> <Element>NotifyAnnualLeaveApproved</Element>
<Element>NotifyAnnualLeaveApprovalHR</Element>
<ActionName>ApproveAnnualLeave</ActionName>
</Action>
<Action>
<Element>EmployeeName</Element> <Element>NumberOfDays</Element> <Element>LeaveReason</Element>
<Element>ContactNumber</Element> <Element>ApproveAnnualLeave</Element><Element>DenyAnnualLeave</Element>
<ActionName>AnnualLeaveApprovals</ActionName>
</Action>
<Action>
<Element>ApproveAnnualLeave</Element> <Element>DenyAnnualLeave</Element>
<Element>ShutOffAnnualLeaveApprovals</Element>
<ActionName>GenAnnualLeaveNames</ActionName>
</Action>
</Actions>
Define Agents
The different agents are as follows
Define User Process This defines the user processes. User process is the agent and its synapses/signals created when a user is created through the MasterKube console. This user process can be configured by specifying agents to control behavior. In this instance, it consists of a number of agents that define the user role. For example: The HOD role is assigned by interacting with AssignHODRole
<?xml version="1.0" encoding="UTF-8"?> 01 <Process> 02 <Compose> 03 -- --- --- ----- ---- Rest of Code -- -- -- --- 04 <!-- Do the Admin Role --> 05 <AgentCommand> <AgentName>AdminRoleAgent</AgentName> 06 <Ask><action> <actionName>AssignAdminRole</actionName> </action> </Ask> 07 </AgentCommand> 08 <!-- Apply the Employee Role for this User --> 09 <AgentCommand> <AgentName>EmpRoleAgent</AgentName> 10 <Ask><action> <actionName>AssignEmpRole</actionName> </action></Ask> 11 </AgentCommand> 12 <!-- Apply the HOD Role for this User. This is triggered only when AssignHODRole is pressed by 13 administrator--> 14 <AgentCommand><AgentName>HODRoleAgent</AgentName> 15 <Ask> <action><actionName>AssignHODRole</actionName> </action> </Ask> 16 </AgentCommand> 17 <!-- Apply the HR Role for this User. This is triggered only when AssignHRrole is pressed by administrator--> 18 <AgentCommand><AgentName>HrRoleAgent</AgentName> 19 <Ask> <action><actionName>AssignHRRole</actionName> </action> </Ask> 20 </AgentCommand> 21 </Compose> 22 </Process>
The four agents AdminRoleAgent , EmpRoleAgent , HODRoleAgent and HrRoleAgent that give different roles are running in parallel. Initially when the user is created, it shows the four ( AssignAdminRole, AssignEmpRole,AssignHODRole & AssignHRRole) actions to turn on the different roles. By turning on these roles, the services for each role or the agents for each role are turned on.
Define EmpRoleAgent The purpose of this agent is to do all the functionality of an employee. In this case, it has 3 agents, one doing the annual leave request agent (AnnualLeaveAgent) (Line05), the second one to receive the leave approvals ( LeaveSummaryAccrualAgent ) (Line 08) and 3rd to receive the leave denials (LeaveSummaryDeniedAgent) (Line 09) operate concurrently.
<?xml version="1.0" encoding="UTF-8"?> 01 <Agent> 02 <AgentName>EmpRoleAgent</AgentName> 03 <Compose> 04 <!-- An Employee Role has annual Leave agent capability. This is done by this agent. This agent keeps repeating. --> 05 <AgentCommand> <AgentName>AnnualLeaveAgent</AgentName></AgentCommand> 06 <!-- An Employee has always a leave summary agent. This agents job is to listen for leave approval requests and update the records 07 for this employee. Also agent which would listen to deny requests and create an entry of denied leaves --> 08 <AgentCommand><AgentName>LeaveSummaryAccrualAgent</AgentName></AgentCommand> 09 <AgentCommand><AgentName>LeaveSummaryDeniedAgent</AgentName></AgentCommand> 10 </Compose> 11 </Agent>
The Annual Leave Agent offers the Annual Leave request action persistently. Here on interacting with AnnualLeaveRequest it spawns a new process thru AnnualLeaveProcessAgent. After that it goes on to repeat it over.
<?xml version="1.0" encoding="UTF-8"?> 01 <Agent> 02 <AgentName>AnnualLeaveAgent</AgentName> 03 <Sequence> 04 <!-- Get the Annual Request . --> 05 <AgentCommand> <AgentName>AnnualLeaveProcessAgent</AgentName> 07 <Ask><action> <actionName>AnnualLeaveRequest</actionName> </action> </Ask> 08 </AgentCommand> 09 <!-- Once a leave is applied then this agent repeats recursively for another Sick leave application. --> 10 <AgentCommand><AgentName>AnnualLeaveAgent</AgentName></AgentCommand> 11 </Sequence> 12 </Agent>
LeaveSummaryAccrualAgent agent listens to NotifyAnnualLeaveApproved. On receiving it, adds the leave count and update the approval records . This agent is called persistently offering the LeaveSummaryAccualservice.
The LeaveSummaryAccrualAgent consists of 3 broad parallelly operating pieces of code. One is the recordAnnualLeaveApprovalAgent agent at (line 05) which listens on ChReceiveALApprovedEntry . The other is a sequence block (line 08)that adds number of days and the third (line 42) which triggers the recordAnnualLeaveApprovalAgent. The whole agent waits till NotifyAnnualLeaveApproved before all of these are executed. The moment the NotifyAnnualLeaveApproved is interacted with Line10 it will raise TriggerALApproveRecorder Line14 which will trigger the ChReceiveALApprovedEntry (line 46). Then it will activate the same agent again (Line 49).
<?xml version="1.0" encoding="UTF-8"?> <Agent> 01 <AgentName>LeaveSummaryAccrualAgent</AgentName> 02 <Compose> 03 <!-- Position an agent to record Approvals. This agent will be waiting on 04 ChReceiveALApprovedEntry to receive inputs--> 05 <AgentCommand> <AgentName>RecordAnnualLeaveApprovalAgent </AgentName> 06 </AgentCommand> 07 08 <Sequence> 09 <!-- Accept the annual leave information approval so it can be recorded. --> 10 <Ask> <action><actionName> NotifyAnnualLeaveApproved </actionName> </action> 11 <internal>true</internal></Ask> 12 <!-- Tell the agent to record this leave. It also generates the 13 channel ChReceiveDeniedEntry --> 14 <Tell><action><actionName> TriggerALApproveRecorder </actionName> </action> 15 <internal>true</internal> </Tell> 16 <Sequence> 17 <Compose> 18 <!-- Set up the agent to Add the leave approvals to the leave taken counter. 19 This will trigger when the numberofdays arrives --> 20 <Tell> <action><actionName> NumberOfDays </actionName> </action> 21 <internal> true </internal> </Tell> 22 <Tell> <action><actionName>AnnualLeaveTaken </actionName> </action> 23 <internal> true </internal> </Tell> 24 <ArithmeticAgentCommand> <AgentExpression>AnnualLeaveTaken =AnnualLeaveTaken + 25 NumberOfDays </AgentExpression> </ArithmeticAgentCommand> 26 </Compose> 27 <Compose> 28 <Tell> <action><actionName>AnnualLeaveBalanceForward</actionName> </action> 29 <internal> true </internal></Tell> 30 <Tell> <action><actionName>AnnualLeaveEntitled</actionName> </action> 31 <internal> true </internal> </Tell> 32 <!-- Compute the leave balance after the leave taken amount has changed. --> 33 <ArithmeticAgentCommand> 34 <AgentExpression> AnnualLeaveBalance=AnnualLeaveBalanceForward + 35 AnnualLeaveEntitled - AnnualLeaveTaken</AgentExpression> 36 </ArithmeticAgentCommand> 37 </Compose> 38 </Sequence> 39 </Sequence> 40 41 <Sequence> 42 <!-- Wait till the notification is received. --> 43 <Ask><action> <actionName>TriggerALApproveRecorder</actionName> </action> 44 <internal> true </internal></Ask> 45 <!-- Tell the agent to write a new approval entry. --> 46 <Tell><element><elementName> ChReceiveALApprovedEntry </elementName> </element> 47 <internal> true </internal> </Tell> 48 <!-- Repeat the agent after the computation is triggered so more requests can be received. --> 49 <AgentCommand><AgentName>LeaveSummaryAccrualAgent</AgentName></AgentCommand> 50 </Sequence> 51 52 </Compose> 53 </Agent>
RecordAnnualLeaveApprovalAgent The agent is a sequence that is triggered on ChReceiveALApprovedEntry for approved entries (Line 06) and then it grows the synapse ShowAnnualLeaveApprovedLeaves (Line07)
01 <?xml version="1.0" encoding="UTF-8"?> 02 <Agent> 03 <AgentName>RecordAnnualLeaveApprovalAgent</AgentName> 04 <Replicate> 05 <Sequence> 06 <Ask><action><actionName>ChReceiveALApprovedEntry</actionName> </action> <internal>true </internal> </Ask> 07 <Tell><action><actionName> ShowAnnualLeaveApprovedLeaves </actionName> </action></Tell> 08 </Sequence> 09 </Replicate> 10 </Agent>
Define HODRoleAgentThe purpose of this agent is to do all the functionality of an approver. In this case, it has an agent LeaveApprovalAgent (Line 05). This agent runs as a service. More functionality can be increased by just adding more services as agents to run in compose.
<?xml version="1.0" encoding="UTF-8"?>
01 <Agent>
02 <AgentName>HODRoleAgent</AgentName>
03 <Compose>
04 <!-- PRovides a service that offers a service to approve leave. -->
05 <AgentCommand> <AgentName>LeaveApprovalAgent</AgentName></AgentCommand>
07 <!-- All the other agents can be added here which comprises of the HOD Role Agent services -->
09 - - - - - - - --- --- ---- -----
10 ....................................................................
11 ....................................................................
12 </Compose>
13 </Agent>
The LeaveApprovalAgent does the leave approval at the approval role. It waits on AcceptAnnualLeaveApproval (Line 07) to get leave requests for approval. On receiving it, it opens up a composition of two choices. One being AnnualLeaveApprovals (Line 15) and the other being ApproveAnnualLeave and DenyAnnualLeave (line 25). . The ApproveAnnualLeave and DenyAnnualLeave are hidden and cannot be seen from the outside. AnnualLeaveApprovals is a menu of information, a path for the hidden ApproveAnnualLeave and DenyAnnualLeave actions. On screen this synapse appears as the depicted navigation. At the same time, the sequence node collapses (Line01), and it triggers the compose node (Line 60). It repeats LeaveApprovalAgent and again opens up AcceptAnnualLeaveApproval. In Effect, this works like a micro service.
Through AnnualLeaveApprovals user can navigate to the hidden approve and deny signals. This is possible due to way this signal is defined with a combination showing employee information and also the name pointing to ApproveAnnualLeave (Illustration8). On interacting with ApproveAnnualLeave, it raises 4 synapses in parallel they are ApproveSignal (Line30) telling Leave process agent to proceeed, ShutOffAnnualLeaveApprovals (Line32) shutting of the AnnualLeaveApprovals,NotifyAnnualLeaveApproved (Line17/20) notify employee (Line34) and NotifyAnnualLeaveApprovalHR (Line34) notify hr
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>LeaveApprovalAgent</AgentName>
01 <Sequence>
02 <Replicate>
03 <Compose>
04 <!--The casual leave approval menu is shown in parallel with the controls for leave approval and
05 leave denial. -->
06 <Sequence>
07 <Ask> <action> <actionName>AcceptAnnualLeaveApproval</actionName> </action>
08 <internal>true</internal> </Ask>
09 <Tell> <action> <actionName>GenAnnualLeaveNames</actionName> </action>
10 <internal>true</internal> </Tell>
11 </Sequence>
12 <Sequence>
13 <Ask> <action> <actionName>GenAnnualLeaveNames</actionName> </action>
<internal>true</internal> </Ask>
14 <Compose>
15 <Choice>
16 <ChoiceOption>
17 <Tell> <action> <actionName>AnnualLeaveApprovals</actionName> </action></Tell>
18 <OptionAction> </OptionAction>
</ChoiceOption>
19 <ChoiceOption>
20 <Ask> <action> <actionName>ShutOffAnnualLeaveApprovals</actionName>
21 </action> <internal>true</internal> </Ask>
22 <OptionAction></OptionAction>
23 </ChoiceOption>
24 </Choice>
25 <Choice>
26 <ChoiceOption>
27 <Ask> <action> <actionName>ApproveAnnualLeave</actionName>
</action><internal>true</internal> </Ask>
28 <OptionAction>
29 <Compose>
30 <Tell> <element> <elementName>ApproveSignal</elementName> </element>
<internal>true</internal> </Tell>
32 <Tell><element><elementName>ShutOffAnnualLeaveApprovals</elementName>
33 </element> <internal>true</internal> </Tell>
34 <Tell> <element> <elementName>NotifyAnnualLeaveApproved</elementName>
35 </element> <internal>true</internal> </Tell>
36 <Tell> <element> <elementName> NotifyAnnualLeaveApprovalHR
37 </elementName> </element> <internal> true </internal> </Tell>
38 </Compose>
39 </OptionAction>
40 </ChoiceOption>
41 <ChoiceOption>
42 <Ask> <action> <actionName> DenyAnnualLeave</actionName> </action> <internal>
43 true </internal> </Ask>
44 <OptionAction>
45 <Compose>
46 <Tell> <element> <elementName> ShutOffAnnualLeaveApprovals
47 </elementName> </element> <internal>true</internal> </Tell>
48 <Tell> <element> <elementName>DenySignal</elementName> </element>
49 <internal>true</internal> </Tell>
50 <Tell> <element> <elementName> NotifyAnnualLeaveDenied </elementName> </element>
51 <internal>true</internal> </Tell>
52 </Compose>
53 </OptionAction>
54 </ChoiceOption>
55 </Choice>
56 </Compose>
57 </Sequence>
58 </Compose>
59 </Replicate>
60 <Compose>
61 <Tell> <action> <actionName>TriggerMgr1</actionName> </action> <internal> true</internal> </Tell>
62 <AgentCommand>
63 <AgentName>LeaveApprovalAgent</AgentName>
64 <Ask> <action> <actionName>TriggerMgr1</actionName> </action> <internal> true
65 </internal> </Ask>
66 </AgentCommand>
67 </Compose>
68 </Sequence>
69 </Agent>
The LeaveApprovalAgent does the complete leave processing. It waits on AcceptAnnualLeaveApproval to get leave requests for approval and sends the approval ApproveSignal or deny DenySignal message to move the leave process forward.
Define AnnualLeaveProcessAgent
The purpose of this agent is to keep the context of a leave. The other agents are role based agents. If the leave process itself has a state and control then that is done by this agent. For example if a SendEmailNotification notification has to be send, then it can be the job of this to signal an action so appropriate event agent can read and do its part. The email sending daemon will read this and send the email and shut this off.
<?xml version="1.0" encoding="UTF-8"?> 01 <Agent> 02 <AgentName>AnnualLeaveProcessAgent</AgentName> 03 <ProcessName>AnnualLeave</ProcessName> 04 <AvatarName>EmployeeName</AvatarName> 05 <Element>EmployeeName</Element> 06 <Element>DepartmentName</Element> 07 <Element>HeadOfDepartmentEmailAddress</Element> 08 <Element>LeaveFromdate</Element> 09 <Element>LeaveTodate</Element> 10 <Element>NumberOfDays</Element> 11 <Element>LeaveReason</Element> 12 <Element>EmployeeInformation</Element> 13 <Element>ContactNumber</Element> 14 <Element>AcceptAnnualLeaveApproval</Element> 15 <Compose> 16 <!-- Send email notification to the hod email address --> 17 <Ask><action> <actionName>SendEmailNotification</actionName> </action> </Ask> 18 <Sequence> 19 <!-- TEll the HOD of the arrival of approval. When this is communicated, the approve and deny 20 requests are send along with this channel --> 21 <Tell> <element> <elementName> AcceptAnnualLeaveApproval </elementName> </element> 22 <internal> true </internal> </Tell> 23 <!-- The user process which got hold of the workflow, signals directly from there to Employee and HR 24 if the leave is approved Also signals this process whether to keep track of this or die. --> 25 <Choice> 26 <ChoiceOption> 27 <Ask><action> <actionName>ApproveSignal</actionName> </action> </Ask> 28 <OptionAction> </OptionAction> 29 </ChoiceOption> 30 <ChoiceOption> 31 <Ask> <action> <actionName>DenySignal</actionName> </action> </Ask> 32 <OptionAction> </OptionAction> 33 </ChoiceOption> 34 </Choice> 35 </Sequence> 36 </Compose> 37 </Agent>
Define HRRoleAgentThe purpose of this agent is to report all approvals to the HR. The HR agent listens all the functionality of an approver. The listening is done by the synapse NotifyAnnualLeaveApprovalHR
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>HrRoleAgent</AgentName>
<Compose>
<!-- PRovides a hr service that offers a service to approve leave. -->
<AgentCommand> <AgentName>HRLeaveApprovalAgent</AgentName></AgentCommand>
<!-- All the other agents can be added here which comprises of the HOD Role Agent services -->
- - - - - - - --- --- ---- -----
....................................................................
....................................................................
</Compose>
</Agent>
The above code is the agent that gets turned on when a role is assigned for a user. This agent i.e HrRoleAgent, in turns turns on the agent below HRLeaveApprovalAgent. It is the HRLeaveApprovalAgent that gets all approved leaves. It waits on synapse NotifyAnnualLeaveApprovalHR to do all the stuff that needs to get done on the HR side.
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>HRLeaveApprovalAgent</AgentName>
<Sequence>
<Replicate>
<Compose>
<Sequence>
<!-- Waits on annual leave events reported to HR and then does further actions. -->
<Ask> <action> <actionName>NotifyAnnualLeaveApprovalHR</actionName> </action>
<internal>true</internal> </Ask>
<Tell> <action> <actionName>ApprovalAdvancer</actionName> </action>
<internal>true</internal> </Tell>
</Sequence>
<Sequence>
<Ask> <action> <actionName>ApprovalAdvancer</actionName> </action>
<internal>true</internal> </Ask>
<!-- Records the actions are that to be send to payroll. -->
<Ask> <action> <actionName>SendToPayroll</actionName> </action> </Ask>
</Sequence>
</Compose>
</Replicate>
<Compose>
<!-- Repeats the same agent so it goes on to wait for further HR requests. -->
<Tell> <action> <actionName>TriggerMgrHRAL</actionName> </action> <internal> true
</internal> </Tell>
<AgentCommand>
<AgentName>HRLeaveApprovalAgent</AgentName>
<Ask> <action> <actionName>TriggerMgrHRAL</actionName> </action> <internal> true
</internal> </Ask>
</AgentCommand>
</Compose>
</Sequence>
</Agent>
How does all these agents work together to create the process?
To begin with let us assume that all the agents are active. The table below gives all synapses at the time of agent initiation. The signals/synapses AnnualLeaveRequest, ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden) appear/grow on EmpRoleAgent. The synapses TriggerALApproveRecorder(hidden) grow on HODRoleAgent agent. The synapses NotifyAnnualLeaveApprovalHR(hidden), ApprovalAdvancer(hidden) grow on HRRoleAgent.
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
All roles EmpRoleAgent, HODRoleAgent, RecordAnnualLeaveApprovalAgent and HRRoleAgent is active. |
--- Nothing is active --- |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden), TriggerALApproveRecorder(hidden),AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), NotifyAnnualLeaveApprovalHR(hidden),ApprovalAdvancer(hidden) |
After the annualLeaveRequest action is taken it spawns a new instance of AnnualLeaveProcessAgent. All action in the AnnualLeaveRequest is passed into the AnnualLeveProcessAgent instance. The action AnnualLeaveRequest repeats again as AnnualLeaveAgent (Line 10 in AnnualLeaveAgent) is activated again. The first signal that is grown in the AnnualLeaveProcessAgent is the synapse AcceptAnnualLeaveApproval.
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
On Interacting with AnnualLeaveRequest. |
AcceptAnnualLeaveApproval |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden), TriggerALApproveRecorder(hidden),AcceptAnnualLeaveApproval(hidden), GenAnnualLeaveNames(hidden),NotifyAnnualLeaveApprovalHR(hidden),ApprovalAdvancer(hidden) ApproveSignal(hidden), Denysignal(hidden) |
On AcceptAnnualLeaveApproval Interaction | ||
Grows GenAnnualLeaveNames |
GenAnnualLeaveNames(hidden) |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden), TriggerALApproveRecorder(hidden), AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), NotifyAnnualLeaveApprovalHR(hidden),ApprovalAdvancer(hidden) ApproveSignal(hidden), Denysignal(hidden) |
The AnnualLeaveRequest has AcceptAnnualLeaveApproval as an element in the action definitions. This ensures that the AnnualLeaveRequest always picks a appproval instance when this interaction happens. This is passed as parameter (Line 14) to the AnnualLeaveProcessAgent instance. The first step of this agent is to trigger approval using the synapse AcceptAnnualLeaveApproval (Line 21 of AnnualLeaveProcessAgent). when this interaction happens it grows the synapse GenAnnualLeaveNames. The synapses GenAnnualLeaveNames bind the synapses as shown below become active. The AcceptAnnualLeaveApproval is open again to accept approvals because of the node collapse.
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
On Interacting with GenAnnualLeaveNames and also the node collapses to show the AcceptAnnualLeaveApproval |
AnnualLeaveApprovals |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden), TriggerALApproveRecorder(hidden),AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), NotifyAnnualLeaveApprovalHR(hidden),ApprovalAdvancer(hidden) ApproveSignal(hidden), Denysignal(hidden), ShutOffAnnualLeaveApprovals(hidden),ApproveAnnualLeave(hidden),DenyAnnualLeave(hidden) |
The LeaveApprovalAgent In HOD Role to which the Approval request was send thru the AcceptAnnualLeaveApproval (Line 07) will now grow AnnualLeaveApprovals synapse (Line 17). This accomplished with two choice signal operators in parallel. (Line 15 and 25). The choice of ApproveAnnualLeave and DenyAnnualLeave is hidden and will not be visible. But the AcceptAnnualLeaveApproval (Line 07) consists of employee information and it has elements that point to ApproveAnnualLeave and DenyAnnualLeave. This way the AnnualLeaveApprovals behaves like a menu, by letting the user walk thru to these hidden signals. These hidden names are generated by GenAnnualLeaveNames at (line 09). The AnnualLeaveApprovals is in choice with a hidden ShutOffAnnualLeaveApprovals as a way to shut off AnnualLeaveApprovals, when either ApproveAnnualLeave or DenyAnnualLeave are interacted with after navigating thru AnnualLeaveApprovals. The next table gives what happens when this ApproveAnnualLeave is interacted with.
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
On navigating through AnnualLeaveApprovals and then interacting with ApproveAnnualLeave |
AnnualLeaveApprovals, ApproveSignal, ShutOffAnnualLeaveApprovals(hidden), NotifyAnnualLeaveApproved, NotifyAnnualLeaveApprovalHR |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden),TriggerALApproveRecorder(hidden) ,AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), NotifyAnnualLeaveApprovalHR(hidden),ApprovalAdvancer(hidden), ShutOffAnnualLeaveApprovals(hidden),ApproveSignal, Denysignal |
On interaction of ShutOffAnnualLeaveApprovals and approve signal |
NotifyAnnualLeaveApproved, NotifyAnnualLeaveApprovalHR |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden),TriggerALApproveRecorder(hidden), AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), NotifyAnnualLeaveApprovalHR(hidden),ApprovalAdvancer(hidden) |
On Interaction of NotifyAnnualLeaveApprovalHR |
NotifyAnnualLeaveApproved,ApprovalAdvancer(hidden) |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden),TriggerALApproveRecorder(hidden), AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), NotifyAnnualLeaveApprovalHR(hidden),ApprovalAdvancer(hidden) |
On Interaction of ApprovalAdvancer |
NotifyAnnualLeaveApproved |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), NotifyAnnualLeaveApproved(hidden),TriggerALApproveRecorder(hidden), AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), NotifyAnnualLeaveApprovalHR(hidden),SendToPayroll |
When NotifyAnnualLeaveApporvalHR is pressed, it grows the final SendToPayRoll action in the right HR group. This completes the whole flow in HR. Since Connection Machine is concurrently operating system, the employee side of the equation operates concurrently.The Sequence table below, shows all actions on interaction of NotifyAnnualLeaveApproved. The action NotifyAnnualLeaveApproved, is the action that notifies the employee of the leave approval. When this is done it records this leave approval and also computes the leave balance and adds to the leave consumed. These interactions are now located in the agent LeaveSummaryAccrualAgent
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
On interaction of NotifyAnnualLeaveApproved |
TriggerALApproveRecorder(hidden) |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), TriggerALApproveRecorder(hidden),AcceptAnnualLeaveApproval(hidden), GenAnnualLeaveNames(hidden),NotifyAnnualLeaveApprovalHR(hidden), SendToPayroll |
Interaction of TriggerALApproveRecorder |
|
|
Triggers the Computation Node to compute AnnualLeaveTaken & AnnualLeaveBalance |
ChReceiveALApprovedEntry |
AnnualLeaveRequest,ChReceiveALApprovedEntry(hidden), AcceptAnnualLeaveApproval(hidden), GenAnnualLeaveNames(hidden),NotifyAnnualLeaveApprovalHR(hidden),SendToPayroll |
Interaction of ChReceiveALApprovedEntry |
|
|
Triggers the Computation Node to compute AnnualLeaveTaken & AnnualLeaveBalance |
ShowAnnualLeaveApprovedLeaves |
AnnualLeaveRequest,AcceptAnnualLeaveApproval(hidden),GenAnnualLeaveNames(hidden), |
When NotifyAnnualLeaveApproved is triggered, it triggers TriggerALApproveRecorder action. This triggers three activities, one is to Begin the computation, next is to trigger (ChReceiveAlApprovedEntry) the record of the transaction and the other is repeat this agent so that NotifyannualLeaveApprovalHR is triggered again. Triggering the write creates the action ShowAnnualLeaveApprovedLeaves.
How is Security by Design Accomplished
How can i use MasterKube connection machine to build applications that have Security by Design
How is Privacy by Design Accomplished
How can i use MasterKube connection machine to build applications that have Privacy by Design
How is Micro services Accomplished
How can i use MasterKube connection machine to build Micro services?
How is Secure persistent channels Accomplished
What is the purpose of secure persistent channels and how is it accomplished in MasterKube connection machine?
How can i achieve cascading arithmetic operations
Mention the arithmetic operations. Say how MK CM mentions it. Then say how cascading arithmetic agents are accomplished. Leading to realtime just in time arithmetic operations. How can it be accomplished in MasterKube Connection Machine.
How can i achieve Decisions in MaterKube Connection Machine?
Mention the the unique approach to decision making and tell how it is parallel operations with an example.
Creating pathways with Connection Machine
Mention what a pathway is. How it appears to he humans as a interaction pathway. This applies to machines and other algorithms. Mention the advantage of doing it this way. With a analogy with Human central nervous cell signaling.
Workflows with Connection Machine (Some examples)
Workflow is how different agents are coordinated. Most of these workflow patterns are available at workflow patterns. A few of these patterns are chosen and is explained how it is implemented with MasterKube Connection Machine programming Language. MasterKube connection language does not differentiate between people, processes or devices. Everything is represented as interactions.
Some of the patterns are chosen because they are supported by all workflow or Business process management tools. One pattern in particular i.e Discriminator pattern, is chosen as it is now not supported by any of the current implementations.
Simple Merge
Exclusive Merge is the concept of a workflow where the convergence of two or more branches into a single subsequent branch such that each enablement of an incoming branch results in the thread of control being passed to the subsequent branch. An example for this is After the case-payment or provide-credit tasks, initiate the product-receipt task.
More information above Simple Merge is available [here]
MasterKube Code
Only the agents are specified as the elements and what action has what elements are not relevant to show the interaction patterns and how it accomplishes the Simple Merge Workflow Pattern. This is illustrated with the following Functionality. Whenever a payment is made or when credit is granted then the product receipt is printed. In this workflow pattern, the control flows from two threads of control and moves to a single thread of control i.e Product receipt.
01 <?xml version="1.0" encoding="UTF-8"?> 02 <Agent> 03 <AgentName>SimpleMergeAgent</AgentName> 04 <Choice> 05 <ChoiceOption> 06 <Ask><action><actionName>Case-Payment</actionName></action></Ask> 07 <OptionAction> 08 <Tell><action><actionName>Product-Recipt</actionName></action></Tell> 09 </OptionAction> 10 </ChoiceOption> 11 <ChoiceOption> 12 <Ask><action><actionName>provide-credit </actionName></action></Ask> 13 <OptionAction> 14 <Tell><action><actionName>Product-Recipt</actionName></action></Tell> 15 </OptionAction>< 16 </ChoiceOption> 17 </Choice> 18 </Agent>
Code Explanation
The fundamental objective of the SimpleMergeAgent is to trigger product-receipt when either Case-Payment or Provide-Credit is interacted with.
The explanation of how the agents in above code interact to create many to many relationships is given below:
| Interaction Steps | Active Tell Signals Synapses |
Active Ask Signals Synapses |
ExclusiveMergeAgent is active. |
|
Case-Payment |
After interacting on Case-Payment. |
|
|
Product-Recipt |
This signifies the interaction on Case-Payment. Case-payment and Provide-Credit is always active on the ASK side. So when Case-Payment synapse is interacted with it triggers the first choice and then triggers the tell on Product-Receipt I.e it tells the process which is waiting on Product-Receipt to continue the process.
The explanation of how the agents in above code interact to create many to many relationships is given below:
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
ExclusiveMergeAgent is active. |
|
Case-Payment |
After interacting on Provide-Credit. |
|
|
|
Product-Recipt |
This signifies the interaction on Provide-Credit. Case-payment and Provide-Credit is always active on the ASK side. So when Provide-Credit synapse is interacted with it triggers the first choice and then triggers the tell on Product-Receipt I.e it tells the process which is waiting on Product-Receipt to continue the process.
Structured Discriminator Pattern
Structured Discriminator Pattern is the convergence of two or more branches into a single subsequent branch following a corresponding divergence earlier in the process model such that the thread of control is passed to the subsequent branch when the first incoming branch has been enabled. Subsequent enablement of incoming branches do not result in the thread of control being passed on. [This link depicts it pictorially]
One of the reasons this is picked is because of the lack of support of this pattern in most of the current tools available commercially and in open source. MasterKube is the only technology which can support this directly.
An Example is as follows. When handling a cardiac arrest, the check_breathing and check_pulse tasks run in parallel. Once the first of these has completed, the triage task is commenced. Completion of the other task is ignored and does not result in a second instance of the triage task.
MasterKube Code
Only the agents are specified as the elements and what action has what elements are not relevant to show the interaction patterns and how it accomplishes the Structured Discriminator Workflow Pattern. This is illustrated with the cardiac arrest work flow. Whenever a cardiac_arrest is raised, then first check_breathing and Check_pulse has to be done in parallel and on completion of any of this task it can trigger the Triage. I.e it does not have to wait for both to complete
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>HearAttackAgent</AgentName>
<Sequence>
<Ask><action><actionName>cardiac_arrest</actionName></action></Ask>
<Choice>
<ChoiceOption>
<Ask><action><actionName>Check_breathing_done</actionName></action></Ask>
<OptionAction>
<Tell><action><actionName>Triage</actionName></action></Tell>
</OptionAction>
</ChoiceOption>
<ChoiceOption>
<Ask><action><actionName> Check_pulse_done</actionName></action></Ask>
<OptionAction>
<Tell><action><actionName>Triage</actionName></action></Tell>
</OptionAction>
</ChoiceOption>
</Choice>
</Sequence>
</Agent>
Parallel Split Pattern
Parallel split pattern is defined as the divergence of a branch into two or more parallel branches each of which execute concurrently. More information of how this will work is available [here].
An example of this is as follows. a) After completion of the capture enrolment task, run the create student profile and issue enrolment confirmation tasks simultaneously, b) When an intrusion alarm is received, trigger the despatch patroltask and the inform police task immediately or c) Once the customer has paid for the goods, pack them and issue a receipt.
MasterKube Code
Only the agents are specified as the elements and what action has what elements are not relevant to show the interaction patterns and how it accomplishes the Parallel Split Workflow Pattern. This is illustrated with the student student enrolment process. This student enrolment process is defined as signalling StudentProfile and enrolment confirmation after receiving the signal Issue
enrolment confirmation.
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>ParallelSplitAgent</AgentName>
<Sequence>
<Ask><action><actionName>Student_entrolment</actionName></action></Ask>
<Compose>
<Tell><action><actionName>StudentProfile</actionName></action></Tell>
<Tell><action><actionName>enrollmentConfirmation</actionName></action></Tell>
</Compose>
</Sequence>
</Agent>
Code Explanation
The fundamental objective of the ParallelSplitAgent is to trigger studentprofile and enrollmentconfirmation after it is signalled with student enrollment. The exact mechanics of how this happens as interactions in MasterKube is given below.
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
ParallelSplitAgent is active. |
|
Student_entrolment |
After interacting on student_enrollment. |
|
|
Studentprofile |
Parallel Join Pattern
Parallel join pattern is defined as the convergence of one or more parallel branches to one branch. After completion of the order_materials task, and Book_labourer then signal quality_review.
MasterKube Code
Only the agents are specified. The elements and the particular elements each action has are not relevant to show the interaction patterns and how it accomplishes the Paralllel Join Workflow Pattern. A simple workflow that signals quality_review after completion of the order_materials task and Book_labourer is used to illustrate this.
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>ParallelJoinAgent</AgentName>
<Sequence>
<Ask><action><actionName>order_materials</actionName></action></Ask>
<Ask><action><actionName>Book_labourer</actionName></action></Ask>
<Tell><action><actionName>quality_review</actionName></action></Tell>
</Sequence>
</Agent>
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
ParallelJoinAgent is active. |
|
order_materials |
After interacting on Order_materials.. |
|
|
|
Book_labourer | |
After Interacting on Book_labourer. |
|
|
|
Quality_Review |
|
When the agent is activated. i.e ParallelJoinAgent, it exposes order_materials., when order_materials is triggered, it triggers Book_labourer. After interacting with Book_Labourer it raises Quality_review.
Smart Agents with Connection Machine
Real time operation is the property of applications by which the computer responds as rapidly as required by the user or necessitated by the process being controlled. One of the advantages of moving from algorithmic based systems to interaction based systems is the way in which the computer systems responds quickly to the stimuli.
This is fundamentally difficult to achieve in the traditional applications because of the sequential and input/output nature of the applications. Let us take the instance of invoice aging and illustrate how the invoice aging is done now and how it will be done with MasterKube and then it will be obvious how the difference in approach to information, lead to systems that are operating in real time.
Invoice aging is a metric, that show how fast invoices are being paid. For exmple, in the case above, the Inv1 and inv2 are aged at 30 days and the inv3 is aged at 60 days. Because of the duedate, the different invoices have different aging days and hence is classified into different aging buckets (eg: bucket of invoices over 30 days and bucket of invoices over 60 days).
The current approach is to build a program which would sift through all the outstanding invoices. By looking at the current date and due date, it decides which bucket the appropriate invoice belongs and the balance is added to that bucket. As the number of outstanding invoices increase so also the processing time it takes to create this invoice aging. This makes the algorithms based systems not real time.
The MasterKube approach to information is different. Each invoice is an agent which has its own behavour and it operates autonomously. I.e it changes its behavour at runtime depending on the state of the invoice. So on the day when the invoice becomes overdue, it turns on OverDue action. And when the invoice becomes overdue more than 30 days then it turns on the Over30Days action. At the same time it turns off the OverDue action. When the invoice goes past 60 days then it turns off Over30Days and turns on Over60Days.
Timer Agent in MasterKube, simulates the passage of time. It works as a alarm clock service. With the timer agent, it is possible to regiser an action and the date on which this action has to be triggered. On that specific date, the action will be triggered.
These actions are observable immediately, making the overall systems realtime.
MasterKube Code
In the code given below, only the agents, elements and actions are relevant to show the interaction patterns and how it accomplishes the Real time agent Pattern is mentioned. This is illustrated with the invoice aging process. This invoicing agent does not take into consideration, the fact that the invoice balance is dynamic and aging has to be done only when balance is not zero.
Define Elements
<?xml ve<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Actions>
<!-- Over30dayDue Action -->
<Action> <Element>InvoiceNumber</Element> <Element>InvoiceBalance</Element> <Element>InvoiceDate</Element>
<Element>60DayDueDate</Element>
<ActionName>Over30DayOverDue</ActionName>
</Action>
<!-- OverDue Action -->
<Action> <Element>InvoiceNumber</Element> <Element>InvoiceBalance</Element> <Element>InvoiceDate</Element>
<Element>30DayDueDate</Element>
<ActionName>OverDue</ActionName>
</Action>
<!-- Over60dayDue Action -->
<Action> <Element>InvoiceNumber</Element> <Element>InvoiceBalance</Element> <Element>InvoiceDate</Element>
<ActionName>Over60DayOverDue</ActionName>
</Action>
</Actions>
Define Agents
<?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>InvoiceAgent</AgentName>
<Compose>
<!--- Other code for invoice..... -->
<!-- Does the overdue processing --->
<AgentCommand> <AgentName>OverDueAgent</AgentName> </AgentCommand>
</Compose>
</Agent>
<?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
<Agent>
<AgentName>OverDueAgent</AgentName>
<Compose>
<!-- When this agent is turned on, it turns on Overdue When the 30days becomes due, it turns off
OverDue and turns on Over30DayOverDue -->
<Sequence>
<Tell> <action> <actionName>Turn30daywatch<actionName> </action> </Tell>
<Tell> <action> <actionName>OverDue</actionName> </action> </Tell>
<Tell> <action> <actionName>Turn60daywatch<actionName> </action> </Tell>
<Tell> <action> <actionName>Over30DayOverDue</actionName> </action> </Tell>
<Tell> <action> <actionName>Over60DayOverDue</actionName> </action> </Tell>
</Sequence>
<!-- At the same time it puts a timer on so that on the day the invoice turns 30 days it triggers this action
-->
<Sequence>
<Ask> <action> <actionName>Turn30daywatch<actionName> </action> </Ask>
<Timer>
<Ask> <action> <actionName>OverDue</actionName> </action> </Ask>
<DateElementName>30DayDueDate</DateElementName>
</Timer>
</Sequence>
<!-- At the same time it puts a timer on so that on the day the invoice turns 60 days it triggers this action
-->
<Sequence>
<Ask> <action> <actionName>Turn60daywatch<actionName> </action> </Ask>
<Timer>
<Ask> <action> <actionName>Over30DayOverDue</actionName> </action> </Ask>
<DateElementName>60DayDueDate</DateElementName>
</Timer>
</Sequence>
</Compose>
</Agent>
Code working
The agent that is going to give the whole behaviour is InvoiceAgent. InvoiceAgent is composed of many agents. One of the agent is OverDueAgent. This is the agent, which has the ability to signal to the outside world, the overdue state of the invoice..
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
OverDueAgent is active. |
Turn30daywatch |
Turn30daywatch, Turn60daywatch |
After interacting on Turn30daywatch. |
|
|
OverDue |
Turn60daywatch |
When the agent is activated, it turns on the two sentinels which keeps track of the date. The agent with the Turn30daywatch, turnsoff OverDue when the 30th day is passed. This is accomplished by putting the complementary OverDue action on a timer with the 30th day due date. The agent with the Turn60daywatch, turnsoff Over30DayOverDue and turns on Over60DayOverDue. In the above case, the OverDue is turned on. So the outside observers will see this as OverDue.
| Interaction Steps | Emitter Synapses (Tell) |
Receptor Synapses (Ask) |
When current date goes past date in 30dayduedate it turns on as OverDue as per timer agent |
||
OverDue |
OverDue,Turn60daywatch | |
After Interaction of OverDue |
||
Turn60daywatch |
Turn60daywatch | |
After Interacttion of Turn60daywatch |
Over30DayOverDue |
|
When current date goes past date in 60dayduedate it turns on as Over30DayOverDue as per timer agenth |
Over30DayOverDue |
Over30DayOverDue |
Interaction of Over30DayOverDue |
Over60DayOverDue |
As per the table above, the invoice agent ages the invoice. As you can notice, when the current date goes past 30daydueDate, it turns on Over30dayOverDue. When the current date goes past the date in 60dayduedate, it turns on Over60DayOverDue.
Looping with Connection Machine
M .
How is horizontal performance scaling achieved with Connection Machine
M .
How is Network performance scaling achieved with Connection Machine
M .
