Googleがバイナリエンコード形式「Protocol Buffers」を公開

作者 Werner Schuster , 翻訳者 編集部 投稿日 2008年7月30日

セクション

デベロップメント,

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

.NET ,

Ruby ,

SOA ,

パフォーマンス&スケーラビリティ ,

Webサービス ,

Java ,

Architecture

タグ

CORBA ,

XMLスキーマ ,

Google ,

分散プログラミング

Googleは最近、データ交換フォーマット「Protocol Buffers」をオープンソースとして公開した(リンク)。その平凡な名前の裏には、次の要素が隠されている。

• データフォーマットを記述するIDL
• IDLで記述されたフォーマットをエンコードするバイナリエンコード方式
• コードジェネレータによるデータバインディングのサポート、GoogleはC++、Python、Java実装を提供

IDLはデータフォーマットの記述を可能とし(リンク)、ここに、Protocol Buffersプロジェクトページからの一例を示す(リンク)。

message Person { 
  required int32 id = 1;   
  required string name = 2;
  optional string email = 3; 
} 

フィールド名に割り当てられる数値（「タグ」）は、フォーマットの進化が可能なように明示的に指定する必要がある。数値が自動的に割り当てられたとしたら、フォーマットへの変更（たとえば、新規フィールドの挿入）によって問題が生じるであろう。なぜか? それは、バイナリフォーマットでは、タグは特定のバイトの塊がどんなフィールドであるかを（プロトコル記述で）記述するために使用されるからである。未知のタグは無視されるという規則とともに、明示的に割り当てられたタグ数値では、フォーマットの進化に合わせて新規フィールドを追加することができ、互換性は維持される。

 

.protoファイルに保存されたフォーマット記述を使用するには、それらをソースコードにコンパイルする。Googleのリリースは、C++、Python、およびJavaをサポートしている。その他、Ruby、Erlang、Perl、Haskellなどの言語のサポートも順次進めていく予定だ(リンク)。別の言語のサポートを追加したいと思っている人は皆、.protoファイルのリバースエンジニアリングされた文法をEBNFとして歓迎するであろう(リンク)。

言語サポートとは、.protoファイルで定義されたフォーマットにマップするクラスで構成されるように、.protoファイルがターゲット言語でコードに変換されることを意味する。これにより、バイナリからオブジェクトを取得し、オブジェクトのフィールドを修正し、ステートをもとのバイナリフォーマットにシリアライズすることが可能である。

Googleの新規プロジェクトの公開時はいつもであるが、Protocol Buffersのリリースはかなりの物議を醸しだし、多くのブログ投稿でそれがテーマとして取り上げられた。Googleのブログのリリース記事では、Protocol Buffersの公開理由について説明され、XMLがエンコードフォーマットとして非常に非効率的であることが言及された。このことがブログ投稿の嵐を引き起こし、Protocol BuffersはXMLの終焉を意味するという主張と、Protocol BuffersはXMLより劣っているという主張が展開した。Ted Neward氏は、この状況を次のように結論付けている(リンク)。

結局のところ、疎結合で最大の柔軟性を提供するエンドポイントを望むのであれば、基調となるトランスポートに応じてSOAPエンベロープまたはRESTfulエンベロープのいずれかでラップされたXMLに固執してください（つまり、RESTはRestafarian（REST主義者）によって明確に定義されたことがないので、HTTPを意味します）。バイナリフォーマットを必要とする場合は、Protocol Buffersは確かに1つの答えではありますが、ICEやCORBAも（この分野における利用者の緩やかな減少の結果、その魅力を急速に失いつつありますが）候補としてあります。Googleの名を冠しているというだけで、各ソリューションの技術的な強みや弱みを見失ってはいけません。 

XMLやJSONとのあらゆる比較で、Protocol Buffersが既存の技術の再実装であるということを見落としてしまいがちである。すでに触れたものに次いで、広く使用されている競争技術がASN.1(リンク)である。ASN.1は数十年前から存在するが、やや不明瞭であまり知られていないように思われる。ASN.1で記述されたフォーマットの小さな例を見ると(リンク)、これは一風変わっている。

• X.509証明書（SSLを含め、多くのシステムでPKIに利用される）
• LDAP
• 電子メール暗号化用のCMS（Cryptographic Message Syntax; 暗号メッセージ構文）
• RSA鍵のPKCS#1
• 3G携帯電話ネットワーク

 ASN.1には多くの用途がある(リンク)。たとえば、ASN.1を使用してエンコードされたデータは、近頃では電気通信を利用する誰もが使用している。ASN.1はProtocol Buffersと同様の概念に基づいている。つまり、IDLを使用してフォーマットを記述し、コンパイラを使用してターゲット言語に必要なコードを生成する。しかし、重要な違いとして、ASN.1の場合は複数のエンコード方式があり、目的に応じてエンコード方式をリストから選択できる。エンコードのリストには、少しの違いがとても大きな違いを意味するデジタル署名に関しては欠かせない、エンコードに厳しい規則を施行するCER（Canonical Encoding Rules）や、PER（Packed Encoding Rules）などが含まれる。XER（XML Encoding Rules）は、データをXMLとしてエンコードすることを可能にする。これは基本的にASN.1をXML Schemaの代替にする。Fast Web Servicesは(リンク)、XML SchemasをASN.1にマップして、ASN.1の、より効率的なエンコードを、それらをサポートするエンドポイント間で使用できるようにする技術である。

GoogleのProtocol Buffersに似た別の技術として、同様の方法で機能するFacebookの(リンク)Thriftがある（Protocol BuffersとThriftの対比を参照(リンク)）。それほど成功していない技術が、Binary XMLである。これは、長年にわたりXMLの場面で思案されてきたが、まだ結論に達していない。Protocol Buffersに関する質問を受けて、ErlangのクリエイターであるJoe Armstrong氏は、構文解析を必要としないプログラム用バイナリフォーマットとしてUBFについて述べた(リンク)。

これらの技術の共通の目標は、効率を高めることである。圧縮によりデータサイズを節約できるため、ワイヤで送信されるデータ量は重要でないと推測することは可能だ。しかし、圧縮／圧縮解除は、データの使用後／使用前に実行する必要がある余分な手順である。実際の構文解析プロセスは依然として大量のデータを使用している。XMLの場合、同じ要素タグを何度も繰り返し読み取ることに値する。これをProtocol Buffersの数値タグと比較してもらいたい。もちろん、この改善は実際のフォーマットに依存する。大部分が文字列で構成されているフォーマットは、大部分が数値データで構成されているフォーマットほど利益をもたらさないであろう。

また、Mark Pilgirm氏は、Protocol Bufferに対する反応をリストにまとめている(リンク)。Steve Vinoskiのブログに、おそら(リンク)くGoogle内でも大いに使用されているだろうが、Protocol Buffersの別の側面について触れたGoogle社員のコメントがある。

効率上の理由からバイナリフォーマットについて検討する状況に置かれたことがありますか? ある場合、既存の技術を使用しましたか、自作しましたか?

原文はこちらです：http://www.infoq.com/news/2008/07/google-protocol-buffers

• 次へ >