Re: Ozone based framework
Christian Merenda <[email protected]> Tue, 13 Nov 2007 11:47:55 +0100
| Newsgroups | gmane.comp.java.ozone.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1901206114== Content-Type: multipart/alternative; boundary="------------090506070803030607020004" This is a multi-part message in MIME format. --------------090506070803030607020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Kov=E1cs, the caching mechanism that you describe is typically (or should be) a=20 basis functionality of an object database system. You query for certain=20 objects, they are delivered to the client (which may be a remote client,=20 e.g. a Java Swing GUI) and then - as you go on the navigate through the=20 object graph - missing objects are transparently downloaded by the=20 client-side caching engine. During commit or before the next query=20 resolution the objects must be transparently sent back to the server.=20 Often it is not sufficient to load the objects not until they are=20 actually needed, thus you must have the ability to pre-load some objects=20 as you know that certain associations will be traversed certainly. To=20 give a short example: You query for all persons in the database and you=20 want to display them in your GUI alongside with their addresses. It=20 wouldn't be a good idea to make a remote procedure call for every=20 address you navigate to during result iteration. (!) In practice, odbms systems sometimes do not offer such a functionality.=20 But often they do. I know that e.g. Versant does offer a caching=20 solution for its objects database. But - for sure - it is not open source= . In fact it is a complex topic and difficult to manage outside the scope=20 of a specific database. Please note, that caching must be also=20 interconnected with transaction management and - as mentioned above -=20 query resolution (which is - as far as I know - not ozone's way of=20 thinking). Therefore I think there are two possible solutions: (1) first, as Gerd M=FCller wrote, you integrate a caching engine directl= y=20 into ozone. Then you upgrade ozone with a client-side caching engine,=20 which would be quite nice, but a specific solution. (2) second, you write a caching engine, which is not bound to a specific=20 database system. This would be really cool, as you are not bound to only=20 one database. Due to the reasons mentioned above, this is nearly=20 impossible and very hard work. But there's an opportunity at hand: you=20 could join our open source project OOMEGA, where we've accomplished=20 nearly everything you need, to code a database-neutral caching engine=20 which would work for e.g. Hibernate/relational databases as well as for=20 object databases. Best, Christian --=20 <http://www.oomega.net> OOMEGA GbR | Christian Merenda Fingerhutstra=DFe 6, 80995 Munich, Germany Phone +49 (89) 82 90 97-17 Fax +49 (89) 82 90 97-80 [email protected] <mailto:[email protected]> http://www.oomega.net Gerd M=FCller schrieb: > Hi Kov=E1cs, > > Although I'm not an active Ozone developer and user anymore it sounds=20 > really interessting to me. From what I understand you've built a=20 > client-side ozone cache by simply serializing certain ozone objects. Bu= t=20 > maybe we could see it from a more abstract point of view: what you need= =20 > is a mirror of parts of an ozone database. Maybe it would more elegant=20 > to use ozone itself to manage such a mirror. > > Than your application would always connect to a local instance of ozone= =20 > with all the speed benefits. This client-side instance is attached to a= =20 > server-side ozone database. If your application requests an object whic= h=20 > is not in your local cache it loads it from the server, i.e. we need a=20 > transparent ozone proxy that implements a cache. > > BTW: You will find CVS read-access here:=20 > http://sourceforge.net/cvs/?group_id=3D39695 > > Best Regards, > Gerd > > Kov=E1cs G=E1bor schrieb: > =20 >> Hi All, >> >> I've been using/testing ozone for 4 years now in various test and proo= f=20 >> of concept projects. >> I've tested a few other object oriented databases as well. I'd like to= =20 >> share some thoughts with you. >> >> I think that ozone is unique, because AFAIK no other object oriented=20 >> database server handles the object links as proxy objects. If you are=20 >> developing a server side application this is a huge plus, since usuall= y=20 >> the hardest part of object retrieval is building and caching a complex= =20 >> object tree, and the main performance hit usually comes from that.=20 >> Ozone, on the other hand, does the object retrieval in a natural and=20 >> elegant way, reaching only for objects really needed. This method is=20 >> perfect on the server side, and it works (but much slower) on the clie= nt=20 >> side as well, if RMI communication is allowed between the server and t= he=20 >> client. >> >> We encounter problems with this model when we need to send a complex=20 >> object graph to a fat, GUI like client, process the data and store som= e=20 >> objects back to the server. >> Another problem is that when developing a real world application,=20 >> sometimes allowing RMI communication between the server and the client= =20 >> is not an option. >> >> I've done more than just thinking about this :). To solve these=20 >> problems, I've developed a framework, where ozone objects can be=20 >> detached from the server - a selected graph serialized and sent to th= e=20 >> client where the data is processed and offline modifications=20 >> subsequently re-attached to the server. The depth of the graph to be=20 >> detached is specified in the call to the framework. The details of=20 >> translating objects/graphs in both directions of this process is=20 >> automatically handled by this solution. The framework also implements=20 >> database indexing using native ozone objects (retrieving all object=20 >> instances of a certain class is also working). This framework should = be=20 >> viewed as a layer on top of Ozone developed specifically to meet the=20 >> real-life problems I mentioned above. The framwork uses native _Ozone=20 >> and serializable _POJO classes. I've also written ant tasks for easy=20 >> generation of the counterpart objects. If a process works on the serve= r=20 >> side, it can use the native _Ozone classes, a remote client can deal=20 >> with serializable _POJO classes. >> >> I have a couple questions regarding Ozone and this framework: First o= f=20 >> all, is ozone currently actively being developed? How can I get CVS=20 >> access (either read-only or with commit rights)?? And finally, does=20 >> this framework interest anyone? Would anyone be interested in testing=20 >> and improving/contributing to this framework project? >> >> I hope there are some folks who actively developing/using Ozone. >> >> Regards, >> Gejzir >> >> >> >> ----------------------------------------------------------------------= --- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser= . >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Ozone-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/ozone-users >> =20 > > =20 --------------090506070803030607020004 Content-Type: multipart/related; boundary="------------080509000201000706040109" --------------080509000201000706040109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Kovács,<br> <br> the caching mechanism that you describe is typically (or should be) a basis functionality of an object database system. You query for certain objects, they are delivered to the client (which may be a remote client, e.g. a Java Swing GUI) and then - as you go on the navigate through the object graph - missing objects are transparently downloaded by the client-side caching engine. During commit or before the next query resolution the objects must be transparently sent back to the server. Often it is not sufficient to load the objects not until they are actually needed, thus you must have the ability to pre-load some objects as you know that certain associations will be traversed certainly. To give a short example: You query for all persons in the database and you want to display them in your GUI alongside with their addresses. It wouldn't be a good idea to make a remote procedure call for every address you navigate to during result iteration. (!)<br> <br> In practice, odbms systems sometimes do not offer such a functionality. But often they do. I know that e.g. Versant does offer a caching solution for its objects database. But - for sure - it is not open source. <br> <br> In fact it is a complex topic and difficult to manage outside the scope of a specific database. Please note, that caching must be also interconnected with transaction management and - as mentioned above - query resolution (which is - as far as I know - not ozone's way of thinking). Therefore I think there are two possible solutions:<br> <br> (1) first, as Gerd Müller wrote, you integrate a caching engine directly into ozone. Then you upgrade ozone with a client-side caching engine, which would be quite nice, but a specific solution.<br> <br> (2) second, you write a caching engine, which is not bound to a specific database system. This would be really cool, as you are not bound to only one database. Due to the reasons mentioned above, this is nearly impossible and very hard work. But there's an opportunity at hand: you could join our open source project OOMEGA, where we've accomplished nearly everything you need, to code a database-neutral caching engine which would work for e.g. Hibernate/relational databases as well as for object databases.<br> <br> Best, Christian<br> <br> -- <br> <span style="font-size: 10pt; font-family: Arial;"> <a href="http://www.oomega.net"><img src="cid:[email protected]" border="0"></a><br> <br> OOMEGA GbR | Christian Merenda<br> Fingerhutstraße 6, 80995 Munich, Germany<br> <br> Phone +49 (89) 82 90 97-17<br> Fax +49 (89) 82 90 97-80<br> <a href="mailto:[email protected]">[email protected]</a><br> <a href="http://www.oomega.net">http://www.oomega.net</a></span><br> <br> Gerd Müller schrieb: <blockquote cite="mid:[email protected]" type="cite"> <pre wrap="">Hi Kovács, Although I'm not an active Ozone developer and user anymore it sounds really interessting to me. From what I understand you've built a client-side ozone cache by simply serializing certain ozone objects. But maybe we could see it from a more abstract point of view: what you need is a mirror of parts of an ozone database. Maybe it would more elegant to use ozone itself to manage such a mirror. Than your application would always connect to a local instance of ozone with all the speed benefits. This client-side instance is attached to a server-side ozone database. If your application requests an object which is not in your local cache it loads it from the server, i.e. we need a transparent ozone proxy that implements a cache. BTW: You will find CVS read-access here: <a class="moz-txt-link-freetext" href="http://sourceforge.net/cvs/?group_id=39695">http://sourceforge.net/cvs/?group_id=39695</a> Best Regards, Gerd Kovács Gábor schrieb: </pre> <blockquote type="cite"> <pre wrap="">Hi All, I've been using/testing ozone for 4 years now in various test and proof of concept projects. I've tested a few other object oriented databases as well. I'd like to share some thoughts with you. I think that ozone is unique, because AFAIK no other object oriented database server handles the object links as proxy objects. If you are developing a server side application this is a huge plus, since usually the hardest part of object retrieval is building and caching a complex object tree, and the main performance hit usually comes from that. Ozone, on the other hand, does the object retrieval in a natural and elegant way, reaching only for objects really needed. This method is perfect on the server side, and it works (but much slower) on the client side as well, if RMI communication is allowed between the server and the client. We encounter problems with this model when we need to send a complex object graph to a fat, GUI like client, process the data and store some objects back to the server. Another problem is that when developing a real world application, sometimes allowing RMI communication between the server and the client is not an option. I've done more than just thinking about this :). To solve these problems, I've developed a framework, where ozone objects can be detached from the server - a selected graph serialized and sent to the client where the data is processed and offline modifications subsequently re-attached to the server. The depth of the graph to be detached is specified in the call to the framework. The details of translating objects/graphs in both directions of this process is automatically handled by this solution. The framework also implements database indexing using native ozone objects (retrieving all object instances of a certain class is also working). This framework should be viewed as a layer on top of Ozone developed specifically to meet the real-life problems I mentioned above. The framwork uses native _Ozone and serializable _POJO classes. I've also written ant tasks for easy generation of the counterpart objects. If a process works on the server side, it can use the native _Ozone classes, a remote client can deal with serializable _POJO classes. I have a couple questions regarding Ozone and this framework: First of all, is ozone currently actively being developed? How can I get CVS access (either read-only or with commit rights)?? And finally, does this framework interest anyone? Would anyone be interested in testing and improving/contributing to this framework project? I hope there are some folks who actively developing/using Ozone. Regards, Gejzir ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> <a class="moz-txt-link-freetext" href="http://get.splunk.com/">http://get.splunk.com/</a> _______________________________________________ Ozone-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ozone-users">https://lists.sourceforge.net/lists/listinfo/ozone-users</a> </pre> </blockquote> <pre wrap=""><!----> </pre> </blockquote> </body> </html> --------------080509000201000706040109 Content-Type: image/gif; name="oomega-logo.gif" Content-Transfer-Encoding: base64 Content-ID: <[email protected]> Content-Disposition: inline; filename="oomega-logo.gif" R0lGODlhpwAZAPcAAAI5hCg1azJHanGHlVeJxjdmqFdsixghWVaEuxQkMBEVJZKnt3WZy4iq 2QAxdMfO1yVSl73W3tbn72eUyufv+CM0Q3F1q5i33L3W6CZFiI12pRApdDRGVyUmRY2Zynml 1ENXZyMlN0xVjta04Ud2tlZoegBKlJi66VR7uWWLx2V4iKm86LjO7AxrrjJYmarH6mWJvIeY qTQ1Vqi72/LW+yYzVZiqyUNqqoenzSIiWAcpdkZGZsre+SRKkqi5y87n7yEYTkRGWA4RGYmZ uEA5Yklldnec11VWeKqZzEZzrCxaomVniHmJo45fbBZCiGh4l0ZXdTI0R5Ws2JiYvKrG28zn +mdmmWFZjZq2xtOltHZ4mzCQ0dnb/IeIqhgYVjNHhXqVpHiIt6iqyq+IsyhEVDNjnYiHulJ2 rho2ffPR2tne6EZHdou130+t7hwXNLm54CVSi8jK6/3t/BZTmGia0gZapRVKkGZWdbODjDEp Rkp7v2NweydCSrzY+Kqq2HeWuTlSXkhja1hzfzZSjFNWaqvM9ZeJvoWRnHVpnFpno8vJ+nBJ U9zH+5vH73eu6Z+uvMLGzbrL9rur4EVrtRtEdS0pVWqUvFNJeDJCSrulyyQYbFNIaN33/+rm 72aCq6vGzpaJqDNKlXOMw/7n7HN3jLy7yd/H6ZSZrB84Zm9ap2LA/TZgcBN+vEpbnVJjcQgp axZSjHloi6rW9xcYYzJ3vV+CkGqM0ZzG3Pz37xsWGVQ6QoGluEZvfwBSlMbe5xkhY87e78bW 5hghbb3O3gBCjABKjN7v99bn9////+/3/wBSnL3O1s7e5xApawBChOf39xAhbtbv98Xe7+f3 /xkpbff//wBanLXO3ghCjff3/97v/+/39xAhY9bn/whKkghSlL7G1sbW8t7n9AhSnAlanNXv /7XG1f/397XG5OHm/whChABSjM/W8f/3/xopYbTO1hApY8LC4QNjpNHW4QBKhPf39///9wBa lO///wgxc/f/93KUnQ1KhAFRltkABgA3cywAAAAApwAZAAAI/wD9CRxIsKBBgsgSIjvIsKE/ hQsdSnwIMeJEhxAvSsyosaPHgRw/GgwpEiTJkhQTokSocKXLkS1fprTo8mRJmyJxyswZ86XO jz87BtU4dOfFokd71lSKEulGpkZ5qpTp9OnUpVdXVhVasStNgTa9doWZFSzTsFDFqq1Idq3a tmInui07E27cgmjL5v06c+5YvH7vslwrd25bu14PA9abtnHgv4Mf7xXc0K/iyG8X8z25F/Fj z4FBQxXteLNhzZfN0t3KcHJi1FFVE4aNmbLs1HVpay1tO3dsy7plZ46Mu7NP3q+Jx+7b23Vy k6vPlqaKHDJ0vtTd4mb+/HZw41hNz45W/vs0+evDrxefrlly9PHq23c/CPy88Obs49vn/lm+ de+1/Uefefqhh997X4FnoGSkiedgbw06GOF2nOW3YH8BshUcf6wRNZpUEu7X4XYgNrgcgOGt h2B22AFVnYbLjUihdCseR1eJ/sFY3o042qdgUx965JyOUcm4YYU1pmjjg/PtZKSINIao5JQX 2hQQADs= --------------080509000201000706040109-- --------------090506070803030607020004-- --===============1901206114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============1901206114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ozone-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ozone-users --===============1901206114==--