At 01:49 PM 20-03-01 -0800, Andrew po-jung Ho wrote: >The promise of merging openflow and OIO, it seems to me, is to give >extensible data objects to openflow and give time and criteria dependent >task management to OIO. As I have been designing the "studies" metadata >for OIO, I repeatedly come up with solutions that look exactly like >workflow systems. I am sure this is the case in all business and heath >information systems. Hopefully, we will be able to come up with a solution >that will be sufficiently extensible and interoperable with other >"plug-and-play" workflow systems. That is what "open" means in "Open >Infrastructure for Outcomes". I fully agree that most applications have a significant workflow component and that we have reached a point where this becomes more and more apparent and explicit. It is great that OIO breaks ground here! >What I like about the PROforma system is that it has been designed and >applied to the same problem space that OIO seeks to address (medical >treatment/research). The big question, however, is whether it is >extensible enough to support other applications of workflow (e.g. Bud's >Laborary system). Even if it is not based on an OMG standard, it _may_ >still be a good open standard. (Whether or not it is "open" remains unknown.) > >Bud, do you think it is reasonable to start with PROforma and extend it to >serve as a more gereric workflow engine? In my current way of thinking, I rather see PROforma as an application on top of a generic workflow system than the other way around. <quote>The PROforma language structure is based on a simple but versatile clinical process model referred to as the "dominio model".</quote> (figures 1 and 2 in http://www.acl.icnet.uk/PUBLICATIONS/ms364.pdf). This dominio model seems to be the basis for the definition of PROforma's formal semantics. In my reading, this implies that the process model is clearly specialized (and thus not general). Some sections of the paper show workflow processes as "task networks" (also called "object-oreinted view". While this makes the impression of generality, I understood that the object view has more to do with making the process model accessible to users (through a GUI) than with defining the process model. So the main point is that the dominio process model is highly domain specific. I'm thinking aloud here, comparing PROforma to the general process model of the WfMC to try to find other possible differences (please correct where necessary): PROforma's Enqueries and Actions roughly correspond to WfMC's Activities; Plans seem to correspond to Processes; Decisions are comparable to WfMC's Process, and Decisions are loosely related to And/Or-Joins/Splits. One of the major differences I see are in the expressiveness (and level of specialization) of Decisions/Joins/Splits. Obviously, PROforma--being a decision support tool--gives much more "meat" to the decision aspects. Another significant difference of the PROforma and WfMC approaches that I sense is that PROforma's process model explicitly includes resource (patient data). WfMC's deals very little with resources and an RFC for a resource model seems to be out only now. This is my reasoning for thinking that it may be possible to implement PROforma on a general purpose workflow engine but not the other way around. >How different are PROforma and OpenFlow in terms of the range of workflow >that they can model? I believe PROforma is specialized and OpenFlow much more generic. Therefore, it seems that it is difficult to apply PROforma outside its domain, but possible to specialize OpenFlow for various applications. The question of how resources are treated in the workflow model is actually a quite interesting one, possibly directly related to what kinds of applications a workflow model (system) can support. It seems that no standardized solutions are ready (see mention of WfMC's RFC above). Some applications give very little importance to how resources interact with the workflow process. This is typically the case where resources are data that sit in some repository and can be used (at least read only) without limit and concurrently from many actions/tasks. In other apps, such as LIMS, resources have a quite central role in the workflow. In a lab the main resource are samples/specimen. They exist physically and have to be moved around, subsampled, etc. The LIMS should be able to track these resources as they move through the lab (guided by the work process). Another class of resource-centric workflow are bioinformatics applications. Systems such as PIPER (open source, but alpha or pre-alpha) (http://bioinformatics.org/piper/) and Khoros (http://www.khoral.com/ideas/technology/cantata.pdf) actually speak of data flow (generalizable to resource-flow) and model how data/resources move around in the process. Every action node has then input and output resources. In my thinking, this is also the most natural approach for LIMS applications (see http://www.sistema.it/labinfo/topics_3.html#Relationships between Entities). >How hard would it be to make PROforma interoperate with one of the generic >workflow standards? Conceptually, I believe the limiting factor is the process model. On the surface, it seems that a PROforma workflow definition may be translated into the WfMG Process Definition Language, but the reverse is not true in the general case. This probably means that a 3rd party workflow engine cannot ask a PROforma engine to enact a workflow defined outside PROforma. It can however request the enactment of an already defined PROforma process. A PROforma workflow engine can possibly request a WfMC workflow engine to enact a process defined within PROforma--but all the special decision support features would get lost on the way... But take all that as a very rough line of thought... Looking forward to your comments and see whether you understood PROforma the same way... cheers --bud /----------------------------------------------------------------- | Bud P. Bruegger, Ph.D. | Sistema (www.sistema.it) | Via U. Bassi, 54 | 58100 Grosseto, Italy | +39-0564-418667 (voice) | +39-0564-426104 (fax) \-----------------------------------------------------------------
