Home » Archived » Java WorkFlow Tooling (JWT) » How to be really generic...
|
| Re: How to be really generic... [message #1638 is a reply to message #1627] |
Fri, 23 December 2005 20:42   |
Eclipse User |
|
|
|
Originally posted by: fabrice.dewasmes.openwide.fr
Hi Michael,
> Here's my approach: leave out any legacy code. In order to be up-to-date
> (especially to be still up-to-date when you have finished ;-)),
This is wise and that's what we want to do : stick with standards !
use BPMN
> as specification for the graphical representation and XPDL 2.0 as
> format.
You're cutting the grass just under my feet ! I was planning to make
modifications on the proposal this way. Sure BPMN is the way to go since
as you said XPDL is now BPMN compatible. Using BPMN has the interest to be
compatible not only with XPDL but also BPEL which we plan to support.
Add editing modes that optionally restrict the available
> elements to the BPEL or XPDL 1.0 subsets and provide a "Save as" or
> export for this format.
This can be an idea. We have to think more about this.
> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
> GMF on top.
You're right. We have started making it with some jawe code and no EMF.
This is not the best way to do it. We're thinking about making it with
GMF, which seems to make development speed up.
> I think it is the way to go.
Your vision is a good one and thank you for your help.
> If I there had been a little
> bit more time at my disposal in the last six months...
May you join the project at a later time ?
> Regards,
best regards
> Michael
Fabrice
|
|
|
| Re: How to be really generic... [message #4613 is a reply to message #1627] |
Thu, 29 December 2005 08:53 |
| Eclipse User |
|
|
|
Originally posted by: allenmacyoung.gmail.com
Hi Michael:
> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
> GMF on top. I think it is the way to go.
I think there is nothing to do with EMF for the workflow editor part. My
workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the workflow
using GEF and generate the XPDL code at the same time. Actually I use a
multiple editor to do the work and provide three views: graphic view in
which we draw the workflow definition, tree view in which I treat XPDL as
simple XML to show its structure as while as editing support according to
XPDL schema, and source view in which we can see XPDL code and edit it with
suggestions according to XPDL schema again.
I cannot find the reason to use EMF if we implement jwt's workflow editor in
this way. Or maybe we can just provide the graphic view. The drawing actions
will create a structure of EMF generated model. Then users can save the
workflow definition as XPDL, BPEL or anything else. But this has some
disadvantages:
1. Less views will reduce the convenience while using the editor. If someone
is familiar with XPDL or BPEL, directly editing source with grammar
suggestions will be more proper sometime.
2. Not all the things can be transferred from BPEL to XPDL, vice versa. It's
better to decide the definition language at the creation time other than
tell the user the complicated diagram he/she drew cannot be saved as
the format he/she wanted.
3. Create java objects first, store them in memory and at a certain time
generate the xml code could be a bottleneck of performance. If the worklfow
process is very complicated or the user create many diagrams once,
big occupying of memory will happen, which is neither acceptable nor
necessary.
So in my opinion, do not use EMF in workflow editor part. It is useful for
WA part, not WE.
Allen
"Michael N. Lipp" <mnl@mnl.de> wrote in message
news:dohkdv$8mq$1@utils.eclipse.org...
> Hi,
>
> I've thought about an eclipse plugin for workflow editing for some time.
> I've even started, but I had much too little time to achieve something
> presentable so far.
>
> Here's my approach: leave out any legacy code. In order to be up-to-date
> (especially to be still up-to-date when you have finished ;-)), use BPMN
> as specification for the graphical representation and XPDL 2.0 as format.
> Add editing modes that optionally restrict the available elements to the
> BPEL or XPDL 1.0 subsets and provide a "Save as" or export for this
> format.
>
> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
> GMF on top. I think it is the way to go. If I there had been a little bit
> more time at my disposal in the last six months...
>
> Regards,
>
> Michael
|
|
|
| Re: How to be really generic... [message #4820 is a reply to message #1627] |
Tue, 03 January 2006 17:03 |
| Eclipse User |
|
|
|
Originally posted by: rzulauf.objeng.ch
Hi Michael
> Here's my approach: leave out any legacy code. In order to be up-to-date
> (especially to be still up-to-date when you have finished ;-)), use BPMN
> as specification for the graphical representation and XPDL 2.0 as
> format. Add editing modes that optionally restrict the available
> elements to the BPEL or XPDL 1.0 subsets and provide a "Save as" or
> export for this format.
I totally agree on using BPMN as a start for the specification for the
graphical representation. However I feel that later on, for a
full-fledged designer, the representation should be pluggable. For
instance, case tools sometimes offer representation in UML, Booch,
Entity-Relationship, etc. I am not yet that familiar with GEF or GMF to
know how to implement this, but what comes to mind is the Bridge Pattern
(GoF).
The reason for this is that BPMN might be ok for techies but a business
user wants to see a notation he is familiar with. So at least a
possiblity to plug other representations should be provided.
I have substantial experience with XPDL 1.0 but am not yet familiar with
all the extensions that have found their way into XPDL 2.0, so the
following may be incorrect. What I am concerned about by using XPDL 2.0
as the internal data format is that you concentrate on one format
instead of the semantics that you would like to represent. This has
proven to be an error in our own implementation of our workflow system,
because what you want at last is a certain set of functionality,
regardless of whether it is defined in a standard or not. So while I
think it is definitely correct to rely heavily on semantics defined in
XPDL 2.0, it should also not impose any limits, in other words the
internal represenation must be extensible as well, regardless of whether
it is XPDL 2.0 compliant or not.
If you have an internal representation not bound to any standard, you
can define a metamodel which covers all functionality found in XPDL 1.0,
2.0, BPEL, FDL, etc. etc. and then limit the available subset at design
time and provide export functions to the corresponding formats.
>
> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
> GMF on top. I think it is the way to go. If I there had been a little
> bit more time at my disposal in the last six months...
>
> Regards,
>
> Michael
|
|
|
| Re: How to be really generic... [message #5290 is a reply to message #4820] |
Wed, 04 January 2006 09:20 |
| Eclipse User |
|
|
|
Originally posted by: fabrice.dewasmes.openwide.fr
Roman Zulauf wrote:
> Hi Michael
>
>> Here's my approach: leave out any legacy code. In order to be
>> up-to-date (especially to be still up-to-date when you have finished
>> ;-)), use BPMN as specification for the graphical representation and
>> XPDL 2.0 as format. Add editing modes that optionally restrict the
>> available elements to the BPEL or XPDL 1.0 subsets and provide a "Save
>> as" or export for this format.
>
> I totally agree on using BPMN as a start for the specification for the
> graphical representation. However I feel that later on, for a
> full-fledged designer, the representation should be pluggable. For
> instance, case tools sometimes offer representation in UML, Booch,
> Entity-Relationship, etc. I am not yet that familiar with GEF or GMF to
> know how to implement this, but what comes to mind is the Bridge Pattern
> (GoF).
> The reason for this is that BPMN might be ok for techies but a business
> user wants to see a notation he is familiar with. So at least a
> possiblity to plug other representations should be provided.
This is to a certain extent right. I like the idea of doing things
incrementally, meaning that we must start simple and see how we can
build more complex system at a later time. What I suggest is to take
this as a second priority requirement.
>
> I have substantial experience with XPDL 1.0 but am not yet familiar with
> all the extensions that have found their way into XPDL 2.0, so the
> following may be incorrect. What I am concerned about by using XPDL 2.0
> as the internal data format is that you concentrate on one format
> instead of the semantics that you would like to represent. This has
> proven to be an error in our own implementation of our workflow system,
> because what you want at last is a certain set of functionality,
> regardless of whether it is defined in a standard or not. So while I
> think it is definitely correct to rely heavily on semantics defined in
> XPDL 2.0, it should also not impose any limits, in other words the
> internal represenation must be extensible as well, regardless of whether
> it is XPDL 2.0 compliant or not.
XPDL allows proprietary extensions doesn't it ? If so, our model should
be extensible in the same way. I mean if we stick to XPDL we should be
able to support proprietary extensions.
>
> If you have an internal representation not bound to any standard, you
> can define a metamodel which covers all functionality found in XPDL 1.0,
> 2.0, BPEL, FDL, etc. etc. and then limit the available subset at design
> time and provide export functions to the corresponding formats.
Yes but we will have to define this representation which doesn't seem so
easy. Have you experience on this specific topic ?
>
>>
>> Using EMF and XPDL 2.0 works quite well, it gives you an easy start.
>> Put GMF on top. I think it is the way to go. If I there had been a
>> little bit more time at my disposal in the last six months...
>>
>> Regards,
>>
>> Michael
Fabrice
|
|
|
| Re: How to be really generic... [message #7559 is a reply to message #5290] |
Wed, 04 January 2006 11:59 |
| Eclipse User |
|
|
|
Originally posted by: rzulauf.objeng.ch
Fabrice Dewasmes wrote:
>> I totally agree on using BPMN as a start for the specification for the
>> graphical representation. However I feel that later on, for a
>> full-fledged designer, the representation should be pluggable. For
>> instance, case tools sometimes offer representation in UML, Booch,
>> Entity-Relationship, etc. I am not yet that familiar with GEF or GMF
>> to know how to implement this, but what comes to mind is the Bridge
>> Pattern (GoF).
>> The reason for this is that BPMN might be ok for techies but a
>> business user wants to see a notation he is familiar with. So at least
>> a possiblity to plug other representations should be provided.
>
>
> This is to a certain extent right. I like the idea of doing things
> incrementally, meaning that we must start simple and see how we can
> build more complex system at a later time. What I suggest is to take
> this as a second priority requirement.
I agree, I just think it should be kept in mind during detail design, to
provide the hooks for extensions added later.
>> I have substantial experience with XPDL 1.0 but am not yet familiar
>> with all the extensions that have found their way into XPDL 2.0, so
>> the following may be incorrect. What I am concerned about by using
>> XPDL 2.0 as the internal data format is that you concentrate on one
>> format instead of the semantics that you would like to represent. This
>> has proven to be an error in our own implementation of our workflow
>> system, because what you want at last is a certain set of
>> functionality, regardless of whether it is defined in a standard or
>> not. So while I think it is definitely correct to rely heavily on
>> semantics defined in XPDL 2.0, it should also not impose any limits,
>> in other words the internal represenation must be extensible as well,
>> regardless of whether it is XPDL 2.0 compliant or not.
>
>
> XPDL allows proprietary extensions doesn't it ? If so, our model should
> be extensible in the same way. I mean if we stick to XPDL we should be
> able to support proprietary extensions.
Yes of course, XPDL does allow proprietary extensions. I was just
wondering if this was actually sufficient. As I mentioned my main
experience has been with XPDL 1.0 and not 2.0, and XPDL 1.0 is IMHO in
many ways insufficient even tough proprietary extensions are supported.
>
>>
>> If you have an internal representation not bound to any standard, you
>> can define a metamodel which covers all functionality found in XPDL
>> 1.0, 2.0, BPEL, FDL, etc. etc. and then limit the available subset at
>> design time and provide export functions to the corresponding formats.
>
>
> Yes but we will have to define this representation which doesn't seem so
> easy. Have you experience on this specific topic ?
I agree this might be a daunting task. But I am willing to do some
work/research on this to see if this can be realized within a reasonable
timeframe. I could present my results and then we could all decide which
is the right way to go.
Roman
>
>
> Fabrice
|
|
|
| Re: How to be really generic... [message #7577 is a reply to message #7559] |
Wed, 04 January 2006 16:03 |
| Eclipse User |
|
|
|
Originally posted by: fabrice.dewasmes.openwide.fr
Roman Zulauf wrote:
> Fabrice Dewasmes wrote:
>
>>> I totally agree on using BPMN as a start for the specification for
>>> the graphical representation. However I feel that later on, for a
>>> full-fledged designer, the representation should be pluggable. For
>>> instance, case tools sometimes offer representation in UML, Booch,
>>> Entity-Relationship, etc. I am not yet that familiar with GEF or GMF
>>> to know how to implement this, but what comes to mind is the Bridge
>>> Pattern (GoF).
>>> The reason for this is that BPMN might be ok for techies but a
>>> business user wants to see a notation he is familiar with. So at
>>> least a possiblity to plug other representations should be provided.
>>
>>
>>
>> This is to a certain extent right. I like the idea of doing things
>> incrementally, meaning that we must start simple and see how we can
>> build more complex system at a later time. What I suggest is to take
>> this as a second priority requirement.
>
> I agree, I just think it should be kept in mind during detail design, to
> provide the hooks for extensions added later.
>
>>> I have substantial experience with XPDL 1.0 but am not yet familiar
>>> with all the extensions that have found their way into XPDL 2.0, so
>>> the following may be incorrect. What I am concerned about by using
>>> XPDL 2.0 as the internal data format is that you concentrate on one
>>> format instead of the semantics that you would like to represent.
>>> This has proven to be an error in our own implementation of our
>>> workflow system, because what you want at last is a certain set of
>>> functionality, regardless of whether it is defined in a standard or
>>> not. So while I think it is definitely correct to rely heavily on
>>> semantics defined in XPDL 2.0, it should also not impose any limits,
>>> in other words the internal represenation must be extensible as well,
>>> regardless of whether it is XPDL 2.0 compliant or not.
>>
>>
>>
>> XPDL allows proprietary extensions doesn't it ? If so, our model
>> should be extensible in the same way. I mean if we stick to XPDL we
>> should be able to support proprietary extensions.
>
> Yes of course, XPDL does allow proprietary extensions. I was just
> wondering if this was actually sufficient. As I mentioned my main
> experience has been with XPDL 1.0 and not 2.0, and XPDL 1.0 is IMHO in
> many ways insufficient even tough proprietary extensions are supported.
I haven't got much experience on proprietary extensions. Let's say this
is sufficient for the moment to keep things simple and if you can draw a
list of foreseen risks this would be perfect.
>
>>
>>>
>>> If you have an internal representation not bound to any standard, you
>>> can define a metamodel which covers all functionality found in XPDL
>>> 1.0, 2.0, BPEL, FDL, etc. etc. and then limit the available subset at
>>> design time and provide export functions to the corresponding formats.
>>
>>
>>
>> Yes but we will have to define this representation which doesn't seem
>> so easy. Have you experience on this specific topic ?
>
> I agree this might be a daunting task. But I am willing to do some
> work/research on this to see if this can be realized within a reasonable
> timeframe. I could present my results and then we could all decide which
> is the right way to go.
Seems a good idea. But keep one important thing in mind : what is so
interesting about using BPMN is that it allows us to have one visual
representation for two different grammars. The defined layer shall
support at least BPMN representation and be able to plug in any concrete
grammar implementation. This means that there will be a trade off
somewhere between genericity and usability : what is not covered by the
generic layer will have to be implemented by the specific layer... So it
is a matter of where you stop in the metamodel.
>
> Roman
>
>>
Fabrice
|
|
|
| Re: How to be really generic... [message #7681 is a reply to message #4613] |
Sun, 08 January 2006 23:09 |
| Eclipse User |
|
|
|
Originally posted by: vgv8.yahoo.com.br
I would agree with Allen. He is original (in that he is not mimicking
opinions and visions of others, in this case, of IBM).
I have exactly the same project for me alone for 3 months that you all are
going to accomplish in more than a year scale.
I should recreate anew in GEF with EMF already existing Workflow Graphical
Editor in Swing.
What is killing me is that no old/Swing code may be (re)used and
requirement of EMF. It is just "pain in the ass". Nobody has experience with
it but everybody wants it.
I also had big enthusiasm about EMF initially . It is a great time-,
good-wishes- and sanity-killer.
Let me cite from
http://en.wikipedia.org/wiki/Model_view_controller
:
"The best models are fully encapsulated, meaning that they implement every
aspect of that real world object of interest to the domain of interest, and
that they don't have any extra code that doesn't model the real world."
what I am rereading for a second day for some or another reasons.
Correct me,
Guennadi Vanine
"Allen Young" <allenmacyoung@gmail.com> wrote in message
news:dp083m$fkm$1@utils.eclipse.org...
> Hi Michael:
>
>> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>> GMF on top. I think it is the way to go.
>
> I think there is nothing to do with EMF for the workflow editor part. My
> workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
> workflow using GEF and generate the XPDL code at the same time. Actually I
> use a multiple editor to do the work and provide three views: graphic view
> in which we draw the workflow definition, tree view in which I treat XPDL
> as simple XML to show its structure as while as editing support according
> to XPDL schema, and source view in which we can see XPDL code and edit it
> with suggestions according to XPDL schema again.
>
> I cannot find the reason to use EMF if we implement jwt's workflow editor
> in this way. Or maybe we can just provide the graphic view. The drawing
> actions will create a structure of EMF generated model. Then users can
> save the workflow definition as XPDL, BPEL or anything else. But this has
> some disadvantages:
> 1. Less views will reduce the convenience while using the editor. If
> someone is familiar with XPDL or BPEL, directly editing source with
> grammar suggestions will be more proper sometime.
> 2. Not all the things can be transferred from BPEL to XPDL, vice versa.
> It's better to decide the definition language at the creation time other
> than tell the user the complicated diagram he/she drew cannot be
> saved as the format he/she wanted.
> 3. Create java objects first, store them in memory and at a certain time
> generate the xml code could be a bottleneck of performance. If the
> worklfow process is very complicated or the user create many
> diagrams once, big occupying of memory will happen, which is neither
> acceptable nor necessary.
>
> So in my opinion, do not use EMF in workflow editor part. It is useful for
> WA part, not WE.
>
> Allen
>
>
> "Michael N. Lipp" <mnl@mnl.de> wrote in message
> news:dohkdv$8mq$1@utils.eclipse.org...
>> Hi,
>>
>> I've thought about an eclipse plugin for workflow editing for some time.
>> I've even started, but I had much too little time to achieve something
>> presentable so far.
>>
>> Here's my approach: leave out any legacy code. In order to be up-to-date
>> (especially to be still up-to-date when you have finished ;-)), use BPMN
>> as specification for the graphical representation and XPDL 2.0 as format.
>> Add editing modes that optionally restrict the available elements to the
>> BPEL or XPDL 1.0 subsets and provide a "Save as" or export for this
>> format.
>>
>> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>> GMF on top. I think it is the way to go. If I there had been a little bit
>> more time at my disposal in the last six months...
>>
>> Regards,
>>
>> Michael
>
>
|
|
|
| Again, on EMF [message #7721 is a reply to message #7681] |
Sun, 08 January 2006 23:21 |
| Eclipse User |
|
|
|
Originally posted by: vgv8.yahoo.com.br
After playing GEF with EMF I came to opinion that EMF probably has sense in
context of properly integrated IDE/ modeling tool, i.e. it is IBM/Rational's
bait to buy their commercial products.
Otherwise it is time-and sanity-killer.
Guennadi Vanine
"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
news:dps63h$12d$1@utils.eclipse.org...
>I would agree with Allen. He is original (in that he is not mimicking
> opinions and visions of others, in this case, of IBM).
>
> I have exactly the same project for me alone for 3 months that you all are
> going to accomplish in more than a year scale.
>
> I should recreate anew in GEF with EMF already existing Workflow
> Graphical
> Editor in Swing.
>
> What is killing me is that no old/Swing code may be (re)used and
> requirement of EMF. It is just "pain in the ass". Nobody has experience
> with
> it but everybody wants it.
>
> I also had big enthusiasm about EMF initially . It is a great time-,
> good-wishes- and sanity-killer.
>
> Let me cite from
> http://en.wikipedia.org/wiki/Model_view_controller
> :
> "The best models are fully encapsulated, meaning that they implement every
> aspect of that real world object of interest to the domain of interest,
> and
> that they don't have any extra code that doesn't model the real world."
> what I am rereading for a second day for some or another reasons.
>
> Correct me,
> Guennadi Vanine
>
> "Allen Young" <allenmacyoung@gmail.com> wrote in message
> news:dp083m$fkm$1@utils.eclipse.org...
>> Hi Michael:
>>
>>> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>> GMF on top. I think it is the way to go.
>>
>> I think there is nothing to do with EMF for the workflow editor part. My
>> workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
>> workflow using GEF and generate the XPDL code at the same time. Actually
>> I use a multiple editor to do the work and provide three views: graphic
>> view in which we draw the workflow definition, tree view in which I treat
>> XPDL as simple XML to show its structure as while as editing support
>> according to XPDL schema, and source view in which we can see XPDL code
>> and edit it with suggestions according to XPDL schema again.
>>
>> I cannot find the reason to use EMF if we implement jwt's workflow editor
>> in this way. Or maybe we can just provide the graphic view. The drawing
>> actions will create a structure of EMF generated model. Then users can
>> save the workflow definition as XPDL, BPEL or anything else. But this has
>> some disadvantages:
>> 1. Less views will reduce the convenience while using the editor. If
>> someone is familiar with XPDL or BPEL, directly editing source with
>> grammar suggestions will be more proper sometime.
>> 2. Not all the things can be transferred from BPEL to XPDL, vice versa.
>> It's better to decide the definition language at the creation time other
>> than tell the user the complicated diagram he/she drew cannot be
>> saved as the format he/she wanted.
>> 3. Create java objects first, store them in memory and at a certain time
>> generate the xml code could be a bottleneck of performance. If the
>> worklfow process is very complicated or the user create many diagrams
>> once, big occupying of memory will happen, which is neither acceptable
>> nor necessary.
>>
>> So in my opinion, do not use EMF in workflow editor part. It is useful
>> for WA part, not WE.
>>
>> Allen
>>
>>
>> "Michael N. Lipp" <mnl@mnl.de> wrote in message
>> news:dohkdv$8mq$1@utils.eclipse.org...
>>> Hi,
>>>
>>> I've thought about an eclipse plugin for workflow editing for some time.
>>> I've even started, but I had much too little time to achieve something
>>> presentable so far.
>>>
>>> Here's my approach: leave out any legacy code. In order to be up-to-date
>>> (especially to be still up-to-date when you have finished ;-)), use BPMN
>>> as specification for the graphical representation and XPDL 2.0 as
>>> format. Add editing modes that optionally restrict the available
>>> elements to the BPEL or XPDL 1.0 subsets and provide a "Save as" or
>>> export for this format.
>>>
>>> Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>> GMF on top. I think it is the way to go. If I there had been a little
>>> bit more time at my disposal in the last six months...
>>>
>>> Regards,
>>>
>>> Michael
>>
>>
>
>
|
|
|
| Re: How to be really generic... [message #7848 is a reply to message #7681] |
Mon, 09 January 2006 10:41 |
| Eclipse User |
|
|
|
Originally posted by: fabrice.dewasmes.openwide.fr
Guennadi Vanine wrote:
> I would agree with Allen. He is original (in that he is not mimicking
> opinions and visions of others, in this case, of IBM).
I haven't used EMF ever. I've tried to build simple models using simple
XSD schemas to see what it generates and I actually believed that it
might be interesting to give it a try.
>
> I have exactly the same project for me alone for 3 months that you all are
> going to accomplish in more than a year scale.
>
> I should recreate anew in GEF with EMF already existing Workflow Graphical
> Editor in Swing.
Swing graphical editor is exactly what Jawe is (at least for XPDL).
>
> What is killing me is that no old/Swing code may be (re)used and
> requirement of EMF. It is just "pain in the ass". Nobody has experience with
> it but everybody wants it.
>
> I also had big enthusiasm about EMF initially . It is a great time-,
> good-wishes- and sanity-killer.
>
> Let me cite from
> http://en.wikipedia.org/wiki/Model_view_controller
> :
> "The best models are fully encapsulated, meaning that they implement every
> aspect of that real world object of interest to the domain of interest, and
> that they don't have any extra code that doesn't model the real world."
> what I am rereading for a second day for some or another reasons.
>
> Correct me,
> Guennadi Vanine
>
> "Allen Young" <allenmacyoung@gmail.com> wrote in message
> news:dp083m$fkm$1@utils.eclipse.org...
>
>>Hi Michael:
>>
>>
>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>GMF on top. I think it is the way to go.
>>
>>I think there is nothing to do with EMF for the workflow editor part. My
>>workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
>>workflow using GEF and generate the XPDL code at the same time. Actually I
>>use a multiple editor to do the work and provide three views: graphic view
>>in which we draw the workflow definition, tree view in which I treat XPDL
>>as simple XML to show its structure as while as editing support according
>>to XPDL schema, and source view in which we can see XPDL code and edit it
>>with suggestions according to XPDL schema again.
>>
>>I cannot find the reason to use EMF if we implement jwt's workflow editor
>>in this way. Or maybe we can just provide the graphic view. The drawing
>>actions will create a structure of EMF generated model. Then users can
>>save the workflow definition as XPDL, BPEL or anything else. But this has
>>some disadvantages:
>>1. Less views will reduce the convenience while using the editor. If
>>someone is familiar with XPDL or BPEL, directly editing source with
>>grammar suggestions will be more proper sometime.
>>2. Not all the things can be transferred from BPEL to XPDL, vice versa.
>>It's better to decide the definition language at the creation time other
>>than tell the user the complicated diagram he/she drew cannot be
>>saved as the format he/she wanted.
>>3. Create java objects first, store them in memory and at a certain time
>>generate the xml code could be a bottleneck of performance. If the
>>worklfow process is very complicated or the user create many
>>diagrams once, big occupying of memory will happen, which is neither
>>acceptable nor necessary.
>>
>>So in my opinion, do not use EMF in workflow editor part. It is useful for
>>WA part, not WE.
>>
>>Allen
>>
>>
>>"Michael N. Lipp" <mnl@mnl.de> wrote in message
>>news:dohkdv$8mq$1@utils.eclipse.org...
>>
>>>Hi,
>>>
>>>I've thought about an eclipse plugin for workflow editing for some time.
>>>I've even started, but I had much too little time to achieve something
>>>presentable so far.
>>>
>>>Here's my approach: leave out any legacy code. In order to be up-to-date
>>>(especially to be still up-to-date when you have finished ;-)), use BPMN
>>>as specification for the graphical representation and XPDL 2.0 as format.
>>>Add editing modes that optionally restrict the available elements to the
>>>BPEL or XPDL 1.0 subsets and provide a "Save as" or export for this
>>>format.
>>>
>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>GMF on top. I think it is the way to go. If I there had been a little bit
>>>more time at my disposal in the last six months...
>>>
>>>Regards,
>>>
>>> Michael
>>
>>
>
>
Fabrice
|
|
|
| Re: Again, on EMF [message #7869 is a reply to message #7721] |
Mon, 09 January 2006 10:44 |
| Eclipse User |
|
|
|
Originally posted by: fabrice.dewasmes.openwide.fr
Guennadi Vanine wrote:
> After playing GEF with EMF I came to opinion that EMF probably has sense in
> context of properly integrated IDE/ modeling tool, i.e. it is IBM/Rational's
> bait to buy their commercial products.
>
> Otherwise it is time-and sanity-killer.
Have you concretely tried to use it ? Is it a user feedback ?
Fabrice
> Guennadi Vanine
>
> "Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
> news:dps63h$12d$1@utils.eclipse.org...
>
>>I would agree with Allen. He is original (in that he is not mimicking
>>opinions and visions of others, in this case, of IBM).
>>
>>I have exactly the same project for me alone for 3 months that you all are
>>going to accomplish in more than a year scale.
>>
>>I should recreate anew in GEF with EMF already existing Workflow
>>Graphical
>>Editor in Swing.
>>
>>What is killing me is that no old/Swing code may be (re)used and
>>requirement of EMF. It is just "pain in the ass". Nobody has experience
>>with
>>it but everybody wants it.
>>
>>I also had big enthusiasm about EMF initially . It is a great time-,
>>good-wishes- and sanity-killer.
>>
>>Let me cite from
>>http://en.wikipedia.org/wiki/Model_view_controller
>>:
>>"The best models are fully encapsulated, meaning that they implement every
>>aspect of that real world object of interest to the domain of interest,
>>and
>>that they don't have any extra code that doesn't model the real world."
>>what I am rereading for a second day for some or another reasons.
>>
>>Correct me,
>>Guennadi Vanine
>>
>>"Allen Young" <allenmacyoung@gmail.com> wrote in message
>>news:dp083m$fkm$1@utils.eclipse.org...
>>
>>>Hi Michael:
>>>
>>>
>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>>GMF on top. I think it is the way to go.
>>>
>>>I think there is nothing to do with EMF for the workflow editor part. My
>>>workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
>>>workflow using GEF and generate the XPDL code at the same time. Actually
>>>I use a multiple editor to do the work and provide three views: graphic
>>>view in which we draw the workflow definition, tree view in which I treat
>>>XPDL as simple XML to show its structure as while as editing support
>>>according to XPDL schema, and source view in which we can see XPDL code
>>>and edit it with suggestions according to XPDL schema again.
>>>
>>>I cannot find the reason to use EMF if we implement jwt's workflow editor
>>>in this way. Or maybe we can just provide the graphic view. The drawing
>>>actions will create a structure of EMF generated model. Then users can
>>>save the workflow definition as XPDL, BPEL or anything else. But this has
>>>some disadvantages:
>>>1. Less views will reduce the convenience while using the editor. If
>>>someone is familiar with XPDL or BPEL, directly editing source with
>>>grammar suggestions will be more proper sometime.
>>>2. Not all the things can be transferred from BPEL to XPDL, vice versa.
>>>It's better to decide the definition language at the creation time other
>>>than tell the user the complicated diagram he/she drew cannot be
>>>saved as the format he/she wanted.
>>>3. Create java objects first, store them in memory and at a certain time
>>>generate the xml code could be a bottleneck of performance. If the
>>>worklfow process is very complicated or the user create many diagrams
>>>once, big occupying of memory will happen, which is neither acceptable
>>>nor necessary.
>>>
>>>So in my opinion, do not use EMF in workflow editor part. It is useful
>>>for WA part, not WE.
>>>
>>>Allen
>>>
>>>
>>>"Michael N. Lipp" <mnl@mnl.de> wrote in message
>>>news:dohkdv$8mq$1@utils.eclipse.org...
>>>
>>>>Hi,
>>>>
>>>>I've thought about an eclipse plugin for workflow editing for some time.
>>>>I've even started, but I had much too little time to achieve something
>>>>presentable so far.
>>>>
>>>>Here's my approach: leave out any legacy code. In order to be up-to-date
>>>>(especially to be still up-to-date when you have finished ;-)), use BPMN
>>>>as specification for the graphical representation and XPDL 2.0 as
>>>>format. Add editing modes that optionally restrict the available
>>>>elements to the BPEL or XPDL 1.0 subsets and provide a "Save as" or
>>>>export for this format.
>>>>
>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>>GMF on top. I think it is the way to go. If I there had been a little
>>>>bit more time at my disposal in the last six months...
>>>>
>>>>Regards,
>>>>
>>>> Michael
>>>
>>>
>>
>
>
|
|
|
| Re: Again, on EMF [message #10442 is a reply to message #7869] |
Thu, 12 January 2006 00:04 |
| Eclipse User |
|
|
|
Originally posted by: vgv8.yahoo.com.br
Hi, Fabrice,
It is business analyst, developer, modeler and programmer feedback.
Yes I certainly tried GEF with EMF on the scale of a 200+ hours. It is
certainly not to get up alone.
I can tell you that I need one week alone in C#.NET
http://blogs.msdn.com/markhsch/archive/2005/10/06/478042.asp x
to create plug-in or stand-alone Workflow Editor Designer
what will require a year in GEF with EMF.
Guennadi Vanine
"Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
news:dptet5$ep3$2@utils.eclipse.org...
> Guennadi Vanine wrote:
>> After playing GEF with EMF I came to opinion that EMF probably has sense
>> in context of properly integrated IDE/ modeling tool, i.e. it is
>> IBM/Rational's bait to buy their commercial products.
>>
>> Otherwise it is time-and sanity-killer.
>
> Have you concretely tried to use it ? Is it a user feedback ?
>
> Fabrice
>
>
>> Guennadi Vanine
>>
>> "Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
>> news:dps63h$12d$1@utils.eclipse.org...
>>
>>>I would agree with Allen. He is original (in that he is not mimicking
>>>opinions and visions of others, in this case, of IBM).
>>>
>>>I have exactly the same project for me alone for 3 months that you all
>>>are
>>>going to accomplish in more than a year scale.
>>>
>>>I should recreate anew in GEF with EMF already existing Workflow
>>>Graphical
>>>Editor in Swing.
>>>
>>>What is killing me is that no old/Swing code may be (re)used and
>>>requirement of EMF. It is just "pain in the ass". Nobody has experience
>>>with
>>>it but everybody wants it.
>>>
>>>I also had big enthusiasm about EMF initially . It is a great time-,
>>>good-wishes- and sanity-killer.
>>>
>>>Let me cite from
>>>http://en.wikipedia.org/wiki/Model_view_controller
>>>:
>>>"The best models are fully encapsulated, meaning that they implement
>>>every
>>>aspect of that real world object of interest to the domain of interest,
>>>and
>>>that they don't have any extra code that doesn't model the real world."
>>>what I am rereading for a second day for some or another reasons.
>>>
>>>Correct me,
>>>Guennadi Vanine
>>>
>>>"Allen Young" <allenmacyoung@gmail.com> wrote in message
>>>news:dp083m$fkm$1@utils.eclipse.org...
>>>
>>>>Hi Michael:
>>>>
>>>>
>>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start.
>>>>>Put GMF on top. I think it is the way to go.
>>>>
>>>>I think there is nothing to do with EMF for the workflow editor part. My
>>>>workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
>>>>workflow using GEF and generate the XPDL code at the same time. Actually
>>>>I use a multiple editor to do the work and provide three views: graphic
>>>>view in which we draw the workflow definition, tree view in which I
>>>>treat XPDL as simple XML to show its structure as while as editing
>>>>support according to XPDL schema, and source view in which we can see
>>>>XPDL code and edit it with suggestions according to XPDL schema again.
>>>>
>>>>I cannot find the reason to use EMF if we implement jwt's workflow
>>>>editor in this way. Or maybe we can just provide the graphic view. The
>>>>drawing actions will create a structure of EMF generated model. Then
>>>>users can save the workflow definition as XPDL, BPEL or anything else.
>>>>But this has some disadvantages:
>>>>1. Less views will reduce the convenience while using the editor. If
>>>>someone is familiar with XPDL or BPEL, directly editing source with
>>>>grammar suggestions will be more proper sometime.
>>>>2. Not all the things can be transferred from BPEL to XPDL, vice versa.
>>>>It's better to decide the definition language at the creation time other
>>>>than tell the user the complicated diagram he/she drew cannot be
>>>>saved as the format he/she wanted.
>>>>3. Create java objects first, store them in memory and at a certain time
>>>>generate the xml code could be a bottleneck of performance. If the
>>>>worklfow process is very complicated or the user create many diagrams
>>>>once, big occupying of memory will happen, which is neither acceptable
>>>>nor necessary.
>>>>
>>>>So in my opinion, do not use EMF in workflow editor part. It is useful
>>>>for WA part, not WE.
>>>>
>>>>Allen
>>>>
>>>>
>>>>"Michael N. Lipp" <mnl@mnl.de> wrote in message
>>>>news:dohkdv$8mq$1@utils.eclipse.org...
>>>>
>>>>>Hi,
>>>>>
>>>>>I've thought about an eclipse plugin for workflow editing for some
>>>>>time. I've even started, but I had much too little time to achieve
>>>>>something presentable so far.
>>>>>
>>>>>Here's my approach: leave out any legacy code. In order to be
>>>>>up-to-date (especially to be still up-to-date when you have finished
>>>>>;-)), use BPMN as specification for the graphical representation and
>>>>>XPDL 2.0 as format. Add editing modes that optionally restrict the
>>>>>available elements to the BPEL or XPDL 1.0 subsets and provide a "Save
>>>>>as" or export for this format.
>>>>>
>>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start.
>>>>>Put GMF on top. I think it is the way to go. If I there had been a
>>>>>little bit more time at my disposal in the last six months...
>>>>>
>>>>>Regards,
>>>>>
>>>>> Michael
>>>>
>>>>
>>>
>>
|
|
|
| Re: How to be really generic... [message #10476 is a reply to message #7848] |
Thu, 12 January 2006 00:33 |
| Eclipse User |
|
|
|
Originally posted by: vgv8.yahoo.com.br
Fabrice:
IMHO JaWE is the best Wf Designer I have seen in Java even in comparison
with commercial products.
As I understood Eclipse/IBM and Sun/Swing does not agree with each other
To me it appears like JWT is going to kill JaWE.
Can you share with me any links on JaWE docs (I found some but strange
Guennadi Vanine
"Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
news:dptens$ep3$1@utils.eclipse.org...
> Guennadi Vanine wrote:
>> I would agree with Allen. He is original (in that he is not mimicking
>> opinions and visions of others, in this case, of IBM).
>
> I haven't used EMF ever. I've tried to build simple models using simple
> XSD schemas to see what it generates and I actually believed that it might
> be interesting to give it a try.
>
>>
>> I have exactly the same project for me alone for 3 months that you all
>> are
>> going to accomplish in more than a year scale.
>>
>> I should recreate anew in GEF with EMF already existing Workflow
>> Graphical
>> Editor in Swing.
>
> Swing graphical editor is exactly what Jawe is (at least for XPDL).
>>
>> What is killing me is that no old/Swing code may be (re)used and
>> requirement of EMF. It is just "pain in the ass". Nobody has experience
>> with
>> it but everybody wants it.
>>
>> I also had big enthusiasm about EMF initially . It is a great time-,
>> good-wishes- and sanity-killer.
>>
>> Let me cite from
>> http://en.wikipedia.org/wiki/Model_view_controller
>> :
>> "The best models are fully encapsulated, meaning that they implement
>> every
>> aspect of that real world object of interest to the domain of interest,
>> and
>> that they don't have any extra code that doesn't model the real world."
>> what I am rereading for a second day for some or another reasons.
>>
>> Correct me,
>> Guennadi Vanine
>>
>> "Allen Young" <allenmacyoung@gmail.com> wrote in message
>> news:dp083m$fkm$1@utils.eclipse.org...
>>
>>>Hi Michael:
>>>
>>>
>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>>GMF on top. I think it is the way to go.
>>>
>>>I think there is nothing to do with EMF for the workflow editor part. My
>>>workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
>>>workflow using GEF and generate the XPDL code at the same time. Actually
>>>I use a multiple editor to do the work and provide three views: graphic
>>>view in which we draw the workflow definition, tree view in which I treat
>>>XPDL as simple XML to show its structure as while as editing support
>>>according to XPDL schema, and source view in which we can see XPDL code
>>>and edit it with suggestions according to XPDL schema again.
>>>
>>>I cannot find the reason to use EMF if we implement jwt's workflow editor
>>>in this way. Or maybe we can just provide the graphic view. The drawing
>>>actions will create a structure of EMF generated model. Then users can
>>>save the workflow definition as XPDL, BPEL or anything else. But this has
>>>some disadvantages:
>>>1. Less views will reduce the convenience while using the editor. If
>>>someone is familiar with XPDL or BPEL, directly editing source with
>>>grammar suggestions will be more proper sometime.
>>>2. Not all the things can be transferred from BPEL to XPDL, vice versa.
>>>It's better to decide the definition language at the creation time other
>>>than tell the user the complicated diagram he/she drew cannot be
>>>saved as the format he/she wanted.
>>>3. Create java objects first, store them in memory and at a certain time
>>>generate the xml code could be a bottleneck of performance. If the
>>>worklfow process is very complicated or the user create many diagrams
>>>once, big occupying of memory will happen, which is neither acceptable
>>>nor necessary.
>>>
>>>So in my opinion, do not use EMF in workflow editor part. It is useful
>>>for WA part, not WE.
>>>
>>>Allen
>>>
>>>
>>>"Michael N. Lipp" <mnl@mnl.de> wrote in message
>>>news:dohkdv$8mq$1@utils.eclipse.org...
>>>
>>>>Hi,
>>>>
>>>>I've thought about an eclipse plugin for workflow editing for some time.
>>>>I've even started, but I had much too little time to achieve something
>>>>presentable so far.
>>>>
>>>>Here's my approach: leave out any legacy code. In order to be up-to-date
>>>>(especially to be still up-to-date when you have finished ;-)), use BPMN
>>>>as specification for the graphical representation and XPDL 2.0 as
>>>>format. Add editing modes that optionally restrict the available
>>>>elements to the BPEL or XPDL 1.0 subsets and provide a "Save as" or
>>>>export for this format.
>>>>
>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>>GMF on top. I think it is the way to go. If I there had been a little
>>>>bit more time at my disposal in the last six months...
>>>>
>>>>Regards,
>>>>
>>>> Michael
>>>
>>>
>>
>>
>
>
>
> Fabrice
|
|
|
| Re: Again, on EMF [message #13099 is a reply to message #10442] |
Fri, 13 January 2006 10:32 |
| Eclipse User |
|
|
|
Originally posted by: fabrice.dewasmes.openwide.fr
Guennadi Vanine wrote:
> Hi, Fabrice,
> It is business analyst, developer, modeler and programmer feedback.
>
> Yes I certainly tried GEF with EMF on the scale of a 200+ hours. It is
> certainly not to get up alone.
>
> I can tell you that I need one week alone in C#.NET
> http://blogs.msdn.com/markhsch/archive/2005/10/06/478042.asp x
> to create plug-in or stand-alone Workflow Editor Designer
> what will require a year in GEF with EMF.
alright. Let's take this into consideration. I'm going to post my
definitive impression on using GEF/GMF this day.
Fabrice
>
> Guennadi Vanine
> "Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
> news:dptet5$ep3$2@utils.eclipse.org...
>
>>Guennadi Vanine wrote:
>>
>>>After playing GEF with EMF I came to opinion that EMF probably has sense
>>>in context of properly integrated IDE/ modeling tool, i.e. it is
>>>IBM/Rational's bait to buy their commercial products.
>>>
>>>Otherwise it is time-and sanity-killer.
>>
>>Have you concretely tried to use it ? Is it a user feedback ?
>>
>>Fabrice
>>
>>
>>
>>>Guennadi Vanine
>>>
>>>"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
>>>news:dps63h$12d$1@utils.eclipse.org...
>>>
>>>
>>>>I would agree with Allen. He is original (in that he is not mimicking
>>>>opinions and visions of others, in this case, of IBM).
>>>>
>>>>I have exactly the same project for me alone for 3 months that you all
>>>>are
>>>>going to accomplish in more than a year scale.
>>>>
>>>>I should recreate anew in GEF with EMF already existing Workflow
>>>>Graphical
>>>>Editor in Swing.
>>>>
>>>>What is killing me is that no old/Swing code may be (re)used and
>>>>requirement of EMF. It is just "pain in the ass". Nobody has experience
>>>>with
>>>>it but everybody wants it.
>>>>
>>>>I also had big enthusiasm about EMF initially . It is a great time-,
>>>>good-wishes- and sanity-killer.
>>>>
>>>>Let me cite from
>>>>http://en.wikipedia.org/wiki/Model_view_controller
>>>>:
>>>>"The best models are fully encapsulated, meaning that they implement
>>>>every
>>>>aspect of that real world object of interest to the domain of interest,
>>>>and
>>>>that they don't have any extra code that doesn't model the real world."
>>>>what I am rereading for a second day for some or another reasons.
>>>>
>>>>Correct me,
>>>>Guennadi Vanine
>>>>
>>>>"Allen Young" <allenmacyoung@gmail.com> wrote in message
>>>>news:dp083m$fkm$1@utils.eclipse.org...
>>>>
>>>>
>>>>>Hi Michael:
>>>>>
>>>>>
>>>>>
>>>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start.
>>>>>>Put GMF on top. I think it is the way to go.
>>>>>
>>>>>I think there is nothing to do with EMF for the workflow editor part. My
>>>>>workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
>>>>>workflow using GEF and generate the XPDL code at the same time. Actually
>>>>>I use a multiple editor to do the work and provide three views: graphic
>>>>>view in which we draw the workflow definition, tree view in which I
>>>>>treat XPDL as simple XML to show its structure as while as editing
>>>>>support according to XPDL schema, and source view in which we can see
>>>>>XPDL code and edit it with suggestions according to XPDL schema again.
>>>>>
>>>>>I cannot find the reason to use EMF if we implement jwt's workflow
>>>>>editor in this way. Or maybe we can just provide the graphic view. The
>>>>>drawing actions will create a structure of EMF generated model. Then
>>>>>users can save the workflow definition as XPDL, BPEL or anything else.
>>>>>But this has some disadvantages:
>>>>>1. Less views will reduce the convenience while using the editor. If
>>>>>someone is familiar with XPDL or BPEL, directly editing source with
>>>>>grammar suggestions will be more proper sometime.
>>>>>2. Not all the things can be transferred from BPEL to XPDL, vice versa.
>>>>>It's better to decide the definition language at the creation time other
>>>>>than tell the user the complicated diagram he/she drew cannot be
>>>>>saved as the format he/she wanted.
>>>>>3. Create java objects first, store them in memory and at a certain time
>>>>>generate the xml code could be a bottleneck of performance. If the
>>>>>worklfow process is very complicated or the user create many diagrams
>>>>>once, big occupying of memory will happen, which is neither acceptable
>>>>>nor necessary.
>>>>>
>>>>>So in my opinion, do not use EMF in workflow editor part. It is useful
>>>>>for WA part, not WE.
>>>>>
>>>>>Allen
>>>>>
>>>>>
>>>>>"Michael N. Lipp" <mnl@mnl.de> wrote in message
>>>>>news:dohkdv$8mq$1@utils.eclipse.org...
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I've thought about an eclipse plugin for workflow editing for some
>>>>>>time. I've even started, but I had much too little time to achieve
>>>>>>something presentable so far.
>>>>>>
>>>>>>Here's my approach: leave out any legacy code. In order to be
>>>>>>up-to-date (especially to be still up-to-date when you have finished
>>>>>>;-)), use BPMN as specification for the graphical representation and
>>>>>>XPDL 2.0 as format. Add editing modes that optionally restrict the
>>>>>>available elements to the BPEL or XPDL 1.0 subsets and provide a "Save
>>>>>>as" or export for this format.
>>>>>>
>>>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start.
>>>>>>Put GMF on top. I think it is the way to go. If I there had been a
>>>>>>little bit more time at my disposal in the last six months...
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>> Michael
>>>>>
>>>>>
>
|
|
|
| Re: How to be really generic... [message #13128 is a reply to message #10476] |
Fri, 13 January 2006 10:34 |
| Eclipse User |
|
|
|
Originally posted by: fabrice.dewasmes.openwide.fr
Guennadi Vanine wrote:
> Fabrice:
> IMHO JaWE is the best Wf Designer I have seen in Java even in comparison
> with commercial products.
>
> As I understood Eclipse/IBM and Sun/Swing does not agree with each other
> To me it appears like JWT is going to kill JaWE.
>
> Can you share with me any links on JaWE docs (I found some but strange
>
What kind of docs are you looking for ? javadoc ? user guide ? technical
owverview ?
Fabrice
> Guennadi Vanine
> "Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
> news:dptens$ep3$1@utils.eclipse.org...
>
>>Guennadi Vanine wrote:
>>
>>>I would agree with Allen. He is original (in that he is not mimicking
>>>opinions and visions of others, in this case, of IBM).
>>
>>I haven't used EMF ever. I've tried to build simple models using simple
>>XSD schemas to see what it generates and I actually believed that it might
>>be interesting to give it a try.
>>
>>
>>>I have exactly the same project for me alone for 3 months that you all
>>>are
>>>going to accomplish in more than a year scale.
>>>
>>>I should recreate anew in GEF with EMF already existing Workflow
>>>Graphical
>>>Editor in Swing.
>>
>>Swing graphical editor is exactly what Jawe is (at least for XPDL).
>>
>>>What is killing me is that no old/Swing code may be (re)used and
>>>requirement of EMF. It is just "pain in the ass". Nobody has experience
>>>with
>>>it but everybody wants it.
>>>
>>>I also had big enthusiasm about EMF initially . It is a great time-,
>>>good-wishes- and sanity-killer.
>>>
>>>Let me cite from
>>>http://en.wikipedia.org/wiki/Model_view_controller
>>>:
>>>"The best models are fully encapsulated, meaning that they implement
>>>every
>>>aspect of that real world object of interest to the domain of interest,
>>>and
>>>that they don't have any extra code that doesn't model the real world."
>>>what I am rereading for a second day for some or another reasons.
>>>
>>>Correct me,
>>>Guennadi Vanine
>>>
>>>"Allen Young" <allenmacyoung@gmail.com> wrote in message
>>>news:dp083m$fkm$1@utils.eclipse.org...
>>>
>>>
>>>>Hi Michael:
>>>>
>>>>
>>>>
>>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>>>GMF on top. I think it is the way to go.
>>>>
>>>>I think there is nothing to do with EMF for the workflow editor part. My
>>>>workflow editor for XPDL1.0 doesn't use EMF at all. I just draw the
>>>>workflow using GEF and generate the XPDL code at the same time. Actually
>>>>I use a multiple editor to do the work and provide three views: graphic
>>>>view in which we draw the workflow definition, tree view in which I treat
>>>>XPDL as simple XML to show its structure as while as editing support
>>>>according to XPDL schema, and source view in which we can see XPDL code
>>>>and edit it with suggestions according to XPDL schema again.
>>>>
>>>>I cannot find the reason to use EMF if we implement jwt's workflow editor
>>>>in this way. Or maybe we can just provide the graphic view. The drawing
>>>>actions will create a structure of EMF generated model. Then users can
>>>>save the workflow definition as XPDL, BPEL or anything else. But this has
>>>>some disadvantages:
>>>>1. Less views will reduce the convenience while using the editor. If
>>>>someone is familiar with XPDL or BPEL, directly editing source with
>>>>grammar suggestions will be more proper sometime.
>>>>2. Not all the things can be transferred from BPEL to XPDL, vice versa.
>>>>It's better to decide the definition language at the creation time other
>>>>than tell the user the complicated diagram he/she drew cannot be
>>>>saved as the format he/she wanted.
>>>>3. Create java objects first, store them in memory and at a certain time
>>>>generate the xml code could be a bottleneck of performance. If the
>>>>worklfow process is very complicated or the user create many diagrams
>>>>once, big occupying of memory will happen, which is neither acceptable
>>>>nor necessary.
>>>>
>>>>So in my opinion, do not use EMF in workflow editor part. It is useful
>>>>for WA part, not WE.
>>>>
>>>>Allen
>>>>
>>>>
>>>>"Michael N. Lipp" <mnl@mnl.de> wrote in message
>>>>news:dohkdv$8mq$1@utils.eclipse.org...
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I've thought about an eclipse plugin for workflow editing for some time.
>>>>>I've even started, but I had much too little time to achieve something
>>>>>presentable so far.
>>>>>
>>>>>Here's my approach: leave out any legacy code. In order to be up-to-date
>>>>>(especially to be still up-to-date when you have finished ;-)), use BPMN
>>>>>as specification for the graphical representation and XPDL 2.0 as
>>>>>format. Add editing modes that optionally restrict the available
>>>>>elements to the BPEL or XPDL 1.0 subsets and provide a "Save as" or
>>>>>export for this format.
>>>>>
>>>>>Using EMF and XPDL 2.0 works quite well, it gives you an easy start. Put
>>>>>GMF on top. I think it is the way to go. If I there had been a little
>>>>>bit more time at my disposal in the last six months...
>>>>>
>>>>>Regards,
>>>>>
>>>>> Michael
>>>>
>>>>
>>>
>>
>>
>>Fabrice
>
>
>
|
|
| |
Goto Forum:
Current Time: Thu Dec 26 13:19:24 GMT 2024
Powered by FUDForum. Page generated in 0.05833 seconds |
] 
Search
Help
Register
Login
Home
