David Forslund wrote:
>
> We have been using workflow engines for a while. The one I happen to
> prefer is Shark (http://shark.objectweb.org)
> <http://shark.objectweb.org%29> which is quite robust and
> uses standard WfMC's XPDL for the workflow representation and that it
> supports both Web Services and the OMG CORBA workflow standard. The
> lack of interoperability in workflow models is a major impediment. We
> worked with the City of Hope for three years to try to come up with the
> fundamental generic workflow for clinical trials, but didn't finish the
> task. My main interest in XPDL is that it separates out the workflow
> definitions from the implementation of workflow. The popular BPEL seems
> to confuse this issue, at least as I see it. Getting some agreement on
> the basic workflow elements for healthcare that might be shared would be
> quite interesting and valuable, in my opinion.
During last last year I read 3 clinical workflow PhD dissertations, and
spent a fair bit of time looking at BPEL, XPDL etc. My conclusions when
struggling to see what was "the" workflow model to use to represent
workflow were:
a) none of the models I reviewed did everything needed
b) I realised one day that the right way to represent such semantics is
in a programming language-like syntax, rather than the object model
form. The reason for this is that a syntax and parser approach are far
more amenable to understanding a problem domain; it is only when it is
completely sorted that you can afford to publish object models.
c) such a language needs to have all the temporal operators required by
workflow, including all the synchronous/asynchronous branching, split &
join operators and so on. I can imagine a modified version of current
programming language syntax might go close to this. The advantage is
that the language can be improved over time, but previous workflows will
still compile (if the compiler builders take care); whereas object model
representations are usually left out in the cold because they are the
equivalent of what the compiler generates (the parse tree), not the
input, whose syntax might not change, but whose meaning might.
d) the XML-based attempts really suffer from not having an abstract
language. XML is just a transfer syntax. When will people start getting
this? (do you read OWL in XML-RDF? Of course not, you read it in
OWL-abstract; do you read .class files or .java files? etc....). Worse,
XML models are actually direct serialisations of structural object
models, they are not any kind of syntax. It is too early in the learning
curve of this area to be committing to object models.
I agree with Dave that this area is interesting and important to sort
out. I'll put the PhD thesis links on openEHR.org - they are all a
great read.
my 5c
- thomas
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/openhealth/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
