[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [stp-dev] Service Creation questions

1st I agree that we do not want to maintain this subproject on its own, instead I would really like to see as part of broader tooling integration project.
Again the reason it was initially described on its own is for historical reasons and because we believe it isn't part of the core framework.
We do intend to make use of the introspection mechanism, but the aim of SC is to integrate tools, not just the by products of those tools (i.e assemblies and service implementations) as the introspectors do. And more than the raw features of the introspector will be required for this. 
if we take the notification change for example: 
I believe too that any STP resource view, or the likes, will very likely be based on the common navigator but that's an implementation details (so to speak) that's why I did not mentioned it at this stage.

From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Berg
Sent: 12 May 2006 03:25
To: STP Dev list
Cc: STP Dev list; stp-dev-bounces@xxxxxxxxxxx
Subject: RE: [stp-dev] Service Creation questions

I am still confused for the following reasons.
  1. The core contribution already has an "introspection" extension point in place to allow implementation types to produce and react to changes in the componentType definition.
  2. The core contribution already has change notification built into the componentType to allow for changes to the componentType to be propagated back to the implementation.
  3. The central assembly resources view sounds like an instance of the Eclipse platform Common Navigator.  If it is not then I would like to know what this view is intended to provide.  The Common Navigator provides a way to register content providers to display content and actions in a tree view (i.e., a navigator).
    Is it the intention that this subproject is providing the SOA perspective?  Do we really need a full subproject for this?

I still do not see a compelling reason to sustain this subproject.  Maybe the work intended for the subproject should be rolled into another subproject.


"Beaurpere, David" <David.Beaurpere@xxxxxxxx>
Sent by: stp-dev-bounces@xxxxxxxxxxx

05/11/2006 05:44 AM

Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>

"STP Dev list" <stp-dev@xxxxxxxxxxx>
RE: [stp-dev] Service Creation questions

Actually I think that SC and SAF look complementary: the Service Creation project intends to focus on supporting existing service implementation tools while, and as far as I understand it, SAF focuses on supporting tools that will manipulate the assembly itself (graphical or otherwise).
SC is not about manipulating the assembly, it aims at providing an integration layer for existing service implementation tooling to integrate with with STP platform in term of We do not really have more detailed requirements yet as we need to work more with the SCA/STP framework and understand better what will be needed. The plan is to acquire that understanding by 1st focusing  on developing an initial exemplary tool based on the Celtix runtime. So both the Celtix tools and the SC platform will be worked on in parallel.

From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Berg
09 May 2006 16:30
STP Dev list
[stp-dev] Service Creation questions

I am not clear about the role of the Service Creation subproject.  It seems like there may be some overlap with the
SOA Assembly Framework in the Core subproject.  We need to ensure that we are clear on the content in the subproject to avoid duplicate work.

stp-dev mailing list