Re: [stp-dev] regarding the SOAS framework...

["Johnson Ma" <johnson.ma@xxxxxxxx>]

Hi Rob,

Besides directly adding action and launch extension, I think another option 
is to reuse the server runtime framework in WTP. That means SOAS 
logical/physical package and package constructor + WTP server runtime 
framework.

I have used the WTP framework to deploy Celtix plugin to Tomcat container 
before. Now i am doing some
experimental work on how to do the same thing using SOAS.
Then we will get better picture of how everything works and what is the 
difference between two frameworks.


Regards

Johnson

----- Original Message ----- 
From: <rcernich@xxxxxxxxxx>
To: "Johnson Ma" <johnson.ma@xxxxxxxx>; "STP Dev list" <stp-dev@xxxxxxxxxxx>
Sent: Wednesday, October 18, 2006 2:09 AM
Subject: Re: [stp-dev] regarding the SOAS framework...


> Hi Johnson,
>
> > Two more points regarding the SOAS framework:
> >
> > 1. One missing feature for SOAS is the interface to control the
> > server runtime, just like the launch interface in WTP server
> runtimeframework.
> There is currently an open BZ entry in the DTP connectivity project for
> this feature.  As an FYI, you could contribute this functionality directly
> by providing the action and a launch extension.
>
>
> > 2. It will be better if the deploy editor is more flexible. I like
> > the way Eclipse plugin editors does. It shows all information about
> > the plugin (Overview, Dependency, Extenstions...etc) in one editor
> > with multi pages. For STP case, hope we can show all information
> > about the current developing component in one editor view,
> > including: webservice, assemble, deploy, sca.module...etc
>
> Agreed.  However, keep in mind, the original purpose of the deployment
> editor was to facilitate the deployment of heterogeneous applications in a
> repeatable manner.  It was not intended as an SCA specific deployment
> editor.
>
> A nice enhancement would be to allow the editor to automatically include
> dependent packages.  It would also be nice if there were a mechanism that
> would allow packages to communicate information between each other within
> some sort of context.  In an SCA context, it would be nice to allow the
> user to wire an external service and have the binding information 
> populated
> automatically based on the deployment of the external service (assuming 
> the
> external service's implementation is also being deployed from the same
> profile).
>
> Thanks for the feedback,
> Rob