RE: xforms and wokflow?

Hi Bob,

I wouldn't want to belittle the task, but I have to say I'm not that
impressed with the current generation of 'workflow engines'. Just as XForms
gives us a nice layer of abstraction over the behaviour of a UI, I can see
it evolving to provide a layer of abstraction over many 'tasks' that would
need coordination, and indeed the notion of coordination itself.

However, at the same time, your points are exactly right, and it's good to
hear that you are getting good results with existing tools.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: rob.bull@blackdog.co.uk [mailto:rob.bull@blackdog.co.uk] 
> Sent: 19 August 2005 13:01
> To: Mark Birbeck
> Cc: jeacott@hardlight.com.au; www-forms@w3.org
> Subject: Re: xforms and wokflow?
> 
> Hi Mark, Jason, et al. 
> 
> For the record, I have worked on a couple of proof of concept 
> apps using a proprietary Workflow Engine (Metastorm) for the 
> back end and xForm for the front; both client side xForms 
> with FormsPlayer, and Transcoded xForms with FormFaces, and 
> have achieved very pleasing results. Admittedly this is 
> probably more using xForms as "codeless" web applications 
> delivered via a workflow method; but the technique utilises 
> the dynamic and multi-integrational capablities of xForms 
> with the process management capacity of a BPM tool. 
> 
> Even if the xForms spec eventually includes some element of 
> workflow as part of the submission, I think that complex 
> systems would still need some kind of data driven tool for 
> managing groups, roles, reportees and their managers etc, etc. 
> 
> When you consider that some process take months or years to 
> complete, the need for data management and manipulation, and 
> generally the length to which BPM tools have already evolved, 
> I would say that xForms, much as I love it, would have to go 
> a long way to replace the proprietary worflow/BPM solutions, 
> HOWEVER it already goes a long way to enhancing them.
> Regards 
> 
> Rob 
> 
> 
> Mark Birbeck writes: 
> 
> > 
> > Hi Jason,
> > 
> > Once people move beyond basic forms to serious 
> applications, then the 
> > most common questions they raise concern workflow. For 
> example, we are 
> > working on a substantial project for a customer where they have a 
> > complex workflow defined. But at various points that 
> workflow needs to 
> > retrieve information from users. The question becomes, should the 
> > workflow pause and give the user a large form, let them 
> fill it in and 
> > then only move on when it has the complete results? Or should the 
> > workflow break the task into sub-tasks, and therefore give the user 
> > many smaller forms -- one for names and addresses, one for 
> the product 
> > they want to buy, a different one depending on whether they 
> are a smoker or a non-smoker...and so on.
> > 
> > The latter seems to fit more with how people consider 
> workflow engines 
> > at the moment, but the former is by far the better 
> experience for the 
> > user, and actually easier to manage for the developers.
> > 
> > 
> > USER EXPERIENCE
> > Treating the whole thing as a high level task gives the 
> user a better 
> > experience, since they can then do things like work 
> offline. Filling 
> > in a tax return, for example, is the type of thing you 
> might need to 
> > do disconnected from a server, since it can take a while. (And it's 
> > certainly the kind of thing you *wouldn't* want to do in a 
> traditional 
> > HTML form.)
> > 
> > 
> > DEVELOPMENT
> > It's also easier to manage, since a lot of functionality is 
> > encapsulated in the form, which means that you have flexibility in 
> > using different back-end systems. One of the (many) really powerful 
> > things about XForms is that it talks nice and easily to 
> REST and web 
> > services systems, meaning that your 'back-end' gets very 
> clean -- once 
> > you have produced the web services that you need, you're 
> more than half-way done.
> > 
> > 
> > But that of course brings us to your specific question; you 
> are saying 
> > that given XForms can express so much of our workflow, why would we 
> > want add a further layer to get BPEL to orchestrate? I 
> agree. XForms 
> > actually has much of the functionality that you would need to 
> > synchronise various actions in the way that you describe. And given 
> > that it has an eventing model it is extremely flexible 
> compared to other workflow languages.
> > 
> > But all I can say is that, today, we are not there yet. 
> There is work 
> > underway on the XForms Working Group to make the submission 
> side into 
> > a separate specification that could stand alone. This will 
> take us a 
> > long way in the direction you want, since it could easily be 
> > implemented in non-client systems.
> > 
> > And what you would also need would be for XForms to have 
> the ability 
> > to be 'paused' whilst waiting for external input, such as an email. 
> > This is something we are working on with formsPlayer -- in 
> particular 
> > the idea of having a list of forms that are at various 
> stages of completion.
> > 
> > So although I'm giving you bad news for today -- you 
> probably need to 
> > use your workflow engine to orchestrate the things you have 
> described 
> > (although I would reflect the status back to a form, so 
> that XForms is 
> > still in the driving seat) -- I think the things you are describing 
> > are a 'must have' for XForms in the future, and I can certainly say 
> > that we plan to help make sure they are implemented over 
> the coming period.
> > 
> > Best regards,
> > 
> > Mark
> > 
> > 
> > Mark Birbeck
> > CEO
> > x-port.net Ltd. 
> > 
> > e: Mark.Birbeck@x-port.net
> > t: +44 (0) 20 7689 9232
> > w: http://www.formsPlayer.com/
> > b: http://internet-apps.blogspot.com/
> > 
> > Download our XForms processor from
> > http://www.formsPlayer.com/
> > 
> >> -----Original Message-----
> >> From: www-forms-request@w3.org
> >> [mailto:www-forms-request@w3.org] On Behalf Of Jason Eacott
> >> Sent: 19 August 2005 04:37
> >> To: Sikora, Gary
> >> Cc: www-forms@w3.org
> >> Subject: RE: xforms and wokflow? 
> >> 
> >> 
> >> ok,
> >> 	so if I were using formfaces (it shouldn't make any
> >> difference) then how would you approach the problem? 
> >> 
> >> thanks. 
> >> 
> >> 
> >> Subject:        	RE: xforms and wokflow?
> >> Date sent:      	Thu, 18 Aug 2005 23:49:08 -0400
> >> From:           	"Sikora, Gary" <gjsikora@progeny.net>
> >> To:             	<jeacott@hardlight.com.au> 
> >> 
> >> > Try ForeFaces and we can help ... Cleaner approach ... 
> No division 
> >> > between server-side and client-side processing ...
> >> > 
> >> > Very respectfully,
> >> > Gary Sikora, FormFaces Product Manager
> >> > 
> >> > -----Original Message-----
> >> > From: www-forms-request@w3.org 
> [mailto:www-forms-request@w3.org] On 
> >> > Behalf Of Jason Eacott
> >> > Sent: Thursday, August 18, 2005 22:51
> >> > To: www-forms@w3.org
> >> > Subject: xforms and wokflow?
> >> > 
> >> > 
> >> > Hi,
> >> > 	heres a use case I have to implement, and I'd sday its
> >> a very common
> >> > scenario. I already have an xform that can define and 
> build simple 
> >> > xforms (an xform builder form :)  ).
> >> > the forms it builds can submit the data to any number of email 
> >> > addresses and optionally send it to a data sink too (it
> >> always sends
> >> > it to the sink if no email addresses are assigned)
> >> > 
> >> > ok - so now I have to implement a simple workflow into 
> the system.
> >> > after one of these generated forms (just a plain old xform
> >> - we could
> >> > have started the story here but I thought some background
> >> might help -
> >> > hope it doesnt confuse) is made it gets used.
> >> > when a user fills in a form and submits the data, that data
> >> needs to
> >> > be approved before it is stored/emailed. it may need to be
> >> approved by
> >> > multiple folk, so using a workflow engine would make sense.
> >> > 
> >> > is there any way to intercept the processing of an xform so
> >> that I can
> >> > accept the submission, send out other emails for
> >> confirmation on other
> >> > forms, and then somehow ask an xform to complete its tasks.
> >> > I can see how I might have one form that just submits, 
> then do some 
> >> > serverside logic for the workflow , get another form for
> >> answers, then
> >> > just write code serverside to dump  the data into the sink,
> >> and send
> >> > off the various email responses if the data is approved,
> >> but how could
> >> > I achieve this last part by letting the xform do all that
> >> (because it
> >> > already knows how to) I may have an advantage that I am
> >> using chiba -
> >> > serverside xforms implementation, so perhaps I could
> >> instantiate half
> >> > a form serverside or something.
> >> > I run across this kind of thing all the time with xforms, I
> >> don't want
> >> > to break up my simple definition of what data should go 
> where - it 
> >> > works well all described in a simple xform, I just want to
> >> insert some
> >> > workflow before it completes. how can i do this kind of
> >> thing without
> >> > getting REALLY ugly?
> >> > 
> >> > any thoughts appreciated.
> >> > thanks
> >> > Jason.
> >> > 
> >> >  
> >> 
> >>  
> >> 
> >> 
> >  
> > 
> >  
> > 
>  
> 
>

Received on Friday, 19 August 2005 12:52:01 UTC