WSIFは以下の側面をもっています。
- ApacheSOAP-APIを使わない他の方法でWebサービスを呼び出す方法
- ダイナミック・バインディングを実現するフレームワーク
- Webサービスを呼び出すための抽象APIを提供するフレームワーク
WSIFは以下の側面をもっています。
まず、比較の対象となるWebサービスは、会社の名前をStringで渡すと株価が返ってくる「StockQuote」Webサービスで、そのWSDLは下記のものとします。
このWSDLで表現されるWebサービスを呼び出すプログラムコードを、ApacheSOAP 2.2 APIとWSIF APIで比較してみましょう。
Apache SOAP 2.2 APIによるクライアントコード
WSIF APIによるクライアントコード
これらをよく観察して判ることは、WSIFの方は、
WSIFが必要な背景は次のようなことです。
さて、今までの考察からすると、WSIFではサービスの呼び出し方法がいくつも存在することになります。バインディングの拡張ができるということは、いくつものクライアントから自分自身にアクセスし、実行してもらえるという意味では大変よいのですが、クライアントから見れば、サービスの表示方法の統一で問題が生じます。それを、解決しているのが、WSIFの代表的なAPIであるWSIFDynamicPortFactoryというクラスなどです。
現在の呼び出しスタイルは、以下のような欠点をもっています。
WSIFの特徴は以下のようなことです。
ここで、また一言で結局のところどういう仕組みか?というと、WSIF APIは『WSDLを直接読むように、APIは書かれている』と言ってよいでしょう。つまり、WSDLの中身を走査しながら、実装手順としては
また、別の特徴としては、『メッセージinput,outputと、特定のbinding/protocolとの対応を意識する必要がない』ということも挙げられます。行き交うメッセージの特徴は
で表現し、
<binding>・・・・</binding> や
<port name="SOAPPort" binding="tns:SOAPBinding">
<soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port>
とは別に部品的にメッセージ部分と、binding/protocol部分を考えればよいわけです。
WSIFは、最新のIBMのテクノロジーWSHT1.1(料金制Webサービス構築環境)で外部のWebサービスを課金対象とする場合に使われる、WSGWの主要な技術として使われています。また、今後はWebサービスにアクセスするアプリケーション部品を自動生成したり、Webサービスのワークフローエンジンが実行フレームワークとして利用したりするようになります。WSIFがフレームワークとして利用されることにより、アプリケーションの寿命が長くなります。