XMLメッセージング、パート1

XMLメッセージングは​​、ITの急速に成長している動的な領域を表しており、同時にエキサイティングで面倒な状況になっています。B2B交換やその他の形態の企業間電子通信が成長するにつれて、XMLメッセージングは​​これまで以上に広く展開されるようになります。

「XMLメッセージング」シリーズ全体をお読みください。

  • パート1:カスタムXMLメッセージ用の単純なXMLメッセージブローカーを作成する
  • パート2:SOAP方式でのXMLメッセージング
  • パート3:JAXMとebXMLは、XMLメッセージングの新しい標準を設定します

この記事では、最初にXMLメッセージングとそれが役立つ理由について説明します。次に、メッセージルーティング、変換、ブローカリングなど、特定のXMLメッセージング機能について詳しく説明します。最後に、XMLブローカーの簡単な例で締めくくります。概念を読んで理解したら、XMLメッセージングソリューションの実装に役立つシナリオを明確に理解する必要があります。

XMLメッセージングとは何ですか?

調査を開始するには、XMLメッセージングの基本的な前提と、メッセージングという用語の意味を理解する必要があります。この記事では、メッセージを次のように定義します。

ソフトウェアアプリケーション間で一緒に送受信されるデータフィールドのコレクション。メッセージには、ヘッダー(メッセージに関する制御情報を格納する)とペイロード(メッセージの実際のコンテンツ)が含まれます。

メッセージングは​​、メッセージを使用してさまざまなシステムと通信し、ある種の機能を実行します。RPC(Remote Procedure Call)指向の通信とは対照的に、操作を実行するためにメッセージを送受信するため、通信をメッセージ指向と呼びます。簡単な例えが役立つかもしれません:メッセージングをアプリケーションの電子メールと考えてください。実際、メッセージングには、電子メールメッセージを相互に送信する個人の属性の多くがあります。

以前は、メッセージ指向システムを使用または作業していたときは、TibcoのRendezvous、IBMのMQSeries、JMSプロバイダーなどのMOM(メッセージ指向ミドルウェア)製品を使用してメッセージを送信していました。非同期(一方向)ファッション。今日のメッセージングは​​、必ずしもMOM製品を使用していることを意味するわけではなく、非同期で通信していることを必ずしも意味するわけでもありません。むしろ、メッセージングは​​同期(双方向)または非同期のいずれかであり、HTTPやSMTPなどの多くの異なるプロトコルやMOM製品を使用できます。

なぜXMLメッセージングなのか?

なぜメッセージングを使用してシステムを開発したいのですか?メッセージングを有用な設計手法にする理由とその利点は何ですか?前述のように、2つのアプリケーションがネットワークを介して相互に通信する必要がある場合は、RPCまたはメッセージ指向の2つの選択肢から選択できます。 RPCベースのアプローチ(RMIはこのカテゴリに分類されます)を使用するということは、プロシージャコールのクライアント(または呼び出し元)が、呼び出したいプロシージャと、プロシージャに渡したいパラメータを知っていることを意味します。また、呼び出し元は、呼び出されたサーバー(アプリケーション)が要求を完了するまで待機したいと考えています。

2番目のアプローチ(メッセージ指向)では、呼び出し元は呼び出される正確なプロシージャを必ずしも知っているとは限りませんが、代わりにクライアントとサーバーの両方に認識されている特定の形式のメッセージを作成します。クライアントはメッセージを作成し、ネットワーク経由でサーバーに送信します。したがって、クライアントはサーバーまたはサーバーの手順に依存しませんが、メッセージ形式に依存します。また、通信は非同期で行われる可能性があります。つまり、クライアントは要求を送信しますが、応答を待機(ブロック)しません。これにより、サーバーが使用できなくなった場合(クラッシュなど)でも、クライアントは機能し続けることができます。クライアントがサーバーからより独立しているこの設計は、より疎結合であると見なされます。

メッセージ指向の設計を使用するかどうかを評価するときは、そのようなシステムの長所と短所を理解することが重要です。長所は次のとおりです。

  • 疎結合
  • より簡単なメッセージルーティングと変換
  • より柔軟なペイロード(たとえば、バイナリ添付ファイルを含めることができます)
  • 複数のメッセージを一緒に使用して、特定のプロシージャを呼び出すことができます

一般に、メッセージ指向のアプローチは、RPCアプローチよりも柔軟性があります。

今ここにいくつかの短所があります:

  • メッセージを介してクライアント/サーバー相互作用を開発することはRPCからの別のレベルの間接参照を表すため、RMIのようなRPCアプローチと比較して、メッセージ指向アプローチを使用してクライアント/サーバー相互作用を開発するにはより多くの作業が必要です。複雑さは、クライアント側(RPCアプローチでのプロシージャ呼び出しとは対照的に)およびサーバー側でメッセージ処理コードを使用してメッセージを作成することで追加されます。複雑さが増すため、メッセージ指向の設計は理解とデバッグがより困難になる可能性があります。
  • メッセージが送信されたプログラミング言語の型情報を失うリスクがあります。たとえば、Javaのdoubleは、メッセージのdoubleとして変換されない場合があります。
  • ほとんどの場合、メッセージが作成されたトランザクションコンテキストはメッセージングサーバーに伝播されません。

長所と短所を考慮して、メッセージ指向のアプローチをいつ使用する必要がありますか?最も一般的なシナリオは、クライアント/サーバー通信がインターネットを介して行われ、クライアントとサーバーが異なる会社に属している場合に発生します。このシナリオでは、2つの会社に手順のインターフェースについて合意させることはかなり難しいかもしれません。また、企業が同じプログラミング言語を使用したくない場合もあります。別の例では、関係する企業が非同期通信モデルを使用して、どちらも他のアプリケーションが稼働していることに依存しないようにすることができます。

もう1つの魅力的なメッセージングシナリオは、イベントが作成され、関係者によって消費されるイベントベースのシステムを開発しているときに発生します。ほとんどのGUIはイベントベースです。たとえば、関係者がイベントをリッスンし、それに基づいて何らかのアクションを実行するマウスクリックイベントを作成する場合があります。このシナリオでは、メッセージングアプローチを使用すると、イベント(またはシステム内のアクション)とサーバー上で実行されるイベントに対するシステムの反応との間の依存関係を取り除くことができます。

メッセージングについて少し理解したので、方程式にXMLを追加する準備が整いました。メッセージングにXMLを追加することは、メッセージに柔軟なデータフォーマット言語を利用できることを意味します。メッセージングでは、クライアントとサーバーの両方がメッセージ形式について合意する必要があります。XMLは、多くのデータフォーマットの問題を決定し、Rosetta Netなどの他のXML標準を追加することで、これを容易にします。メッセージ形式を作成するために追加の作業は必要ありません。

XMLメッセージブローカーは何をしますか?

メッセージブローカーは、メッセージ指向システムのサーバーとして機能します。メッセージブローカーソフトウェアは、受信したメッセージに対して操作を実行します。これらの操作には次のものが含まれます。

  • ヘッダー処理
  • セキュリティチェックと暗号化/復号化
  • エラーと例外処理
  • ルーティング
  • 呼び出し
  • 変換

ヘッダー処理

ヘッダー処理は通常、XMLブローカー内でメッセージを受信したときにメッセージで実行される最初の機能の1つです。ヘッダー処理には、着信メッセージのヘッダーフィールドの調査と、いくつかの機能の実行が含まれます。ヘッダー処理には、受信メッセージに追跡番号を追加することや、メッセージの処理に必要なすべてのヘッダーフィールドが存在することを確認することが含まれます。以下のXMLメッセージの例では、メッセージブローカーはtoヘッダーフィールドをチェックして、これがこのメッセージの適切な宛先であることを確認できます。

セキュリティチェックと暗号化/復号化

セキュリティの観点から、メッセージブローカーはいくつかの異なる操作を実行できますが、ほとんどの場合、認証、承認、暗号化というセキュリティの「ビッグ3」を実現する必要があります。まず、メッセージに認証に使用できるデータが含まれていると判断されると、メッセージブローカーはセキュリティデータベースまたはディレクトリに対してメッセージを認証します。次に、メッセージブローカーは、このタイプのメッセージと承認されたプリンシパルを使用して実行できる操作を承認します。最後に、メッセージブローカーに到着するメッセージは、何らかの暗号化スキームを使用して暗号化される場合があります。メッセージをさらに処理するためにメッセージを復号化するのはブローカーの責任です。

エラーと例外処理

エラーおよび例外処理は、メッセージブローカーによって実行されるもう1つの重要な機能です。通常、メッセージは、ブローカーに送信されたメッセージに十分または正確な情報が含まれていない場合に発生するエラーメッセージでクライアントに応答します(同期呼び出しを想定)。エラーまたは例外の別の原因は、要求を処理するときに発生します(実際には、メッセージのペイロードに基づいてプロシージャ/メソッドを呼び出します)。

ルーティング

Message routing is branching logic for messages. It occurs at two different levels in a message. The first, header-level routing, determines if an incoming message is bound for this application or needs to be resent to another application. The second, payload routing, determines which procedure or method to invoke once the broker determines that the message is bound for this application. Together these two types of routing enable a rich set of functionality when dealing with messages.

Invocation

Invocation means to actually call or invoke a method with the data (payload) contained in the incoming message. This could produce a result that is then returned through the broker back to the client. What is invoked could be anything, including an EJB Session bean, class method, and so on.

Transformation

Transformation converts or maps the message to some other format. With XML, XSLT is commonly used to perform transformation functionality.

An example XML message

Below you'll find an XML message used in the sample application that follows. Notice the header and body portions. This example is a "saveInvoice" type of message, in which the body contains an invoice that needs to be saved.

   companyReceiver companySender saveInvoice      John Smith 123 George St. Mountain View CA 94041   Company A 100 Main St. Washington DC 20015    IBM A20 Laptop 1 2000.00       

You may wonder whether there is an advantage to developing a custom XML message. Why not use one of the existing message standards like ebXML or SOAP to encapsulate the payload (the invoice)? There are a couple of reasons. The first is to demonstrate some of the contents needed in a message without all of the complexity of explaining a full-blown industry standard. Second, although the existing standards fill most needs, there still will be scenarios in which using a custom message will better fit the needs of a situation, much like the tradeoffs between using a higher-level protocol like HTTP or SMTP and using raw sockets.

A prototype XML broker implementation

Having discussed the reasons for using a messaging design in your application, we will now proceed to a prototype XML messaging broker implementation.

Why should you develop a custom message broker implementation instead of using an existing one? Well, because many of the implementations for XML messaging products are new, so it's important to know what goes into a basic implementation. Also, it's possible that because XML message brokers are somewhat immature products, you'll need to develop your own to get the features you want.

The basic broker presented here can service two types of messages: a request to create an invoice, which it stores on the filesystem, and a client code component, which just reads the XML message from a file and sends it.

The broker comprises three main parts: a listener piece that receives incoming messages on some transport (in this example there will only be an HTTP implementation provided); the main broker piece, which will decide what to do with an incoming message; and the invocation piece that will actually perform some logic based on the incoming message. Let's look at each in more detail.

Receive the message from the transport

メッセージは最初にブローカーのリスナー部分に遭遇します。ほとんどのXMLメッセージブローカーは、HTTP、SMTP、JMS(特定のベンダーの実装)など、さまざまなトランスポート(プロトコル)をサポートしています。私たちのブローカーは、輸送部分を分離することによってこれを可能にします。以下に示す部分は、特定のトランスポートでメッセージを受信し、着信メッセージを文字列変数に配置して、ブローカーのシングルトンを呼び出すだけです。