avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] container extensions
Date Thu, 26 Jun 2003 20:16:18 GMT
Farr, Aaron wrote:

>>-----Original Message-----> 
>>What kind of extensions are we talking about?  From your doc, I can see
>>* Management Extensions
>>* Directory Extensions
>>* Container Components
>>Management extensions would include certain things like JMX support and
>>Instrumentation support.
>>Directory extensions would include JNDI integration, context value
>>customization, etc.
>>Container Components include privileged code that runs in the container
>>space.  Perhaps a shutdown component, or something else along those lines.
> Sounds good to me.
>>Is there anything else?
> Probably.
> Specifically I've been thinking about SOAP and JMS.  For example, in JMS you
> have a MessageListener interface which provides an onMessage(Message msg)
> method.  If an Avalon service were able to tell a JMS-enabled container what
> JMS destination it wants to listen to, the container could take care of
> subscribing it to the destination.  In the end you get an Avalon version of
> Message Driven Beans.

Hmm.  SOAP, AltRMI, RMI, etc. are all remoting protocols.  We should make this
as plugable as possible and as invisible to the user as we can.

JMS is a messaging service, which can be analogous to an event based system.
Whether it is using JMS or some other application, we need to provide some
mechanism for it.

> This can pretty much be done using Lifecycle extensions now (I'm almost done
> with one version) but would be significantly easier if the extensions could
> get a hold of assembly attributes for the component which could convey the
> JMS destination information.

:)  Understood.  Extensions should probably be formally made into priviledged
components (i.e. container-space components) which should have the additional
access to component meta info and assembly info.

> Same holds for (Alt)RMI exporting of objects.  I suppose these all fall into
> the "Directory Extensions" you mention.

(Alt)RMI is a remoting tool.  Directory Extensions are more for JNDI

> More random thoughts:
> One way I've been looking at it is to try to figure out the basic roles or
> lifecycles of a container (this is not a perfect list):
> - Establish Runtime Environment (Context)
> - Assemble Components
> - Provide Resources/Bundles
> - Handle Lifecycle
> - Handle Component Access (Lookups)
> - Handle Component decommissioning
> and so on.


> Next is to determine which of these are valid for extension.  Perhaps all
> are.  Perhaps only certain ones make sense.  I'm still in the "thinking
> about it" stage on this one.  However, off the top of my head, here are some
> other container extensions which might be interesting:

Let's focus on one use case at a time.  Let's start by trying to solve one
problem, and then we can move to the next.  By the time we are done, we will
have the best set of interfaces/etc.

> - Clustering and Failover

Ambitious aren't we?  This means we need a better security model...
We don't want someone to force us to fail over to an unauthorized
backup do we?

> - Transparent Remote Service Lookup (looking up services across VMs)

Yep.  That's the (Alt)RMI connection there.

> - Resource loading/downloading (Downloading from Maven or JNLP repository)

Again, security model improvements are needed.  Signing of JARs, etc.

> - Hot deploy of services

We might want to start here...  Again security model applies.

> - Support for JINI or Javaspaces

Licensing!  It's not easy working with patent enabled technologies.

> It's also a question of which of these could be implemented as normal
> services under Avalon 4 and which would require new capabilities.  Not
> saying I have all the answers, but I certainly have a bunch of questions.
> :)

If you ask the right questions, you just might get an answer you like. :)


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message