SOAP アプリケーションで WSDL を活用する方法

SOAP プログラマーのための WSDL 入門

Web Services Description Language (WDSL) は、ネットワーク経由の XML ベース・サービスを記述するための新しい仕様であり、これによって基礎になるプロトコル (Simple Object Access Protocol や XML など) やエンコード方式 (Multipurpose Internet Messaging Extensions など) にかかわりなく、サービス・プロバイダーが自システムに対する要求の基本フォーマットを記述することができます。Universal Description, Discovery and Integration (UDDI) イニシャティブでは、電子ビジネス用オンライン・サービスのディレクトリーや記述方法を提供するための作業が行われていましたが、この WSDL はまさにその主要な成果と言えます。本稿では、この WSDL の背景を簡単に取り上げ、技術的な解説を示したいと思っています。XML と XML 名前空間についての知識を前提として話を進めますが、XML スキーマと SOAP についてもいくらかの知識があれば、さらに理解が深まると思います。

Uche Ogbuji, Consultant, Fourthought, Inc.

Uche photoUche Ogbuji 氏は、Fourthought, Inc. のコンサルタント兼共同設立者です。この会社は、企業のナレッジ・マネジメントのための XML ソリューションを専門とするソフトウェア・ベンダー兼コンサルタント会社です。Fourthought では、XML、RDF、およびナレッジ・マネジメント・アプリケーション用のオープン・ソース・プラットフォームである 4Suite を開発しています。Ogbuji 氏は、ナイジェリア出身のコンピューター・エンジニア兼ライターで、現在は、米国コロラド州ボールダーに住み、そこで働いています。



2000年 11月 01日

過去数年にわたり、ネットワーク経由のサービス要求 のための標準仕様の案がいくつも登場してきました。これらは、今後 XML ミドルウェアの分野で重要な役割を果たすと思われます。インターネットなどのネットワーク経由で、リモート・マシンから XML 関連機能を要求するための方法、それがネットワーク経由のサービス要求です。

こうした標準仕様の主導権争いには、Allaire Corp の Web Distributed Data eXchange (WDDX) (参考文献を参照)、UserLand Inc の XML Remote Procedure Call (XML-RPC)、Microsoft、David Winer 氏、IBM などによる Simple Object Access Protocol (SOAP) (参考文献を参照) など、そうそうたる面々が加わっています。そのような動きの一方で、一部の開発者たちは、従来のプレーンな HTTP をベースにして、優れたアプリケーションを構築してきました。こうした XML ベースのネットワーク経由サービスに関連して、最も著しい発展を遂げてきたのが、コンテンツのやり取りや共有という分野なのです。

そのようなコンテンツの記述方法や構造を定義するためにも、やはり多くの仕様が提唱されています。その中でも特に注目に値するのは、Vignette Corp などによる Information Content Exchange (ICE) と、Netscape などによる RDF (Resource Description Framework) Site Summary (RSS) でしょう (いずれも参考文献を参照)。さらに、広く採用されているインターネット標準仕様 Multipurpose Internet Messaging Extensions (MIME) を使って、優れた仕事をしている開発者たちも少なくありません。

そのほかにも、XML プロトコルに関連したイニシャティブは実にたくさんあります。こうした状況を受けて、W3C では、この種の問題に取り組むために、XML Protocol ワーキング・グループを設置したばかりです (参考文献を参照)。W3C がこの重量級のワーキング・グループによって統一基準のようなものを作り出そうとする中で、各陣営がどのように火花を散らし合うのかは、たいへん興味のあるところです。

Web アプリケーション間の通信方法として、これほど多種多様な仕様が入り乱れている中で、通信プロトコルや要求構造の種類にかかわりなく、XML ベースのネットワーク・サービスを記述するためメカニズムがどうしても必要になってきました。そのようなメカニズムがあれば、先進的な Web 開発の作業では、さらに自動化が進んでゆくことでしょう。たとえば、次のような可能性が考えられます。

  • ポータル・サイト向けのツールキットでは、コンテンツ・セクション用のプラグイン・システムを提供できるかもしれません。そのようなシステムがあれば、アプリケーション設計者は、技術的な詳細情報をいちいち調べなくても、多彩なオンライン・サービスの中から必要なものを手軽に選び出せるようになるでしょう。
  • 業界グループやサービス・ブローカーは、オンラインの XML サービスをまとめた総合的なホワイト・ページやイエロー・ページを公開できるかもしれません。そのような情報を活用すれば、開発者は、技術的な評価や比較検討を手早く済ませることができるはずです。
  • サービス・プロバイダーは、自社の要求構造の更新事項やバージョンアップ情報を標準フォーマットで手早く公開できるかもしれません。それに応じて、開発者は、更新情報を自動的に取り込んでゆけるはずです。

IBM、Ariba、Microsoft の各社は、そのようなメカニズムの策定に乗り出し、9 月 25 日に、Web Services Description Language (WDSL) バージョン 1.0 (参考文献を参照) を発表しました。その日まで、この "1.0" の仕様がベールに包まれていたのは、いくらか奇妙なことであり、そのために XML コミュニティーは、リリース前の検討機会を失いました。それはともかく、この WSDL は、ネットワーク経由の XML サービスを記述するためのフォーマットであり、これまでに述べたようなニーズをかなりの程度まで埋め合わせるのは間違いないでしょう。

背景

WSDL は、これまでに登場した多くの仕様をベースにしており、一部の仕様とは実際に重なり合っている部分があります。WSDL の背景を示すために、その下敷きになったいくつかの仕様を簡単に取り上げてみましょう。WebMethods の Web Interface Definition Language (WIDL) は、リモート Web Services の記述の先駆けとなった仕様の 1 つですが、RPC や CORBA といったリモート・プロシージャー・テクノロジーのユーザーにとっては、たいへん馴染み深いアプローチ (つまり、ローカル・マシン上の機能と同じようにして、リモート・マシン上の機能にアクセスする方法) を採用した XML フォーマットでした。UserLand による XML-RPC とこの WIDL は、相性は悪くありませんでした。しかし、プロシージャー・ベースの XML テクノロジーよりも、メッセージ・ベースの XML テクノロジーのほうが広く定着したため、WIDL は姿を消してしまいました。XML-RPC も、SOAP に道を譲りつつあるようです。SOAP のほうは、プロシージャー指向のアプローチだけでなく、メッセージ指向のアプローチもサポートしているからです。

SOAP では、エンベロープとメッセージのフォーマットが記述されており、基本的な要求/応答のハンドシェーク・プロトコルが用意されています。さらに、Microsoft が今年の初めに開発した SOAP Contract Language (SCL) では、SOAP ベース・アプリケーション用のオンライン・サービスを記述するための仕組みが提供されました。この SCL をはじめ、IBM や Ariba による他のプロトコルや関連作業の成果が、段階的に WSDL に取り込まれていったわけです。

この WDSL が登場する直前に、IBM、Ariba、Microsoft をはじめとする 36 社からなるコンソーシアムが、Universal Description, Discovery and Integration (UDDI) システム (参考文献を参照) を立ち上げました。これはまさに、ビジネス・サービスの標準的なディレクトリーを想定して、ディレクトリーやサービス・プロバイダーの検索用の精巧な API を用意するための試みです。

Microsoft は、WSDL の登場前から、Web Services の記述という分野にかなり力を入れていました。今となっては忘却のかなたに置かれつつある Discovery of Web Services (DISCO) (参考文献を参照) も、Microsoft の公式の .NET 戦略プランからは外れているとはいえ、Microsoft が投入した仕様の 1 つです。DISCO は、特定の要件にかなったサービスの SCL 記述を見つけ出す ("発見する") 方法を示した仕様です。確かに、DISCO の仕様を読んでも、その価値がどこになるのかはなかなかつかみ難いのですが、その実用的な部分は、間違いなく UDDI と WSDL の中に散りばめられています。

Microsoft が SCL に取り込んでいたころ、IBM では、Network Accessible Service Specification Language (NASSL) (参考文献を参照) を開発していました。IBM も、NASSL の着想を WSDL に十分組み込んだようです。NASSL の執筆担当者たちが WSDL プロジェクトに参加しているのは、その証拠でしょう。IBM はさらに、Advertisement and Discovery of Services (ADS) によって、サービスの検索の分野にも踏み込みました。ADS の正式な仕様書はまだ存在しないようですが、IBM の alphaWorks プロジェクト発の Web Services Toolkit には、その仕様の参考実装が組み込まれています (参考文献を参照)。

これまでの説明で完全に混乱してしまったとしても、心配するには及びません。XML というのは、他の仕様をたくさん生み出す以外に使い道のない仕様だ、と冗談まじりに嘆いてみせた人は何人もいます。UDDI グループの結成によって、サービスの記述という分野に一筋の光が差し込むのではないでしょうか。現在の混乱状態から、Web ベース・サービスを展開するための統一的なプロトコルがまとまり、秩序らしきものが生まれてくるはずです。おそらく、サービスの検索、記述、要求/応答のためのプロトコル、要求構造とデータ・タイプ指定、セマンティックの検索、そしてもちろんトランスポートのためのプロトコルなど、いろいろなフォーマットをそれぞれリンクしたようなかたちで、その種の統一的なプロトコルがまとまってゆくのだろうと思います。図 1 は、これまでに述べた様々な仕様を系統的にまとめ、その種の秩序を私なりに示したものです。いくらかでも視界が良好になれば幸いです。このような全体像の中で、WSDL は、サービスの記述メカニズムという位置を占めることになります。

図 1. サービスの役割と相互関係

WSDL 文書のサンプル

WSDL と SOAP のかかわり方について、サンプルを使って考えてみましょう。このサンプルに出てくるのは、snowboard-info.com という架空の会社です。スノーボード業界のデータベースから、各スノーボード・メーカーの広告内容を検索するためのサービスを提供するという、大胆な発想に基づく会社です。クライアントは、サーバーからそのような情報を取り出すための要求を送信できますが、そのための SOAP 要求の一例がリスト 1 です。リスト 1 にカプセル化されている要求を日常の言葉で表せば、「K2 の FatBob を推奨しているプロ・スノーボーダーはだれか」ということになります。

リスト 1. SOAP 1.1 の要求
POST /EndorsementSearch HTTP/1.1
Host: www.snowboard-info.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 261
SOAPAction: "http://www.snowboard-info.com/EndorsementSearch"
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body>
   <m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">    
     <manufacturer>K2</manufacturer>
     <model>Fatbob</model>
   </m:GetEndorsingBoarder>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

サーバーからは、この要求に対する応答を送信できますが、その SOAP 1.1 応答メッセージ (HTTP ヘッダーなし) の一例がリスト 2 です。日常の言葉で表せば、「Chris Englesmann」というシンプルな回答がカプセル化されています。

リスト 2. SOAP 1.1 の応答
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body>
   <m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
     <endorsingBoarder>Chris Englesmann</endorsingBoarder>
   </m:GetEndorsingBoarderResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

この場合、要求の全体的な構造、関連するデータ・タイプ、使用する XML 要素のスキーマなどは、SOAP の仕様そのものからして、取引先のパートナーに任されています。WSDL が提供するのは、要求のタイプや要求処理のための要件を統一したサービス記述の標準仕様です。

スノーボードのホット情報を載せたポータル・サイトや専門サイトをすべてこのシステムで拾い上げるために、WSDL 通信ポート を定義することにしましょう。そのためには、この会社のサービス・ポイントの WSDL 記述をリリースするわけですが、その一例がリスト 3. スノーボード広告内容検索のための WSDL 記述 です。

リスト 3. スノーボード広告内容検索のための WSDL 記述
<?xml version="1.0"?>
<definitions name="EndorsementSearch"
  targetNamespace="http://namespaces.snowboard-info.com"
  xmlns:es="http://www.snowboard-info.com/EndorsementSearch.wsdl"
  xmlns:esxsd="http://schemas.snowboard-info.com/EndorsementSearch.xsd"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types>
    <schema targetNamespace="http://namespaces.snowboard-info.com"
        xmlns="http://www.w3.org/1999/XMLSchema">
      <element name="GetEndorsingBoarder">
        <complexType>
          <sequence>
             <element name="manufacturer" type="string"/>
             <element name="model" type="string"/>
          </sequence>
        </complexType>
      </element>

      <element name="GetEndorsingBoarderResponse">
        <complexType>
           <all>
             <element name="endorsingBoarder" type="string"/>
           </all>
        </complexType>
      </element>

      <element name="GetEndorsingBoarderFault">
        <complexType>
           <all>
             <element name="errorMessage" type="string"/>
           </all>
        </complexType>
      </element>
    </schema>
  </types>

  <message name="GetEndorsingBoarderRequest">
    <part name="body" element="esxsd:GetEndorsingBoarder"/>
  </message>

  <message name="GetEndorsingBoarderResponse">
    <part name="body" element="esxsd:GetEndorsingBoarderResponse"/>
  </message>

  <portType name="GetEndorsingBoarderPortType">
    <operation name="GetEndorsingBoarder">
      <input message="es:GetEndorsingBoarderRequest"/>
      <output message="es:GetEndorsingBoarderResponse"/>
      <fault message="es:GetEndorsingBoarderFault"/>
    </operation>
  </portType>

  <binding name="EndorsementSearchSoapBinding"
            type="es:GetEndorsingBoarderPortType">
    <soap:binding style="document"
                    transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="GetEndorsingBoarder">
      <soap:operation
        soapAction="http://www.snowboard-info.com/EndorsementSearch"/>
      <input>
        <soap:body use="literal"

namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
      </input>
      <output>
        <soap:body use="literal"
         
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
      </output>
      <fault>
        <soap:body use="literal"

namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
      </fault>
    </operation>
  </binding>

  <service name="EndorsementSearchService">
    <documentation>snowboarding-info.com Endorsement Service</documentation> 
    <port name="GetEndorsingBoarderPort"
          binding="es:EndorsementSearchSoapBinding">
      <soap:address
location="http://www.snowboard-info.com/EndorsementSearch"/>
    </port>
 
 </service>
</definitions>

まずは、安心してもらうために一言添えておきましょう。リスト 3 は確かに長大ですが、実際の WSDL はいたってシンプルです。この WSDL 文書のサンプルでは、WSDL のほとんどすべての面のほかに、大掛かりな XML スキーマも使用しており、さらに言えば、SOAP から WSDL へのバインディングも活用しています。このバインディングについては、同じサービス記述の中に含めてありますが、技術的には標準サービス記述の拡張部分になります。

すべての情報が、関連サービスのセットを記述した<definitions> 要素に組み込まれています。<types> では、メッセージやプロシージャーの内容の下位データ・タイプを指定します。名前空間の拡張機能によって、いろいろなメカニズムの使用が可能になっていますが、ほとんどのユーザーは、XML スキーマを採用することになるでしょう。実際に、このサンプルでも、XML スキーマを採用しています。したがって、サンプルのリスト 1リスト 2 のやり取りでは、要素の内容モデルが統一されているわけです。WSDL では、別個のリソースとして存在しているデータ・タイプ指定をインポートするための仕組みを提供しており、複数の使用ドメインにまたがる複合メッセージの場合には、そのようなリソースが複数存在することもあり得ます。

<message> 要素では、通信のやり取りの中で行われる個々の送信のデータ・フォーマットを定義します。このサンプルでは、1 つのメッセージがEndorsingBoarder 要求を表し、もう 1 つのメッセージがその応答を表します。これは、単純ステートメントであり、メッセージの本体が types セクションのスキーマからの 1 つの要素になっています。この送信がいくつかのメッセージ部分に分割されるかどうかは、データの論理ビューに依存しています。たとえば、この送信がリモート・プロシージャー呼び出しであれば、メッセージが複数の部分に分割される可能性があります。その場合は、1 つがプロシージャー名とメタデータになり、その他がプロシージャーの各種パラメーターになるでしょう。当然、データ・タイプ指定の細分度とメッセージの分割処理の間には、一定の関係があります。

<portType> 要素では、1 つの論理操作を構成するメッセージ群をひとまとめにします。たとえば、このサンプルであれば、EndorsingBoarder 要求によって、EndorsingBoarder 応答を起動するか、エラーや例外の場合には、EndorsingBoarderFault 応答を起動するといった操作が可能です。このようなやり取りを WSDL ポート・タイプ としてひとまとめにするわけです。お気づきのとおり、メッセージとの関連付けは、修飾名の参照によって行います。

WSDL であらかじめサポートされている操作には、4 つの種類しかありません。つまり、一方方向、要求/応答、送信請求/応答、通知 の 4 つです。最後の 2 つは最初の 2 つの "反転" にすぎず、唯一の違いは、想定しているエンド・ポイントが、最初のメッセージの受信側になっているのか、送信側になっているのかというだけのことです。基本的に、WSDL では、単一方向のポート・タイプ (一方方向と通知) と両方向のポート・タイプ (要求/応答と送信請求/応答) をサポートしています。エラーは、両方向のポート・タイプでのみサポートされており、その点は CORBA モデルと違っています。ここでは、そのどちらのアプローチがいいかといった意見の対立には触れないでおきましょう。

これまで、この WSDL 文書については、具体的かつ物理的な点 (データ・タイプ指定) から、抽象的かつ論理的な点 (メッセージとポート・タイプ) に至るまで、その両方の関連も含めて話を進めてきました。このような物理的なモデルと論理的なモデルをしっかりと結び合わせるのが、<binding> 要素です。この場合は、抽象的なポート・タイプで定義した操作を取り込んで、SOAP でどのように送信するかという具体的な記述に結び付けるわけです。ここで登場するのが、前に述べた WSDL の SOAP 拡張機能です。WSDL では、HTTP や MIME そのものに対するバインディングも提供しており、その他のプロトコルへの拡張機能を十分に備えています。

このサンプルのバインディングでは、GetEndorsingBoarderPortType に Document という SOAP "スタイル" を設定しています。スタイルとしては、RPC と Document のいずれかを指定できますが、RPC はどちらかと言えばプロシージャー的な通信形態であり、Document はメッセージ交換による通信形態になります。もちろん、この 2 つのスタイルの境界線はかなりあいまいなので、どのポート・タイプがどちらのスタイルになるのかといった、不毛な論議が行われることになるのではないでしょうか。筆者の独断と偏見によれば、ほとんど場合、Document を使用すればよいだろうと思います。

このサンプルのバインディングでは、ネットワーク・トランスポートとして HTTP を指定しています。もちろん、SOAP は、SMTP などの他の手段でも送信できます。<soap:operation> 要素は、まさに問題の核心に触れるものであり、指定のポート・タイプの個々のメッセージを該当する SOAP 送信の定義に関連付けます。このサンプルでは、SoapAction を指定していますが、この指定は、HTTP 経由の SOAP の場合に必須です。ここで指定する値は、実際のメッセージの HTTP ヘッダーでも使用して、メッセージの "意図" を示さなければなりません。したがって、SOAP 通信のインテリジェントなプロキシー処理やファイアウォール処理がいつの日か可能になるかもしれません。

最後の要素である<service> では、通信エンド・ポイントの物理的な位置を定義します。すでに指定したポート・タイプとバインディングを使って、基本的には、記述対象サービスのプロバイダーの Web アドレスまたは URI を指定するわけです。当然ながら、このサンプルでは、スノーボード製品の広告内容を検索するための SOAP サーバーのアドレスを指定します。

ところで、このようにして立ち上げたサービスが大ヒットして、通信量がサーバーの能力を超えそうになった場合は、どうしたらよいでしょうか。おそらくミラー・サイトをヨーロッパなどにセットアップすることになるでしょう。要するに、サービス自体はまったく同じですが、サービスを手に入れるための URI を別に設けるということです。WSDL の仕組みの場合、そのためには、WSDL 文書を編集して、<service> 要素をもう 1 つ追加するだけでよいのです。その一例がリスト 4 です。

リスト 4. 複数のサイトを運用するための <service> 要素の一例
<service name="EndorsementSearchEuropeanService">
   <documentation>snowboarding-info.com Endorsement Service European
      Mirror</documentation> 
   <port name="GetEndorsingBoarderPort"
      binding="es:EndorsementSearchSoapBinding">
      <soap:address location="http://www.snowboard-info.co.uk/EndorsementSearch"/>
   </port>
</service>

サービス名とアドレスを変えた点に注目してください。何らかのサービス検索の手段によってこの WSDL 文書を見つけたユーザーには、実際の要求の送り先として 2 つの選択肢があることになります。

この WSDL について、全体的なコメントをいくつか加えておきましょう。お気づきのとおり、WSDL は、XML 名前空間に大きく依存しています。デフォルトの場合、<definition> 要素のtargetNameSpace 属性で指定する XML 名前空間は、WSDL の他の最上位要素で使用されるすべての名前に結び付けられます。開発者たちは、それらの要素を参照するために、該当する名前空間宣言からの接頭部を付けた修飾名を使用することもできます。ただし、WSDL 属性内の接頭部なしの名前に対して、デフォルトの名前空間が適用されるわけではありません。このような動作は、XML 仕様の文字データ内の名前を明確にするために XML 名前空間のメカニズムを借用した他のケースとも調和しています。XML 名前空間は、WSDL 要素 (およびバインディング拡張機能からの要素) を、<types> 要素で指定するデータ・タイプに結び付けるためにも使用されます。このサンプルでは、デフォルトの名前空間http://schemas.xmlsoap.org/wsdl/ を使用して、WSDL の正式な要素を指定していますが、WSDL の仕様で明示されているように、他の名前空間の要素を使って、コア要素を拡張する余地も大きく残されています。

全体的に見て、このサンプルは非常にシンプルです。短い SOAP 送信からなる通信ですが、各操作ごとに 2 つの入力ストリングと 1 つの出力だけが指定されています。WSDL では、XML スキーマの極めて広い守備範囲を十分に使い切って、何万というメッセージからなるポート・タイプをたくさん定義するのも難しいことではありません。とはいえ、少なくとも短期的な観点からすれば、XML サービス・プロバイダーとユーザーの間のもっとシンプルな通信のほうが、成功する確率は高いと言えるでしょう。


要約と次回のテーマ

WSDL は、期待されている役割をきちんと果たしています。一見して貧弱な印象は否めないかもしれませんが、XML ベースの商取引のための重要な材料となるのは間違いありません。むしろ、このプロジェクトにかかわった企業の顔ぶれや、それぞれの利害関係を考えれば、このようにシンプルに仕上がっているということのほうが画期的なのです。IBM、Microsoft、Ariba の各社は、複数のベンダーが集まって 1 つの仕様を作り上げる場合の正しい事の進め方を見事に示しました。

WSDL の策定作業では、骨の折れる仕事の重複を避けるために、他のプロジェクトの成果を巧みに取り入れました。XML 名前空間による強力な拡張機能を用意したり、かなり複雑なサービスでも記述できるように、たくさんのツールを組み入れて用途を広げたりしています。要するに、"1.0" というかたちでまとめられて公開されたばかりの仕様については、懐疑的になるのが通例ですが、この仕様については、文句をつけるような個所はほとんどなさそうです。

ただし、WSDL が触れていないことが 1 つあります。それはつまり、RDF との統合の可能性です。W3C がよく使う表現を借りれば、"セマンティック Web" が発展してゆくにつれ、オンライン・サービスの記述も、RDF が評価と信用というネットワークのかたちで提供するあらゆる機能の恩恵を受ける可能性が開けてくるかもしれません。WSDL に関する次回の記事では、RDF と WSDL を併用する道を探ってみたいと思います。

参考文献

コメント

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=244772
ArticleTitle=SOAP アプリケーションで WSDL を活用する方法
publish-date=11012000