Issue 536: Current and get_current() (sec-rev) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Security spec uses CORBA::Current, while our (transactions?) spec says CORBA::ORB::Current. Anybody involved in all 3 (CosTx, CosSec,Core)to make sure inconsistency gets cleared-up? Resolution: resolved, close issue Revised Text: Fix is entirely editorial. IDL in Transaction spec is invalid since you cannot define interface within an interface.The correction is to replace all occurences of string CORBA::ORB::Current by the string in CORBA::Current in the revised transactions spec Actions taken: March 19, 1997: received issue April 4, 1997: closed issue Discussion: End of Annotations:===== Return-Path: Date: Wed, 19 Mar 1997 09:45:28 -0800 From: "Mark Christiansen" Organization: Visigenic Software To: transactions@omg.org Cc: Farid Khoujinian , Jeff Mischkinsky , Prasad Subject: Current and get_current() Since Current and get_current() are still not defined in the CORBA Core specifications, I've been looking at the Transaction and Security specifications for hints. It looks like the Security Specification (I'm looking at page 220, section A.3 in what looks like an 8/5/1996 document) uses CORBA::Current, while our latest spec (12/6/96?) says CORBA::ORB::Current. Is anyone involved with all three (CosTx, CosSec and Core), and can make sure that this inconsistency gets cleared-up? Then there's the problem of getting the correct implementation of Current. It sounds like something is in the works to have CORBA::ORB::get_current() (or is that CORBA::get_current() or CORBA::BOA::get_current()?) take a "in unsigned long" or "in IOP::ServiceID" that represents the IOP service tag assigned in the IOP module. Does anyone have more information on this? Thanks! -- Mark Christiansen markc@visigenic.com Visigenic Software, Inc. Voice: (415) 655-3943 951 Mariner's Island Blvd #120 Fax: (415) 286-2464 San Mateo, CA 94404 http://www.visigenic.com Return-Path: From: kukura@apollo.hp.com Date: Wed, 19 Mar 1997 13:46:33 -0500 To: markc@visigenic.com Cc: transactions@omg.org, faridk@visigenic.com, jeffm@visigenic.com, prasad@visigenic.com, sec-rev@omg.org, joey@expersoft.com Subject: Re: Current and get_current() Snarfer: $Revision: 1.1.2.9 $ $Date: 1992/11/13 23:40:23 $ Date: Wed, 19 Mar 1997 09:45:28 -0800 From: "Mark Christiansen" Organization: Visigenic Software X-Mailer: Mozilla 4.0b2 (WinNT; I) Mime-Version: 1.0 Cc: Farid Khoujinian , Jeff Mischkinsky , Prasad X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Since Current and get_current() are still not defined in the CORBA Core specifications, I've been looking at the Transaction and Security specifications for hints. It looks like the Security Specification (I'm looking at page 220, section A.3 in what looks like an 8/5/1996 document) uses CORBA::Current, while our latest spec (12/6/96?) says CORBA::ORB::Current. Is anyone involved with all three (CosTx, CosSec and Core), and can make sure that this inconsistency gets cleared-up? Then there's the problem of getting the correct implementation of Current. It sounds like something is in the works to have CORBA::ORB::get_current() (or is that CORBA::get_current() or CORBA::BOA::get_current()?) take a "in unsigned long" or "in IOP::ServiceID" that represents the IOP service tag assigned in the IOP module. Does anyone have more information on this? Hi Mark, I'm involved with the ORB RTF, the Security RTF, and the Portability RFP submission (which is adding a PortableServer::Current), and am doing what I can to make sure the issues regarding Current get cleared up and made consistent across all relevant specifications. In Austin, I described the Portability RFP submitters' interpretations and intentions regarding Current to the Security RTF. I then accepted the action item to write up text for the CORBA core specification that will clarify the interfaces and semantics associated with CORBA::Current, and distribute this to all involved RTFs (orb, security, and transactions). I expect to complete this by the end of next week. Once agreement is reached, I'd hope the revised CORBA core text could be incorporated via whichever group's document is approved first. Here are the main points: 1) The base interface for Currents is CORBA::Current. It is a real IDL interface and normal language mapping rules apply. We'll probably say something about locality-constraints on implementations of interfaces derived from CORBA::Current. 2) Operations on interfaces derived from Current access state associated with the thread in which they are invoked, not state associated with the thread from which CORBA::ORB::get_current() was called. This prevents one thread from manipulating another thread's state, and eliminates the need to obtain and narrow a new Current in each method's thread context. Applications that do obtain a new Current in each thread still work, as long as they don't try to manipulate other threads' Currents. 3) Currents are singleton objects, so no destroy() operation is needed. 4) The CORBA::ORB::get_current() operations takes a CORBA::ServiceType as an in parameter to specify for which service a Current is being obtained. In most language mappings, the CORBA::Current returned must then be narrowed to the proper type. Passing the ServiceType parameter allows (but does not require) each ORB service's Current to be independently implemented. Thanks! -- Mark Christiansen markc@visigenic.com Visigenic Software, Inc. Voice: (415) 655-3943 951 Mariner's Island Blvd #120 Fax: (415) 286-2464 San Mateo, CA 94404 http://www.visigenic.com -Bob -- Robert A. Kukura Internet Technology Lab email: kukura@apollo.hp.com Hewlett-Packard Company phone: 508-436-4512 300 Apollo Drive CHR-03-WR fax: 508-436-5176 Chelmsford, MA 01824 Return-Path: Date: Wed, 9 Apr 97 10:16:48 EDT From: Dan Frantz ZKO2-2/R80 603-881-2272 09-Apr-1997 0944 -0500 Cc: issues@omg.org, sec-rev@omg.org, soley@omg.org, andrew@omg.org Apparently-To: andrew@omg.org, soley@omg.org, sec-rev@omg.org, issues@omg.org, jis@fpk.hp.com Subject: Re: issue536 Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues > >> This is issue # 536 >> >> Current and get_current() >> >> Security spec uses CORBA::Current, while our (transactions?) spec >> says CORBA::ORB::Current. Anybody involved in all 3 (CosTx, >> CosSec,Core)to make sure inconsistency gets cleared-up? >> >> -Juergen > >Yes, I am. > >Since informally the chairs of Core RTF and Security RTF have decided to >let the Security RTF provide text for fixes to Current, Juergen, please >assign this issue to Security. > >The fix is entirely editorial. The Transaction spec is plain wrong. The >IDL in the Transaction spec is invalid since you cannot define an >interface within an interface. The correction is to simply replace all >occurences of the string "CORBA::ORB::Current" by the string in >"CORBA::Current" in the revised transaction spec. This editorial fix >will be applied to the revised transaction spec before it is published. > >Juergen, after assigning this issue to Security, you can enter the above >paragraph as resolution and close the issue. This has been discussed >with Richard Soley, and he has declared the fix to be editorial in >nature. Just to throw one more group into the pot, the Portability group is using Current and noticed the above problem also. We have the same fix in our draft due next week. If the OTS spec has it fixed before final publication, then we won't bother to include a change to OTS. BTW, it appear the OTS people just put in what the security spec told them to do; thus, the published Security spec, section B.9.4 is also incorrect. Dan Frantz Return-Path: Date: Wed, 09 Apr 1997 13:32:14 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs Cc: issues@omg.org, sec-rev@omg.org, orb_revision@omg.org, soley@omg.org, andrew@omg.org Subject: Re: issue536 References: <9704091416.AA02762@us2rmc.zko.dec.com> Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues Dan Frantz ZKO2-2/R80 603-881-2272 09-Apr-1997 0944 -0500 wrote: > > > > >> This is issue # 536 > >> > >> Current and get_current() > >> > >> Security spec uses CORBA::Current, while our (transactions?) spec > >> says CORBA::ORB::Current. Anybody involved in all 3 (CosTx, > >> CosSec,Core)to make sure inconsistency gets cleared-up? > >> > >> -Juergen > > > >Yes, I am. > > > >Since informally the chairs of Core RTF and Security RTF have decided to > >let the Security RTF provide text for fixes to Current, Juergen, please > >assign this issue to Security. > > > >The fix is entirely editorial. The Transaction spec is plain wrong. The > >IDL in the Transaction spec is invalid since you cannot define an > >interface within an interface. The correction is to simply replace all > >occurences of the string "CORBA::ORB::Current" by the string in > >"CORBA::Current" in the revised transaction spec. This editorial fix > >will be applied to the revised transaction spec before it is published. > > > >Juergen, after assigning this issue to Security, you can enter the above > >paragraph as resolution and close the issue. This has been discussed > >with Richard Soley, and he has declared the fix to be editorial in > >nature. > > Just to throw one more group into the pot, the Portability group is using > Current and noticed the above problem also. We have the same fix in our > draft due next week. If the OTS spec has it fixed before final publication, > then we won't bother to include a change to OTS. > > BTW, it appear the OTS people just put in what the security spec told them to > do; thus, the published Security spec, section B.9.4 is also incorrect. > > Dan Frantz Dan (and others), Note that I added the orb_revision list to the CC list since they are deeply involved in this too. (Andrew, before I dive into my coda on Current, should we schedule some time at the AB in Stresa to explain this convluted cross dependencies and how we are proposing to work them to the AB, so that they are forewarned? The issues involved are Current, Object and Policy changes/additions) About B.9.4 being incorrect in the Security spec, you are indeed right. (Ultimately the fault is mine and Bob Blakly's:-)). Most fortunately the entire section B.9 (as well as sections B.1, B.2, B.3, B.4 and B.5) will be gone from the next rev of the Security spec, since all of it (minus the bugs of course:-)) will have been incorporated into the Core rev by then. In what follows we cover the following Issues from the OMG Issues list: 370, 536 and in addition Issue DII-3 in the Portability Spec Draft 11. The incorporation of Current in the Core has several aspects. I enumerate them below as I see them and propose how we should go about handling that aspect with my reasoning for proposing so: 1) The basic interface declaration in CORBA module and the declaration of the type ServiceType. This needs to be incorporated into the published CORBA Core spec ASAP so as to make things like the Security Rev 1.2 (when it comes out in a few months) consistent with the then published Core spec, and hence actually implementable consistently based on published specs. The best way to achieve this is to provide the text and IDL related to this aspect to the Core RTF for inclusion in the Core revision that is due in June. The IDL affected by this part (excerpted from Page 2-11 of Portability D11 is the following: module CORBA { // interface for Current object and its service identifiers interface Current { // IDL }; typedef unsigned short ServiceType interface ORB { ... Current get_current(in ServiceType serv_id); }; }; Notice that there are a couple of bugs in the IDL declaring the get_current operation on page 2-11, which has been fixed above (Bug (1) is that "in" is missing and bug (2) is that the type of the in parameter is said to be "ServiceId" which is not defined anywhere). There is an issue associated with that bug (the type of the in parameter being ServiceType instead of ServiceId. It turns out that the Security spec in conjunction with the definition of the ORB::get_service_information operation defines a thing called ServiceType and indeed. Its purpose is to identify service profiles that are supported by the ORB, and hence perhaps it is not a good idea to use it for identifying the type of Current. My inclination is to define a new type called something like CurrentType to identify the type of Current one is interested in and thus orhtogonalize the representation of two things that really are orthogonal, i.e. all service types may not have associated distinct current types and vice-versa. So in the above IDL, I would propose global replacement of the string "ServiceType" by "CurrentType" and change the name of the in parameter to "curr_type" or some such. With that proposed change the IDL becomes: module CORBA { // interface for Current object and its current type identifiers interface Current { // IDL }; typedef unsigned short CurrentType; interface ORB { ... Current get_current(in CurrentType curr_type); }; }; 2) The specific CurrentType that is used by the Security Service. This needs to be incorporated in the Core ASAP for the same reasons as 1 above. Hence the proposal is to let the Core RTF get it in there. The IDL line affected is (with my proposed modification of type) module CORBA { const CurrentType Security = 1; }; 3) The specific CurrentType that is used by the Transaction Service. This needs to be incorporated in the Core ASAP for the same reasons as 1 (as applied to Transaction Service) above. Hence the proposal is to let the Core RTF get it in there. The IDL line affected is (with my proposed modification of type) module CORBA { const CurrentType Transaction = 2; }; 4) The Transaction Service use of Current object as described in Issue DII-3 on page 2-13. This needs to be hashed out with the Transaction folks and resolved. This is independant of the IDL changes. 5) The bug that appears in the revised Transaction & Security Service spec which talks of CORBA::ORB::Current interface. This is an editorial fix that will be applied as such to the published version of the current rev of the Transaction service as per discussions we have had with Richard Soley. In case of Security the entire section B.9 will be gone from the next rev of the Security spec where this error appears. Certain other Current related editorial errors in the Security spec will also be fixed like the reference to something called SecureCurrent et. al. 6) The definition of the const POA. This can only occur in the Portability spec and hence should be done there. IDL lines affected are: module CORBA { const CurrentType POA = 3; }; As you can see many things have to occur together for us to pull this off most efficiently. Anyway, described above is the way I think this could be achieved. Of course further discussion is necessary to determine that this will actually work logistically. Paul Rabin, Bob Kukura, myself and Melony Katz have discussed this (and several other things like Policy and Object and stuff that Security defines/extends) and we thought this might work OK. So let me know if all this makes sense to you. Thanks and Regards, Jishnu Mukerji jis@fpk.hp.com