Issue 633: connect_* operations in sections 4.5.(4,5,6,7) (events) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The connect_* operations in these sections raise an AlreadyConnected exception if the client is already connected!? In some cases the channel will allow consumer to connect twice Resolution: Rejected Revised Text: Actions taken: July 24, 1997: received issue February 27, 2001: closed issue Discussion: Whether a proxy is connected is a property of the proxy, not of the connecting party. In particular, a client can connect to a particular proxy only once, whereupon the proxy enters the connected state; the only way out of the connected state is to destroy the proxy. If a client calls the connect operation on a particular proxy a seond time (or another client calls the connect operation on an already connected proxy), the AlreadyConnected exception is raised. This enforces the one-to-one relationship between consumers and producers. End of Annotations:===== Return-Path: From: D.R.Stringer@nortel.co.uk Date: Thu, 24 Jul 97 12:03:35 BST To: andrew@omg.org Subject: tip-off to the object-identity police (!?) Cc: ab@omg.org Hi Andrew I've been looking at the Event Service and I'm concerned. The EventChannel has this concept of "connected", i.e. suppliers and consumers are, in some sense, connected to the channel. This allows exceptions like "AlreadyConnected" and "Disconnected" to be raised. The connect_* operations, in sections 4.5.{4,5,6 and 7} of CORBAservices, raise an AlreadyConnected exception if ... umm, the client is already connected !? This would appear to be on the basis of the "in param", which is an object reference [referring to a target object "associated" with the client]. The assumption is probably that the EventChannel "spots" (via is_equivalent? - what else?) that this object reference is the same as one it saw earlier. Now one might suppose that nothing is broken: in a small minority of cases the channel will allow a consumer (or supplier) to connect twice. Or perhaps there is an entirely different interpretation of the spec. Yours, "concerned of Harlow" Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Fri, 25 Jul 1997 00:31:59 +1000 (EST) From: Michi Henning To: D.R.Stringer@nortel.co.uk cc: andrew@omg.org, ab@omg.org Subject: Re: tip-off to the object-identity police (!?) On Thu, 24 Jul 1997 D.R.Stringer@nortel.co.uk wrote: > client is already connected !? This would appear to be on the basis > of the "in param", which is an object reference [referring to a target > object "associated" with the client]. The assumption is probably that > the EventChannel "spots" (via is_equivalent? - what else?) that this > object reference is the same as one it saw earlier. > Isn't it funny how this identity problem raises it's head time and time again? There are more and more services affected by this. If we can't agree to define a strong notion of object identity as part of CORBA, could we at least agree on standard interfaces to provide strong identity to services that require it? If this goes on much longer, each new service will come up with its own idea of how identity should be established, and we'll end up in a maze of twisty little passages, all different... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Sender: andrew@emerald.omg.org Date: Sun, 27 Jul 1997 22:56:28 -0400 To: D.R.Stringer@nortel.co.uk From: Andrew Watson Subject: Re: tip-off to the object-identity police (!?) Cc: ab@omg.org, Michi Henning Dave, You wrote: > I've been looking at the Event Service and I'm concerned. The > EventChannel has this concept of "connected", i.e. suppliers and > consumers are, in some sense, connected to the channel. This > allows exceptions like "AlreadyConnected" and "Disconnected" to > be raised. The connect_* operations, in sections 4.5.{4,5,6 and 7} > of CORBAservices, raise an AlreadyConnected exception if ... umm, > the > client is already connected !? This would appear to be on the basis > of the "in param", which is an object reference [referring to a > target > object "associated" with the client]. The assumption is probably > that > the EventChannel "spots" (via is_equivalent? - what else?) that this > object reference is the same as one it saw earlier. > > Now one might suppose that nothing is broken: in a small minority of > cases the channel will allow a consumer (or supplier) to connect > twice. > Or perhaps there is an entirely different interpretation of the > spec. And Michi wrote: > Isn't it funny how this identity problem raises it's head time and > time again? There are more and more services affected by this. If we > can't > agree to define a strong notion of object identity as part of CORBA, > could > we at least agree on standard interfaces to provide strong identity > to services that require it? I agree there is an issue here, and this is exactly the kind of thing we need to keep an eye out for when looking at proposed specifications. And I like Michi's idea of a set of identity management interfaces (although not a separate identity management service - that would be too heavyweight). Meanwhile, to make sure the issue doesn't get mislaid, I'll get Juergen to register it as an issue, so that at least the next Services RTF will see it. Cheers, Andrew