[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stp-dev] Suggestion on undeploy support in SOAS (bug162516)
|
Hi Rob,
Please see my comments inline
Thanks
Johnson
----- Original Message -----
Sent: Friday, November 03, 2006 1:45
AM
Subject: Re: [stp-dev] Suggestion on undeploy
support in SOAS (bug162516)
> Hey Johnson,
>
>> I have some
draft idea on how to support undeploy function in SOAS:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=162516>>
>> 1. Connection related changes
>>
First, we need to enhance the connection profile to list those
>>
deployed service component.
>> Such as define the new connection
interface used in SOAS as following:
>
> I agree with having a
common set of interfaces for interacting with service
>
containers.
>
>
>> public interface
org.eclipse.stp.soas.deploy.core.IServerConnection
>> extends
IConnection {
>> public
IServiceController getServiceController();
>> }
>>
>>
public interface org.eclipse.stp.soas.deploy.core.IServiceController()
{
>> public
Collection<ServiceComponent> listServices() throws
>>
ServerException;
>> public boolean
isServiceExists(String serviceName) throws
>>
ServerException;
>> public IStatus
start(String serviceName) throws
ServerException;
>> public IStatus
stop(String serviceName) throws
ServerException;
>> public IStatus
undeploy(String serviceName) throws ServerException;
>> }
>
> I don't think we need to extend IConnection. IConnection is
simply a
> wrapper for a connection object. Its purpose is to simply
give clients a
> stripped down set of connection type methods in the event
they get a
> connection that they are unfamiliar with (i.e. so they can
close the
> connection). I also don't think we need "deploy.core" in
the package name,
> since, presumably, these APIs are not specific to
deployment.
>
> I would recommend defining a set of interfaces that
can be used to
> represent the contents of a service container. At
the root should be a
> "connection" object. This object would be
returned by the
> IConnection.getRawConnection() method. This will
decouple the service
> container connection interfaces from the connection
profile APIs (meaning
> you could still use these outside of the
connection profile framework; e.g.
> for a simple command-line
utility).
>
> Other tooling components within STP can then key
their functionality to
> specific connection profiles by looking for
profile implementing an
> IServiceController connection factory. For
example, we could contribute a
> basic content extension to the DSE for
all profiles implementing an
> IServiceController factory.
Agree, we can use the
getRowConnection to get the serivce continer connection, then
invoke the IServiceController
interface to interact with container.
For the package name, maybe it is
time to define a org.eclipse.stp.soas.server package for those factories.
Even we can consider to move the current IServerType and
ITechnologyType stuff to the new package.
>
>
>> 2.
ServiceComponent.
>> Once we integrated with the STP core model in the
near future, we
>> can use org.eclipse.stp.core.sca.Component direclty
in the
>> deploy/undeploy scenario. But for the time being, let's
define a
>> simple component logic for SOAS to use
only.
>>
>> public class
org.eclipse.stp.soas.deploy.core.ServiceComponent{
>>
>>
public String getName(); //this name is linked with
>>
IPackageOutputDescriptor::LogicalName
>>
public Properties getProperties(); //Those properties should
>> get
from server runtime. we can show them later.
>>
}
>>
>> We can use the ServiceComponent.name to identify the
deployed
>> service. This name is linked with
IPackageOutputDescriptor::LogicalName
>
> Sounds good to
me.
>
>
>> 3 IDeploySession::unDeploy
>> Need to
add unDeploy function to deploy driver as following:
>> public
interface IDeploySession {
>> IStatus
unDeploy(IPackageOutputDescriptor descriptor) throws
>
Exception;
>> ...
>> }
>
>
Seems reasonable.
>
>
>> In deploy driver, we can get
IServiceContoller from
>> IServerConnection, then call
IServiceContoller.undeploy according to
>> the
IPackageOutputDescriptor::LogicalName.
>>
>>
>> 4
UnDeploy action from GUI.
>> The current deploy scenario for Tomcat is:
selecting a war file from
>> workspace, then right click the
'Deploy...' menu. It will popup a
>> dialog to ask user to select one
target server.
>> I think the undeploy scenario could be: selecting a
war file from
>> workspace, then right click 'Undeploy...' menu. It
will popup a
>> dialog to list all servers, which has this component
deployed. User
>> select one or more target server, clicks OK to
undeploy.
>
> I think this requires a bit more thought from a
technical perspective.
> Perhaps it would be better to associate the
undeploy action with a specific
> object in the servers view (the data
source explorer, although we need to
> consider either renaming this view
or creating a specialized view for
> service containers). For
example, enable undeploy for any IPackage objects
> in the view.
Implementations could specify adapter factories for their
> specific
package objects. In STP, we could create a generic adapterFactory
>
extension for the new ServiceComponent object.
It is good if we can reuse/extend the
current data source explorer. In that view, we can use
the ServiceController I/F to get list
of ServiceComponent. And allow user to provide
their adapter for render the returned
object.
However, i think it is more
convenient if we can also provide one-click undeploy by selecting the assembled
service component from project/package explorer.
One missing contact point
between SC and SOAS is the association between STP project and SOAS server
types. I am thinking about
when user create a new STP project, he need to specify the server type (and technology type too?), such as
create a JAW-WS project or SCA project. Then we will save the server type (and
technology type?) into the project properties.
During deployment, we are asking user
to select target server runtime instanaces. This information can also be saved
into the project properties. Thus we can support one-click deploy/undeploy
based on those information .
