Thanks for trying to stand back and take a broader look. I believe I'm in
violent agreement with you.
It may be true that the interfaces we have defined in CORBAmed are the
least common denominator, but that doesn't stop us from building on them
and making them more complete. For example, the COAS model is read-only,
but we have added the ability to create, edit, and sign COAS data with a
simple extension of the COAS IDL which is fully compatible with the
standard but adds functionality. I would like to see this group pioneer
enhanced functionality that could eventually be standardized. This is what
we've been doing with CORBAmed and we would like to see additional
coordinated efforts in this area. There is no reason we should be
satisfied with a "dumbing down" approach in creating standard interoperable
components that are language and platform neutral. If PIDS, TQS, COAS,
RAD have insufficient flexibility, lets fix them! There is a process
to do that and this group could be a great platform for pushing the right
change forward. The alternative is to come up with our own interoperable,
lanaguage and platform neutral approach which seems a little silly with the
large amount of work that has already gone on.
Thanks,
Dave
At 11:02 PM 1/23/00 -0800, Gregory J. Woodhouse wrote:
>I think it may be useful at this point to take stock of where we
>stand. From what I can tell, it seems to me that we all want an
>architecture which component based (which probably means object
>oriented) and language neutral. There is, however, some disagreement, or
>at least some skepticism, about how best to achieve these goals. I fear
>that our points of agreement here have a tendency to be lost as a
>result.
>
>To be clear about where I stand: I believe we need to think about
>encapsulating existing systems or components of existing systems in a
>language neutral manner, and I believe we would do well to focus on
>defining interface models rather than on the underlying technology, and
>that's one reason why I suggested we would do well to start at the UML
>level (though even here I have some doubts). But, having said that, I
>think it is equally important that our model not become a straitjacket
>that will unnecessarily constrain existing systems. We need a flexible
>model, one that leaves room for individual systems to grow and
>evolve. Now, what about CORBA? I suspect I have come across as something
>of a CORBA detractor. Such is not the case. I am still somewhat skeptical
>about CORBA, but I am hopeful! I do think object oriented technology is
>the way to go, and I do think language independence and a distributed
>architecture are important. I simply do not yet feel that I am in a
>position where I could recommend a CORBA based solution, but that means I
>still have questions, it does not mean I have rejected CORBA! In fact,
>quite the opposite is true. Experience with VistA has already shown the
>value of creating (Delphi) components which provide a software interface
>to VistA. Unfortunately, this solution is not yet technology independent,
>but as Greg Kreis has pointed out, FixIt does provide some important steps
>in this direction. I would like to see a system in which patient records
>could be stored in Fileman, Oracle, mSQL, or any a number of other
>products, but other parts of the system would not know or care what the
>underlying technology was. I would, however, want these interfaces to
>provide sufficient flexibility to allow us to use the full power of these
>applications. I've seen proposals that only work by "dumbing
>down" existing systems until we reach a least common denominator, and, in
>my view, this is simply not acceptable.
>
>---
>Gregory Woodhouse
>[EMAIL PROTECTED] / http://www.wnetc.com/home.html
>"An atheist staring from his attic window is often nearer to God than the
>believer caught up in his own false image of God."
>--Martin Buber
