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

consumed, a large amount of dynamic information, which is only
determinable in runtime but crucially in charge of the process state and
enactment, such as messages, queues, alarms, counters, faults, correlations,
and so on, must all be coordinated. Not only that, executable processes as
normal computer programs are inl uenced by a wide spread of system
variables, from hardware coni guration to operating system support, from
hosting server to external services, which ought to be looked after. Likewise
in grid computing, traditional concerns of those causing abnormal system
behaviors when both hardware and software are under enormous stress
remain themselves in a BPEL-enabled environment. We will try to discuss
these in common with regard to large-scale and concurrent executions.
All computer programs consume memory. As memory usage begins to
grow with processes in a system, memory-management mechanisms start to
kick in to release memory slots that are no longer in use. Taking Java for
instance, garbage collection is built into the Java Virtual Machine (JVM) and
managed automatically. Optimization policies and related coni gurations
can be passed directly at server (e.g., Tomcat) startup, and all hosted applica-
tions will be affected accordingly. With long-running executions, allocated
memory is persistently held by processes that are waiting for conditions of
continuing, for example, replies from partner services, to be satisi ed.
Deallocation noticeably lags behind, and available memory has to keep
decreasing until the next major collection. Then, as the execution proceeds, a
process itself can get more complex such that dependencies may establish
and complicate themselves both internally and with other processes and ser-
vices. It is almost certain, under such circumstances, that the general process-
ing speed of the system will suffer a steep cut-down, not to mention the
growing need of system resources of both existing and new processes that
keep feeding in. The longer the processes stay in the system, the more the
memory is needed by maintenance and the more the deallocation will be
delayed, and in the end, less memory will be available overall for further
executions. Having said that, an exponential climb-up of memory use may
eventually occur and start to take down the system until a complete exhaus-
tion under extreme conditions. Or, more likely, the virtual memory that has
been swapped into the system may seriously slow down the machine even
more due to demanding disk access. System stability will be seriously com-
promised such that a functional state cannot be maintained.
Another concern falls within threading. In a burst of spawn of massive
concurrent processes, a large amount of threads are acquired to hold sub-
process execution states. Typically, application servers implement their
own native thread pools and threading managements to support high-
density serving requests. With no exceptions to any large multithreaded
systems, i ne-grained tuning is required to meet concurrency requirements
for particular application deployment. ActiveBPEL replies on Axis/Tomcat
to handle low-level communications with external services, while its
own scheduling of concurrent processes (e.g., via l ow and for each ) is