Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Java WorkFlow Tooling (JWT) » move to STP
move to STP [message #20115] Fri, 03 February 2006 09:15 Go to next message
Eclipse User
Originally posted by: fabrice.dewasmes.openwide.fr

Hi all,

Following discussions with STP PMC, it appears that we've got three
options for project creation :
- first we have an opportunity to be incubated as part of the STP BPMN
subproject.
- second we can be incubated inside technology project as every other
project and wait to move to a TLP.
- third start being incubated by technology project and move to STP at a
later time.

What are the consequences of the various options ?
In option 2, we are independant from anyone. But this state is expected
to be temporary as we should move to a TLP anyway.
In option 1, we are still 'somehow' independant from the TLP but in
software group that is clearly our concern.
In option 3, we start by being independant and keep the choice to move
to STP at a later time. HOWEVER, if this will be possible only if no
overlapping project exist inside STP at that time.

I *strongly* invite you to take a look at STP proposal at
http://www.eclipse.org/proposals/stp/

and eventually look at STP web site (even if it is really ready yet) at
http://www.eclipse.org/stp/.

Please keep in mind that process/workflow modeling is typically part of
the tools used to achieve SOA and moving to STP could be wise choice.

I wanted to know what you guys think of this and how we should request
the creation review. Anyone listed in the current JWT proposal state is
called to vote so please do so.

Best regards,

Fabrice Dewasmes
Re: move to STP [message #21504 is a reply to message #20115] Fri, 03 February 2006 11:47 Go to previous messageGo to next message
Eclipse User
Originally posted by: rzulauf.objeng.ch

Hi Fabrice

Fabrice Dewasmes wrote:
> Hi all,
>
> Following discussions with STP PMC, it appears that we've got three
> options for project creation :
> - first we have an opportunity to be incubated as part of the STP BPMN
> subproject.
> - second we can be incubated inside technology project as every other
> project and wait to move to a TLP.
> - third start being incubated by technology project and move to STP at a
> later time.
>
> What are the consequences of the various options ?
> In option 2, we are independant from anyone. But this state is expected
> to be temporary as we should move to a TLP anyway.
> In option 1, we are still 'somehow' independant from the TLP but in
> software group that is clearly our concern.
> In option 3, we start by being independant and keep the choice to move
> to STP at a later time. HOWEVER, if this will be possible only if no
> overlapping project exist inside STP at that time.
I feel this is a very important decision. The problem I see is that we
wanted to focus on XPDL while STP has the immediate goal of creating and
using BPEL processes.

In my opinion it would be best to get STP to use our editor and
contribute to it if it is missing support for some stuff they need. The
point is that our mission in terms of workflow editor and tooling is a
bit broader than that of STP - I consider WAM for example misplaced in
STP, and they do not have any need for XPDL or differeng graphical
representations.

Therefore my vote is for option 2, if the STP project agrees on using
our editor. If no consensus can be found, then we will be forced into
option 1 as STP clearly has more support from commercial companies at
the moment and I do not think two BPML editors will eventually survive.

However I do not think it is important as to whether we are considered a
subproject of STP or if we are a TLP, as long as:
- we still have somewhat control over our roadmap
- there is no risk of *two* BPML editors being written

Regards
Roman

>
> I *strongly* invite you to take a look at STP proposal at
> http://www.eclipse.org/proposals/stp/
>
> and eventually look at STP web site (even if it is really ready yet) at
> http://www.eclipse.org/stp/.
>
> Please keep in mind that process/workflow modeling is typically part of
> the tools used to achieve SOA and moving to STP could be wise choice.
>
> I wanted to know what you guys think of this and how we should request
> the creation review. Anyone listed in the current JWT proposal state is
> called to vote so please do so.
>
> Best regards,
>
> Fabrice Dewasmes
confused<--move to STP [message #21522 is a reply to message #21504] Fri, 03 February 2006 18:07 Go to previous messageGo to next message
Eclipse User
Originally posted by: vgv8.yahoo.com.br

> I feel this is a very important decision. The problem I see is that we
> wanted to focus on XPDL while STP has the immediate goal of creating and
> using BPEL processes.

I also want XPDL and/or even non-standard (pluggable) XML.
XPDL is just superset of BPEL, BPML, etc.

BPEL is linked to WSDL

But :
- SOA is NOT synonym of webservices;
- workflow designers are needed NOT only to specify webservices and SOA!
They are needed first of all for business processes with user interaction
what BPEL lacks!
- webservices is not the means of interoperability in intranet and
webservices make sense for external to enterprise comm. This is specific
problem of Java that Java doesn't have interoperable binary protocols

Well, all this is serious and we should discriminate what doesn't overlap
with others. If GMF (after pushing EMF) satisfies its requirements of
extensibility, interoperability, pluggability and support of different
languages... JWT designer may also be seen as GMF subproject and GMF will
make many parts of STP redundant also

I feel bad about all this scattering and multiplication of centrifugal
projects, framewroks without observable intentions to create integrating
them architecture

Less of all, I want to see JWT designer restricted by webservices/BPEL

Guennadi Vanine
interoperability is not webservices [message #21571 is a reply to message #21522] Sun, 05 February 2006 09:13 Go to previous messageGo to next message
Eclipse User
Originally posted by: vgv8.yahoo.com.br

The problem is that webservices in Java platform is synonym of
interoperability and this is wrong policy and distorted concept, if to speak
about general purpose Workflow Designer.

http://elearning4guruscom.ntitemp.com/only4gurus/techlib/mis cellaneous/j2ee_vs_net.pdf
"J2EE vs. NET - An Executive Look"
"Sun's interoperability strategy for J2EE is based on the communications
protocol called IIOP which have the following problems: Only supports J2EE
and CORBA, is not designed to transport over the Internet and current
specification of IIOP is inadequate to ensure interoperability[16].
The.NET platform has a much stronger technology neutral e-Collaboration
strategy than does J2EE.
Inaddition, the .NET platform have a set of application servers that
supports other forms of e-Collaboration..."

Guennadi Vanine

"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
news:ds0nn8$sr7$1@utils.eclipse.org...
>> I feel this is a very important decision. The problem I see is that we
>> wanted to focus on XPDL while STP has the immediate goal of creating and
>> using BPEL processes.
>
> I also want XPDL and/or even non-standard (pluggable) XML.
> XPDL is just superset of BPEL, BPML, etc.
>
> BPEL is linked to WSDL
>
> But :
> - SOA is NOT synonym of webservices;
> - workflow designers are needed NOT only to specify webservices and SOA!
> They are needed first of all for business processes with user interaction
> what BPEL lacks!
> - webservices is not the means of interoperability in intranet and
> webservices make sense for external to enterprise comm. This is specific
> problem of Java that Java doesn't have interoperable binary protocols
>
> Well, all this is serious and we should discriminate what doesn't overlap
> with others. If GMF (after pushing EMF) satisfies its requirements of
> extensibility, interoperability, pluggability and support of different
> languages... JWT designer may also be seen as GMF subproject and GMF will
> make many parts of STP redundant also
>
> I feel bad about all this scattering and multiplication of centrifugal
> projects, framewroks without observable intentions to create integrating
> them architecture
>
> Less of all, I want to see JWT designer restricted by webservices/BPEL
>
> Guennadi Vanine
>
>
>
>
Re: confused<--move to STP [message #21661 is a reply to message #21522] Tue, 07 February 2006 08:46 Go to previous messageGo to next message
Eclipse User
Originally posted by: fabrice.dewasmes.openwide.fr

Guennadi Vanine wrote:
>>I feel this is a very important decision. The problem I see is that we
>>wanted to focus on XPDL while STP has the immediate goal of creating and
>>using BPEL processes.
>
>
> I also want XPDL and/or even non-standard (pluggable) XML.
> XPDL is just superset of BPEL, BPML, etc.
>
> BPEL is linked to WSDL
>
> But :
> - SOA is NOT synonym of webservices;

beware that WSDL does not necessarily mean web service. More and more
WSDL is used as a interoperable contract. Kind of interface in the java
programming language but understable and usable by any language.

> - workflow designers are needed NOT only to specify webservices and SOA!

This is true. But what should be taken into consideration is the
visibility. If we get more visibility being incubated by STP then it may
be acceptable to switch to STP even if get a 'SOA label'. Of course this
depends of a shared agreement.

> They are needed first of all for business processes with user interaction
> what BPEL lacks!
> - webservices is not the means of interoperability in intranet and
> webservices make sense for external to enterprise comm. This is specific
> problem of Java that Java doesn't have interoperable binary protocols
>
> Well, all this is serious and we should discriminate what doesn't overlap
> with others. If GMF (after pushing EMF) satisfies its requirements of
> extensibility, interoperability, pluggability and support of different
> languages... JWT designer may also be seen as GMF subproject and GMF will
> make many parts of STP redundant also

I guess this won't ever happen. GMF won't host subproject.

>
> I feel bad about all this scattering and multiplication of centrifugal
> projects, framewroks without observable intentions to create integrating
> them architecture

>
> Less of all, I (don't ?) want to see JWT designer restricted by webservices/BPEL
neither do I.
>
> Guennadi Vanine
>
>
>
>
already decided: share schemas and not types [message #21706 is a reply to message #21661] Fri, 10 February 2006 02:47 Go to previous messageGo to next message
Eclipse User
Originally posted by: vgv8.yahoo.com.br

"Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
news:dsa8kc$a3u$1@utils.eclipse.org...
> beware that WSDL does not necessarily mean web service. More and more WSDL
> is used as a interoperable contract. Kind of interface in the java
> programming language but understable and usable by any language.
>
We already agreed but I'd like to comment
For ex., I need to interoperate through Repository, or drop-file... no
bindings, porttypes of WSDL

I really like .NET(Indigo/Avalon/Vista/Biztalk/MS SWL Server 2005/WWF/)
approach: share schemas and not types, use internally XML/XAML for
everything

I recommend to look into Biztalk2004/2006 how they realized what we need in
JWT. It has many replies and interesting approaches

Guennadi Vanine
repository is not registry [message #21751 is a reply to message #21706] Sat, 11 February 2006 14:41 Go to previous messageGo to next message
Eclipse User
Originally posted by: vgv8.yahoo.com.br

I saw that repository is sometimes considered to be synonym of registry.
I do not. IMHO registry (UDDI, WSDL) is usually for services and repository
IMHO for data, files.

Guennadi Vanine
"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
news:dshgf1$epm$1@utils.eclipse.org...
> "Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
> news:dsa8kc$a3u$1@utils.eclipse.org...
>> beware that WSDL does not necessarily mean web service. More and more
>> WSDL is used as a interoperable contract. Kind of interface in the java
>> programming language but understable and usable by any language.
>>
> We already agreed but I'd like to comment
> For ex., I need to interoperate through Repository, or drop-file... no
> bindings, porttypes of WSDL
>
> I really like .NET(Indigo/Avalon/Vista/Biztalk/MS SWL Server 2005/WWF/)
> approach: share schemas and not types, use internally XML/XAML for
> everything
>
> I recommend to look into Biztalk2004/2006 how they realized what we need
> in JWT. It has many replies and interesting approaches
>
> Guennadi Vanine
>
dependencies to take into account [message #21796 is a reply to message #21661] Sat, 11 February 2006 16:24 Go to previous messageGo to next message
Eclipse User
Originally posted by: vgv8.yahoo.com.br

I beleive the following thread is relevant to this decision
http://www.eclipse.org/newsportal/article.php?id=1111&gr oup=eclipse.technology.gmf#1111
i.e. there are extensibility, interoperability (both inside and outside of
Eclipse, as well as integration), (re)unification/cooperation (with other
Eclipse projects), XML formats pluggability depending on...

Guennadi Vanine
"Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
news:dsa8kc$a3u$1@utils.eclipse.org...
> Guennadi Vanine wrote:
>>>I feel this is a very important decision. The problem I see is that we
>>>wanted to focus on XPDL while STP has the immediate goal of creating and
>>>using BPEL processes.
>>
>>
>> I also want XPDL and/or even non-standard (pluggable) XML.
>> XPDL is just superset of BPEL, BPML, etc.
>>
>> BPEL is linked to WSDL
>>
>> But :
>> - SOA is NOT synonym of webservices;
>
> beware that WSDL does not necessarily mean web service. More and more WSDL
> is used as a interoperable contract. Kind of interface in the java
> programming language but understable and usable by any language.
>
>> - workflow designers are needed NOT only to specify webservices and SOA!
>
> This is true. But what should be taken into consideration is the
> visibility. If we get more visibility being incubated by STP then it may
> be acceptable to switch to STP even if get a 'SOA label'. Of course this
> depends of a shared agreement.
>
>> They are needed first of all for business processes with user interaction
>> what BPEL lacks!
>> - webservices is not the means of interoperability in intranet and
>> webservices make sense for external to enterprise comm. This is specific
>> problem of Java that Java doesn't have interoperable binary protocols
>>
>> Well, all this is serious and we should discriminate what doesn't overlap
>> with others. If GMF (after pushing EMF) satisfies its requirements of
>> extensibility, interoperability, pluggability and support of different
>> languages... JWT designer may also be seen as GMF subproject and GMF will
>> make many parts of STP redundant also
>
> I guess this won't ever happen. GMF won't host subproject.
>
>>
>> I feel bad about all this scattering and multiplication of centrifugal
>> projects, framewroks without observable intentions to create integrating
>> them architecture
>
>>
>> Less of all, I (don't ?) want to see JWT designer restricted by
>> webservices/BPEL
> neither do I.
>>
>> Guennadi Vanine
>>
>>
>>
No to contracts, i.e. rigid coupling! [message #21935 is a reply to message #21706] Sun, 12 February 2006 09:26 Go to previous messageGo to next message
Eclipse User
Originally posted by: vgv8.yahoo.com.br

http://www.theserverside.net/blogs/showblog.tss?id=BizTalkLo oseCoupling

"Guennadi Vanine" <vgv8@yahoo.com.br> wrote in message
news:dshgf1$epm$1@utils.eclipse.org...
> "Fabrice Dewasmes" <fabrice.dewasmes@openwide.fr> wrote in message
> news:dsa8kc$a3u$1@utils.eclipse.org...
>> beware that WSDL does not necessarily mean web service. More and more
>> WSDL is used as a interoperable contract. Kind of interface in the java
>> programming language but understable and usable by any language.
>>
> We already agreed but I'd like to comment
> For ex., I need to interoperate through Repository, or drop-file... no
> bindings, porttypes of WSDL
>
> I really like .NET(Indigo/Avalon/Vista/Biztalk/MS SWL Server 2005/WWF/)
> approach: share schemas and not types, use internally XML/XAML for
> everything
>
> I recommend to look into Biztalk2004/2006 how they realized what we need
> in JWT. It has many replies and interesting approaches
>
> Guennadi Vanine
>
Re: repository is not registry [message #22025 is a reply to message #21751] Mon, 13 February 2006 04:50 Go to previous message
Eclipse User
Originally posted by: fabrice.dewasmes.openwide.fr

Guennadi Vanine wrote:
> I saw that repository is sometimes considered to be synonym of registry.
> I do not. IMHO registry (UDDI, WSDL) is usually for services and repository
> IMHO for data, files.
>

Completely agree.
Previous Topic:Wrap-up
Next Topic:creation review slides
Goto Forum:
  


Current Time: Fri Aug 22 09:59:32 EDT 2014

Powered by FUDForum. Page generated in 0.02183 seconds