| Re: [stp-newsgroup] SCA v0.95 EMF model contribution? [message #587221] |
Tue, 22 August 2006 15:24 |
 Daniel Berg
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
This is a multipart message in MIME format.
--=_alternative 00544634852571D2_=
Content-Type: text/plain; charset="US-ASCII"
This is a completely different topic.
We are updating the schemas and models now to react to the 0.95 (looking
at 0.96 now as well). For the most part the changes are aligned with the
direction that we wanted. That is that Composite has been added as a
first class type. The big change is that Module, EntryPoint,
ExternalReference, and ModuleComponent are removed. The main concepts
still in the spec are the following:
Composite
Component
Implementation
ComponentType
Service
Reference
Interface
Binding
Wire
Composite is an implementation and can be set as the implementation of a
component. EntryPoints have been replaced with Service and
ExternalService has been replaced with Reference. Composites support
"includes" semantics to enable teams to divide the content of a Composite
into more manageable bits. When a Composite is included in another
Composite all of its contents are "absorbed" into the definition of the
containing Composite. Therefore, the Composite is nothing more than a
container in this situation.
The spec hasn't changed Subsystem too much except to remove
ModuleComponent and SystemWire. However, there is still a great deal of
churn around the deployment model in SCA so we are going to avoid this
area of the model for now until the specification settles on an approach.
Regards,
Dan
Oisin Hurley <ohurley@iona.com>
Sent by: stp-newsgroup-bounces@eclipse.org
08/21/2006 05:37 PM
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?
> 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.
I agree that formal contracts is the place to share and not
the generated code, absolutely. However, afaik last time I
checked, the Tuscany code is using the 0.95 schemas and the
STP Core is not and that's the misalignment that needs to
be watched.
I'll gather up the schemas from each project and take a look
at the differences and summarize to the dev list.
cheers
--oh
_______________________________________________
stp-newsgroup mailing list
stp-newsgroup@eclipse.org
https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
--=_alternative 00544634852571D2_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">This is a completely different topic.</font>
<br>
<br><font size=2 face="sans-serif">We are updating the schemas and models
now to react to the 0.95 (looking at 0.96 now as well). For the most
part the changes are aligned with the direction that we wanted. That
is that Composite has been added as a first class type. The big change
is that Module, EntryPoint, ExternalReference, and ModuleComponent are
removed. The main concepts still in the spec are the following:</font>
<br>
<br><font size=2 face="sans-serif">Composite</font>
<br><font size=2 face="sans-serif">Component</font>
<br><font size=2 face="sans-serif">Implementation</font>
<br><font size=2 face="sans-serif">ComponentType</font>
<br><font size=2 face="sans-serif">Service</font>
<br><font size=2 face="sans-serif">Reference</font>
<br><font size=2 face="sans-serif">Interface</font>
<br><font size=2 face="sans-serif">Binding</font>
<br><font size=2 face="sans-serif">Wire</font>
<br>
<br><font size=2 face="sans-serif">Composite is an implementation and can
be set as the implementation of a component. EntryPoints have been
replaced with Service and ExternalService has been replaced with Reference.
Composites support "includes" semantics to enable teams
to divide the content of a Composite into more manageable bits. When
a Composite is included in another Composite all of its contents are "absorbed"
into the definition of the containing Composite. Therefore, the Composite
is nothing more than a container in this situation.</font>
<br>
<br><font size=2 face="sans-serif">The spec hasn't changed Subsystem too
much except to remove ModuleComponent and SystemWire. However, there
is still a great deal of churn around the deployment model in SCA so we
are going to avoid this area of the model for now until the specification
settles on an approach.</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/21/2006 05:37 PM</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>> We do share a common model that is generated
differently. The <br>
> shared model is in the form of standard XSDs. For Tuscany they
<br>
> generate one<br>
> model instance and for the tools we generate an EMF model <br>
> instance. So the level of sharing for the models stops at the
<br>
> formal contract.<br>
<br>
I agree that formal contracts is the place to share and not<br>
the generated code, absolutely. However, afaik last time I<br>
checked, the Tuscany code is using the 0.95 schemas and the<br>
STP Core is not and that's the misalignment that needs to<br>
be watched.<br>
<br>
I'll gather up the schemas from each project and take a look<br>
at the differences and summarize to the dev list.<br>
<br>
cheers<br>
--oh<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 00544634852571D2_=--
|
|
|
Powered by
FUDForum. Page generated in 0.01800 seconds
] 
Search
Help
Register
Login
Home
