Guys, Thanks for a the detailed update. I think recent developments got some of us concerned about Avalon's future but things seem to be still in good hands. :) Pawel
-----Original Message----- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 12:21 PM To: Avalon framework users Subject: Re: Discovering current Avalon direction Pawel Karendys wrote: > Could anyone at Avalon (developers and/or users) update the > rest of us with more information on what the current > direction is? Sure - see notes in-line (my personal take on the what is happening and where we are going). > Most likely many of us would be interested in > knowing: > > 1) Which containers are positively being deprecated? ECM Fortress Phoenix > 2) What is the current offering for stand-alone and web > (or EJB container) embedded applications? Merlin. A dozen lines of code and your up and running. Basically you create an InitialContext, supply an application address, set any specific params you want, then request a kernel instance. From here you have access to the component model which means you can add component models and containers, control assembly, selectively deploy things, remove components, redeploy components, etc. There is an example in cvs - avalon/merlin/platform/tutorials/main See README.txt for build and execution details. > Probably, it would be nice to have one container with its > configuration determining how light-weight one wants to "travel"? What Merlin provides today is a core containment model. That model allows you to customize a containment solution using "facilities". Facilities are simply regular components with privileged access to the containment model (which means they see other component models and general interact with model in a passive or active fashion). The notion of facilities is really important because it introduces a very powerful mechanism through which you can take control of a container personality. Combine this with support for cascading containment and you have lots of scope within which you can craft new solutions. That being said - there is still work to be done on the security side at two levels. Firstly, work on security permission profile association with a component needs to be integrated with classic Java code-base security under the activation runtime. Secondly, we need to put in place security policies at the repository level (which ties in with the classic code-security model). > 3) A general summary of where we're going with this project would also > help. Way way back in really early days of Avalon - the project focused on the development of what is know as the framework - basically a light-weight API that mainly focused on establishing good patterns for COP based development. From this point work was undertaken on a component handler utility called ECM that was largely related to the Cocoon project. At about the same time the Phoenix project was initiated - aiming to be a app-server. The two projects evolved into two separate communities, different users, and different assumptions concerning the framework semantics (which really come down to two things - push versus pull semantics, and developer centric versus business oriented). Merlin is resolving these differences (which is largely the cause of a degree of current community shake-up). |--------------------------------------------| | pull-based | pull-based | | developer centric | enterprise-centric | | (ECM/Fortress) | ^ | | | | (via facilities | | | discovery services, | | | selection, http facility, | | | etc.) | |-------------------------------|------------| | | | | | push-based | push-based | | developer centric | enterprise-centric | | <----------- (via repo) | | | | | | Merlin | | | | |--------------------------------------------| Simply put - the Avalon community took a vote to go for a single container, single architecture, single specification. This has ramifications as it is forcing consolidation within the community and termination of a number of competing projects. CVS activity is currently all focused on cleaning up content that prior to retirement. This means a lot of effort going into things like Excalibur build procedures, getting Excalibur, ECM and Fortress in to a maintainable condition, ensuring gump integration builds are ok - basically setting the stage for a definitively final release of content while ensuring the any projects or users that want to continue with legacy code can do so by taking the code elsewhere. End result of the process will be a scaled down Avalon - focused on one container, one architecture, one specification. But that is only the consolidation story. Beyond this there is strategy concerning the direction that Avalon is heading that I and several others here in Avalon share. This strategy can be summarized in two words "Avalon Planet". But this needs a little explanation. Looking around in the COP world - you have a dozens of experimental initiatives, a number of small technology focused communities, and last but not least - the Avalon community. Unlike the rest - Avalon is an Apache project and a community with a long history is this domain. Unlike the others - the Avalon Planet initiative aims to escalate COP potential by delivering the tools and technologies that will enable distributed component and service publication, mediation, and brokerage. Avalon is morphing - one reference container, a set of core utilities, a number of standard business facilities, and the products to enable anyone to become a component and/or service publisher. Underlying this strategy is the principal of network-effect ... "how do we (Avalon devs) turn you (Avalon users) into valued solution and service providers within a global services network". We can do this by building strong specifications (see Niclas email), rigorous implementations (refer Merlin and its development path), combined with smart back-office technologies (think avalon-repository, service registration, discovery, brokerage, collaborative service management, and adaptive security). Cheers, Stephen. > Everyone, thanks for your hard work, > > Pawel > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
