Stephen,
That was a great explanation. Thanks.
I found from the Fulcrum website that you are involved in that project also. And I read one of ur emails in the list in which u mentioned that all fulcrum components now run in Merlin.
No all - most.
There are still three components within the fulcrum suite that have not been ported - XML RPC, Security and the workflow composition component. With respect to the XML RPC there is a technical problem related to selectors. In ECM you can make a request for all available services and then select a service based on a particular label. This strategy is not supported under Merlin for two reasons. Firstly, it introduces logic into a component implementation which is tied to a container-side description (which is a problem with respect to atomic component reuse). Secondly, the Avalon specifications in this area of Selectors is insufficient.
Here at Avalon a lot of focus has been applied to finalizing the release of Merlin 3.2.5 (currently under a PMC vote to publish). This release contains some significant improvements to the APIs used to embed Merlin in an application - something that is needed within the Turbine environment. Clearing the 3.2.5 release will mean that real progress on fulcrum/turbine/merlin integration will be possible.
As I mentioned, In the Fulcrum code that I checkout I found the interfaces using roles and there were no avalon tags. I just looked into one component: the "pool" component. So does that mean the component won't run in Merlin ?
I'm assuming your referring to jakarta-turbine-fulcrum/pool. This component has been fully converted. You may have been looking at the API package (most of the component have also been separated with respect to api and impl). The @avalon tags only need to present on the implementation classes.
I basically came to Avalon via Fulcrum and to Fulcrum via Turbine. I understand Merlin in the latest and the greatest.
It's looking good. Version 3.2.5 (under release vote) is solid and functional and includes the new improved embedding strategy and repository management technologies. Version 3.3 (CVS HEAD) is about finalizing APIs at the level of the meta-model and runtime. Version 3.4 brings in a complete code security model and will provide even more flexibility in terms of plugable platform configuration (JMX, JNDI, replaceable subsystems, and potentially an active and adaptive meta-model).
So is the process of convertion of Fulcrum components and services to Merlin under way right now.
Correct. In fact our release schedule is slowing down the guys over on Turbine/Fulcrum - but that should be cleared by the end of next week.
Fulcrum site still mentions ECM but I can assume that its outdated.
Yes.
But Fulcrum components in their present form ( the new ones ) must be compatible to some Avalon standard/pattern. What standard is that ? ECM, Fortress or Merlin ?
Unfortunately not (but chances are that others here will disagree with me on this). ECM was designed more as a helper/utility for component access - and it was for all practical purposes the first cut in this area. A lot things have evolved, in particular the general understanding of component/container separation.
Merlin represents a very concrete effort to eliminate requirements for container awareness by promoting a strict separation of component meta-info, container meta-data, a formal meta-model and an associated runtime. What is coming out of this are standard Avalon utilities and container facilities.
At the Avalon level these include (released or under release vote):
* Avalon Framework - the component support API * Avalon Meta - the component meta-info model * Avalon Utilities - a set of container independent utilities * Avalon Repository - bootstrapping, cache and repository management
At the Merlin the main system include:
* Optional Extension management
* Composition Framework
- meta data specification, api and impl
- meta-model API and impl
* Activation Framework
- model runtime
- composite component management
- deployment facilities
* Merlin Kernel
- facilities management
- application management
- embedding solutions (CLI, servlet, jellyscript, unittest, ..)I want to follow the Avalon container standard ( or whatever u call it ), where Fulcrum has moved or is moving.
http://avalon.apache.org/merlin/starting/index.html
On http://jakarta.apache.org/turbine/fulcrum/changes-report.html, what is meant by the first change in the list, which involves you.
That's a reference to the security, XML RPC and workflow components. Basically the Fulcrum suite is kind of a benchmark for Merlin. Plus some of the things that are planned concerning http integration the Merlin core have the potential to dramatically change the definition of "what is possible" with respect to web-service management. But more on at another time - this post is already too long!
Cheers, Steve.
Thanks a lot for ur help
M
From: Stephen McConnell <[EMAIL PROTECTED]> Reply-To: "Avalon framework users" <[EMAIL PROTECTED]> To: Avalon framework users <[EMAIL PROTECTED]> Subject: Re: Roles and Components in Merlin : another newbie Date: Sat, 17 Jan 2004 02:32:22 +0100
Mathews Julien wrote:
So does having "String ROLE = InterfaceName.class.getName();" doesn't matter.
The notion of ROLE has never been used within Merlin.
And how are roles resolved now in Merlin ?
Forget about the term "role" - think instead in terms "component", "services" and "dependencies. Any component compliant with the Avalon Meta package declares itself as a component by simply including @avalon.component at the class level (in fact that's not even a requirement - but that's another subject).
/** * @avalon.component name="fred" */ public class Fred { }
If the component has a dependency then the component needs to declare this using @avalon tags. Dependencies that are managed my Merlin include all deployment and runtime features that the Avalon Meta Model declares. These include classic service dependencies (accessible via a ServiceManager), context dependencies (accessible via a Context interface, derived context interface, or custom contextualization strategy), not to mention logging, parameterization and configuration dependencies, together with lifecycle stage dependencies.
Here is a simple addition to the above component to include a service dependency:
/** * @avalon.component name="fred" */ public class Fred { private Gizmo m_gizmo;
/** * @avalon.dependency type="Gizmo" key="my-gizmo" */ public void service( ServiceManager manager ) throws ServiceException { m_gizmo = (Gizmo) manager.get( "my-gizmo" ); } }
The key things in the above example - the component is declaring explicitly that it needs a service that conforms to the Gizmo interface contract. Secondly, it is saying that it will lookup that service in the service manager using the key "my-gizmo". From here it is the containers responsibility to establish and associate the component relative to the requested key.
A complete description of the @avalon tags is available here:
http://avalon.apache.org/meta/tools/tags/index.html
The specification of the component type descriptors build from tags which provides binary component portability is defined here:
http://avalon.apache.org/meta/meta/info/type/index.html
An API supporting dynamic component type definition construction is available here:
http://avalon.apache.org/meta/api/index.html
The bottom line is ... if you can describe the contract using the @avalon tags you have source portability across any container that is compliant with the Avalon Meta standard. If you use the tools bundled with the package you can automatically escalate to binary component compatibility.
Finally, Merlin ... actually there isn't much to say. Merlin is based on the Avalon Meta Model, it defines a parallel architecture with respect to meta data management, a comprehensive model-driven architecture, and ultimately - an efficient and reliable runtime platform.
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]
_________________________________________________________________
Learn how to choose, serve, and enjoy wine at Wine @ MSN. http://wine.msn.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | 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]
