[84] in Open-Software-Foundation-News
Re: Interoperability recommendation
daemon@ATHENA.MIT.EDU (Peter de Jong)
Thu Nov 10 19:59:04 1994
Resent-From: Bill Cattey <wdc@MIT.EDU>
Resent-To: osf-news-mtg@menelaus.LOCAL
Date: Mon, 31 Oct 1994 21:52:53 -0500
To: curtis@expersoft.com (David Curtis), tc@omg.org
From: dejong@apollo.hp.com (Peter de Jong)
David,
At 09:18 PM 10/30/94 PST, David Curtis wrote:
>TC members:
>
>CLAIM: THE UNO GIOP PROTOCOL IS "NEW, UNTESTED, UNIMPLEMENTED
>AND UNDEPLOYED PROTOCOL"
>
>TRUTH: The DCE-CIOP protocol proposed in the DEC/HP
>submission is itself a "new, untested, unimplemented
>and undeployed protocol". It is not the DCE standard RPC
>mechanism. The specification has been heavily modified to
>implement CORBA semantics, and to comply with some elements
>of the UNO specification. The recently-announced zero-cost
>license availability for DCE RPC does not provide the
>community with an implementation of the DCE-CIOP protocol
>in the DEC/HP proposal.
>
FALSE: The DCE-CIOP uses the standard DCE-RPC. The subset was created by
specifying that certain optional fields in the DCE-RPC PDU's be set to zero.
These are legal DCE-RPC values.
One of the main purposes of releasing the DCE-RPC source as a zero-cost
license is to make the DCE-RPC which is used in the DCE-CIOP more widely
available. Why would we release the DCE-RPC source if it can't be used in
the DCE-CIOP?
There are zero modifications to the DCE-RPC to implement the CORBA
semantics. This is in fact one of the main reasons we are asking the OMG TC
to vote no on the UNO proposal. The DCE-CIOP specifies a clear separation
between transportation issues and CORBA semantic issues. The OMG should not
need to approve a new standards submission every time there is a change in
transport.
>MORE TRUTH: The GIOP protocol specified in the UNO proposal is
>based on the collective experience of the UNO submitters
>(Expersoft, IBM, Iona, ICL, BNR, and SunSoft). Each of these
>submitters has extensive experience implementing ORBs over
>a variety of communication protocols and messaging systems.
>This collective experience is embodied in a number of
>successful, commercially available, deployed ORB products offered
>by the UNO submitters. The UNO submitters drew directly upon
>their existing, tested ORB protocol designs when forming the
>GIOP protocol specifications.
I respect your technical ability and the ORBs by the above companies. I
have no doubt each of the above companies can implement the GIOP and IIOP
specification. But I think if each company independently implemented the
IIOP, they would not interoperate from the information within the UNO
submission. Eventually with revisions enough information would be placed in
the UNO specification to support independent implementation.
The main question is why are we making the IIOP a standard. And even more
importantly why are we mandating that an RPC which no one is currently using
be needed for CORBA compliance.
>
>In fact, no existing, deployed protocol meets the requirements
>of the ORB Interoperability RFP. ORBs represent a new design
>center in the distributed computing arena. Existing RPC
>mechanisms and messaging systems are designed for coarse-grained
>non-object-oriented client-server systems. The GIOP is
>specifically targeted at CORBA distributed object systems.
>
The granularity of the IIOP and the DCE-RPC are exactly the same. The
design center of the IIOP and the DCE-RPC are exactly the same. And they are
both equally object-oriented. The main difference is that the DCE-RPC has
more function, runs over more protocols, and is more widely available.
Microsoft is building its RPC into MS Windows-95. This RPC is interoperable
with the OSF DCE-RPC. The DCE-CIOP can be built using either the MS RPC or
the OSF DCE-RPC. In a short while the majority of PCs will have the
DCE-CIOP RPC transport built in.
>CLAIM: "UNCLEAR WHETHER CUSTOMERS WILL BUY IT OR IF VENDORS
>WILL BE ABLE TO ACHIEVE INTEROPERABILITY WITH IT"
>
>TRUTH: The UNO proposal has clear, strong support from the
>end user community, and from independent software vendors.
>In the ORB2 Task Force vote, not a single end-user or ISV
>voted against the UNO submission. Several members of
>the end-user community spoke up strongly in support of
>the UNO submission.
We already know of end-users and ISV's who will be voting no in the TC vote.
>
>MORE TRUTH: It is quite clear to the six UNO submitters (among
>whom are a majority of the leading ORB vendors today) that we can
>achieve interoperability with the GIOP specification.
>
And we can achieve interoperability with the DCE-CIOP specification.
>EVEN MORE TRUTH: The implication of the HP statement is that,
>by contrast, all customers *would* be willing to buy and maintain
>a DEC-based environment to achieve ORB interoperability.
>This is clearly not the case for a very large number of
>customers, many of whom voiced this sentiment strongly in
>the TF meeting.
>
The DCE-CIOP is self-contained. It does not require any more of DCE.
Future versions of the DCE-CIOP will add more DCE function (some of which is
specified in the DCE-CIOP appendix). But their will always be the minimal
version of DCE-CIOP which does not need any more of DCE than the DCE-RPC.
>
>CLAIM: "IT WILL MAKE NEAR-TERM INTEROPERABILITY MORE
>DIFFICULT TO ACHIEVE... IT'S VERY DIFFICULT TO
>ACHIEVE INTEROPERABILITY FROM A SPECIFICATION"
>
>TRUTH: This is nonsense. Specifications are the
>primary mechanism through which interoperability is achieved
>is almost any technical community. The UNO submission
>was specifically designed to be simple. Simplicity
>reduces the cost of implementation, encouraging multiple,
>independent implementations. Simplicity also ensures
>that independent implementations will interoperate properly.
>Even a casual comparative reading of the UNO/GIOP and DEC-CIOP
>protocol specifications will convince readers that the GIOP
>specification is simpler, easier to implement. We argue that
>the above claim is the opposite of the truth: the DEC-CIOP
>submission is also (merely) a specification; because of its
>greater complexity, the DCE-CIOP specification would make
>interoperability more difficult to achieve.
All the greater complexity of the DCE-CIOP is in the specification of
important functions (such as fragmentation and a binding protocol) which is
missing from the IIOP.
The DCE-RPC is very well documented in the AES RPC specification published
by Prentice Hall. What makes the specification complicated, is that it
contains the specification of the finite state machines which implement the
protocol. This detail of specification is what makes it a good standard,
and it allows independent implementations of the RPC.
>
>
>CLAIM: "WITH GIOP, COMPANIES WOULD HAVE TO DEAL WITH YET
>ANOTHER RPC. THEY WOULD NEED TO BEAR TO COSTS OF HAVING
>TO DUPLICATE DEVELOPMENT WORK AND THE COSTS OF END-USERS
>HAVING TO ADMINISTER YET ONE MORE 'INDUSTRY STANDARD'"
>
>TRUTH: GIOP is not an RPC. It is not a large computing
>environment (such as DCE) that requires significant administration
>by end-users. It is a messaging system used for inter-ORB communication
>which will be completely transparent to the end-user. What development
>work? What administrative costs? There is no additional
>administrative cost or burden. The same claim
>cannot be made for the DCE environment.
It has a request response protocol. This is the definition of an RPC.
The IIOP has a very simple notion of object location, in which the end-point
is hardwired into the IOR. The first version of the DCE-CIOP uses the same
notion of object location. This was done so that the IIOP and DCE-CIOP can
be compared in terms of complexity, and the DCE-CIOP is self-contained. This
fixed end-point hardwired into the IOR makes the IIOP very hard to administer.
Future versions of the DCE-CIOP will use the DCE end-point mapper (which is
part of the license free version of the DCE-RPC) so that the end-point does
not have to be buried into the object reference.
Future versions will also use path names which can be resolved using XFN,
GDS, or CDS directory services for location. The use of the end-point
mapper and path name services will greatly simplify the administration of
CORBA systems. The tools for administering these location services are part
of DCE.
Network monitoring tools are being built to allow the networks to be
administered. These tools can be written at different protocol levels to
provide additional administrative information. The DCE-RPC is a protocol
level at which some of these tools are being written.
>
>MORE TRUTH: DCE is not as ubiquitous and universally accepted
>as its supporters would like to claim. An overwhelming majority of
>ORB products today contain no DCE-based technology. In fact,
>DEC's own ObjectBroker ORB product is (as described by DEC
>representatives at the Nashua OMG meeting) currently not
>built on DCE technology. Therefore, the criticism that "companies
>would have to deal with yet another RPC" is more appropriately
>applied to DCE-CIOP than UNO/GIOP.
HP, DEC, and IBM will be building ORBs which conform to the DCE-CIOP. HP
currently has a prototype of the DCE-CIOP running. As mentioned the DCE-RPC
is widely available, and will even more so in the near future.
>
>
>CLAIM: "DURING THE TASK FORCE MEETING... SUBMITTERS BEGAN TO
>CONVERGE...WOULD HAVE LED TO AN EFFECTIVE MERGER... IF DISCUSSIONS
>CONTINUE, THE TWO PROPOSALS CAN BE MERGED"
>
>TRUTH: The two proposals have already been merged in a way
>that makes the most technical and business sense for the
>OMG community. The current recommendation already includes
>the DCE-CIOP protocol as an optional Environment-Specific Inter-ORB
>Protocol. What DEC and HP seem to object to is the fact that
>the DCE protocol is not mandatory, and the GIOP is. If any point
>was made clear at the TF meeting, it was that the user community
>demanded a single, simple, mandatory inter-ORB protocol to guarantee
>"out-of-the-box" ORB interoperability. The DEC-HP merger proposals
>would create multiple, optional protocols with no guarantees of
>interoperability. HP's mail message suggests that "if two peer
>protocols are selected, the market and the industry will gain
>experience with both and be able to pick the protocol of preference."
>This statement is implying, incorrectly, that the motion before
>the TC denies customers the ability to choose the protocol of their
>preference. HP is failing to recognize that the ORB2 TF recommended
>that such choices be allowed to exist, and are in fact supported
>by the UNO submission architecture. The TF also insisted that making
>such choices must not compromise interoperability, and that low-overhead
>solutions were needed. It is these latter points that HP appears
>to be resisting.
>
The UNO submission did not specify a mandatory protocol for good reason. It
only specified that the IIOP would be more equal than any other protocol.
This is what DEC and HP objected to.
The reason it did not specify a mandatory protocol, is that the IIOP makes
no sense in many environments (telephone switching systems, DCE enterprise
systems, Novell network systems, etc.) Yet all these ORBs will be required
to support the IIOP or they can not be called CORBA compliant. This makes
no sense.
The OMG TC and the OMG board will have to decide if the ORB task force made
the right decision.
>MORE TRUTH: In fact, the two submitting groups have spent months in
>discussions, without yielding a compromise acceptable to both groups.
>There is no reason to believe that further discussions would be
>any more fruitful. The fundamental disagreement has not been over
>technical details, but over whether or not there should be a
>mandatory protocol, and which one it should be.
If your are opposed to working on an agreement, then there will be no
agreement. The TC should take in account that a small subgroup of its
membership is deciding what interoperability will be. This is not a very
open decision process.
>
>WHY YOU SHOULD VOTE YES ON THE INTEROPERABILITY RECOMMENDATION:
>
>The current recommendation has strong support from the ORB2 Task
>Force, where all of the technical arguments raised in the HP
>message were debated thoroughly. The final vote was 18 yes, 5 no,
>8 abstaining.
>
They are still being debated as this email message illustrates. More
technical details are being brought out. We contend that the debate was
ended too soon.
>The UNO proposal is a complete specification. It provides a comprehensive
>architecture, with complete detailed specifications for key elements,
>including the bridging interfaces, and the General Inter-ORB Protocol.
>These specifications provide a full, clear response to the Interoperability
>RFP.
>
The UNO specification contains some very good technology of which you are a
primary contributor. We don't think that it is yet complete. We think that
the communication section is under architected especially since it requirers
an OMG submission for hosting the GIOP on a new transport.
>The current recommendation provides reasonable guarantees of
>practical, low-cost ORB interoperability, by providing a simple
>mandatory protocol for inter-ORB communication.
Low cost to who.
>
>The current recommendation does not preclude the use of any other
>protocols or environments (such as DCE) for inter-ORB communication.
>Indeed, the UNO architecture provides specific features to allow open,
>flexible choices between a wide variety of interoperability mechanisms.
>For ORBs and customer installations with large investments in existing
>environments that provide environment-specific features (e.g., a particular
>[non-OMG] security or directory mechanism), ORBs are free to make
>whatever interoperability agreements are most advantageous to them.
>
But they must still implement the IIOP to be CORBA compliant.
>WHY YOU SHOULD NOT VOTE NO:
>
>A no vote will delay ORB interoperability for the entire community.
>The HP message seems to suggest that a rejection could be quickly and
>easily recovered from by simply accepting their demands and ratifying the
>decision. This is not true. A rejection would result in another
>protracted decision cycle, most likely delaying real ORB interoperability
>by over a year.
>
This argument has been continually used by the UNO group on why we should
not disagree with them. An interoperability specification which will become
a standard because it doesn't meet customer needs and market realities will
delay real ORB interoperability to a much greater extent then sending the
interoperability specification back the the ORB task force for further work.
If the task force cannot figure how to get agreements between the submitting
companies, then OMG should rethink its submission procedures.
>The objections raised by DEC/HP are without foundation. These issues
>were discussed in depth by the task force, and their decision clearly
>reflects the overwhelming consensus that the UNO submission was
>technically sound and complete.
Not complete depth as this message indicates.
>David Curtis
>Chief Technical Officer, Expersoft
>
Peter
=======================================================================
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
========================================================================
