You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by J Aaron Farr <fa...@apache.org> on 2004/01/17 22:10:51 UTC
[RT] A Bright (and Radical) Future for Avalon
Definitely a Random Thought:
http://www.jadetower.org/muses/archives/000019.html
Feedback is welcome.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] A Bright (and Radical) Future for Avalon
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
From: http://www.jadetower.org/muses/archives/000019.html
> So this is my first proposal (and perhaps the most radical): Break up
> the Avalon Framework. Let's take our own medicine and seperate
> concerns. Seperate lifecycles into an avalon-lifecycle framework.
> Create a generic way to support user defined lifecycles and perhaps
> include a standard set of lifecycles used by and fully supported by
> all official Avalon containers.
>
> Seperate out the service package into a true IoC framework which
> focuses on dependency resolution. Provide support for all sorts of
> IoC types. But focus on just this one issue.
+1, this is very much aligned with my own vision of what A5
should be about
> So, is Avalon about the Framework or is it about a Container?
> (Yes, there are other options, but I'm trying to build an
> arguement here. :) ). I know that there are some Avaloners who
> feel strongly about unifying all efforts behind the standard of
> one true Container. In that case, (here comes another radical
> idea), perhaps what we need to consider is putting Merlin on
> the roadmap for becoming it's own top level project. Or perhaps
> we need a place for just framework development. But I am
> concerned that as soon as we tie to two too closely together,
> the power of the framework will be lost in the implementation of
> the container.
Avalon isn't about the Framework or a Container. Instead, from our
charter, Avalon is about community concerned with the development and
publication of open-source software dealing with component and service
management.
From this assertion there are a few things that are worth pushing onto
the table - the most central point is that we are a product focused
community. Within this context the principal of "one product"
introduced a set of very health social dynamics. It forces community
cohesion. If you don't like something you have to do something about it
within the context of a single product framework - and the procedures at
Apache facilitate collaborative and radically approaches to this. The
key and socially binding principal is that these procedures ensure that
there is only ever one product.
In the document you described the Holly Grail as "a single container
which is truly generic". The solution is as much about community as it
is about technology. We have some issues to deal with here at Avalon
with respect to multiple product branches - and resolution will not be
easy to achieve - but finding the Holly Grail has never been a walk in
the park.
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] A Bright (and Radical) Future for Avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 17 January 2004 15:45, Leo Simons wrote:
> IMHO, it should be about delivering on the promise of reuse, even making
> it rather difficult *not* to reuse. The Framework|Container split is so
> useful because it allows (in theory; the practice so far has been quite
> ugly) to keep the framework intact while replacing the container, and
> still being able to use all the components.
YES, the Promise is there, but IMHO, the A-F is too weak.
> In our ever-changing development world, we currently have "components"
> using type-0, type-1, type-1.1, type-2, type-3, type-4, type-n IoC,
> components that aren't IoC at all, javabeans, enterprise beans, eob
> beans, corba components, soap services, RPC and XML-RPC services,
> mbeans, singletons, static factories, and others.
> Jicarilla is about making (potentially) all of these components work
> together. And about me being stubborn, ignorant, and arrogant :D
You will need a lot of good luck!!!
Most of the components listed above doesn't even work between two different
implementations of the same type of framework.
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] A Bright (and Radical) Future for Avalon
Posted by Leo Simons <le...@apache.org>.
J Aaron Farr wrote:
> Definitely a Random Thought:
>
> http://www.jadetower.org/muses/archives/000019.html
>
> Feedback is welcome.
Good essay, nice read. (I don't know how to pronounce it. Never tried so
far :D)
"The exciting part of IoC and COP development is not in lifecycles, it's
in dependency resolution."
Actually, the way I see it...IoC == top-down dependency resolution.
But COP includes other cornerstones...lifecycle management,
configuration management, service discovery. In many applications, you
need each of those (the A-F lifecycle is arguably too granular, we don't
have much in the way of service discovery, and A-F configuration
management remains an absolute gem, the only thing is looking like it'll
be a viable competitor is XStream).
COP also seems to be about "packaging", but I think that sucks. IMNSHO
there should be a shared standard for packaging that is used for
packaging non-COP things as well (@see .Net).
"Break up the Avalon Framework"
Something PeterD once said that I always remembered: Seperation of
Concerns and Fragmentation of Concerns are one and the same. The
Framework API is already quite small. It can be easily rolled into a
single package, and it will still be small (@see DNA). Sure, let's
seperate concerns, but haven't we already? The fact that we have a
single distributable that does several things is pure pragmatism. An
avalon-framework-dependency-resolution-api.jar would be just 3
interfaces and 2 exceptions. That's a bit small :D
"is Avalon about the Framework or is it about a Container?"
It's currently about both. It has also always been about designing and
redesigning the balance in the relationship between the two every few
months.
IMHO, it should be about delivering on the promise of reuse, even making
it rather difficult *not* to reuse. The Framework|Container split is so
useful because it allows (in theory; the practice so far has been quite
ugly) to keep the framework intact while replacing the container, and
still being able to use all the components.
In our ever-changing development world, we currently have "components"
using type-0, type-1, type-1.1, type-2, type-3, type-4, type-n IoC,
components that aren't IoC at all, javabeans, enterprise beans, eob
beans, corba components, soap services, RPC and XML-RPC services,
mbeans, singletons, static factories, and others.
Jicarilla is about making (potentially) all of these components work
together. And about me being stubborn, ignorant, and arrogant :D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] A Bright (and Radical) Future for Avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 17 January 2004 14:05, J Aaron Farr wrote:
> Yep. But the important thing is to maintain separation of concerns.
> Lifecycles are separate from Service Dependency. Service Discovery and
> Availability are probably close enough to be solved in a single
> framework, but Service Dependency is probably a separate issue from
> these. Meta data (or Service Description) is a seperate issue too.
Are we looking at these;
* Service Discovery
* Service Availability and Lookup
* Service Description
* Service Dependency Resolution
* Service Life Cycle
* Service Environment (Context)
I would like to view these from the perspective of Jini for a second.
Service Discovery and Join
====================
Service Discovery a Service needs to announce its presence. They do that via
multicase IP communication.
Then the Service will Join the Federation. That means that it registers itself
with one or many Lookup Services that it finds during the Discovery phase.
Service Availability and Lookup
=======================
Availability and Lookup is a "client-perspective" operation. You need a
service, you can either look it up straight away (just like with
ServiceManager in Avalon) or create what they call a LookupCache. That means
that the Lookup Service, will notify when a service fulfilling the lookup
template (a kind of filter) joins.
Through the LookupCache, the rest of the application can register itself as
listeners to know when things comes and goes.
Service Description
==============
Jini has generic attributes for the services. Not only can they "tell story"
about the service, such as name, type, location, serial number, expiration
date, and so on, but also they are searchable.
So when I do the lookup, either direct or via the LookupCache, I can specify
that only services that has a particular attribute set to some value will be
returned/notified.
Service Dependency
===============
Jini doesn't have this notion at all. Why not?
Typically, the deployer will receive some form of feedback that "Service Abc"
is not running and looking closer, it will show that it is because the
"Service Def" is not present on the network. Then he/she starts "Service Def"
and things continues.
Service Life Cycle
=============
Jini services has an vague life cycle, not really well articulated, but it
seems that it is not needed, probably because the nature of "things comes and
goes" very much at any point.
* Service construction.
* When a Lookup Service is found, register yourself there.
* When a Service available notification is received, enable the parts in the
application that depends on it.
* When a Service not-available notifcation is received, disable those parts.
* If a service call fail, disable those parts, and make a new lookup in the
Lookup Service.
and so on...
Service Environment
===============
Again Jini doesn't provide any environment or context other than what is
provided by other services, such as Lookup Service or the JavaSpaces Service.
What can we learn?
1. There are many ways to handle the same thing, and the Avalon way is far
from the only, nor the "right" way to do it.
2. None of the listed sub-systems are probably a "requirement", i.e. should be
a choice, even Dependency which at first looks very much needed.
3. Components would need to be able to declare which system *contracts* are
required in the container to operate properly.
4. Should Context really be a "native" concept? (I can make an argument why
not separately if interest exists).
I hope you enjoyed this elaboration.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] A Bright (and Radical) Future for Avalon
Posted by J Aaron Farr <fa...@apache.org>.
On Sat, 2004-01-17 at 16:46, Niclas Hedhman wrote:
> On Saturday 17 January 2004 13:10, J Aaron Farr wrote:
> > Definitely a Random Thought:
> > http://www.jadetower.org/muses/archives/000019.html
> > Feedback is welcome.
>
> I enjoyed reading it, as it reflects a fair bit of my own thoughts;
>
> 1. There are MANY aspects of framework construction.
> 2. There could potentially be ANY number of container implementations.
> 3. All container variations should not be part of our ambition, just like all
> components should not be part of our ambition.
>
> Although I like Merlin very much, as it is in-line with my current thought
> process, I realize that not everyone find it as amazing as I do.
> As in the article, I don't know if Merlin will be capable to be "cut up" in
> smaller pieces that can be assembled in arbitrary constellations to suit
> different needs. It would be great.
>
> But I DO believe that Avalon Framework needs some form of Playground
> Container, where new ideas can be tested, and I DO believe that we need a
> collection of "high quality", "low level" Reference Components, serving both
> the need of functionality as well as education (easy to forget).
Education is easy to forget about. One thing that has been suggested
form time to time is an Avalon super-distribution or set of
super-distos. Something that really shows off Avalon and one or more
containers and has a bunch of components already wired and ready to go.
Sort of an Avalon Application Server.
> Reagrding the evolution fo Avalon Framework itself, and the identification
> that Dependency is very different from LifeCycle is a much harder nut to
> crack. I would like to throw in a 3rd, almost forgotten, same-level issue;
> Service Availability. And then of course, Meta-info about the components.
Yep. But the important thing is to maintain separation of concerns.
Lifecycles are separate from Service Dependency. Service Discovery and
Availability are probably close enough to be solved in a single
framework, but Service Dependency is probably a separate issue from
these. Meta data (or Service Description) is a seperate issue too.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] A Bright (and Radical) Future for Avalon
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 17 January 2004 13:10, J Aaron Farr wrote:
> Definitely a Random Thought:
> http://www.jadetower.org/muses/archives/000019.html
> Feedback is welcome.
I enjoyed reading it, as it reflects a fair bit of my own thoughts;
1. There are MANY aspects of framework construction.
2. There could potentially be ANY number of container implementations.
3. All container variations should not be part of our ambition, just like all
components should not be part of our ambition.
Although I like Merlin very much, as it is in-line with my current thought
process, I realize that not everyone find it as amazing as I do.
As in the article, I don't know if Merlin will be capable to be "cut up" in
smaller pieces that can be assembled in arbitrary constellations to suit
different needs. It would be great.
But I DO believe that Avalon Framework needs some form of Playground
Container, where new ideas can be tested, and I DO believe that we need a
collection of "high quality", "low level" Reference Components, serving both
the need of functionality as well as education (easy to forget).
I think we can spur innovation by separating "Playground Container" from
"Production Container", and saying that the "Playground Container" will not
graduate, but features may make its way into the Production Container.
Reagrding the evolution fo Avalon Framework itself, and the identification
that Dependency is very different from LifeCycle is a much harder nut to
crack. I would like to throw in a 3rd, almost forgotten, same-level issue;
Service Availability. And then of course, Meta-info about the components.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org