[...] > That part of Avalon is fairly straight forward to understand and implement by > yourself outside the robust Merlin platform.
well, i think i'll manage it ;-) > Facilities = Components that have access to the Merlin internals. To provide > the JMX (which is a facility (still in development)) support in your client > (for whatever reason), would require you 'home grown' container to replicate > the Merlin internals, which is far too much work, and you would be better off > embedding Merlin into your clients. hmm, i can't see a reason yet to build jmx into my clients... > If you could provide a little bit more info about your client side, we might > provide some advice on whether or not an Embedded Merlin is to recommend over > a 'home grown' container surrogate. if you really want, you're invited to have a look at my cdo project (connected data objects), which is open source and hosted at http://developer.berlios.de/projects/cdo. i've appended the original project reg. request to get a fast impression. the project is very very preliminary althoughbasically functional. if you don't want to go through the whole source you could read the architecture doc first. if you do so you should focus on the signalling framework which in fact is the heart of my cdo server. this framework is also extensible with user defined protocols (if i could use avalon services for that?). btw. i think the avalon/merlin/... docu would profit a lot from a common glossary of terms ;-)) /eike CDO Registration Request CDO (Connected Data Objects) is an object persistence technology that integrates with EMF (Eclipse Modelling Framework) to transparently store model objects into a relational database system and vice versa. To reduce network calls, it is based on a three-tier design. A CDO client enables EMF to use commonly known transaction semantics to manipulate model objects and their associated database records. It also offers demand loading of referenced objects and some kind of cache invalidation. A CDO server is responsible for taking the client requests and doing the actual O/R mapping through JDBC. It also provides asynchronous invalidation notification, auto-creating all needed tables and reliable and fast persistent garbage collection. CDO client and server communicate via a fast binary protocol, that is driven by a generic and extensible signalling framework. The support for sending asynchronous notifications to the client is used by the O/R mapper to distribute cache invalidations, but can also be extended to implement, for example, collaborative functionality. The open source technology EMF is very well suited for acting as a JAVA programmer’s front-end to the domain model of a software system and already provides an abstract persistence framework with concepts, like resource separation, transparent proxy resolution, model reflection and change recording. CDO aims at most conveniently and least intrusively providing relational persistence for new or existing EMF (ecore) models, that can even be used with EMF generated editors. The CDO client and server units are formed from a set of rather small Eclipse plugins, some of them being common to both. The common subset offers EMF model analysis and extensible bi-directional signalling. The client-side only plugins are mainly driven by the needs of a CDO aware EMF resource, that implements the six persistence use cases: a.. Initial loading of the resource contents (top-level objects) b.. Committing changes of the model objects back to the database c.. Demand loading of referenced objects from the database d.. Querying the database in addition to navigating from the top-level e.. Invalidating loaded objects on remote change (push service) f.. Unloading of model objects to better scale with heavy sessions The server-side plugins are concerned with doing the actual JDBC communication, needed to map the object-oriented paradigm of EMF and the CDO protocol to a relational database. By making use of an extensible SQL DDL abstraction framework the mapper allows for auto-creation of all needed tables. A deterministic garbage collection for persistent objects can be implemented quite easily, because the mapper stores all references between objects in a single separate table. The CDO server is expected to be run standalone or as a system service and would possibly be most performant in combination with an embedded database system. For further information see also: CDO Architecture.pdf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
