このトピックでは、Web サービスに関するアップグレードでの変更の詳細について説明します。
バージョン 8.1 からアップグレードされるアプリケーションに対して行われる変更の詳細なリストについては、「WebLogic Workshop 8.1 からバージョン 10.x へのアップグレード時における変更点」を参照してください。
サポートされていますが、非推奨になっています。アップグレードされた Web サービスおよびサービス コントロールのコードには、クラス レベルで適用される @UseWLW81BindingTypes アノテーションおよび @WLWRollbackOnCheckedException アノテーションが含まれます。これらのアノテーションは非推奨になっていますが、バージョン 8.1 のコードを使用するクライアントをサポートするために必要です。
サポートされていますが、非推奨になっています。バージョン 10.x では、ステートレス オペレーションは NONE フェーズ定数でマークされなければなりません。アップグレード ツールによるアップグレード処理の中で、バージョン 8.1 のステートレス オペレーションに @Conversation(value = Conversation.Phase.NONE) でマークされるようにアノテーションが追加されます。これは、不正なオペレーションが存在しないようにするためです。
注意 : NONE フェーズ定数は非推奨になっていますが、下位互換性を保持するためだけに含められます。Web サービスの機能が将来のリリースでも確実にサポートされるようにするには、ステートレス機能とステートフル機能が別々の Web サービスに配置されるようにサービスを書き換える必要があります。
バージョン 8.1 : 次のバージョン 8.1 のコードの例では、まずステートフル オペレーションが示され、その後にステートレス オペレーションが示されています。
/**
* @common:operation
* @jws:conversation phase="start"
*/
public void startShopping(int customerId)
{
... ステートフル ...
}
// finish オペレーションを含む、その他のステートフル オペレーション
/**
* @common:operation
*/
public String buyWithOneClick(int customerId)
{
... ステートレス ...
}
バージョン 10.x : アップグレードされると、上記のコードは次のようになります。
@Conversation(value = Conversation.Phase.START)
@WebMethod()
@WebResult(name = "startShoppingResult")
public void startShopping(int customerId)
{
...
}
// finish オペレーションを含む、その他のステートフル オペレーション
@Conversation(value = Conversation.Phase.NONE)
@WebMethod()
@WebResult(name = "noPhaseResult")
public String butWithOneClick(int customerId)
{
...
}
バージョン 8.1 では、start オペレーションおよび finish オペレーションのない「会話形式の」Web サービスをコンパイルできました。つまり、Web サービス クラスに会話形式としてアノテーションを付けることができました (たとえば、アノテーションの maxAge 属性を設定できました)。しかし、その Web サービスのオペレーションに会話の phase 属性を付けることはできませんでした。バージョン 10.x では、会話形式の Web サービスは start オペレーションおよび finish オペレーションの両方がなければコンパイルできません。
会話フェーズを設定する
バージョン 8.1 では、デザイン ビューで Web サービスを開いてオペレーションを選択し、それぞれ順番に phase 属性を設定することで会話フェーズを設定できます。バージョン 10.x では、Web サービスのソース コードを開いてフェーズ属性を設定するオペレーションにカーソルを置き、[プロパティ] ビューの Conversation 値で設定します。次の start メソッドに対する例のように、ソースでアノテーションを適用することもできます。
@WebMethod()
@Conversation(Conversation.Phase.START)
public void startConversation()
{
....
}
バージョン 8.1 とは異なり、バージョン 10.x では Web サービスで定義されるバインディングでの複数の SOAP バージョンの使用はサポートされていません。アップグレードする場合は、複数の SOAP バージョンを使用しているすべての Web サービスを、1 つの SOAP バージョンのみを使用するように手動で編集する必要があります。
バージョン 8.1 には、SOAP 1.2 仕様の草案に基づく SOAP 1.2 実装が含まれていました。バージョン 10.x の SOAP 1.2 実装は、この仕様の最終バージョンに基づいているため、旧バージョンの実装とは異なっています。バージョン 8.1 の SOAP 1.2 実装を使用する Web サービスをアップグレードすると、そのサービスのクライアントはそのサービスを使用できなくなります。
バージョン 8.1 で作成された、SOAP 1.2 の Web サービスのクライアントとの互換性を確保するには、アップグレードされたバージョン (バージョン 10.x) の Web サービスから生成された WSDL を使用してクライアントを再ビルドする必要があります。バージョン 10.x では、[プロジェクト エクスプローラ] ビューで Web サービス ファイルを右クリックし、[WSDL を生成] をクリックすることで WSDL を生成できます。
HTTP または JMS を介する非 SOAP の XML フォーマットを使用するバージョン 8.1 の Web サービスがある場合は、SOAP プロトコルまたはそれに代わるプロトコルを使用するように Web サービスをバージョン 10.x 上で変更する必要があります。つまり、バージョン 10.x の Web サービスでは SOAP ヘッダを含まないメッセージ フォーマットはサポートされていません。
バージョン 8.1 の @jws:protocol アノテーションでは、以下の属性と値がサポートされていました。
@jws:protocol http-xml="true"- オペレーションまたは Web サービスで、SOAP ヘッダを含まない HTTP を介した XML メッセージの受信がサポートされていることを示しました。@jws:protocol jms-xml="true"- オペレーションまたは Web サービスで、SOAP ヘッダを含まない Java Message Service (JMS) を介した XML メッセージの受信がサポートされていることを示しました。
バージョン 10.x には、これらの属性と値に対応するものがありません。バージョン 10.x にアップグレードする場合、サポートされていないプロトコル設定はアップグレード ツールで単に無視されます。
バージョン 10.x では、HTML フォームから送信されるメッセージの、form-get メッセージ フォーマットおよび form-post メッセージ フォーマットを使用した受信はサポートされていません。これらのフォーマットを使用する Web サービスをアップグレードする場合、Web ブラウザのフォームから送信されるデータの受信には別の方法を使用する必要があります。
つまり、バージョン 10.x の Web サービスでは SOAP ヘッダを含まないメッセージ フォーマットはサポートされていません。
バージョン 8.1 の @jws:protocol アノテーションでは、以下の属性と値がサポートされていました。
@jws:protocol form-get="true"- オペレーションまたは Web サービスで HTTP GET リクエストの受信がサポートされていることを示しました。@jws:protocol form-post="true"- オペレーションまたは Web サービスで HTTP POST リクエストの受信がサポートされていることを示しました。
バージョン 10.x には、これらの属性と値に対応するものがなく、推奨される対応策もありません。バージョン 10.x にアップグレードする場合、サポートされていないプロトコル設定はアップグレード ツールで単に無視されます。
バージョン 10.x では、Web サービス レベルでの複数プロトコルの使用はサポートされていますが、バージョン 8.1 で提供されていたオペレーション レベルでの複数プロトコルの使用はサポートされていません。たとえばバージョン 8.1 では、Web サービスのオペレーションに対して次のアノテーションがサポートされていました。
@jws:protocol jms-soap="true" public void myOperation()
このアノテーションは、アップグレード時には、JMS を介した Web サービスの呼び出しをサポートするために必要であると解釈されます。アップグレードされたコードでは、アノテーションはオペレーション レベルではなく、Web サービス レベルで適用されます。
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
@WLJmsTransport(queue = "jws.queue",
serviceUri = "myservices/MyWebService.jws")
@WebService(serviceName = "MyWebService",
targetNamespace = "http://www.openuri.org/")
public class MyWebService
{
...
}
複数のオペレーションに対して異なるプロトコルをサポートする必要がある場合には、Web サービスのコードを分割して複数の Web サービスを作成し、サービスごとに 1 つのプロトコルがサポートされるようにしてください。たとえば、JMS のサポートが必要なオペレーションはそのために設計された Web サービスに配置し、HTTP を介して呼び出されるオペレーションは別の Web サービスに配置します。
JMS キューが指定された JWS のアップグレード
JMS バインディング プロトコルをサポートするバージョン 8.1 の Web サービスをアップグレードする場合、アップグレード後のサービスで HTTP および JMS 転送アノテーションは、同じサービスの URI を共有します。
次のいずれかの方法でこの問題を解決することを検討してください。
- アップグレードしたサービスで、@WLHttpTransport または @WLHttpTransport annotations の serviceURI の値を手動で変更します。
- アップグレードを行う前に、バージョン 8.1 の JWS ソース ファイルを編集します。各メソッドレベルのプロトコル バインディング アノテーション (
@jws:protocol) に対して、HTTP または JMS の (両方ではなく) どちらかを選択します。 - 両方のプロトコルが必要な場合は、Web サービス コードを HTTP プロトコルをサポートするものと、JMS プロトコルをサポートするものの 2 つの独立した Web サービス ファイルに分割することで、Web サービスをリファクタリングします。
バージョン 8.1 の Web サービスに、RPC SOAP バインディングを使用する 1 つ以上のオペレーションと、ドキュメント SOAP バインディングを使用する 1 つ以上のオペレーションが両方とも含まれている場合、アップグレード後には、それらのオペレーションに対して生成される型が異なるネームスペースに配置されます。アップグレードされた Web サービスはバージョン 8.1 の Web サービス自体とは異なったものになります (バージョン 8.1 の Web サービスでは型は同じネームスペースにありました)。アップグレードされた Web サービスから生成される WSDL も、バージョン 8.1 の Web サービスから生成される WSDL とは異なります。
この問題は、既存の WSDL ファイルから生成された Web サービスではなく、Java で新規に記述された Web サービスに対してのみ発生すると考えられます。また、Web サービス インタフェースで WSDL をサポートすることが重要でない場合には、このことがまったく問題にならないこともあります。
WSDL 規約をサポートする必要がある場合は、バージョン 8.1 で WSDL を生成し、その WSDL からバージョン 10.x の新しい Web サービスを作成することでこの問題を回避できます。その後、バージョン 8.1 のサービスからバージョン 10.x のサービスに実装コードをコピーして貼り付けることができます。
バージョン 8.1 では、WSDL で複数のサービスが定義されている Web サービス (JWS) またはサービス コントロールを含めることができました。Web サービスまたはコントロールは、これらのサービスのいずれか 1 つのみを表しました。このようなコードをバージョン 10.x にアップグレードすると、アップグレードが失敗します。このようなコードのアップグレードを確実に成功させるには、JWS またはサービス コントロールによって表されるサービスのみを定義するようにするように WSDL を編集する必要があります。
バージョン 8.1 のサービス コントロールに関連付けられる WSDL に対しては <wsdl:import> 要素の複数回の出現がサポートされていましたが、バージョン 10.x ではこの要素の複数回の出現は同一の WSDL 内ではサポートされていません。従来は、たとえば 1 つのインポート文で WSDL の WSDL 部分を取得し、もう 1 つのインポート文で必要な型の XSD 部分を取得するといった記述ができました。
アップグレード前に、インポートされる WSDL のネームスペースがネームスペース属性値となっている <wsdl:import> 文が 1 つだけ含まれるようにすることで、この変更に対応できます。WSDL 部分と XSD 部分は 1 つの文でインポートされます。
バージョン 8.1 で xs:any ではなく xs:anyType が指定された WSDL を使用して Web サービスを作成した場合、バージョン 10.x にアップグレードした後、その Web サービスは誤った XML ペイロードを送受信しようとします。xs:anyType が正しく処理されるようにするには、該当する Web サービスのクラス レベルに以下のアノテーションを適用する必要があります。
@WildcardBindings( @WildcardBinding(className="org.apache.xmlbeans.XmlObject", binding=WildcardParticle.ANYTYPE) )
バージョン 8.1 では、1999 スキーマ ネームスペースの型の使用が、その型を使用した WSDL から生成されたサービス コントロールおよび Web サービスでサポートされていました。バージョン 10.x ではこのネームスペースの型はサポートされていないため、WSDL を 2001 ネームスペースに手動で移行する必要があります。単純なケースとして、以下のような URI があるとします。
http://www.w3.org/1999/XMLSchema
http://www.w3.org/1999/XMLSchema-instance
これらを以下のように変更します。
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
もっと複雑な WSDL では、型自体を移行するために WSDL の部分を変更する必要があります。こうした変更によって、Web サービスと通信するクライアントが使用できなくなる場合があることに注意してください。
オペレーション パラメータの名前と WSDL 内での名前との不一致に関するサポート
Web サービスのメソッド パラメータ名が、その Web サービスの作成時に使用した WSDL 内の対応する名前と一致していない場合、その Web サービスをアップグレードした後で各パラメータに @WebParam アノテーションを追加する必要があります。
このような状況は、Web サービスの生成後にパラメータ名を変更した場合や、WSDL 内で使用されている名前が Java の識別子として有効でない場合に発生することがあります。問題を回避するには、該当する JWS オペレーションの各パラメータに、対応する WSDL 名を指定した @WebParam アノテーションを追加します。
バージョン 8.1 とバージョン 10.x では Web サービスのデフォルトの targetNamespace 値を生成する方法が異なるため、アプリケーション内に同じクラス名の Web サービスが複数あるとデプロイメント エラーが発生する場合があります。バージョン 10.x の Web サービスに対しては、WebLogic Server では内部で使用するリソースをバインドするために Web サービスの targetNamespace 値が含まれた完全修飾されたポート名が使用されます。そのため、ポート名はアプリケーション内でユニークでなければなりません。
バージョン 8.1 では、targetNamespace 値はデフォルトでは http://www.openuri.org/ でした。このデフォルトにより、修飾値がアプリケーション内の複数の Web サービスに対して同一になる可能性がありました。そのため、バージョン 10.x へのアップグレード後に、同一の単純なクラス名 (パッケージのない名前) を持つ複数の Web サービスとこのデフォルト値が存在していると、衝突が発生してデプロイメント エラーが引き起こされるおそれがあります。このエラーは、「<web_service_name> is already bound.」という形式になっています。
このエラーが発生した場合には、@java.jws.WebService アノテーションの name 属性および serviceName 属性の値を設定することで解決できます。これにより、WSDL の portType 要素および port 要素内の name 属性が変更されます。その場合でも、バージョン 8.1 のクライアントと Web サービスとの対話には影響しません。
バージョン 10.x で作成される Web サービスの場合、デフォルトの targetNamespace 値は、全部に対して同一の値ではなく、Web サービスのパッケージ名に基づいています。@WebService アノテーションの targetNamespace 属性を使用して別の値を指定できます。
アップグレードが必要です。バージョン 8.1 では、Web サービスのメッセージレベルのセキュリティは WS-Security (WSSE) ポリシー ファイルを使用して管理されました。バージョン 10.x では、Web Services Policy Framework (WS-Policy) を使用する必要があります。Workshop のアップグレード ツールではこの変更はアップグレードされません。この節では、バージョン 8.1 のモデルとバージョン 10.x のモデルとの主な相違点について説明します。
- WSSE ポリシー ファイルに保持されていたセキュリティ情報は、WS-Policy フレームワークでは 2 つの場所に分けて保持される。WSSE では「何を」(実際のセキュリティ ポリシーの種類) と「どのように」(セキュリティ ポリシーの評価方法) の両方が保持されていましたが、サービス コントロールとそれが通信する Web サービスの両方に対してこれらのセキュリティ情報が分けられるようになりました。
- 分けられた役割は、クライアント コードから Web サービスと通信するサービス コントロール内ではなく、Web サービス内で異なった方法で処理される。
- Web サービスでは、@weblogic.jws.Policy アノテーションを使用して、使用するポリシーを指定する。特定のセキュリティ コンフィグレーションが必要な場合は、weblogic.jws.security.WssConfiguration アノテーションを使用して、WebLogic Server Administration Console から管理されるコンフィグレーションの名前を指定してください。たとえば、暗号化とデジタル署名の処理に必要な情報が含まれるコンフィグレーションを作成することもできます。セキュリティ コンフィグレーションの作成については、「Web サービス セキュリティ コンフィグレーションの作成」を参照してください。
- サービス コントロールでは、以下の 2 つの選択肢がある。
- セキュリティ コンフィグレーション情報が記述されている WSDL から生成されたサービス コントロールでは、Web サービスと正常に通信するために必要な情報が含まれていなければならない。たとえば、セキュリティが WebLogic Server で完全にコンフィグレーションされる、アップグレードされた Web サービスに対しては、<servicepath>?WSDL で WSDL を取得することで必要な情報が記述された WSDL が生成されます。
- 完全にコンフィグレーションされている Web サービスの WSDL から生成されなかったサービス コントロールでは、セキュリティ コンフィグレーション設定をサポートするためのアノテーションを付けることができる。セキュリティ制約を追加する手順を行う前に、アプリケーションの機能をテストおよびデバッグするために (たとえば、Web サービスのテスト バージョンを使用して) サービス コントロールを生成する場合が、これに該当します。セキュリティ制約を追加するには、セキュリティ コンフィグレーション情報が記述されている XML フラグメントを指定する @ServiceControl.Policy アノテーションをサービス コントロールに付けます。「サービス コントロールを使用した実行時のメッセージ レベル セキュリティのコンフィグレーション」で説明されている 2 種類の方法のいずれかを使用して、実行時の値を指定します。
- WSSE ポリシー ファイルの値は、大部分が WS-Policy フレームワークにマップされる。
8.1 の WSSE ファイルの要素 10.x のアノテーション 方向 wsSecurityIn/token @Policy(uri="policy:Auth.xml, direction=Policy.Direction.inbound) 着信 wsSecurityIn/encryptionRequired @Policy(uri="policy:Encrypt.xml") 両方 wsSecurityOut/encryption @Policy(uri="policy:Encrypt.xml") wsSecurityIn/signatureRequired @Policy(uri="policy:Sign.xml") 両方 wsSecurityOut/signatureKey @Policy(uri="policy:Sign.xml") wsSecurityOut/additionalSignedElements @Policy アノテーションを使用して、カスタム ポリシー ファイルおよびそれへのリンクを定義する。 両方 wsSecurityOut/additionalEncryptedElements @Policy アノテーションを使用して、カスタム ポリシー ファイルおよびそれへのリンクを定義する。 両方 keystore @WssConfiguration アノテーションを使用して、コンフィグレーションおよびそれへのリンクを定義する。 なし 
アプリケーションのセキュリティ関連の特性の中には、バージョン 8.1 のアプリケーションをアップグレードする過程で、Workshop に付属のドメインと再デプロイ先になるアップグレードされたドメインで動作が異なってしまうものがあります。アップグレードされたアプリケーションのデプロイ先になるアップグレードされたドメインには下位互換性があるのに対して、Workshop に付属の「新しい」10.x ドメインには下位互換性がないことが原因です。
新しいドメイン上のアプリケーションでは、デフォルトでロール マッピングの組み合わせが有効になっています。このため、weblogic.xml に一致するエントリがないロールに対するマッピングはなくなります (空のマッピングになります)。
web.xml にマップされていないエントリがあった場合には、以下のいずれかを行う必要があります。
- weblogic.xml に明示的なマッピングを追加する。
- ロール マッピングの組み合わせ機能を無効にする (後述の関連ドキュメントを参照)。
ロール マッピングの組み合わせを無効にするには、レルムの <combined-role-mapping> プロパティを以下のように設定します。
security-configuration> <name>workshop</name> <realm> ... <sec:combined-role-mapping-enabled>false</sec:combined-role-mapping-enabled> <sec:name>myrealm</sec:name> </realm> <default-realm>myrealm</default-realm> </security-configuration>
ロール マッピングの組み合わせの設定とそれがセキュリティに与える影響については、「[ロール マッピングの組み合わせを有効化] 設定について」を参照してください。
Workshop のアップグレード ツールでは、信頼性のあるメッセージングのサポート (@jws:reliable アノテーションなど) はバージョン 8.1 からバージョン 10.x にアップグレードされません。 バージョン 8.1 のドキュメントに記載されているように、バージョン 8.1 の信頼性のあるメッセージング (RM) のサポートは非常に限定されたものであり、将来のバージョンでもサポートされる仕様に基づいたものではありませんでした。この節では、バージョン 10.x で Web サービスに信頼性のあるメッセージングのサポートを追加するための、推奨される高度な手順について説明します。
バージョン 8.1 では、@jws:reliable や @jc:reliable などのアノテーションを使用することによって信頼性あるメッセージングのサポートを部分的に追加しました。たとえば、Web サービス クラス レベルでメッセージの生存時間を指定し、オペレーション レベルでオペレーションが確実に呼び出せることを指定しました。次に例を示します。
/**
* @jws:reliable message-time-to-live="600 seconds"
*/
public class ReliableService implements com.bea.jws.WebService
{
static final long serialVersionUID = 1L;
/**
* @common:operation
* @jws:reliable enable="true"
* @jws:protocol form-get="false" form-post="false"
*/
public void doSomething()
{
... メソッド本体 ...
}
...
}
信頼性のあるメッセージングに関連するバージョン 10.x のアノテーションは、アップグレードされたコードに自動的には追加されません。代わりに、次の高度な手順を使用して、バージョン 10.x の信頼性のあるメッセージングのサポートを手動で追加できます。次の手順は最低限の変更のリストと考えてください。全体像については、BEA e-docs ページの「Web サービスの信頼性のあるメッセージングの使用」を参照してください。
- Workshop ツールを使用して、プロジェクトを WebLogic Workshop バージョン 8.1 からアップグレードします。
- Web サービスの信頼性あるメッセージングのサポートを記述する WS-Policy XML ファイルを作成します。WebLogic Server に付属しているデフォルトのポリシー ファイルもあります。詳細については、BEA e-docs ページの「Web サービスの信頼性のあるメッセージングをコンフィグレーションするための WS-Policy ファイルの使用」を参照してください。ポリシー ファイルを使用して、@jws:reliable アノテーションの「message-time-to-live」属性に対応する「expiration」値を指定できます。
- Web サービス クラスに、ポリシー ファイルを参照する @weblogic.jws.Policy アノテーションを付けます。このアノテーションの詳細については、BEA e-docs ページの「@Policy アノテーションの使用」を参照してください。
- 信頼性の高いメソッドに、@javax.jws.Oneway アノテーションを付けます。WebLogic Server のリクエストと応答の非同期処理が使用されない場合は、すべての「信頼性のある」オペレーションは「一方向」でなければなりません。詳細については、BEA e-docs ページの「@Oneway アノテーションの使用」および「非同期の要求と応答を使用した Web サービスの呼び出し」を参照してください。
- バージョン 10.x のサービス コントロールではバージョン 8.1 の onDeliveryFailure コールバック メソッドが提供されないので、これに対処します。onDeliveryFailure メソッドは、信頼性のあるメッセージが配信されなかったという通知を提供するように設計されていました。バージョン 10.x にアップグレードされた Web サービスでこの機能をサポートするには、@weblogic.jws.AsyncFailure アノテーションと、WebLogic Server のリクエストと応答の非同期処理を組み合わせて使用します。
- 最後に、クライアント サービス コントロールをアップグレードします。これを行うには、完全にアップグレードされた Web サービスを表す WSDL ファイルが必要となります。WSDL には、信頼性のあるメッセージングに必要なポリシー情報が含まれていなくてはなりません。この目的に使用できる WSDL を入手するには、<URL_of_deployed_web_service>?WSDL という形式の URL を指定して、該当する Web サービスの WSDL を Web ブラウザに表示します。
必要な WSDL を入手してから、以下のいずれかを実行します。
- 新しい WSDL ファイルからサービス コントロールを生成し直す。
- @com.bea.control.ServiceControl.Policy アノテーションを既存のサービス コントロール (クラス レベル) に追加し、その Web サービス用に作成したポリシー ファイルを指定する。WSDL からは以下の例のようなポリシー情報が得られる。
注意 : Web サービスでの非同期に関連するオプションの概要については、「イベントとコールバックによる長期稼動の実現」を参照してください。
以下に、アップグレードされた Web サービスの簡単な例を示します。
@Transactional(true)
@UseWLW81BindingTypes()
@WLHttpTransport(serviceUri = "reliable/ReliableService.jws")
@WLWRollbackOnCheckedException()
@WebService(serviceName = "ReliableService",
targetNamespace = "http://www.openuri.org/")
@javax.jws.soap.SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT,
use = javax.jws.soap.SOAPBinding.Use.LITERAL,
parameterStyle = javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED)
@Policy(uri="ReliableServicePolicy.xml", direction=Policy.Direction.both, attachToWsdl=true)
public class ReliableService implements java.io.Serializable
{
static final long serialVersionUID = 1L;
@SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT,
use = javax.jws.soap.SOAPBinding.Use.LITERAL,
parameterStyle = javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED)
@WebMethod()
@Oneway()
@WebResult(name = "doSomethingResult")
public void doSomething()
{
...
}
...
}
注意 : 障害通知をサポートするには、コードを WebLogic Server のリクエストと応答の非同期技術に移行する必要があります。詳細については、BEA e-docs ページの「非同期の要求と応答を使用した Web サービスの呼び出し」を参照してください。
クライアント コードの基本的な概要は、次のようになります。
@WebService
public class ClientService
{
@Control()
private ReliableServiceControl reliableServiceControl;
@WebMethod()
public void someMethod(String parm)
{
// サービス コントロールのメソッドを呼び出す
reliableServiceControl.doSomething(parm);
}
@AsyncFailure(target="reliableServiceControl", operation="doSomething")
public void onDoSomethingFailure(AsyncPostCallContext apc, Throwable e)
{
// ここでエラーを処理する
}
}
<s0:Policy s1:Id="ReliableServicePolicy.xml"> <wsrm:RMAssertion xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"> <wsrm:InactivityTimeout Milliseconds="600000"/> <wsrm:AcknowledgementInterval Milliseconds="200"/> <wsrm:BaseRetransmissionInterval Milliseconds="3000"/> <wsrm:ExponentialBackoff/> <beapolicy:Expires Expires="P1D" xmlns:beapolicy="http://www.bea.com/wsrm/policy"/> </wsrm:RMAssertion> </s0:Policy> <wsp:UsingPolicy n1:Required="true" xmlns:n1="http://schemas.xmlsoap.org/wsdl/"/>
アノテーションの uri 属性には、<Policy> 要素にある Id 属性の値を指定します。アノテーションの direction 属性の値としては、ServiceControl.Direction.both を指定します。次に例を示します。
@ServiceControl.Policy(uri="ReliableServicePolicy.xml", direction=ServiceControl.Direction.both) public interface ReliableServiceControl extends com.bea.control.ServiceControl
サポートされていますが、非推奨になっています。バージョン 8.1 では、送信 SOAP エラーの内容を制御するためのラッパー クラスと受信 SOAP エラーから内容を取得するための API が提供されていました。この機能を使用するコードはバージョン 10.x にアップグレードされたコードでもサポートされていますが、この機能は非推奨になっています。
この機能はこのリリースで非推奨になっているので、将来のリリースのために別のソリューションを用意し、新しいコードではこの機能を使用しないようにする必要があります。たとえば、JAX-RPC で提供される javax.xml.rpc.soap.SOAPFaultException クラスの使用を検討してください。詳細については、Web サービスの開発に関する WebLogic Server ドキュメントの「例外の送出」を参照してください。
バージョン 8.1 では、@jc:handler および @jws:handler アノテーションに callback 属性があり、コールバックに関連付けられた SOAP メッセージを処理するハンドラを指定するために使われていました。バージョン 10.x には、コールバックに特有のハンドラ サポート機能はありません。バージョン 10.x でこれらのアノテーションに対応する機能については、「アノテーションのアップグレード」を参照してください。
サポートされていますが、非推奨になっています。バージョン 8.1 では、アプリケーションまたはランタイムからチェック済み例外が送出されると、コンテナ管理によるトランザクションはランタイムでロールバックされました。バージョン 10.x では、この動作は @Transactional アノテーションと @WLWRollbackOnCheckedException() アノテーション (アップグレード ツールにより Web サービスのソース コードに追加される) によりサポートされます。
バージョン 10.x では XQuery マップ (Web サービスのオペレーションをやり取りする XML メッセージを XQuery を使用して再成形するためのバージョン 8.1 の機能) はサポートされていません。Web サービスのクライアントの構築元になる WSDL の形式は、XQuery マップによって部分的に定義されます。XQuery マップには、マップのアノテーションが付けられたオペレーションで受信または送信が予期される型が指定されるからです。マップが削除されると、ほとんどの場合で予期される型が異なってしまい、Web サービスのインタフェースが変更され、クライアント呼び出しが失敗します。これにより、Web サービスから生成される WSDL の形式も変更され、その WSDL のバージョン 8.1 のコピーから生成されたその他すべてのファイル (サービス コントロールなど) は Web サービス自体に一致しなくなります。
注意 : XQuery マップがサポートされなくなっても、XQuery 自体はサポートされています。引き続き XMLBeans API を使用して XQuery 式を実行できます。この API に影響を与えるアップグレードでの変更については、「アップグレードされた XQuery 実装をサポートするための XQuery の使用の更新」を参照してください。
これを回避する方法の 1 つは、XQuery マップを使用しないで、アップグレード後の WSDL がバージョン 8.1 の WSDL 形式に一致するように Web サービスのオペレーションを書き換えることです。そうすることで、Web サービスを呼び出すクライアントは、バージョン 8.1 の Web サービスによってすでに確立されていたインタフェース規約に依存できます。
次に、これを行うための高度な手順について説明します。
- バージョン 8.1 で、バージョン 8.1 の Web サービスから WSDL ファイルを生成します。
- WebLogic Workshop バージョン 8.1 の [アプリケーション] タブで JWS ファイルを右クリックし、[WSDL ファイルの生成] をクリックします。
- バージョン 8.1 で、上記で生成された WSDL ファイルを使用して、バージョン 10.x のアプリケーションにインポートする、新しい Web サービスのソース コードを生成します。ここでは、オペレーションで XQuery マップが使用されない Web サービスを生成する必要があります。この Web サービスのオペレーションでは、マップが使用されていたオペレーションと同じ形式で XML メッセージの送受信が行われるようにします。
- バージョン 8.1 で、上記で生成した WSDL ファイルを右クリックし、[複製] をクリックします。これにより、既存の JWS ファイルが上書きされなくなります。
- 複製された WSDL ファイルを右クリックし、[Web サービスの生成] をクリックます。
Web サービスのメソッドに対して XMLBeans 型を使用するかどうかを確認するプロンプトが表示されます。[はい] を選択すると、IDE では受信メッセージの一部をバインドできる XMLBeans 型のパラメータを持つメソッドが作成されます (このバインドは実際には XQuery マップによって行われていました)。[いいえ] を選択すると、IDE ではパラメータ型として使用できる内部クラスのコードが生成されます。
オペレーションで必要とされる XML 形式が Web サービスのアップグレード後も確実に有効なままにするには、XMLBeans 型を保持するほうが信頼性は高くなります。
- オペレーションでマップが使用されていた元の Web サービスのコードを使用して、新しく生成されたマップなしの Web サービスに元のサービスのロジックを実装します。このプロセスの一部として、既存のクライアントを使用して新しいマップなしの Web サービスをテストし、マップなしでも旧バージョンの機能が引き続き存続していることを確認してください。
- アップグレード ツールを使用して、マップなしの Web サービスを含んだバージョン 8.1 のアプリケーションをバージョン 10.x にアップグレードします。 アップグレード ツールにより、ほとんどすべてのアプリケーションの更新作業 (型、アノテーション、プロジェクト構造などの更新) が行われます。
- 既存のクライアントを使用して、アップグレードされた Web サービスをテストします。
バージョン 8.1 では、Web サービスのオペレーションから java.util.Map のインスタンスを返すことがサポートされていました。XML とのマップの、WebLogic Workshop 固有のシリアライゼーションがランタイムで提供されていました。そのシリアライゼーションのスキーマは、Web サービスの WSDL に含まれていました。バージョン 10.x では、java.util.Map インスタンスを Web サービスのオペレーションから返すことができなくなっています。
java.util.Map によって提供されるキーと値の機能をサポートしている、アプリケーション定義の型を指定します。その型は、JAX/RPC Java と XML 間のシリアライゼーション ルールに準拠している必要があります。アプリケーション定義の型に、その型のキーの型または値の型のサブクラスが含まれる場合は、weblogic.jws.Types アノテーションを使用して、実行時に含めることのできる型を指定する必要があります。以前に java.util.Map を返していた Web サービス (およびそのクライアント) は、この新しいアプリケーション定義の型を使用するように手動で更新されなければなりません。
影響を受ける対象 : XMLBeans および XQuery を使用するコード (Web サービス、コントロール、ページ フロー、エンタープライズ JavaBean など)
旧バージョンの XQuery 実装は非推奨になっていますが、このバージョンでは下位互換性を保持するためにサポートされています。旧バージョンの実装に基づくクエリは保持されますが、旧バージョンの実装が使用されるように指定するための特別な XmlOptions パラメータが追加されます。
注意 : 旧バージョンの実装は、JSP ファイルでは自動的にはアップグレードされません。これらのファイルにある XQuery コードに Path._forceXqrl2002ForXpathXQuery オプションを手動で追加する必要があります。
次に、旧バージョンの XQuery エンジンを指定する XmlOptions パラメータが追加された、アップグレードされたコードの例を示します。
import org.apache.xmlbeans.impl.store.Path;
import org.apache.xmlbeans.XmlOptions;
String queryExpression =
"for $e in $this/xq:employees/xq:employee " +
"let $s := $e/xq:address/xq:state " +
"where $s = 'WA' " +
"return $e";
try{
XmlCursor resultCursor = empCursor.execQuery(m_namespaceDeclaration + queryExpression,
(new XmlOptions()).put(Path._forceXqrl2002ForXpathXQuery));
resultXML = resultCursor.getObject();
resultCursor.dispose();
}catch(Exception e){
System.out.println(e.getLocalizedMessage());
}
バージョン 10.x でサポートされている標準に準拠するように XQuery 文字列のアップグレードも開始する必要があります。新旧の標準の詳細については、次の表のリンクを参照してください。
|
|
|
||||||
|
|
|
||||||
|
|
|
バージョン 9.0 または 9.1 上でコンパイルされた WebLogic Server の Web サービスをデプロイする場合には、バージョン 10.x にデプロイする前に再コンパイルが必要になることがあります。Web サービスのコードに以下のアノテーションのいずれかが含まれていると、再コンパイルが必要になります。
weblogic.jws.Conversation
weblogic.jws.Context
weblogic.jws.Callback
weblogic.jws.ServiceClient
org.apache.beehive.controls.api.bean.Control
バージョン 8.1 の IDE には、IDE で関連ファイルを同期した状態で保持するための一連の機能が含まれていました。たとえば、WSDL からサービス コントロールが生成された後に WSDL に対して変更が行われると、それに対応するように IDE でサービス コントロールが自動的に再生成されました。この機能はバージョン 10.x の IDE ではサポートされていません。
以下の場合に、「ソース」WSDL ファイルに変更が行われたら、コンテキスト メニューと適切な生成アクションを使用して、生成されているファイルを手動で再生成する必要があります。
- WSDL からサービス コントロールが生成されている場合
- WSDL から Web サービスが生成されている場合
バージョン 8.1 のクライアントは通常、バージョン 10.x の Web サービスとの相互運用でサポートされますが、バージョン 8.1 のクライアントがサポートされるのは、バージョン 8.1 からアップグレードされたバージョン 10.x の Web サービスとの通信に対してのみとなります。たとえば、@Oneway アノテーションが付けられたオペレーションを含んだバージョン 10.x の Web サービスから生成される WSDL は、バージョン 8.1 ではサポートされません。
バージョン 9.2 では、JMS キューを指定して JMS 転送を実行できますが、新しい JWS アプリケーションでは「jws.queue」を使用しないでください。「jws.queue」は、JMS 転送がサポートされているアップグレードされた JWS および JPD アプリケーションで使用されるため、WLI 対応のドメインで競合してしまうからです。