次の事例は、WebSphere
Studio Application Developer Integration Edition サービスが、新しいプログラミング・モデルに確実に正しく
マイグレーションされるように設計する方法を示しています。
- 可能であれば、「割り当て」アクティビティーを使用してみてください
(これは、拡張変換が必要な場合にのみ必要とされる変換プログラム・サービスとは対照的です)。
この事例を使用しなければならない理由は、
SCA モジュールが変換プログラム・サービスを呼び出すには、
中間コンポーネントを構成する必要があるためです。
さらに、WebSphere Integration Developer には、
バージョン 5.1 で作成された変換プログラム・サービス用の特殊ツールのサポートはありません (変換プログラム・サービスの動作を変更する必要がある場合は、
WSDL または XML エディターを使用して、WSDL ファイルに組み込まれた XSLT を変更する必要があります)。
- Web サービス・インターオペラビリティー (WS-I) 仕様と 6.0 優先スタイルのとおり、WSDL メッセージあたりに 1 つの
パーツを指定します。
- WSDL doc-literal スタイルは 6.0 の優先スタイルであるため、これを使用してください。
- すべての複合タイプに名前が付いていること、
およびそれぞれの複合タイプがそのターゲット名前空間と名前によって一意的に識別可能であることを確認してください。
以下に、複合タイプおよびそのタイプのエレメントを定義するのに推奨される方法を示します
(複合タイプ定義の後に、その複合タイプ定義で使用するエレメント定義が続きます)。
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<complexType name="Duration">
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
<element name="DurationElement" type="tns:Duration"/>
</schema>
以下の例は、SDO が XML
(匿名複合タイプ定義が含まれているエレメント) にシリアライズされるときに問題の原因となることがあるため、避けなければならない匿名複合タイプです。
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<element name="DurationElement">
<complexType>
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
</element>
</schema>
- 外部コンシューマー向けサービスを公開する場合は (Apache SOAP/HTTP ではなく)、
IBM® Web Services を使用して
サービス・デプロイ・コードを生成します。
これは、IBM Web Services は 6.0 で
直接サポートされているが、Apache Web サービスはサポートされていないためです。
- WSDL および XSD ファイルを 5.1 で編成して、マイグレーション中に実行しなければならない再編成の量を最小限にする
には、2 つの方法があります。
6.0 では、WSDL ファイルや XSD ファイルなどの共用成果物を BI サービスによって参照させるために、これらを BI プロジェクト
(Business Integration modules および libraries) に配置するする必要があります。
- サービス・プロジェクトが参照できる Java™ プロジェクト内の複数のサービス・プロジェクトに
よって共有されるすべての WSDL ファイルを保持します。
6.0 へのマイグレーションで、5.1 の共用 Java プロジェクトと同じ名前を持つ新しいビジネス・インテグレーション・ライブラリーを作成します。
5.1 の共用 Java
プロジェクトから、すべての成果物をこのライブラリーにコピーして、
これらの成果物を使用するサービス・プロジェクトをマイグレーションするときに、
マイグレーション・ウィザードが成果物を解決できるようにしてください。
- サービス・プロジェクトが、そのサービス・プロジェクト自体の中で参照するすべての WSDL/XSD ファイルのローカル・コピーを
保持します。
WebSphere Studio Application
Developer Integration Edition サービス・プロジェクトは、WebSphere Integration Developer の Business Integration Module にマイグレーションされ、
モジュールは他のモジュールとの依存関係を持つことができません (WSDL ファイルまたは XSD ファイルを共有するために別の
サービス・プロジェクトと依存関係を持つサービス・プロジェクトは、クリーンにマイグレーションされません)。
- Business Process Choreographer Generic Messaging API (Generic MDB) は 6.0 では提供されないため、使用しないで
ください。
MDB インターフェース・オファリング遅延バインディングは 6.0 では使用できません。
- 特定バージョンのプロセスに特有の生成済みセッション
Bean を呼び出す代わりに、Business Process Choreographer Generic EJB API を使用してください。
これらのセッション Bean は、V6.0.0.0 では生成されません。
- 同じ操作に対して複数の応答を持つビジネス・プロセスがある場合、
いずれかにクライアント設定があれば、
その操作に対するすべての応答が同じクライアント設定を持っていることを確認してください。
6.0 では、操作応答ごとに 1 セットのクライアント設定のみがサポートされるためです。
- 次のガイドラインに準拠して、BPEL Java snippet を設計してください。
- WSIFMessage パラメーターを任意のカスタム Java クラスに送らないでください。
可能であれば、WSIFMessage データ・フォーマットに依存しないようにしてください。
- 可能であれば、WSIF メタデータ API を使用しないでください。
- BPEL Java Snippet で BPEL 変数と同じ名前のローカル変数を宣言しないでください。
6.0 では Snippet 内で BPEL 変数に直接アクセスできるため、
同じ名前のローカル変数があると、競合が起こることがあります。
- WSDL ポート・タイプ/メッセージから生成された Java/EJB スケルトンは WSIF クラス
(WSIFFormatPartImpl など) に依存するため、トップダウンの EJB または Java
サービスを作成することはできるだけ避けてください。
その代わり、Java/EJB インターフェースを作成してから、Java クラス/EJB にサービスを生成してください (ボトムアップのアプローチ)。
- soapenc:Array タイプを参照する WSDL インターフェースを作成したり、使用しないようにしてください。
このタイプのインターフェースは、SCA プログラミング・モデルではネイティブにサポートされないためです。
- ハイレベル・エレメント (maxOccurs 属性が 1 より大きい) が配列型のメッセージ・タイプは作成しないようにしてください。
このタイプのインターフェースは、SCA プログラミング・モデルではネイティブにサポートされていないためです。
- WSDL インターフェースは正確に定義し、
xsd:anyType タイプへの参照を持つ XSD complexTypes の使用はできるだけ避けてください。
- WebSphere
Process Server V6 にマイグレーションするときに名前の衝突を避けるために、EJB または Java
Bean から生成するすべての WSDL および XSD について、
ターゲット名前空間が固有である (Java クラス名およびパッケージ名が、ターゲット名前空間によって表されている) ことを確認してください。
WebSphere Process
Server V6 では、
同一の名前とターゲット名前空間を持つ、2 つの異なる WSDL/XSD 定義は許可されません。
この状況は、ターゲット名前空間を明示して指定しないで Web サービス・ウィザードまたは
Java2WSDL コマンドが使用される場合によく起こります
(ターゲット名前空間が EJB または
Java Bean のパッケージ名に対しては固有であるが、クラス自体に対して固有でないため、
Web サービスが同一パッケージ内で 2 つ以上の EJB
または Java Bean に対して生成される場合に問題が発生します)。
この解決方法は、Web サービス・ウィザードで名前空間マッピングにカスタム・パッケージを指定するか、 -namespace Java2WSDL コマンド行オプションを使用して、
生成されるファイルの名前空間が所定のクラスに対して固有となるようにすることです。
- すべての WSDL ファイルに、できるだけ固有の名前空間を使用してください。
WSDL 1.1 仕様に準拠した同一の名前空間を持つ 2 つの異なる WSDL ファイルのインポートについては制限があり、WebSphere
Integration Developer 6.0 では、これらの制限が厳密に強制されます。