[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: [Fwd: jacOrb]]

Tom Bradford wrote:

Mark J Stang wrote:

Marcel,
Reading your response brought up a question.   In the client code, where
do I
specify which CORBA implementation I am using?   I am writing an XML
Server.   The server uses dbXML to store the documents.   dbXML can be
based on jacOrb or OpenOrb.      dbXML is currently running on OpenOrb.
So I am an OpenOrb CORBA client to dbXML.  I am trying to use xmlBlaster
for the networking.   This will allow my clients to "subscribe" to database
changes.   So I am a CORBA Client there also.   However, the version that I
am using is running on top of jacOrb.   So I am a jacOrb Client.

So, now I am back to my two options:

1)   Switch everyone to the same CORBA or at least get the clients to
work with both Orbs at the same time.

2) Switch out one component and replace it with a non-CORBA implementation.

I am pretty much locked into dbXML, not many open source XML databases...


Hey! What's that supposed to mean?
It means that dbXML is my database of choice. It works very well, it

does what I need it to do. And as I said, it is the only one that I know of that
is open source. Also, there are plans to wean dbXML off of CORBA. I have
considered using a relational database. If I were to then I would have to do it
right. That would mean normalizing the database and then get an Object/Relational
Mapping tool to map back to my object model. Or I would have to use an
Object Database. I have looked at both of those. The Relational/OR mapping
seems unnatural. The Object database seems more natural in that it maps to
my internal object model. However, I didn't see an implementation that I liked. And there isn't a standard. In my current view of my database needs, it appears
that my data is Hierarchical. XML maps very well to that. I considered using
individual XML files for my database. I would have had to write some searching
and indexing routines. With dbXML, I don't have to do that.

My core technology is not a database, it is not messaging, it is not Java. These
technologies combined with my business logic enable me to create my product.

Having said all of that, sorry for the long rant, I am sticking with dbXML, it is
my technology of choice for database. I have looked at swiftmq, xmlBlaster, Jxta,
JavaGroups, Jini and sockets as options for my messaging technology. I thought
I had finalized on xmlBlaster when I ran into the CORBA issue. My product
has stopped dead in its tracks while I solve this issue. So now I am re-evaluating
my messaging options. I am concerned with how much work it will take to get
xmlBlaster and dbXML to play well with each other. From my point of view,
it might take less time to use either a different product or a different technology.

Does anyone have a suggestion?


So does anyone think it is possible to get one client to talk to two
different orbs?
Or how do I eliminate all traces of jacOrb from my classpath?   By
eliminating
all traces, I mean what is imbedded in xmlBlaster that might be in the
way or
based on jacOrb?


One of the 'theoretical' beauties of CORBA, especially post-IIOP, but
even with GIOP, is that it should no longer matter what ORB code is at
each end point, so long as IIOP is being used as the wire protocol
between them.  There shouldn't be any reason why you couldn't use the
JacORB libraries to talk to a server being exposed using OpenORB.  Of
course, the complexity and generally nastiness of CORBA doesn't make
this easy.  It is definitely possible to do.

If there's anything I can do to help out, let me know.