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

engine to customize individual deployment. Depending on proprietary
implementations, this may be achieved declaratively with a deployment
descriptor. BPEL Designer handles the generation of the deployment descrip-
tor (as well as other i le formats) transparently with the ActiveBPEL server
runtime that we have mentioned.
Once a process archive is uploaded to ActiveBEPL, deployment i les are
unpacked to the working directory that the engine monitors periodically to
pick up new deployments and make changes to existing ones. ActiveBPEL
supports hot deployment , which avoids interruption of ongoing processes or
other hosted applications on the server when a process needs to be modi-
i ed and redeployed. In particular, this is of benei t to long-running pro-
cesses that cannot afford unmanaged terminations.
Nevertheless, some practical issues emerge with process deployment.
A BPEL engine could spend considerable time and computer resources,
particularly memory resources, on deploying large process descriptions
depending on the complexity that is roughly in proportion to the size of a
plain BPEL document. It is possible that system reliability may be threat-
ened so that stable process execution will not be guaranteed as a conse-
quence, or the process deployment could not even complete in the i rst place.
In less extreme scenarios, there are indeed great chances (when processes
are becoming too complex and believed to be larger than necessary), in
which cases decomposition that can distribute process complexity to coor-
dinated subprocess modules is always suggested and likely to be applicable
normally. In fact, the divide-and-conquer approach permits better control
of process logic through the separate optimizations of individual sub-
processes. It is good practice to perform service-oriented analysis and
design in general anyway, even if memory constraint is not a concern of a
particular system setup. Consequently, subprocess units may be further
distributed onto multiple server instances whenever necessary to decentral-
ize associated computing stress, without affecting the initial process.
Because of the deliberate separation of service interface and binding (which
only takes place at deployment time), service relocations, which are com-
pletely transparent and irrelevant at design time, can be simply managed as
altering subprocess service endpoint references in the deployment descrip-
tor, leaving the process document unmodii ed completely. Conventional
strategies such as server clustering, which is supported by Tomcat, are still
feasible to enable load balancing.

8.18
Process execution is clearly far more complex. Except for the static contents
of a process like the process map deployed on an engine that must be

Execution