Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
- 1 STP Deployment Framework Design
- 1.1 Current Design
- 1.2 Problems
- 1.3 Refactor Plan
- 1.3.1 New STP SOAS Extension Points and major Interfaces
- 1.3.2 JAXWS and Tomcat Extensions for packaging
- 1.3.3 JAXWS and Tomcat Extensions for deploy
- 1.3.4 Sequence diagram for creating jaxws war component for tomcat
- 1.3.5 Sequence diagram for deploying cxf war to tomcat server
- 1.3.6 WTP Facet Framework
- 1.3.7 Refactor steps
- 1.4 Advantages
STP Deployment Framework Design
Current STP SOAS Extension Points and major Interfaces
JAXWS and Tomcat Extensions for SOAS
*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...
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
JAXWS and Tomcat Extensions for deploy
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.
<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>
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
*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.