Eclipse Community Forums: Service Oriented Architecture Tools Platform (STP) » Re: [stp-newsgroup] SCA v0.95 EMF model contribution?

Home » Archived » Service Oriented Architecture Tools Platform (STP) » Re: [stp-newsgroup] SCA v0.95 EMF model contribution?

Show: Today's Messages :: Show Polls :: Message Navigator

Re: [stp-newsgroup] SCA v0.95 EMF model contribution? [message #374041]

Mon, 14 August 2006 20:44

Daniel Berg

Messages: 19
Registered: July 2009

Junior Member

This is a multipart message in MIME format.
--=_alternative 0071ACD5852571CA_=
Content-Type: text/plain; charset="US-ASCII"

We do share a common model that is generated differently. The shared
model is in the form of standard XSDs. For Tuscany they generate one
model instance and for the tools we generate an EMF model instance. So
the level of sharing for the models stops at the formal contract.
In my time of building tools I have seen sharing between the runtime. At
first we (tools guys) created the models that would be used by
the tools and runtime. This was not so easy since the tools couldn't add
dependencies which they wanted because they were not
available in the runtime and the runtime complained because of the extra
baggage of the model to support interactive development.
I've also worked on projects that took the models from the runtime and
used them in the tools. These models were better within the runtime but
fell short in the tools and a large number of hacks were put in place to
allow overrides in the tools environment.

In the end it is best to share formal contracts and not actual binaries.
But this is only by 2 cents.

Regards,
Dan

Oisin Hurley <ohurley@iona.com>
Sent by: stp-newsgroup-bounces@eclipse.org
08/14/2006 08:59 AM
Please respond to
"Gateway between eclipse.stp and stp-newsgroup"
<stp-newsgroup@eclipse.org>

To
"Gateway between eclipse.stp and stp-newsgroup"
<stp-newsgroup@eclipse.org>
cc

Subject
Re: [stp-newsgroup] SCA v0.95 EMF model contribution?

> Yes there are plans to update the current stp.core.* plug-ins to be
> compliant with the latest specification level. We have been
> putting this off since the spec is still churning and no-one in STP
> was clamoring for the latest changes.

Keeping an implementation in line with a moving specification is always
a challenge as it can be easier to change words rather than change
code :)

This is an issue that the folk that are working on the Tuscany
project [0]
are also facing in their work on an SCA-supporting runtime. During
ApacheCon
EU earlier this year, I had a chat with Jim Marino and Jeremy Boynes
about
how STP and Tuscany could share information, technology, expertise or
whatever to allow both of us to move faster in our reactions to the
spec.

We kicked around some ideas, but nothing presented itself as being an
obvious contender - one of the reasons being that we're working from an
EMF model purposed to provision of a UI, whereas they are working from
a POJO model (which was once EMF), purposed to the provision of a
runtime.

I think however that as two open source projects with licenses that are
considered 'friendly', we should invest a little more time in seeing how
would could approach this challenge together. For example, is it
feasible
to construct a model that we could both share, based on EMF, but
generate
code differently?

Anyone got any opinions? :)

cheers
--oh

[0] http://incubator.apache.org/tuscany
_______________________________________________
stp-newsgroup mailing list
stp-newsgroup@eclipse.org
https://dev.eclipse.org/mailman/listinfo/stp-newsgroup

--=_alternative 0071ACD5852571CA_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">We do share a common model that is generated
differently.  The shared model is in the form of standard XSDs.  For
Tuscany they generate one</font>
<br><font size=2 face="sans-serif">model instance and for the tools we
generate an EMF model instance.  So the level of sharing for the models
stops at the formal contract.</font>
<br><font size=2 face="sans-serif">In my time of building tools I have
seen sharing between the runtime.  At first we (tools guys) created
the models that would be used by </font>
<br><font size=2 face="sans-serif">the tools and runtime.  This was
not so easy since the tools couldn't add dependencies which they wanted
because they were not</font>
<br><font size=2 face="sans-serif">available in the runtime and the runtime
complained because of the extra baggage of the model to support interactive
development.<br>
I've also worked on projects that took the models from the runtime and
used them in the tools.  These models were better within the runtime
but</font>
<br><font size=2 face="sans-serif">fell short in the tools and a large
number of hacks were put in place to allow overrides in the tools environment.</font>
<br>
<br><font size=2 face="sans-serif">In the end it is best to share formal
contracts and not actual binaries.  But this is only by 2 cents.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Dan<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Oisin Hurley <ohurley@iona.com></b>
</font>
<br><font size=1 face="sans-serif">Sent by: stp-newsgroup-bounces@eclipse.org</font>
<p><font size=1 face="sans-serif">08/14/2006 08:59 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
"Gateway between eclipse.stp and stp-newsgroup" <stp-newsgroup@eclipse.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"Gateway between eclipse.stp and
stp-newsgroup" <stp-newsgroup@eclipse.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [stp-newsgroup] SCA v0.95 EMF model
contribution?</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>> Yes there are plans to update the current stp.core.*
plug-ins to be  <br>
> compliant with the latest specification level.  We have been
 <br>
> putting this off since the spec is still churning and no-one in STP
 <br>
> was clamoring for the latest changes.<br>
<br>
Keeping an implementation in line with a moving specification is always<br>
a challenge as it can be easier to change words rather than change  <br>
code :)<br>
<br>
This is an issue that the folk that are working on the Tuscany  <br>
project [0]<br>
are also facing in their work on an SCA-supporting runtime. During  <br>
ApacheCon<br>
EU earlier this year, I had a chat with Jim Marino and Jeremy Boynes  <br>
about<br>
how STP and Tuscany could share information, technology, expertise or<br>
whatever to allow both of us to move faster in our reactions to the  <br>
spec.<br>
<br>
We kicked around some ideas, but nothing presented itself as being an<br>
obvious contender - one of the reasons being that we're working from an<br>
EMF model purposed to provision of a UI, whereas they are working from<br>
a POJO model (which was once EMF), purposed to the provision of a  <br>
runtime.<br>
<br>
I think however that as two open source projects with licenses that are<br>
considered 'friendly', we should invest a little more time in seeing how<br>
would could approach this challenge together. For example, is it  <br>
feasible<br>
to construct a model that we could both share, based on EMF, but  <br>
generate<br>
code differently?<br>
<br>
Anyone got any opinions? :)<br>
<br>
 cheers<br>
  --oh<br>
<br>
<br>
[0] http://incubator.apache.org/tuscany<br>
_______________________________________________<br>
stp-newsgroup mailing list<br>
stp-newsgroup@eclipse.org<br>
https://dev.eclipse.org/mailman/listinfo/stp-newsgroup<br>
</font></tt>
<br>
--=_alternative 0071ACD5852571CA_=--

Report message to a moderator

Re: [stp-newsgroup] SCA v0.95 EMF model contribution? [message #374076 is a reply to message #374041]

Wed, 06 June 2007 18:00

Eclipse User

Originally posted by: carrasco.ModelDrivenDevelopment.co.uk

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01C7A875.54A30BC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Alternatively, the ComponentX implementation of the spec SCA was =
inspired in,
did execute the very same specification,
with no difference whatsoever between tool and server deployment
(other that the aspect-based bindings to resources and end-points).
http://portal.modeldriven.org/web/guest/downloads

Others used this just as a "contract point",
but for that, ebXML BPSS variant was more specific
to contract between external collaborating parties.
"Daniel Berg" <danberg@us.ibm.com> wrote in message =
news:mailman.6.1155588297.5402.stp-newsgroup@eclipse.org...

We do share a common model that is generated differently. The shared =
model is in the form of standard XSDs. For Tuscany they generate one=20
model instance and for the tools we generate an EMF model instance. =
So the level of sharing for the models stops at the formal contract.=20
In my time of building tools I have seen sharing between the runtime. =
At first we (tools guys) created the models that would be used by=20
the tools and runtime. This was not so easy since the tools couldn't =
add dependencies which they wanted because they were not=20
available in the runtime and the runtime complained because of the =
extra baggage of the model to support interactive development.
I've also worked on projects that took the models from the runtime and =
used them in the tools. These models were better within the runtime but =

fell short in the tools and a large number of hacks were put in place =
to allow overrides in the tools environment.=20

In the end it is best to share formal contracts and not actual =
binaries. But this is only by 2 cents.=20

Regards,
Dan

Oisin Hurley <ohurley@iona.com>=20
Sent by: stp-newsgroup-bounces@eclipse.org=20
08/14/2006 08:59 AM Please respond to
"Gateway between eclipse.stp and stp-newsgroup" =
<stp-newsgroup@eclipse.org>=20

To "Gateway between eclipse.stp and stp-newsgroup" =
<stp-newsgroup@eclipse.org> =20
cc =20
Subject Re: [stp-newsgroup] SCA v0.95 EMF model =
contribution?=20

=20

=20

> Yes there are plans to update the current stp.core.* plug-ins to be =

> compliant with the latest specification level. We have been =20
> putting this off since the spec is still churning and no-one in STP =

> was clamoring for the latest changes.

Keeping an implementation in line with a moving specification is =
always
a challenge as it can be easier to change words rather than change =20
code :)

This is an issue that the folk that are working on the Tuscany =20
project [0]
are also facing in their work on an SCA-supporting runtime. During =20
ApacheCon
EU earlier this year, I had a chat with Jim Marino and Jeremy Boynes =20
about
how STP and Tuscany could share information, technology, expertise or
whatever to allow both of us to move faster in our reactions to the =20
spec.

We kicked around some ideas, but nothing presented itself as being an
obvious contender - one of the reasons being that we're working from =
an
EMF model purposed to provision of a UI, whereas they are working from
a POJO model (which was once EMF), purposed to the provision of a =20
runtime.

I think however that as two open source projects with licenses that =
are
considered 'friendly', we should invest a little more time in seeing =
how
would could approach this challenge together. For example, is it =20
feasible
to construct a model that we could both share, based on EMF, but =20
generate
code differently?

Anyone got any opinions? :)

cheers
--oh

[0] http://incubator.apache.org/tuscany
_______________________________________________
stp-newsgroup mailing list
stp-newsgroup@eclipse.org
https://dev.eclipse.org/mailman/listinfo/stp-newsgroup

------=_NextPart_000_0069_01C7A875.54A30BC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Alternatively, the ComponentX =
implementation of the=20
spec SCA was inspired in,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>did execute the very same=20
specification,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>with no difference whatsoever between =
tool and=20
server deployment</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(other that the aspect-based bindings =
to resources=20
and end-points).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://portal.modeldriven.org/web/guest/downloads">http://portal.=
modeldriven.org/web/guest/downloads</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Others used this just as a "contract=20
point",</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>but for that, ebXML BPSS variant was =
more=20
specific</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to contract between external =
collaborating=20
parties.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Daniel Berg" <<A=20
href=3D"mailto:danberg@us.ibm.com">danberg@us.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:mailman.6.1155588297.5402.stp-newsgroup@eclipse.org">news:ma=
ilman.6.1155588297.5402.stp-newsgroup@eclipse.org</A>...</DIV><BR><FONT=20
face=3Dsans-serif size=3D2>We do share a common model that is =
generated=20
differently.  The shared model is in the form of standard XSDs. =
 For=20
Tuscany they generate one</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>model=20
instance and for the tools we generate an EMF model instance.  So =
the=20
level of sharing for the models stops at the formal contract.</FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2>In my time of building tools I have seen =
sharing=20
between the runtime.  At first we (tools guys) created the models =
that=20
would be used by </FONT><BR><FONT face=3Dsans-serif size=3D2>the tools =
and=20
runtime.  This was not so easy since the tools couldn't add =
dependencies=20
which they wanted because they were not</FONT> <BR><FONT =
face=3Dsans-serif=20
size=3D2>available in the runtime and the runtime complained because =
of the=20
extra baggage of the model to support interactive development.<BR>I've =
also=20
worked on projects that took the models from the runtime and used them =
in the=20
tools.  These models were better within the runtime but</FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2>fell short in the tools and a large number =
of hacks=20
were put in place to allow overrides in the tools environment.</FONT>=20
<BR><BR><FONT face=3Dsans-serif size=3D2>In the end it is best to =
share formal=20
contracts and not actual binaries.  But this is only by 2 =
cents.</FONT>=20
<BR><BR><FONT face=3Dsans-serif=20
size=3D2>Regards,<BR>Dan<BR><BR></FONT><BR><BR><BR>
<TABLE width=3D"100%">
<TBODY>
<TR vAlign=3Dtop>
<TD width=3D"40%"><FONT face=3Dsans-serif size=3D1><B>Oisin Hurley =

<ohurley@iona.com></B> </FONT><BR><FONT face=3Dsans-serif=20
size=3D1>Sent by: stp-newsgroup-bounces@eclipse.org</FONT>=20
<P><FONT face=3Dsans-serif size=3D1>08/14/2006 08:59 AM</FONT>=20
<TABLE border=3D1>
<TBODY>
<TR vAlign=3Dtop>
<TD bgColor=3Dwhite>
<DIV align=3Dcenter><FONT face=3Dsans-serif =
size=3D1>Please respond=20
to<BR>"Gateway between eclipse.stp and stp-newsgroup"=20
=
<stp-newsgroup@eclipse.org></FONT></DIV></TR></TBODY></TABLE><BR></=
P>
<TD width=3D"59%">
<TABLE width=3D"100%">
<TBODY>
<TR vAlign=3Dtop>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>To</FONT></DIV>
<TD><FONT face=3Dsans-serif size=3D1>"Gateway between =
eclipse.stp and=20
stp-newsgroup" <stp-newsgroup@eclipse.org></FONT>=20
<TR vAlign=3Dtop>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>cc</FONT></DIV>
<TD>
<TR vAlign=3Dtop>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>Subject</FONT></DIV>
<TD><FONT face=3Dsans-serif size=3D1>Re: [stp-newsgroup] SCA =
v0.95 EMF=20
model contribution?</FONT></TR></TBODY></TABLE><BR>
<TABLE>
<TBODY>
<TR vAlign=3Dtop>
<TD>
=
<TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR ><BR><BR><TT><FONT=20
size=3D2>> Yes there are plans to update the current stp.core.* =
plug-ins to=20
be  <BR>> compliant with the latest specification level. =
 We have=20
been  <BR>> putting this off since the spec is still churning =
and=20
no-one in STP  <BR>> was clamoring for the latest=20
changes.<BR><BR>Keeping an implementation in line with a moving =
specification=20
is always<BR>a challenge as it can be easier to change words rather =
than=20
change  <BR>code :)<BR><BR>This is an issue that the folk that =
are=20
working on the Tuscany  <BR>project [0]<BR>are also facing in =
their work=20
on an SCA-supporting runtime. During  <BR>ApacheCon<BR>EU earlier =
this=20
year, I had a chat with Jim Marino and Jeremy Boynes =
 <BR>about<BR>how=20
STP and Tuscany could share information, technology, expertise =
or<BR>whatever=20
to allow both of us to move faster in our reactions to the=20
 <BR>spec.<BR><BR>We kicked around some ideas, but nothing =
presented=20
itself as being an<BR>obvious contender - one of the reasons being =
that we're=20
working from an<BR>EMF model purposed to provision of a UI, whereas =
they are=20
working from<BR>a POJO model (which was once EMF), purposed to the =
provision=20
of a  <BR>runtime.<BR><BR>I think however that as two open source =

projects with licenses that are<BR>considered 'friendly', we should =
invest a=20
little more time in seeing how<BR>would could approach this challenge=20
together. For example, is it  <BR>feasible<BR>to construct a =
model that=20
we could both share, based on EMF, but  <BR>generate<BR>code=20
differently?<BR><BR>Anyone got any opinions? =
:)<BR><BR> cheers<BR> =20
--oh<BR><BR><BR>[0]=20
=
http://incubator.apache.org/tuscany<BR>__________________________________=
_____________<BR>stp-newsgroup=20
mailing=20
=
list<BR>stp-newsgroup@eclipse.org<BR>https://dev.eclipse.org/mailman/list=
info/stp-newsgroup<BR></FONT></TT><BR></BLOCKQUOTE></BODY ></HTML>

------=_NextPart_000_0069_01C7A875.54A30BC0--

Report message to a moderator

Re: [stp-newsgroup] SCA v0.95 EMF model contribution? [message #589352 is a reply to message #374041]

Wed, 06 June 2007 18:00

Eclipse User

Report message to a moderator

Previous Topic:	Do the STP run on a Mac ?
Next Topic:	B2J generated files do not compile

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 22:31:11 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter