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
jhan...@vanstar.com

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

    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".

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

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...)

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.

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.

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...

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.

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

--
****************************************
Ken Cartwright
Systems Architect & Developer
kenc...@erols.com
703-283-8292
****************************************

On 26 Sep 1997, Filipe Oliveira wrote:

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.

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.

        -- 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    |
+-------------------------------------------------------------------+

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

: 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

: > 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
: > jhan...@vanstar.com
: >
: > -------------------==== Posted via Deja News ====-----------------------
: >       http://www.dejanews.com/     Search, Read, Post to Usenet

: --
: ****************************************
: Ken Cartwright
: Systems Architect & Developer
: kenc...@erols.com
: 703-283-8292
: ****************************************

--

Ciao
  Roland

---------------------------------------------------------
Medical Informatics FH Heilbronn/Uni Heidelberg, Germany