Multi Site Components and Containers

Topics: CAB & Smart Client Software Factory
Jul 10, 2005 at 7:10 AM
originally posted by: eilert

The design of the component model in CAB enables components and containers to be sited, through the 'Site' property, on each other. Thus allowing one to compose a hierachy of containers, which then can access services on the same or upper level in the hierarchy. (Services can be promoted to a higher level if neccessary thus making them available to containers higher up). (At the moment only one container can be sited on another one.)
However some services need to be accessed by multiple containers and or components, but these need not be related, thus need not be sited on each other. One could add the same service to each container, thus duplicating them, which is probably not what we want.

If on the other hand components and containers can have multiple 'Sites' one can design a base container with base services and components and then site multiple other containers on the base.

This design also allows to flatten the hierarchy, thus making shorter branches.
Jul 11, 2005 at 6:40 PM
originally posted by: EdJez

I think I understand what your are saying. Right now in CAB is done in such a way that it's hard to make an object locatable/sitable in more than one container (and especially if the object is a component). We are using the service container as a service locator - merging it with with component containers brings in the restriction that a component can only have one site. In a sense, that service location (finding the right object references in a given "context" or "environment") should be orthogonal to the fact that components might have a relationship to a site - and a container- that is unique because it owns its lifetime.

The perfect example for me when thinking about this is workspaces. Workspaces can be shared (should be findable) across many workitems, but lifetime of it is managed by one workitem only. Since workitems are components, adding them as a named item in a child workitem will make it be "sited" in this child, showcasing the limitation you mention.

I'm sure Peter and Kzu will have lots of opinions as well on this.

The behavior right now is obviously derived from our component model backbone. Changing this would imply departing and/or adding other semantics besides the current ComponentModel ones. What would you think about that?
Jul 12, 2005 at 2:39 AM
originally posted by: FrancoisTanguay

I totally agree that service lifetime and service reference should be managed separately. I alread reached those limits while trying to share service instances.. something similar to workspaces.

One easy solution could be to overload CompositeServiceContainer.AddService(Type, object) with AddService(Type, object, bool).

Boolean flag could be something like "ownService" or "siteService". It would indicate whether the service instance should be owned and sited on the container or whether it should only be referenced through the services dictionary.

see CompositeServiceContainer.AddServiceInternal.
Jul 13, 2005 at 8:50 PM
originally posted by: eilert

A central service locater were you could register your services would be a nice component to have. One could also implement a component locater, for components which need to be more widly available, eg. components which implement cross cutting aspects.

Both the service and component locater schould have similar behavior as the event broker. They schould be available locally or globally. You might want to add an extra level of behavior, were all three above are available to the root container, which might not be the top most container, and all containers below it.