4

背景
現在の Web アプリケーション内でのメッセージングの効率性を調査し、XML の代替手段の使用を検討しています。これは大学のプロジェクトであり、その結果は公開されます。コミュニティの参加が増えるほど、返される結果の価値が大きくなります。

次のことを行うために、できるだけ多くの実際の XML の使用例が必要です。

  • ホスト A がホスト B
    と通信するときに、XML がどのように使用されるかを完全に理解する。現実はかなり違うかもしれません。
     
  • 架空のデータではなく、実際のデータに対してテストを実行する 実際のデータセット
    に対してテクノロジー X と比較して XML がどのように機能するかは、任意のデータ セットに対してXML がテクノロジー X とどのように比較されるかと同じくらい重要です。
     

  •  要素のみ、要素といくつかの属性、または最小限の要素と大量の属性の使用など、XML の使用パターンを特定して測定します。

質問

Web アプリケーションの世界で XMLをどのように使用しますか?

ホスト B が XML 構造のデータを HTTP 経由でホスト A に返すと、何が返ってくるでしょうか? これは、AJAX 環境でデータを返すサーバー、または 1 つ以上の他のサーバーからのデータを照合する 1 つのサーバーの場合があります。

理想的な答えは次のとおりです。

  • HTTP 応答内の XML の実例
  • 該当する場合、上記をリクエストするための URL
  • 必要に応じて、データが何を表しているかについての説明
  • 明白でない場合、そのようなメッセージが交換されている理由の説明 (たとえば、ユーザー要求を満たすため、ホスト X がホスト Y にヘルス ステータス レポートを返すため)

どんな例でも大歓迎ですが、あなたが作成、開発、または取り組んだアプリケーション/サービスからの例を希望します。5 行の XML 文書から 10,000 行のモンスターまで、どんなものでも素晴らしいでしょう。

あなたの例での XML の使用に関するあなた自身の意見も素晴らしいでしょう (たとえば、要件 X/人 Y のために XML 構造の応答を実装しましたが、...; または、XML を使用して[本当に正当な理由]であり、それが仕事に最適な選択だからです)。

更新
一般的に XML のトピックに関するすべての回答に非常に感謝していますが、私が本当に探しているのは、XML を含む HTTP 応答本文の実際の例です

私は現在、XML の歴史、どのような一般的な代替案が存在する可能性があるか、および特定のシナリオに対する機能と適合性がどのように比較されるかについて、かなり認識しています。

現在の使用法が正しいか適切であるかに関係なく、HTTP ホスト間のデータ交換で XML が現在どのように使用されているかを理解することで、より大きな利点が得られます。XML が誤って適用された例は、XML が正しく適用された場合と同じくらい価値があります。

4

10 に答える 10

3

必要以上に使わないようにしています。クライアントとサーバーがお互いを認識せず、独立して実装されているアーキテクチャ、またはAPIがクライアントから独立して開発されているアーキテクチャでの伝送プロトコルとしての位置付けは間違いありませ。それはまた、同じ推論が当てはまる永続的な場所を持っており、私はその領域でははるかに少ないことに反対します。

ただし、クライアントとサーバーが同じチームによって実装されている場合、人間が読める形式で2つの間を行き来することはほとんど意味がなく、ほとんどの場合、(処理の観点から)より高速で安価な代替手段があります。クライアントとサーバーのテクノロジーは異なります。

伝送プロトコルに私の意見を集中すると、帯域幅と処理能力が貴重であった「悪い」古いクライアント/サーバー時代にXMLが到着する前に、プロトコル(通常はバイナリ)を設計するのはアーキテクトの仕事でした。パケットサイズが最小化される効率と速度。明らかな制限は、ハンドシェイクが非常に具体的であり、バイナリダイアレクトが公開されない限り理解できないことです。利点は、それが非常に効率的であり、手元のアプリケーションに合わせて高度に最適化できることでした。非常に多くの場合、バイナリ形式が公開されました(古いExcel BIFF仕様を見たことがありますか?プロトコルではなく、バイナリ形式の公開の例です)。

HTTPのXML、つまりSOAPはそれを破りました。理論的根拠は非常に正気で、ハンドシェイクのプロトコルが広く理解されており、一種のコンピューターエスペラントであるため、クライアントアーキテクチャとサーバーアーキテクチャを分離し、開発のペースと内部を完全に別々に決定できます。さらに、クライアントの切り替えは新しいクライアントの実装の問題であるという約束を持って、クライアントの要件に対して将来にわたって利用できるようにします。さらに、XMLパーサーを使用するすべてのJoeがAPIを使用できるようにします。すべての素晴らしいものと非常によくマークされたアーキテクチャのキノコ狩りにつながりました-それは完全に良いです。

したがって、この提案の力はかなりの程度まで現れており、明らかに利点がありますが、a)この要件はしばしば誇張されており、b)XMLプロトコルは非常に緩慢に実装されていることが多く、処理コストをほとんど考慮していないと思います。意味する。さらに、元々正しい推論が過激派の宗教の事例に取って代わられ(私は投票されたに違いない)、同じクラス内の関数呼び出し間でXMLを渡すコードを見て、正確に将来を見据えた理論的根拠と機能分離の引数を使用しています。明らかにボンカーです。

ですから、私の信条は、コミュニケーションを効率的かつ効果的にすることです。それが任意の未知の消費者に一般化されたAPIとプロトコルを提供することを意味する場合、XMLは非常に良い選択です。それが非常にホットでスケーラブルなクライアント/サーバー(つまりWeb)アーキテクチャを作成することを意味する場合、私はバイナリプロトコルを使用しようとし、多くの場合、独自のプロトコルを使用します。

JSONの出現は、XMLバンドワゴンのレイヤーが多すぎるという事実を証明しています。JSONは、一般性を維持しながら構造要素を短縮し、それによってより小さなパケットの利点を得る試みです。AdobeのAMFのようなプロトコルは、一般的にはるかにコンパクトで、ほぼ完全にバイナリです。

そして、そこに未来があると思います。XMLがインターフェースの公開のために表すすべての利点を維持することは可能であると確信していますが、それを劇的に調整し、プロセッサーと帯域幅の集中を減らすことができます-少なくともそれが開発者およびアーキテクトとしての私の使命です。

平均的なクライアント/サーバーリクエストがサイズの1/10であり、どちらの端にもテキスト解析がなかったが、インターフェイスの一般性は維持されていたと想像してください。それを受け入れない開発者は誰も知りません。

于 2008-12-13T23:59:46.133 に答える
2

私のアドバイスは、XMLをスキップして、JSONのようなもっと単純なものを調べることです。XMLが提供するものは2つだけです。

1)複雑なデータをシリアル化する「標準化された」方法2)上記のシリアル化の正確さを(DTDを介して)検証する方法

「標準化」が引用符で囲まれていることに注意してください。標準化されているのは、タグのフォーマット方法だけです。タグの意味はまったく標準ではありません。結局、XMLが提供するのは、自分で作成する必要のない優れたパーサーだけです。

渡すデータを単純な文字列、配列、または連想配列(またはハッシュ)として表すことができる場合、XMLはやり過ぎです。

于 2008-12-13T23:46:56.547 に答える
2

おそらくあなたが望む答えではありませんが、私はXMLを使用したことがありません.XMLは複雑すぎます.

于 2008-12-13T23:07:48.983 に答える
1

残念ながら、ビジネス上/法律上の理由から、実際のデータを提供することはできません。

私の経験では、xmlは、バックエンドの90%以上の標準形式であり、これを操作するためのツールが普及していることと、ほとんどの開発者がそれに関するいくつかの経験。

グーグルのプロトコルバッファのようなものは多くのタスクにとってより効率的かもしれませんが、「エンタープライズ」の経験を持つほとんどのプログラマーがすでに使用方法を知っているフォーマットの便利さと安全性はビジネスケースを作るのが難しいです。

外の世界にサービスを販売している場合、xmlベースのインターフェースを提供すると、販売がはるかに簡単になります。CIOは「xmlベースのWebサービス」と読み、CIOは「わかりました。私のチームはそれを知っています...」と言います。

Xmlは常に(決して議論しない)仕事に最適なツールではありませんが、その遍在性、およびそれを操作するための既存のコードベースとスキルセット(良い、悪い、平凡)の量は、しばしばそれを候補者の頭に押し付けます列。

于 2008-12-13T23:45:02.060 に答える
1

XML の代替であり、そのコンパクトさから広く使用されている JSON も学習することをお勧めします。

于 2008-12-13T23:04:04.293 に答える
1

私は Web アプリケーションで XML を何度か使用しました。すべての時間は、SOAP Web サービスを介して行われました。これは、SOAP Web サービスの優れた組み込みサポートを備えた Visual Studio でプログラミングしているためです。AJAX (クライアント エンド) と .NET (サーバー間通信のサーバー エンド) の両方から簡単に使用できる OOP ラッパーを自動的に生成します。

例を投稿できるとは思いませんが、とにかくあまり変わらないと思います。

于 2008-12-14T00:53:52.310 に答える
1

XML がバイト効率の良い言語だとは思いませんが、XML の目的はそれではありません。XML が提供するものは、プロトコルを構築できる優れたインフラストラクチャです。私が取り組んでいる製品の場合、SOAP を使用してビジネス データを外部システムとの間で送受信しますが、SOAP は健全で一般的なメッセージング プロトコルであることを受け入れています。同様に、SAML アサーションを使用して、システム間で認証データを交換します。

于 2008-12-14T00:50:22.940 に答える
1

XML を使用して満たしたニーズの例を 2 つ挙げます。

  1. 多くの UNIX サーバーから収集したファイル割り当てに関するデータを通信し、詳細を分析のために Windows サーバーに送信する必要がありました。詳細と要約の両方が、Web アプリケーションを介してグラフィカルに表示されます。

  2. 後で検索して「再生」するために、複数の形式のフォーム応答を 1 つのリポジトリに保存する必要がありました。フォームは、Web アプリケーション内で生成、保存、検索、および再生されます。

どちらの場合も、大まかに構造化されたデータを自己定義形式で伝える機能が必要でした。どちらの場合も、送信プロセスが簡単に生成でき、受信プロセスが保存 (本質的に単一の長い文字列)、検索、デコードが簡単で、人間が簡単に読み取って理解できる汎用的な XML 構造を発明しました。そして、私たちがずっといなくなった後。XML 以外の構文を発明することもできましたが、当時は誰もそれ以上の構文を思いつきませんでした。データは専有と見なされるため、具体的な例を共有することはできません。

于 2008-12-14T03:40:45.453 に答える
0

Eucarisは、車の登録データを取得するためのWebアプリケーションです。バックエンドは、要求メッセージと応答メッセージにXSDタイプのXMLデータを使用します。

于 2008-12-13T23:36:48.957 に答える
0

他の多くの人と同じように、ある時点で SOAP と XMLRPC を試してみましたが、ブラウザーのサポートが非常に弱いことがわかり、MSXML が入力を妨害したときにアドホック パーサーに "フォールバック" する必要がありました。私の netMail アプリケーションの初期のバージョンはXML を使用していましたが、MSIE は単純に XML 解析の速度が十分ではありませんでした。本当に興味があるなら、私はまだ XML 実装を持っています。

ここ数か月で対処しなければならなかった現実世界の例として、すぐに 2 つの例が思い浮かびます。

Ingram-Micro の XML 順序付けインターフェイスを処理する際、メッセージはすべての要素の順序に依存し、エンコードの問題に非常に敏感です。標準の XML 処理ツールを使用して対話する方法はまったくありませんでした。アドホック ソリューションの方が優れていたはずです。なぜなら、要素がどの順序で入ったかに疑問の余地がないからです。交換は、プッシュ メソッドとプル メソッドの両方で実行されます。私たちのサーバーがデータを IM-XML のエンドポイントに POST し、そのサーバーがデータを POST します。

MRIS の XML フィードは、<Data Separator="~"> のような行と、一連の - 区切りデータで構成され~ます。フィードは何メガバイトもあり、"XML" の代わりに行指向の読み取り + 分割のアプローチを採用するだけで、より少ないメモリでより高速にジョブを実行できます。「XML」データは、HTTP GET 経由で定期的にダウンロードされます。

XML はもう使用していません。常にアドホック パーサー。私は、XML は信じられないほど近視眼的な設計上の決定であり、せいぜい素朴あり、それ以外の場合は実に愚かであると考えています。

ほとんどの場合、ブラウザーが関係している場合は生の JavaScript 式 (多くの場合 JSON と呼ばれます) を使用し (単純にeval「可能な限り高速」であるため)、それ以外の場合は S 式を使用します。

申し訳ありませんが、Web 上の適切な XML の例を参考にすることはできません。私は単に何もないと思います。

于 2008-12-14T00:42:14.830 に答える