[
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:
-
notification from componentType to implementation is
provided but what about the other way around? at this point I am think of an
"SC/STP" nature and a builder that rerun the
introspector
-
the other way around: componentType to allow for
changes to the componentType to be propagated back to the implementation but
for the purpose of tooling the platform should be flexible enough to
allow human/tool intervention.
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.
Rgds,
d.
I am still
confused for the following reasons.
- 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.
- 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.
- 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.
Regards,
Dan
"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> |
|
|
To
| "STP Dev list"
<stp-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| 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
- making the service implementations
they produce available to the assembly model (i.e. as componentType)
- allowing change notification and
synchronisations between the service assembly tools and the various
implementations tools it uses.
- providing generic/convenience tools
like a central assembly resources view to help.
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.
rgds,
d.
From: stp-dev-bounces@xxxxxxxxxxx
[mailto:stp-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel
Berg
Sent: 09 May 2006 16:30
To: STP Dev
list
Subject: [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.
Regards,
Dan
_______________________________________________
stp-dev mailing
list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
