Some quick comments:
- I'd only put the SLA params (avg expected time) in the processdefinition
- Maybe a DSL for simulation/scenarios is interesting. Tom loves DSL's
Even for the simple cases I'd not put it in the processdefinition, at least not without it's own namespace (but that is also the discussion with the GPD file, form info etc...)
I remember that discussion, yes ;-)
But I still think it is a very easy way to get started, just add some simulation parameters here and there in the existing process-defintion and run it. I don't want to mess too much required additonal XML files here...
Can you give some more conrete thoughts what you mean with DSL in this context?
Don't get me wrong, I am hugely in favour of embedding the GPD and Form info (not the forms themselves, althoughhh....) in the processdefinition. But I want them t o have their own namespace. But you probably also remember that.... btw... Tom is in favour, Koen is, only one person that is (was?) against this is Gavin (yes that one). But now for Seam they also thinking of embedding some seam related meta info about a page in the xhtml of the page and not in the pages.xml so.... who knows.
About the DSL ;-) Google is your friend
One of the blogs points to: http://www.martinfowler.com/bliki/DomainSpecificLanguage.html
e.g. Drools/JBossRules has some things in this area where you can even create a DSL (although still rules related)
Some other links:
http://www.infoq.com/news/domain-specific-language-debates (love this site!! one of my favourites, some nice discussions on WS-HELL)
Okay, a small misunderstanding here ;-) I know what's a DSL, my problem was how to apply it here.
But if I read it right between the lines, you mean to have a XML-based "DSL" to configure the scenarios. I wouldn't have called it DSL in this approach, but I think you can.
But the name DSL maybe strengthen the idea to make the scenario description a bit more general, no tied to jPDL or even jBPM, but "only" for simulation scenarios of business processes.
Basically, I like this idea, but I think I prefer a two way approach then: Embedding in the process definition (namespaces or not) for fast and easy use, and an own scenario description XML file (some kind of DSL if you wish) for more complex scenarios (information there override the "inline" configuration).
I think, this would be a good solution, easy but also powerful.
One additonal thought: The external scenario description is a good idea for an addtional reason: When porting simulation to jbpm 4 with different languages, it is maybe not so easy to embedd stuff in BPEL or XPDL process descriptions like it is now in jPDL.
why XML? Tom even blogged about a non-xml based version of a processlanguage (can't find the entry at the moment). Besides that, I agree with all the rest of your remarks.
here's what i would do:
create 1 language that is embedded in the process definition xml.
but design your language in such a way that the amount of information inside the nodes or other elements is limited. if more information is required, refer to something that is defined in the process definition level. similarly to e.g. swimlanes.
then you can still define a kind of import of a process archive resource so that most of the big complex building blocks of the simulation information are potentially defined in an external file, but that the link between those externally defined entities and the process definition elements is right inside elements in the processdefinition.xml
makes sense ?
OK, I think the main direction is more or less clear at the moment. Thanks for your remarks!
I wrote a short article about my first language proposal. For this, I included everything in the process definition, but I can imagine to "outsource" the resource-pool & distribution elements (or to allow overriding them from the outside).
For comments on the concrete language, I start an own thread in a minute.