In order to build such a form and to process the data submitted through it you’d need some kind of data type description associated with the process definition. Even if you don’t intend to build those forms at runtime, but instead chose a design time approach you would still be left with the question of validation.
But not only that. The tooling that helps you build the task forms at design time would need some data type description as well. How would know what types to chose for UI elements and the keys to access it?
This leads to an additional requirement: Once you got the data type description and you successfully modeled your form, how do access the data at runtime? Somehow the process data needs to extracted and displayed through the forms.
One thing you may realize at this point is that a simple example like the task management forms already require type information across BPM components. It start’s with the tooling, is used to extract data at runtime and finally describes how the forms should be rendered.
One thing that jumps to my mind XML and XSD. Ok, I admit that I have been working on the JBoss web service stack, but other problem domains chose such a solution as well. Just think of heterogenous (i.e. ESB) or event based systems (i.e. CEP). And they do so for good reasons:
- You get a data type model that supports structured and simple types
- It can be validated through XSD
- Access to the data can either be done programatically or through XPath
- Data can be represented in Java or XML
If you add XForms to the picture we are one step closer to solving my initial task management problem: Describe your data types through XSD, extract it by using XPath and display it through XForms.
But there’s more to it: Decoupled producer and consumers in SOA, in which BPM plays in important role, would greatly benefit from such a type system as well. Any invocation between a process and a service could then be constrained to the type information at hand.
4 comments:
I took a very similar approach using XForms to solve task management with jBPM. Its a shame browser support for XForms is terrible. We also used XSD for the datatyping of process variables. It worked very well. I hope this gives some validation to your ideas.
I to use XForms, but have no problem with the lack of browser support since I use Chiba. A server-side XForms solution that provides html (dojo components provide the look-and-feel) to the client and uses ajax (dwr) to update the server-side model and do all kinds of validations.
The XForms can be either created runtime based on an xsd or created design-time and be manipulated a lot. JSF, GWT etc are not usable for this imo.
Regarding the decoupling, I made sure my process based application does not care where the xml message comes from. Be it a b2b messaging system, an esb or the XForm 'front-end'. I do need some additional metadata for which I took the ebxml messaging terminology. Service refers to the processname, action to the taskname, conversationId to a processInstance and I need sender/recipient and their role. Works great. I can return all kinds of default error like 'message does not fit in the flow', 'invalid action', 'invalid messageType' etc..
I added the required messageType to the jBPM processdefinition and use this by reading the processdefinition.xml from the database, make a Document out of it and extract my additional config items via xpath. All this without customzing the the task-node or whatever.
So personally, I'd go for XForms and add some loose coupling, probably kind of what Thomas has in mind for the 'messages' in jBPM4
Thanks, for your feedback. The browser support for XForms is terrible, but you move that to an XForms server like Chiba or Orbeon (http://www.orbeon.com/)
I think the problem should be regarded at two levels: Support for data type descriptions on the one hand and a form solution on the other. XML + XSD supply the first, adding XForms the later.
@Rex: Interesting. We'll take this discussion to the forums soon and I would appreciate your input there. Maybe you are even intersted in contributing to a solution for jbpm4?
take a look of cforms:
http://cocoon.apache.org/2.1/userdocs/basics/index.html
it is a framework based on the xforms ideas (problem is how can adapt it to the console).
Post a Comment