PDF of this tutorialBuilding on the foundations of a distributed, possibly heterogeneous environment, this tutorial will now discuss the application of intelligent behavior to the components that comprise the system. The following two aspects of the system apply here:
- The system is distributed using object techniques.
- The system is performing a basic IN function.
Whether homogeneous or heterogeneous elements construct the system is inconsequential. The impetus is toward a distributed object environment working to provide intelligent behavior during tasking. Moving beyond the basic task of translation, many other elements of the system must operate simultaneously to provide availability, scalability, and manageability of the components and, therefore, the overall solution. Owing to these responsibilities, the tutorial examines methods that involve message-based states, intelligent agents, rules processing, and state transition management.
State Transitioning
Preservation of call-state during the flow of a transaction addresses one of the fundamental principles of OLTP techniques within intelligent networking. Call-state moves through several identities during a basic transaction’s lifecycle. The net result is a much larger extension of basic request/reply models that are attributed to elementary client/server techniques. However, when examined at its basic components, each instance of the transaction’s lifecycle can be interpreted as following the specifications of OLTP. Taken as a whole, the transactions themselves do not fall under the rigors of a TP monitor’s initiatives (i.e., there are no back-out activities). Instead, the transaction itself carries with it the notion of call-state so that the steps performed during transaction processing can take that state value into account. Moreover, persistent operations administration, maintenance, and provisioning (OAM&P) activity that takes place during transaction processing can enter into or be enacted by the state transitions. These, too, involve actions determined by the current state that invoked the OAM&P functions.
Thus, looking at the transaction lifecycle as a series of iterative operations uncovers a series of operations connected to each other both with data and with state value. These operations are then correlated to actions dictating the behavior of the next iteration in the lifecycle and the behavior of the overriding OAM&P activity. Two common methods are used to manage the state transition: callback methods and message-based methods. For true distribution techniques, the message-based methods prove to be the more appropriate vehicle.
Callback Methods
In an application program or a transaction-processing environment, a callback is a user routine or method that is registered with a state engine. When registered, the name or address of the callback is provided along with a triggering mechanism recognized by the state engine. The state engine retains the function/method address and invokes that address upon encountering the registered event that corresponds to the triggering mechanism. Callback message-processing methods offer a distinct advantage in that they centralize all message-processing code while, at the same time, they work with a uniform state value. Multiple callbacks can be registered with a single event either at the registration point (with the state engine) or as a second- and third-tier operation. For example, the primary callback could instigate a series of functions or callbacks. Rather than performing event-trigger registration with the state engine, sundry functions could register with the master callback. A callback model implies a multithreaded model (see Figure 11).
Figure 11. State Table Transitioning with Callbacks
Message-Based Methods
Message-based methods for transaction processing give the application program greater control of the timing of actions to be performed during the call’s lifecycle. The method requires a generic set of actions used to parse the content of the message to the point that interests the particular function receiving the message. The parsing methods increase in depth of discovery as the transaction moves through the system and builds upon itself. This is required as the transaction itself carries its current state as it moves along. Additionally, OAM&P activities may be generically invoked along the transaction’s path to determine (again, based on the parsed combination of state and value) if actions should be taken outside the normal call path (see Figure 12).
Figure 12. Message Transition through State Changes
One easy example is the notion of discarding aged transactions. A generic routine, which examines the current timestamp and compares it to the originating timestamp of the transaction, can be provided. At each point along the transaction’s iterative movement through the system, the routine is invoked. If the delta between the two timestamps ever moves out of acceptable range, the transaction processing is halted. This does not require registration or notification because the triggering mechanism itself is a logic test—not an event within the state engine. Building upon this principle, generic logic gates can be developed that add intrinsic management and reporting values to the entire transaction path.
Intelligent Agents
Building upon the discoveries in the computer industry surrounding artificial intelligence, agent technology has emerged as a significant contributor to providing user-level understanding of flexible and dynamic computing environment conditions. As previous sections have clarified, an intelligent networking environment is by far a dynamic environment, and intelligent agents in the middle of the transitioning activity provide a succinct method of proactively and reactively changing the behavior of the overall system. Loosely defined, an agent is an entity (typically software) that is able to perform actions in a dynamic environment and that ultimately serves the directions of its creator. An agent is classified by its basic behavior, instantiated by the creator. Several classifications exist.
Mobility
Either the agent and its underlying behavior is static to a particular element of a network, or it is declared as mobile, indicating that it is able to transverse individual computing elements of the network. The latter implies a series of computing elements able to service the coding specifications of the mobile agent. Clearly, Java comes to mind in the form of acceptable coding environments, as it involves platform-independent behavior.
Intent
Fundamentally, an agent’s behavior is either deliberate or reactive. A deliberate agent tends to possess a set of actions to be performed in the form of an internal set of rules and or goals to be achieved. Through collaboration with other agents in the system, a deliberate agent acts to modify system behavior. Reactive agents, on the other hand, contain an orderly set of actions to be taken based on the changing nature of the system (see Figure 13).
Figure 13. Message State Governing Intelligent Agents
Personality
Agents perform actions on a system either through collaboration with other agents in the system or as an independent autonomous event. A collaborative agent determines its behavior and implements its actions through negotiation and conversation with other agents in the system. An autonomous agent typically gathers its information and affects the system directly.
Roles
One of the easiest methods of classification for agents is the role that the agent plays in the system. Information agents, as an example, are associated with fundamental information-gathering activity. Reactive agents extend the role of an information agent by performing an action based on the content of the gathered information.
When placed within the boundaries of an IN, agents serve an immediate purpose in the correlation of activities traditionally found within OAM&P. The trio of events, statistics, and overload offers the best example (see Figure 14):
Figure 14. Basic Triad of Events, Statistics, and Overload
Events, statistics, and overload interact with one another and ultimately influence each other’s behavior. Events are triggered, which subsequently poll statistics, which eventually escalate or abate an overload condition, which then triggers an event. Tying the three together and then attempting to perform corrective behavior in the form of process or application management becomes a challenging task from a static-system-description point of view. Interjecting agents between the components with rules of engagement based on the reactive and collaborative behavior softens the impact of the changing system. Furthermore, adding discovery-oriented agents to negotiate with the trio allows the end user the ability to perform off-line intelligence gathering about the dynamics of the state change. Through proper information passing, an explanation for various events can be determined.
Rules-Based Processing
Rules processing forms the user’s mandates for specific conditions and actions to be detected and performed by agents during system environment transition. Fundamental rules take on the form of if-then-else constructs. For example, if a link goes out of service, issue an alarm. Or, if the link is out of service, route to another link.
The semantics are found within all application environments as basic conditional processing. Rules, however, identify these elements within an external resource and apply the elements in a language setting, typically in IDL fashion:
Rule: link_out_of_service
Conditions: link_error; link_manually_downed; link_not_open
Actions: issue_link_alarm; alter_routing_table
Implementation of a rules-based method within an agent setting implies continuous checking for the enabling of the rule followed by actions. When compared to prior discussions on callback methods for state transitioning, the rule itself can be registered as a state within the overall engine. Applied to message-based processing, a notion of a when condition applies:
Rule: link_out_of_service
When: link_state_changes
If: link_error; link_manually_downed; link_not_open
Actions: issue_link_alarm; alter_routing_table
So the difference here is the addition of the state change registration through the when condition. Architecturally, the result is an abstraction of a state engine–callback environment held above the fundamental message processing. The differences occur in that the agents manage the state engine through callbacks enabled and executed outside and independent of the call path.
Interaction
Rules allow the agents to tie the models together. Through rules-based processing, agent and nonagent entities in the call flow are able to perform scripted actions based on registered occurrences. In many cases, the registration of events to detect is also determined through rules logic. An intelligent agent in the call-processing path is privy to a wide variety of information regarding the activity of the system and, using this information, is able to interact with other agents to effect change. It is the act of change that is determined by rules scripting. State table management as an overriding factor in the call path(s) of the system allows for abstract implementation of dynamic rules processing. Agents may implement a callback method for notification of the when clause of the rules script. The state table becomes the mediator of scripted agent behavior, while the call path remains the instigator of agent activity (see Figure 15).
Figure 15. Agent Behavior with Scripted Callbacks
