Java, CORBA & ODBMS Integration
jha...@vanstar.com
Hello all, We are currently performing an evaluation on OODBMS and CORBA
vendors for a proof-of-concept project that will potentially impact the
future direction of our enterprise development strategy. We are
assessing the viability of "wrapping" the functionality of our existing
disparate legacy systems with these this framework, and to continue
future systems development using this technology. On all three counts:
Java, CORBA and OODBMS we will be blazing new ground as we are
traditionally a VB/Powerbuilder IS shop. I am hoping to solicit some
discussion/private responses from anyone who has experience good or bad,
with using these technologies as a foundation for an Enterprise-Wide IS
Solution. Also, any experience those of you who have entered into
arrangements with any of the following vendors as to the level of
service, support, scalability and overall product satisfaction would be
greatly appreciated.
CORBA Vendors: Expersoft, Visagenics, Orbix
Gemstone
ODBMS: ODI ObjectStore, POET, O2, Versant
TIA,
Jennifer Hansen
Systems Engineer
jha...@vanstar.com
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Paul Thomas Schneider
Here's a thought...
I worked on an effort where we wanted to integrate an existing set of
legacy
applications. The apps were large, monolithic, in-house analysis apps with
their own "hard-wired" file and data formats. We used CORBA as the "glue"
to put this all together (i.e. wrap the legacy apps' APIs), and an OODBMS
to provide persistence for our "little system".
There's lots of thoughts to share from this, but let me start with one.
We
really didn't prepare ourselves well for the ramifications w.r.t. business
data
that result for getting N applications to "collaborate" that were never
designed for it. The legacy apps had their own "spin" on how our business
data should be structured, etc.. Since these legacy apps were rather
monolithic
things, existing data was structured/stored/etc in such a way as to be
prejudiced
to a particular spin. When we started to look at our apps and our data from
an
enterprise perspective, little/none of it seemed "fit for consumption", i.e.
incomplete (from the enterprise perspective), ambiguities, no quality
indicators,
no pedigree, etc.. {Ya, a data warehouse expert on the team, in retrospect,
would probably have been a godsend, but such is life...} It became very
tough
to make data from certain data sources "palatable" for "new" (diffferent)
data
sinks!
I won't bore you with the gory details : I'll just say that there were
some very
serious issues about legacy data (and its sources), and legacy apps
"suddenly
collaborating" that hadn't before. Such issues are not new (hence my
reference to my assertion that a data warehouse person expert would probably
have sounded good warnings sooner). An effort can get so caught up in
dealing
with the issues that arise from using "cutting-edge" technology, that you
end
up getting nailed by a "legacy (well-known) problem".
Filipe Oliveira
We are developing a new SCADA system and we are using ORBIX from IONA
technologies with very good results.
We have already performed an evaluation on CORBA vendors and IONA was
considered for us the best one!
For the OODBMS evaluation we have evaluated some products in the market but
we concluded that the OODBMS is still relatively immature technology.
Paul, are you sure you want to use an OODBMS? Why don't you use an ORDBMS?
In fact, we are actually evaluating these products.
Bye and if you need something more tell me!!!
Filipe
Paul Thomas Schneider
Filipe Oliveira wrote:
> We are developing a new SCADA system and we are using ORBIX from IONA
> technologies with very good results.
>
> We have already performed an evaluation on CORBA vendors and IONA was
> considered for us the best one!
I'm using Iona products now, too. Of the three ORBs I've used on a project,
I'ddefinitely say that I like Orbix the best. (That's not to say Iona doesn't
have
room for improvement...)
>
>
> For the OODBMS evaluation we have evaluated some products in the market but
> we concluded that the OODBMS is still relatively immature technology.
> Paul, are you sure you want to use an OODBMS?
We _did_ use an OODBMS for the 2 years I was there, and they still are using
it.
I may have been unsure at the time whether that was what I wanted to do; in
retrospect, it was a good decision. Would an ORDBMS have been "just as good"
of a decision? I don't know; I don't think there were many
around/available_to_me
at the time I had to make the decision, so I'm not sure if it was an option.
I've not
had cause to look at ORDBMS products since then. It is my understanding that
ORDBMS products do not have the sorts of sophisticated client-side caching
features that are commonplace for OODBMS products; if true, that would
definitely
have supported my use of an OODBMS. We had a deployment environment
solely populated by fat clients, and performance was a high-priority issue; the
client-side caching provided by my OODBMS was a real benefit.
> Why don't you use an ORDBMS?
Had we not been able to find an OODBMS, we probably would have. My
questionwould be; if I can find an OODBMS that meets my needs, why would I use
an
ORDBMS? Once again, it is my understanding that an ORDBMS is really just a
transitional construct; industry wraps a legacy technology with new technology
to make it palatable. In DBMS-land, this is great if you want to use new
technology
with legacy data stores; if you're creating a new data store, then it's
redundant in
the presence of OODBMS products. Lucky for me, I was creating a new data store.
Joshua Duhl
Filipe Oliveira wrote:
>
> We are developing a new SCADA system and we are using ORBIX from IONA
> technologies with very good results.
>
> We have already performed an evaluation on CORBA vendors and IONA was
> considered for us the best one!
>
> market but
> we concluded that the OODBMS is still relatively immature technology.
It is my understanding that SCADA applications have some very
interesting database requirements, in particular, the need for
for simultaneous real-time access as well as historical analysis of
SCADA data.
I disagree with your assessment that the object databases are immature.
They may not meet the above requirements of SCADA applications, and
possible many traditional databases wouldn't either. But that does not
mean that they are immature.
If SCADA data is fairly regular, than a relational database may do.
Or you might have considered the MATISSE datatbase (www.matisse.com)
which has been used to run nuclear power plants and has a database
engine that is geared for both real-time and historical data access.
The engine is based on a versioning server architecture meaning that it
creates a new instance of an object upon update rather than overwriting
the object. Thus it can handle lots of new data creation as well as the
sort of historical analyses typically done in SCADA applications. It
uses
a semantic data model which supports objects very well, and provides
modeling flexibility as well. But you may not have looked that far...
> Paul, are you sure you want to use an OODBMS? Why don't you use an
> ORDBMS? In fact, we are actually evaluating these products.
There are only a couple of the ORDBMSs which really do support objects.
Those are from Unidata (which is basically the O2 product), Unisys,
and InterSystems. There are a couple of Java Relational databases as
well, such as Harmonia from JB Development and Cloudscape's product
still in development. The ORDBMSs from IBM, Informix and Oracle do
not provide full support of objects and in my opinion would be a step
backwards for an IS shop looking forwards.
Regards,
-- Joshua Duhl
Stillpoint Consulting
email: remove the "_remove_this_to_reply_" from above email address to
respond.
Kenneth Cartwright
Hello,
I've been a developer and leader on threee different projects that use the
combination of an ORB and an OODBMS and a couple using the combination
of an ORB and Java. I hope the following is usefull to you. Please keep in
mind that these opinions are mine. Others may have different opinions. Sorry,
its a bit lengthy, but you've hit on my area :-)
All of the projects used Orbix and or OrbixWeb in concert with either
Object Store or Objectivity. In general my experience using the technologies
separate from one another is entirely positive. I really enjoyed developing
developing with each. Setting aside the bugs that existined in the 1.0
version of JDK I saw about a 25% improvement in productivity
developing in Java over C++. Working with Orbix and OrbixWeb was
great. It makes working with TCP/IP or CGI look painfull and silly
(respectively). Developing an object oriented application whose objects must
be persistent is greatly simplified by using an OODBMS (I like Object Store).
That said, I advise you to proceed with care when using Java, CORBA,
and OODBMSs in concert to provide an enterprise solution. Its not
nearly as easy as the marketing literature suggests when developing a mid
to large sized distributed system. Look closely
at the following issues (some of which are much easier to solve now
than they were when I first encountered them over the past three years):
CORBA and Java:
Firewalls. CORBA brings Web based enterprise systems into the
20th century. No more CGI junk or data blades (screen scrapers for
data bases >:-( ) ). However, while most firewall proxies are built
to let HTTP in and out, most are not built to work with IIOP. Iona
and others are working to rectify this problem, but if you will develop
applets that need to talk through client side and or server side firewalls
you will need to work thiss issue. Check out Wonderwall and OrbixWeb
documentation on http://www.iona.com for some guidance.
Java's Applet Security Model. The applet sandbox secutiry, by default
only allows applets to connect (open a tcp/ip connection) back to the
host that serverd up the applet. This can be worked around with applet
signatures Wonderwall and some other mechanisms but keep in mind
that your ORB servers *may* have to reside on your web server host
if you do not use one of the work arounds.
CORBA and OODBMS
OODBMS structures to IDL strustures. ORBs are great OODBMS's
are fantastic (I've been very pleased with Object Store, but not as
happy with Objectivity, just my $.02) but they were not built to
necessarily work in concert. You will have to create an
ORB/OODBMS adaptation layer that make the persistent objects
and functionality of your OODBMS classes available to ORB clients.
This is a bit easier these days because some patterns
are emerging based on the work people have done in this area over
the past few years. Check out the ODAF at http://www.iona.com.
ODAF stand for Object Databse Adapter Framework. If you
can get your hands on it try using it. If not, just reading about its design
will offer some design and implementaion patters. In general, the
complexity revolves around, mapping your server side data structures
onto the IDL data typs and structures. Its interesting that the this is
an area where the wonderful flexibility of OODBMS's and ORBs
work against you. Since you can define any persisted class structure
in an OODBMS using your implementation language and any data
ORB data structures using IDL there is no easy way to automate this
mapping.
Adapter Scaleability. OODBMS can hold millions of objects. They are
designed and optimized to page object into and out of client memory as
pointers to them are dereferenced (no need for joins just to access a
related object, its so great and intuitive), however when the client is on the
other end of the ORB wire these capabilites of the OODBMS server are
watered down. In general, ORB objects accessed by ORB clients are not
also persistent objects. When a call comes over the wire to an ORB
object you will need to map/forward that call onto the target persistent
object, and potentially convert the calls return value from its OODBMS
data type to the appropriate IDL data type (not a big deal with ints
and shorts but when the return value is an ObjectStore::Collection
of objects, for example, it gets a bit involved). You will have to
design and implement a mechanisms to implement this ORB-object to
persisten-object mapping. On my first project combining Orbix and
ObjectStore back in '94/'95 I learnded the hard way that trying to make
each persistent object live as an ORB object does not scale to big servers.
You may want to look at loaders, markers, object_to_string,
string_to_object, the naming service wrapped to support load balancing
across several server hosts, etc.
OODBMS scaleability. An interesting property of OODBMSs is that
they can put more onerous on the developer to optimize the use of the
OODBMS facilities. While relational databases are primarily built
on strict tabular structures, OODBMS's allow the developer to build any
object oriented structure they wish. The result is the potential need for
the developer to pay close attention to object clustering and cascading
locks imposed by transactions that touch and lock many objects.
I hope the above helps. Don't let it scare you. If your applications
are fairly small then the above issues are much less important. These
are rather new technologies that are maturing rapidly and it is only
natural that the mechanisms and patters to support their combined use
would lag a bit. I like and am sold on each of them.
Ken
jha...@vanstar.com wrote:
--
****************************************
Ken Cartwright
Systems Architect & Developer
ken...@erols.com
703-283-8292
****************************************
Akmal B Chaudhri
On 26 Sep 1997, Filipe Oliveira wrote:
> Date: 26 Sep 1997 11:25:31 GMT
> From: Filipe Oliveira <ene...@edinfor.pt>
> Newsgroups: comp.object.corba, comp.databases.object
> Subject: Re: Java, CORBA & ODBMS Integration
>
>
> We are developing a new SCADA system and we are using ORBIX from IONA
> technologies with very good results.
>
> We have already performed an evaluation on CORBA vendors and IONA was
> considered for us the best one!
>
> For the OODBMS evaluation we have evaluated some products in the market but
> we concluded that the OODBMS is still relatively immature technology.
Filipe, can you give reasons why you think OODBMS is still relatively
immature? I've seen some very good documented papers + my own experiences
in industry over the past few years suggest that on the whole, the
technology is mature. There are still deficiencies in some areas (e.g.
standards support - namely ODMG), but C++ gives plenty of portability in
my experience. Some 18 papers from users and practitioners on their
experiences with object databases are forthcoming in a book to be
published in November. They show mixed experiences (i.e. where there were
deficiencies, people were able to plug the "holes"), but generally, people
used the technology very effectively to solve their business problems.
> Paul, are you sure you want to use an OODBMS? Why don't you use an ORDBMS?
My benchmark tests with an ORDBMS showed it to be very mixed in
performance. In fact an object database was better by an order of
magnitude for OLTP! As far as navigational access was concerned, the
ORDBMS just dug a hole in the ground and disappeared.
> In fact, we are actually evaluating these products.
>
> Bye and if you need something more tell me!!!
>
> Filipe
>
>
>
>
-- Akmal.
"No amount of experimentation can ever prove me right; a single experiment
can prove me wrong." - Albert Einstein
+-------------------------------------------------------------------+
| OOPSLA '97 Workshop on "Experiences Using Object Data Management" |
| http://www.soi.city.ac.uk/~akmal/oopsla97.dir/workshop.html |
+-------------------------------------------------------------------+
Adnan Mumbasic
Hello Jennifer,
we had have the same problem, we wanted to build enterprise applications
with JAVA (100%), CORBA and ODBMS. At the beginning everything seems to
be easy. But after evaluating OODBMS=B4s we were totally disapointed. No
DB (with 100% JAVA) were able to be integrated with an ORB and giving us
transactional security (!). Transactions with CORBA a very hard to solve
without OTS. We evaluated all possible ODBMS=B4s and came to the
conclusion that oly GemStone could satisfy all of our requirements, but
we never did see GemStone. They promised us every week that we will get
the software, until today I haven=B4t seen anything from GemStone.
We met some people from POET, and together found for us the solution.
POET added some features in the database kernel so that we could access
all objects over CORBA. We programmed our own adapter between POET and
the ORB. Even transactions can be started over CORBA. We could do
queries, and the whole object tree is accessible over CORBA as well
through normal JAVA references. And remeber we made all in pure JAVA. We
didn=B4t develop an OTS, but we have our own transactions through =
together with IONA OrbixWeb and POET. We are waiting for a JAVA release
of OTS.
Ok the performance is not so, but our project should be finished in 2-3
years. So there is time for some improvment of the JAVA compilers.
Best regards
Adnan Mumbasic
SEITZ GmbH
jha...@vanstar.com wrote:
> =
> Hello all, We are currently performing an evaluation on OODBMS and CORB=
A
> vendors for a proof-of-concept project that will potentially impact the=
> future direction of our enterprise development strategy. We are
> assessing the viability of "wrapping" the functionality of our existing=
> disparate legacy systems with these this framework, and to continue
> future systems development using this technology. On all three counts:=
> Java, CORBA and OODBMS we will be blazing new ground as we are
> traditionally a VB/Powerbuilder IS shop. I am hoping to solicit some
> discussion/private responses from anyone who has experience good or bad=
,
> with using these technologies as a foundation for an Enterprise-Wide IS=
> Solution. Also, any experience those of you who have entered into
> arrangements with any of the following vendors as to the level of
> service, support, scalability and overall product satisfaction would be=
> greatly appreciated.
> =
> CORBA Vendors: Expersoft, Visagenics, Orbix
> =
> Gemstone
> =
> ODBMS: ODI ObjectStore, POET, O2, Versant
> =
> TIA,
> Jennifer Hansen
> Systems Engineer
> jha...@vanstar.com
> =
> -------------------=3D=3D=3D=3D Posted via Deja News =3D=3D=3D=3D------=
Roland Haag
Kenneth Cartwright (ken...@erols.com) wrote:
: Hello,
: CORBA and Java:
: CORBA and OODBMS
: Ken
: jha...@vanstar.com wrote:
--
Ciao
Roland
---------------------------------------------------------
Medical Informatics FH Heilbronn/Uni Heidelberg, Germany