Re: [Fwd: [COAS-List] Potential Issue for the FTF]

[Tim Brinson <TBrinson@mindspring.com>]

David Forslund wrote:

> We need to sit down and work out the example structures that COAS would
> support with this model.

Agreed!  I think there would be just a few (<6) simple cases in order to cover
the most important cases (using the 80/20 rule).  These would be some subset
of (but not all permutations):

    Atomic vs. Composite;
    Qualifiers or not;
    Relations or not;
    Card coded PersonId or not;
    Card coded TimeSpan or not.

Dave, I don't understand the concern about changing the Information Model for
COAS.  Nothing I am proposing is suggesting that.  It is just freeing up how
that Information Model gets mapped into the IDL so we can take advantage of
other capabilites in the future and other benefits right now.

As I was talking with Tom just before I left the CORBAmed meeting there are a
number of reasons that other structures might be wanted in the future or
within certain environements.

As I undersatand it there is a general RM-ODP belief that you decouple the
various viewpoints.  For example the Computational Viewpoint (i.e. services or
business logic) and the Engineering Viewpoint (i.e. middleware) should be as
independent as possible of each other.  Using IDL we have a language to
describe our services that can be mapped to a number of middleware
technologies (not just CORBA but also DCOM, DCE, RMI, etc.).  Within a certain
environment the middleware will be chose to implement the service.

In a similar way the Computational Viewpoint and Information Viewpoint should
be as independent of each other as possible.  In both PIDS and to a large
extent COAS we have worked to make this happen.  In PIDS this was only needed
for Traits since that was the only business data we dealt with.  In COAS the
business data shows up as both ObservationValues and as ObservationData (the
structures).  ObservationValues are defined in the most generic and flexible
way (as an any) so they are independent of the InformationViewpoint.

That doesn't mean we loose interoperability though - we just manage it in a
different way as opposed of putting it in the static IDL types that get bound
to the operations.  We do define a small set of specific ObservationValue
types so we can have interoperability (but it is still open for future
expansion and changes or for extensions by other people).  This does cause
dynamic binding for interoperability as opposed to static binding.  The
benefit is the flexibility.  If a particular new observation value is needed
by someone they can create it.  If we want to standardize on some additional
observation values in the future we can.  If a future RFP decides to redefine
some of the observation values to use objects by value it can - and the same
service could support both of them with no IDL changes to the interface.

By ObservationData in COAS being defined as a static structure that is bound
to all operations it limits future extensions and changes of the IDL data
types that can be used to carry the same information.  For example the self
referential structure we defined has some problems in IIOP and if it was not
statically bound to the operations we could correct the IDL for the data type
and it would not change the service specification.  Another example is if
Objects by Value gets popular in the next couple years and you want to pass
observations with them you will have to create new IDL.  Someone supporting
the new and the old will have to have two service specifications since the
interfaces are different.

The ORBOS just issued an RFP for mapping XML to IDL (specifically the desire
is to Value Types).  By hardcoding the generic structure of ObservationData
within our IDL we may not be able to benefit directly from these middleware
advances when  HL7 XML Templates are mapped into IDL.


Cheers,

Tim