Hi Bram, I think in general this approach would be good solution, the question is if we can provide reasonable solutions for the concerns and challenges you already raised yourself.
The most important concern I think is 'abandoning' the Http service OSGi specification/implementing our own. Currently we indeed already depend on some additional functionality supported by the Felix http service but not covered by the OSGi spec, which is support for servlet filters. But since this is done whiteboard style, there is no direct dependency between the filter and the felix http service. Theoretically, you can mix servlet registration whiteboard style and by invoking the http service immediately, but since servlets registered whiteboard style run in a different servlet context then those registered directly with the http service, this may already lead to issues (as I found out in Shindig). Not supporting direct method invocations of Http service is at least questionable. A related concern is how to deal with the http context. We started Amdatu some time ago with sharing one httpcontext with all bundles. However, since Pax Web doesn't support this (each OSGi bundle should have its own httpcontext) we refactored this to the mechanism still used today; one http context per OSGi bundle. With Felix we should be able to share one httpcontext with all bundles, but I found this is not true for the whiteboard pattern bundle; the felix HttpContextManager assumes that bundle that registers the filter is the same bundle as the one that registered the httpcontext to which the filter is bound (the bundleid is appended to the id that is supposed to identify the httpcontext). Some stuff to think about is to provide a http context per tenant. Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: woensdag 19 januari 2011 10:46 To: amdatu-developers at amdatu.org Subject: [Amdatu-developers] Tenant resolving and dispatching Hi list, would like to hear your opinion on the following general approach to the web (tenant)resolver/dispatcher. In this design I assume we want to be able to support multiple instances (eg. per tenant) of a servlet at the same logical path (eg /hello/world) and therefore standard HttpService will not do, we need to keep our own registration and dispatch. Eg. simple use case ***** Using a simple hostname to tenantid resolver strategy ******** ***** http://tenanta.com/hello/world => filter1 => filter5 => servlet target at /hello/world with svc registration property tenant_id=tenanta ***** http://tenantb.com/hello/world => filter3 => servlet target at /hello/world with svc registration property tenant_id=tenantb ************ Approach: 0) We replace Felix HTTP Whiteboard with "Amdatu Web Resolver". This component tracks servlet/filter/httpcontext services just like whiteboard, but does not register them directly with the HttpService. Instead this Component manages registry and lifecycle of these web component (init/destroy) just like the HttpService (but see notes 2) would. 1) We register an InterceptorFilter with the HttpService. This filter intercepts all (maybe with pluggale exceptions) requests and redirects them to a Processor that is responsible for mapping incomming requests the their eventual targets based on Amdatu knowledge. 2) The Processor has a whiteboard mechanism that supports a pluggable (whiteboard) interceptor chain (think FilterChain alike) to plugin and run within the request scope. This rather generic mechanism provides the most flexibility for current and future challenges Eg. -> Security / QoS / whatever interceptors -> TenantResolverInterceptor maps hostname to tenantid -> TenantFilterChainInterceptor maps tenantid to filters and builds the FilterChain -> ServletTargetInterceptor maps tenantid to a a Servlet -> DefaultTargetInterceptor maps to legacy / fallbacks / whatever 3) At the end of the Processor chain the request is forwarded to the selected recources simply by direct method invocation (no need/room for dispatching as the virtual path does not change?). We are done!(?) Concerns: a) Constraint is that all web component MUST be registered whiteboard style unless we allow/support exceptions for nono-tenant aware components. This may prove not always to be the case with 3rd party software like the Felix Webconsole. How should we deal with this? b) To support filters we (already) use the The Felix ExtHttpService but as we used whiteboard this did not imply coupling to it. Just the Filter interface. I this approach however we will tightly couple the dispatcher implementation to the Felix implementation. It also look like embedding Felix base/whiteboard code may reduce the loc we need to write ourselfs as we can reuse some wrapper objects. c) The dispatcher can not freely access HttpService ServletContext adminitration. Instead we (re)use the one provided to us through the InterceptorFilter and wrapping it. Is this a valid approach in terms of spec? ServletContext javadoc says: "In a server that supports the concept of multiple hosts (and even virtual hosts), the context must be at least as unique as the host. Servlet engines may also provide context objects that are unique to a group of servlets and which is tied to a specific portion of the URL path namespace of the host. This grouping may be administratively assigned or defined by deployment information." However at this point it seems that HttpService wraps every HttpContext is a unique ServletContext and is not even looking at hostnames. Any spec experts here? d) I am not yet clear on resources and how there are used now. Any thought and/or cautions? e) Future extensions could mostly fit into the interceptor model allthough more close management of the thread 'given' to the 'untrusted' web component may be interesting at some point. Nevermind... stuuf for later. Your comments please! Regards Bram _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
