Home » Modeling » MDT (Model Development Tools) » [Announce] BPMN2 component proposal
| |
| Re: [Announce] BPMN2 component proposal [message #378033 is a reply to message #378031] |
Thu, 20 December 2007 16:03   |
 Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Hugues,
Thank you for your feedback on the proposal! The goal of this component is
not to develop a modeler, but rather an implementation of (what will become)
the new BPMN2 metamodel that conforms to the specification. It's my
understanding (please correct me if I'm wrong!) that the metamodel in the
BPMN subproject of STP does not currently conform to the (existing) BPMN
specification, and indeed it's unclear whether compliance is one of the
objectives of your subproject. The primary goal of the MDT subproject is to
host (reference) implementations of OMG specifications - that's why, to me,
an implementation of the new BPMN2 metamodel belongs in MDT. As you have
said, GMF facilitates the separation of concerns between semantics and
notation, so in my mind this is a great opportunity for cross-project
collaboration - as stated in the proposal, we hope to work closely with the
STP project in shaping the future of BPMN at Eclipse.
The BPMN 2.0 specification is still in its RFP stage which, as you point
out, means that a draft of the specification is not yet available; in fact,
responses to the RFP have yet to be submitted (although I'm told that this
should happen in the first half of 2008). While it is true that developing a
component based on a specification that has not yet been adopted presents
its challenges, I feel that this represents an opportunity to increase
collaboration between Eclipse and the OMG. Rather than waiting for a
specification to be finalized, and realizing (perhaps too late) that a
number of practical concerns have been overlooked, we will be able to
provide meaningful feedback to the OMG as the specifcation is developed, and
at the same time produce an implementation of a specification that we know
works. Some of the parties interested in this proposal are also active
members of the OMG, so we hope to use these channels in an appropriate way
to participate in the OMG specification process...
Kenn
"Hugues Malphettes" <hmalphettes@intalio.com> wrote in message
news:d68bf7dd7c5bf147cfbcf3fe2ba86efe$1@www.eclipse.org...
> Hi Kenn,
>
> I am the lead developer for the STP-BPMN modeler:
> http://www.eclipse.org/stp/bpmn/
>
> I am excited to see interest in the BPMN modeler developed in eclipse.
> I am puzzled however at the idea of starting a new project at this point.
>
> There is a community in eclipse working on BPMN.
> ------------------------------------------------
> We have in STP a community interested in BPMN and its application.
> We would love to have the proposed contributers of this proposal join our
> efforts.
> We are definitely looking for contributors.
> Please let us know what problems were identified in our modeler.
>
> On the implementation side: GMF nicely decouples the domain model from its
> visualization. Even if we were to find out that a new domain model is
> needed, we would benefit from our common efforts on the user-interactions
> specific to GMF. That is where in my experience we spend the most time.
>
> We do feel quite opened minded and you can notice that the STP-PMC accepts
> new contributors regularly: we could make a BPMN-2.0 branch if that is
> what it takes. Otherwise let's use, the stp-dev mailing list, the
> stp-newsgroup, the wiki, the website and all the eclipse infrastructure.
>
> BPMN-2.0 has not reached the stage where a public draft is available.
> ------------------------------------------------------------ ---------
> Please correct me if I am wrong and do send me a link to a BPMN-2.0 draft;
> I have not found it.
>
> In that case it will be hard to discuss the specification outside of the
> OMG itself. In fact I would even worry about IP if we start discussing non
> publicly available documents.
>
> The advantage of this situation is: the OMG can make sure that discussions
> are constrained to interested OMG members.
> I think it would not help to distract them from their process before a
> public draft is accessible.
>
>
> Thanks for your attention,
> Hugues.
>
>
>
|
|
| |
| Re: [Announce] BPMN2 component proposal [message #378035 is a reply to message #378034] |
Sat, 22 December 2007 00:48 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
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@intalio.com> wrote in message
news:1302721b35b633c8192197cc4d77f6d8$1@www.eclipse.org...
> 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/ESE 2006-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.
>
|
|
|
| Re: [Announce] BPMN2 component proposal [message #378036 is a reply to message #378035] |
Sat, 22 December 2007 01:11 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Oops, I've actually only been involved with the UML2 project/component for
just over four years (although sometimes it feels more like six years or
longer)... ;)
Kenn
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fkhms8$uq6$1@build.eclipse.org...
> 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@intalio.com> wrote in message
> news:1302721b35b633c8192197cc4d77f6d8$1@www.eclipse.org...
>> 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/ESE 2006-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.
>>
>
>
|
|
|
| Re: [Announce] BPMN2 component proposal [message #378037 is a reply to message #378034] |
Sat, 22 December 2007 13:27 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Hugues,
My personal opinions below.
Hugues Malphettes wrote:
> 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.
Designing a specification without a lock-step reference implementation
of it seems highly questionable to me. I can't imagine that any human
mind is sufficiently powerful to be able to understand all the
implications of a verbal description without implementing it in a formal
way. So to me, a reference implementation is key to achieving a
technically sound specification and any process lacking this validation
seems broken.
>
> In fact last year at eclipsecon the relationship of Eclipse and the
> OMG was discussed:
> http://www.eclipsecon.org/summiteurope2006/presentations/ESE 2006-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.
I think the OMG is recognizing that Eclipse is one of the key driving
forces behind many of its important specifications (if not simply the
key driving force). Paper is only paper while an implementation is
needed to make it real.
>
>
> 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.
That seems problematic from an exchange point of view. If I understand
correctly, there is now an effort to pin down the underlying metamodel.
> 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.
It sounds like you might well want to have some influence into how the
metamodel definition unfolds so that these kind of good simplifications
end up in the specification. This is precisely the type of reason why a
real implementation is needed.
>
> We are aware that we are not supporting the entire BPMN-1.0 spec.
> We are answering to the community to that regard.
It's not so different from Ecore predating EMOF and now with 2.3 changes
in Ecore to support Java-style generics, we've pushed the envelope
father yet again.
>
> 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.
I would hope that folks participate actively in pushing the
specification where the community needs to go. I.e., be proactive, not
reactive...
>
>
> 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.
That would be bad. I don't think anyone wants to see that happen. I'm
wondering though if this all simply boils down to alternative
serialization formats (much as Ecore is able to read and write EMOF
serializations). If it's more than that, there's all the more reason to
ensure that you be proactive in helping direct the specification effort
with implementations that demonstrate the best way to support the concepts.
>
> 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?
Kenn does have a long history of dealing with a shifting UML
specification. I've had to deal with MOF becoming EMOF and CMOF. It
seems there is no way to avoid this type of problem, so best to address
it in the most constructive way possible.
> By doing this effort in the existing project we will make sure we
> don't spend energy clarifying this.
Who am I to give advice, but personally I don't care whether the model
work is done in MDT or STP; putting it in MDT is no different from XSD
in MDT and the editor for it in WTP. I imagine that if you guys are
interested, you would be welcomed as committers on the component no
matter where it lives. You might well want to continue on your current
path until the metamodel is sufficiently robust and pinned down by the
specification to justify using it. And again, I strongly encourage you
to be proactive in guiding the specification where it needs to go. It
seems to me you guys have by far the most expertise in where that target
should be...
>
> Thanks!
> Hugues.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | |
| Re: [Announce] BPMN2 component proposal [message #581212 is a reply to message #378031] |
Thu, 20 December 2007 16:03 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Hugues,
Thank you for your feedback on the proposal! The goal of this component is
not to develop a modeler, but rather an implementation of (what will become)
the new BPMN2 metamodel that conforms to the specification. It's my
understanding (please correct me if I'm wrong!) that the metamodel in the
BPMN subproject of STP does not currently conform to the (existing) BPMN
specification, and indeed it's unclear whether compliance is one of the
objectives of your subproject. The primary goal of the MDT subproject is to
host (reference) implementations of OMG specifications - that's why, to me,
an implementation of the new BPMN2 metamodel belongs in MDT. As you have
said, GMF facilitates the separation of concerns between semantics and
notation, so in my mind this is a great opportunity for cross-project
collaboration - as stated in the proposal, we hope to work closely with the
STP project in shaping the future of BPMN at Eclipse.
The BPMN 2.0 specification is still in its RFP stage which, as you point
out, means that a draft of the specification is not yet available; in fact,
responses to the RFP have yet to be submitted (although I'm told that this
should happen in the first half of 2008). While it is true that developing a
component based on a specification that has not yet been adopted presents
its challenges, I feel that this represents an opportunity to increase
collaboration between Eclipse and the OMG. Rather than waiting for a
specification to be finalized, and realizing (perhaps too late) that a
number of practical concerns have been overlooked, we will be able to
provide meaningful feedback to the OMG as the specifcation is developed, and
at the same time produce an implementation of a specification that we know
works. Some of the parties interested in this proposal are also active
members of the OMG, so we hope to use these channels in an appropriate way
to participate in the OMG specification process...
Kenn
"Hugues Malphettes" <hmalphettes@intalio.com> wrote in message
news:d68bf7dd7c5bf147cfbcf3fe2ba86efe$1@www.eclipse.org...
> Hi Kenn,
>
> I am the lead developer for the STP-BPMN modeler:
> http://www.eclipse.org/stp/bpmn/
>
> I am excited to see interest in the BPMN modeler developed in eclipse.
> I am puzzled however at the idea of starting a new project at this point.
>
> There is a community in eclipse working on BPMN.
> ------------------------------------------------
> We have in STP a community interested in BPMN and its application.
> We would love to have the proposed contributers of this proposal join our
> efforts.
> We are definitely looking for contributors.
> Please let us know what problems were identified in our modeler.
>
> On the implementation side: GMF nicely decouples the domain model from its
> visualization. Even if we were to find out that a new domain model is
> needed, we would benefit from our common efforts on the user-interactions
> specific to GMF. That is where in my experience we spend the most time.
>
> We do feel quite opened minded and you can notice that the STP-PMC accepts
> new contributors regularly: we could make a BPMN-2.0 branch if that is
> what it takes. Otherwise let's use, the stp-dev mailing list, the
> stp-newsgroup, the wiki, the website and all the eclipse infrastructure.
>
> BPMN-2.0 has not reached the stage where a public draft is available.
> ------------------------------------------------------------ ---------
> Please correct me if I am wrong and do send me a link to a BPMN-2.0 draft;
> I have not found it.
>
> In that case it will be hard to discuss the specification outside of the
> OMG itself. In fact I would even worry about IP if we start discussing non
> publicly available documents.
>
> The advantage of this situation is: the OMG can make sure that discussions
> are constrained to interested OMG members.
> I think it would not help to distract them from their process before a
> public draft is accessible.
>
>
> Thanks for your attention,
> Hugues.
>
>
>
|
|
| |
| Re: [Announce] BPMN2 component proposal [message #581251 is a reply to message #378034] |
Sat, 22 December 2007 00:48 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
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@intalio.com> wrote in message
news:1302721b35b633c8192197cc4d77f6d8$1@www.eclipse.org...
> 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/ESE 2006-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.
>
|
|
|
| Re: [Announce] BPMN2 component proposal [message #581280 is a reply to message #378035] |
Sat, 22 December 2007 01:11 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Oops, I've actually only been involved with the UML2 project/component for
just over four years (although sometimes it feels more like six years or
longer)... ;)
Kenn
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fkhms8$uq6$1@build.eclipse.org...
> 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@intalio.com> wrote in message
> news:1302721b35b633c8192197cc4d77f6d8$1@www.eclipse.org...
>> 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/ESE 2006-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.
>>
>
>
|
|
|
| Re: [Announce] BPMN2 component proposal [message #581296 is a reply to message #378034] |
Sat, 22 December 2007 13:27 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Hugues,
My personal opinions below.
Hugues Malphettes wrote:
> 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.
Designing a specification without a lock-step reference implementation
of it seems highly questionable to me. I can't imagine that any human
mind is sufficiently powerful to be able to understand all the
implications of a verbal description without implementing it in a formal
way. So to me, a reference implementation is key to achieving a
technically sound specification and any process lacking this validation
seems broken.
>
> In fact last year at eclipsecon the relationship of Eclipse and the
> OMG was discussed:
> http://www.eclipsecon.org/summiteurope2006/presentations/ESE 2006-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.
I think the OMG is recognizing that Eclipse is one of the key driving
forces behind many of its important specifications (if not simply the
key driving force). Paper is only paper while an implementation is
needed to make it real.
>
>
> 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.
That seems problematic from an exchange point of view. If I understand
correctly, there is now an effort to pin down the underlying metamodel.
> 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.
It sounds like you might well want to have some influence into how the
metamodel definition unfolds so that these kind of good simplifications
end up in the specification. This is precisely the type of reason why a
real implementation is needed.
>
> We are aware that we are not supporting the entire BPMN-1.0 spec.
> We are answering to the community to that regard.
It's not so different from Ecore predating EMOF and now with 2.3 changes
in Ecore to support Java-style generics, we've pushed the envelope
father yet again.
>
> 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.
I would hope that folks participate actively in pushing the
specification where the community needs to go. I.e., be proactive, not
reactive...
>
>
> 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.
That would be bad. I don't think anyone wants to see that happen. I'm
wondering though if this all simply boils down to alternative
serialization formats (much as Ecore is able to read and write EMOF
serializations). If it's more than that, there's all the more reason to
ensure that you be proactive in helping direct the specification effort
with implementations that demonstrate the best way to support the concepts.
>
> 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?
Kenn does have a long history of dealing with a shifting UML
specification. I've had to deal with MOF becoming EMOF and CMOF. It
seems there is no way to avoid this type of problem, so best to address
it in the most constructive way possible.
> By doing this effort in the existing project we will make sure we
> don't spend energy clarifying this.
Who am I to give advice, but personally I don't care whether the model
work is done in MDT or STP; putting it in MDT is no different from XSD
in MDT and the editor for it in WTP. I imagine that if you guys are
interested, you would be welcomed as committers on the component no
matter where it lives. You might well want to continue on your current
path until the metamodel is sufficiently robust and pinned down by the
specification to justify using it. And again, I strongly encourage you
to be proactive in guiding the specification where it needs to go. It
seems to me you guys have by far the most expertise in where that target
should be...
>
> Thanks!
> Hugues.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | |
Goto Forum:
Current Time: Fri Apr 19 14:23:18 GMT 2024
Powered by FUDForum. Page generated in 0.04246 seconds |
] 
Search
Help
Register
Login
Home
