XPDL Package element and PVM

[mvaldes]

Hi,

I'm currently concerned about the impact of the XPDL package element on the PVM. This element was not supported in Bonita v3 but I wondering whether or not to add this support in the version based on the PVM.

A package acts as a container of elements which can be used by a number of different workflow processes, that is: variables, performers (users, roles), actions...

After some thoughts my feeling is that this is indeed an interested concept for some use cases. I remember a customer wanted to leverage, among others, participants (users and roles) for all the workflow processes used in this organisation. Basically he wanted to avoid workflow designers to define new users/roles than those ones availables in the package (lets say in a container or a repository). In fact he wanted to "centralize" some of the entities used within workflow processes in the organization.

In order to add support for packages propertly I guess some changes are needed in the PVM, isn't it ? what is your opinion about the package concept ? do you see it as a useful thing ?

I'm also concerned about the development impact that could have to support such a functionality so... this need a further investigation.

regards,
Miguel Valdes

[tom.baeyens]

i'm in doubt wether i want the package construct in the pvm or not. until we are actually going to use it in at least 2 process languages, i think i prefer it to be in XPDL only.

It should be straightforward to implement, i guess;

public class Package implements Serializable {
protected Map<String, Process> processes;
protected Map<String, SwimlaneDefinition> swimlaneDefinitions;
protected Map<String, Application> applications; // XPDL only
...

}

So the only thing to do is to maintain such an object throughout the parsing. If one of these things is referenced by name, the parser first checks in the process, if not there, it checks the package.

The result is that multiple processes can actually reference the same swimlane objects and share other objects as well.

Dunno if the package object itself should be made persistable.

regards, tom.

[mvaldes]

Even if package is XPDL concept, the idea behind (let's call that container of resources) could apply to other languages (ie. JPDL, or even for BPEL if we consider web services as resources that can be shared among different processes).

Have this idea of container any sence/practical use cases for JPDL, I mean have you ever got a feedback from users about this kind of fonctionality ?

In terms of implementation I agree it could be easy to add this new element for XPDL (even if tricky things needs to be taken into account during the parsing and execution phases, i.e packages referencing external packages...) but for sure I think this element should be persistable, otherwise how we can manage to get resources from a deployed package without parse again the XPDL file ?

regards,
Miguel Valdes

[tom.baeyens]

"mvaldes" wrote:
Have this idea of container any sence/practical use cases for JPDL, I mean have you ever got a feedback from users about this kind of fonctionality ?

It makes sense, but as long as there is no real user demand for those kind of features, I think it's better to keep it out of jPDL for now. We can always add it later. Afaict now, it should be possible to add it later in a backwards compatible fashion.

"mvaldes" wrote:
In terms of implementation I agree it could be easy to add this new element for XPDL (even if tricky things needs to be taken into account during the parsing and execution phases, i.e packages referencing external packages...) but for sure I think this element should be persistable, otherwise how we can manage to get resources from a deployed package without parse again the XPDL file ?

it should indeed be persistable.

if you ever encounter a difficulty or something that just doesn't feel right in the design of the pvm to support packages, let me know and i can always help search for better solutions.

afaik, it a package will be the unit of deployment. when you're going to support reference of external packages, it means that one package is deployed and then another package gets deployed with a reference to the already-deployed-package. i don't see another way to resolve this reference then through the persistence service (or process repository).