I'm working on ${Subject} to come up with an architectural design to cater
aPaaS requirements. At the moment I came up with following ideas it's
better if we can start a discussion here to find best option among them or
new best approach.
(a) Option 1 - Use context-postfix ( like we use context-prefix to handle
webapps belong to tenants)
========================
1. Say user upload a webapp called "mvcapp.war" with version number "2.0"
2. Assume above web app will be copied to "webapps" directory of AS as
"mvcapp__v20.war" ( For the moment let's forget how we create
mvcapp__v20.war file, we have full control on this area)
3. During the deployment it detect file name contains "__v" pattern and
call to handle versioning
4. Finally deployer deploy above mvcapp__v20.war app with "/mvcapp/v20"
context path.
5. Now above app can be accessed using following URL
http://192.168.1.4:9763/mvcapp/v20
Special Notes
--------------------
1. Unlike tenant use cases in above option .WAR file get unpacked during
the deployment but due to suggested modification .WAR file name and
unpacked directory name are not identical.
e.g - .WAR file - "mvcapp__v20.war"
Unpacked directory - "mvcapp#v20" ( We don't have any
control to change this behavior)
Due to this fact during the undeployment unpacked directory will remains
without deleting, but this is not an issue as we can detect the pattern and
can delete unpacked directory through the undeployment.
2. After deployment app's Context URL will remains constant we can't
dynamically change it. Here it's not possible to change default version of
the app just using Tomcat or AS through Admin UI.
e.g -
http://192.168.1.4:9763/mvcapp/v10
http://192.168.1.4:9763/mvcapp/v10
http://192.168.1.4:9763/mvcapp/v30
In order to change default version time to time we need to have
URL-Rewriting component ( within ELB ? ) in front of AS. URL-Rewriting
component should handle followings.
* It can receive messages (cluster messages ?) from AS when the default
version of app get changed.
* Based on current default version it should able to redirect incoming
messages to correct app version on AS.
* If it's a required feature, it should hide actual context URL on AS from
users and have to always requite URL like mod_rewrite do .
(b) Option 2 - Add Proxy or adapter to existing ProtocolHandlers
========================
This idea is to wrap or create proxies for existing Tomcat ProtocolHandlers
so that we can intercept messages before send to actual ProtocolHandlers
but this seems not straightforwards thing without losing major performance
level. When receiving a message Tomcat directly deal with Java Socket and
and when finding a URL of a message it act on byte level processing hence
it hard to intercept in this area while keeping same level of performance.
Tomcat use a class called "Mapper" to dispatch incoming messages to correct
Context but we don't have any point to intercept until this mapping
happened. AFAIK Valves get hit after context matching happened so we can't
use them here.
One alternative is to write and maintenance our own set of ProtocolHandlers
but this is not straightforward as it sounds and really complex task to
keep same performance level.
(c) Option 3 - Customize Tomcat's Mapper Class
===================================
Complexity wise this is not hard and we can cater all our aPaaS
requirements in once place but the cost is we have to fork Tomcat locally
and maintain, upgrading according to Apache released versions is the
biggest challenge in long run and generally not a good idea.
Among above 3 options personally I prefer options-1 as it less complex and
less effect to current Tomcat and AS architectures and I already having
working prototype. Also any way the prosed URL-
Rewrite component is useful to ELB.
Comments ?
Thanks !
--
Sagara Gunathunga
Senior Technical Lead; WSO2, Inc.; http://wso2.com
V.P Apache Web Services; http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ; http://ssagara.blogspot.com
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
