Everyone interested in this technology should also check out the Rio project @ rio.jini.org.
Chad -------Original Message------- From: Stephen McConnell <[EMAIL PROTECTED]> Sent: 11/14/02 10:19 AM To: Avalon Developers List <[EMAIL PROTECTED]> Subject: Re: Avalon Containers and Clustering > Kasper Nielsen wrote: >Hi, > > > >For a research project in distributed value-oriented storage facilities for >xml I need (unless everything fails) a container that supports stuff like >auto-discovery of other container, cluster-wide deployment of code, state >transfer from one container to another, failover, and other common features >found in distributed systems. > > An area of common interest! on auto-discovery The Merlin container model provides support the publication of services established by the component it is managing. I'm using this feature internally with a variety of container specializations that basically handle service publication using a number of different policies - mainly request based discovery in which the client is supplying service URL which is resolved by the container implementation (the sort of thing needed to support ECM style solutions) On a more ambisouse level, I've been worked on a specification for general service registration and discovery that handles the exchange of information between peers. http://www.osm.net/technical/lib/osm-rd.pdf I'm also working on distributed containers - not finished yet - but when I have something working ok I'll commit it. The main issues here are that the host container cannot assume that it is in control of all of the services it is managing and things into the picture distributed notification of service provider state. Thats a little more complicated but well within the spectrum of workable and achievable. The main criteria is to make this very clean, simple to use, and automatically resolvable. >I'm going to use javagroups with a transfer neutral layer on top, and I >would probably prefer creating something that is as container-neutral as >possible, i.e. for use in both phoenix + merlin/fortress > At the moment the Phoneix meta model contains more limited type model. The difference being that Phoenix does not currently support the lifecycle extension concepts that exist in both Merlin and Fortress. Addition of these to Phoenix is not at all not difficult - in fact I'd be really interested to hear from others involved in Phoenix development as to intest in this feature and possible work to include this. For now, if lifecycle extensions are a requirement (which generally speaking is not the case), the only approach is to run your compoents inside a merlin or fortress running inside Phoenix. I'm not sure what the status is concerning Fortress but I can confirm that Merlin runs perfectly inside the Phoenix environment. Assuming that lifecyle extensions are not an issue, you will need to include meta descriptions for Phoenix and for excalibur/meta - i.e. the .xinfo files. Both Phoenix and Merlin use .xinfo files but their respective DTDs are different. For Merlin this is all handled by the excalibur/meta package which includes support for the phoenix meta descriptors. To handle the conflict in naming, the excalibur/meta package also allows the a .xtype descriptor whcih is basically the same as the .xinfo but with a differnet name. This means you can include Phoenix style meta in a .xinfo and excalibur/meta (Merlin/Fortress) in a .xtype. This ensures that your component will run without problem across Merlin and Phoenix and later in Fortress. > > >Could anybody give me an overview of what kind of changes is needed to >archive this, does eob support any of this? > > Can't help you with EOB - perhaps Paul can anser that one. Aside from that - don't hesitate to post addition questions, suggests, etc. Its very much an area I'm interested in. Cheers, Steve. > >- Kasper > > >--------- >Kasper Nielsen >Norrebrogade 110A, 1.tv. >DK-2200 Copenhagen N, Denmark > >IT University of Copenhagen >E-mail: [EMAIL PROTECTED] > >--------- > > > > > > >-- >To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> >For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org> > > > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
