[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.modeling.mdt] Re: [Announce] BPMN2 component proposal
|
Hugues,
There is actually a standard metamodel and serialization format for the
current BPMN 1.x specification - the BPDM (Business Process Definition
Metamodel) specification...
Let me reiterate that this proposal is about providing an implementation of
the metamodel (only), not a modeling tool. IMHO, it is important that BPM
tool users/developers have the flexibility to choose whether they want to
(re)use and/or extend an existing BPMN tool at Eclipse (i.e. yours) or
whether they want to build their own, in which case it should be possible to
consume just a metamodel implementation. In either case, I think it would be
ideal to have one standard-compliant metamodel implementation at Eclipse,
and we are offering to provide it. I don't see how providing an
implementation of the metamodel that can be used independently of SOA tools
is confusing; end users that are looking for a BPMN modeler can continue to
obtain it from STP, whereas developers that are looking to build their own
standard-compliant tool (for whatever reason) will now have the option to do
so. Hopefully, future versions of the BPMN modeler in STP will be based on
the metamodel in MDT, in which case we will have made your job easier! ;)
I am quite willing/able to deal with questions about which versions of
projects/components at Eclipse correspond to which versions of OMG
specifications, having done so for over six years for the UML2
project/component. On the short term, it's clear (at least to me): STP BPMN
supports BPMN 1.0/1.1 and MDT BPMN2 (and hopefully future versions of STP
BPMN) will support BPMN 2.0.
Kenn
"Hugues Malphettes" <hmalphettes@xxxxxxxxxxx> wrote in message
news:1302721b35b633c8192197cc4d77f6d8$1@xxxxxxxxxxxxxxxxxx
> Kenn,
>
> Thanks for your answer.
>
> Relationship with the OMG regarding on a non-drafted specification.
> ------------------------------------------------------------------------
> I agree that it is best for the community to have a voice before those
> specifications are finalized:after all we are the one who end-up
> having to support them !
>
> However regarding the OMG, this happens when the specification is
> available as a draft release. At this point the community is welcome
> to influence something that it can review.
> If there is a need to involve non-OMG members outside of the OMG
> processes before that, then it is up to the OMG to change their
> process.
> I don't see an eclipse-project being productive in that area.
>
> In fact last year at eclipsecon the relationship of Eclipse and the
> OMG was discussed:
> http://www.eclipsecon.org/summiteurope2006/presentations/ESE2006-EclipseModelingSymposium14_OMGStandards.pdf
> From what I understand these discussions are still going on.
> The symposium between eclipse and the OMG will certainly help.
> Maybe once we know more in that area, the relevance of a specific project
> to deal with the OMG's own process will be clearer.
>
>
> BPMN-metamodel and STP-BPMN modeler.
> -----------------------------------------------------------------
> The original goal of the project was to get out of the door a BPMN
> modeler for the eclipse community.
> Let's note that the 1.0 and 1.1 specs do not enforce a particular format,
> there is no xml-schema, no ecore, no serialization format, no namespaces.
> We chose to have a core-semantic model that does not enforce the whole
> specification by itself.
> This way we are able to support on the top of it the rest of the
> specification and in fact several versions of the specification.
> We also make sure that people interested in using parts of the
> specification only can use the modeler as the base to their product.
>
> So for example we decided that the properties are not hard-coded in
> the meta-model.
> Instead they are supported as annotations.
> We chose also to support all activities and event-shape with the
> combination of a single element and an attribute 'activityType'. This is
> because it saves 10s of classes and that simplifies enormously the
> complexity of the generated modeler.
>
> We are aware that we are not supporting the entire BPMN-1.0 spec.
> We are answering to the community to that regard.
>
> When BPMN-2.0 will be drafted accessible publicly we are expecting the
> community starting with my own employer to push us to support it.
>
>
> This brings me to the most important point: starting another BPMN
> effort outside of the existing STP-BPMN project will certainly confuse
> our community and freeze the adoption.
>
> This tentative target release is June 2009.
> In the mean time:
> Should people wait for this other effort to go somewhere? Is the
> STP-BPMN modeler compliant to the standard (answer: yes BPMN-1.0 and
> soon 1.1 minus the bugs)?
> Are you ready to discuss with all potential contributors are users
> what standard is implemented what version of it and its actual
> availability to the public?
> By doing this effort in the existing project we will make sure we
> don't spend energy clarifying this.
>
> Thanks!
> Hugues.
>