![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
JAX-RPC (Java APIs for XML-based Remote Procedure Call) は、Java Community Processにおいて最終的な勧告の段階へと進みました (JSR 101)。XML Webサービス・ベンダーは、Javaプラットフォームで相互運用可能なWebサービスを構築する場合のコアAPIとして、このパッケージの使用を開始しました。このシリーズでは、この標準によって提供される主な機能について、サンプル・コードを使用して段階的に紹介します。
このシリーズの第1回では、WSDL/XMLの型とJavaの型の間のマッピングについて説明しました。さらにその機能がJAX-RPC規格でどう定義されているかについて、また相互運用型システムの設計におけるいくつかの重要なポイントについても説明しました。型マッピングのこの規格は、Webサービス・ランタイム・システムでメッセージ・レベルの相互運用性を実現するのに、ある程度役立ちます。
シリーズ第2回のこの記事では、JAX-RPC規格のクライアント・サイドおよびサーバー・サイドのインターフェース定義およびメッセージ処理モデルを使用して、さらに高いレベルのWebサービス相互運用性を実現する方法を説明します。
JAX-RPC仕様には、次の点が含まれていることを思い起こしてください。
- 型マッピング・システム
- サービス・エンドポイント
- 例外処理
- サービス・エンドポイント・コンテキスト
- メッセージ・ハンドラー
- サービス・クライアントおよびサービス・コンテキスト
- SOAP With Attachments
- ランタイム・サービス
- JAX-RPCクライアント呼び出しモデル
シリーズ第1回では、JAX-RPCの型マッピング・システムのいくつかの重要なポイントについて述べました。今回は、仕様のその他の部分のポイントを説明します。第1回と同じように、架空の書店Acme Booksellersが提供するWebサービスのサンプル・コードを示して、それらの重要ポイントを説明します。このサンプルの詳細については、第1回の記事をご覧ください。また、付録で、WSDLの全サンプル・コードのリストを参照できます。(参考文献を参照。)
JAX-RPCのサービス・エンドポイント とは、実際のサービスが実装されているWebサービス・エンドポイントのことです。図1 に示すように、サービス・エンドポイント実装 (具象) クラスと、サービス・エンドポイント・インターフェース定義とが1つずつ用意されています。
図1. サービス実装インターフェース階層
Webサービス・エンドポイント・クラスは、WSDL2Java (Apache Axis提供のWSDLからJavaへのマッピング・ツール) を使用することによりWSDL定義に基づいて作成した、サービス・エンドポイント・インターフェースからの派生クラスです。それらのサービス・エンドポイントは、JAX-RPC仕様書のセクション5.2に記述されているサービス・エンドポイント・インターフェース定義に準拠していなければなりません。その定義によれば、次のような要件があります。
- どのサービス・エンドポイントも
java.rmi.Remoteインターフェースを継承したものでなければなりません。 - このインターフェースを使って実装するどのメソッドも、
java.rmi.RemoteExceptionをスローしなければなりません。この標準的な例外に加えて、アプリケーション特有の例外も可能です。 - メソッドのパラメーターはJAX-RPCでサポートされるJavaの型でなければなりません。仕様によれば、これによりJavaプラットフォームとそれに対応するXML型に固有のシリアライゼーション/デシリアライゼーションのメカニズムが保証されます。
- 普通、Javaインターフェースでは、定数データに
public static finalの宣言を使用します。しかし、JAX-RPC仕様では、この宣言の使用が勧められていません。WSDL 1.1には、wsdl.porttypeの中で定数を記述する標準的な手段がないからです。 - インターフェースのメソッドへの引数として、
HolderクラスおよびSOAPElementクラスを使用できます。(HolderクラスとSOAPElementクラスについては、このシリーズの第1回を参照。)
サービス・エンドポイント・インターフェースの例をリスト1 に示します。
リスト1. サービス・エンドポイント・インターフェース
Public interface AuthorSearchService implements java.rmi.Remote{
Public Books[] seachForAuthor(String authorName) throws java.rmi.RemoteException,
com.acme.InvalidAuthorName;
}
|
リスト1 に示すサンプル・エンドポイント・インターフェースでは、ランタイムのRemoteException とアプリケーション・レベルのInvalidAuthorName の両方を処理しています。それらのアプリケーション例外のWSDLのコンテキストでの意味と相互の関係については、JAX-RPCの例外処理の説明のところで詳しく書くことにします。
また、SOAPベースの分散システムと、その他のプロトコル (RMIなど) による分散システムの実装上の主な相違点の1つとして、前者ではオブジェクトを参照によって渡したり戻したりすることがサポートされていないことがあげられます。したがって、サービス・エンドポイントを作成する際に、リモート参照をパラメーターまたは戻り値として使用することは避けてください。さらに、Java値の型と配列にリモート参照を入れないようにしてください。
ベンダーによっては (WASPなど)、オブジェクトのリモート参照をサポートした実装を提供している場合もあります。しかし、それらの実装を使用するコードは、ランタイム・システムに関して移植性がなくなってしまう可能性があります。たとえば、リスト2 に示すコードは、BookSearchBroker オブジェクトを参照によって戻しているため、一部のJAX-RPCシステムではサポートされない可能性があります。
リスト2. 移植できない可能性のあるコード
Public interface BookSearchBroker extends java.rmi.Remote{
Public Books[] searchForAuthor(String tickerSymbol) throws java.rmi.RemoteException;
}
public interface StockQuote extends java.rmi.Remote{
public BookSearchBroker getBooksSearchBroker() throws java.rmi.RemoteException;
}
|
サービス・エンドポイントの実装クラスは、サービス・エンドポイント・インターフェースから派生したものです。サービス・エンドポイントのこの実装クラスには、そのインターフェースに加えて、サービスのライフサイクルを管理するためのServiceLifecycle インターフェースも実装できます (図1 を参照)。そのインターフェースは、リスト3 のように宣言されています。
リスト3. ServiceLifecycleのインターフェース宣言
Public interface ServiceLifecycle{
void init (Object context) throws ServiceException;
void destroy();
}
|
これを見るとわかるように、JAX-RPCランタイム・システムは、このインターフェースを使用することによってWebサービスの各インスタンスのライフサイクルを管理できます。(サービスの実装がサーブレットなら、そのランタイム・システムはサーブレットのコンテナーです。)サービス・エンドポイント・クラスのロードと、そのインスタンス生成は、ランタイム・システム側で実行します。インスタンスの生成後、ServiceLifecycle.init() メソッドを呼び出して、サービスのインスタンスを初期設定します。ServiceLifecycle.init() には、パラメーターとしてランタイム・コンテキスト (ServiceContext) が渡されることが想定されています。ランタイム・コンテキストについては、後述の「サービス・コンテキスト」のセクションでさらに詳しく説明します。
サービス・エンドポイント・クラスの開発においては、クライアントに関連した状態情報をそのエンドポイントで保持しないようにしてください。ランタイム・システムは、サービス・エンドポイント・インターフェースの複数のクライアント呼び出しを、その単一のインスタンスに対してディスパッチすることがあります。さらに、ランタイム・システムでサービス・エンドポイントのそれらのインスタンスをプールすることにより、パフォーマンスを上げることができるという点に注意してください。
また、ランタイム・システムは、クライアントへのサービス提供からそのエンドポイントを除去する際に、ServiceLifecycle.destroy() メソッドを呼び出します。これにより、サービス・クラスのそのインスタンスの使用しているリソースを解放できるようになります。
JAX-RPC仕様では、アプリケーション・レベルとランタイム・システム・レベルの両方で、Webサービスの実行時例外に関する事項を含める努力がなされています。それは、サービス・エンドポイント・インターフェースの設計と、wsdl.fault 要素へのマッピングに関する標準的なアプローチに基づいています。
サービス固有の例外は、wsdl.fault 要素の中で宣言されます。それらの例外型はjava.lang.Exception クラスから派生したものです。リスト4 に示すwsdl.operation の宣言には、wsdl.fault の特定の要素が含まれています。
リスト4. wsdl.operationの宣言
<message name="AuthorNotFoundException">
<part name="Author" type="xsd:string" />
</message>
<portType name ="BookSearch">
<operation name="getBooksByAuthor" >
<input message="tns:getAuthorName">
<output message="tns:getBookList">
<fault name=" AuthorNotFoundException" message=" tns: AuthorNotFoundException">
</operation>
</portType>
|
リスト5 は、JAX-RPC仕様に基づいて、サービス固有のJava例外を処理するサービス・エンドポイントを作成する方法を示しています。
リスト5. サービス固有のJava例外の処理
Public interface BookSearch implements java.rmi.Remote{
Public Books[] getBooksByAuthor(String authorName) throws java.rmi.RemoteException,
com.acme.AuthorNotFoundException;
}
|
結果として作成されるJava例外クラスは、リスト6 のようになります。
リスト6. Java例外クラス
public class AuthorNotFoundException extends java.lang.Exception{
...........
public AuthorNotFoundException(String Author ){
.....
}
public getAuthor(){...}
}
|
JAX-RPCでは、ランタイム・システムによるコンテキスト情報の管理方法が、非常に柔軟なものになっています。ServiceLifecycle.init() メソッドは、Object 型のコンテキストを受け取ることに注意してください。保存されるコンテキスト情報は、ランタイム環境ごとにそれぞれ独自のものです。たとえば、サーブレットによるランタイム・システムの場合は、ServletEndpointContext オブジェクトが使用されます。EJB 2.1仕様の場合は、EJBSessionContext が定義されています。
一例として、サーブレットによるランタイム・システムと、その場合のコンテキスト情報の管理方法について詳しく見てみましょう。このサーブレット・エンドポイント・コンテキストには、ユーザー・プリンシパル、メッセージ・コンテキスト、HTTPベースのユーザー・セッション情報、およびサーブレット・コンテキストなどの情報が含まれています。この仕様では、サービス・エンドポイントの各インスタンスごとに、その複数のリモート・メソッド呼び出しを通じて一貫した情報が提供されるようにするため、それらの情報のすべてをサービスのランタイムで管理することが求められています。下記のリスト7に示すサービス・コンテキスト・インターフェースに示されているように、これは、サービスがさまざまな方法で利用できる非常に貴重な情報です。
- HTTPセッション情報は、クライアントでサーバーとのHTTPセッションを管理するのに役立ちます。これは、オプションの機能です。
- ユーザー・プリンシパル (既にランタイム・システムによってそのユーザーが認証済みの場合) は、サービス開発者が、特定のランタイム・アクションに関してユーザーの身元を知るために使用できます。
- このインターフェースによって可能になるもう1つの機能は、SOAPメッセージのコンテキスト伝播がサポートされるということです。それによりサービスのインプリメンターは、要求ハンドラー・チェーンからSOAPメッセージ・コンテキストを入手でき、さらに、そのコンテキストを操作したり、それを応答ハンドラー・チェーンに関連付けたりすることができます。
要するにこのインターフェースは、呼び出し側、メッセージ、および現在の環境に関する動的なランタイム情報を詳細に提供します。
リスト7 に、サービス実装クラスを拡張してライフサイクルの管理をサポートする方法、およびサービス・コンテキストの使用方法を示します。
リスト7. サービス・コンテキスト・インターフェース
Public interface BookSearchServiceImpl implements java.rmi.Remote, javax.xml.rpc.server.
ServiceLifecycle {
public void init(Object context) throws ServiceException{
ServletEndpointConext sC = (ServletEndpointConext)context;
Java.security.Principal userPrinciple = sC.getUserPrincipal();
HttpSession session = null;
Try{
session = sC.getHttpSession();
}catch(JAXRPCException e){ // HTTPベースの
// エンドポイントではない
}
MessageContext ctx = sC.getMessageContext();
}
public void destroy(){
}
public Books[] searchForBooks(String authorName)
throws java.rmi.RemoteException, com.acme.InvalidAuthor{
return null;
}
}
|
いよいよ、JAX-RPC仕様の最も強力な機能であるメッセージ・ハンドラー について考慮しましょう。メッセージ・ハンドラーは、Webサービス・エンドポイント (クライアントとサーバーの両方) に対して、基本的なサービス実装ロジックへの拡張機能として付加的なメッセージ処理機能を提供するものです。ハンドラーは、暗号化と復号化、ロギングと監査、その他の処理を管理できます。現在のところ、JAX-RPCランタイム・システムで定義されているのはSOAPメッセージ・ハンドラーだけですが、その他のハンドラーも柔軟に定義でき、メッセージの処理モデルに依存することがありません。
図2. サービスとハンドラーの呼び出しモデル
JAX-RPCハンドラーのAPIでは、3つの基本的なメソッドと共に、ライフサイクルに関する2つのメソッドが定義されています。それらを、リスト8に示します。
リスト8. ハンドラーのメソッド
public class Handler{
handleRequest(MessageContext context)
handleResponse(MessageContext context)
handleFaults(MessageContext context)
init(HandlerInfo info);
destroy();
...........
}
|
ハンドラーは、ステートレス・インスタンスとして実装する必要があります。ランタイム・システムは、初期化インターフェース (Handler.init (HandlerInfo info)) を提供することによって、必要となるコンテキスト情報をハンドラーに渡すことができます。これによりハンドラーは、コンテナー固有の付加価値機能にアクセスできるようになります。それには、認証メカニズム、機構、トランザクション処理、ロギング・フレームワークなどが含まれます。
APIで提供されるデフォルトのハンドラー、SOAPメッセージ・ハンドラー (SOAPMessageContext をパラメーターとする)、あるいは一般のハンドラーから、新しいハンドラーを派生させても問題はありません。ハンドラーでは、渡されるメッセージを修正できます。セキュリティー上の理由のため、それらのハンドラーは非常に柔軟なものになっており（訳注：SOAPのセキュリティ機能WS-Securityを実装するために柔軟である必要があります）、現在利用できるほとんどのフレームワークでは、それらをランタイム・システムの制御下で管理するようになっています。たとえば、J2EEコンテナーの場合、ハンドラーはJ2EEコンテナーの一部になっていることがあります。したがって、実際に使用する製品に含まれる組み込みハンドラーについては、アプリケーション・サーバー (ランタイム) のベンダーから提供されるドキュメンテーションを調べてください。それら組み込みハンドラーには、WS-Security、WS-Transaction、ロギングのためのものなどがあります。独自のJAX-RPCハンドラーも作成できますが、新しいハンドラーの作成が可能かどうかは、アプリケーション・サーバーのベンダーが、構成やセキュリティーに関するポリシーに基づいて決定する場合があります。
ハンドラー・チェーン は、順序を指定したハンドラーのリストを表すものです。そのようなグループ化は、そのハンドラーの呼び出しモデルにどんなポリシーを関連付けるかを定義する上で役立ちます。そのようなポリシーの例としては、呼び出しの順序、呼び出しの方式 (たとえば1方向の呼び出しではhandleRequest() だけが呼び出され、handleResponse() は呼び出されない) などがあります。ハンドラー・チェーンに対して設定できるポリシーとして、別のものもあります。すなわち、ハンドラー・チェーンでは、SOAPヘッダー・ブロックの最も外側の要素のqname に基づいてハンドラーを呼び出すことができます。そのような関連付けをハンドラーに対して構成するには、Handler.init() メソッドにHandlerInfo オブジェクトを渡します。ハンドラー・チェーンは、現在処理中のハンドラーからtrue が戻された場合にのみ、ハンドラーの処理を継続します。
ハンドラー・チェーンをSOAPのアクター (または役割。SOAP 1.1の仕様書を参照、下記の参考文献のセクションにリンクがあります) に関連付けることができます。それには、アクターのURIを指定します。デフォルトでは、ハンドラー・チェーンは常にnext という特殊なSOAPアクターに関連付けられます。WSDLポートのqname を見るとわかるように、ハンドラー・チェーンは、サービス・エンドポイントごとに登録されます。
リスト9 に、SOAPメッセージ・ハンドラーを処理できるハンドラーの実装例を示します。
リスト9. ハンドラーの例
Public class AcmeSOAPHeaderHandler extends GenericHandler{
Public Boolean handleRequest(MessageContext ctx){
try{
SOAPMessageContext mc = (SOAPMessageContext)ctx;
SOAPMessage msg = mc.getMessage();
SOAPPart sp = msg.getSOAPPart();
SOAPEnvelop se = sp.getEnvelop();
SOAPHeader header= se.getHeader();
// これでヘッダーを処理できる
if (処理が成功)
return true; // ハンドラー・チェーンの
// 処理を続行
else{
// falseを戻してチェーンの処理を停止
return false;
}
}catch(Exception ex){
}
}
}
|
クライアントにとってJAX-RPCのメリットの1つは、エンドポイントのリモート・メソッド呼び出しに、コンテキスト情報を関連付けることができるという点です。JAX-RPC仕様では、コンテキスト情報のセマンティクスについては規定されていません。それは、WSDLバインディングでのSOAPヘッダー定義に基づいてユーザーが明示的に定義できます。WS-Securityなどの規格に基づいて定義できます。あるいは、HTTP要求ヘッダーなどのバインディング固有の情報に基づいて定義することもできます。
このランタイム・コンテキスト情報は、コンテナーにおいて、またはクライアントで設定できます。コンテナーによるコンテキスト管理は暗黙のコンテキスト管理 と呼ばれるのに対し、クライアントによるコンテキスト管理は明示的コンテキスト管理 と呼ばれます。
暗黙 という語が使用されるのは、暗黙のコンテキスト管理の場合、クライアント側でもサーバー側でも、コンテキストの伝播をサポートするためのプログラミングがまったく必要ないからです。それをサポートするのはランタイム・エンジンです。このようなコンテキスト情報としては、セキュリティーやトランザクションに関する情報があります。
明示的 サービス・コンテキストは、サービス・メソッド呼び出しに追加される付加的なパラメーターとして処理されます。JavaパラメーターからWSDLへのマッピングにおいては、このために問題が発生することがあります。そのような付加的なパラメーターがWSDLのヘッダーにマップされるからです。リスト10 に、soap:header 情報を含み、エンドポイントJavaインターフェースによる明示的なサービス・コンテキストの表現を使用したWSDL定義を示します。
リスト10. WSDL定義のためのエンドポイントJavaインターフェース
public interface BookSerachService implements java.rmi.Remote{
public Books[] searchForBooks(String authorName, StringHolder context) throws RemoteException;
}
|
リスト10 では、メソッド・パラメーターにコンテキストが追加されています。
JAX-RPC仕様では、サービス・コンテキストの処理のためのサーバー・サイド・モデルについて規定されていません。サービス・コンテキストを処理するためのハンドラーを定義することは、コンテナーのベンダー (暗黙または明示的なコンテキスト管理)、およびプログラマー (明示的なコンテキスト管理) の責任です。お気付きのように、このことによって、コンテキストのルーティングやヘッダー・メッセージ・プロセッサーの設定がより柔軟なものになります。
JAX-RPC仕様のAPIでは、リモート・プロシージャー呼び出しや戻り値において、MIME符号化によるコンテンツの使用がサポートされています。これは、SOAP With Attachments規格に基づいています (参考文献を参照)。SOAP With Attachmentsのメッセージは、MIMEのmultipart/related型を使用して作成されます。そのルート・パートは元のSOAPメッセージであり、MIMEのコンテンツはメッセージのその他のパートとして追加されます。SOAPのそれらのパートには、MIMEパートへの参照が含まれることがあります。また、MIMEの各パートには、MIMEのパートを特定するためのコンテンツIDまたはコンテンツの位置情報が含まれていることに注意してください。MIMEメッセージの例については、次の図3 をご覧ください。
図3. SOAPメッセージ・パッケージ
Javaサービス・エンドポイント・インターフェースのリモート・メソッドでは、MIME符号化コンテンツのためにいくつかのJava型のうちの1つを使用できます。
- JAX-RPC仕様では、MIME型に直接マップされる一連のJavaクラスが提供されています。たとえば、
-
Image/gifはjava.awt.imageにマップされます。 -
text/plainはjava.lang.stringにマップされます。 -
text/xmlはjavax.xml.transform.Sourceにマップされます。
すべてのマッピングのリストについては、JAX-RPC仕様書のセクション7.5を参照してください。(仕様書へのリンクが参考文献にあります。)
-
-
javax.activation.DataHandlerは任意のMIME型にマップ可能です。
JAX-RPCランタイム・システムは、次のものを使用することによって、MIMEパートのMIME型を決定します。
- WSDLの
mime.content要素を使用して定義されたMIME型 - SOAPメッセージに含まれるMIMEパートの
Content-Type
JAX-RPCランタイム・インフラストラクチャーについては、サポートしなければならないいくつかの要件があります。ここでは、その最も重要なもののうち2つについて説明します。
JAX-RPCランタイム・システムでは、基本的なHTTP認証をサポートしなければなりません。クライアントは、HTTPサーバーに対してユーザー名とパスワードを送信し、それらの情報がそこで検証されます (HTTPサーバーはJAX-RPCランタイム・システムの一部と見なされます)。その他のすべてのセキュリティー・メカニズム、機構 (ディジタル証明書、SSL、WS-Securityなど) は、クライアントおよびサーバーJAX-RPCシステムによって提供される付加価値機能です。それらは、JAX-RPCハンドラーとサービス・コンテキスト伝播を使用することによって処理できます。詳細については、実際に使用するランタイムのシステム・ドキュメンテーションを参照してください。
この要件は、クライアントがサービス・エンドポイントとのセッションに参加できるようにするためのものです。JAX-RPCランタイム・システムでは、次のうちの少なくとも1つをサポートする必要があります。
- Cookieベースのセッション管理
- URLの書き換え
- SSLセッション
このセッション管理プロセスは、サーバーが開始します。クライアントでそのセッションのサポートが可能であることを明示するには、session.maintain プロパティーをtrue に設定します。その方法については、サンプルをご覧ください。
JAX-RPCのセッション管理で明らかに欠落していることの1つは、現在ではほとんどのツールキットでサポートされているSOAPヘッダー・ベースのセッション相関の要件です。セッション管理のための標準的な手法を定義したのであれば、仕様の次の改訂ではこの問題が扱われて、WS-Iプロファイルやその他の規格に対する各方面の同意が得られるものと期待してよいでしょう。
図4. クライアント・サイドのJAX-RPC
図4 に示されているように、クライアントからのサービス・エンドポイント呼び出しには3種類のモデルがあります。それらは、特定のサービス実装モデルとは独立したものです。ここでは、それらについて1つずつ説明します。
-
スタブ・ベースのモデル (静的スタブ)。サービス・スタブを作成するには、次の2通りの方法があります。
- Javaサービス・エンドポイント・インターフェースから
- サービスのWSDL記述から
スタブ・クラスは、(WSDL2Javaを使用して) WSDLからでも、サービス・エンドポイント・インターフェースからでも生成できます。生成されるスタブ・クラスは、javax.xml.rpc.stubの実装においても、サービス・エンドポイント・インターフェースの実装においても必要です。このスタブ・インターフェースには、エンドポイント・アドレス、セッション、ユーザー名、パスワードなどのプロパティーを設定してスタブを構成するためのAPIが用意されています。
-
動的プロキシー。上記の静的スタブとは異なり、実行時にクライアントが
javax.xml.rpc.Serviceインターフェースを使用して動的にスタブを作成します。クライアントは、WSDLとそれが呼び出すに関する知識を事前に 持っています。クライアントはServiceFactoryクラスを使用することによって、サービスを作成したりプロキシーを取得したりします。
- DII (動的呼び出しインターフェース)。このソフトウェア・パターンでは、クライアントが事前にサービスの正確な名前やパラメーターを知っておく必要がありません。DIIクライアントは、サービスに関する情報を調べることのできるサービス・ブローカーを使用することによって、実行時にその情報を入手できます。このようにサービスに関する情報入手が柔軟になることにより、ランタイム・システムは、状況に応じたサービス発見メカニズム (ebXMLレジストリー、UDDIなど) を採用する複数のサービス・ブローカーを使用できるようになります。
J2EEによる開発作業では、J2EE固有の次のようなJAX-RPC要件があることに注意してください。
- サービスで登録とルックアップ機能をサポートするためには、
javax.naming.referenceableまたはjava.io.serlializable、あるいはその両方のインターフェースをサポートする必要があります。 - コンポーネントのプロバイダーは、デプロイメント記述中のすべてのサービス参照を宣言する必要があります。
ここまでで、JAX-RPCのうち、相互運用可能なWebサービスを生成するために使用できる機能のほとんどについて説明しました。JAX-RPC規格に関するこの初級シリーズをマスターすれば、最大限の相互運用性を備えたWebサービスを開発できるようになります。前に述べたように、JAX-RPCのランタイム・エンジンの実装として利用できるものにはさまざまなものがあり、そのサービスの機能 (J2EEサポート) の品質はさまざまに異なっています。そのため、アプリケーション・コンテナーのベンダー提供の情報を常に参照して、JAX-RPCサポートに関する詳しい情報を得るようにしてください。今のところ、このシリーズで述べた機能のすべてを単独で提供するJAX-RPCランタイム・システムはありません。やがて、相互運用可能型マッピングの標準規格として最近のSOAP仕様およびWSDL仕様 (どちらも現在のバージョンは1.2) をサポートするよう、JAX-RPC仕様書が改訂されることと思います。また、相互運用可能な型マッピングの規格としてJAXB (Java XML Binding、JSR 31) がJAX-RPCに採用される可能性もあります。Webサービスがさらに多くのサービス・プロファイルやSOAPヘッダー拡張をサポートするよう発展していくにつれて、この仕様がどう移り変わっていくかに注目しましょう。
- このシリーズの第1回、「JAX-RPCの紹介: 第1回」(developerWorks、2001年11月) もご覧ください。
- この記事の付録をご覧ください。そこには、この記事で使用されているサンプルの完全なWSDLリストが含まれています。
- Java Community ProcessからJAX-RPC仕様を入手してください。
- JAX-RPC仕様の解説は、Apache Axis beta 3 およびSun's Web Services Developer Pack に基づいています。この記事のコードは、これらのテクノロジーを使用してテストされています。
- 最新のIBM Web Services ToolkitをalphaWorksから入手して、試用することができます。
- このシリーズを読みながら、以下に示すW3Cの仕様を気軽にお調べなることをお勧めします。
- WSDL
- SOAP
- SOAP Messages with Attachments
- XML
- IBM developerWorks の Web services specifications のページも役に立ちます。
- 以下に示すグループは、Webサービスの相互運用性のための活動を行っています。
- JSR 109、Implementing Enterprise Web Services もご覧ください。この標準化作業は、IBM主導によるものです。
目次
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ