5

私はしばらくの間、ソケットを介してxmlを送信するシステムに取り組んできました。そして、カスタムプロトコルの代わりにソケットよりもxmlを選択することの本当の利点が何であるかを私は本当に理解していませんでした。

しかし、私は多くの開発者（特に元々はWeb開発者）がこの種の実装（ソケット上のxml）を設定しているのを見ます。

私はそれがより「人間が読める」ものであることを理解しています（それは私が聞き続けていることです）。

だが、

  • Xmlには非常に多くの文字が含まれているため、実際にはコンテンツが非常に小さく単純な場合でも、巨大なメッセージが表示されます。

  • メッセージのサイズはさまざまであるため、特定の文字または文字列パターンでメッセージを終了することを保証する必要があります。

  • xmlを解析するときのオーバーヘッドが増えます

これらすべての理由から、固定サイズのメッセージを使用するカスタムプロトコルを使用してシステムを設定できる場合、新しいシステムでXMLoverSocketsを検討することに懐疑的です。送信される巨大なメッセージとパフォーマンスがクライアントサイズのxmlの解析に影響を与えることを回避します。

私はそのように考えるのは間違っていますか？システムアーキテクチャの観点から「最良」とは何ですか？

よろしく

4

7 に答える 7

6

XMLがネットワークを介してデータを送信するときに従来から使用されてきた主な理由は、XMLが拡張可能であるためです。それはあなたのアプリケーションをスケーリングし、他のアプリケーションがあなたの上に構築するための潜在的なプラットフォームに変えます、あるいはそれはすでに解決された問題を解決する必要なしに他のアプリケーションがあなたとより簡単に統合することを可能にします。

結局のところ、それは開発者が行うために支払われるものです。新しい問題を解決します。それらを作成しないでください。

Ryan Tomaykoは、妻にRESTを説明した方法に関するブログ記事でこれについて話しました。標準を使用すると、世界中の個々のシステムをネットワーク化して、大規模でまとまりのある、しかし個別のシステムを形成できることを強調しました。

独自のカスタムプロトコルを使用する場合、基本的には、アプリケーションを独自の小さな世界でのみ通信するように制限します。次に、別のシステムと接着するときが来ると、両端でさらに多くの統合作業が必要になります。

そうは言っても、JSONはXMLの代わりとして多くの注目を集め始めています。より軽量で、複数のプラットフォームで理解され、実際にはWebの言語であるJavaScriptにネイティブです。

どちらの選択も、経験豊富なすべての開発者が簡単に理解できるものを使用し、すべてのシステムが消費できるという点で優れています。

于 2012-05-21T07:42:14.503 に答える
4

ここに「最良の」決定はありません。それはすべてあなたの要件に関するものです。非常に高いパフォーマンスが必要な場合は、小さなメッセージでカスタムバイナリプロトコルを使用する必要があります。ただし、これには欠点もあります。XMLの主な利点は、非常に標準化された形式であり、さまざまなプラットフォームやアプリケーションから読みやすいことです。たとえば、cusomプロトコルでは、メッセージのシリアル化と逆シリアル化を実装する必要があります。さらに、XMLはカスタム形式よりもはるかに拡張可能です。

つまり、要約すると、それは実際にはシステムの要件によって異なります。

于 2012-05-21T07:40:49.150 に答える
4

カスタムプロトコルを使用することは、開発とテストに多くの労力を費やすことになり、不要になるため、お勧めできません。また、一般的な方法で設計するために多くの努力を払わない限り、これは特定の実装になります。XMLを使用すると、トランスポート自体がアプリケーションに拘束されることはありません。XMLは柔軟性と拡張性があるため、トランスポートに影響を与えることなく構造とコンテンツを変更できます。

ただし、ご指摘のとおり、XMLの使用には独自の欠点があります。それは不必要な体重移動を伴うことは事実です。ただし、JSONのような代替手段は、これらの問題を回避するための良いアイデアです。

于 2012-05-21T07:46:50.827 に答える
3

プロトコルがSockets上で実行されるという事実は、問題に直接関係しません。

多くの人がプロトコルのプレゼンテーション層にXMLを使用することを選択する理由は、主に、独自のプレゼンテーション層を指定して実装するための労力とコストを回避するためです。はい、メッセージサイズ、変更の可能性、実装コスト、およびその他の要因の間で異なるトレードオフが必要な場合は、XMLよりもこれらの要件に最適化されたプロトコルを設計できる可能性があります。または、多くの非常に優れた人々がXML設計に関与していることを考えると、より悪いものを設計することもできます（通常、長期的な要件が思ったものとは異なるためです。たとえば、次のようなものを設計することになります。優れたパフォーマンスですが、変更の可能性は非常に低いです）。しかし、あなたがあなたのデザインの良い仕事をするか悪い仕事をするかにかかわらず、

于 2012-05-21T08:57:50.580 に答える
3

設計上の決定はすべてトレードオフに関するものです。XMLが提供するもの、つまり読みやすさと自己記述性を列挙しました。また、記述言語（XSD）が付属しており、非常にポータブルです。

しかし、これらの利点には、あなたが言及する欠点が伴います。それでは、それらに1つずつ取り組みましょう。

冗長性

はい、XMLは冗長であり、自己記述的でテキストベースです。これは、パフォーマンスが懸念される場合にのみ実際に問題になります。それは...ですか？ポジティブなトレードオフはどうですか？

ここでの合理的な代替手段はJSONであることに注意してください。これは、同じように読みやすく、はるかに効率的です。

さまざまなサイズ

はい。ただし、これは接続レイヤーによって異なります。持続的接続（HTTPなど）がない場合、または独自の「フレーミング」を提供するプロトコル（AMQPやJMSなど）を使用している場合、これは問題ではありません。トランスポート層がそれを処理します。このホイールを再発明することを計画している場合、はい、ペイロードを変えるとプロトコルが難しくなります。しかし、プロトコル（特にすべてのエッジケースで）は十分に難しいものです。

オーバーヘッドの解析

これは、冗長性に直接関係しています。

于 2012-05-21T07:40:08.623 に答える
2

あなたがよく説明したように、XMLには独自の長所と短所があります。ネットワークトラフィックを削減するための代替手段が必要な場合は、データを圧縮し、独自のマーシャリング技術を備えたhttp://code.google.com/p/protobuf/を検討できます。そして、Webテクノロジーでよく知られている他の1つはJSONです。

システムアーキテクチャの観点から最も優れている点：それがWebであるかエンタープライズシステムインテグレーションであるかなどを定義する必要があります。それはすべて、設計しているシステムによって異なります。

于 2012-05-21T07:41:20.500 に答える
2

ホイールを再発明することは決して良い考えではありません。私は標準のHTTPプロトコルに固執し、XMLやJSONなどの相互運用可能なデータ交換形式を使用します。カスタムプロトコルを再発明する代わりに業界標準のプロトコルを使用すると、さらに多くのツールとサポートが見つかります。これは、ベストプラクティスの観点からです。もちろん、非常に具体的な要件がある場合は、さらにカスタマイズされたものを実装するのに十分な理由があるかもしれません。

于 2012-05-21T07:37:57.293 に答える