|
Hi Joe, <snip> At one point, I thought named activation groups were shared across jobs, which then made them very attractive, but since that's not the case, I have a hard time understanding the benefits of a named activation group. The housekeeping involved with having to manually shut down the activation group makes them unwieldy to me. </snip>I think a good candidate for a service program running in a named activation group is one that provides a simply but universal service. Think of a service program designed for easy string manipulation. It could (among others) have the following procedures:
toUpper(...) toLower(...) capitalize(...) centerText(...) etc...There really isn't a good reason to have more than one invocation of this service program within any given job. The use of a named activation group ensures that we get one and only one instance.
I would not normally expect to shut this activation group down until job end, so there is no extra overhead involved.
It may also be necessary to mimic the singleton design pattern for consumption of large stand-alone services such as http client services, xml decomposition services, html creation services, etc... These services may need to be integrated into our code (as they are used via several procedure calls) so the use of a separate job to provide the service may not be feasible. The use of a named activation group allows us to go some way towards the goal of having an integrated, yet stand-alone, service. The introduction of named, *NEW, and *CALLER activation groups has provided a pseudo-OO environment (or at least some level of granularity, with multiple instances of the same program object running in the same job), and within this environment we sometimes need to force a service to be provided using a "single invocation" approach. This is where named activation groups work a charm.
Cheers Larry Ducie
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
