Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change 
notification.

The "ProtocolBuffers" page has been changed by SteveLoughran:
http://wiki.apache.org/hadoop/ProtocolBuffers?action=diff&rev1=2&rev2=3

Comment:
I can't believe we have two binary protocols in the ASF, WS-* and avro yet 
Hadoop now depends on something external. 

   * Excellent support for forward versioning, in which a remote service can 
support older versions of a client.
   * Workable support for backward versioning, in which a remote service can 
support newer versions of a client. This requires more careful programming in 
the service code.
  
- It's closest equivalent formats are [[http://thrift.apache.org/|Apache 
Thrift]]. 
+ It's closest equivalent formats are [[http://thrift.apache.org/|Apache 
Thrift]] and the -in Apache incubation- 
[[http://incubator.apache.org/etch/|Etch]] protocol
  
  The protocol is significantly different from the Web Services WS-* stack, 
that has been criticised by [[SteveLoughran|Steve Loughran]] and Edmund Smith 
in  [[http://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf|Rethinking the 
Java SOAP Stack]] and 
[[http://steve.vinoski.net/pdf/IEEE-RPC_Under_Fire.pdf|RPC under fire]] in that 
the WS-* language for describing data XML-Schema, is not completely mappable to 
the Object-Oriented model of today's languages, yet the WS-* stacks attempt to 
seamlessly do so, even across languages. Loughran and Smith regard such an O/X 
mapping to be as insolvable as a perfect O/R Mapping, and hence doomed. Instead 
SOAP stacks should embrace the XML nature of documents and use mechanisms such 
as !XPath to directly work with the XML content. No widely used SOAP stack does 
this, as WS-* developers appear to prefer to write implementation-first code in 
which the datatypes are written in their native language, the interface 
specification reverse-engineered from this and then everyone hopes that this 
specification will be convertable into usable datatypes in other languages, and 
stable across protocol versions.
  

Reply via email to