 |  |  |
OSJI 1.3 with ObjectStore 5.1 Database Voyager 2.0 beta 1 5 May 1998 BlueDot Software, San Francisco, CA BlueDot Software
Note: there was a significant change from Voyager 2.0 b1 -> b2. I no longer use the "VObject" stuff. There is a new, better, way to do it, but in terms of integration with ObjectStore it doesn't matter much. - GENE 18 Jun 1998A while back I did a post with a detailed example of how to use ObjectSpace's Voyager and ObjectDesign's PSE. That example had full code, whereas, this one is only descriptive. Here is an updated one that tells, roughly, how I built a distributed app, in very short time, using JavaWebServer with Servlets, ObjectDesign's ObjectStore database with the Java interface ( OSJI ) and ObjectSpace's Voyager as a wire protocol. Apologies for the aspects of this post which involve other technologies, but I think its useful to see integration posts, and there is no where else to post them. I strongly recommend all three products and technologies. Putting together a sophisticated distributed database application is now in the reach of mere mortal programmers like myself. :) ObjectDesign - object databases ObjectSpace - CORBA compliant (soon) wire protocol Sun's JavaWebServer - web server with servlet support ----------- I have one class that I call the ContentManager whose job it is to provide access to the information in the database. Most of the database collections are held by the ContentManager. The ContentManager (CM) has many methods for getting, setting, relating, etc. the various Content items. So I made a small application that starts up, gets a database connection and gets a reference from the database root to the CM. I call this application the ReadServer. I intend to have a ReadServer and an UpdateServer. For now I just have the ReadServer, but they will be similar. The difference is that the ReadServer will open an MVCC Session to the database which is optimized for read only access. The UpdateServer will, obviously, allow updates. Then I "voyagerized" ReadServer. This is just a simple post compile step which I've heard isn't necessary anymore in the beta 2 release. Then I made a small StartReadServer class which has a "main" method that creates a new VReadServer and runs it at a well known port number on my localhost. The reason for a second class to be just a "main" method is that it is tough to compile ReadServer with a main method that makes a VReadServer. Its only tough the first time, however. That's the Server side. On the client side, I am using servlets, and I hope to use one C++ Windows app. In the servlet case I use the Voyager protocol to move data around and in the C++ app case I will use the CORBA functionality which should be available soon in Voyager. The servlet side is actually two servlets. I wrote a simple HTML template "language" which is just HTML plus a few special tags for doing queries and inserting their results. I had a recent post that tells how this works. The template processing servlet connects to another servlet that maintains a connection to the ReadServer through a VReadServer that it finds at the well known port #. Then I can pass most of my Content objects from the ReadServer to the client. It was really pretty easy to set up the voyager side of things. One thing I don't totally like is I now have 3 classes that have lots of methods, two of which don't really do anything. The servlet that maintains the connection to ReadServer has a method for every method in the Content Manager described above. There is another layer between the ContentManager and the servlet, however. The servlet calls methods in the ReadServer, and the ReadServer passes those calls on to the ContentManager. The nice thing about this is that the methods in the servlet are my public API and the methods in ReadServer are my private API and the methods in ContentManager are my actual implementation. Its great separation. Its a bit troublesome to maintain all three, and I feel a little foolish having 30 methods that do nothing but call other methods with identical names, but I can live with that. :) Gotchas: The nice thing about Voyager is that objects you want to pass as method parameters, or return values, don't require any special post-compiling or stub files or anything like that. The only postcompile I did was on ReadServer. There are 2 gotchas: 1) If you are returning a Vector from some method on the ReadServer, to some object on the client, you must "fetch" every item in the Vector. On the server side, when you get the Vector, it is just a Vector of references to objects that have not been "materialized" by the database. If you stayed on the Server side and printed one of those objects, it would "materialize" when you print it (or part of it). You must force this materialization before you send it through Voyager. The ObjectStore.fetch( object ) does this. So I fetch each object before I send it through Voyager, and if its a Vector, I iterate through and fetch each object. Note, fetching must be done even for single objects. 2) I had never really done a distributed app before, except for my PSE Voyager test that you saw, so this was a lesson for me. You do not want to send, through Voyager, a class that has a large collection or other data that you really don't need the client to have. It is wise to separate out the data that should be passed from Server to Client and the data that should remain Server side only. Sometimes it is enough to put the large Server only data in a separate object that never gets passed. The data you do want to pass is another object. Often, those two objects need to point to each other, however. If an object that you are passing references an object you don't want to pass, you are probably going to pass both. The way around this is to write your own serialization methods. It sounded intimidating at first, but it was easy. Just look at the JDK API under java.io.Serialization and Externalization. There is a difference between Serialzation and Externalization and you can write the methods for either. I did Serialzation. Hope that helps.
Return to Gene's Home Page
Return to Gene's Random Java Crap
Links: