Gary Shea wrote:
At this stage the relationship between a container and a TypeManager is undefined. If you follow the structure of the Merlin system - then yes, one container, one type manager etc. However, I envisage the potential for a container to manage multiple type managers - maybe one for internal services, another for contained compoents, and maybe another for published components. Whatever - the pricipal is that its a manager of a set of types (class + metainfo).Hi Steve -- I'm looking at the excalibur.assembly code now. This is probably just going to be a sort of "opinion dump". I will try to preface each opinion with my interpretation of what's going on, so you can tell what's based on fact and what's just lost in space ;) Since I'm spewing, I'd suggest read everything first before responding. Since I tend to look at the stuff I don't like and ignore the rest, let me preface all this by saying that this is great stuff and I appreciate your ongoing efforts to make it architecturally cleaner. Bravo! Here we go... .type: This seems to be the infrastructure for maintaining a collection of Type objects. I'm guessing that each container will have a single TypeManager object where the Type information is maintained for components handled in that container (but in no parent container).
As I read the code I see a lot of inheritance from Service goodies,
some of which show evidence of originally being the Type stuff,
then hacked.
Yep - cleaning up of docs from cut-and-paste is still pending. :-)
Have been thinking about the same thing. Bottom line there is no dramtic or fundimental reason to have this as inheritance based. In fact I've been reworking TypeManager locally to turn it into a component. This follows the thinking in my post about bootstrap versus pluggable components that provide core services. If the pluggable things are always full components, then there is no reason why one should not allow an alternative TypeManager (or XxxxManager) component.Is this inheritance for re-use or inheritance that really 'means something', i.e., IS-A? I've heard a number of Java folks say something to the effect that one should "never use inheritance unless you will 1) instantiate the inherited object, and 2) in some cases use the inheriting object in place of the inherited object". Inheritance for re-use creates (IMHO) tight webs of dependency and makes code hard to understand.
For the moment I suggest maintaining the inheritance approach while I turn things into conponents and then look at this again in a few days.
Yep - javadoc is incorrect. This is simply a convinience operation to create a new type without having to know about how the type is constructed. The static methods do not register anything.DefaultTypeManager.createType() is static but the javadoc refers to it as 'registering' something. Details... looks like it really just creates a Type object?
Umm - would it be ok if I answered "it's just you"?
Is it just me or is it weird that Type, which describes Services (as
well as coomponents in general, yes?) also classloads the Class
objects for the services? I would somehow expect that to be part of
the _interpretation_ of the Type data, and hence at a different
level.
;-)
There is a distinct difference between Type and Service. Imagine for example a jar file container the service org.omg.CosTime.TimeService. The TimeService interface is described by a class and a Service is the meta info about the service. This service can exist indepedently of an componet implemetation class (i.e. the service interface and meta defintion can exist in a seperate jar from a component the provides the service). On the other hand, types can declare that they provide services - which basically means that a type manager when registering types in its repository needs to be able to access/register services from a service manager.
A catalog of services (indepedently of the ability of a system to provide solutions or implemetations).service This is a somewhat similar critter to Type. Each component has the ability to declare the service(s?) it provides. Again we're dealing with a catalog of metadata about the component.
No. Related but not subset. A Type declares services that it provides via 0..n ServiceDescriptors. A ServiceDescriptor referrences a Service. When you get into characterising a service verus characterising "the provision of a service", you end up seperating attributes between a service defintion and the declarion of service provisioning.
This appears to be a subset of Type data?
Is there some reason forTwo main reasons:
this, for instance is this where Service selection takes place if
multiple components provide the same service?
1. physical seperation of service defintion from type
2. ability to have multiple service versions that coexist across different classloaders
If you are wanting Type to present a ServiceManager view, so Type isI have the same feeling ( a liitle "forced"). Inital objective was to sketch out interfaces and throw in a default implemetation. These things need to be worked up but I really wanted to put something out there for discussion as opposed to comming up with something perfect.
a kind of facade combining itself with ServiceManager (which is just
another view of Type! eek!) wouldn't it be more flexible to delegate
to a ServiceManager rather than inherit from it? Might express the
design better too. The whole construct feels a bit forced, but I
think I can see where you're headed...
DefaultServiceManager.installService(): shouldn't this be
addService(String)? I don't see what it installs?
Fixed - thanks.
So far we have some facilities for accessing metadata. In general they
are isolated from where the metadata is used... yay!
.profile:
In practice the kernel.xml 'profile' aggregates and 'completes'
information about a bunch of Types, so as I start reading this code
I don't know yet if a Profile will be about one component or a
collection of them.
A profile is about deployment scanario. name + type + configuration + context + logging setup, etc.
What's fairly clear is that, at the individualA Profile has a 1-1 relationship with a Type. A Type may be referenced my many Profiles. For example - take class X (the type) and using congiuration A is represented as deployment Profile P1. Taking class x (the type) and using configuration B is represented as deployment profile P2. The profiles simply represent potential solutions for establishment of a particular appliance. Thet do not represent deployed solutions - its just the collection of information on which deployment (via an appliace) can be made.
component level, we start at the 'bottom' with Type meta-information
and then compose in more concrete information.
It occurs to me that calling the file a 'profile' and calling the
result of composing a Type with a 'profile' file a Profile is a
possible point of confusion.
Ok, with some review I see that a Profile applies to one component.:-(
The terminology is definitely confusing.
More javadoc?
Something that makes it clear the a Profile is "the named collection of information for the potential deployment of a specific componet type".
The Profile seems to be the result of pulling together all meta and
concrete data about a component, yes?
Yes.
So by piling the Profile stuff on top of the Type/Service stuff, we
are able to ask the same questions as before, but now the answers
are in some sense complete, all information known about deploying
the component has been assembled into one box, the Profile.
Yes.
Which is not yet complete - what's missing is accessors on the Appliace interface for the service the a client needs (and generally speaking the client is the implimentation of a framework ServiceManager or ComponentManager.
That's enough for now. Gimme some feedback and when my brain recovers
from all this exercise I'll go dig around in .appliance.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
