Re: popular CORBA systems ?
On Thu, 23 Sep 2010, ashok maiti wrote:
CORBA, or Common Object Request Broker Architecture, is a standard
architecture for distributed object systems.
I want to know example of such "distributed object systems". This is
what I don't understand. What kind of system are those ?
It means systems which:
1. Are composed of multiple processes, typically on different machines all
networked together
2. Are implemented in an object-oriented manner (whether in an OO language
or not)
3. Handle communication between the separate processes in terms of objects
(rather than messages, commands, or some other abstraction)
For your convenience , here is what my line of thinking says..
Can I say mainframe application is a "distributed object systems" ?
[ I guess not]
Typically not, because it's not composed of multiple processes. The
traditional mainframe app consists of a single chunk of software (which
could be multiple processes, although they don't really count as such for
our purposes) which interacts with fairly dumb clients through TN3270 or
HTTP or whatever.
If a mainframe app was built to interact with smarter clients, or other
mainframes, or backend systems doing other stuff, then it could be part of
a distributed system.
Can I say application developed in Lotus notes is a "distributed
object systems" ? [ I guess not]
It's distributed. I have no idea if it's an object system. I suspect not,
because i think there are clearer and more efficient abstractions for what
it does.
I am not clear with what is "distributed object systems" . Here is
the problem.
I worked on a classic one a long time ago.
It was in the field of research informatics; the problem was that there
were many different computer systems in a research organisation, each of
which provided access to some combination of data sets and analytical
services. For example, one machine might have a copy of the human genome,
and know how to search it. Another might have crystallographic structures
of lots of proteins. Another might be able to analyse structures to find
drug binding sites. Another might have a pile of excel spreadsheets with
the results of drug trials. Yet another might have data on the genetic
markers found in test subjects. A last could have a service to do linkage
analysis.
Lots of interesting analysis could be done by combining these datasets and
services. For example, you could look at people on whom some drugs were
effective and ineffective, and use linkage analysis to look for genetic
loci which determined responsiveness to the drug, then search for genes in
those loci which had known structures, and determine if any of them were
likely binding targets. That would tell you what protein the drug was
actually affecting, and which would give you ideas on how to improve it.
The problem was that the data and services were on separate and
unconnected systems.
The solution was to wrap each of those machines in an object model, then
build a CORBA layer which let them interact. So, the linkage analyser
could query the marker server, and so on.
The key thing about this is that the focus wasn't on writing software to
carry out some particular analysis, it was on building a foundation which
would enable hundreds of different such programs to be written quickly and
easily, so enabling more efficient research.
I wasn't there for long enough to see how it worked out (the company got
swallowed up several years ago - i don't know if that was a sign of
success or of failure), but it was interesting stuff.
tom
--
Cthulu saves! (so he can eat you later)