Issue 465: Transport Level Bridge (interop) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Work for transport level bridge that doesn"t need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn"t share commom transport protocol Resolution: accomodated by "NeedAddressingInfo" change Revised Text: related issues are issue 382 and 383 Actions taken: December 4, 1996: received issue April 9, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Wed, 10 Dec 1997 16:49:32 -0500 From: ter@holta.ho.lucent.com (T E Rutt) To: interop@omg.org Subject: Interop 1.2 RTF Conference call (Proposed revisions and issues) To: Interop 1.2 RTF Subject: Dec 19, Conference Call From: Tom Rutt, RTF Chair I have attached my proposed Resolutions of Issues for ORB Interoperability 1.2 Revision Task Force. There was no meeting of the RTF at the NJ meeting, since everyone is so busy I decided to take a whack at coming up with resolutions for the issues. We need further discussion on some of these issues, as indicated in the actions section of each issue. A conference Call is scheduled for Friday, December 19, at 11:00 EST. I have the bridge reserved for 2 hours. The bridge phone number (16 ports reserved) is: +1 630 224 444 Conference Code 674 369 Let me know if you will participate, so I can ensure 16 is enough ports. Tom Rutt Issue 465: Transport Level Bridge (interop) Source: Netlabs (Mr. Jonathan Biggar, jon@wall.org) Nature: Uncategorized Severity: Summary: Work for transport level bridge that doesn't need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn't share commom transport protocol Resolution: Do not understand issue. A transport bridge could be constructed in at least two ways: 1) The IOR from one domain may be embedded by the bridge into the object key for the other domain. The transport bridge would have to change all the Object references in each message from one transport domain to the other by wrapping/unrapping the foreign IOR in/from object keys.. 2) All IORs to interwork in both transport domains could have an IIOP component plus an additional component for the other transport domain. Then the bridge would have all the necessary information for transport bridging. Revised Text: related issues are issue 382 and 383 Actions taken: Proposed No revision. December 4, 1996: received issue Return-Path: Sender: jon@biggar.org Date: Wed, 10 Dec 1997 23:41:39 -0800 From: Jonathan Biggar To: T E Rutt CC: interop@omg.org Subject: Re: Interop 1.2 RTF Conference call (Proposed revisions and issues) References: <199712102149.QAA22910@holta.ho.lucent.com> T E Rutt wrote: > Issue 465: Transport Level Bridge (interop) > > Source: Netlabs (Mr. Jonathan Biggar, jon@wall.org) > Nature: Uncategorized > Severity: > Summary: Work for transport level bridge that doesn't need > to understand full > GIOP/IIOP protocol. Requirements: interoperability across > network that doesn't share > commom transport protocol > > Resolution: Do not understand issue. A transport bridge > could be constructed in at least two ways: > 1) The IOR from one domain may be embedded by the bridge > into the object key for the other domain. The transport > bridge would have to change all the Object references in > each message from one transport domain to the other by > wrapping/unrapping the foreign IOR in/from object keys.. > 2) All IORs to interwork in both transport domains could > have an IIOP component plus an additional component for the > other transport domain. Then the bridge would have all the > necessary information for transport bridging. > Revised Text: related issues are issue 382 and 383 > Actions taken: Proposed No revision. > December 4, 1996: received issue Well, maybe my proposal (or how it was summarized in the issue list) wasn't clear enough. What I would like to add to the architecture is a method to do transport level bridging, not request level bridging, which is what the current CORBA 2.1 spec defines. In existing corporate intranets, there may not be a common transport level protocol (TCP/IP) that is shared across all devices on the network. For example, there may be isolated pockets of machines running only IPX or Appletalk. CORBA 2.1 only provides for a request level bridge as the connectivity solution, which is more heavyweight than necessary when there is no other need for bridging, such as between security domains. In this case, a transport level bridge, that just copied the raw GIOP datastream between the different transports would be a simple and lightweight solution to the connectivity problem. Unfortunately, GIOP as it is currently defined cannot be bridged at the transport level, because there is no way to specify the needed transport addressing information, since the GIOP request packet only carries the key portion of the IOR, not the entire IOR. So, my proposal was to add a new GIOP message, called BridgeRequest, whose body is a complete IOR that the bridge can extract the addressing information to establish a new transport connection to complete the bridging setup. This message would only be sent by the originating client when it recognized that it needed to use a bridge as the first request sent on the GIOP connection. The client would use local, ORB specific means to determine the location of the transport bridge. Let me know if this is still unclear. Jon Biggar jon@biggar.org Return-Path: Sender: jon@biggar.org Date: Thu, 11 Dec 1997 09:36:04 -0800 From: Jonathan Biggar To: T E Rutt , interop@omg.org Subject: Re: Interop 1.2 RTF Conference call (Proposed revisions and issues) References: <199712111349.IAA24347@holta.ho.lucent.com> T E Rutt wrote: > I think i understand, however I do not understand why your peoposal would not require > a new ior profile or component for the new transport domain. You are right that there would need to be a new IOR profile or component to handle the addressing for a new transport domain (such as IPX, ISO TP4, or Appletalk), however, I am not yet proposing those components, just the need for a generic transport bridge mechanism. Jon Return-Path: Sender: jon@biggar.org Date: Sat, 03 Jan 1998 20:12:21 -0800 From: Jonathan Biggar To: T E Rutt CC: interop@omg.org, jmhenson@monmouth.com Subject: Re: Revised text for Interop RTF vote References: <199801040017.TAA01331@holta.ho.lucent.com> T E Rutt wrote: > Issue 465: Transport Level Bridge (interop) > > Source: Netlabs (Mr. Jonathan Biggar, jon@wall.org) > Nature: Uncategorized > Severity: > Summary: Work for transport level bridge that doesn't need > to understand full > GIOP/IIOP protocol. Requirements: interoperability across > network that doesn't share > commom transport protocol > > Resolution: Do not understand issue. A transport bridge > could be constructed in at least two ways: > 1) The IOR from one domain may be embedded by the bridge > into the object key for the other domain. The transport > bridge would have to change all the Object references in > each message from one transport domain to the other by > wrapping/unrapping the foreign IOR in/from object keys.. > 2) All IORs to interwork in both transport domains could > have an IIOP component plus an additional component for the > other transport domain. Then the bridge would have all the > necessary information for transport bridging. > Revised Text: None. Could be subject of future RFP. New > features are outside the scope of this RTF. > Actions taken: Closed with no revision. > December 4, 1996: received issue Well, I guess I need to explain again. The proposed solution 1 does not work because I would like to provide a transport level bridge which does not need to cache information, which is assumed by solution 1. Solution 2 does not work because the GIOP REQUEST header does not contain the whole IOR, only the object key portion, so it is impossible for the transport bridge to get access to the information that it would need to do the bridging. Jon Biggar jon@biggar.org