Detailed project descritpion

WDAB was created as a proof-of-concept project to invesigate a possibility of implementing load-balanced location-transparent services on top of WCF.

Bird's eye view of the architecture

The access to all WDAB functions is provided via a statefull facade class (Services). Below the facade lies the runtime (RuntimeBase derived class). Runtime is tied to specific environment configuration and when this configuration changes, runtime instance is disposed and a brand new instance is created according to new config.

Runtime by itself doesn't provide any real functionality. It serves as a container for modules (IModule) and service controllers (IServiceController). Modules manage and provide service controllers to the runtime. Service controllers are abstractions of communication channels; they purpose is to provide client-side proxies to services they 'control'.

Location transparency is achieved through service controllers because they hide communication details. Thre can be local service controllers as well as remote service controllers.

Runtimes, modules and service controllers

These are the components od WDAB. They were created to structure WDAB code according to well-known object-oriented desing rules. They weren't present in the first, prototype, version of WDAB; Although they aren't directly exposed to client code, their role is priceless. You can read more about them here.

From request to response

The prefered way of using WDAB is though Communicate methods. There methods accept a delegate which can be executed against service proxy. Client supplies this delagate (probably using lambda expression). Then, WDA internals creates a client-side proxy. This proxy can have multiple layers, but only 2 are manadatory and are created by runtime: WCF channel and (lying on top of it) reconfiguration lock proxy. The latter is responsible for preventing reconfiguration when services are being invoked. The former packages requests and sends them on the wire. It is replaced with null proxy if service implementation is located in the same host.

On server side request is unpackaged by WCF runtime and transfered to servant-side proxy layer. Currenlty the only WDAB-provided proxy there is the one responsible for maintaining service statistics for load balancing capabilities. In future, however, (release 0.8) there will be also a proxy for management support. After all the proxies do their work, a servant instance is created or retrieved and it's method is called to generate the response.

Internals of WDAB

From the very first day, WDAB implementation was based on Unity container. The container provided means for communication between solution components. Since that time the role of Unity container in WDAB was growing with every refactoring and implementation phase. Currently there are five container instances used in WDAB runtime, each has its own vell-defined purpose:
  • So-called external container is used to provide configuration to WDAB runtime. It should contain mappings of WDAB extension-point interfacase to concrete classes. This container is not owned by WDAB runtime and is only used during start-up.
  • Persistent internal container is used to coordinate configuration update procedure in which WDAB runtime reloads itself using new version of configuration data
  • Internal container is used as main communication device in WDAB runtime
  • Stub container is used to store client-side proxies
  • Servant container* is used to store service implementations
The last two mentioned containers can be configured using standard configuration file. Runtime assumes that you define Unity configuration section named unity and containers named stubContainer and servantContainer. By using this feature you can, obviously, register types, but main purpose of it is setting up interception.

Last edited Dec 14, 2008 at 3:03 PM by SzymonPobiega, version 6


No comments yet.