Information Technology Reference
In-Depth Information
PBWD, and at runtime, by using a service oriented approach, where services
providing monitoring information can be dynamically orchestrated in the moni-
toring processes obtained through PBWD.
The elementary monitoring information products are the monitoring infor-
mation that can be made available by actors in the business network to other
actors for monitoring purposes. e.g. the progress information made available by
the supplier or the factor in our running example. In the information system
or process engine executing a process to be monitored, monitoring information
can be captured from various sources and through different mechanisms, such
as (i) native APIs of the actor's ERP system, e.g. SAP monitoring architecture,
workflow or BPEL engine and (ii) ad-hoc instrumentation, e.g. through the de-
velopment of event captors or other online process inspection techniques [2].
Irrespectively of how monitoring information is captured, the process provider
can make such information available to users by exposing a Web service [6] im-
plementing, for instance, a different operation for each leaf element in the moni-
toring product data model. The cost, quality, and availability of the monitoring
information (see Table 1) can be then specified in a policy document [4], that
can be attached to such service before its publication.
In a service-oriented architecture, process providers publish their monitoring
services in a service registry (STEP 1 in Fig. 5(a)) and process users browse the
registry to get service descriptions and build their monitoring PDM (STEP 2).
Note that, in Fig. 5(a), process
provider
and
user
should be intended as roles,
since an actor in the business network canactatthesametimeasaproviderof
processes and a user of processes contributed by other actors.
The architecture depicted in Fig. 5(a) supports also the creation of an exe-
cutable monitoring process. Specifically, a process user in the business network
interested in building a monitoring process retrieves the required monitoring
service description from the registry. Service descriptions are then used to build
a monitoring product data model using the ProM toolkit (STEP 3). Currently,
as discussed in the previous sections, the algorithms for obtaining monitoring
process models (STEP 3), expressed as Petri nets and satisfying given quality
constraints, have been implemented as plugins of the ProM toolkit. ProM also
provides a plugin for the translation of models from Petri nets to (abstract)
WS-BPEL specifications (see Fig. 5(b)). The abstract WS-BPEL specification
is bound by the monitoring stakeholder to the required monitoring services in
the registry, in order to make it executable, and deployed in a process engine
(STEP 4). When in execution, a monitoring process will use the monitoring ser-
vices originally published by actors in the business network, according to the
aggregation and dependency constraints specified in the monitoring PDM and
the derived monitoring process model (STEP 5).
In respect of the scenario depicted in Fig. 5(a), most of the steps of our
methodology, such as the definition and retrieval of monitoring services from the
registry, the binding of the WS-BPEL specification obtained through ProM to
actual services in the registry, and the deployment of the WS-BPEL specification
in the process engine, are still executed manually. Future work will concern the
