CSFramework & CSContainer Thoughts...

[Chris Geer <cg...@comcast.net>]

I was just thinking through how the framework and a container based on
Fortress would port over to C# and had some things I wanted to throw out
there for thought. Mind you, I'm not an Avalon expert by any means so bare
with me.

Fortress (and Merlin) is built with the concept of a hierarchical container.
This is a wonderful concept that allows for a lot of flexibility within the
container and the components within it. This concept seems to be built
around how Java's hierarchical class loaders (hopefully I'm not sticking my
foot in my mouth here), giving each container (potentially) its own class
loader and a degree on independence from its peers. A similar concept is
used in J2EE containers with Web Applications for example; where each Web
App can have its own class loader (actually has to have its own). 

While this concept works well for Java based applications it doesn't quite
port as well to C# and .NET because there is no concept of a class loader.
Instead, when you need a type (analogous to a Java class), the DLL where
that type is defined is loaded globally within the application domain (an
application domain is essentially a light-weight process). Once it is loaded
it is the one that is used until the app domain exits. There is no means to
unload a DLL, which would make it hard to "hot-redeploy" applications
(components) since once it was loaded, a newer version could not be loaded
(at lease not without affecting the entire app domain, if it could be at
all).

One possible solution to this would be to load each application into its own
app domain. This would allow each application its own DLL suite to be
loaded, however, no DLLs could be shared between any two, and they would
each have to have their own copies. The major downside of this approach is
it would make it more difficult to share information between applications
since all communications would have to be remote communications. In the web
app example, this would mean all session data would have to be accessed
remotely (there would have to be a master (I was going to say root, however
there is no hierarchy in app domains) node everyone had access to) and every
application that wanted to use that data would have to have access to the
DLL the type came from (same name and version). 

These were just a few things I was thinking about for this port, but they
are based on the concept I have of being able to deploy different groups of
components as "applications/services" where each application could have its
own semi-isolated environment. 

Another topic I was thinking about was management and security. For
management Microsoft is pushing their WMI service which is their proprietary
version of the DMI's WBEM initiative. The reason I say its proprietary is
because the majority of the schema they use is not part of the standard and
their communications mechanism is DCOM and not HTTP like the spec says it
should be. While WMI does have the benefit of being integrated into the
Windows OS it has some serious limitations when used from C# such as no
cross DLL inheritance of management objects and no support for updatable
properties or callable methods. I suspect these two issues will be fixed in
.NET 2.0 but I haven't heard when that is supposed to arrive. Also, if this
container is going to support Mono, I'm not sure how they are handling the
WMI infrastructure. I wasn't sure what the approach for this would be so I'm
curious what people are thinking. I'd be interested to see if there was a
way to do a scaled down JMX port. As for security, there are quite a few
issues there and I'm getting tired of this email so I'll put those off until
later. 

As I mentioned in the beginning, I'm still pretty new to Avalon but am
trying to learn it quickly. I am also very interested in a C# version of the
framework and a container and would love to hear people's opinions/thoughts
on what they would like to see and ideas of how to do it.

Chris Geer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org