[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: [Fwd: jacOrb]]
Tom Bradford wrote:
does what I need it to do. And as I said, it is the only one that I
know of that
Mark J Stang wrote:
Reading your response brought up a question. In the client code, where
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
is open source. Also, there are plans to wean dbXML off of CORBA. I
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
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
seems unnatural. The Object database seems more natural in that it
my internal object model. However, I didn't see an implementation that
And there isn't a standard. In my current view of my database needs,
that my data is Hierarchical. XML maps very well to that. I
individual XML files for my database. I would have had to write some
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
technologies combined with my business logic enable me to create my
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,
JavaGroups, Jini and sockets as options for my messaging technology. I
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
my messaging options. I am concerned with how much work it will take
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
Does anyone have a suggestion?
So does anyone think it is possible to get one client to talk to two
Or how do I eliminate all traces of jacOrb from my classpath? By
all traces, I mean what is imbedded in xmlBlaster that might be in the
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.