[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.jwt] Re: [Metamodel] Initial metamodel uploaded

I know that it was reinvented.
What companies are using it? How big user-base does it have? What was the 
biggest process written in this language that was actually used by some 
users? Maybe I am wrong, and it is widely used and tested but I just don't 
know...
The best thing that is about some standard model, is that you don't have an 
option to change it. New models (or owned models) always require some 
changes, and working with changing model... it just makes things delivered 
later then expected.
Also (as I have mention in other post in the [Metamodel] XPDL thread) I am 
not sure how to handle roundtrip between models, and how to handle vendor 
specyfic extensions. Not sure if we need to, but it depends on the usecases 
that we want to support.

Sorry to be so 'anty', but I don't want to repeat the same errors again and 
want to be sure that we know where we are going and this is right direction.

Wojtek

"Marc Dutoo" <marc.dutoo@xxxxxxxxxxx> wrote in message 
news:45F80647.1080303@xxxxxxxxxxxxxx
> 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