CHAPTER 7

CONCLUSION AND FUTURE WORK

7.1 CONCLUSION

Workflow technology cuts across the boundaries of organizations to reach a larger number of users, resources and tools, to offer tremendous opportunities for streamlining business processes and gaining unique competitive advantages in software reengineering. Workflow management offers a powerful technique to cooperate, integrate and automate different business tasks for today’s organizations, yet preserves the diversity of these tasks for specialized functions used by the organizations. However, most WFMSs (either commercial or research prototype) offer little or no support for the scalability, reliability and robustness, and these are critical to commercial software products. Such limitations of current workflow products prevent them from becoming the backbone of corporate computing.

In this thesis, we have designed and implemented a reasonably scalable and reliable CORBA-based centralized engine for the METEOR₂WFMS. For scalability, the NEOWork run-time architecture is strongly based on the object-oriented concept. The run-time components (schedulers and task managers) of NEOWork are dynamic CORBA object instances which have their own lifecycle in the system. They can be created dynamically by their component factories as needed to handle new workflow instances and tasks, and will be destroyed after these workflows and tasks complete.

The other major contribution of this thesis is the design of the CORBA-based recovery framework for NEOWork, which supports the run-time failure handling and recovery in the context of the METEOR₂WFMS. We have incorporated a hierarchy of recovery components that synchronize the execution of WFMS components, detect their run-time failures with the try-catch block and recover the components based on the well-defined recovery processes. We also have designed and examined the ability of object persistence service to support the persistence of state of WFMS components, which leads us to conclude that the object persistence service is a feasible way to facilitate persistence logging for workflow recovery. Although the recovery framework is designed based on the METEOR₂workflow model, the ideas can be extended to support run-time reliability in the context of other WFMSs.

We have also designed a mechanism to bypass the use of CGI scripts as the hook for Web-based applications to communicate with the CORBA world. The interface server supports the direct socket data communication between task managers and user tasks with Java interfaces so that run-time errors of the communication could be detected and handled in a programmable way. It is important to note that this design was done before OMG supported the IDL to Java mapping in CORBA products.

A prototype implementation of the NEOWork architecture has been achieved successfully and demonstrated with the immunization-tracking workflow application. The implementation also shows an example of using CORBA object services, such as, the Naming Service, Life Cycle Service, Object Persistent Service, Event Channel Service and Concurrency Control Service to support the WFMS implementation.

7.2 FUTURE WORK

Finally, in this section, we outline some suggestions to improve the design of NEOWork as well as some future research possibilities.

Sun provides an IDL-to-Java compiler (JOE) that makes GUI clients written in Java able to communicate with NEO objects directly. One could design a Java library for the GUI development of METEOR₂user tasks.

Logging of current component states during the system run-time is done through the PSM operations. We assume that these operations are transactional in nature so that no updates will be lost in the case of failures. In the future, using the object transaction service defined in the CORBA 2.0 specification will guarantee the atomicity of updating component states.

NEOWork uses centralized scheduler engines to scheduling workflows. Although each scheduler object is only responsible for one workflow instance, if a workflow contains a lot of tasks running currently, message exchanges between a scheduler and task managers may cause a bottleneck. Therefore, a distributed approach for workflow scheduling is recommended in the future WFMS architectural design (see ORBWork, [Das97]).

The current implementation of NEOWork does not incorporate a deadline mechanism for task scheduling. But in the real world, workflow tasks should be completed in a certain amount of time. The deadline attributes should be seen as one of the inter-task dependencies and can be enforced by schedulers at the run-time.