第3章 サービスとメッセージ

ここから、サービス指向アーキテクチャーの原理を保ちつつ、JBoss Enterprise Service Bus にあるものはすべてサービスまたはメッセージのいずれかと考えてください。コンセプト別に考えると、SOAP がどのように機能するかより早く理解することができます。
  • サービスはそれぞれ、ビジネス論理や統合ポイントをレガシーシステムでカプセル化します。
  • メッセージを使い、クライアントとサービスは互いに通信します。
次のセクションより、サービスとメッセージがどのようにサポートされるかを説明します。

3.1. サービス

JBoss Enterprise Service Bus では、サービスは「順番にメッセージを処理するアクションクラスの一覧として定義されます。
この定義が指すアクションクラスの一覧とは、アクションパイプラインのことです。
サービスは、リスナーの一覧を定義することもできます。Listeners は、action pipeline へメッセージを送るため、サービスのインバウンドルーターとして機能します。
下記は非常に簡単な設定です。ここでは、メッセージの内容をコンソールに出力する単一サービスを定義しています。
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" invmScope="GLOBAL">

<services>
    <service category="Retail" name="ShoeStore" description="Acme Shoe Store Service">
        <actions>
            <action name="println" class="org.jboss.soa.esb.actions.SystemPrintln" />
        </actions>
     </service>
</services>

</jbossesb>
サービスは category 属性と name 属性を持っています。JBoss ESB がサービスをデプロイする時、これらの属性を使用してサービスのリスナーをエンドポイントとしてサービスレジストリに登録します。クライアントは ServiceInvoker クラスを使用してサービスを呼び出すことができます。
ServiceInvoker invoker = new ServiceInvoker(“Retail”, “ShoeStore”);
Message message = MessageFactory.getInstance().getMessage();

message.getBody().add(“Hi there!”);
invoker.deliverAsync(message);
この例では、ServiceInvokerServices Registry を使用して Retail:ShoeStore サービスが使用できるエンドポイントのアドレスをルックアップします。また、クライアントから使用できるサービスエンドポイントの 1 つにメッセージを送る処理をすべて行います。メッセージのトランスポート処理はクライアントに対して完全に透過的です。
エンドポイントアドレスが ServiceInvoker に渡されるタイミングは、サービスに設定されているリスナーの種類により左右されます。例えば、JMS、FTP、HTTP などの種類です (上記の例では、リスナーは定義されていませんが、invmScope="GLOBAL" を使うことで、サービスの InVM listener が有効になっています)。
InVM トランスポートは、Enterprise Service Bus の機能で、同じ Java 仮想マシン (JVM) 上で実行しているサービス同士の通信ができます。

重要

追加のエンドポイントを有効にするには、明示的にリスナーの設定をサービスに追加する必要があります。
2 種類のリスナー設定に対応しています。サポートされるリスナー設定:
  • ゲートウェイリスナー
    ゲートウェイリスナーの設定は、ゲートウェイエンドポイントを提供します。エンドポイントタイプは、ESB デプロイメント外部からメッセージのエントリポイントを提供します。また、サービスの action pipeline へ送る前にメッセージペイロードを ESB Message へラップし、メッセージペイロードを「正規化」します。
  • ESB 対応リスナー
    ESB 対応のリスナーは、ESB 対応のエンドポイントを提供します。これは、ESB 対応コンポーネント間で ESB メッセージを交換する際に使用するエンドポイントのタイプです(たとえば、ESB 対応リスナーを使い、Bus 上でメッセージの交換ができます)。
この例は、ShoeStore Service に JMS ゲートウェイリスナーが追加される方法を示しています。
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/
                                       trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd">
<providers>
    <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
        <jms-bus busid="shoeStoreJMSGateway">
            <jms-message-filter dest-type="QUEUE" dest-name="queue/shoeStoreJMSGateway"/>
        </jms-bus>
    </jms-provider>
</providers>

<services>
    <service category="Retail" name="ShoeStore" description="Acme Shoe Store Service"             
                                                                   invmScope="GLOBAL">
<listeners>
    <jms-listener name="shoeStoreJMSGateway" busidref="shoeStoreJMSGateway" 
                  is-gateway="true"/>
</listeners>
        <actions>
            <action name="println" class="org.jboss.soa.esb.actions.SystemPrintln" />
        </actions>
     </service>
</services>

</jbossesb>
上の例では、バスの <providers> セクションが設定に追加されたのが分かるでしょう。ここで、エンドポイントに対するトランスポートレベルの詳細を設定します。この場合、<jms-provider> セクションが追加されました。これは、Shoe Store JMS キューの <jms-bus> 1 つ定義するのが目的です。このバスは、Shoe Store Service で定義されている <jms-listener> 参照されます。この Shoe Store は InVM や JMS ゲートウェイエンドポイントを使い呼び出し可能となります (ServiceInvoker は、常にサービスのローカル InVM エンドポイントがあればそれを優先的に利用します)。

3.2. メッセージ

JBossESB 内のクライアントとサービス間の対話はすべてメッセージの交換によって発生します。疎結合を促進するため、メッセージ交換パターン (MEP) を使用した開発が推奨されます。要求と応答は、必要な場合にインフラストラクチャーやアプリケーションによって相互に関連付けられる、独立したメッセージでなければなりません。このようにして構築されたアプリケーションは耐障害性が高く、デプロイメントやメッセージ配信の要件に対して開発者はより柔軟に対応できるようになります。
サービスの疎結合や堅牢な SOA アプリケーションを確保するため、次のガイドラインが推奨されます。
  1. 要求応答アーキテクチャーでなく一方向メッセージを使用します。
  2. 交換されたメッセージ内で規定の定義を維持します。後で実装の変更が大変難しくなるため、バックエンド実装の選択を公開するサービスインターフェースを定義しないようにしてください。
  3. メッセージペイロードに拡張可能なメッセージ構造を使用します。これにより、変更をバージョン化して後方互換性を維持することができます。
  4. 極端に粒度が細かいサービスは開発しないようにしてください。これは、簡単に環境の変化に対応できないような非常に複雑なアプリケーションが必要になることが多いためです (SOA のパラダイムは分散オブジェクトではなく、1 つのサービスである点を忘れないでください)。
リクエストとレスポンスの一方向メッセージ配信パターンを使用している場合は、メッセージ内でのレスポンスの送信先に関する情報を常にエンコードするようにします。このような場合は、必須条件となっています。メッセージボディ (ペイロード) (アプリケーションが処理) にこの情報を置くか、最初のリクエストメッセージの部分に置きます (エンタープライズサービスバスのインフラストラクチャーが処理)。
ESB の中心がメッセージの概念で、この構造は SOAP の構造と似ています。
<xs:complexType name="Envelope">
	<xs:attribute ref="Header" use="required"/>
	<xs:attribute ref="Context" use="required"/>
	<xs:attribute ref="Body" use="required"/>
	<xs:attribute ref="Attachment" use="optional"/>
	<xs:attribute ref="Properties" use="optional"/>
	<xs:attribute ref="Fault" use="optional"/>
</xs:complexType>
以下に示すように図を用いてその基本的なメッセージの構造を表すことができます (本セクションの残りの部分で、これら各コンポーネントについて詳しく見ていくことにします)。
メッセージの構造は、UML でも表記できます。
メッセージの基本構造

図3.1 メッセージの基本構造

各メッセージは org.jboss.soa.esb.message.Message インターフェースの実装です。このパッケージには、メッセージ内の各種フィールドのインターフェースが同梱されます。
public interface Message
{
	public Header getHeader ();
	public Context getContext ();
	public Body getBody ();
	public Fault getFault ();
	public Attachment getAttachment ();
	public URI getType ();
	public Properties getProperties ();

	public Message copy () throws Exception;
}

警告

JBossESB では、アタッチメントとプロパティもボディ同様に処理されます。これらの一般的な概念については現在再評価中で、今後のリリースで大幅に変更される可能性があります。
ヘッダーは、エンドポイント参照形式のメッセージルーティングとアドレスの情報で構成されています。また、ヘッダーには、メッセージを一意に特定する際に使用する情報も含まれています。JBoss Enterprise Service Bus は、W3C 作成の WS-Addressing 規格ベースのアドレススキームを使用しています(org.jboss.soa.esb.addressing.Call クラスに関して学習するには、次章を参照してください)。
public interface Header
{
	public Call getCall ();
	public void setCall (Call call);
}
コンテキストには、トランザクションコンテキストやセキュリティコンテキストなどのセッション関係の情報が格納されます。JBossESB では、ユーザー拡張のコンテキストにも対応しています。

注記

JBoss Enterprise Service Bus のバージョン 5 からはじめて、ユーザー拡張のコンテキストに対応することになります。
ボディは一般的にメッセージの「ペイロード」を格納します。ボディを使用して任意数の異なるデータタイプを送信することができます (ボディ内における単一データ項目の送信や受信に制限はありません)。このようなオブジェクトがメッセージボディへシリアライズされる方法やメッセージボディからシリアライズされる方法は、オブジェクトタイプによって異なります。

警告

メッセージのボディから/へシリアライズしたオブジェクトを送信する際は十分に注意してください。シリアライズ可能なものがすべて受信者側で意味があるわけではありません。例えば、データベース接続などです。
public interface Body
{
  public static final String DEFAULT_LOCATION = 
  "org.jboss.soa.esb.message.defaultEntry";

	public void add (String name, Object value);
	public Object get (String name);
	public byte[] getContents();
	public void add (Object value);
	public Object get ();
	public Object remove (String name);
	public void replace (Body b);
	public void merge (Body b);
  public String[] getNames ();
}

重要

ボディのバイト配列コンポーネントは JBoss ESB 4.2.1 で廃止されました。継続してバイト配列とボディ内に格納される他のデータを使用したい場合は、固有の名前に add を使用してください。クライアントとサービスに対して同じバイト配列の場所が必要な場合、JBoss ESB が使用する ByteBody.BYTES_LOCATION を使用できます。

警告

複数のサービスやアクションが互いのデータをオーバーライドしないよう、デフォルトの名前付きオブジェクト (DEFAULT_LOCATION) は注意して使用してください。
不良はエラー情報を伝達するために使用されます。情報はメッセージボディー内に表示されます。
public interface Fault
{
	public URI getCode ();
	public void setCode (URI code);
	
	public String getReason ();
	public void setReason (String reason);
	
	public Throwable getCause ();
	public void setCause (Throwable ex);
}

警告

JBossESB では、アタッチメントとプロパティもボディ同様に処理されます。これらの一般的な概念については現在再評価中で、今後のリリースで大幅に変更される可能性があります。
メッセージプロパティを使用して、追加のメタデータを定義します。以下にこれらのメッセージプロパティを提示しています。
public interface Properties
{
	public Object getProperty(String name);
	public Object getProperty(String name, Object defaultVal);
	
	public Object setProperty(String name, Object value);
	public Object remove(String name);
	
	public int size();
	public String[] getNames();
}

注記

java.util.Properties を使用する properties はまだ、JBoss Enterprise Service Bus には実装されていません。これは、利用可能なクライアントやサービスのタイプを制限するためです。同じ理由から、Web Services スタックもこれらのプロパティを実装しません。この制約に対応するには、現在の抽出に java.util.Properties を埋め込んでください。
メッセージには、メインのペイロードボディには表示されない添付 (イメージ、図、バイナリドキュメント形式、zip ファイルなど) が含まれることがあります。Attachment インターフェースは、名前の付いた添付と名前のない添付の両方をサポートします。JBossESB の現在のリリースでは、Java でシリアライズされたオブジェクトのみが添付として扱われます。今後のリリースではこの制限が解除される予定です
public interface Attachment
{
	Object get(String name);
	Object put(String name, Object value);
	
	Object remove(String name);
	
	String[] getNames();
	
	Object itemAt (int index) throws IndexOutOfBoundsException;
	Object removeItemAt (int index) throws IndexOutOfBoundsException
	Object replaceItemAt(int index, Object value)
	throws IndexOutOfBoundsException;
	
    void addItem		(Object value);
	void addItemAt	(int index, Object value)
									throws IndexOutOfBoundsException;
	public int getUnnamedCount();
	public int getNamedCount();
}

注記

添付を使用する理由はさまざまですが、メッセージに論理的な構成を提供するために使用するのが一般的です。エンドポイント間で添付のストリーミングができるようにすると、サイズの大きなメッセージのパフォーマンスを向上することができます。

注記

JBoss Enterprise Service Bus はメッセージや添付のストリーミングに他のエンコーディングメカニズムを指定できません。この機能は今後のリリースに追加され、添付を持つ SOAP の配信メカニズムと結合される予定です。現在、添付はボディ内の名前付きオブジェクトと同じ方法で処理されます。
ペイロードを挿入する場所を決定する際、アタッチメント、プロパティー、名前付きのオブジェクトのいずれを選べばいいのか圧倒されるかもしれません。しかし、選択の基準はいたって簡単です。
  • 開発者は、クライアントがサービスとの対話を行うために使用するコントラクトを定義します。このコントラクトの一部で、サービスの機能、非機能部分を指定します。例えば、航空予約サービス (機能) やトランザクション関連のサービス (非機能) です。
    また、開発者はサービスが理解できるオペレーション (メッセージ) も定義します。形式 (Java Serialized Message や XML) もメッセージ定義の一部として定義されます (この例ではトランザクションコンテキスト、座席番号、顧客名などです)。コンテンツを定義すると、サービスがペイロードがメッセージのどの部分にあるか分かるよう指定します (アタッチメントや、具体的な名前付きオブジェクト、またはデフォルトの名前付きオブジェクトなどの形式で行うことができます)。これはサービス開発者が決定します。唯一の制限事項は、オブジェクトとアタッチメントはグローバル一意名でなければならない点です (そうでなければ、同じメッセージボディが複数の「Hop」で転送される場合、サービスやアクションは別のものに向けられた部分的なペイロードを誤って拾ってしまう場合があります) 。
  • サービスのコントラクト定義 (UDDI レジストリか、帯域外通信で) 取得でき、これでメッセージのどの部分にペイロードを置くかを定義します。それ以外の場所に置かれた情報は、ほぼ無視されるため、サービスが正しく実行されなくなります。

3.3. データの取得、設定

Enterprise Service Bus コンポーネントはすべて (actionslistenersgatewaysroutersnotifiers) はデフォルトでメッセージのデフォルトのペイロードの場所を使用して、メッセージ上にあるデータを "get"、"set" するよう設定されています。
すべての ESB コンポーネントは MessagePayloadProxy を使用してメッセージの get やset を管理します。このクラスは上記のようにデフォルトのケースに対応しますが、すべてのコンポーネントで一様に無効にすることもできます。以下のコンポーネントプロパティを使用して、メッセージペイロードの get や set の場所を一様に無効にすることができます。
  • get-payload-location: メッセージペイロードを取得する場所。
  • set-payload-location: メッセージペイロードを設定する場所。

注記

JBossESB 4.2.1GA 以前は、デフォルトのメッセージペイロードの交換パターンはありませんでした。今後のリリースでの後方互換については、以下の手順に従ってください。
  1. jbossesb.sar に移動します。
  2. jbossesb-properties.xml ファイルを開きます。
  3. core セクションで、use.legacy.message.payload.exchange.patterns プロパティを true に設定します。

3.4. ボディの拡張

メッセージボディのコンテンツを操作するプロセスを簡素化するインターフェースが多数存在します。定義済みのメッセージ構造とメソッドを提供することで簡素化します。
これらのインターフェースは基本のボディーインターフェースの拡張で、既存のクライアントやサービスと共に使用できます。メッセージの基礎となるデータ構造は変更されないため、メッセージのコンシューマーは新しいタイプを認識する必要はありません。

拡張タイプ

org.jboss.soa.esb.message.body.content.TextBody
ボディの内容が任意のストリングの場合これを使用します。getText メソッドや setText メソッドを使用して操作することができます。
org.jboss.soa.esb.message.body.content.ObjectBody
ボディの内容がシリアライズされたオブジェクトの場合はこれを使います。getObject メソッドや setObject メソッドを使用して操作することができます。
org.jboss.soa.esb.message.body.content.MapBody
ボディの内容がマップ (ストリング、シリアライズされている) の場合これを使用します。setMap メソッドやその他のメソッドを使用して操作することができます。
org.jboss.soa.esb.message.body.content.BytesBody
ボディの内容が任意の Java データタイプを含むバイトストリームの場合これを使用します。データタイプのメソッドを使用して操作することができます。BytesMessage が作成されると、操作の必要に応じて読み取り専用モードまたは書き込み専用モード内に置かれます。readMode() メソッドや writeMode() メソッドを使用してモードを変更することができますが、モードが変更される度にバッファーポイントがリセットされます。flush() メソッドを呼び出して、すべての更新がボディに適応されたことを確認する必要があります。
XMLMessageFactory クラスや SerializedMessageFactory クラスを使用すると、これらのインターフェースを基にしたボディの実装を持つメッセージを作成することができます。メッセージに対して作業を行う場合、MessageFactory クラスや MessageFactory に関連したクラスを使用するより、XMLMessageFactory クラスや SerializedMessageFactory クラスを使用した方が便利です。
createTextBody など、ボディの各タイプに関連する create メソッドが存在します。このメソッドによって、特定タイプのメッセージを作成し初期化することができます。メッセージの作成後、ローボディまたはインターフェースメソッドを使用して直接メッセージを操作することができます。ボディの構造は送信後も維持されるため、メッセージを作成したインターフェースのメソッドを使用すればメッセージの受信側が操作することもできます。

注記

ベースのボディインターフェースへの拡張は任意でオリジナルのボディに追加することができます。このように、既存のクライアントとサービスと連携して使用することができます。メッセージ内の基盤のデータ構造が変更されないため、必要であればメッセージコンシューマーは、これらの新しいタイプは認識しないままにすることができます。重要なのは、この拡張はデフォルトの場所にデータを格納しない点です。データは、拡張インスタンス上にある該当のゲッターを使用してリトリーブする必要があります。

3.5. メッセージヘッダー

メッセージヘッダーの内容は org.jboss.soa.esb.addressing.Call クラスのインスタンスに格納されます。
public class Call
{
	public Call ();
	public Call (EPR epr);
	public Call (Call copy);
	public void setTo (EPR epr);
	public EPR getTo () throws URISyntaxException;

	public void setFrom (EPR from);
	public EPR getFrom () throws URISyntaxException;

	public void setReplyTo (EPR replyTo);
	public EPR getReplyTo () throws URISyntaxException;

	public void setFaultTo (EPR uri);
	public EPR getFaultTo () throws URISyntaxException;

	public void setRelatesTo (URI uri);
	public URI getRelatesTo () throws URISyntaxException;
	public void copy();
	public void setAction (URI uri);
	public URI getAction () throws URISyntaxException;
	public final boolean empty();
	public void setMessageID (URI uri);
	public URI getMessageID () throws URISyntaxException;
	public String toString();
	public String stringForum();
	public boolean valid();
	public void copy (Call from);
}
org.jboss.soa.esb.addressing.Call は一方向パターンと要求返答対話パターンの両方をサポートします。

表3.1 org.jboss.soa.esb.addressing.Call プロパティ

プロパティ タイプ 必須 説明
To EPR Yes メッセージ受信側のアドレス
From EPR No メッセージ発信元のエンドポイント
ReplyTo EPR No このメッセージに返信する受信側を特定するエンドポイント参照
FaultTo EPR No 不良の警告の受信側を識別するエンドポイント参照
Action URI Yes これは、メッセージが暗示するセマンティクスを一意かつ不透明に識別します。
MessageID URI 場合による 時空間でこのメッセージを一意に識別する URI。別のアプリケーションに使う予定のメッセージは [MessageID] を共有することはできません。メッセージは、通信エラーなどが原因で再送信され、同じ [MessageID] プロパティを使用する可能性があります。このプロパティの値は、不透明な URI で、等価を超えた解釈については定義されません。返信が来るものについては、このプロパティを必ず設置する必要があります。
ヘッダーと各種エンドポイント参照の関係は以下のように表記できます。
UML で表記されたヘッダーとエンドポイント参照の関係

図3.2 UML で表記されたヘッダーとエンドポイント参照の関係

サービスを開発し使用する際、ヘッダーの役割について考慮しなければなりません。たとえば、要求と応答に基づいた同期の対話パターンが必要な場合、ReplyTo フィールドの設定が求められます。設定がない場合はデフォルトのエンドポイント参照が使用されます。要求/応答の場合でも、指定があれば応答は元の送信側に戻る必要はありません。一方向メッセージ (応答なし) を送信する場合、ReplyTo フィールドを設定しても無視されるため、設定しないようにしてください。

注記

詳細については、LogicalEPR の章を参照してください。

警告

EPR の内部形式は API 実装固有のものであるため、これに依存すべきではありません。この形式が同じ形でとどまるという保証はありません。

注記

メッセージヘッダーは、メッセージと連携して構成されます。エンドポイント間で配信されると、このメッセージヘッダーは不変となります。インターフェースにより、受信側が個別の値を変更できるようになりますが、JBoss Enterprise Service Bus はこれらの変更については無視します (今後のリリースでは、明確化を目的に、アプリケーションプログラミングインターフェースでこのような変更が行えないようになるはずです)。このルールについては、 WS-Addressing 規格にまとめられています。

3.6. LogicalEPR

ReplyToFaultTo EPR は、物理 EPR (JMS-EPR など) ではなく、常に論理 EPR を使用するようにしてください。LogicalEPR とは、ESB サービス/エンドポイントの名前とカテゴリを指定する EPR のことです。LogicalEPR には物理アドレス指定の情報は含まれません。
LogicalEPR は EPR ユーザー(通常 ESB ですが、そうとは限りません)を想定しないため、LogicalEPR の選択が奨励されます。LogicalEPRのクライアントは EPR で提供されるサービス名やカテゴリの詳細を使用して、呼び出し が行われる時に(適切なアドレス指定情報を取得する場合など)サービスやエンドポイントに対する物理エンドポイントの詳細をルックアップできます。クライアントは適切な物理エンドポイントタイプを選択することもできます。

3.7. デフォルトの FaultTo

FaultTo は、不良関連のメッセージの送信先を識別するエンドポイント参照です。

注記

LogicalEPR の詳細を参照してください。

3.8. デフォルトの ReplyTo

JBoss Enterprise Service Bus では、対話パターンは一方向メッセージ交換をベースとするように推奨していました。メッセージは、自動的にレスポンスを受信しない場合があります (送信者がレスポンスを受け取るかについてはアプリケーションにより左右されます)。このように、返信先アドレス (エンドポイント参照) は、ヘッダーのルーティング情報のうちオプションの情報で、必要に応じてアプリケーションはこの値を設定するようにしてください。しかし、レスポンスが必要で、エンドポイント参照 (ReplyTo EPR) が設定されていない場合、JBoss Enterprise Service Bus はトランスポートの各タイプにデフォルト値を提供できます (ReplyTo のデフォルトを使用するには、システム管理者は JBoss Enterprise Service Bus をデフォルト使用するよう設定する必要があります)。

表3.2 トランスポートによるデフォルトの ReplyTo

トランスポート ReplyTo
JMS 元のリクエストの配信に使用した名前と同じものを持つキュー。接尾辞は _reply です。
JDBC 元の要求の配信に使用した名前を持つ同じデータベース内にあるテーブル。接尾辞は _reply_table (応答テーブルには、要求テーブルと同じ列定義が必要となります)。
ファイル ローカルファイルとリモートファイル共に管理的な変更は必要ありません。元の送信側のみが応答を受け取るようにするため、応答は固有のサフィックスで要求と同じディレクトリに書き込まれます。

3.9. メッセージペイロード

メッセージペイロードはボディ、添付、プロパティの組み合わせになります。

警告

JBossESB では、アタッチメントとプロパティもボディ同様に処理されます。これらの一般的な概念については現在再評価中で、今後のリリースで大幅に変更される可能性があります。
ペイロードの UML 表記を以下に示します。
メッセージペイロードの UML 表記

図3.3 メッセージペイロードの UML 表記

より複雑なコンテンツを適用するには、名前付きオブジェクトに対応している add メソッドを使用します。粒度の細かくデータにアクセスできるように、名前付きのオブジェクトペアを使用します。どのタイプのオブジェクトでもメッセージボディに追加できます (Java シリアライズ可能でないオブジェクトを追加するには、JBoss Enterprise Service Bus にメッセージのマーシャル化アンマーシャル化機能を追加する必要があります。このプロセスの詳細については、"メッセージフォーマット"のセクションを参照してください)。

注記

"setting" や "getting" に名前が提示されていない場合は、DEFAULT_LOCATION 設定に定義されているものを使用します。

注記

メッセージ内でシリアライズされた Java オブジェクトを使用する際は、サービス実装に制約を加えるため、注意してください。
メッセージボディに「名前付きオブジェクト」を使用するのが最も簡単でしょう。ボディ全体をデコードしなくてもメッセージペイロード内で各データ項目を追加、削除、検査することができます。また、ペイロード内の名前付きオブジェクトとバイト配列を組み合わせることも可能です。

注記

現在、Java シリアライズオブジェクトしか添付することができません。この制約は、今後のリリースではなくなる予定です。

注記

現在のリリースでは、Java シリアライズオブジェクトしか添付することができません。この制約は、今後のリリースではなくなる予定です。 

3.10. MessageFactory

各 ESB コンポーネントは ESB メッセージを Java オブジェクトの集合として処理しますが、多くの場合で ESB メッセージをシリアライズする必要があります。データストアへの保存や異なる JBossESB プロセス間でのメッセージ送信、デバッグなどの場合に ESB メッセージをシリアライズする必要があります。
正規化形式の要件は、各 ESB デプロイメント独自の特性に左右されるため、JBoss Enterprise Service Bus はメッセージに対して単一の正規化形式を指定することはありません。org.jboss.soa.esb.message.Message インターフェースの実装はすべて org.jboss.soa.esb.message.format.MessageFactory クラスから取得されます。
public abstract class MessageFactory
{
	public abstract Message getMessage ();
	public abstract Message getMessage (URI type);
	public abstract void reset();
	public static MessageFactory getInstance ();
}
メッセージシリアライゼーションの実装は URI によって一意に識別されます。新しいインスタンスを作成する時に実装を指定するか、設定されているデフォルトを使用します。
  • MessageType.JBOSS_XML: これは、ワイヤー上にあるメッセージの XML 表現を使用します。メッセージのスキーマは、message.xsd ファイルで定義します (schemas ディレクトリ内にあります)。URI は urn:jboss/esb/message/type/JBOSS_XML です。
  • MessageType.JAVA_SERIALIZED: この実装では、メッセージの全コンポーネントをシリアライズできます。また、このメッセージタイプの受信側には、デシリアライズするための十分な情報 (Java クラス) が必要なのは明らかです。URI はurn:jboss/esb/message/type/JAVA_SERIALIZED です。

重要

アプリケーションが簡単に特定のサービス実装に結合されてしまうため、メッセージ形式の JBOSS_SERIALIZED バージョンの使用には細心の注意を払ってください。
他のメッセージ実装をランタイム時に提供するには、org.jboss.soa.esb.message.format.MessagePlugin を使用します。
public interface MessagePlugin
{
	public static final String MESSAGE_PLUGIN =	
						 "org.jboss.soa.esb.message.format.plugin";
	public Object createBodyType(Message msg, String type);
	public Message getMessage ();
	public URI getType ();
}
各プラグインは getType() メソッドを使用して、提供するメッセージ実装のタイプを一意に識別しなければなりません。プラグインの実装は、org.jboss.soa.esb.message.format.plugin 拡張の付いたプロパティ名を使って jbossesb-properties.xml ファイル内でシステムに対し識別されなければなりません。

注記

デフォルトのメッセージタイプは、JBOSS_XML です。これを変更するには、org.jboss.soa.esb.message.default.uri プロパティを任意の URI 名に設定します。

3.11. メッセージのフォーマット

シリアライズメッセージフォーマットには、JBOSS_XML と JBOSS_SERIALIZED の 2 種類あります。詳細は本項を参照してください。
MessageType.JAVA_SERIALIZED
この実装では、メッセージの全コンポーネントがシリアライズ可能でなければなりません。このタイプのメッセージの受信側は、メッセージをデシリアライズできなければなりません。よって、メッセージ内に格納された Java クラスをインスタンス化できなければならないことになります。
この実装では、すべての内容が Java でシリアライズできなければなりません。メッセージにシリアライズ可能でないオブジェクトを追加しようとすると、IllegalParameterException がスローされます。
URI は urn:jboss/esb/message/type/JAVA_SERIALIZED です。
MessageType.JBOSS_XML
この実装は、ワイヤー上にあるメッセージの XML 表現を使用します。メッセージのスキーマは、message.xsd ファイルで定義されます (schemas ディレクトリにあります)。任意オブジェクトをメッセージに追加できます。つまり、シリアライズする必要はありません。そのため、メッセージのシリアライズが必要な場合、このようなオブジェクトを XML にマーシャリングまたは、アンマーシャリングできるようにする必要があります。org.jboss.soa.esb.message.format.xml.marshal.MarshalUnmarshalPlugin から設定できます。
public interface MarshalUnmarshalPlugin
{
	public static final String MARSHAL_UNMARSHAL_PLUGIN =
				 "org.jboss.soa.esb.message.format.xml.plugin";
	public boolean canPack(final Object value);
	public boolean marshal (Element doc, Object param)
											throws MarshalException;

	public Object unmarshal (Element doc) throws UnmarshalException;

	public URI type ();
}

注記

デフォルトで、Java シリアライズオブジェクトはサポートされています。
プラグインのマーシャリングは、jbossesb-properties.xml 設定ファイルよりシステムに登録しなければなりません。プラグインは MARSHAL_UNMARSHAL_PLUGIN で始まる属性名を持たなければなりません。
XML でオブジェクトをパッキングする時、JBoss Enterprise Service Bus はそのオブジェクトタイプを処理できるプラグインが見つかるまで、登録されたプラグインのリスト内を検索します (適切なプラグインが見つからない場合は、不良メッセージを返します)。メッセージの受信側でのアンパッキングを容易にするため、オブジェクトをパッキングしたプラグインの名前も添付されます。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。