[news.eclipse.technology.jwt] Re: [Metamodel] Initial metamodel uploaded

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

Hi Wojciech and Florian


I think we're not that far from each other. On a global point, 
re-wording what was said at the Kickoff Meeting :

Starting from a metamodel close to the AgilPro metamodel has several 
advantages, including being able to tap into a whole host of features 
that AgilPro already provides (eclipse-based, emf model, modeling 
features... etc.). I'm not really into rewriting everything from 
scratch, and I agree with you that we should not try to reinvent the 
wheel ; and for these very reasons and the fact that we've got this code 
and expertise on it I'd give the advice to use it as a base.

Moreover, I'd rather have a working proof of concept of genericity that 
we could use to test use cases, receive feedback and preview the wam 
than an "under development" cathedral.

So Wojciech, that's not like we're trying to reinvent the wheel, it has 
already been reinvented (quite nicely at that, according to Fabrice and 
Miguel) by our german friends ^^ And what's in question is rather how to 
adapt it to fit every need of JWT's goals - which is a step we would 
have to pass through anyway.


Now, your list of concerns is very much interesting in this light. Here 
are some more comments of mine about them :

Florian Lautenbacher wrote:
> Hi Wojciech,
>
> concerning your questions about the details of AgilPro which should be 
> revisited:
>
>  > * definition of the performer of the activity
>
> This is currently modelled with the Role element that is part of the 
> Organisation. A Role is a ReferenceableElement and can henceforth be 
> attached to each action. Perhaps it might be important to define 
> different roles for the performer and for people involved (somebody who 
> gives the instructions, is responsible for, working for, etc.).

That's one thing of identifying the role in the context of the workflow, 
that's another to model the actual users and groups that will have to be 
mapped and / or chosen to fit them. What does model these user and group 
concepts (ex. coming from an LDAP, an OS etc.) ? (Is that what you were 
saying, Wojciech ?)

>  > * data types - usually processes can have private complex data
>
> Yes, you are right. We created some initial data tpyes like String, 
> Integer, etc. but mostly we use the "Data" element for complex data, 
> where we don't specify how exactly this element is structured (only 
> which data type it has and which information type).

This is important, we should at least know how we will do that. What 
would be the easiest standard-inspired mapping to plug there ? Maybe 
BPEL-inspired WSDL types ?

>  > * data mapping - especially mapping between two complex types
>
> Currently there is only a 1:1 mapping between data types, not like in 
> BPEL where you can define the whole complex type and then map parts of 
> the first complex type with parts of the second.

What are the drawbacks ? Can't this be worked around by merely using the 
"maximum complexity" type everywhere ?

>  > * applications - it just cannot be limited to java
>
> This is a first part, yes. I agree with you that it should not be 
> limited to Java. One solution could be to have an abstract "Application" 
> class with several concrete sub-classes. One for Java, one for Web 
> Services, one for .NET, etc.

OK for me, let me add the possibility of scripting languages.
This would in turn need for the runtime engine to be able to execute 
these "Applications" (which could be done through native interfaces 
linking, web services, REST, CORBA, DCOM etc. implemented at runtime in 
Java or anything else).
One important feature of using engines in the "real world" is their own 
application engines, and notably their own scripting engines. Being able 
to model them would be a great asset. Your idea ?

>  > * simulation data - it needs much, much more
>
> Here, you are the specialist. I don't know much about this kind of 
> simulation yet.

Hmm... maybe we'd need some definition of what we mean by "simulation" 
first.

>  > * extensability - how to preserve engine/tool specific data in the 
> model? do we need to do that?
>
> Maybe yes, depends on the framework that will be created in the WAM part 
>   of JWT for executing and monitoring a process.

Yes, I think this as to do with Applications and ApplicationProviders as 
seen up there. I recon it is potentially harmful for genericity, so we 
have to draw a clear line between what ApplicationProviders are generic 
and those who are not. Let's dream - maybe even allow a way to 
"repackage" portable ApplicationProviders so to be able to execute jPDL 
script on Bonita ;)

>  > * flow - it looks right, but I am not sure. In BPMN you can have
>  > decision/join or parallel split on any activity. Is that the same here?
>
> I think so. This part is similar to UML2 Activity Diagrams. You can have 
> DecisionNode and MergeNode for alternative flows and SplitNode / 
> JoinNode for parallel flows. How exactly is the decision/split ON an 
> activity in BPMN?

Anyone ?

>  > the model seams to include graphical information (in the way like XPDL
>  > does)
>
> You are also right, here. This is currently used only for the graphical 
> display and is surely not interesting for the Meta-model itself and 
> should be part of the editor.

Is there any way to draw a clear line between the two models, or do they 
need to be separated "at birth" ? Some EMF / GMF magic, Etienne ?

>  > What is in this model that is not available in the other meta-models?
>
> As already mentioned above this model is principially similar to UML2 
> Activity Diagrams. There we don't have applications, data or a better 
> description of roles than available in swimlanes. We tried to focus on 
> the process and added some functional descriptions like e.g. in ARIS. 
> But, currently there is no detailed comparison between this approach and 
> the other standards. I am currently working on that and will put a 
> document on the wiki about this topic, soon.

I liked what I've seen about this document ;)

> Best regards,
>
> Florian

Regards
Marc