Hi,
Thanks for the comments. I realise that what I am pointing out is not
straight forward, but I think I do have some insight in how to achieve
it. If I am really honest the current object orientated paradigm is
flawed and this flaw propagates to all software based on certain
principles espoused, ideally we want to be modelling the relationships
between objects as opposed the objects themselves, then infer a given
objects properties from its relationships, something that cannot be said
of the inverse....but this is a little too deep. That type of thinking
however has allowed me to look at the problem slightly differently.
Briefly, the framework I have been developing is aimed at users that
require sophisticated combinations of services and features but have low
levels of traffic. A typical user would be a small business professional
with one physical machine hosted 24/7 that provides a 'virtual office'
with website and email server, software components will share common
business objects and all the usual. These professionals may recruit the
services of various technical skills sets
(artists,designers,developers,etc) from time to time who will need
access to the things they are responsible for. This means my focus is
on manageability and integration instead of scalable capacity at
present, but I hope to move to that in the future. My framework is not a
lot different to other frameworks in principle but there are subtleties
which distinguish it from others. Also, the terminology I have used to
represent certain concepts is generally more descriptive of what it
actually does in comparison to others, this makes it easy to understand
for both new and more experienced users. Although I am happy with what I
have so far the thing stopping me from finishing it is the component
model. For instance, my framework could actually support James, but not
in the way I would like. I am loath to start working on something when
there are other frameworks that already do it very well. I have been
influenced by a few other frameworks with Avalon being probably my first
exposure to the idea of a framework many years ago. I guess I am at a
critical design juncture and the perspective of others will be useful at
present.
Anyway, I think it is generally fair to say that James is a component,
composed of components that are composed of components and so on.
Components generally have a life cycle and have relationships with other
components. And that last bit is important, a component has
relationships with other components. Usually, when initialising a
component, a framework will be responsible for supplying other
components that the component being initialised requires to operate. At
a very low level, we take an object and put other objects inside of it.
This is what needs to change (conceptually at least). Another way to
look at it is that when we initialise a component, we do not pass it the
other components it requires to operate, instead we pass in a set of
relationships. This is very like the idea of an interface but slightly
different.
That is a bit abstract so I will use the terminology from my design. In
my framework, every component is a 'micro virtual machine' and
applications/components are networks of these machines. When a component
is initialised it is passed a network, or collection of network cards if
you like, that represent the components the component being initialised
requires to operate. This means the usual parent/child relationship
between components exists but is virtual instead of real. Now, when a
given component calls the method of a sub-component (virtually a child,
but really a peer) it is actually sending a message to another component
(method calls here are paths/expressions....). This now gives the
framework an opportunity to intercept the before and after of the call
and evaluate its properties for monitoring, applying security measures
or other such things. This interception can be very fine grained and is
completely transparent. In this way all components communicate in a
uniform fashion and permit the emergence of self-organising systems (or
if that's too much, having the ability to drop a component into a system
and have it adopt the policies of the system without configuration(in
principle)).
I haven't touched too much on implementation details because they are a
few consequences of this design (which I think are great, but may not
sit well with other programming habits). If you can really grasp what I
am saying it is actually moving towards what I said right at the
beginning, i.e. focusing a bit more on the relationships of objects
rather than just the objects themselves. Object orientated paradigms are
good for describing objects in abstract space, but are insufficient for
describing the effects of time because the effects of time are inherited
from the system within which an instance of the object manifests.
That is a summary of my approach and as you can probably tell it
requires a very specific method of component design hence questioning
its immediate practicality. That said, I still think it is worth solving
the problem because its already halved solved and the benefits are
obvious. I will leave it here to get some feed back, I do have more to
say on the subject.
On a side note, if there is anything specific about the documentation
you would like looking at, I can take a look and see if I can help. As I
am using James at the moment so its operation is personally more
important than its development (in that my current position requires
it). In this way, if I can improve the documentation, this in turn will
improve the user base and I will benefit from the impact of a broader
community.
I hope you find this is of interest and look forward to any suggestions.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
