Issue 4445: Interoperability of ObjectReferenceTemplate and Factory. (ort-ftf) Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, Vijaykumar.Natarajan@borland.com) Nature: Severity: Summary: Nothing in the specs (I think the submission does say this somewhere) say that the valuetypes defined in this spec and implemented by the ORB vendor are not expected to be transmitted across different ORB implementations. Proposal: Add paragraph to 51.5.3.1: Concrete definitions and implementations of ObjectReferenceTemplate and ObjectReferenceFactory are ORB implementation specific and are not defined as they are not expected to be exchanged between ORB implementations. Resolution: Add a clarification to the specification Revised Text: Add the following paragraph to the end of section 21.5.3.1: Concrete definitions and implementations of ObjectReferenceTemplate and ObjectReferenceFactory are ORB implementation specific and are not defined as they are not expected to be exchanged between ORB implementations Actions taken: August 2, 2001: received issue Discussion: End of Annotations:===== Date: Wed, 01 Aug 2001 21:23:24 -0700 From: Vijaykumar Natarajan Subject: Interoperability of ObjectReferenceTemplate and Factory. To: ort-ftf@omg.org, issues@omg.org Cc: Muhammad Arshad Khan , Kay Kit Chan Message-id: <3B68D5BC.9F733C3B@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en Content-Type: multipart/mixed; boundary="Boundary_(ID_uwaWJ0ddWW0ebtMViLXuPw)" X-UIDL: LnPe9UB+e9jAj!!g"=!! Hi all, Nothing in the specs (I think the submission does say this somewhere) say that the valuetypes defined in this spec and implemented by the ORB vendor are not expected to be transmitted across different ORB implementations. Proposal: Add paragraph to 51.5.3.1: Concrete definitions and implementations of ObjectReferenceTemplate and ObjectReferenceFactory are ORB implementation specific and are not defined as they are not expected to be exchanged between ORB implementations. Comments? Thanks, Vijay [] vnatarajan2.vcf Date: Wed, 1 Aug 2001 21:45:56 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Interoperability of ObjectReferenceTemplate and Factory. To: ort-ftf@omg.org, issues@omg.org, vnatarajan@borland.com Cc: akhan@borland.com, kkchan@borland.com MIME-Version: 1.0 Content-MD5: NzQwUqfn4zgiisabWkLstA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: f^i!!J_e!!k,od9*(-e9 >From: Vijaykumar Natarajan >Subject: Interoperability of ObjectReferenceTemplate and Factory. >To: ort-ftf@omg.org, issues@omg.org >Cc: Muhammad Arshad Khan , Kay Kit Chan > >MIME-version: 1.0 >X-Accept-Language: en > > >Hi all, > >Nothing in the specs (I think the submission does say this somewhere) Yes. In the revised submission (orbos/01-01-04) section 4.2.1, the note does say that interop between IMRs and ORBs written by different vendors is not a goal. >say that the valuetypes defined in this spec and implemented by the ORB >vendor are not expected to be transmitted across different ORB >implementations. > >Proposal: > >Add paragraph to 51.5.3.1: This should be 21.5.3.1. I think we should add this paragraph at the end of the section. > >Concrete definitions and implementations of ObjectReferenceTemplate >and >ObjectReferenceFactory are ORB implementation specific and are not >defined as they are not expected to be exchanged between ORB >implementations. > > Looks like a good addition to me. Thanks, Ken. Date: Thu, 2 Aug 2001 15:50:22 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: ORT FTF Vote 1 To: ort-ftf@omg.org Cc: Ken.Cavanaugh@Sun.COM, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: xa0FfXOsZtrCJX2HBCUbnQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: CL[d9McC!![Ufd9L;@e9 I think we can vote on issues 4440 and 4445. Votes on these proposals are due 5pm PST August 8, 2001. This leaves enough time to get in one more vote if needed before I write the FTF report. Here are the proposals: ================================================================================ issue # 4440: Object Adapter name problem in ORT The adopted specification for the Object Reference Template is ptc/01-04-03. This specification introduces adapter names for object adapters. Adapter names are needed in the definition of the ObjectReferenceTemplate abstract valuetype. An AdapterName is simply a sequence of strings that is used to identify an instance of an object adapter. In the case of the POA, the spec defines the AdapterName as follows in section 21.5.2.1: In the case of the POA, the adapter name shall be the sequence of names starting with the root POA that is required to reach the POA using the find_POA call. The name of the root POA is the empty sequence. Also, in section 21.3.14.6: The adapter_name attribute defines a name for the object adapter that services requestws for the invoked object. In the case of the POA, the adapter_name is the sequence of names from the root PAO to the POA that services the request. The root POA is not named in this sequence. The problem here is that the POA occupies the entire name space of possible adapter names, so an ORB that supports other proprietary object adapters cannot unambiguously identify instances of other object adapter through ServerRequestInfo.adapter_name. Proposed resolution: Give the root POA a standard name, and then require that no other object adapter may use the reserved name. I propose that the name of the root POA be { "RootPOA" }. This updates the above sections as follows: in 21.5.2.1: In the case of the POA, the adapter name of a POA instance shall be the sequence of names starting with the root POA that is required to reach the POA instance using the find_POA call. The name of the root POA is the sequence containing only the string "RootPOA". (also clarifying a small ambiguity in the original between "POA" as the name of the kind of object adapter and "POA" as an instance of the POA interface) in 21.3.14.6: The adapter_name attribute defines a name for the object adapter that services requestws for the invoked object. In the case of the POA, the adapter_name is the sequence of names from the root PAO to the POA that services the request. The name of the root POA is the sequence containing only the string "RootPOA". ============================================================================ issue # 4445: Interoperability of ObjectReferenceTemplate and Factory. Nothing in the specs (I think the submission does say this somewhere) say that the valuetypes defined in this spec and implemented by the ORB vendor are not expected to be transmitted across different ORB implementations. Proposal: Add the following paragraph to the end of section 21.5.3.1: Concrete definitions and implementations of ObjectReferenceTemplate and ObjectReferenceFactory are ORB implementation specific and are not defined as they are not expected to be exchanged between ORB implementations. ============================================================================