RE: [stp-dev] Service Creation questions

[Daniel Berg <danberg@xxxxxxxxxx>]

• 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
  <dcb>The introspection framework accommodates the inverse as well (changed in the impl back to the componentType).  In this
  situation we do not dictate how the implementation integration detects its changes (we can't).  But we do provide a mechanism that
  makes it simple for the implementation owner to compute a new componentType (either completely or partially) and we take care
  of merging the changes as a single unit back to the "live" copy of the componentType that the tool is operating upon.
  
  Having a builder to control this is the wrong approach.  Builders are often misused in Eclipse and in this case the changes to the impl would only take place after a build runs.  The
  other problem with the builder is that you can only react to resource changes and you cannot be assured what changed in the implementation resource.  Not only that you don't know
  what file(s) from the implementation to react.  It is best to leave the reaction of the implementation changes to the implementation owner but provide (as we do) a simple way to recompute
  the componentType definition (either entirely or incrementally).  Within core we provide this mechanism which provides a simple mechanism for implementation owners to merge componentType changes
  back into the "live" componentType.</dcb>
• 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.
  <dcb>We have incorporated event notification at the componentType model level.  This means that however the componentType model element is changed the notification will be propagated back to the implementation extension.  If a componentType "file" actually exists (which is rare) the user can modify it and these changes should propagate back to the "live" componentType.  Note that it is the responsibility of the implementation extension to merge a componentType file with the implementation itself.  So this falls back onto the implementation owner to detect the change to either its implementation or the componentType file (that it created) and propagate the changes back to the "live" componentType using the mechanism we have in place.</dcb>
  
  
  Can you provide concrete requirements of the SC subproject.  Everything you have mentioned so far is either supported in core already or it is just hand waving with no clear descriptions.
  I'm not trying to be a pain here but if I am confused about the intentions and goals of the subproject I think most of our clients will be as well.
   
  Regards,
  Dan
  
  
  
  
  
  "Beaurpere, David" <David.Beaurpere@xxxxxxxx>
  Sent by: stp-dev-bounces@xxxxxxxxxxx

  05/12/2006 06:48 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

  
  
  
  
  
  
  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.
   
   
   
   
  
  

  ---

  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.
  
  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
  _______________________________________________
  stp-dev mailing list
  stp-dev@xxxxxxxxxxx
  https://dev.eclipse.org/mailman/listinfo/stp-dev