Issue 3747: define the State as typedef any State (ft-ftf) Source: Eternal Systems (Dr. Louise E. Moser, moser@eternal-systems.com) Nature: Uncategorized Issue Severity: Summary: The Fault Tolerant CORBA specification defines the State used by the get_state(), set_state(), get_update(), set_update() methods, as typedef sequence<octet> State Those methods must be implemented by the application programmers. They will find their task easier if we define the State as: typedef any State Resolution: rejected Revised Text: 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: any State; Actions taken: July 18, 2000: received issue May 24, 2001: closed sse, Discussion: End of Annotations:===== Date: Mon, 17 Jul 2000 17:33:55 -0700 (PDT) Message-Id: <200007180033.RAA12513@chi.ece.ucsb.edu> X-Authentication-Warning: chi.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: ft-ftf@omg.org, juergen@omg.org Subject: Fault Tolerant CORBA FTF Issue Reply-to: moser@ece.ucsb.edu Cc: moser@apex.ece.ucsb.edu Content-Type: text X-UIDL: YQ/e9@EXd95:=e9I9(e9 Hello, The Fault Tolerant CORBA specification defines the State used by the get_state(), set_state(), get_update(), set_update() methods, as typedef sequence State Those methods must be implemented by the application programmers. They will find their task easier if we define the State as: typedef any State Thank you. Louise Moser X-Sender: giddiv@gamma X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 15:23:55 -0400 To: moser@ece.ucsb.edu, ft-ftf@omg.org, juergen@omg.org From: Victor Giddings Subject: Re: Fault Tolerant CORBA FTF Issue Cc: moser@apex.ece.ucsb.edu In-Reply-To: <200007180033.RAA12513@chi.ece.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: Vb!"!#U\d9aWD!!QLE!! At 05:33 PM 7/17/00 -0700, Louise Moser wrote: >Hello, > >The Fault Tolerant CORBA specification defines the State used by the >get_state(), set_state(), get_update(), set_update() methods, as > > typedef sequence State > >Those methods must be implemented by the application programmers. >They will find their task easier if we define the State as: > > typedef any State > >Thank you. > >Louise Moser This isn't immediately obvious to me. I assume the advantage is the self description of type Any. However, a number of languages have streaming facilities that ease conversion from CORBA. types to an undifferentiated sequence of bytes. Type Any also has a number of disadvantages: 1) The entire (well recoverable at least) state of an object would have to stored in a single contiguous structure. This is not necessarily natural. Separate variable could be covered by a streaming interface. 2) The elements of a state could only be those expressible in IDL. Most languages have useful types and other facilities that are not covered well by IDL. 3) The storage requirements for the TypeCode part of an Any often exceeds the data part. Victor Giddings victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 296 6501 Sender: Chris.Smith@uab.ericsson.se Message-ID: <3975810D.6CEB2E97@uab.ericsson.se> Date: Wed, 19 Jul 2000 12:21:01 +0200 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: Victor Giddings CC: moser@ece.ucsb.edu, ft-ftf@omg.org, juergen@omg.org, moser@apex.ece.ucsb.edu Subject: Re: Fault Tolerant CORBA FTF Issue References: <4.3.2.7.2.20000718151346.01c4bdc0@gamma> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0Iad9*H > At 05:33 PM 7/17/00 -0700, Louise Moser wrote: > > >Hello, > > > >The Fault Tolerant CORBA specification defines the State used by the > >get_state(), set_state(), get_update(), set_update() methods, as > > > > typedef sequence State > > > >Those methods must be implemented by the application programmers. > >They will find their task easier if we define the State as: > > > > typedef any State > > > >Thank you. > > > >Louise Moser > > This isn't immediately obvious to me. I assume the advantage is the self description of type Any. > > However, a number of languages have streaming facilities that ease conversion from CORBA. types to an undifferentiated sequence of bytes. Type Any also has a number of disadvantages: > > 1) The entire (well recoverable at least) state of an object would have to stored in a single contiguous structure. This is not necessarily natural. Separate variable could be covered by a streaming interface. > > 2) The elements of a state could only be those expressible in IDL. Most languages have useful types and other facilities that are not covered well by IDL. > > 3) The storage requirements for the TypeCode part of an Any often exceeds the data part. > > Victor Giddings victor.giddings@ois.com > Senior Product Engineer +1 703 295 6500 > Objective Interface Systems Fax: +1 703 296 6501 Date: Fri, 21 Jul 2000 10:07:15 -0700 (PDT) Message-Id: <200007211707.KAA16148@chi.ece.ucsb.edu> X-Authentication-Warning: chi.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: victor.giddings@ois.com, ft-ftf@omg.org, juergen@omg.org In-reply-to: <4.3.2.7.2.20000718151346.01c4bdc0@gamma> (message from Victor Giddings on Tue, 18 Jul 2000 15:23:55 -0400) Subject: Re: Fault Tolerant CORBA FTF Issue Reply-to: moser@ece.ucsb.edu Cc: moser@apex.ece.ucsb.edu Content-Type: text X-UIDL: dV$e9+3P!!~m)e9VEh!! Victor, In the course of implementing the specification and talking to potential customers, it has become apparent that it is preferable to define the State as an any, rather than as a sequence. If the State were defined as a sequence, the application programmer would have to provide his own routines for marshalling and unmarshalling and for maintaining identification information as part of the sequence, something that your customers and ours would be reluctant to undertake. These customers would prefer to use the functionality that CORBA already provides. Defining the State as an any does not preclude a user's generating and transmitting the State as a sequence, preceded by the sequence typecode. >1) The entire (well recoverable at least) state of an object would have >to stored in a single contiguous structure. This is not necessarily >natural. Separate variable could be covered by a streaming >interface. The specification defines the State to be a single contiguous structure. Regardless of whether any or sequence is used, the State could refer to some external structure, such as might be provided by a streaming interface or a data file. >2) The elements of a state could only be those expressible in IDL. Most >languages have useful types and other facilities that are not >covered >well by IDL. Using the any does not preclude the transmission of non-IDL types within the State (as you suggest). Such types could always be bundled into a sequence and could be inserted into a CORBA any. If the state must be a sequence, the users loose the useful ability to have the underlying CORBA system marshal and typecode the data. >3) The storage requirements for the TypeCode part of an Any often >exceeds the data part. Use of the CORBA any marshaling has an associated typecode overhead. If you prefer to marshal the data yourself as a sequence, so as to minimize the overhead, a trivial overhead, just a sequence typecode, turns the sequence into an any. Thanks. Louise X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Sep 2000 16:08:35 -0400 To: ft-ftf@omg.org From: Victor Giddings Subject: issue 3747 (was: Re: Fault Tolerant CORBA FTF Issue) In-Reply-To: <200007211707.KAA16148@chi.ece.ucsb.edu> References: <4.3.2.7.2.20000718151346.01c4bdc0@gamma> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_706675445==_.ALT" X-UIDL: fE3e9E1Pe9L8Q!!S"8e9 During the meeting in Burlingame, a "hybrid option" was discussed that would allow the user to pass his state as either a sequence of octets or an Any. In order to solidify this proposal, I will provide new IDL below intended to replace the Checkpointable and Updateable interfaces in 27(!!).5.4. I'm sure there are better names and such, but hope this clarifies things enough to decide whether to proceed. If the group is generally in favor of this approach, the supporting material can be fleshed out later. module FT { typedef sequence StreamedState; typedef any SelfDescribingState; exception NoStateAvailable {}; exception InvalidState {}; exception NoUpdateAvailable {}; exception InvalidUpdate {}; interface Checkpointable {}; interface Updateable : Checkpointable {}; interface StreamingCheckpointable : Checkpointable { StreamedState get_state() raises (NoStateAvailable); void set_state(in StreamedState s) raises(InvalidState); }; interface StreamingUpdateable : Updateable { StreamedState get_update() raises(NoUpdateAvailable); void set_update(in StreamedState s) raises(InvalidUpdate); }; interface SelfDescribingCheckpointable : Checkpointable { SelfDescribingState get_state() raises (NoStateAvailable); void set_state(in SelfDescribingState s) raises(InvalidState); }; interface SelfDescribingUpdateable : Updateable { SelfDescribingState get_update() raises(NoUpdateAvailable); void set_update(in SelfDescribingState s) raises(InvalidUpdate); }; }; Victor Giddings victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 296 6501 Date: Tue, 17 Oct 2000 19:59:14 -0700 (PDT) Message-Id: <200010180259.TAA23294@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 To: ft-ftf@omg.org, issues@omg.org, juergen@omg.org Subject: Issue 3747 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: ;?^!!\pn!!"_Ce9NEn!! Hello, Here is an alternative proposal for checkpointing and updating that supports state transfer using either sequence of octet or any. This might be preferable, if the state of an object involves some any's (so that those any's do not have to be marshalled into a sequence of octet) and some other types that can be marshalled more easily into a sequence of octet. It would avoid the need for the object to inherit from two (four) interfaces, as in the previous proposal for checkpointing and updating that supports both sequence of octet and any. Louise ======================================================================= typedef sequence OctetState; typedef any AnyState; exception NoStateAvailable {}; exception InvalidState {}; exception NoUpdateAvailable {}; exception InvalidUpdate {}; interface Checkpointable { OctetState get_octet_state() raises (NoStateAvailable); void set_octet_state(in OctetState s) raises(InvalidState); AnyState get_any_state() raises(NoStateAvailable); void set_any_state(in AnyState s) raises(InvalidState); }; interface Updateable { OctetState get_octet_update() raises(NoUpdateAvailable); void set_octet_update(in OctetState s) raises(InvalidUpdate); AnyState get_any_update() raises(NoUpdateAvailable); void set_any_update(in AnyState s) raises(InvalidUpdate); }; Date: Wed, 18 Oct 2000 20:05:36 -0700 (PDT) Message-Id: <200010190305.UAA24380@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 To: ft-ftf@omg.org, issues@omg.org, juergen@omg.org Subject: Issue 3747 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: n6A!!j8f!!RFZ!!dM@!! Hello, Here is another alternative proposal for checkpointing and updating that supports state transfer using either sequence of octet or any. This proposal requires changing only the definition of State in the current specification and is therefore (I think) preferable to the preceding proposals. Thanks. Louise ======================================================================= struct State { sequence octetVal; any anyVal; }; exception NoStateAvailable {}; exception InvalidState {}; exception NoUpdateAvailable {}; exception InvalidUpdate {}; interface Checkpointable { State getstate() raises (NoStateAvailable); void setstate(in State s) raises(InvalidState); }; interface Updateable { State getupdate() raises(NoUpdateAvailable); void set_update(in State s) raises(InvalidUpdate); }; 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 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. 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 and an any. This would allow a user to transfer state using either the sequence 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_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 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 ISSUE 3747 YES NO ABSTAIN > > The adopted draft specification defines State as a sequence. > 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 and an any. This would allow a user > to transfer state using either the sequence 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_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." Date: Thu, 02 Nov 2000 11:16:59 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 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 References: <200011020419.UAA12446@iota.ece.ucsb.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :Ufd9_bo!!#]U!!?<-!! 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 From: "Rutt, T E (Tom)" To: moser@ece.ucsb.edu, "'Jishnu Mukerji'" 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:03:38 -0800 (PST) Message-Id: <200011022203.OAA12976@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 To: uabcsru@uab.ericsson.se In-reply-to: <3A0174A3.9A6749E7@uab.ericsson.se> (message from Chris Smith on Thu, 02 Nov 2000 15:05:23 +0100) Subject: Re: Issue 3747 Reply-to: moser@ece.ucsb.edu CC: ft-ftf@omg.org, juergen@omg.org Content-Type: text X-UIDL: cONe9bDWhen 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. Yes, the application "knows" what to expect, but the get_state() and set_state() methods are invoked by the fault tolerance infrastructure and consequently must be defined. >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. Our choices are: (1) sequence State (2) any State (3) combination of sequence and any (a) two interfaces: interface that provides two methods to transfer sequence interface that provides two methods to transfer any (b) single interface that provides two methods to transfer sequence and two methods to transfer any (c) single interface that provides two methods that transfer both sequence and any The advantage of (1) is efficiency. The disadvantage of (1) is that other parts of the Fault Tolerant CORBA specification do not work. We would need to redefine the properties and the criteria so that they are not expressed in terms of any. The advantage of (2) is generality and conceptual simplicity. The disadvantage of (2) is that any is inefficient in processing and in message size. The advantage of (3a) is that either sequence or any can be used, as appropriate. The disadvantage of (3a) is a more complex specification and the infrastructure needs to check which interface an object implements before it can invoke the appropriate state transfer method. The advantage of (3b) is that either sequence or any can be used, as appropriate. The disadvantage of (3b) is that an implementation must implement methods for sequence and methods for any, and the infrastructure must invoke both. The advantage of (3c) is that either sequence or any can be used, as appropriate. Further, the specification is kept simpler and no additional methods are required. The disadvantage of (3c) is that the application must "know" which of sequence or any or both to use. Perhaps the best way to proceed is to take a straw vote on these five alternatives, before we define a precise change to the specification and take a formal vote on that change. These various alternatives have been discussed in prior email messages and/or at the FTFTF meeting in Burlingame. If anyone has further comments on these five alternatives, please send email to the FTFTF. Thanks. Louise Date: Thu, 2 Nov 2000 14:23:10 -0800 (PST) Message-Id: <200011022223.OAA13003@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 To: ft-ftf@omg.org, juergen@omg.org Subject: Straw Vote on Issue 3747 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: o7"e9\<"e9f6Vd9MDod9 Hello, We will take a straw vote on the possible resolutions of Issue 3747. Please rank the following in order of preference (first, second, third, fourth, fifth) with first being your preferred choice. Please email your preferences to the FTFTF by Wednesday, November 8. (1) sequence State (2) any State (3a) two interfaces: interface that provides two methods to transfer sequence interface that provides two methods to transfer any (3b) single interface that provides two methods to transfer sequence and two methods to transfer any (3c) single interface that provides two methods that transfer both sequence and any Thanks. Louise 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 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 Date: Fri, 3 Nov 2000 09:45:14 +1000 (EST) From: Michi Henning To: moser@ece.ucsb.edu cc: ft-ftf@omg.org Subject: Re: Issue 3747 In-Reply-To: <200011022203.OAA12976@iota.ece.ucsb.edu> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "*1!!*'cd9Zg\!!nY)!! On Thu, 2 Nov 2000, Louise Moser wrote: > (2) any State To me, this seems the cleanest option. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: Chris.Smith@uab.ericsson.se Message-ID: <3A026DFD.DA9182B6@uab.ericsson.se> Date: Fri, 03 Nov 2000 08:49:17 +0100 From: Chris Smith 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: Issue 3747 References: <200011022203.OAA12976@iota.ece.ucsb.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: BhG!!!-Ie9,8,!!GTW!! Good analysis. My opinion is that 1) Good for efficiency (and deployment in restricted footprint environments). Makes applicatios more complicated. 2) Good for ease of use, bad for footprint. 3a) Difficult to manage (does an application implement just one of the two interfaces?, etc.) 3b) Nothing gained - the application still has to implement both "mechanisms" 3c) Nothing gained - the application still has to implement both "mechansism" For me, the "compromise" solutions are bad. We should go for 1 or 2. I could live with either. Louise Moser wrote: > > Hi Chris, > > Thanks for your valuable feedback. > > >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. > > Yes, the application "knows" what to expect, but > the get_state() and set_state() methods are invoked > by the fault tolerance infrastructure and consequently > must be defined. > > >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. > > Our choices are: > > (1) sequence State > > (2) any State > > (3) combination of sequence and any > > (a) two interfaces: > interface that provides two methods to transfer sequence > interface that provides two methods to transfer any > > (b) single interface that provides > two methods to transfer sequence and > two methods to transfer any > > (c) single interface that provides two methods > that transfer both sequence and any > > The advantage of (1) is efficiency. > The disadvantage of (1) is that other parts of the Fault Tolerant > CORBA specification do not work. We would need to redefine > the properties and the criteria so that they are not expressed > in terms of any. > > The advantage of (2) is generality and conceptual simplicity. > The disadvantage of (2) is that any is inefficient in processing > and in message size. > > The advantage of (3a) is that either sequence or any can > be used, as appropriate. > The disadvantage of (3a) is a more complex specification and the > infrastructure needs to check which interface an object implements > before it can invoke the appropriate state transfer method. > > The advantage of (3b) is that either sequence or any can > be used, as appropriate. > The disadvantage of (3b) is that an implementation must implement > methods for sequence and methods for any, and the infrastructure > must invoke both. > > The advantage of (3c) is that either sequence or any can > be used, as appropriate. Further, the specification is kept simpler > and no additional methods are required. > The disadvantage of (3c) is that the application must "know" > which of sequence or any or both to use. > > Perhaps the best way to proceed is to take a straw vote on > these five alternatives, before we define a precise change > to the specification and take a formal vote on that change. > > These various alternatives have been discussed in prior > email messages and/or at the FTFTF meeting in Burlingame. > If anyone has further comments on these five alternatives, > please send email to the FTFTF. > > Thanks. > > Louise Reply-To: From: "Nick Sharman" To: , Subject: RE: Straw Vote on Issue 3747 Date: Fri, 3 Nov 2000 10:46:35 -0000 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200011022223.OAA13003@iota.ece.ucsb.edu> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: `_^d9^nbd9lOn!!"X4e9 If I were implementing CORBA FT, I would prefer single form of state, i.e. (1) or (2). The problem with (2) is that possibly bulky TypeCodes have to be transmitted and persisted, and the Logging/Recovery process has to 'walk' the TypeCodes just to receive and send state. The perceived problem with (1) is that it places a serialization overhead on the checkpointable/updatable applications. I assume that's a design/coding problem - after all, the state has to be serialized before sending to the logger. However, that problem goes away if the ORB supports the Codec interface introduced in the Portable Interceptors spec. Of course, the Codec interface is expressed in terms of Anys, but 'smart' implementations of Any (e.g. IDL/Java's use of Streamables) means that the serialization can take advantage of local knowledge of the type. The TypeCode need not be part of the serialized data. Also, the resulting octet sequence is an encapsulation, so at a stroke we have catered for replicas on machines with different endianness. So my vote (if I had one :-) would be for (1). Regards Nick --------------------------------- Nick Sharman Architect, LiveContent BROKER Critical Path UK Tel: +44 (0) 161 333 4073 UK Fax: +44 (0) 161 333 4001 E-mail: mailto:nick.sharman@cp.net Web: http://www.cp.net > -----Original Message----- > From: Louise Moser [mailto:moser@alpha.ece.ucsb.edu] > Sent: Thursday, November 02, 2000 10:23 PM > To: ft-ftf@omg.org; juergen@omg.org > Subject: Straw Vote on Issue 3747 > > > > Hello, > > We will take a straw vote on the possible resolutions of Issue 3747. > Please rank the following in order of preference (first, second, third, > fourth, fifth) with first being your preferred choice. Please email your > preferences to the FTFTF by Wednesday, November 8. > > (1) sequence State > > (2) any State > > (3a) two interfaces: > interface that provides two methods to transfer sequence > interface that provides two methods to transfer any > > (3b) single interface that provides > two methods to transfer sequence and > two methods to transfer any > > (3c) single interface that provides two methods > that transfer both sequence and any > > Thanks. > > Louise > Sender: shalini@research.bell-labs.com Message-ID: <3A0326B4.3C8F21E@research.bell-labs.com> Date: Fri, 03 Nov 2000 15:57:24 -0500 From: Shalini Yajnik Organization: Lucent / Bell Labs, USA X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: moser@ece.ucsb.edu CC: ft-ftf@omg.org, juergen@omg.org Subject: Re: Straw Vote on Issue 3747 References: <200011022223.OAA13003@iota.ece.ucsb.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?o;!!5%!!![p9!!gM7e9 Louise, I am ok with either option (1) or (2). I dont think the hybrid options are a good idea.. Thanks, Shalini Louise Moser wrote: > > Hello, > > We will take a straw vote on the possible resolutions of Issue 3747. > Please rank the following in order of preference (first, second, third, > fourth, fifth) with first being your preferred choice. Please email your > preferences to the FTFTF by Wednesday, November 8. > > (1) sequence State > > (2) any State > > (3a) two interfaces: > interface that provides two methods to transfer sequence > interface that provides two methods to transfer any > > (3b) single interface that provides > two methods to transfer sequence and > two methods to transfer any > > (3c) single interface that provides two methods > that transfer both sequence and any > > Thanks. > > Louise -- ____________________________________________________________ Shalini Yajnik, Rm # 2B-441 Ph: (908) 582-2589 Lucent Tech, Bell Labs Fax: (908) 582-5809 700 Mountain Ave. Murray Hill, NJ 07974 Email:shalini@research.bell-labs.com _____________________________________________________________ Date: Fri, 3 Nov 2000 14:18:01 -0800 (PST) From: Anita Jindal Reply-To: Anita Jindal Subject: Re: Straw Vote on Issue 3747 To: ft-ftf@omg.org, juergen@omg.org, moser@ece.ucsb.edu Cc: Anita.Jindal@eng.sun.com MIME-Version: 1.0 Content-MD5: 6FQvctvUwFjNFMl2gldLjg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: Fgid9!KBe9V$pd9Y/@!! My preferences: (1) any State: simplicity and consistency with other parts of FT spec. (2) sequence State: efficiency seems to be the motive, but there will be overhead related conversion to/from seq to Anys. (3) single interface that provides two methods to transfer sequence and two methods to transfer any (4) two interfaces: interface that provides two methods to transfer sequence interface that provides two methods to transfer any (5) single interface that provides two methods that transfer both sequence and any - Anita > X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f > To: ft-ftf@omg.org, juergen@omg.org > Subject: Straw Vote on Issue 3747 > > > Hello, > > We will take a straw vote on the possible resolutions of Issue 3747. > Please rank the following in order of preference (first, second, third, > fourth, fifth) with first being your preferred choice. Please email your > preferences to the FTFTF by Wednesday, November 8. > > (1) sequence State > > (2) any State > > (3a) two interfaces: > interface that provides two methods to transfer sequence > interface that provides two methods to transfer any > > (3b) single interface that provides > two methods to transfer sequence and > two methods to transfer any > > (3c) single interface that provides two methods > that transfer both sequence and any > > Thanks. > > Louise Date: Fri, 3 Nov 2000 15:14:48 -0800 (PST) Message-Id: <200011032314.PAA13714@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 To: ft-ftf@omg.org, juergen@omg.org Subject: Re: Straw Vote on Issue 3747 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: ~fkd9S^Ge9a?K!!~RLe9 Eternal Systems' straw vote: First: any State Second: single interface that provides two methods that transfer both sequence and any Third: two interfaces: interface that provides two methods to transfer sequence interface that provides two methods to transfer any Fourth: single interface that provides two methods to transfer sequence and two methods to transfer any Fifth: sequence State -- Louise Reply-To: From: "Eric Newcomer" To: , Subject: RE: Straw Vote on Issue 3747 Date: Wed, 8 Nov 2000 13:33:22 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200011071935.LAA05560@iota.ece.ucsb.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: mL'!!&CN!!id6e9EX,e9 Hi Louise, We'd prefer sequence, as this is more natural for Java developers i.e. they can use serialization to store internal Java data, without requiring that it be converted into IDL structures first). The Portable Interceptor spec defines a Codec interface that allows simple and easy conversion between arbitrary IDL types and sequence, which probably eliminates concerns about developers needing to do their own streaming. We definitely wouldn't like to see multiple ways of expressing state. Also, we should consider using CORBA::OctetSeq, instead of sequence. Regards, Eric Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Louise Moser [mailto:moser@alpha.ece.ucsb.edu] Sent: Tuesday, November 07, 2000 2:36 PM To: ft-ftf@omg.org Subject: Straw Vote on Issue 3747 Hi, If you have not already done so, please email your straw vote on Issue 3747. The polls on this straw vote close tomorrow, Wednesday, November 8. Thanks. Louise