[70] in Open-Software-Foundation-News
OMG TC FAX Ballot, Oct. 21 1994 on Corba Interoperability Proposal.
daemon@ATHENA.MIT.EDU (Peter de Jong)
Mon Nov 7 02:01:39 1994
Resent-From: Bill Cattey <wdc@MIT.EDU>
Resent-To: osf-news-mtg@menelaus.LOCAL
Date: Sat, 29 Oct 1994 20:26:40 -0400
To: sig-dce@osf.org
From: dejong@apollo.hp.com (Peter de Jong)
An OSF member has requested that we send the following statement concerning
the OMG vote on CORBA interoperability to the SIG-DCE mailing list. This
statement is made by DEC and HP concerning the relationship of DCE in the
CORBA interoperability motion.
>X-Sender: dejong@pop-e5.ch.hp.com
>Date: Wed, 26 Oct 1994 00:02:38 -0400
>To: tc@omg.org
>From: dejong@apollo.hp.com (Peter de Jong)
>Subject: OMG TC FAX Ballot, Oct. 21 1994 on Corba Interoperability Proposal.
>
>
> We ask TC members to vote "no" on the current fax ballot for
>Corba Interoperability. We think the proposal will not meet
>customers needs or be effective technically for the reasons we're
>outlining below. Since the impact of the current recommendation is
>potentially very broad, we think it needs more careful consideration.
>We also believe a compromise solution -- meeting more customers'
>needs -- can be worked out fairly straightforwardly.
>
> As background, on October 19 the Corba 2V Interoperability
>Task Force made a complex recommendation to the OMG TC regarding the
>two interoperability proposals submitted in response to the OMG's RFP
>for interoperability. During the TC meeting on Oct. 20, the
>recommendation was further modified. The two proposals were voted on
>prior to the completion of a thorough technical evaluation or
>consideration as to how they could be merged. Since only 18 members
>voted out of a potential of 51, we think further discussion is
>warranted.
>
> The UNO proposal you are being asked to vote on will, if
>successful, mandate a new, untested, unimplemented and undeployed
>protocol designed by the UNO submitters. It will represent the only
>possible way to claim conformance with Corba V2 interoperability
>within TCP-based networks. We think it represents a minimalist
>approach and it's unclear if customers will buy it or if vendors will
>be able to achieve CORBA interoperability with it. If anything is
>mandatory, we think it should be a proven, tested protocol like the
>DCE RPC.
>
>
>Why We're Against UNO.
>
> Our position is that the industry would be best served by
>specifying a single protocol for CORBA interoperability. However, we
>believe that such a protocol should be based on existing, proven
>technology and not on a new invention.
>
> With this in mind, we created an initial submission based on
>the DCE RPC network protocol. We have not recommended the use of the
>entire DCE RPC. Instead, in order to provide small code footprint
>and strong performance, we submitted a subset of the DCE RPC.
>
> However, after receiving feedback that the community is
>reluctant to mandate a single protocol for CORBA interoperability, we
>drafted a compromise submission (DCE-CIOP). As a compromise, we
>support the concept of allowing two peer protocols in the final CORBA
>V2 Interoperability Specification. Doing so at this point in the
>evolution and deployment of CORBA would allow the industry to benefit
>from experience with both prior to the selection of a single protocol.
>
> The HP and Digital proposal was intended to complement the
>UNO proposal, which mandates a TCP-IP based protocol. Since the DCE
>RPC runs on top of TCP-IP, the Digital and HP proposal fits in as a
>protocol. Of the two submissions, the only differences were the
>underlying messaging layer.
>
>
>
>Advantages of DCE-CIOP over UNO IOP
>
> In looking at the problem of interoperability between
>networked ORBs, HP and Digital worked with other companies on a
>combined submission. Based on input from customers, end users and
>ISVs, we discovered a marked resistance from customers and end users
>to deploying new network protocols, even ones which layered on
>familiar lower level network transport services.
>
> Our response to the Interoperability RFP contains a subset of
>the DCE RPC specification, as implemented today on a variety of
>platforms/transports, plus the required definitions for CORBA headers
>and messages. We continued to call it "DCE-RPC based" to reflect our
>choice of solid, existing technology and experience with that
>technology. What we have specified is really a request/response
>transport which was designed and architected specifically for the
>Corba object model. The DCE RPC is also compatible with a widely
>available industry standard for distributed computing. Here are the
>key differences between the GIOP and DCE-CIOP proposals:
>
>GIOP mandates the use of a new, untested, unimplemented and
>undeployed communications protocol as the basis for CORBA V2
>compliance. Since different vendors may choose to implement this
>protocol differently, it will make near-term interoperability more
>difficult to achieve. As you know, it's very difficult to achieve
>interoperability from a specification. This takes much
>trial-and-error work and debugging.
>
>In contrast, the DCE RPC is widely deployed, well documented and well
>tested. It's been endorsed by most of the industry, including
>Microsoft, and been proven to be completely interoperable over a wide
>range of hardware and different implementations. Two implementations
>were created from the DCE RPC specification, one by the OSF and one
>by Microsoft. Both these implementations successfully interoperate
>with each other today. Products from vendors using either the OSF or
>Microsoft DCE implementations have been proven to be completely
>interoperable.
>
>The DCE RPC operates over multiple transport layers -- including
>TCP-IP. It supports two object models: CORBA as implemented by HP
>and Digital, and OLE/COM as implemented by Microsoft. With GIOP,
>companies would have to deal with yet another RPC. They would need
>to bear the costs of having to duplicate development work and the
>costs of end-users having to administer yet one more "industry
>standard."
>
>We subsetted the DCE RPC to meet performance and code-size goals. We
>also used the existing components to ensure complete compatibility
>while operating in full DCE environments. Our submission separates
>communication protocol layers from the Corba object architecture.
>This allows rehosting on new communication layers to take place
>without direct OMG involvement while preserving the concept of
>"conformance" within the new communication domain and also preserving
>application portability.
>
>
>Technical Discussion Background
>
> During the Task Force meeting, the UNO group and Digital and
>HP began to converge on a common nomenclature and architecture which
>would have led to an effective merger of these proposals.
>Unfortunately, active discussion was cut off by the question being
>called. This caused an immediate vote on a version of the
>recommendation now in front of the TC. We regret that the question
>was called during the discussion in the Task Force. Our belief is
>that people were moving closer together and further discussion would
>have resulted in something all parties could have accepted.
>
> Even if this conformance situation were acceptable to all,
>currently these two submissions can't be merged without further
>change and compromise in both of the current submissions.
>
> Digital and HP explored these changes with members of the UNO
>team on the afternoon of Oct. 20th. We asked for a compromise based
>on the relatively contained technical levels. We believe that if
>discussion can continue, the two proposals can be merged along with a
>structure for conformance claims allowing for Corba V2 conformance to
>be correctly identified for various selections of transports and
>protocol stacks.
>
>
> In trying to reach a compromise with the UNO submitters, we
>modified our submission to match their language and architecture. We
>also agreed to support bridging technology specified in their
>submission, which would handle issues of multiple low level transport
>domains. Rather than redesign non-protocol related aspects of their
>work, we agreed to use their specification in our proposal.
>
> In response to concerns over access to technology, we made
>our code base for full DCE RPC - not just the subset needed for an
>implementation of our specification -- publicly available without a
>royalty.
>
>
>Next Steps:
>
> If the current recommendation before the TC is rejected, both
>Digital and HP will continue to work with the other submitters to
>iron out a joint submission through a combination of our proposals.
>If one protocol is selected, it should be the DCE-CIOP. If two peer
>protocols are selected, the market and industry will gain experience
>with both and be able to pick the protocol of preference. We wrote
>our submission to make the combination of two peer protocols a
>relatively easy editing function with few outstanding technical
>details.
>
>Summary:
>
> We would be more than willing to answer questions relative to
>our submission or the position reflected in this mail.
>
>Peter de Jong
>TC member for Hewlett-Packard Company
>
> Rudolf Riess
>TC member for Digital Equipment Corp.
>
>
>
Date: Fri, 28 Oct 1994 07:28:20 -0400
To: tc@omg.org
From: dejong@apollo.hp.com (Peter de Jong)
Subject: Clearification of DCE-CIOP/IIOP claims raised by Geoff Lewis
Currently the TC is faced with a fax vote, which if successful, will
mandate a new, untested, unimplemented and undeployed communications
protocol designed by the UNO submitters as the basis of claiming
conformance to Corba V2 interoperability within TCP-based networks.
The motion also includes an optional communication protocol
(DCE-CIOP) which will also provide CORBA interoperability within
TCP-based networks.
One can't choose between these two communication protocols on the
basis claimed by Geoff Lewis in his letter to the tc mailing list. He
claims the following:
(Lewis) The GIOP is purpose-built and optimized for ORB to ORB
communications.
The DCE-CIOP was built and optimized for ORB to ORB communications
using the same architecture as the GIOP. They are both at the same
protocol level. In the DCE-CIOP there is an explicit separation
between the communications protocol and the ORB message handling. In
the GIOP the same separation exists, but it is implicit. The DCE-RPC is
purely concerned with communication transport issues. It is not
concerned with the many issues the UNO submitters claim for it. In
particular it does not support procedural programming any better or
worse than the GIOP communication layer. What it does support better
than the GIOP communication layer are the following:
* ORB level message fragmentation. This permits large marshaled
messages to be buffered by the ORB. The GIOP communications protocol
requires the marshaled message to be allocated in one buffer. In
the GIOP, a four megabyte message will need a four megabyte buffer
to be allocated.
Message fragmentation also permits the cancellation of a message
while its in the process of being transmitted.
* Multiple transports are supported below the RPC layer. This
permits the addition of new communication protocols below the RPC
layer. Since the GIOP does not make a clear distinction between the
RPC layer and the rest of the transport layer, it needs to add new
names when adding new protocols. The UNO proposal names an IIOP
protocol. ICL has added a OIOP protocol.
The GIOP message headers are not as fixed as the UNO submitters
suggest. When new non-stream based protocols are added, the message
headers will need to change in the GIOP protocol. The message
headers will also have to change when new functions, such as
fragmentation, are added to the GIOP.
* DCE-RPC fully supports the internet IP protocol suite (TCP/IP
and UDP/IP). Where as the IIOP (despite its name) only supports
TCP/IP. In an earlier draft version of the UNO submission, the IIOP
was called the CIOP. It is now called the Internet Inter-ORB
protocol for purely marketing reasons. It does not support the
full internet protocol suite.
* The DCE-RPC is well documented. Two independent implementations
were created from this documentation, one by OSF and one by
Microsoft. Both these implementations successfully interoperate
with each other.
* The DCE-RPC currently supports two object models. CORBA as
implemented by HP and DEC. and OLE/COM as implemented by Microsoft.
* The DCE-RPC is widely deployed and available. The DCE-RPC source
is available royalty free.
(Lewis) The GIOP avoids the complexity and overhead of a general
purpose RPC mechanism.
The DCE-RPC is focused on providing efficient RPC communications.
All the functions in the DCE-RPC are to support these communications.
All its mechanisms provide useful functions. The GIOP will
eventually need to grow to add these functions.
(Lewis) The GIOP can be specially designed to allow transport
mappings to be defined for different network protocols domains.
The DCE-RPC currently supports the following protocols in products: TCP/IP,
UDP/IP, SPX, IPX, namedpipes, netbios. In addition prototype
implementations have included OSI protocols.
(Lewis) Since the GIOP's specification is not tied to any
particular implementation of supporting technology, it can evolve
more easily in the future to support the special needs of distributed
object systems.
The question is where does the communications protocol end and ORB
message processing begin. Will OMG take over the IP protocol suite
to more easily in the future support the special needs of distributed
object systems? We believe the DCE-RPC gives excellent support for
RPC communications. This type of communications should not be
specified by the OMG.
(Lewis) The GIOP can make minimal assumptions about the
architecture of agents that support it.
The DCE-CIOP and GIOP make exactly the same minimal assumptions about
the architecture of agents that support it.
(Lewis) It has built-in basic support for the propagation of
implicit context required to support certain Object services.
The DCE-CIOP has exactly the same support as the GIOP for the
propagation of implicit context required to support certain Object services.
=======================================================================
Peter de Jong email: dejong@apollo.hp.com
Hewlett-Packard Company Tel: 508 436-5372
300 Apollo Drive / CHR-03-DW Fax: 508 436-5122
Chelmsford, MA 01824
========================================================================
