On Fri, Jul 12, 2013 at 6:06 AM, Kishanthan Thangarajah <[email protected] > wrote:
> Hi Sagara, > > > On Thu, Jul 11, 2013 at 2:43 AM, Sagara Gunathunga <[email protected]>wrote: > >> >> 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 >> > > > For option-1 above, instead of bringing our own way of app versioning, > can't we use the same approach that tomcat follows [1] ? > > The following table is copied from the tomcat doc page for reference. > > Context Path Context VersionContext Name Base File NameExample File Names > (.xml, .war & directory) /foo*None* /foofoo foo.xml, foo.war, foo/foo/bar > *None*/foo/bar foo#barfoo#bar.xml, foo#bar.war, foo#bar *Empty String** > None* *Empty String*ROOT ROOT.xml, ROOT.war, ROOT/foo 42/foo##42 > foo##42foo##42.xml, > foo##42.war, foo##42 /foo/bar42 /foo/bar##42foo#bar##42 foo#bar##42.xml, > foo#bar##42.war, foo#bar##42 *Empty String*42 ##42ROOT##42 ROOT##42.xml, > ROOT##42.war, ROOT##42 > So here is how the versioning works in tomcat. > > The context name, context path and base file name are closely related. > "##" is used to add the version and "#" is used to add another context to > the path. > > As a given example above, foo##42.war will have /foo as the context path > and 42 as the version. In here, if there are one or more version of the > same app, the latest version takes precedence and the requests gets > dispatched to that. > > "#" can be added to have hierarchical context value for the app. > It seems I discover the same thing but in reverse order :) if we have above support that's more than enough to handle our use cases in fact I used "__v" instead of "#". > > So why don't we follow the same approach as above? > > Also I have some questions related to $subject. > 1. Do we need to have all the version of a particular app deployed at all > time? > It's up to the user, if user want to run all of them we should facilitate. > 2. Is there a requirement to distinguish the version of a app in the URL > like http://192.168.1.4:9763/mvcapp/v20 ? > It's just how i came up with my initial design but we can go according to above table. Thanks ! > > Thanks, > Kishanthan. > [1] http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming > >> >> 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 >> >> > > > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com* > Twitter - *http://twitter.com/kishanthan* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
