Quino has long included support for connecting to an application server instead of connecting directly to databases or other sources. The application server uses the same model as the client and provides modeled services (application-specific) as well as CRUD for non-modeled data interactions. We wrote the first version of the server in 2008. Since then, it's acquired better authentication and authorization capabilities as well as routing and state-handling. We've always based it on the .NET <c>HttpListener</c>. <h>Old and Busted</h> As late as Quino 2.0-beta2 (which we had deployed in production environments already), the server hierarchy looked like screenshot below, pulled from issue <a href="https://secure.encodo.ch/jira/browse/QNO-4927">QNO-4927</a>: <img src="{att_link}2015-11-10_22_53_56-quino_-_microsoft_visual_studio.png" align="none" caption="Server class/interface hierarchy"> This screenshot was captured <i>after</i> a few unneeded interfaces had already been removed. As you can see by the class names, we'd struggled heroically to deal with the complexity that arises when you use inheritance rather than composition. The state-handling was welded onto an authentication-enabled server, and the base machinery for supporting authentication was spread across three hierarchy layers. The hierarchy only hints at composition in its naming: the "Stateful" part of the class name <c>CoreStatefulHttpServerBase<tstate></c> had already been moved to a state provider and a state creator in previous versions. That support is unchanged in the 2.0 version. <h>Implementation Layers</h> We mentioned above that implementation was <iq>spread across three hierarchy layers</iq>. There's nothing wrong with that, in principle. In fact, it's a good idea to encapsulate higher-level patterns in a layer that doesn't introduce too many dependencies and to introduce dependencies in other layers. This allows applications not only to be able to use a common implementation without pulling in unwanted dependencies, but also to profit from the common tests that ensure the components works as advertised. In Quino, the following three layers are present in many components: <ol> <b>Abstract</b>: a basic encapsulation of a pattern with almost no dependencies (generally just <c>Encodo.Core</c>). <b>Standard</b>: a functional implementation of the abstract pattern with dependencies on non-metadata assemblies (e.g. <c>Encodo.Application</c>, <c>Encodo.Connections</c> and so on) <b>Quino</b>: an enhancement of the standard implementation that makes use of metadata to fill in implementation left abstract in the previous layer. Dependencies can include any of the Quino framework assemblies (e.g. <c>Quino.Meta</c>, <c>Quino.Application</c> and so on). </ol> <h>The New Hotness<fn></h> The diagram below shows the new hotness in Quino 2.<fn> <img src="{att_link}server_dependencies_graph.png" href="{att_link}server_dependencies_graph.png" align="none" caption="Quino 2.0 Server Infrastructure" scale="25%"> The hierarchy is now extremely <i>flat</i>. There is an <c>IServer</c> interface and a <c>Server</c> implementation, both generic in <c>TListener</c>, of type <c>IServerListener</c>. The server manages a single instance of an <c>IServerListener</c>. The listener, in turn, has an <c>IHttpServerRequestHandler</c>, the main implementation of which uses an <c>IHttpServerAuthenticator</c>. As mentioned above, the <c>IServerStateProvider</c> is included in this diagram, but is unchanged from Quino 2.0-beta3, except that it is now used by the request handler rather than directly by the server. You can see how the abstract layer is enhanced by an HTTP-specific layer (the <c>Encodo.Server.Http</c> namespace) and the metadata-specific layer is nice encapsulated in three classes in the <c>Quino.Server</c> assembly. <h>Server Components and Flow</h> This type hierarchy has decoupled the main elements of the workflow of handling requests for a server: <ul> The server manages listeners (currently a single listener), created by a listener factory The listener, in turn, dispatches requests to the request handler The request handler uses the route handler to figure out where to direct the request The route handler uses a registry to map requests to response items The request handler asks the state provider for the state for the given request The state provider checks its cache for the state (the default support uses persistent states to cache sessions for a limited time); if not found, it creates a new one Finally, the request handler checks whether the user for the request is authenticated and/or authorized to execute the action and, if so, executes the response items </ul> It is important to note that this behavior is <i>unchanged</i> from the previous version---it's just that now each step is encapsulated in its own component. The components are small and easily replaced, with clear and concise interfaces. Note also that the current implementation of the request handler is for HTTP servers only. Should the need arise, however, it would be relatively easy to abstract away the <c>HttpListener</c> dependency and generalize most of the logic in the request handler for any kind of server, regardless of protocol and networking implementation. Only the request handler is affected by the HTTP dependency, though: authentication, state-provision and listener-management can all be re-used as-is. Also of note is that the only full-fledged implementation is for metadata-based applications. At the bottom of the diagram, you can see the metadata-specific implementations for the route registry, state provider and authenticator. This is reflected in the standard registration in the IOC. These are the service registrations from <c>Encodo.Server</c>: <code> return handler .RegisterSingle<iserversettings,>() .RegisterSingle<iserverlistenerfactory>, HttpServerListenerFactory>() .Register<iserver,>>(); </code> And these are the service registrations from <c>Quino.Server</c>: <code> handler .RegisterSingle<iserverrouteregistry>, StandardMetaServerRouteRegistry>() .RegisterSingle<iserverstateprovider>, MetaPersistentServerStateProvider>() .RegisterSingle<iserverstatecreator>, MetaServerStateCreator>() .RegisterSingle<ihttpserverauthenticator>, MetaHttpServerAuthenticator>() .RegisterSingle<ihttpserverrequesthandler,>>() </code> As you can see, the registration is extremely fine-grained and allows very precise customization as well as easy mocking and testing. <hr> <ft>Any <i>Men in Black</i> fans out there? Tommy Lee Jones was <iq>old and busted</iq> while Will Smith was <iq>the new hotness</iq>? No? Just me? All righty then...</ft> <ft>This diagram brought to you by the diagramming and architecture tools in ReSharper 9.2. Just select the files or assemblies you want to diagram in the Solution Explorer and choose the option to show them in a diagram. You can right-click any type or assembly to show dependent or referenced modules or types. For type diagrams , you can easily control which relationships are to be shown (e.g. I hide aggregations to avoid clutter) and how the elements are to be grouped (e.g. I grouped by namespace to include the boxes in my diagram).</ft>