AW: [Objectbridge-jdo-dev] Non-JDBC data sources
Brought to you by:
thma
Menu
▾
▴
AW: [Objectbridge-jdo-dev] Non-JDBC data sources
|
From: Mahler T. <tho...@it...> - 2002-06-17 09:47:48
|
Hi Juozas, >=20 > Hi, > I work on experimental persistence framework, it is Apache=20 > SimpleStore. It > has implementation > for JDBC, XMLDB and file. May be it is possible to merge both=20 > projects ? Yes this may be interesting for the new db.apache.org project! > It is nothing bad to have two or more projects about the=20 > same, but I think > it is good > to find something the most usefull and reuse it. I agree! > I prefer to have three or more projects at Apache : > 1) Standard Apache DB API, only interfaces and "large" documentation. Do we need new persistence APIs? There are standard APIs for Object-Persistence: ODMG, JDO, S.O.A.P. I don't see any requirements for Yet Another Persistence API. > 2) Implementations and "small" documentation. >=20 > JDO can be some kind of "standard" API, but it closed for=20 > people like me and > I prefer Open Standards. >=20 Where can I find more info on your project? cheers, Thomas >=20 > Hi David, >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: David Zejda [mailto:dv...@at...] > > Gesendet: Donnerstag, 13. Juni 2002 01:17 > > An: Obj...@li... > > Betreff: [Objectbridge-jdo-dev] Non-JDBC data sources > > > > > > I know, that OJB's focus sharpness (faq: It's concerned with > > O/R mapping and > > nothing else.) is design/manage advantage, but I work on > > project, where it's > > crucial to integrate disparate data sources (RDBMS, ODBMS, > > XML based DBMS, > > flat-files, vendor specific formats..). I decided not to use = closed, > > non-free solutions at all, so OJB (open-source, clearly designed, > > scalable...), seems to be suitable as a persistency-heart. > > Could you advise how to get on with OJB? >=20 >=20 > > 1) use OJB as a single persistency adaptor, manage several ODMG > > implementations, make some fascade to hide it, e.g. solve=20 > distributed > > transactions...? >=20 > If there are existing ODMG Java bindings to you other=20 > datasources this will > be vers easy. > Just write litte wrappers that route user request to different ODMG > implementations. >=20 > If there is no ODMG API for a given persistent store, you can=20 > implement a > dedicated PersistenceBroker for this special persistent store. > This way you can use the OJB ODMG (or JDO if you prefer)=20 > implementation to > access arbitrary persistent stores. >=20 > > 2) extent OJB (add persistency adpators to OJB) - if > > publically useful, > > release them under LGPL as modular OJB's parts/add-ons? >=20 > Yes, that's what I'm recommending. have a look at our=20 > persistence kernel > interface ojb.broker.PersistenceBroker. > It contains no specifics for RDBMS. It is a generic abstractiion of = an > object store. > There could be implementations for OODBMS, RDBMS, XML=20 > databases, file system > or Directory Services ! >=20 > You only have to provide a persistent store specific = PersistenceBroker > Implementation. > Than you can use the OJB ODMG or JDO layer to work against=20 > those specific > brokers. >=20 > regarding OJB scope: > As OJB will be one of the foundation projects of the new=20 > db.apache.org site, > our scope is not longer limited as mentioned in the faq. > OJB will be a generic object persistence integration platform! >=20 > Thus having new PersistenceBroker implementations is very=20 > interesting for > us! > (especially XML, OODBMS, LDAP, flat-file) >=20 > As we are moving to Jakarta, we will use the apache licence soon. >=20 > > 2.1) is this posible without (negative) impact on OJB's=20 > actual design >=20 > yes no problems! >=20 > > 3) something else? > > > > In the roadmap there is (4me) a bit mysterious sentence "provide > > distributed Meta-Object Protocol access through=20 > PersistenceBroker API" >=20 > This has been implemented a long time ago. OJB comes with a=20 > client/server > mode. To have fully operational clients it is necessary to=20 > have meta-data on > the client too. This was not possible in the early days, but=20 > now it is. >=20 > > Somewhere in OJB doc I read about possibility to build my own > > PersistenceManager. Does it relate to mentioned problem? > > >=20 > No. You simply have to implement the PersistenceBroker=20 > interface to write a > new storage adaptor. >=20 > A persistenceManager would be something like your own ODMG or JDO > implementation. That would be a much more difficult task! >=20 > cheers, >=20 > Thomas >=20 > > Thanks for reply > > David Zejda > > > > > > PS: I know, I can suck all wanted info from API, but I=20 > thing, you (OJB > > experts) can answer quickly and painlessly. > > > > BTW thanks for OJB, well done! > > > > > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas - > > http://devcon.sprintpcs.com/adp/index.cfm?source=3Dosdntextlink > > > > _______________________________________________ > > Objectbridge-jdo-dev mailing list > > Obj...@li... > > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=3Ddntextlink >=20 > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >=20 >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -=20 > http://devcon.sprintpcs.com/adp/index.cfm?source=3Dosdntextlink >=20 > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >=20 |
