Ideas using CAB Infrastructure Part 1

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

The CAB makes use of the folowing

Inversion of Control:
Principals:
(a) Classes schould be concerned with their own properties, methods etc.
(b) When classes need to obtain data or run methods on other classes, they schould only use these, without concerning themeselves with the lifecycle, ie. instantitiation etc. and other concerns of the other classes. Something else schould do this. Typically this is done through the use of services.

Eg. Instead of this inside our class:
Form myform = new Form();
string myName = myForm.Name;

we would do this:
string myName = GetService<Form>.Name;
//(the generic version of ‘GetService’ in CAB),

were we rely on a service to instantiate our ‘Form’.

Composibility of the ComponentModel in .Net framework:
The ComponentModel is designed for composibility of components, services and containers, which get sited on each other using the ‘Site’ property and obtain services using the ‘GetService’ method.
Using this, one is able to get a hierarchy of containers, services and components.
This one of the underrated and underused aspects of .Net (together with I would say ‘Attributes’) by .Net programers.

The CAB infrastructure builds on the above to build composibile smart clients.
It also has a ‘ComponentAdapter’, which wraps any objects with the ‘IComponent’ interface, thus making them siteable on the containers.

However a lot of this infrastructure can be used outside of smart clients.
Using this infrastructure one can design simplified classes, relying on the containers and services to supply other aspects of class interaction.

continued in thread Part 2......... (only 3500 characters can be used)
Jul 2, 2005 at 10:07 AM
originally posted by: eilert

Part 2
........see Part 1 for Introduction

Ideas what I want to through in for debate, are the following:

1. Use service agents to act on behalve of your classes making them act like services.
These agents wrap the class’s properties, methods etc., but more importantly can map these to similar ones in other classes.

The ‘Agent’ class would look like this:
public class Agent<T> : ComponentAdapter
{
public Agent<T>()
: base(T)
{
}
}

where T is the class which the agent acts upon. The default constructor would create a new instance of the class. With some other overload that ensure that an instance of the class already exists and maybe another one which checks if it already exists, otherwise it will create it.

To access the ‘Agent’ you would do something like this:

string myName = GetService<Agent<Form>>.Name;

We would also need a mapping class similar like the ‘Agent’ class:
public class Map<T> : ComponentAdapter
{
public Map<T>()
: base(T)
{
}

public MethodInfo MapMethod (string methodToMap);
{
.
.
.
}


and in the ‘Agent’ class we would have something like this:

MethodInfo svc = GetService<Map<T>>.MapMethod(methodToMap);

The method to map can be obtained from configuration files or a ‘MapAttribute’ in the new mapping class. The same for properties etc.

Your class which uses the ‘Agent’ does not known or care whether you act on the methods or properties of the class you think you are using or those supplied from an other class.
There maybe some security issues with this, which need to be investigated.

Now we only have to get rid of the 'GetService' syntax. We might possibly do this by extending the ‘My’ features of Visual Basic 2005 by extending them with ’Service’ and ‘Agent’ so that the syntax would be similar like this:

With My.Service.Agent
myName as String = Form.Name
.
.
End With

(By the way C# users can also have access to these features by referencing the VisualBasic library, since the ‘My’ features are in reality managed classes)

....... continue in Part 3 (only 3500 characters)
Jul 3, 2005 at 12:09 AM
originally posted by: eilert

......continued from Part 2 (only 3500 characters can be used)

2. LifeCycle service(s):
I don’t know what the performance and memory pressure of the CAB is, but I can imagine that they are substantial. I propose that we add some LifeCycle services to the existing ones in ths CAB.
I am thinking of services like:
Speculative creation and intialization of containers and or services to prepare them for siting and instantiating of components, like the ‘Agents’ above and their classes;

Activation and suspension of individual components, services and whole containers;

Cacheing of these;

Attaching and detaching of these;

3. Security service(s):
Container isolation services can also be added, so that only certain services and components can access these.
Supply EndPoint portals for containers so that they can only be accessed by other services through messages. Services like WebServices. This might be a future release in the Indigo timeframe.

4. Configuration services:
Automatic runtime configuration of containers, services and components a la ‘FabriQ’ of Clemens Vasters and Avindra Sehmi.

5. Cacheing service(s)
eg. You might want to use this when you do service or component discovery in the various containers and then cache the discovered ones for later access.