The informational aspects have been discussed in section 8.4. Also the need for data and control flow to support the implementation of the ICP has been clearly stated in section 8.6.3. The informational aspects are compared among the different systems in table 8.6.
Informational Aspect Kepler Taverna Triana Stateframe jBPM
Data flow X X X
Control flow X X X
Table 8.6: Informational aspects of different WFMSs.
Security Aspects
The security aspect depends on the organisational needs. Security can be a dominant require- ment for some systems while it is not even an issue to be considered in others. One of the ways of securing the system is setting rules to be met for access to the system where each task could be restricted to certain rules and even roles within those rules.
This is a very important feature that is associated with the business- workflows, as they allow human interaction. Here the roles and rules as well as the security constraints in term of access are identified. This is an important aspect required for the implementation of the ICP as at the different stages along the treatment, different healthcare providers get involved. Moreover, information along the treatment progress are targeted to a certain role and should be viewed only by this person. This is in addition to the multiple system across the multiple organisations that are involved and therefore the security constraints that need to be placed. The availability aspects to support security settings, rules and roles is shown in table 8.7.
Security Aspect Kepler Taverna Triana Stateframe jBPM
Rules and roles X X
Security X X
Table 8.7: Security aspects of different WFMSs.
8.8
System Choice
We specified in section 8.6.3 the required characteristics in the WFMS to support the ICP. We then compared different WFMSs in different aspects in section 8.7.2. At this stage, we need to select a WFMS to use in the implementation of the proof-of-concept prototype.
88 8.8 System Choice
According to sections 8.6.3 and 8.7.2, we need a WFMS that supports the behavioural aspect, is activity-based, the informational aspect to be data and control driven, and the functional aspect to support workflow patterns. Consequently, the paradigm is of a business workflow supporting human interaction and setting timers as organisational aspects and supporting roles and rules as well as security as security aspects.
Stateframe and jBPM are the only systems within the studied WFMSs that support activity- based (see table 8.5). These systems also support the control flow in addition to Taverna (see table 8.6). Data flow is supported by Kepler, Taverna, and Triana only (see table 8.6). This means none of the systems are activity-based, data and control driven. However, Stateframe and jBPM can manually support data-flow. This limits our choice to Stateframe and jBPM when comparing the behavioural and informational aspects.
In the comparison of the functional aspects (in section 8.6.3), workflow patterns were discussed. These include constructing complex analysis, building hierarchal workflow, including iterations, and including logical conditions. These were all supported equally by all the systems except Triana which did not support building a hierarchal workflow (see table 8.3). This is particu- larly important to ease the implementation of the complex process in ICPs. Functional aspects concerned with locating and using services are not one of the main requirements of this project. Aspects such as the ability to progress individual objects and the support for RAD are important. Table 8.3 shows that only Stateframe supports these features. This makes Stateframe preferable at the functional level.
Finally, we stated in section 8.6.3 that we need a business workflow. This is to support human interaction and security constraints. Table 8.1 and table 8.7 shows that Stateframe and jBPM are the only systems that support these two aspects combined.
The Choice of a WFMS
At this stage, the choice is limited to Stateframe [24] and jBPM [227]. As they are both business process workflow management systems, there are a lot of similarities between them. They are similar in the type of workflow and the type of flow, in that both are activity-based and support control-flows. Data-flows are needed but can be included manually when implementing the process.
One of the major differences between them is that jBPM is open-source, while Stateframe is a commercial software product. Here the trade off between commercial and open-source soft- ware arises. In this comparison between these two approaches, issues such as cost, flexibility, security, end user support, compatibility and integration are considered [243]. The main issues
8.8 System Choice 89
related to our project are the cost and the support provided. Here Stateframe is preferred over jBPM because of the support provided from its vendors in setting and operating the system. The second major difference between Stateframe and jBPM is the visual interface provided in Stateframe, which increases its usability by supporting building and designing workflows. Al- though jBPM does provide a library which can be used by the developers. Having the supportive interface in Stateframe saves time and effort and reduces the errors that can occur during the implementation process. This also makes Stateframe preferable over jBPM.
The third major difference is the support for distributed technology, which is the ability to com- bine with web services. jBPM supports distributed technology, while Stateframe only supports the use of backing hardware for remote components. This covers part of the advantages of web services. Hence jBPM is preferable over Stateframe on this point.
Moreover, Stateframe supports extra functionalities which jBPM does not have for progressing individual objects and supporting RAD of new components.
Finally, JBOSS will provide installation and technical support through its online forum while Stateframe developers will support the installation and give the technical support in person. By looking at the identified factors needing to be considered when making the choice of the WFMS to be used, we found that the advantages that will be gained from using Stateframe are more than those gained by using jBPM. Therefore, Stateframe was chosen to implement the proof of concept prototype for this project.
91
Chapter 9
Architecture of Proposal System
Overview
This chapter explains the architecture of the proposed system, WffICP. The architecture will position the proposed system against the current CISs and show how the CIS’s functionalities could be evolved. This will be followed by explaining the architecture of WFMS used in the project. Finally, the technical details of how the proposed system works will be presented.