Grid Services Orchestration with OMII-BPEL - Grid Computing: Infrastructure, Service, and Applications - page 209

The asynchronous interaction modeling may ease the network and memory
tension for long-running invocations.
A BPEL process can be invoked by any valid Web service client that
creates and delivers SOAP messages. Support has been given from many
modern technologies since Web services gradually merged into mainstream
IT. Various tools have become widely available. OMII-BPEL users benei t
from the simple yet powerful Web Service Explorer so that they can work
seamlessly and efi ciently within the OMII environment.

8.19
It is obviously important that BPEL users should be able to keep track of
their processes. ActiveBPEL provides the monitoring facility through its
one-stop administration console that is deployed side by side with the core
engine. An administration console is shown in Figure 8.5 . The Web portal
allows access to various information and coni gurations of the engine, while
process monitoring is only one of the functionalities it provides.
Starting from the navigation index on the main Web interface, entries
can be found for engine administration, deployment status, as well as
process status in groups, which are followed by a link to a separate
thorough user guide to the console. A short list of coni gurable engine
settings can be found, from elements as simple as logging style through
to validation control and thread management. The engine can be stopped
and started without killing the host server to enforce lightweight reset of
engine coni gurations and states; for example, to reset database login
information. Upon the deployment of a process, apart from the deploy-
ment log given as expected along with a list of deployment i les, full
WSDL desertion of the deployed process is made available with a unique
URL and made ready for use. Once a service request is made at the given
WSDL service endpoint, for example, using WSE, the resulting process
instance will be assigned with an entry in the console and labeled with a
sequential process ID, a process name, a start date (and an end date if
competed), and one of the main statuses of running , completed , faulted , or
terminated . Every entry is linked to a separate page of full process details,
where users can i nd out about variable data, partner links, execution
progress, faults, log, and other state information of the process, using the
given graphical process tree structure that maps to the process dei nition.
A running process may be suspended, resumed, or terminated on the same
page. The optimized JSP implementation of the detail page is capable of
rendering large process instances (e.g., with foreach in parallel) in reason-
able time.

Monitoring