Niclas Hedhman wrote:
On Thursday 11 March 2004 00:09, Niclas Hedhman wrote:
On Wednesday 10 March 2004 22:37, Berin Loritsch wrote:
I am all in favor of *controlled* contracts. They provide a reasonable foundation to build with, and yet still alow for some amount of flexibility. No-one on this list has ever advocated complete hippy free-bird approach to development. I don't think that has ever been a question.
Are you suggesting that the 4 (out of 4 possible) different lookup
semantics of ServiceManager is a desirable result of 'flexibility'? If so,
we are on different trains, and will end up at different destinations...
Since I believe you will answer "No, that was not intended", you may answer the question "So, how did we (even if I was not around, I still consider it a community thingy) end up with it?" You were around and must have observed it happening... And I can for no reason have a clue how it was allowed...
Easy answer is that at that time there was no community, much less consensus
on it. Before, it was wide open and anything could map to anything, with no
control. There were big conversations to help make it more reasonable in
respects to looking up services. At that time, the concensus is what was
written in the DWA paper. Based on the tools available at that time, the
choice of looking up a service based on the interface name was a natural and
simple solution.
The above is totally understandable with respect to the specification of an implementation - although I have grave doubts about the approach of using a tutorial document as the grounds for a product specification. If fact I would go further and say that using a tutorial document is basically equivalent to not doing the specification.
The problem came in as we evolved the container code based on these assumptions.
ECM made it a bit easier to use the guidelines by adding some semantics to them that the ECM would handle automatically (in hindsight, it was too much magic).
Lets' drop the "too much magic". In hindsight it was a fork of the common interoperability specification. But wait - there was never a common interoperabily specification - just the spec on a set of artifacts - contract without semantics. In hindsight the problem was the absence of an interoperability specification.
Meanwhile, as time went on, Phoenix experimented with attributes tagged in the source code. Since Phoenix was able to provide assurances without the need for selectors or mapping interface names to lookup values it evolved along those lines. Now Merlin actively discourages mapping lookup values to interface FQCNs.
Not completely correct.
Merlin simply documents the specification by requiring the component to declare explicitly its assumptions concerning the supplied key. This only difference - the completion of the contract by both parties so that there are no ambiguities.
Fortress came on the scene to help with the transition from needing
interface names for lookup values and selectors, but still supported it due to the need for using existing components.
That is the nutshell view of how we got where we are. Fortress sits between ECM and Phoenix, and Merlin is somewhere past Phoenix.
Here is another view.
Phoenix made very significant progress in actually dealing with the question of the full contract. Merlin went further and filled in a bunch of additional details not addressed in Phoenix, Fortress or ECM concerning the complete contract.
But what Merlin does is not end-game. Its just an example of doing things more completely. There is a lot more that we need to do to provide a complete interoperability specification. And in reality it such a specification must deal with evolution of the specification itself.
In a sense, we went from a stronger contract to a weaker one on the key names.
We went from an vague contract to an explicit contract.
Was this bad? No, because the overall contracts were made stronger due to the meta information.
Forget about meta - the contract was better because the information was actually provided as opposed to implied.
A perfect example of what I view to be a bad contract is the Meta package in the avalon module.
*sigh*
It is unnecessarily strict in that any user of the package must supply any of the myriad of undocumented contracts that Merlin has with it.
Either you don't understand the content of Avalon Meta or, your attempting to provide misleading information. There are no myriad of contracts.
The Avalon Meta package defines the following:
* an immutable descriptor of a component type that declares
a service dependencies, context requirements, logging requirements,
configuration requirements, parameterization requirements, stage
dependencies, and service and extension capability* an API that provides simply and convenient access to this information
* a set of builders and writers that provide support for the
internalization and externalization of this information * a collection of tools to make the process of generating the
information trivial and totally automatedFrom this - and before you reply with you standard line, just present your concrete technical arguments about what you think should change - and as you do this, reflect on what is working well - and the requirements for maintaining a released platform that is working really well - taking into consideration real constraints.
The contract is with the XML data format, the serialized format, etc. The
information is not stored with the class itself. A better contract is one where we supply the code for the attributes, but use something less restrictive in how to set up and use like Commons Attributes.
This is an implementation detail this is "academic". The important thing that your missing is that there is a object model (the Type) that provides the complete declaration. There is also an XML form that is needed when we are dealing with "real-world" problems that "real-world" clients are addressing.
You can still provide the Attribute classes to provide strong contracts,> but you are not locked into only using the meta information
defined by the meta package. Since you are into tools, there are some meta data that would help tools out but not really be useful at runtime.
Sooner of later (or perhaps not at all) your going to figure out that interoperability is *not* about implementation - its about contract, sufficiency and clarity of information, and formats for the exchange of that information. It's not about how you go about implementing the model. Would Avalon Meta be easer to deal with in JDK 1.5 sure - but its totally academic - we are supporting users on JDK 1.3. Are that improvements we can make to the package - sure - I got a big list - but that big list will not break the principal of:
* a complete specification of the requirements of
the component type
* backward compatibilityDo you want to really go to the mat with Stephen to add that meta data definition to the Meta package?
If anyone want to go to the mat with Stephen they should really come to grips with the difference between meta-info (an object model specified and implemented under the Avalon Meta package) as opposed to meta-data (an object model specified and implementation as part of the Avalon Composition package). And if they really want to take me out - they should have a good idea of how meta-data combined with meta-info establishes the context for the creation of a manageable and sustainable meta model.
Are your ready?
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
