At 12:17 AM 1/24/00 +0100, you wrote:
>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 Meta Object Facility also has the capability of creating XML which
could help
automate some of the work being done in HL7.
>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.
This is why we use the AbbreviatedInclude in the COAS specification, so
only the part you need in a
given component is included. This is a pattern that can be used in other
applications, too. It radically reduces the size of the problem you mention.
>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.
Hmmm. I don't see why this is occurring. The Notification service is not
supposed to
be in the revised PIDS IDL.
>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.
See the AbbreviatedInclude approach.
>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.
This is what we recommend as demonstrated in the COAS document. It is not
a fake. You only need
to satisfy the typing requirements in your implementation. It still could
connect to a real Notification service somewhere else.
Dave
>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
