[sim] Configuration of Experiment

[camunda]

Hi, I decided to use this forum also for the simulation features, I currently develop, so here we go with a question, hopefully somebody has an opinion on it, at least Tom ;-))

How to configure simulation experiments?

An experminet contains different informations (a bit simplified here):
- Which processes should be started after what time distribution
- How much resources I have per resource pool
- maybe shift calendar
- work times for tasks
- ...

Some of them can be included in the existing ProcessDefinition XML structure, maybe even all of them. But this has one big disadvantage: I can not maintain scenarios, which would be a very valuable feature, enabling the comparision of different staffing strategies for example.

So the question is, where to put these information: In an additional XML? In Java-classes? In the <process-definition> (with some nested "scenario" elements)?

A second thought must be considered here: I maybe need more than one process for my simulation experiment (because same people maybe work not only in order, but also in service tasks). Maybe this is not a MUST for the simulation environment, but I think a restriction to one process is not nice.

So I tend to allow to include the information directly in the ProcessDefinition elements, for the easy case, where no scenarios are required. So the user can play with simulation easily at the beginning.

More complex stuff and scenarios have to be configured in a special XML file. The data there "overwrites" the simulation data in the process definitions.

But I am nwondering, if maybe a complex scenario configuration can be build more easy in Java code directly? At least for the moment, this may change as soon (but here is a big: WHEN) there is GUI support available...

Thanks for any (even rough) thoughts on it...
Cheers
Bernd

[kukeltje]

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...)

[camunda]

Hi Ronald!
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?

Thanks
Bernd

[kukeltje]

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://jspwiki.org/wiki/HowToImplementADomainSpecificLanguage
http://www.infoq.com/news/domain-specific-language-debates (love this site!! one of my favourites, some nice discussions on WS-HELL)

[camunda]

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.

[kukeltje]

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.

[tom.baeyens]

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 ?

[camunda]

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.