Greg Kreis wrote:
>
> Brian Bray wrote:
> >
> > I really agree with this concern. Corba has a huge learning curve and
> > some of it's component standards are much better than others (I curse
> > the C++ bindings daily).
>
> If I was a CORBA vendor, this would be my biggest concern. HTML caught the
> computer world by surprise and upset the apple cart for many a client/server
> vendor. Could CORBA be in a similar predicament? I DO NOT want to start a
> flame war. Not at all. But I am wondering if some interoperability standard
> (perhaps using XML) is going to sneak up on the CORBA/DCOM/EJB world.
> Describing this competitor, I'd say it probably won't be as sophisticated as
> them, BUT it will be a lot simpler for legacy systems to implement.
>
I think is one way to look at the HL7 / Corbamed debate. HL7 is going
to XML defined transactions based on transmitting extensible data
objects in an easy to process public format while CorbaMed is putting
fairly abstract active objects into large servers and communicating by
exchanging data structures.
The thing that will make or break Corba though is its implementations
and the way they interact with higher level standards such as CorbaMed.
To give a specific example, the CorbaMed PIDS standard, like a lot of
other recent standards, provides a set of links to other components in
it's primary interface. This means that you can go from a PIDS object
to an associated Naming service, Trading service, or Notification
service.
You return a simple NIL value to indicate that you don't support this
type of service or provide a link. Sounds simple?
Corba IDL has no ability to partially define a type, so the interface
for these other services must be included in the IDL for the PIDS
interface. These interfaces themselves provide links to other
components. When using a statically typed language, this means that the
generated header files for virtually every Corba standard is included
for every PIDS source file. On my system this means over 50,000 lines
of header files before a single line of PIDS server code is processed by
the compiler. This makes no difference to the end product, but slows
development.
I don't have a Notification service, so I return a NIL value. The
automatically generated code from the IDL compiler doesn't know that I'm
only sending a NIL, so it's ready to send anything. It bulks up my
executable with 615K of automatically generated object code to send that
one NIL.
Is this a problem with the PIDS IDL? The Corba IDL language. The C++
binding standard. My ORB implementation? My development tools? It could
be fixed at any of these levels, but it's really a consequence of how
they all work together.
My choices are:
0) Accept that 615K is OK to send a NIL(after all, it's just *virtual*
memory)
1) Edit the automatically generated header and source files manually
2) Abandon the standard C++ binding (other open source projects have
done this)
3) Implement an "almost PIDS" interface
4) Create my own "short" idl definition of the Notification Service.
I.E. Fake a partial definition.
What do the Corba folks on the list recommend?
> Can we come up with a design that is above DCOM, CORBA or EJB so we can remain
> neutral enough to easily migrate to a different strategy? The obvious problem
> with this approach is it adds one more layer of complexity and performance drain
> to the onion. The great advantage, in my eyes, is being able to rest easy that
> the EMR would be better prepared to withstand a Standards earthquake.
>
> > While Corba doesn't have to be large and slow, some of the implementations are.
>
> This benchmark shows there can be a WORLD of difference in the speed.
>
> http://www.omex.ch/CorbaTB/corbatb.htm
>
The more I think about EMR, the more I think of a document for each
patient. No database or middleware needed ;-)
-Brian
