Page 275 -
P. 275

10  The Resource Service                                        271
                              Even though there is necessarily a certain volume of data passed from the engine
                           to the service and back again, one of the fundamental design goals of the service
                           was to minimize data passing to the greatest possible extent. One way it has been
                           minimized is through the utilization of various data caches on the service side – see
                           Sect. 10.4.2 for more details.
                              In addition to the engine interfaces, the Resource Service provides three inter-
                           faces of its own:

                             Interface O is the Organizational Model Interface, providing the means to use
                              organizational data held in external data sources, rather than the default inter-
                              nal YAWL Org Model. Any type of external data format may be used; an
                              abstract DataSource class is provided, which must be extended by each client
                              to map the external org data into the format required by the service, called a
                              ResourceDataSet – essentially a set of five maps, each a mapping of unique iden-
                              tifier – populated YAWL resource object pairs (i.e., Participant, Role, Position,
                              OrgGroup, and Capability).
                             Interface R is the Resourcing Interface, which externalizes the organizational
                              data managed by the service via a set of API methods, thus providing custom
                              services (and particularly the YAWL Process Editor) with a means of accessing
                              the YAWL default org model contents and codelet list (all data are exposed as
                              read-only through this interface).
                             Interface W is the Workqueue Interface, which externalizes the mechanisms of
                              the internal worklist handler, allowing external applications and custom services
                              the means to provide alternate worklist visualizations, rather than the default
                              worklist forms provided with the service. This interface supports and exposes
                              the full set of resource patterns handled by the service.

                              The Process Repository is a data store (i.e., local disk or URL) holding the set
                           of process specifications created via the Editor, from where they may be loaded
                           through the service’s administration tools into the Engine. The Event Logs is a data
                           store (again, local disk or URL) where a process log is written containing all resourc-
                           ing decisions made for each work item handled by the service. The service supports
                           administrators and users via a number of web forms.



                           10.4.2 Internal Architecture


                           Figure 10.5 is a representation of the internal structure of the Resource Service and
                           shows its primary components and the major relationships between them. At the
                           core of the service is the Resource Coordinator, which is the hub for all traffic into
                           and out of the service via all six interfaces, and is responsible for communication
                           between, and coordination of, all of the composite parts of the internal service.
                              To minimize data traffic across the interfaces (described in Sect. 10.4.1), the ser-
                           vice makes extensive use of data caching. First, when the service starts, the entire
                           organizational data model is loaded into memory-cached data structures, which
   270   271   272   273   274   275   276   277   278   279   280