SOAS Refactor

STP Deployment Framework Design

Current Design

Current STP SOAS Extension Points and major Interfaces

The diagram below shows all extension points and major interfaces defined in stp soas. Interface (class) with blue border are extension points (extensions)

JAXWS and Tomcat Extensions for SOAS

The diagram below shows how we extend soas to support creating CXF War and deploy to Tomcat Container

Problems

*Missing runtime in the model.
 Should be modeled as Server + Runtime. Thus we can tell the difference between Tomcat Server + CXF runtime and Tomcat Server + Asix2 runtime.
*Can't see the status once deployed
 Once the war is deployed, there is no way see its status. Need to fully integrated with wtp server framework. Then user can query/start/stop/remove component from wtp server's module view
*Workspace based deployment

The current approach is based on individual project. It should be changed to allow user to select multiple services across workspace, thus they can deploy soa network in one step.

*Using connection profile is odd here. Since it was originally designed to model database connection.
*Package Constructor only has technology info. Can't directly create war package for Spring and Tomcat containers from this extension.

Should add server and runtime information to the package constructor as well

*Shouldn't ask user to select server to create the deployable package. 

This is wrong. should be changed to only ask for server type. (since the logical package already have tech and runtime information)

*Need to define logical package builder.
which will build the logical pacakge before call physical package constructor's createPackage() operation. During this building process, stp user can hook customized function. such as apply policy...

Refactor Plan

Some major changes:

*use wtp server framework instead of connection profile
*add runtime information to logical package, physical package, and package constructor

New STP SOAS Extension Points and major Interfaces

Below are the new architecture. connection profile, techType, serverType has been replaced with relative definitions from WTP. And also added runtime type to support server + runtime model.

JAXWS and Tomcat Extensions for packaging

Sequence diagram for creating jaxws war component for tomcat

Sequence diagram for deploying cxf war to tomcat server

WTP Facet Framework

We will use the Facet Framework from wtp to identify technology and version for each project. The jax-ws nature on project is not enough. since we do need version information as well. The follow extension will define jaxws2.0 facet.

<extension point="org.eclipse.wst.common.project.facet.core.facets">

 <project-facet id="jaxws">
   <label>JAX-WS</label>
   <description>
     JAX-WS development
   </description>
 </project-facet>
 <project-facet-version facet="jaxws" version="2.0">
     <constraint>
     <requires facet="jst.java" version="5.0"/> 
   </constraint>
  </project-facet-version>

</extension>

Refactor steps

We want to keep the refactor as smooth as possile, although we will change all extensions points and code everywhere. The refactor process has been separated as following steps to ensure the packaging and deployment functions won't break during refactor:

*WTP Server Module Factory, which will convert physical package to WTP Module 
*Change Connection Profile calls to use wtp servers instead
*Modify Server Definition and Technology Definition usage, use wtp server type and module Type extensions instead
*Add runtime definition and supportedRuntime extension point
*Add runtime information to logical package, physical package and package constructor.
*Add Jax-Ws Facet and runtime information to project during service creation
*Add logical package builder
*Final cut: remove Connection Profile, Server Definition, Technology Definition. and Deploy Driver extension points

Advantages

*package based deployment approach, without tie to project
*create deployable package based on server type, instead of server instance. Thus users can create package without server, and manually deploy to remote server.
*deployment profile editor. which allows users to deploy multiple components onto multiple servers at the same file.