この章では、JDeveloperで使用するカスタムService Busトランスポートを開発するためのベスト・プラクティス、設計上の考慮事項およびパッケージ化について説明します。トランスポートSDKのインタフェースは、トランスポート・プロトコルとService Busランタイムの間の橋渡しを行います。
ヒント:
この章を始める前に、「カスタム・トランスポート・プロバイダについて」を確認してください。
この章の内容は次のとおりです。
Service Busトランスポートは、元々はOracle Service Busサーバーにデプロイするように設計され、Oracle Service Busコンソールを使用して構成されています。JDeveloperのような設計環境では、SDKを一部変更し、トランスポート設計時機能をOracle Service Busコンソール以外のプラットフォームで使用できるようにする必要があります。
Service Busとともにインストールされているサンプル・ソケット・トランスポートは、JDeveloperに移植されており、JDeveloper統合のベスト・プラクティスとみなすことができます。サンプル・ソケットのリソースは、OSB_ORACLE_HOME
/samples/servicebus/sample-transport
にあります。Javaソース・ファイルは/src
サブディレクトリにあります。サンプルにはビルド・スクリプトも含まれており、JDeveloper統合とOracle Service Busコンソールデプロイメント両方のためにサンプル・ソケット・トランスポートを自動的にパッケージ化できます。サンプル・ソケット・トランスポートのビルドおよびデプロイについては、「サンプル・ソケット・トランスポート・プロバイダの作成」を参照してください。
トランスポートを開発する場合は、ランタイム・アスペクトと構成アスペクトを区別します。ランタイム・アスペクトには、プロキシ・サービスまたはビジネス・サービスのデプロイメントおよびサービスの実行時の呼出しが含まれます。構成アスペクトには、プロキシまたはサービスの構成と検証が含まれます。ランタイム・アスペクトは、Service Busサーバーが実行されている状況で常に実行されるため、変更する必要はありません。ただし、構成アスペクトは、設計環境に依存します。
開発者は、次の3種類のデプロイメント・モードを考慮する必要があります。
オンライン・モード: カスタム・トランスポートを使用するサービスが、実行中のService BusサーバーでOracle Service Busコンソールによって構成されます。
オフライン・モード: カスタム・トランスポートを使用するサービスが、Service Busサーバーの外部で実行されている設計環境を使用して構成されます。リモート・サーバーは使用できません。
オフライン・モード(リモート・サーバーあり): カスタム・トランスポートを使用するサービスが、Service Busサーバーの外部で実行されている設計環境を使用して構成されます。ただし、リモート・サーバーが利用可能であり、検証および構成の両方の目的に使用できます。
JDeveloperで実行されるトランスポートは、オフライン・モードと、必要に応じて、オフライン・モード(リモート・サーバーあり)をサポートする必要があります。
オフライン・モードでトランスポートをデプロイする場合、構成フレームワークは、すべてのリソースの構成用に1つのセッションを作成します。このセッションがアクティブ化されることはありません。プロキシ・サービスまたはビジネス・サービスは、実行中のService Busサーバーにしかデプロイできないため、セッションをアクティブ化する必要はありません。ただし、やはり競合および構成エラーの検出は重要であるため、検証メソッドは引続き実行されます。
次に、オフライン・モードで実装する必要がある、トランスポートSDKによって定義されているクラスおよびメソッドの最小セットのリストを示します。読みやすくするために、例外はメソッド・シグネチャから削除されています。
注意:
オフライン・モード用にトランスポートを完全に再実装する必要はありません。ほとんどの場合、トランスポートは、既存のメソッドにいくつかの変更を加えるだけで、オンライン・モードとオフライン・モードの両方をサポートできます。
オフライン・メソッドのために実装する必要があるクラスとメソッド
public interface TransportProvider
。特に次のメソッドです。
String getId()
void validateEndPointConfiguration(TransportValidationContext context)
SchemaType getEndPointConfigurationSchemaType()
SchemaType getRequestMetaDataSchemaType()
SchemaType getRequestHeadersSchemaType()
SchemaType getResponseMetaDataSchemaType()
SchemaType getResponseHeadersSchemaType()
TransportProviderConfiguration getProviderConfiguration()
TransportUIBinding getUIBinding(TransportUIContext context)
void shutdown()
Collection<NonQualifiedEnvValue> getEnvValues(Ref ref, EndPointConfiguration epConfig)
void setEnvValues(Ref ref, EndPointConfiguration epConfig, Collection<NonQualifiedEnvValue> envValues)
Collection<Ref> getExternalReferences(EndPointConfiguration epConfig)
void setExternalReferences(Map<Ref, Ref> mapRefs, EndPointConfiguration epConfig)
Map<String, String> getBusinessServicePropertiesForProxy(Ref ref)
XmlObject getProviderSpecificConfiguration(Ref ref, Map<String, String> props)
public interface TransportProviderFactory
このインタフェースは、トランスポートをオフライン・モードで登録します。詳細は、「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。
public interface TransportUIBinding
このインタフェースですべてのメソッドを実装して、プロキシ・サービスまたはビジネス・サービスの構成に使用されるユーザー・インタフェースを定義します。
ヘルパー・クラス
public class TransportManagerHelper
このクラスは、通常はTransportProvider
の開発者によって使用されます。プロバイダを実装する際にコードがオフラインで実行しているかどうかを判別するためのboolean isOffline()
メソッドを提供します。オフライン・モードで無効な一部のメソッドは次のように例外をスローします。他のメソッドは、public isAdmin()
のようにランタイムまたはデプロイメントのみに対応します。
オフライン・モード(リモート・サーバーあり)で作業するときは次のメソッドも使用できます。
public Set<String> getDispatchPolicies(JMXConnector connector)
public DomainRuntimeServiceMBean getDomainRuntimeServiceMBean(JMXConnector connector)
詳細は、「オフライン(リモート・サーバーあり)での作業」を参照してください。
オフライン・モードでは、次のメソッドは呼び出さないでください。
public static boolean isAdmin()
このメソッドは、java.lang.IllegalStateException
メッセージをスローします。
public static boolean clusterExists()
このメソッドは、常にfalseを返します。
注意:
ランタイムのステータスをチェックするための推奨メソッドは、isRuntimeEnabled()
とgetRuntimeServers()
を組み合せて使用することです。
オフラインで作業する場合、サーバー上で実行されているWebLogic Serverサービスは使用できません。「オフライン・メソッド」で説明されているメソッド内でこれらのサービスを使用しないでください。
次に、オフラインで作業する場合の制限の例を示します。
Oracle WebLogic Server MBeansは使用できません。
サーバーJavaプロパティは使用できません。
JNDIツリーに直接アクセスすることはできません。ただし、JNDIプロパティがサービス構成で定義されている場合は、それらの使用を試みることができます。
サービスがクラスタまたはスタンドアロン・サーバーのどちらで実行されるのかを判断することはできません。
Oracle WebLogic Serverセキュリティ・インフラストラクチャにはアクセスできません。
サーバーにある静的なシングルトン・サービスにアクセスすることはできません。
一部のサービスが使用できないため、トランスポートのユーザー・インタフェースがどのように影響を受けるかを評価する必要があります。一般的に、ユーザー・インタフェースは、ユーザーが値をサーバー環境から取得しようとするかわりに、値を手動で構成できるだけの柔軟性を備えている必要があります。
たとえば、一部のトランスポートでは、TransportManagerHelper
を使用し、ユーザーがリストから選択できるようにして、使用可能なワーク・マネージャ(ディスパッチ・ポリシー)項目のリストを取得します。ただし、オフライン・モードではMBeanが使用できないため、リストを設定することはできません。トランスポート・プロバイダには次の2つの選択肢があります。
ユーザーが正確なワーク・マネージャ名を入力できるようにします。この場合、オフラインで作業する際は、ユーザー・インタフェースを、リストではなくテキスト・ボックスに変更する必要があります。
より柔軟性の低いもう1つの選択肢は、デフォルトのワーク・マネージャのみを使用してリストを設定する方法です。サービスが実行中のService Busサーバーにプッシュされるときに、環境値の代入を使用してワーク・マネージャ名を切り替えることができます。
オフラインで作業する場合に、リモート・サーバーを使用できる場合があります。たとえば、JDeveloperでサービスを構成するときに、リモートのService Busサーバーを現在のプロジェクトに関連付けることができます。トランスポート・プロバイダは、Oracle WebLogic Server MBeanにアクセスして情報を取得することで、リモート・サーバーを利用することができます。このモードは、オンラインでの作業に似ていますが、コードがサーバーで実行されず、MBeanしか使用できないため、やはりいくつかの制限が適用されます。
リモート・サーバーを使用してオフラインで作業している場合、次の制約があります。
サーバーJavaプロパティは使用できません。
「オフライン・メソッド」で説明されているように、多くのTransportManagerHelper
メソッドは使用できません。
JNDIツリーに直接アクセスすることはできません。ただし、JNDIプロパティがサービス構成で定義されている場合は、それらの使用を試みることができます。
サーバーにある静的なシングルトン・サービスにアクセスすることはできません。
MBeanにアクセスするために、フレームワークは、TransportUI
オブジェクトをリクエストするときまたはプロバイダに構成を検証するようにリクエストするときに、JMXConnector
のインスタンスを提供します。JMXConnector
はTransportUIContext
またはTransportValidationContext
で使用できます。
JMXConnector connector = (JMXConnector)uiContext.get(TransportValidationContext.JMXCONNECTOR);
詳細は、「オフライン・ツール用のカスタム・トランスポート・プロバイダ・リファレンス」のサンプル・トランスポートを参照してください。
コネクタが存在しない場合、リモート・サーバーは使用できません。このコネクタ・オブジェクトはその後MBeanへのアクセスに使用できます。ヘルパー・メソッドがTransportManagerHelper
に追加されたため、WorkManager
およびWebLogic ServerドメインMBeanのリストを取得できます。
注意:
この動作は、オンライン・モードおよびオフライン・モード用に汎用化されています。TransactionManagerHelperで定義されているpublic static Set<String> getDispatchPolicies()
メソッドは非推奨となるため、JMXConnectorをパラメータとして持つ同じメソッドで置き換える必要があります。置換えない場合、com.bea.wli.sb.transports.TransportException
エラーが表示されます。
オンライン・モードでは、トランスポートをEARファイルとしてパッケージ化し、Service Busサーバーにデプロイする必要があります。起動時にEARがロードされると、トランスポートは、起動イベントでコールバックを登録し、TransportProvider
のインスタンスをTransportManager
に登録します。
オフライン・モードでは、トランスポートを登録するcom.bea.wli.sb.transports.TransportProviderFactory
というインタフェースがSDKで提供されます。トランスポートの開発者は、このインタフェースを実装し、デフォルトのコンストラクタをパブリックにする必要があります。このインタフェースは、「オフライン・ツール用のカスタム・トランスポート・プロバイダ・リファレンス」でサンプル実装とともに提供されています。
TransportProvideFactory
がインスタンス化された場合、トランスポートを(リモート・サーバーの有無にかかわらず)オフライン・モードで動作させる必要があると想定できます。
注意:
トランスポートがオフライン・モードで実行されているかどうかを判断するためにコンストラクタが呼び出されるときに、TransportManagerHelper
でブール演算子を設定できます。この情報は、TransportUIContext
およびTransportValidationContext
にも渡すことができます。この決定に際しては、技術部門に支援を受けることができます。
JDeveloperでカスタム・トランスポート・プロバイダを使用するためには、トランスポート・プロバイダを作成したときに生成したJARファイルをService Busインストールに追加する必要があります。JDeveloperプラグインとしてカスタム・トランスポートをパッケージ化し、同時にトランスポートのユーザー・インタフェースを実装することで、サービスの開発者が、開発環境でそのトランスポートを選択および構成できるようになります。
オフライン・モードでは、JDeveloperなど様々な設計環境でトランスポートを使用できます。一般的に、転送は、自己完結型のJARファイルとして、外部の設計時環境から使用できる必要があります。自己完結型のJARファイルでは、トランスポートのconfig.xml
ファイル、ヘッダー、メタデータ・スキーマ、XBeanクラス、TransportProviderFactory
実装およびコンパイル済のトランスポート・クラスが含まれます。
図41-1に、サンプル・ソケット・トランスポートの構成ページを含むJDeveloperのサービス・エディタ(サービス作成後)を示します。
カスタム・トランスポート・プロバイダのパッケージ化およびデプロイの詳細は、「カスタム・トランスポート・プロバイダのパッケージ化とデプロイ」を参照してください。
注意:
TransportUIBinding
インタフェースの実装によって、JDeveloperとOracle Service Busコンソールでの、トランスポートを選択および構成するためのユーザー・インタフェースが決まります。
ここでは、JDeveloperでオフライン・ツール用のカスタム・トランスポート・プロバイダを開発するときに認識している必要がある参考情報を説明します。
ほとんどのトランスポートでディスパッチ・ポリシーが使用されており、これによりサービスの抑制が可能になります。このコードは、「サービスのランタイムとサービスの構成」で説明されている、次の3つのモードを区別します。
オンライン・モード
オフライン・モード
オフライン・モード(リモート・サーバーあり)
次の例で示しているように、リモート・サーバーへの接続はコンテキストから取得されます。
例 - リモート・サーバーへの接続
/**
* Builds the dispatch policies in the ui object.
*
* @param curDispatchPolicy
* @return TransportEditField containing existing dispatch policies.
*/
public TransportEditField getDispatchPolicyEditField(StringcurDispatchPolicy {
TransportUIFactory.TransportUIObject uiObject = null;
Set<String> wmSet = null;
if (SocketTransportManagerHelper.isOffline())
{ // if on JDeveloper try to get the MBeans from the UIContext
JMXConnector connector =
(JMXConnector)uiContext.get(TransportValidationContext.JMXCONNECTOR);
if (connector != null) {
try {
wmSet = TransportManagerHelper.getDispatchPolicies(connector);
} catch (Exception ex) {
wmSet = null;
}
}
} else { // if running on the server use the helper to get the policies
try {
wmSet = TransportManagerHelper.getDispatchPolicies();
} catch (TransportException transexcept) {
SocketTransportUtil.logger.error(SocketTransportMessagesLogger.noDispatchPolicies(),
transexcept);
}
}
if (wmSet == null) // if JMXConnector not available or impossible to connect provide a simple
edit field
{
uiObject = TransportUIFactory.createTextBox(curDispatchPolicy);
} else // create a drop down list
{ // adding default work manager to the list.
wmSet.add(DEFAULT_WORK_MANAGER);
String[] values = wmSet.toArray(new String[wmSet.size()]);
uiObject = TransportUIFactory.createSelectObject(values,values,curDispatchPolicy,
TransportUIFactory.SelectObject.DISPLAY_LIST,false);
}
return TransportUIFactory.createEditField(DISPATCH_POLICY,
TextMessages.getMessage(TextMessages.DISPATCH_POLICY,locale),
TextMessages.getMessage(TextMessages.DISPATCH_POLICY_INFO,locale), uiObject);
}
TransportProviderFactory
では、JDeveloperで設計時機能が提供されます。これには、カスタム・トランスポート・プロバイダを登録するメソッドが含まれ、プロバイダ用に定義するIDを取得できます。このインタフェースで提供されるメソッドの詳細は、「Oracle Service Bus Java APIリファレンス」を参照してください。
サンプル・ソケット・トランスポートがこのインタフェースを実装する方法を次のサンプルに示します。
例 - インタフェースを実装するソケット・トランスポートの例
package com.bea.alsb.transports.sock; import com.bea.wli.sb.transports.TransportManager; import com.bea.wli.sb.transports.TransportException; import com.bea.wli.sb.transports.TransportProviderFactory; public class SocketTransportProviderFactory implements TransportProviderFactory { public void registerProvider(TransportManager tm) throws TransportException { SocketTransportProvider instance = SocketTransportProvider.getInstance(); tm.registerProvider(instance, null); } public String getId() { return SocketTransportProvider.ID; } }