JAX-RPC の紹介: 第1回 JAX-RPC型マッピング・システムのすべてを学ぶ

型マッピングは相互運用可能なWebサービスの基礎を築く

JAX-RPC (Java APIs for XML-Based Remote Procedure Call) は、Webサービスの相互運用の達成における重要な前進となりました。2つの記事からなるシリーズのこの最初の記事で、Joshy Joseph氏は相互運用推進の核であるJAX-RPC型マッピング・システムについて説明します。この記事では、XML型をJava型へ変換する方法について解説し、Webサービス・クライアントとJavaベースのアプリケーションの間でスムーズにデータを交換できるようにします。

Joshy Joseph, Software Engineer, IBM OGSA Development Team

Joshy JosephJoshy Joseph 氏は、ソフトウェア・エンジニアとして、IBM OGSA 開発チームで作業しています。彼が現在関心を持っているプログラミング分野は、Web サービス、セマンティック・ウェブ、グリッド・コンピューティングといった新しいテクノロジー、および UML、AOP、XP に基づくプログラミング・モデルです。



2002年 11月 01日

JAX-RPC (Java APIs for XML-based Remote Procedure Call) は、Java Community Processにおいて最終的な勧告の段階へと進みました (JSR 101)。XML Webサービス・ベンダーは、Javaプラットフォームで相互運用可能なWebサービスを構築する場合のコアAPIとして、このパッケージの使用を開始しました。このシリーズでは、この標準によって提供される主な機能について、サンプル・コードを使用して段階的に紹介します。このシリーズを最後まで読み終えるころには、JAX-RPC仕様の中心的な機能について精通していることでしょう。こうして得た知識は、サービス、クライアント、およびツールセット開発者が、相互運用性を最大限に高めるようにWebサービスを設計するのに役立つことでしょう。

この記事では、読者がSOAP、WSDL、およびXMLなどの基本的なWebサービスの概念に精通していることを前提としています。(これらの詳細および他の関連トピックについては、参考文献のセクションを参照してください。この記事に出てくるサンプル・コードは、すべてApache Axis beta 3およびSun Web Services Developer Packを使用して開発されました。つまり、JAX-RPC仕様の参照版を使用して開発されました。

この記事は、2部からなるシリーズの最初の記事です。この記事では、JAX-RPCの最も重要な面の1つである型マッピング・システムに取り組むことから始めます。このシステムは、ランタイム・システムがWSDL文書に定義されている各XML型を、対応するJavaサービス・インターフェースに指定されたJava型にマップできるようにします。また、その逆も可能にします。これは、相互運用が可能なWebサービスへの大きな一歩となります。JAX-RPCは、XMLとJava型の拡張セットのための拡張型マッピング・サポートを指定します。JAX-RPCランタイム・システムは、この型のマッピングをサポートするためのシリアライゼーション・フレームワークをインプリメントします。

次の記事では、この記事で扱う内容を基に、仕様の残りの部分について解説します。

JAX-RPCの基本概念

Webサービスの開発者であれば、Webサービスの標準 (SOAP、WSDL、XML) によってもたらされる利点や体系上の柔軟性についてすでにご存じでしょう。Webサービスの背後にある概念を理解すれば、抽象的なインターフェースによる疎結合のサービスを設計することができ、サービス定義からサービスのインプリメンテーションを切り離すことができます。Webサービスにおいて直面する最も重要な問題は、相互運用可能なサービスを開発することです。この問題を解決するために、さまざまな規格グループ (WS-I、OASIS、W3C、およびSOAPBuilders) は、多くの努力をして相互運用性のための標準を定義しようとしています (詳細については参考文献を参照してください)。

JAX-RPCは、この問題を解決するためにJavaコミュニティーによって作成されました。これにより、クライアントとサーバーの両方でWebサービスをインプリメントするための良く知られたアプリケーション・プログラミング・インターフェース (API) を提供することができます。JAX-RPCは、Webサービスに標準のAPIを採用することによって、サービスの相互運用の仕事をランタイム・インフラストラクチャーへ移して、サービス利用者 (クライアント) とサービス提供者が最大限に柔軟に作業できるようにすることを目指しています。ランタイム・フレームワークは、標準組織によって提供されているグローバル・スタンダードを採用して、適切に定義されたプロファイル (たとえば、WS-I) を使用し、さらにそれらの標準に適合するようにIDEおよび他の開発ツールを作成することによって、回線レベルの相互運用性を提供できます。

JAX-RPCは、その中心部分で、XMLベースのリモート・プロシージャー・コールのメカニズムを定義し、使用します。JAX-RPCは、サーバー (つまり、サービス提供者) が標準のAPIを使用してサービスを定義し、WSDLを使用してサービスを記述できるようにします。さらに、クライアント (つまり、サービス利用者) が標準のAPIを使用してサーバーと通信できるようにします。

この仕様は広範囲に及ぶもの (約160ページ) で、Java開発者向けの新しいプログラミング・パターンを網羅しています。このシリーズの記事で紹介する概念を以下に示します。

  • 型マッピング・システム
  • サービス・エンドポイント
  • 例外処理
  • サービス・エンドポイント・コンテキスト
  • メッセージ・ハンドラー
  • サービス・クライアントおよびサービス・コンテキスト
  • SOAP With Attachments
  • ランタイム・サービス
  • JAX-RPCクライアント呼び出しモデル

上述のとおり、この最初の記事では、リストの中の最初の概念であるJAX-RPCの型マッピング・システムに焦点をあてます。この仕様の他の重要な概念については、今後の記事で解説する予定です。

各トピックで、架空の書店であるAcme Booksellersが提供するWebサービスのサンプル・コードを例示して、重要なポイントを解説します。

図1. JAX-RPCフレームワークを使用したAcme BooksellersのサンプルWebサービス・アプリケーション
図1. JAX-RPCフレームワークを使用したAcme BooksellersのサンプルWebサービス・アプリケーション

この書店は、ビジネス・パートナーが以下のようにさまざまな方法で使用できるサービスを提供します。

  • 顧客が、特定の検索基準 (ISBN、著者名など) に基づいて本を検索できる.
  • 承認された著者が、本の更新情報をアップロードできる
  • レビュアーが本のレビューを書き込むことができる

読者の皆さんは良くご存じのように、Webサービスのアーキテクチャーおよびインプリメンテーションへの体系的なアプローチには以下の2つの方法があります。

  • トップダウン方式 (つまり、WSDLから始める)
  • ボトムアップ方式 (つまり、Java実装クラスから始める)

このAcme Booksellersを使用した例では、JAX-RPCプログラミング・モデルに適合したトップダウン方式の設計およびインプリメンテーションを使用する方法を説明します。付録で、サンプル・サービスのWSDLファイルを参照することができます。そのコードを十分に検討してから、次のセクションに進んでください。


JAX-RPCの型マッピング・システムの紹介

JAX-RPC仕様がもたらす最も重要な事柄は、WSDL文書をJava表現 (サービス・エンドポイント、スタブ、タイ、およびJava型)へマッピングする (およびその逆) ための標準を定義することです。これまでは、Webサービス・ツールキットの各ベンダーが、関連する標準 (WSDL、SOAP、およびXML) とそれらの間の関係について独自の解釈を持っていたため、大きな混乱が生じていました。これらの標準がそれぞれ別々に発展し、しかも信頼できるほど十分に成熟していないことが、混乱を一層深めています。

JAX-RPCが共通のプログラミング・モデルを定義することによって、これらの問題をどのように解決しようとしているかを詳しく見ていきましょう。この標準化の動きがWSDL 1.1およびSOAP 1.1に基づいていることを覚えておいてください。

JAX-RPC仕様書のWSDLからJavaへのマッピングに関するセクションには、以下について記述されています。

  • XML型からJava型へのマッピング
  • WSDLの抽象的な定義 (ポート・タイプ、操作、およびメッセージ) からJavaインターフェースおよびクラスへのマッピング
  • WSDLの具体的な定義 (ポート、結合、およびサービス) からJavaクラスへのマッピング

これらについて順番に取り上げましょう。


XML型からJava型へのマッピング

シンプル型

XMLスキーマおよびSOAP 1.1エンコード方式によって定義されるシンプルなXMLデータ型のほとんどは、それぞれの対応するJava型にマップされます。JAX-RPC仕様書の表4-1で、このマッピングの詳細を見ることができます (参考文献を参照)。

開発者は、シンプルなXML型のマッピングに関していくつかの点を覚えておく必要があります。まず第一に、JAX-RPCマッピング仕様は、xsd:anyType に対しては、なんら特定のJavaマッピングを与えていないという点です。

第二に、組み込みシンプルXMLデータ型でnillable 属性がtrue に設定されている要素宣言は、Javaプリミティブ型のJavaラッパー・クラスにマップされるという点です。たとえば、以下に示すコードはjava.lang.Integer にマップされます。

<xsd:element name="code" type="xsd:int" nillable="true" />

これにより、ヌル・オブジェクトを対応するXML型にマップできる柔軟な型システムを設計することができます。JAX-RPC仕様書の表4-2で、このマッピングに関する詳細なリストを見ることができます (参考文献を参照)。

第三に、SOAP 1.1エンコード仕様は、型のほとんどをnillable としてマップするという点です。JAX-RPCは、Javaラップ・オブジェクトを使用してこれらの型をマップします。詳細については、JAX-RPC仕様書の表4-3を参照してください。

メタデータとJSR 175

Javaコミュニティーは、Java言語でメタデータ情報を使用できないという問題に取り組んでいます。JSR 175で提案されているメタデータ機能は、Javaクラス、インターフェース、メソッド、およびフィールドに追加の属性を指定できるようにします。Webサービスの分野では、このメタデータ機能 (属性) を使用してWebサービスの構成とデプロイメント・モデルを拡張しようという別のプロジェクト (JSR 181) も進行しています。

複合型

XML Schema複合型は、getterおよびsetterによってJavaBeansにマップされ、複合型内の各要素にアクセスできるようにします。これらの型を扱う場合も、いくつか点を覚えておく必要があります。まず第一に、複合型にxsd:sequence が含まれている場合でも、JavaBeansでは要素の順番は保たれないということを覚えておくのは重要です。

第二に、要素属性maxOccurs に正の値が設定されている複合型は、対応する型のJava配列にマップされるという点です。このような型は、minOccursmaxOccurs の可能なすべての組み合わせを定義するわけではありません。これは、XML Schemaに関連するセマンティクスすべてをマップする方法を考えているJava開発者にとって問題となり得ます。

第三に、このマッピングに関する大きな問題の1つがXML要素属性のマッピングであるという点です。Javaクラスに関連付けられたメタデータがないため、JavaBeansをWSDLに変換しようとするときにマッピングの問題が生じる場合があります。このため、JAX-RPC仕様ではxsd:attribute をマップする方法について記述していません。しかし、SOAPバインディングの場合は、この目的のためにSOAPElement を使用することができます。これは、将来のJava言語の進展によって解決されるものと考えられます。このことに関する詳細については、「メタデータとJSR 175」という囲み記事を参照してください。

リスト1 は、複合型のマッピングがどのように機能するかを示しています。

リスト1. 複合型のマッピング
<xsd:complexType name ="Book">
<sequence>
  <element name="author" type="xsd:string" maxOccurs="10" />
  <element name="price" type="xsd:float" />
</sequence>
<xsd:attribute name="reviewer" type="xsd:string" />
</xsd:complexType>

リスト1 の型がgetterおよびsetterメソッドを使用しているJavaBeansにマップされているのがリスト2です。

リスト2. リスト1の型のJavaマッピング
Public class Book{
    private float price;
    private String[] author;
    private String reviewer;  // attribute
    //....
    public String[] getAuthor() {.......}
    public setAuthor(String[] author) {.......}
    public float getPrice() {.......}
    public void setPrice(float price) {.......}
    public String getReviewer() {.....}
    public void setReviewer(String reviewer) {.....}
}

配列

JAX-RPCは、演算子[] を使用してXML配列をJava配列にマップします。WSDLサービス宣言には、いくつかの異なる種類の配列宣言があります。

最初の型は、WSDL 1.1に指定されているwsdl:ArrayType 属性を使用して制限されている、soapenc:Array から派生する配列です。

リスト3. 制限およびwsdl:ArrayTypeによる配列の定義
<complexType name = "ArrayOfString">
<complexContent>
    <restriction base="soapenc:Array">
    <attribute ref="soapend:ArrayType" wsdlArrayType="xsd:string[]">
    </restriction>
</complexContent>
</complexType>

JAX-RPCは、こうした複雑な型の配列を、java.lang.String を使用して配列内の要素として、JavaString[] にマップします。

次の配列型は、SOAP 1.1仕様に従って制限されているsoapenc:Array から派生します。

リスト4. 制限およびsoapenc:Arrayによる配列の定義
<complexType name = "ArrayOfString">
<complexContent>
   <restriction base="soapenc:Array">
   <sequence>
         <element name="stringArray" type="xsd:string"
              maxOccurs="unbounded" />
   </sequence>
   </restriction>
</complexContent>
</complexType>

JAX-RPCは、これらの複雑な型の配列を、java.lang.String を使用して配列内の要素として、JavaString[] にマップします。

WSDLにある別の種類の配列宣言は、以下のとおりです。

<element name="myNumbers" type="soapenc:Array" />

リスト5 は上記のスキーマのインスタンスを示しています。

リスト5. Javaオブジェクト配列へのマッピング
<myNumbers soapend:arrayType="xsd:int[2]" >
<number>1</number>
<number>2</number>
</myNumbers>

この宣言は、XML Schema型に対応する配列の個々の要素によって、JavaObject 配列にマップされます。(ここでは、integer にマップされます。)

最後に、ユーザー定義のXML Schema型から構成される配列もあります。リスト6は、そのような型の定義を示しています。

リスト6. スキーマ型の定義
<complexType name="Article">
   <all>
      <element name="name" type="xsd:string">
      <element name="author" type="xsd:string">
   </all>
</complexType>

ここで、Article 型の配列を定義する必要があります。

リスト7. ユーザー定義スキーマ型による配列の定義
<complexType name="ArrayOfArticles">
<complexContent>
   <restriction base="soapenc:Array">
   <sequence>
     <element name="article" type="tns:Article"
          maxOccurs="unbounded" />
   </sequence>
   </restriction>
</complexContent>
</complexType>

WSDL内の上記の宣言は、型Article (Article[] article;) のJava配列にマップされます。


抽象WSDL型からJava型へのマッピング

XML型をJava型へマッピングする方法が分かったところで、WSDLの特殊なケースについて考えてみましょう。まず最初に、抽象的なWSDL型がJava表現にどのようにマップされるかを簡単に説明します。

  • wsdl:porttype: この型は、サービス・エンドポイント・インターフェースにマップされます。これは、java.rmi.Remote インターフェースを拡張します。サービス・エンドポイント・インターフェースとその要件については、このシリーズの次の記事で紹介する予定です。
  • wsdl:operation: WSDL 1.1は固有にすべき操作名について何も述べていないため、同じ名前でパラメーターが異なる操作が多重定義される場合があります。さらに、JAX-RPC仕様は、WSDL仕様で定義されているように一方向の要求/応答操作しかサポートしないことに注意する必要があります。請求/応答または通知スタイルの操作はサポートしません。WSDLでのパラメーターの順番は、オプションのparameterOrder 属性を使用して指定できます。

では、パラメーターが渡される方法を見てみましょう。表1 に概略されているように、それらはパラメーターが扱われる方法によって、inout、およびinout となります。

表1. パラメーターを渡す方法
パラメーターの定義元パラメーター・スタイル可能なJAX-RPCマッピング・クラスJAX-RPCサンプル・マッピング・クラス
wsdl:inputinラッパー・クラスまたはJavaBeansjava.lang.Integer
wsdl:outputoutHolder クラスIntHolderStringHolder、その他
wsdl:input およびwsdl:outputinoutHolder クラスIntHolderStringHolder、その他

表1 で示されているように、out およびinout パラメーターをサポートするために、新しいHolder クラスが定義されます。サービス・クライアントは、Holder クラス・インスタンスを使用して、out またはinout パラメーターの値を送信します。Holder クラスの内容は、リモート・メソッドの呼び出しによって変更でき、サービス・クライアントはメソッド起動の後でもこの変更された内容を使用できます。JAX-RPC仕様は、基本型をサポートするための、Holder クラスの数を定義していることに注意してください。Holder と呼ばれる標準のインターフェースから、独自のHolder クラスを定義して複雑な型をサポートできます。

このことをサンプル・コードで示してみましょう。 リスト8 は、サンプルのWSDL定義です。

リスト8. サンプルのWSDL定義
    <xsd:complexType name="Authors">
    <xsd:all>
    <xsd:element name="Authors" type="typens:AuthorArray"/>
    </xsd:all>
    </xsd:complexType>
<message name="AuthorPresentRequest">
        <part name="Authors" type="typens:Authors"/>
    </message>
    <message name="AuthorPresentResponse">
        <part name="return" type="xsd:boolean"/>
        <part name="Authors" type="typens:Authors"/>
    </message>
    <portType name="AcmeAuthorPresentPortType">
        <operation name="IsAuthorPresent">
            <input message="typens:AuthorPresentRequest"/>
            <output message="typens:AuthorPresentResponse"/>
        </operation>
    </portType>

入力および出力メッセージにパラメーターとしてAuthors 型が含まれていることにお気付きになることでしょう。これは、パラメーターを渡す場合のinout スタイルです。この場合、リスト9 に示すように、Authors 型ではHolder クラスが必要です。

リスト9. Authors型のサンプルHolderクラスを作成する
public final class AuthorsHolder implements javax.xml.rpc.holders.Holder {
    public com.acme.www.Authors value;
    public AuthorsHolder() {}
    public AuthorsHolder(com.acme.www.Authors value) {
        this.value = value;
    }
}

最後に、リスト10 はJavaエンドポイントを実装する方法を示しています。

リスト10. Javaエンドポイントの実装
public interface AcmeAuthorPresentPortType extends java.rmi.Remote {
   public boolean isAuthorPresent(AuthorsHolder authors) throws java.rmi.RemoteException;
}

サービス・エンドポイント・インターフェースの名前とエンドポイント・メソッドのシグニチャーが派生する方法について理解する必要があります。それらは、wsdl.portType の名前属性および操作定義から、またはwsdl.binding の名前および操作宣言から派生します。同じportType を示す、異なるスタイルの複数のバインディング (たとえば、RPC/文書) が存在するため、これは覚えておくべき重要な点です。バインディング・スタイルのこの違いは、異なる名前とシグニチャーを持つ異なるエンドポイントを作成する結果につながります。そのため、このマッピングの混乱に対して注意している必要があります。

SOAPメッセージ・スタイルと操作エンコード

ご存じのように、SOAPメッセージ・スタイルには文書 とRPC の2つがあり、これらがSOAPメッセージ本文の形式を定義します。さらに、操作のパラメーターをエンコードするモードには、literal とencoded の2つがあります。

表2 は、SOAPメッセージ・スタイルとモード、さらにはJAX-RPCがそれらをどのように定義しているかを示しています。


具体的なWSDL型からJava型へのマッピング

次に具体的なWSDL要素と、それらをJavaにマッピングする方法について考えましょう。

  • wsdl:binding: JAX-RPCはwsdl.binding の標準のJava表現を定義していません。これは、実行時に必要なバインディングを定義できることを意味します。JAX-RPC実行時システムは、少なくとも以下のSOAPバインディングをサポートしています。

    • RPCスタイル (操作モード・エンコード (RPC/エンコード))
    • 文書スタイル (操作モード・リテラル (文書/リテラル))

    リテラル・マッピングの場合、各メッセージ部分は、XML型からJava型へのマッピングのセクションで説明したように、Java型にマップされます。そのようなマッピングが存在しない場合、メッセージ部分はjavax.xml.soap.SOAPElement Javaクラスを使用して表現されます。このマッピングの例は、属性を含んだ複雑な型です。属性には標準のマッピングが定義されていないため、この複雑な型はSOAPElement として表現されます。

    これら異なるスタイルとモードに関する詳細については、SOAPメッセージ・スタイルと操作エンコードおよび表2 を参照してください。

表2. SOAPメッセージ・スタイルとJAX-RPC
スタイル(SOAPメッセージ本文形式)モード (パラメーター・エンコード)JAX-RPC関連情報
文書 (スキーマを使用して本文の形式を定義)リテラル (各パラメーター・エンコードにXMLスキーマを使用)必須
文書エンコード (SOAPセクション5エンコードを使用)オプション
RPC (SOAPセクション7の規則を使用して本文の形式を定義)エンコード必須
RPCリテラルオプション
  • wsdl:service: このWSDLの具体的な定義は、一連のサービス・エンドポイント (つまりwsdl:ports) をグループ化します。JAX-RPCはwsdl:service をJavaサービス・クラスにマップします。このサービス・クラスは、javax.xml.rpc.Service インターフェースを実装するか、wsdl.service 定義にマップされている生成されたJavaインターフェースを実装して、次いでjavax.xml.rpc.Service を実装します。

    このサービス・クラスは、以下のファクトリーとして機能します。

    • サービス・エンドポイントの動的プロキシー (詳細については、このシリーズの次の記事で紹介)。サービス・オブジェクトでgetPort(..) メソッドを使用することによって動的なプロキシーを作成できます。
    • サービス・エンドポイントでのリモート操作の動的呼び出しの型javax.xml.rpc.Call のインスタンス (詳細については、このシリーズの次の記事で紹介)。動的呼び出しインターフェースは、実行時に作成されるCall オブジェクトを必要とします。そのため、サービス・クラスでcreateCall(..) 操作を使用できるようになっています。
    • 生成されるスタブ・クラスのインスタンス (詳細については、このシリーズの次の記事で紹介)。これらのスタブは、ツールによって作成される、生成されたクラスによって提供されます。

    Service インターフェースの実装は、JAX-RPC実行時システムによって行われます。バインディングの要件に応じて、スタブの実装は異なります。さらに、Service 実装クラスは、JNDI名前空間での登録をサポートするために、java.io.Serializable またはjavax.naming.Referenceable インターフェースを実装しなければならないことに注意してください。

拡張可能マッピング・サポート

現在のJAX-RPC仕様は、この記事で紹介したシンプルな型のマッピングを定義しています。この型のマッピングは複雑なデータ型をサポートするには十分ではないため、JAX-RPC仕様は追加され、プラグ可能なシリアライザーおよびデシリアライザーによって型マッピング・システムを拡張するようになりました。現在の仕様では、シリアライザーおよびデシリアライザーへのプラグ可能性を開発および構築するための、アプリケーション・プログラミング・モデルが提供されています。カスタムの型マッピングとサポートされる型のサポートについては、JAX-RPCベンダーに問い合わせてください。しかし、この柔軟性には、Webサービスの実装間で相互運用性の問題が生じる可能性があるという不利な面もあることを覚えておいてください。


Java型からWSDLへのマッピング

当然ながら、JAX-RPC仕様の大部分は、Java型からXML型へのマッピングと、Javaサービス・エンドポイント・インターフェースからWSDL定義へのマッピングについて説明しています。このようなマッピングは、すでにこの記事で扱った内容と同様ですが、処理を逆転させる必要があります。この処理について、この記事では詳しく説明しません。詳細については、JAX-RPC仕様書のセクション5を参照してください。これは、Webサービス設計のボトムアップ・アーキテクチャーであり、主に既存のJavaベースのアプリケーションをWebサービスに変換する、またはそれらのアプリケーションの周辺にラッパーは作成する場合に使用されます。


結論と今後について

この記事では、シンプルな型のマッピングに関するJAX-RPCサポートについて解説しました。これが、Webサービスの実装間で最大限の相互運用性を実現するために理解しておく必要のある中心的な概念と言えます。現在の型マッピングは非常に精巧ですが、データ型のすべての要求をサポートするほど広範囲に及ぶものではありません。そのため、JAX-RPCランタイムの実装では、カスタム・シリアライザーを使用して他の拡張可能型マッピング・メカニズムをサポートしています。

この記事では、JAX-RPCでの型マッピング・サポートについて解説しましたが、JAX-RPCシステムがXMLとJava型を処理する場合の基本概念と、これらの型を他の型にセマンティクスを失うことなく変換するための方法について、読者の皆さんが理解するのに役立てば幸いです。

このシリーズの次の記事では、JAX-RPC仕様のサービス実装、サービス・クライアント、および他の中心的な概念など、別の面について紹介したいと思います。それまでの間、この記事で概略した型マッピング情報をマスターしておいてください。

参考文献

  • Java Community ProcessからJAX-RPC仕様を入手してください。
  • JAX-RPC仕様の解説は、Apache Axis beta 3 およびSun's Web Services Developer Pack に基づいています。この記事のコードは、これらのテクノロジーを使用してテストされています。
  • 最新のIBM Web Services Toolkit をalphaWorksから入手して、試用することができます。
  • このシリーズを読みながら、以下に示すW3Cの仕様を気軽にお調べなることをお勧めします。
  • 以下に示すグループは、Webサービスの相互運用性のための活動を行っています。
  • Webサービスの型マッピングの詳細については、Gavin Bong氏のコラム「Apache SOAP型のマッピング」(developerWorks 2002年3月) の第1回第2回をお読みください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=294411
ArticleTitle=JAX-RPC の紹介: 第1回 JAX-RPC型マッピング・システムのすべてを学ぶ
publish-date=11012002