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:01:16 UTC