Distributed Resource Management System for Business Process Management Systems

I did my final year research on Distributed Resource Management System for Business Process Management Systems. I have shared my research abstract which was published in UCSC researh symposium 2011 here with. For the purpose of research evaluation and demonstration, RESTful Distributed Resource Management System (DRMS) engine has been developed and integrated with one of FOSS BPMS.

Business Process Management (BPM) is a discipline which maps human tasks and non human tasks according to a predefined workflow in a way that technical and non technical people in the organization can administrate, monitor and communicate effectively and efficiently. Considerable amount of BPM software are available to automate business processes. When business becomes more complex and needed to be expanded or out sourced, a single BPM server may not be sufficient to tackle all these processes. This may lead to manage several BPM systems within one organization. However if those servers are not properly connected and configured, even allocating a single resource for a single BPM system can also be difficult due to the lack of information available at a glance. Apparently a mechanism should be established to enforce cooperation among homogeneous BPM systems.

DRMS for YAWL is a distributed resource management system which leverages administrative activities like monitoring, decision making and scheduling for YAWL, an open source Business Process Management System (BPMS) developed by YAWL foundation. When business is needed
to be expanded to cope with internal or external transactions, organizations should have to increase their technical servers from one to several. At this stage when each of these servers is dealing with organizational processes (business processes) instead of writing their own logic to tackle with business, they can use existing BPM engines to get efficient and effective results. While using several BPM systems within same organization, accurate coordination among each is
highly required to place correct decisions and schedules. Placing a new business process tends to be difficult if the administrator cannot deterministically come to a conclusion, in which BPM engine he should place the new process. In fact that is what DRMS is trying to solve.

DRMS uses existing resource patterns and introduces some new patterns to cope with distributed resource management. DRMS is equipped with two major perspectives called snapshot view and rule execution. In snapshot view, global synchronized view and non-synchronized view are considered. Synchronized view is what administrator can get as a real global view of all resources in BPM cluster. Non-synchronized view lets administrator to explicitly decide in which distributed BPM servers’ view he tends to view in a given time independently from other servers. Before making decisions when managing resources distributed across a cluster of servers, it is more important to analyze the current state of the cluster; thus, we came up with this idea of global view. For this, we have extended few resource patterns where more significant and important features of a state of the cluster can be extracted easily. By thoroughly analyzing, we manipulated several key factors of functions which must be available in any view, to speed up the process of making more effective decisions. The idea of granting administrators both synchronized and non-synchronized views can leverage identifying different states of the cluster before executing the correct rule set. There administrators of the organization can analyze independent views by switching among each of BPMS by standing with a single interface of DRMS. This is facilitated in non-synchronized view. Gradually when cluster expands, implicit information gathering from cluster by the system is more efficient and it is facilitated by synchronized global view.

Views help to decide on decisions that are going to be made. In fact to execute those decided decisions, there should be a distributed rule execution mechanism for DRMS which is called rule implementation. At the moment these rules can be evaluated and put in to action in the synchronized view. Distributing resources according to capabilities, roles or positions and assign administrative access levels to employees are two patterns which are implicitly available in DRMS. Distributing newly available work items (processes) among BPM cluster based on how similar kinds of processes were executed in history is an advanced solution. Mutual and union resource extraction and updating the cluster through global flooding with or without a restriction are some sub patterns that are also available in DRMS for YAWL.

DRMS also supports for load balancing up to some extent. Workflows will be deployed according to the selected load balancing algorithm. Four suggested workload routing algorithms namely random, round robin, priority and dynamic help to adjust the load of the BPM cluster as determined. At the moment DRMS has been developed to work with YAWL BPM engine through mainly communicating via its resource engine. However one of the key features of DRMS is that its implementation is completely independent from YAWL’s implementation issues. That is, DRMS calls to YAWL remote functions via RESTful service calls over HTTP and in order to facilitate this DRMS service, it would be more appropriate to have a homogenous BPM cluster. That means each and every BPM engine should be from the same vendor or otherwise must be same open source product. Apparently, in reality, it is very rare that a particular organization may use different kinds of BPM engines within their domain as it adds performance and scalability issues while integrating, controlling flow of events, associating data and handling exceptions due to different architectural implementations of each BPM systems.

Main objective of this project is to show that if managing several BPM engines, by using a mechanism which is equipped with view analyzing and rule execution by extending standard resource patterns and introducing some new resource patterns to fit with a BPM cluster, both resource and work item scheduling can be orchestrated more easily and effectively. It adds a central accessibility for all distributed engines. Hence, we suggest by applying our studies to existing BPM systems, both local and global contexts will be implicitly available for customers unlike existing BPM engines support only for resource management within its local context. Therefore, as distributed resource management among homogenous BPM engines via work flow patterns is not yet ported, we hope our research findings will be useful in coping with similar kinds of situations in future emerging extensible Service Oriented Architecture (SOA) based BPM engines.