Kasper Nielsen wrote:
Hi,An area of common interest!
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.
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.
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.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
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.
Can't help you with EOB - perhaps Paul can anser that one.
Could anybody give me an overview of what kind of changes is needed to
archive this, does eob support any of this?
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>
