Information Technology Reference
In-Depth Information
implemented independently, to which extent process enactment can be
internally optimized. Users can decide the range of number of threads to
be managed by the built-in work manager of the engine, the maximum
threads to be allowed for each process, and so on in order to control the
workload to be placed on the server in runtime. As for Tomcat, dedicated
tools and methods exist for professional diagnosis and rectii cations.
Nevertheless, it is still the fundamental system resources that will be in
intensive demand when more threads are allocated in process executions:
the operating system will not have an unbounded number of threads;
memory management will be challenged again as we have just discussed;
disk space may be subsequently exhausted; delays around the networks
may result from high volume data transfer, and so on. It is important
to point out that it is not only the critical components like the operating
system, the hosting server, and the BPEL engine that must be sufi ciently
scalable, but also any orchestrated services as self-administrative compo-
nents themselves must be aware of possible grid requirements in dedi-
cated application scenarios. For example, a service invocation may be
failed simply because of nothing but the service running out of i le descrip-
tors for opening i les in the operating system. Extra synchronization must
be implemented to avoid deadlocks or arbitrary data access; a service
desig n should take potential performance requirements into consideration,
so it does not refuse service requests made at a reasonable rate, for exam-
ple. In other situations, extensive service interactions may result in com-
munication deadlocks when both memory and threads are under tight
constraints relative to large-scale executions. A process will be blocked on
the reply of the partner service that is stuck in the thread queue.
BPEL is a specii cation that sums up a high-level agreement on the
normalization of a solution to a specii c problem. Process executions are still
largely dominated by low-level implementations. Existing solutions and
methods that have been efi cient in resolving typical grid computing prob-
lems will still be applicable and play important parts in designing and
implementing BPEL-enabled grid applications, given that BPEL and BPEL
implementations are merely a thin layer on top.* Note that it is always a
systematic consideration to put together pieces of best-i tting technologies
and practices to achieve both functional and nonfunctional requirements.
As far as process modeling is concerned, the responsibility of a process
modeler is to incorporate possible optimizations into the process design, for
example, with appropriate algorithms, interaction models, parallelization,
fault handling, service-oriented analysis, and so on. The modeler must
express the process logic not only accurately, but also efi ciently, for the
benei t of both process development and the underlying implementations.
*
Benchmark data are available in separate publication.
Search WWH ::
Custom Search