Issue 3908: Encoding of Service Contexts in Fault Tolerant CORBA specification missing (ft-ftf)
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity: 
Summary: 13.6.7 of the CORBA 2.3 specification states: "The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that encoded representation will be encapsulated in the context_data member of IOP::ServiceContext. (See Section 15.3.3, Encapsulation, on page 15-13)."

The descriptions of service contexts in the FT spec are missing an explicit statement of the encoding of the service context data.

Proposed Resolution:

Add the following sentence in all appropriate sections: "When encoded in a request or reply message header, the <code>context_data</code> component of the <code>ServiceContext</code> struct will contain a CDR encapsulation of the xxxxxx struct."

Resolution: see below
Revised Text: Replace the first sentence of Section 27.2.7.1 on page 27-22 by 
the following two sentences:

"The FTGroupVersionServiceContext struct contains the version of the object group reference for the server object group, which allows the server to determine whether the client is using an obsolete object group reference. When encoded in a request or reply message header, the context_data component of the ServiceContext struct shall contain a CDR encapsulation of the FTGroupVersionServiceContext struct, which is defined below."
	
Replace the first sentence of Section 27.2.8.1 on page 27-24 by the following two sentences:

"The FTRequestServiceContext is used to ensure that a request is not executed more than once under fault conditions.  When encoded in a request or reply message header, the context_data component of the ServiceContext struct shall contain a CDR encapsulation of the     FTRequestServiceContext struct, which is defined below."


Actions taken:
September 25, 2000: received issue
May 24, 2001: closed issue
Discussion: 

End of Annotations:=====
X-Sender: giddiv@postel
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 25 Sep 2000 13:29:49 -0400
To: issues@omg.org
From: Victor Giddings <victor.giddings@ois.com>
Subject: Encoding of Service Contexts in Fault Tolerant CORBA
  specification missing
Cc: ft-ftf@omg.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-UIDL: B<od9XhNe9i`c!!e@,!!

Issue:

13.6.7 of the CORBA 2.3 specification states: "The context data for a
     particular service will be encoded as specified for its
     service-specific OMG IDL definition, and that encoded
     representation will be encapsulated in the context_data member of
     IOP::ServiceContext. (See Section 15.3.3, Encapsulation, on page
     15-13)."

The descriptions of service contexts in the FT spec are missing an
explicit statement of the encoding of the service context data.

Proposed Resolution:

Add the following sentence in all appropriate sections: "When encoded
in a request or reply message header, the <code>context_data</code>
component of the <code>ServiceContext</code> struct will contain a CDR
encapsulation of the xxxxxx struct."


Victor Giddings	     victor.giddings@ois.com
Senior Product Engineer	+1 703 295 6500
Objective Interface Systems    Fax: +1 703 296 6501

Date: Wed, 1 Nov 2000 20:19:18 -0800 (PST)
Message-Id: <200011020419.UAA12446@iota.ece.ucsb.edu>
X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to
moser@alpha.ece.ucsb.edu using -f
From: Louise Moser <moser@alpha.ece.ucsb.edu>
To: ft-ftf@omg.org, issues@omg.org, juergen@omg.org
Subject: Voting on Issues 3747, 3908, 3976
Reply-to: moser@ece.ucsb.edu
Content-Type: text
X-UIDL: P**!!Wa'e9"A?!!7bLe9


Hello Everyone,

Here are Issues 3747, 3908, 3976 with more precise editing
instructions.
If anyone has any refinements of the proposed resolutions, please
email
us your refinements by Friday, November 3.  Otherwise, we will
commence
voting on these issues with the polls closing on Friday, November 10.

Thanks.

Louise

=======================================================================

ISSUE 3747 YES NO ABSTAIN

The adopted draft specification defines State as a sequence<octet>.
This presents a problem when coding get_state() and set_state() for an
application whose state contains an any.  To marshal an any into a
sequence of octet, the application must contain routines comparable in
size and complexity to those of a complete ORB.  The Replication
Manager
itself contains any values and is such an application.

It has been suggested that the State be defined as an any.  The
marshalling of any is, however, inefficient in processing time and
message size.

The simplest of the proposed compromises defines State as a struct
that
contains both a sequence<octet> and an any.  This would allow a user
to transfer state using either the sequence<octet> or the any or both.

Proposed Resolution:

    Replace the definition of State in Section 27.5.4 on pages 27-84
    and
    27-85 and in Appendix A Consolidated IDL on page 27-102 by

        struct State
        {
          sequence<octet> octet_val;
          any any_val;
        };


=======================================================================

ISSUE 3908 YES NO ABSTAIN

13.6.7 of the CORBA 2.3 specification states: "The context data for a
particular service will be encoded as specified for its
service-specific
OMG IDL definition, and that encoded representation will be
encapsulated
in the context_data member of IOP::ServiceContext. (See Section
15.3.3,
Encapsulation, on page 15-13)." The descriptions of service contexts
in
the FT specification are missing an explicit statement of the encoding
of the service context data.

Proposed Resolution: 

Replace the first sentence of Section 27.2.7.1 on page 27-22 by 
the following two sentences:

     "The FTGroupVersionServiceContext struct contains the version of
     the object group reference for the server object group, which
     allows the server to determine whether the client is using an
     obsolete object group reference. When encoded in a request or
     reply
     message header, the context_data component of the ServiceContext
     struct shall contain a CDR encapsulation of the
     FTGroupVersionServiceContext struct, which is defined below."

Replace the first sentence of Section 27.2.8.1 on page 27-24 by 
the following two sentences:

     "The FTRequestServiceContext is used to ensure that a request is
     not executed more than once under fault conditions.  When encoded
     in a request or reply message header, the context_data component
     of
     the ServiceContext struct shall contain a CDR encapsulation of
     the
     FTRequestServiceContext struct, which is defined below."


=======================================================================

ISSUE 3976 YES NO ABSTAIN

Earlier this year, the Interop FTF deprecated the
LOCATION_FORWARD_PERM
exception because it was poorly specified and made implementation of
hash() difficult.  However, for Fault Tolerant CORBA, the
LOCATION_FORWARD_PERM exception is essential.

Proposed Resolution:

In Section 27.2.5, immediately before 27.2.5.1, insert the following
paragraph:

     "The first of these three options, access directly to a member of
     a
     server object group, requires the use of the
     LOCATION_FORWARD_PERM
     exception. As object replicas fail and are replaced by new
     replicas, a stage may be reached at which all of the original
     replicas, cited in the original interoperable object group
     reference for the object, are inaccessible.  Continued use of the
     original reference will cause system failure.  The
     LOCATION_FORWARD_PERM exception allows such a reference to be
     replaced by an updated reference that contains profiles for the
     new
     replacement replicas.  Thus, the LOCATION_FORWARD_PERM exception
     is
     not deprecated when it is used to return an interoperable object
     group reference.  The use of the LOCATION_FORWARD_PERM exception
     to
     return a reference that is not an interoperable object group
     reference continues to be deprecated."

In Section 27.2.6, after the first paragraph on page 27-21, insert the
following paragraph:

     "The temporal scope of the replacement reference provided by
     LOCATION_FORWARD_PERM is ORB lifetime or the next
     LOCATION_FORWARD_PERM.  It is safe, and appropriate, for an ORB
     to
     replace any reference that contains the same fault tolerance
     domain
     identifier, the same object group identifier and a smaller value
     of
     the version of the object group reference."

In Section 27.2.3.6 on page 27-18, replace "Follows the semantics
above." by

     "Follows the semantics for is_equivalent().  An interoperable
     object group reference contains an object group identifier that
     is
     unique and immutable over the lifetime of the object group.  For
     such a reference, the value of hash() shall be derived from the
     object group identifier.  For references that are not
     interoperable
     object group references, the value of hash() continues to be
     derived as at present."



Sender: Chris.Smith@uab.ericsson.se
Message-ID: <3A0174A3.9A6749E7@uab.ericsson.se>
Date: Thu, 02 Nov 2000 15:05:23 +0100
From: Chris Smith <uabcsru@uab.ericsson.se>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: moser@ece.ucsb.edu
CC: ft-ftf@omg.org, juergen@omg.org
Subject: Re: Voting on Issues 3747, 3908, 3976
References: <200011020419.UAA12446@iota.ece.ucsb.edu>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: Pp<!!l*P!!'_ed9OG5e9

Sorry to come into the discussion late on this one.

This proposal seems to me to provide the worst of 
both worlds.

When receiving a "State", an application must look at
the any and sequence to know what to extract. How
will an application know which is the one to use.
If the sequence of octet has 0 length, is it empty
state or not used? How will he know if the any is 
empty? Therefore he must understand the any, (and
therefore have all the code for understanding 
anys).

One could claim that an application "knows" what it 
will be sent, but in that case, interoperability 
is no problem, and this struct isnt needed to be
defined at OMG.

I think either we stick with sequence of octet and
burden applications with streaming, or we go for
an any (which could contain a sequence of octet)
and burden the deployment environment which having
to have any-enabled code.


> ISSUE 3747 YES NO ABSTAIN
> 
> The adopted draft specification defines State as a sequence<octet>.
> This presents a problem when coding get_state() and set_state() for
> an
> application whose state contains an any.  To marshal an any into a
> sequence of octet, the application must contain routines comparable
> in
> size and complexity to those of a complete ORB.  The Replication
> Manager
> itself contains any values and is such an application.
> 
> It has been suggested that the State be defined as an any.  The
> marshalling of any is, however, inefficient in processing time and
> message size.
> 
> The simplest of the proposed compromises defines State as a struct
> that
> contains both a sequence<octet> and an any.  This would allow a user
> to transfer state using either the sequence<octet> or the any or
> both.
> 
> Proposed Resolution:
> 
>     Replace the definition of State in Section 27.5.4 on pages 27-84
> and
>     27-85 and in Appendix A Consolidated IDL on page 27-102 by
> 
>         struct State
>         {
>           sequence<octet> octet_val;
>           any any_val;
>         };
> 
> =======================================================================
> 
> ISSUE 3908 YES NO ABSTAIN
> 
> 13.6.7 of the CORBA 2.3 specification states: "The context data for
> a
> particular service will be encoded as specified for its
> service-specific
> OMG IDL definition, and that encoded representation will be
> encapsulated
> in the context_data member of IOP::ServiceContext. (See Section
> 15.3.3,
> Encapsulation, on page 15-13)." The descriptions of service contexts
> in
> the FT specification are missing an explicit statement of the
> encoding
> of the service context data.
> 
> Proposed Resolution:
> 
> Replace the first sentence of Section 27.2.7.1 on page 27-22 by
> the following two sentences:
> 
>      "The FTGroupVersionServiceContext struct contains the version
> of
>      the object group reference for the server object group, which
>      allows the server to determine whether the client is using an
>      obsolete object group reference. When encoded in a request or
> reply
>      message header, the context_data component of the
> ServiceContext
>      struct shall contain a CDR encapsulation of the
>      FTGroupVersionServiceContext struct, which is defined below."
> 
> Replace the first sentence of Section 27.2.8.1 on page 27-24 by
> the following two sentences:
> 
>      "The FTRequestServiceContext is used to ensure that a request
> is
>      not executed more than once under fault conditions.  When
> encoded
>      in a request or reply message header, the context_data
> component of
>      the ServiceContext struct shall contain a CDR encapsulation of
> the
>      FTRequestServiceContext struct, which is defined below."
> 
> =======================================================================
> 
> ISSUE 3976 YES NO ABSTAIN
> 
> Earlier this year, the Interop FTF deprecated the
> LOCATION_FORWARD_PERM
> exception because it was poorly specified and made implementation of
> hash() difficult.  However, for Fault Tolerant CORBA, the
> LOCATION_FORWARD_PERM exception is essential.
> 
> Proposed Resolution:
> 
> In Section 27.2.5, immediately before 27.2.5.1, insert the following
> paragraph:
> 
>      "The first of these three options, access directly to a member
> of a
>      server object group, requires the use of the
> LOCATION_FORWARD_PERM
>      exception. As object replicas fail and are replaced by new
>      replicas, a stage may be reached at which all of the original
>      replicas, cited in the original interoperable object group
>      reference for the object, are inaccessible.  Continued use of
> the
>      original reference will cause system failure.  The
>      LOCATION_FORWARD_PERM exception allows such a reference to be
>      replaced by an updated reference that contains profiles for the
> new
>      replacement replicas.  Thus, the LOCATION_FORWARD_PERM
> exception is
>      not deprecated when it is used to return an interoperable
> object
>      group reference.  The use of the LOCATION_FORWARD_PERM
> exception to
>      return a reference that is not an interoperable object group
>      reference continues to be deprecated."
> 
> In Section 27.2.6, after the first paragraph on page 27-21, insert
> the
> following paragraph:
> 
>      "The temporal scope of the replacement reference provided by
>      LOCATION_FORWARD_PERM is ORB lifetime or the next
>      LOCATION_FORWARD_PERM.  It is safe, and appropriate, for an ORB
> to
>      replace any reference that contains the same fault tolerance
> domain
>      identifier, the same object group identifier and a smaller
> value of
>      the version of the object group reference."
> 
> In Section 27.2.3.6 on page 27-18, replace "Follows the semantics
> above." by
> 
>      "Follows the semantics for is_equivalent().  An interoperable
>      object group reference contains an object group identifier that
> is
>      unique and immutable over the lifetime of the object group.
> For
>      such a reference, the value of hash() shall be derived from the
>      object group identifier.  For references that are not
> interoperable
>      object group references, the value of hash() continues to be
>      derived as at present."




From: "Rutt, T E (Tom)" <terutt@lucent.com>
To: moser@ece.ucsb.edu, "'Jishnu Mukerji'" <jis@fpk.hp.com>
Cc: ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org
Subject: RE: Voting on Issues 3747, 3908, 3976
Date: Thu, 2 Nov 2000 13:06:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	      charset="iso-8859-1"
X-UIDL: :O%!!P&+e9!&%"!-ccd9

Does this solution address how the Client application is made aware
that an
old reference
It has must be replaced?

Tom rutt
ter

	----------
	From:  Jishnu Mukerji [SMTP:jis@fpk.hp.com]
	Sent:  Thursday, November 02, 2000 11:17 AM
	To:  moser@ece.ucsb.edu
	Cc:  ft-ftf@omg.org; orb_revision@omg.org; interop@omg.org
	Subject:  Re: Voting on Issues 3747, 3908, 3976

	Louise Moser wrote:
	> 
	> Hello Everyone,
	> 
	> Here are Issues 3747, 3908, 3976 with more precise editing
instructions.
	> If anyone has any refinements of the proposed resolutions,
	please
email
	> us your refinements by Friday, November 3.  Otherwise, we
	will
commence
	> voting on these issues with the polls closing on Friday,
	November
10.
	> 
	> Thanks.
	> 
	> Louise
	> 
	>
=======================================================================
	> 

	. . . . . . .

	> 
	> ISSUE 3976 YES NO ABSTAIN
	> 
	> Earlier this year, the Interop FTF deprecated the
LOCATION_FORWARD_PERM
	> exception because it was poorly specified and made
	> implementation
of
	> hash() difficult.  However, for Fault Tolerant CORBA, the
	> LOCATION_FORWARD_PERM exception is essential.
	> 
	> Proposed Resolution:
	> 
	> In Section 27.2.5, immediately before 27.2.5.1, insert the
following
	> paragraph:
	> 
	>      "The first of these three options, access directly to a
member of a
       >      server object group, requires the use of the
LOCATION_FORWARD_PERM
	>      exception. As object replicas fail and are replaced by
	> new
	>      replicas, a stage may be reached at which all of the
	> original
	>      replicas, cited in the original interoperable object
	> group
	>      reference for the object, are inaccessible.  Continued
	> use of
the
	>      original reference will cause system failure.  The
	>      LOCATION_FORWARD_PERM exception allows such a reference
	> to be
	>      replaced by an updated reference that contains profiles
	> for
the new
    >      replacement replicas.  Thus, the LOCATION_FORWARD_PERM
exception is
	  >      not deprecated when it is used to return an
	> interoperable
object
	>      group reference.  The use of the LOCATION_FORWARD_PERM
exception to
	  >      return a reference that is not an interoperable
	> object group
	>      reference continues to be deprecated."
	> 
	> In Section 27.2.6, after the first paragraph on page 27-21,
	> insert
the
	> following paragraph:
	> 
	>      "The temporal scope of the replacement reference
	> provided by
	>      LOCATION_FORWARD_PERM is ORB lifetime or the next
	>      LOCATION_FORWARD_PERM.  It is safe, and appropriate,
	> for an
ORB to
    >      replace any reference that contains the same fault
	> tolerance
domain
	>      identifier, the same object group identifier and a
	> smaller
value of
      >      the version of the object group reference."
      > 
      > In Section 27.2.3.6 on page 27-18, replace "Follows the
	> semantics
	> above." by
	> 
	>      "Follows the semantics for is_equivalent().  An
	> interoperable
	>      object group reference contains an object group
	> identifier
that is
     >      unique and immutable over the lifetime of the object
	> group.
For
	>      such a reference, the value of hash() shall be derived
	> from
the
	>      object group identifier.  For references that are not
interoperable
	>      object group references, the value of hash() continues
	> to be
	>      derived as at present."

	Louise,

	In addition to changes in Chapter 27, these modifications also
	need
to
	be reflected in Chapters 4 and 15 (I think). The best way to
	handle
this
	is for you to propose additions to these chapters based on the
	draft
	CORBA Core 2.4 as it appears in orbrev/00-09-01, and then have
	the
Core
	RTF and the Interop RTF review them before they are approved
	for
	inclusion in those chapters. So as a starter please propose
	these
	additions to the existing Core chapter to the FT FTF and get
	them
	approved there and then send them over to the Core and Interop
	RTFs
for
	final action, just to help us all maintain our editorial
	sanity.:-)

	Thanks,

	Jishnu.
	-- 
	Jishnu Mukerji
	Senior Systems Architect, EIAL
	Hewlett-Packard Company 
	300 Campus Drive, MS 2E-62
	Florham Park NJ 07932, USA
	+1 973 443 7528
	jis@fpk.hp.com

Date: Thu, 2 Nov 2000 14:26:21 -0800 (PST)
Message-Id: <200011022226.OAA13009@iota.ece.ucsb.edu>
X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to
moser@alpha.ece.ucsb.edu using -f
From: Louise Moser <moser@alpha.ece.ucsb.edu>
To: jis@fpk.hp.com
In-reply-to: <3A01937B.A096BF6E@fpk.hp.com> (message from Jishnu
Mukerji on
	Thu, 02 Nov 2000 11:16:59 -0500)
Subject: Re: Voting on Issues 3747, 3908, 3976
Reply-to: moser@ece.ucsb.edu
Cc: ft-ftf@omg.org
Content-Type: text
X-UIDL: nP/!!?,gd9TCcd9c;Sd9


Jishnu,

Thanks for your feedback.

>inclusion in those chapters. So as a starter please propose these
>additions to the existing Core chapter to the FT FTF and get them
>approved there and then send them over to the Core and Interop RTFs
>for
>final action, just to help us all maintain our editorial sanity.:-)

I will try to get a proposal together on the existing Core Chapters
by tomorrow.

Thanks.

Louise