Abstract:
A service interface enables an application to be developed independently from a particular service. At execution of the application, the application is wrapped or bound to a service. Advantageously, a configuration file includes instructions that bind particular applications with a particular service. Therefore, if improved services are developed after the application is written, only the configuration file needs to be updated, not the application source code. Accordingly, significant time and expense is saved by allowing applications to be developed independently from particular services.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     This patent application is related to and claims the benefit of Provisional U.S. Patent Application No. 60/471,385, filed May 16, 2003 and is incorporated herein by reference in its entirety. This patent application is further related to U.S. patent application entitled “Job Processing Framework,” filed by J. Phenix and N. Judge herewith, which application is incorporated herein by reference in its entirety. 
     
    
     RESERVATION OF RIGHTS IN COPYRIGHTED MATERIAL  
       [0002]     A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.  
       FIELD OF THE INVENTION  
       [0003]     This invention relates to the field of software transaction controllers, and, more specifically, to a service interface that effects binding of a service protocol to a job.  
       BACKGROUND OF THE INVENTION  
       [0004]     It is well known that technological change is occurring at a rapid pace. Such change can be of benefit in the area of software and software development. Developers use software services (e.g., SOAP and EJB for distributed processing) to implement applications. However, new services are regularly developed, which enables developers to select from a rich execution environment when they develop an application. This choice of services provides flexibility in initial implementation, but inhibits later modifications.  
         [0005]     Once a developer has implemented an application according to a particular service, however, it is very difficult to implement application changes without conforming such changes to the constraints of the previously selected service. Therefore, developers typically must implement the changes in accordance with the service regardless of whether a new and improved service exists. If a developer desires to use a different service for the application, a complete rewrite of the application is commonly required.  
         [0006]     Therefore, there is a problem in the art that, once a system is implemented, all new or changed processes are constrained by the selected system service to ensure interoperability.  
       SUMMARY OF THE INVENTION  
       [0007]     This problem is addressed and a technical solution achieved in the art by a service interface according to the present invention. An application is developed independently from a particular service. At execution of the application, the application is wrapped or bound to a service. Advantageously, a configuration file includes instructions that bind particular applications with a particular service. Therefore, if improved services are developed after the application is written, only the configuration source and potentially service tier need to be updated, not the application source code. Accordingly, significant time and expense is saved by allowing applications to be developed independently from particular services.  
         [0008]     Therefore, the service interface according to this invention is highly configurable and enables developers to decide at deployment time which services jobs are bound to without having to make any code changes in previously developed applications. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]     A more complete understanding of this invention can be obtained from a consideration of the specification taken in conjunction with the drawings, in which:  
         [0010]      FIG. 1  is a block diagram that illustrates an exemplary embodiment of this invention;  
         [0011]      FIG. 2  is a class diagram illustrating the relationship among the classes of an exemplary implementation of the embodiment of  FIG. 1 ;  
         [0012]      FIG. 3  is an exemplary Job Context class in accordance with  FIG. 2 ;  
         [0013]      FIG. 4  is an exemplary Job class in accordance with  FIG. 2 ;  
         [0014]      FIG. 5  is an exemplary Job Resource class in accordance with  FIG. 2 ;  
         [0015]      FIG. 6  illustrates the relationships among the Job Resource of  FIG. 5 , the Job of  FIG. 6  and an exemplary job;  
         [0016]      FIG. 7  is an exemplary Job Context Manager class in accordance with  FIG. 2 ;  
         [0017]      FIG. 8  is an exemplary Job Context Broker class in accordance with  FIG. 2 ;  
         [0018]      FIG. 9  is an exemplary Dispatcher class in accordance with  FIG. 2 ;  
         [0019]      FIG. 10  is an exemplary Dispatcher Daemon class in accordance with  FIG. 2 ;  
         [0020]      FIG. 11  is an exemplary Job Producer class in accordance with  FIG. 2 ;  
         [0021]      FIGS. 12   a - 12   c  are exemplary code for a Job Producer in accordance with  FIG. 11 ;  
         [0022]      FIG. 13  is an exemplary Job Feed Producer class in accordance with  FIG. 2 ;  
         [0023]      FIGS. 14   a - 14   f  are exemplary code for a Job Feed Producer in accordance with  FIG. 13 ;  
         [0024]      FIG. 15  is an exemplary Job Producer Feed Manager class in accordance with  FIG. 2 ;  
         [0025]      FIG. 16  is an exemplary Resource class in accordance with  FIG. 2 ;  
         [0026]      FIG. 17  are exemplary ResourceTimerContainer and ThreadResourceContainer classes in accordance with the Resource of  FIG. 16 ;  
         [0027]      FIG. 18  illustrates the relationships among a Resource of  FIG. 16 , a ResourceTimerContainer and ThreadResourceContainer of  FIG. 17  and a TimedResourceManager  1802 ;  
         [0028]      FIG. 19  is a sequence diagram for the addition of a resource that requires timeout management;  
         [0029]      FIG. 20  is an exemplary PooledResourceManager class in accordance with an exemplary embodiment of this invention;  
         [0030]      FIG. 21  illustrates the relationship between a Resource of  FIG. 16  and a PooledResourceManager of  FIG. 20 ;  
         [0031]      FIG. 22  illustrates a service definition in accordance with an exemplary embodiment of this invention, which is implemented as a set of rules for implementation class names and various implementations of the rules;  
         [0032]      FIG. 23  is an exemplary Service Broker Helper class in accordance with an exemplary embodiment of this invention;  
         [0033]      FIG. 24  in an exemplary Delegate Service class in from  FIG. 23  in accordance with an exemplary embodiment of this invention;  
         [0034]      FIG. 25  is an exemplary SOAP12 Service in accordance with an exemplary embodiment of this invention;  
         [0035]      FIG. 26  is an exemplary Client Job in accordance with an exemplary embodiment of this invention;  
         [0036]      FIGS. 27   a - 27   c  are a code example of a Client Job of  FIG. 26  in accordance with an exemplary embodiment of this invention;  
         [0037]      FIG. 28  illustrates an exemplary structure of a configuration source in accordance with one aspect of this invention;  
         [0038]      FIGS. 29 through 37  are exemplary rtclass nodes of the configuration source; and  
         [0039]      FIGS. 38 through 41  are exemplary values of the rtclass nodes of the configuration source.  
     
    
     DETAILED DESCRIPTION  
       [0040]     This specification is divided into four sections. Section I describes the job processing flow according to the exemplary embodiment of the invention. Section II describes the manner in which resources are managed according to the exemplary embodiment of this invention. Section III describes service utilities and Section IV describes an exemplary configuration file according to the exemplary embodiment of this invention.  
         [0041]     Section I: Job Processing Flow  
         [0042]      FIG. 1  illustrates an overview of job processing framework  100  according to an exemplary embodiment of the present invention, illustrated herein as divided into a first box  102  and a second box  104 . An application  106  performs various tasks via the framework  100 . Boundary box  102  represents a portion of the framework  100  that divides the tasks from application  106  into atomic units of work, or “jobs,” and efficiently manages the execution flow of such jobs. Boundary box  104  represents a portion of the framework  100  that binds each of the jobs to its associated service at execution, thereby allowing the application  106  to be implemented without constraint to any particular service or services.  
         [0043]     Deployer  108  represents a configuration data source that contains instructions as to how the components of the framework  100  operate. In particular, the configuration source of deployer  108  contains instructions as to which service protocol is associated with each job and how the execution flow of the jobs occurs. Accordingly, deployer  108  effects service selection and tuning of the framework  100  by the developer without implementing code changes in application  106 . To elaborate, the developer modifies the configuration source of deployer  108  to make changes pertaining to service usage and job execution flow instead of modifying the code used to implement the application  106  or the framework  100 . An exemplary configuration source is described in Section IV, below.  
         [0044]     Now a lifecycle of a task performed by the application  106  via the framework  100  is described with reference to  FIG. 1 . Tasks, according to this embodiment, can be broken down into identical processing units, or “jobs.” An example of such a task is processing large XML files, where the file can be subdivided into many smaller files enabling the large file to be processed in parallel.  
         [0045]     A task from application  106  is initially picked up by a job dispatcher  110  and then handed off to a job producer  112 . Job producer  112  refers to the configuration source of deployer  108  to determine how the task is to be divided into separate jobs. The configuration source indicates, for instance, the desired granularity of the task being divided. In other words, the configuration source instructs job producer  112  as to the size of each job. Because the size of the jobs is configurable via the configuration source, the amount of network bandwidth used for distributed batch processing is controllable. As job producer  112  generates jobs from the task, job producer  112  also adds the jobs to a job “container”  114  managed by job dispatcher  110 . Therefore, job producer  112  generates an in-flow of jobs to job container  114 .  
         [0046]     Advantageously, job producer  112  may be configured to generate jobs as a series of blocks of jobs. In this exemplary scenario, job producer  112  produces up to a defined maximum set of jobs that the dispatcher  110  manages until all jobs in the set have been executed. After the block of jobs has been processed, job producer  112  generates another block of jobs for processing.  
         [0047]     Job producer  112  may also be configured to generate jobs as a continuous “feed;” that is, job producer  112  constantly generates jobs until no more jobs in the task remain. The difference between these two job production methods affects the way in which resources, such as threads, are managed by and available to the framework  100 .  
         [0048]     In the exemplary embodiment, job producer  112  not only generates jobs from the task, but also generates a “job context” for each job. The job context may include a reference to the job and a job status field, but will include a reference or handle to the materials of a job (the data to be processed). The job status field includes information about whether the job has been successfully executed, has failed to execute, how long the job has existed prior to execution, where it is in the execution process, and other important statistical and managerial information. The job contexts coexist with their associated jobs throughout the job lifecycle.  
         [0049]     Along with managing job container  114 , job dispatcher  110  also manages a pool of job resources, such as threads, that will be used to execute the jobs. Job dispatcher  110  refers to the configuration source of deployer  108  for instructions as to the resources available and the manner in which they are to be used to execute the jobs.  
         [0050]     Execution of the jobs is managed by job consumer  116 . When job consumer  116  is ready to operate, job consumer  116  requests a job resource from the pool of job resources from job dispatcher  110 . If resources are available, job consumer  116  is assigned one (or more) of available resources  118  (box  104 ) and takes a job from job container  114 . The number of jobs taken and which specific jobs are taken by job consumer  116  are determined by the configuration source of deployer  108 . Armed with a job and a resource  118 , job consumer  116  then accesses the configuration source of deployer  108  to determine which service  120  is associated with the job. It should be noted that the services listed at  120  are merely examples, and the invention is not limited to those services listed.  
         [0051]     Having determined the appropriate service for the job, the job consumer hands the job off to service interface  122  (herein referred to as “pluggable service”). Pluggable service  122  wraps each job in appropriate content to conform to the service protocol identified by deployer  108 . Once wrapped, the job is executed using the assigned job resource  118 . After execution (or failure to execute by a certain period), status information about the job is updated in the associated job context and passed back to job dispatcher  110 . Job execution status is recorded by job dispatcher  110 . Also, resource  120  used by job consumer  116  is released back into the resource pool managed by dispatcher  110 .  
         [0052]     All of the jobs in the task are processed in the above-described manner, wherein job producer  112  continually fills job container  114  of job dispatcher  110 , and job consumer  116  continually removes jobs from job container  114 . Advantageously, an instance of job consumer  116  may consume more than one job at a time. It should also be noted that multiple instances of job dispatcher  110 , job producer  112 , and job consumer  116  may be used. Multiple job producers  112  may increase efficiency in dividing the task into jobs. Multiple job dispatchers  110  may increase efficiency in making jobs and resources available to job consumers  116 . Multiple job consumers  116  may increase efficiency in executing the jobs. Further, multiple job consumers  116  may be authorized to execute the same job, so that the multiple job consumers  116  race to execute the job first. In this scenario, only the results from the job consumer  116  that executes the job first are recorded.  
         [0053]     Additionally, although boundary box  104  is shown separate from job consumer  116 , it is advantageously incorporated within job consumer  116 . In particular, boundary box  104  is responsible for wrapping the job via pluggable service  122  with the content required for its associated service and executing the job with job resource  118 . Accordingly, boundary box  104  implements the binding and job execution functions of job consumer  116 .  
         [0054]     Further, a dispatcher daemon (not shown in  FIG. 1 ) advantageously controls creation and termination of instances of job dispatcher  110 . The dispatcher daemon creates one or more instances of job dispatcher  110  as tasks come in for processing. The dispatcher daemon may be configured for one-shot process execution or as a daemon.  
         [0055]      FIG. 2  is a class diagram  200  illustrating an exemplary implementation of the embodiment of  FIG. 1 . In  FIG. 2 , the exemplary implementation of job dispatcher  110  includes a dispatcher class  202 , a dispatcher daemon class  204 , a job context manager class  206  and a job context broker class  208 . Dispatcher daemon class  204  is an exemplary implementation of the dispatcher daemon previously discussed.  
         [0056]     An exemplary implementation of job producer  112  includes a job producer class  210 , a job feed producer class  212  and a job producer feed manager class  214 . The exemplary implementation of jobs and job contexts created by job producer  112  comprise job class  216  and job context class  218 , respectively. The exemplary implementation of job consumer  116  includes job resource class  220  which corresponds to job resource  118 . As previously discussed, it is resource  118  that actually implements the execution of a job, and job resource  118  is included within job consumer  116  in this exemplary embodiment. Each of these classes is described in more detail, below.  
         [0057]      FIG. 3  illustrates an exemplary embodiment of job context class  218 . Objects of this class hold a reference to the data the job is to execute and the results of the execution of the job. The job context is created in the framework via an instance of the job producer class  202  (described in  FIG. 11 ). It should be noted that all references are advantageously implementers of the java.io.Serializable interface  302  to enable passage across process and machine boundaries via RMI to RMI, EJB, SOAP, etc., servers.  
         [0058]      FIG. 4  and  FIG. 5  illustrate exemplary embodiments of job class  216  and job resource class  220 , respectively, according to an exemplary embodiment of this invention. Objects of type job  216  ( FIG. 4 ) are generated by job producer  112  and are executed as discussed in connection with  FIG. 1 . Objects of type job resource  220  advantageously represent a reusable processing component. Job resource management is discussed in more detail in Section II, below.  FIG. 6  illustrates illustrative embodiments of components for a job to be executed. An instance of job  216 , having a job context, requires an instance of resource  220  to execute, as shown at  600 .  
         [0059]      FIG. 7  and  FIG. 8  represent an exemplary embodiment of job context manager class  206  and job context broker class  208 , respectively. Objects of the job context manager class  206  manage the production of job context  218  and job  216  instances when generated by job producer  112 . The job context broker class  208  assists the job context manager class  206  in managing the generation of job context  218  instances.  
         [0060]      FIG. 9  presents an exemplary embodiment of dispatcher class  202 . Objects of the dispatcher class  204  are managers of the resource pools (described above in  FIG. 1 ) and any associated timeouts of those resources. The pools of resources facilitate efficient job processing by managing the ability of job consumers  116  to execute jobs. The resource pools are implemented as instances of the thread resource container class  1830  ( FIG. 18 , described in more detail, below) and managed by the pooled resource manger class  2000  ( FIG. 20 , described in more detail, below). The resources included in the pool are instances of the job resource class  220 . Rogue jobs (i.e., jobs that have timed out prior to successful execution, thereby tying up resources) are managed using the timed resource manager class  1802  ( FIG. 18 ). Dispatcher  202  manages job execution using the dispatch class  902 , given a job list and a reference to a job. The job list is a list of job contexts  206 .  
         [0061]      FIG. 10  comprises an exemplary embodiment of dispatcher daemon class  204 . Objects of this class manage instances of the dispatcher class  202  with respect to the number and type of job producer(s)  112  being used. The “type” of job producer  112 , in this context, refers to whether job producer  112  is a block job producer or a continuous feed job producer, as previously discussed.  
         [0062]      FIG. 11  is an exemplary embodiment of job producer class  210 . Job producer class  210  manages generation of a list of jobs  1102  and associated job contexts. Exemplary code for a simple job producer implementation returning a list of a list of integers is presented in  FIGS. 12   a - 12   c .  FIG. 13  illustrates an exemplary embodiment of job producer feeder class  212 . An object of this class interfaces with an object of the job producer class  210  to produce jobs and job contexts on a continuous feed basis. Exemplary code for a simple job feed producer  212  implementation returning a list of integers is illustrated in  FIGS. 14   a - 14   f.    
         [0063]      FIG. 15  is an exemplary embodiment of job producer feed manager class  214 . Objects of this type manage production of the continuous job feed. In particular, job producer feed manager  214  manages the life-cycle of a one-depth buffer of jobs. The configuration source of deployer  108  may describe buffer minimum and maximum size, the frequency to refresh the buffer, and other parameters to efficiently manage the continuous job feed.  
         [0064]     Section II: Resource Management  
         [0065]     A resource is typically a reusable component that may mediate access to physical (e.g., COM port) or logical (e.g., JDBC connection) resources. According to framework  100 , a resource has the following characteristics. A resource can be created, given some resource specific context information; is capable of timing out (if appropriate for the type of resource being used); can be considered available or unavailable; can refresh itself to prevent being permanently unavailable, i.e., a rogue resource; and has the effect of propagating events when refreshed.  
         [0066]     A resource manager, such as job dispatcher  110  in  FIG. 1 , has the following characteristics. Job dispatcher  110  manages the resource pool in a thread-safe and load-balanced manner; handles addition and removal of resources from the pool; handles event propagation due to changes in the resource pool; and handles any resource changes external to the framework  100 .  
         [0067]     An exemplary implementation of resources and resource management system according to the present invention will now be discussed. The reader is reminded that resource management according to the exemplary embodiment occurs via dispatcher class  202  (corresponding to job dispatcher  110  in  FIG. 1 ).  
         [0068]     Referring to  FIG. 16 , an exemplary embodiment of resource class  1600  is shown. Objects of the resource class  1600  include the following methods. The “using resource” method  1602  enables a resource  1600  to register the fact that it is still being used. This method ( 1602 ) assists in the prevention of time-outs. The “register resource observer” method  1604  enables objects managing the resource  1600  to handle the resource&#39;s time-outs. The “initialize resource” method  1610  creates a new resource instance. The parameters to this method reflect broker interface context-specific information, where resource creation context information can be accessed. The “available resource” method  1612  checks if the resource is available. The “in-use resource” method  1614  indicates if the resource is in use. The “free resource” method  1616  makes the resource available again. The “alive” constant  1618  and the “block” constant  1620  require that the resource always be available (i.e., has no timeout) and require that a thread be blocked anytime the resource is unavailable, respectively.  
         [0069]      FIG. 17  illustrates an exemplary embodiment of a thread resource container class  1702  and a resource timer container class  1704 . Objects of the thread resource container class  1702  implement a thread as a resource, and objects of the resource timer container class  1704  manage timing of the threads with respect to time-outs, i.e., manages rogue resources. The resource timer container class takes a time-out time and a resource instance as parameters to manage such timing. As shown in  FIG. 18 , the resource timer container class  1704  works with the timed resource manager class  1802  to manage resources that have time constraint requirements.  FIG. 19  illustrates the addition of a resource that requires timeout management. An exemplary configuration of the timed resource manager class  1802  in the configuration source of deployer  108  is described in Section IV, subsection 3 below.  
         [0070]      FIG. 20  illustrates a pooled resource manager class  2000 . This class, used by dispatcher  110 , is responsible for managing the pool of resources. The pool of resources includes multiple instances of the job resource class  220 . Such management includes creating, deleting, restocking, and reusing the resource instances in the pool in accordance with the configuration source of deployer  108 . An exemplary configuration source for this class is discussed in Section IV subsection 2, and  FIGS. 38 and 41 ( 3812 ,  4102 ) below. As shown in  FIG. 20 , a resource is borrowed from its pool using the get instance method  2002  and returned using the free resource method  2004 . A resource is removed from the pool using the remove instance method  2006 . The relationship between pooled resource manager class  2000  and a resource  220  is illustrated in  FIG. 21 .  
         [0071]     Section III: Service Utilities  
         [0072]      FIG. 22  illustrates an exemplary implementation of pluggable service  122  ( FIG. 1 ). Pluggable service  122  completes the process of binding a job to a particular service at deployment time.  FIG. 22  includes a service definition  2202  and a set of interface rules  2203 . The boxes having names in bold in  FIG. 22  are definitions within framework  100 , and the other boxes are definitions provided external to the framework  100 . In particular, X.service  2204 , X.serviceBean  2206 , X.serviceRules  2208 , X.serviceSoapBean  2210 , and X.serviceHome  2212  are provided within the framework  100 . In the names of these definitions, “service” represents the name of the service or process to be made a distributed component and “X” represents a package reference in Java. X.serviceRules  2208  includes the rules necessary to implement the pluggable service. X.serviceBean  2206  implements the serviceRules  2208 . X.serviceHome  2212  is the implementation name of an EJB Home factory class. X.serviceSoapBean  2210  is an implementation of a SOAP service client.  
         [0073]      FIG. 22  illustrates that, in a local scenario, a service manager will return an instance of serviceRules  2208  interface provided by a serviceBean  2206  instance. In a remote scenario, a service manager is guided by configuration parameters in the configuration source to the type of remote service, e.g., EJB. In this scenario, the service manager then acquires, via the Home class, a remote reference to the service. The actual remote service then implements the serviceRules  2208  and the service is again provided by a serviceBean  2206  instance.  
         [0074]      FIG. 23  illustrates an exemplary embodiment of service broker helper class  2300 . Objects of service broker helper class  2300  act as a factory for the creation and/or access of a service. The method “get new service”  2302  subscribes to a service, and the method “remove service”  2304  unsubscribes to the service. The class delegates to a registered set of services that provide the life-cycle functionality for subscription and removal of a service. An exemplary configuration of the service broker helper class is described in Section IV, subsections 7 to 9.  
         [0075]      FIG. 24  illustrates an exemplary embodiment of delegate service class  2400 . Objects of this class manage service life-cycle management for a particular service middleware implementation.  FIG. 25  represents a SOAP1.2 implementation of this interface. Implementations may also be provided for EJB and SOAP delegate services. Any new service which a Job Resource delegates to via the pluggable service described here would require registration with the service broker helper class and an implementation of the delegate service interface.  
         [0076]     Referring to  FIG. 26 , a number of options are available to implement a JobResource service. To use the one described here, a client delegates to a service in the execute method, as shown in  FIG. 26  and example code in  FIG. 27   a - 27   c . This delegates to a service reference via the method getClientService( )  2602 , the kind of service defined in the ServiceReference.class.  
         [0077]     The exemplary implementation of the framework  100  uses a standard set of service types, such as “EJB,” “SOAP1.2,” “RMI,” and “ORB.” However, the invention is not limited to these services, and by design, is easily modified to accommodate other services. Each of these standard service types is expected to have an associated registration with the service broker as a delegate service implementation. The delegate service performs any caching required for efficient use of resources and the service broker helper manages any retries on a service type access failure. In the exemplary implementation, the default service is EJB, if the service type is not a registered factory reference. An exemplary EJB configuration is described in connection with the service broker class described in Section IV, subsections 7 to 9.  
         [0078]     Section IV: Exemplary Configuration Parameters  
         [0079]     The exemplary implementation of the configuration source of deployer  108  uses a Lightweight Directory Access Protocol (LDAP) structure for organizing the configuration parameters of the framework  100 . The hierarchy structure is three levels deep as illustrated in  FIG. 28 . A root node “factory”  2802  is the parent of a set of “context” nodes  2804   a  and  2804   b  that represent the name of the class to which the parameters belong. The context nodes  2804  have “rtclass” (record-type) nodes  2806  that contain the actual parameters for the class specified by the context node  2804 . Exemplary rtclass nodes for particular classes are defined in  FIGS. 29-37 .  FIGS. 38-41  illustrate exemplary parameter values stored in these rtclass nodes in a screen-shot format. By convention,  FIGS. 29-35  show default values in square brackets [ ], and optional values with a “[−]”. Another convention used by this specification and accompanying figures is to use the job representing the service or process fully qualified Java class name as context name (the service to run), e.g., if a job is defined as “a.b.c.d.MyJob.class,” the context would be “context=a.b.c.d.MyJob.” 
         [0080]     Exemplary configuration parameters in the configuration file of deployer  108  are now described in the following subsections.  
         [0081]     1. Dispatcher Daemon Configuration  
         [0082]     Exemplary configuration parameters for the dispatcher daemon class  204  are shown in  FIG. 40  at  4002  and the specification of the associated rtclass nodes is described in  FIG. 29 . The exemplary rtclass nodes are: 
        jobResourceClass  4004  defines the name of a Job Resource derivative conforming to the service pattern described. Note that this node will usually be the same as the context name.     jobProducerClass  4006  defines the name of the Job Producer class, which in this case is a JobFeedProducer reference  4008 .     argList defines further arguments to a dispatcher daemon implementation, specific in this case to the job to be executed.     pollTime  4010  defines the duration in milliseconds to wait to poll for a new job, or in this case this node is delegated to the JobFeederProducerManager instance (as it is an instance of a JobFeedProducer).     oneShot  4012  defines whether this process is a run only once (true) or is a deamon (false); so never finishes running.     jobMonitor  4014  displays processing information within the Dispatcher Daemon component.     jobRogueTimout  4016  defines a duration in milliseconds, which, if defined (i.e., not −1) represents the maximum time a job is expected to take to process; if it takes longer to execute than the value of this node, it&#39;s deemed a rogue process.     maxList  4018  defines the maximum result set size for a Job Producer to return. −1 means the complete result set is returned.     numberOfRetries (not shown in  FIG. 40 ) defines the number of times a dispatcher will re-run with failed jobs before giving up.     maxProducerPool  4020  defines the maximum number of pooled resources to be maintained in memory given that produced by a Job Feed Producer. This enables the size to be throttled to enable better memory resource management.     minProducerPool  4022  defines the minimum producer pool size reflecting the minimum number of pooled resources to be maintained in memory given that produced by a Job Feed Producer. This enables automatic refresh. This is a string as can be a percentage representation, e.g., 30% of the maxProducerPool  4020 , or a number reflecting the min number of resources maintained in the job pool.     blockUntilData (shown in  FIG. 29 ) defines that a JobFeedProducer will block a result set response if true if no data is available, up to 2 * pollTime milliseconds.     exitCode (shown in  FIG. 29 ) defines the exit code of this process on failure.        
 
         [0096]     2. Dispatcher/Resource Pools  
         [0097]      FIG. 41 , at  4102 , illustrates the exemplary configuration parameters for the resource pools managed by dispatcher  202 . The specification of these rtclass nodes are described in  FIG. 31 . The exemplary rtclass nodes are: 
        MinResource  4104  defines minimum resource pool size.     MaxResource  4106  defines maximum resource pool size.     WaitTime (not shown in  FIG. 31 ) defines the duration in milliseconds to wait for an event, in case there is an issue with a notification being lost, so a resource if available it will be picked up from by a waiting client.     BlockTime (not shown in  FIG. 31 ) defines the duration in milliseconds to wait for a resource to become available.          
         [0102]     3. Dispatcher/Timer Resource Configuration  
         [0103]     Exemplary configuration parameters for the resource timer container class ( FIG. 17 ) is shown in  FIG. 38  (rtclass=java:com/env/ResourceRef/TimerResource  3810 ). The specification of these rtclass nodes is described in  FIG. 33 . The exemplary rtclass nodes are: 
        NotAuto  3816  defines whether the timer to manage resource timeouts should run automatically.     WakeUp  3814  defines a wait to be notified timeout to resolve any issues of many clients trying to wake this process up to refresh a resource.        
 
         [0106]     4. Dispatcher /Thread Resource Configuration  
         [0107]      FIG. 38  at  3818  illustrates the exemplary configuration parameters for the thread resource container class ( FIG. 17 ). The specification of these rtclass nodes are described in  FIG. 34 . The exemplary rtclass nodes are: 
        name  3820  defines the thread resource group name     deamon  3822  defines whether the thread is a daemon thread     priority (shown in  FIG. 34 ) defines the priority of the thread.          
         [0111]     5. JobResource Configuration  
         [0112]      FIG. 38  at  3804  illustrates the exemplary configuration parameters for the job resource class  220 . The specification of these rtclass nodes are described in  FIG. 35 . The exemplary rtclass nodes are: 
        remote  3806  defines whether this resource is to process a remote job.     retryCount  3808  defines the number of times to retry the associated job on failure.          
         [0115]     6. Service Deployment Component Configuration Parameters and standards  
         [0116]      FIG. 39  illustrates configuration parameters for a process job service  3904 . The process job service  3904  includes a service broker configuration  3902  and an EJB configuration  3910 , respectively discussed in subsections 7 and 8 below.  
         [0117]     7. ServiceBroker Configuration  
         [0118]     The specification of the rtclass nodes associated with the service broker configuration  3902  is described in  FIG. 30 . The exemplary configuration parameters for the service broker  3902  are: 
        RetrieDelay ( FIG. 30 ) defines the duration in milliseconds to wait before service access is retried in a failure to access service scenario.     RetrieCount ( FIG. 30 ) defines the number of times to retry to access a service in a failure to access service scenario.     serviceType  3906  defines the tag representing the middleware type the service is represented as. In this example, the value is “EJB.”       
 
         [0122]     8. EJB Configuration  
         [0123]     The specification of the rtclass nodes associated with the EJB configuration  3910  is described in  FIG. 32 . It should be noted that although only a configuration for the EJB service is provided in the exemplary implementation, a configuration for all other available services would also be provided. The exemplary configuration parameter for this configuration is: 
        JNDI  3908  represents JNDI name of the EJB service as defined in an application server.        
 
         [0125]     It is to be understood that the above-described embodiment is merely illustrative of the present invention and that many variations of the above-described embodiment can be devised by one skilled in the art without departing from the scope of the invention. It is therefore intended that such variations be included within the scope of the following claims and their equivalents.