yes.. you are right.. why to use jPDL if you have a standard notation called BPMN 2.0. I know that it's not finished yet.. but it's being adopted by all the framework/products.
I think it is not a good idea to design your own language. jPDL should be capable to catch all your requirements. And jBPM 3 has even a more language possibilities than jPDL 4 by now. I haven't seen much requirements it could not implement.
For BPMN 2.0: That's the way to go for the future. But at the moment the engines are not yet far enough in my eyes. Definitely interessting, and if you have some time bevore you have to go live, than I would consider this option.
And even XPDL would be a better choice than an own language.
If you are Geman speaking you can find some more oppinions from me on that here: http://www.bpm-guide.de/2009/08/02/bauen-wir-uns-eine-bpmn-20-engine/
well i have been reading the docs since 2 days now and i can say that i have an 80% clear view on how jBPM works.
The engine is designed to support multiple DSL, so this is good. and i have also played around with the tutorial in Chapter 3.
I am new to this kind of development and i can see that sooner or later people will have the option to write a program/application using Workflows as the logic says everything can be turned into a workflow.
I am working with a team where one of the guys suggested to have the following architecture:
as you can see in the above picture, we are building a layer on top of PVM called SMD; all of our classes will extends the jPDL ones and add the extra methods/tags/whatever needed in order to have our own Process Definition Language.
the bcdl, brdl, bwdl are workflows definition that will extend the SMD structure but everyone has its own xsd schema.
For me i do see it as re-inventing the wheel; i just can't convince that guy that there's no need for that, he keeps on saying the following:
As we discuss before, we need to change the XML format from standard SMDL format
To the SMDL format (the SMDL format consist to define the activity under the step tag different from JPDL format).
In JPDL, we have just the custom tag that we can customize our step/activities.
So he wants a new language bc the custom tags will make the graph messy? or will be too much complicated/complex..therefore he decided to write his own tag definition but with extending 90% of it from jPDL
The other concern that i have is that we will be building our own graph designer using flex. so this might lead us to have our own DSL.
so i am still kinda lost in here and i thought of sharing this with you guys in case someone is interested to give feedback/comments
I have been reading JPDL documentation and realized that we can add our custom implantation java classes to handle workflows according to some business requirements
We achieve such customization by implementing
- Custom actions by implanting ActionHandler interface
- Decision handlers by implementing DecisionHandler interface
- Task assignment handlers by extending AssignmentHandler interface
- Event listeners by extending EventListener interface
- Custom external activity behavior by extending ExternalActivityBehaviour interface
- User defined java classes and scripts by using java and script JPDL tags
This can save lots of time and effort to develop a definition language and parser
I attached a file, that I got from JBPM documentationm, that contains examples on how to use the above listed handlers
- So can we use the above interfaces and implement them to have classes that behave according to our business needs?
- Is there a limitation to what extent we can control JPDL actions, decision, tasks, events, and activities behavior ?
customizing jBPDL.doc 130.0 KB