Re: [stp-dev] Suggestion on undeploy support in SOAS (bug162516)

[rcernich@xxxxxxxxxx]

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.


> 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.

Thanks for diving into this.  Please let me know if you have any questions
regarding either the connection profile or deployment frameworks.

Best regards,
Rob