[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[COAS-List] Potential Issue for the FTF

Hello COAS Team,


See the attached email thread for a potential issue for the Finalization
Task Force (FTF) that will be formed at the next OMG meeting.  The COAS
spec uses the kind of structure they talk about for the Observation Data
type (I think that is the type it was used for but don't have the spec
handy right now).  I have uncovered a few other problems with the
Observation Data type as well.  I will explain them more after the FTF
forms but here are some quick summaries:

    - It duplicates dyamic structuring functionality already
standardized within the ORB (DynAny).  This functionality was not
implemented widely (since it was fairly new) 6 months ago but I have
found it in many ORBS now.  Why should we create a COAS specific
capability that is already available inthe middleware?  It was no

    - Out of three scenerios (observations with no structure, static
structured observations, dynamic structured observations)  it
standardizes on the most expensive (dynamic structured).  This does not
allow as efficient implementation of structureless observations and it
prevents using static structured observations at all.  Using some
alternatives would have little or no effect on dynamic structured
observations.  Besides as mentioned above the ORB can deal with dynamic
structured data types via DynAny.  The current structuring capability
could still be specified as an option for those cases where DynAny is
not available or where people have already implemented the spec but not
be required.

    - It breaks interoperability in a number of ways.  To implement
statically structured observations you have to put them in the
AtomicObservation which breaks the semantics of the standard observation
structure.  As you know interoperability is not a global phenomena, it
occurs within a domain (e.g. a country or a specific healthcare
institution).  You can not use the ORBs static binding capabilites to do
compile time checking of allowed observation types within an
interoperability domain.

    - It prevents usage in certain environments.  By requiring dynamic
structuring ownly (which can be a major expense) certain applications
that could use COAS but require minimized footprint would not be able to
use it.

    - By COAS (an RM-ODP Computaional Viewpoint specification) dictating
particular rules of structuring within the IDL (ObservationData) it is
not as independent of the RM-ODP Information Viewpoint as it could be.
A particular Information Viewpoint standard (e.i. HL7 RIM and/or
Templates, or UK-NHS models or Brazil data models for Observations)
could have structuring rules that don't fit into the COAS rules.  This
would require an explicit mapping that could be costly (run time issue),
complicated (design time issue) or maybe impossible.  For example a
single atomic observation is allowed within a composite observation but
some information models might allow multiple.  First it is not clear if
they would be allowed in the COAS model but if they were you would have
to create an additional level (fake level) of composite observation to
deal with them.

I see a VERY small change in the spec that could be correct these and
still provide the functionality of the current ObservationData type.  I
will discuss this on the FTF.


Regards,

Tim Brinson

-- BEGIN included message

This issue is very old and very well-known, but I did not to see it
addressed explicitly in the latest 2.3 drafts:

Consider:

module ex {struct foo {sequence<foo> bar;};}

Suppose S is an object reference for instance of type CORBA::StructDef
representing the struct ex::foo.

What is returned on-the-wire when the value of the members attribute
for S is requested over IIOP?

Specifically, how is the type member, which is of type TypeCode, for
the StructMember corresponding to the bar member of ex::foo,
marshalled?

However this is supposed to be marshalled, I recommend an explanation
in the CDR section, since right now it sounds like recursive typecodes
not in a top-level typecode cannot be marshalled portably.

I think this issue would come up even more often with ValueDef.

-- END included message

-- BEGIN included message

Lewis Stiller wrote:
> 
> This issue is very old and very well-known, but I did not to see it
> addressed explicitly in the latest 2.3 drafts:
> 
> Consider:
> 
> module ex {struct foo {sequence<foo> bar;};}
> 
> Suppose S is an object reference for instance of type CORBA::StructDef
> representing the struct ex::foo.
> 
> What is returned on-the-wire when the value of the members attribute
> for S is requested over IIOP?
> 
> Specifically, how is the type member, which is of type TypeCode, for
> the StructMember corresponding to the bar member of ex::foo,
> marshalled?
> 
> However this is supposed to be marshalled, I recommend an explanation
> in the CDR section, since right now it sounds like recursive typecodes
> not in a top-level typecode cannot be marshalled portably.
> 
> I think this issue would come up even more often with ValueDef.

Here is how I think it can be marshalled (structurally):

(Level 1 TypeCode)
kind:		sequence
length:		0
content_type: (Level 2 TypeCode)
	kind:		struct
	id:		"IDL:ex/foo:1.0"
	name:		"foo"
	member_count:	1
	member_name[0]:	"bar";
	member_type[0]: (Level 3 TypeCode indirect to Level 1)

Now some may argue that CDR typecode indirection cannot occur here, and
should only occur directly inside a sequence (or valuetype) typecode,
but I see no such restriction in the standard.

There are also a number of less compact ways of marshalling it, by
unrolling the recursion as many times as you like.
			
-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

-- END included message

-- BEGIN included message

On Tue, 15 Jun 1999, Jonathan Biggar wrote:

> Here is how I think it can be marshalled (structurally):

I agree, and we should nail this down. For the next revision, I hope
to get rid of these silly anonymous types once and for all, so we won't
have this and many other headaches anymore...

							Cheers,

								Michi.
--
Michi Henning               +61 7 3236 1633
Triodia Technologies        +61 4 1118 2700 (mobile)
PO Box 372                  +61 7 3211 0047 (fax)
Annerley 4103               michi@triodia.com
AUSTRALIA                   http://www.triodia.com/staff/michi-henning.html

-- END included message

-- BEGIN included message

Excerpts from local.omg: 15-Jun-99 Re: GIOP encoding of IR ope.. Michi
Henning@triodia.co (598*)

> I hope
> to get rid of these silly anonymous types once and for all, so we won't
> have this and many other headaches anymore...

Hear, hear!

Bill

-- END included message

-- BEGIN included message


This brings up an related issue:
  Many vendors seem to have disagreements about what the indirection
  actually points to: does is it always indirect to a 4 byte boundry?

  The spec doesn't say anything directly other than that the indirection
  always points to the "tk_kind" value of the encoded type code (although
  there is a reference saying that the byte order of the referencecd 
  type code can be determined by the tk_kind value at that location).

  I believe the indirection should always point to a four byte boundry, but
  it is simple enough to always round up.

  Some vendors think agree, others do not (and some products perform
  differently depending on the language binding & version used - no names
  mentioned).

  Some implementations throw a MARSHAL if the indireection is rounded, some 
  throw if it is not (uh interoperability?).

  I'm sure this will become more of an issue once we start to get more OBV
  implementations, where indirections are used quite often and the spec has
  the same clarity problem.

Maybe this should be clarified...

-jeff

> 
> Lewis Stiller wrote:
> > 
> > This issue is very old and very well-known, but I did not to see it
> > addressed explicitly in the latest 2.3 drafts:
> > 
> > Consider:
> > 
> > module ex {struct foo {sequence<foo> bar;};}
> > 
> > Suppose S is an object reference for instance of type CORBA::StructDef
> > representing the struct ex::foo.
> > 
> > What is returned on-the-wire when the value of the members attribute
> > for S is requested over IIOP?
> > 
> > Specifically, how is the type member, which is of type TypeCode, for
> > the StructMember corresponding to the bar member of ex::foo,
> > marshalled?
> > 
> > However this is supposed to be marshalled, I recommend an explanation
> > in the CDR section, since right now it sounds like recursive typecodes
> > not in a top-level typecode cannot be marshalled portably.
> > 
> > I think this issue would come up even more often with ValueDef.
> 
> Here is how I think it can be marshalled (structurally):
> 
> (Level 1 TypeCode)
> kind:		sequence
> length:		0
> content_type: (Level 2 TypeCode)
> 	kind:		struct
> 	id:		"IDL:ex/foo:1.0"
> 	name:		"foo"
> 	member_count:	1
> 	member_name[0]:	"bar";
> 	member_type[0]: (Level 3 TypeCode indirect to Level 1)
> 
> Now some may argue that CDR typecode indirection cannot occur here, and
> should only occur directly inside a sequence (or valuetype) typecode,
> but I see no such restriction in the standard.
> 
> There are also a number of less compact ways of marshalling it, by
> unrolling the recursion as many times as you like.
> 			
> -- 
> Jon Biggar
> Floorboard Software
> jon@floorboard.com
> jon@biggar.org
>

-- END included message