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
