This paper presents an overview of WADE (Work ows and Agents Development Environment ), an open-source platform for agentbased BPM (Business Process Management ) that has been adopted in Telecom Italia for mission-critical systems since the early 2000s. First, we sketch the main features of WADE and outline its internal architecture. Then, we describe WANTS (Work ows and AgeNTS ), an industrial strength platform for large-scale network & service management that is now in service in Telecom Italia, and that leverages WADE agent-based work ows as core technology. Finally, we conclude the paper with a brief summary of the presented innovative technologies.
BPM (Business Process Management ) is now a consolidated trend in IT that has recently come up as a new discipline intended to unify related topics such as Process Modeling, Work ows, Enterprise Application Integration and Businessto-Business integration.
Current BPM systems are high quality, mature tools intended primarily to
manage business processes that are well structured and whose paths are
identied a priori (see, e.g., [
Besides their central role in Arti cial Intelligence, as witnessed by, e.g., [
Taking the peculiar point of view on agents that FIPA promoted, we can say that agents are loosely coupled software entities spread across a network of computation sites that communicate by means of asynchronous message passing. Normally, the ensemble of agents that form a so called MAS (Multi-Agent System) is highly dynamic and decentralized, and the coordination of the tasks of agents is not embedded into a speci c part of the system, rather it is dynamically distributed across the MAS and single agents have full control over their behaviour.
Today, agents are a mature reality in software development with notable
successes, open-source reference tools, and a large literature that targets researchers
and practitioners. They were used to foster collaboration (see e.g., [
Unfortunately, many barriers prevent a massive exploitation of agent
technology both in terms of supporting tools and methodologies, and of the acceptance
of software systems showing a certain degree of autonomy. Nevertheless several
examples of deployed agent-based systems at an industrial scale exist. A number
of them are described in the AgentLink site [
This paper presents WADE (Work ows and Agents Development
Environment ) [
In broad terms, a work ow is the static de nition of a process in terms of activities to be executed, relations between them, criteria that specify the activation and termination of activities, additional information, such as the participants, the software tools to be invoked, required inputs and expected outputs, and internal data manipulated during the execution.
Nowadays the work ow metaphor is commonly used in BPM and a workow represents in this area a possible, and probably the preferred, means for describing a business process.
The main advantage of implementing a process as a work ow is the inherent expressiveness of the work ow metaphor. In fact, a work ow can be represented in a purely graphical form that is understandable by domain experts as well as by programmers. Domain experts can validate system logics directly and not only on documents, that are often not timely updated.
Another important characteristic of work ows is that the steps that compose the process are clearly and explicitly identi ed. This enables creating automatic mechanisms that trace the execution of a work ow, thus facilitating system monitoring and problem investigation.
Additionally, when processes have to be executed within the scope of a transaction, the explicit identi cation of work ow steps allows using semi-automatic rollback procedures that can be activated in case of unexpected faults.
Finally, since work ows are fully self-documented, work ow-based development releases the development team of the burden of keeping documentation aligned with running software. 2.1
WADE (Work ows and Agents Development Environment ) [
WADE is essentially the main evolution of JADE (Java Agent and
DEvelopment framework ) [
JADE has been used in many research and industrial systems at an
international scale since its initial development back in 1998. Just to cite a known
and appreciated use of JADE, which is also related to the network
management scenario discussed in Section 3, BT uses JADE as the core platform for
mPower [
As depicted in Figure 1, WADE mainly adds to JADE the support for the execution of tasks de ned according to the work ow metaphor, and it also provides a number of mechanisms that help managing the inherent complexity of a distributed system both in terms of administration and fault tolerance.
In this work we focus on the aspects related to work ow-based development
because we consider them the most characterizing feature of WADE in its current
form. Nonetheless, it is worth noting that WADE can be used as an everyday
development platform and, in principle, developers can use WADE with little or
no adoption of work ows. As we often say, WADE supports notepad
programming because the full power of the platform is accessible from plain old Java
objects. However, remembering that one of the main advantages of the work ow
metaphor is the possibility of representing processes in a friendly graphical
notation, WADE comes with a development environment called WOLF (WOrk ow
LiFe cycle management environment ) [
- Application specific Application features
JADE - Workflow development - Administration and fault management - Distributed runtime - Agent and behaviour - Communication - Discovery and an advanced graphical editor integrated in the Eclipse IDE, and little or no programming skills are needed to implement simple work ows.
In fact, the main challenge that drives and motivates the design of WADE is to bridge the gap between the BPM-level use of work ows and their use to implement the internal logics of a distributed system. That is, even if it could be used for that purpose too, WADE does not only target high-level orchestrations, rather it provides concrete support for the implementation of the internal behaviour of the system. Furthermore, unlike the majority of existing work owbased systems that provide a powerful centralized engine, in WADE each agent embeds a micro-work ow engine and a complex process can be carried out by a set of cooperating agents, each one executing a piece of the process.
Another key characteristic of WADE is that it does not adapt a privileged textual or graphical notation to express work ows, rather WADE sees a work ow as a set of Java classes. This makes the work ow immediately executable and no interpretation or just-in-time compilation is needed. Moreover, this choice eases the graceful scaling from the BPM-level down to the level of the internal logics. WOLF is an essential tool in this picture because it provides a convenient graphical view of work ow classes and it smoothly integrates work ow editing and Java editing with the advanced features that the Eclipse IDE provides. 2.2
In order to facilitate import/export operations from/to work ow standard
representation formalisms, WADE adopts a work ow meta-model closely derived
from that de ned by the Work ow Management Coalition for XPDL [
A task that is being described is called a process. A process is composed of a set of activities each one corresponding to the execution of given operations. A process de nes a single start activity (specifying the execution entry point) and one or more end activity (specifying the execution termination points). Each non-end activity has one or more outgoing transitions, possibly associated with a condition, leading to another activity in the process. Once the execution of the operations included in a given activity is terminated, the conditions of all outgoing transitions are evaluated. As soon as a condition holds, the corresponding transition is red and the execution ow continues with the operations included in the destination activity.
A process can have one or more formal parameters de ning the type of required inputs and expected outputs. At process invocation time proper values must be provided for input parameters and, at the end of the execution, the values produced as output parameters are returned to the requester.
WADE supports several types of activity and number of the di erent types of activity is constantly growing as the use of the platform increases. Besides many useful types of activity, the most important types are as follows. { Sub ow activities. The operations included in a sub ow activity consist in the invocation of another work ow process. The execution of the sub ow takes place in a separate computational space and can be even carried out by a di erent agent (possibly running in a remote host). { Tool activities. The operations included in a tool activity consist in invoking one or more external tool generically identi ed as applications. Applications are computational entities de ned outside the work ow process and wrapped by a uniform interface. { Code activities. The operations included in a code activity are speci ed directly by a piece of Java code embedded in the work ow process de nition. It should be noticed that, unlike tool and sub ow activities, code activities do not belong to the XPDL meta-model and are a proprietary WADE extension. 3
With over 8:95 million broadband connections (retail and wholesale) in 2012,
Telecom Italia is currently one of the leading operator in the Italian TLC market.
It has one of the most penetrating and advanced networks in Europe, with an
extension of over 114 million km in copper lines and 5:7 million km of optical
bers [
Considering the huge business volumes involved in this scenario, it is not difcult to understand that network management systems carrying out everyday intensive operations have strong requirements in terms of scalability, robustness and exibility. WANTS (Work ow and AgeNTS ) is a platform for the management of telecommunication networks and services that Telecom Italia is currently using to manage its broadband network for many OSS (Operation Support System) and BSS (Business Support System ) activities. In brief, some of the key architectural point of WANTS are: { WANTS is a network & service management platform based on distributed agents running hierarchical work ows; { WANTS has a documentation inventory of all processes and all equipment information models; { WANTS has a model inventory holding all process descriptions and network resource information models with automatic synchronization with all operating functionalities of the platform, which solves the problem of having a continuous up-to-date documentation of equipment modeling and operating processes; { The architecture of WANTS is intrinsically adaptive in detecting and predicting saturation using observation of real load and managing resource utilization.
The prior art in network & service management platform implements exibility as more or less sophisticated con guration capabilities and development environments that helps system designer in building the skeleton of new modules to support new services or new technologies. This degree of exibility is certainly not enough and new trends recommend extraction of embedded process logic from components in order to have an external process manager that can orchestrate the ow of actions, thus achieving a much greater exibility.
WANTS pushes such an approach even further because all process logic that remains inside each component is programmable from an external management entity, using work ow engines in all components of the platform. This concept is radically conceived so that each component is essentially a work ow engine that runs each kind of process, moving further from current approaches of platforms where each component runs a speci c domain functionality to a platform where each component can be freely focused on particular domain functionalities needed by current policies, availability of resources, and load status.
Figure 2 outlines the major components of the WANTS architecture. Each PA (Protocol Adapter ) is responsible for interfacing all the network equipments of a designated area that o ers the same API or protocol, e.g., SNMP, telnet, or TL1. Each PA o ers, as services to RPs (Resource Proxies ), the execution of basic operation on the equipment.
Each RP is responsible for creating, maintaining and managing a so called image of a single equipment. The image is a representation of the con guration of the equipment according to a de ned information model. The alignment of the image to the actual network is done by means of periodic checks or by means of proactive noti cation from PAs or from equipments themselves.
Each RP performs activities typical for the RP level: such activities are called layer 3 activities and they can be structured in sublayers. Activities at the top of layer 3 can be externally invoked, thus they are the services that RP o ers to the AAs (Agent Applications ) and to external applications. They represent the operations that can be atomically performed on the equipment that the RP manages. Examples of services o ered by RP are: con gure port, create crossconnection, modify connection attribute. Each of such processes can include a sequence of basic commands to be sent and/or received to/by the equipments. Activities at the bottom of layer 3 uses services o ered by PAs.
The image handled by an RP is dynamically de ned by the information model of the represented resource. This model is distributed by the MA (Manager Application) loaded by the RP and then instantiated with values retrieved by the resource. In this manner, changes and additions of information models do not require software changes in the component of the platform, thus allowing a high degree of exibility, as long as the equipment API or protocol are supported by the PA.
The network inventory, as a fundamental component of any network management platform, is split into two concepts in WANTS: a DNI (Distributed Network Inventory ) and a CNI (Centralized Network Inventory ). The former is the collection of all images contained in all the RPs; its usage is for all real-time (or almost-real-time) tasks such as provisioning, assurance, and performance, where having updated information on the con guration and state of the network is necessary for the accuracy and e ectiveness of the task.
The latter type of network inventory is the CNI: it is basically the usual network inventory component. In WANTS this inventory is used only for nonreal-time tasks where continuous updates with the network are not possible because of the centralized design. Nonetheless, the CNI is periodically updated interacting with the RPs.
The MDB (Model Data Base) is a documentation inventory of all processes and all equipment information models. The MDB is kept synchronized with the processes and information models running in the architecture. This represents another major bene t for the network operator that does no longer need to dig information from huge amount of documentation of the di erent component vendors with the risk of not nding or even nding obsolete documentation.
AAs are agents that are in charge of performing work ows for coordination of a set of RPs and for the execution of activities typical of the agent level: these activites are called of layer 2 and they can be structured in sub-layers. Activities at the top of layer 2 can be externally invoked, thus they are the services that AAs o ers to the MA. Each AA can perform any type of process of layer 2 or, in other words, supports all FCAPS (Fault, Con guration, Accounting, Performance, Security ) functionalities.
AA interact among each other via a community protocol to support distributed execution of management functionalities like, e.g., distributed circuit design.
AAs do not require software update to support new services and technologies because of the extreme exibility of the processes that are received by the MA that are loaded and executed by the AA. Each AA is responsible for a local performance monitoring to inform the MA about performance status.
The MA is responsible for the following tasks: { Manage the distribution of processes of layer 2 and 3 to AAs and RPs retrieving the process de nitions from the MDB; { Manage the distribution of equipment information models for the RPs retrieving the equipment information models from the MDB; { Monitor the state of the platform with information provided by the AAs, included distribution of components, domain management (partitioning of whole network among the AAs), performance monitoring and consequent actions like load balancing between AAs. { Interact with external systems, like other legacy OSS or BSS. { Execute activities typical of layer 1, that are meant to provide functionalities that require interaction with external entities (other than AAs) or coordination among agents that cannot easily or e ciently be performed by AAs through the community protocol.
It is worth noting that besides AAs, all executors of any of the three layers are developed as a combination of a work ow to fully exploit the power of the underlying WADE platform.
The mobility service that WADE transparently provides is useful to move agent across hosts in order to solve agent deployment and fault tolerance issues. If an agent unexpectedly terminates, WADE instantiates a new agent and moves it toward the target host (obviously if the host is still running) in order to replace defunct agent. The MA periodically monitors the presence of AA agents and acts accordingly. Moreover, agent mobility is also useful to move agent across hosts to face load balancing issues. This can occur if an AA, for instance, is continuously requested by an MA to run a work ow. The AA quickly becomes a bottleneck and WANTS either instantiates a new AA and moves it toward the host where overloaded AA run, or it simply moves the overloaded agent on a host with lower CPU load. The AA agent communicates the current overload condition to the MA, and after that the MA requests for agent mobility. 4
This paper presents a set of tools that are in routine work in Telecom Italia to manage mission-critical business processes. The rst tool is WADE, an opensource platform that can be freely used to implement sophisticated systems that rely on the synergy between agent and work ow metaphors. The second tool is WANTS, a mission-critical network & service management platform completely developed in Telecom Italia using WADE and currently deployed in the eld.
WANTS has a direct in uence on the work of thousands of technicians and on millions of customers and, as a consequence, it has strong requirements in terms of scalability and exibility. The enabler for this compelling price/performance proposition is WADE that uses the combination of agents and work ows to achieve: { High exibility in de ning and modifying services; { Deep control on the accuracy of results in a fault tolerant environment; { High performance and scalability; { High robustness and user-friendliness; { High control and maintainability on the logics used in the platform.
In order to bring the work ow approach from the business process level down to the level of system internal logics, WADE allows viewing work ows both in terms of high-level process descriptions and of lower-level Java code. This allows combining the exibility of the Java language and the power of the Eclipse IDE with the expressiveness and traceability of work ows. Moreover, it lowers the barrier of acceptance of the presented technology from both domain experts, that are familiar with the graphical notation, and from technical personnel, that appreciates working with a well-known language like Java.
Unfortunately, the fuzzy buzzwords that surround agent technology, like autonomy and self-consciousness, still encounters some resistance especially in a large enterprise like Telecom Italia.