Difference between revisions of "Cotrix configuration and deployment scenarios"
(→Separation of Concerns) |
(→GWT for VocBench, Cotrix and Vox) |
||
Line 32: | Line 32: | ||
=GWT for VocBench, Cotrix and Vox= | =GWT for VocBench, Cotrix and Vox= | ||
− | ''The above | + | ''The above scenario numbers are not linked to the below design decision option numbers.'' |
In order to make the above deployment scenarios possible, a design decision is needed. These are the options: | In order to make the above deployment scenarios possible, a design decision is needed. These are the options: | ||
Line 95: | Line 95: | ||
'''Decision''' | '''Decision''' | ||
In the meeting of 05 December 2012 Erik has proposed to follow option 1. No decision has yet been taken. | In the meeting of 05 December 2012 Erik has proposed to follow option 1. No decision has yet been taken. | ||
− | |||
=Separation of Concerns= | =Separation of Concerns= |
Revision as of 17:48, 5 December 2012
TODO, include also the scenario's for local publication channels and external publication channels.
Deployment scenarios for Cotrix and VocBench
Scenario | Cotrix | VocBench | Description |
1 | * | The instance contains only VocBench functionality | |
2 | * | The instance contains only Cotrix functionality | |
3 | * | * | The instance has both the VocBench and Cotrix functions |
GWT for VocBench, Cotrix and Vox
The above scenario numbers are not linked to the below design decision option numbers.
In order to make the above deployment scenarios possible, a design decision is needed. These are the options:
Option | VocBench gwt client | VocBench services | Cotrix gwt client | Cotrix services | Vox gwt client | Vox services |
1 | war + jar | jar | war + jar | jar | jar | jar |
2 | jar | jar | jar | jar | war | NA |
3 | war | NA | war | NA | jar | jar |
In GWT you can choose to develop a client or an application. In order to make a an application for VocBench or Cotrix, you alway need at a certain point a GWT application, e.g. a war file. The GWT application will be written in Java and generated in JavaScript.
The services which are needed by the client are Java and will not be generated in JavaScipt. The services can be native GWT services or REST services.
Option 1 foresees a scenario where VocBench and Cotrix have both an application layer. The notion of Vox completely reflected in jars.
Pros: All deployment scenarios are possible. Projects are more decoupled.
Cons: More work to setup.
Option 2 foresees a scenario where only Vox has the application layer. The notion of VocBench and Cotrix are reflected in jars.
Pros: All deployment scenarios are possible.
Cons: Projects are less decoupled.
Option 3 foresees a scenario where VocBench and Cotrix have both an application layer. The services are not reflected in jars but in the respective wars. The notion of Vox completely reflected in jars.
Pros:
Cons: Not all deployment scenarios are possible.
Decision
In the meeting of 05 December 2012 Erik has proposed to follow option 1. No decision has yet been taken.
Separation of Concerns
Vox is primarily the container for horizontal functions. Over time, generic vertical functions of Cotrix and VocBench can be promoted to Vox.
Cotrix standalone and in the iMarine infrastructure
Scenario |
iMarine front-end |
standalone front-end |
Backend: proprietary persistence (embedded/external) |
Backend: iMarine persistence layer |
iMarine virtual platform | Description |
1 | * | * | No iMarine integration here | |||
2 | * | * | Cotrix fronted can be anywhere, using iMarine persistence services. Cotrix is a iMarine client. | |||
3 | |
* | * | * | Cotrix is deployed in the iMarine virtual platform, bringing its own persistence services. | |
4 | |
* | * | * | Cotrix is deployed in the iMarine virtual platform, using iMarine persistence services. | |
5 | * | * | Cotrix frontend is a gCube portlet, using Cotrix persistence solutions. Is this possible? | |||
6 | * | |
* | Cotrix frontend is a gCube portlet, using iMarine persistence services. | ||
|
|
|
||||
|
|
|
|
|
|
|