最新開発ツールではじめるWebサービス入門 〜 Orbix E2A XMLBusエディション活用講座〜

　XMLのデータを、HTTPなどのプロトコルに乗せてやりとりするのがWebサービスの目的ですが、その特徴として、

プラットフォームやアプリケーションに依存しない

ということが挙げられます。またHTTPを使うのであれば、ファイアウォールも問題なく通過できるので、

企業間連携（BtoB）にはもってこい

という利点もあります。

　サービスという観点から見た場合、サービス間の連携で必ず問題になってくるのが「アダプタ」の存在です。アダプタを使ってサービス同士を接続しようとすると、接続するサービスの組み合わせの数だけアダプタが必要になることになります。これでは、システムがあっという間に訳が分からなくなること請け合いです。その点、「Webサービス」という1つの共通のインターフェイスを使用することで、異なるシステムが提供するサービス同士であっても、インテグレーションにかかる費用を劇的に削減できるメリットがお分かりいただけることと思います。

　そもそもWebサービスには、「既存／新規のサービスをWebで統合してどのマシンからでも使えるようにする」という目的があります。ここで、新規のサービスは別として、「既存のサービス」にはどんなものがあるのでしょう？ では、その内容はともかく、どのように作られているのでしょうか？ そんなことは知りませんね。必要がないからです。

　Webサービスを作成する際に知っておかなければならないのは、そのサービスがVisual Basicで作られているのか、Javaなのか、はたまたEJB、C、COM、CORBA、COBOL、PL/1といった、どの言語で作成されているかです。それさえ分かってしまえば、あとはXMLBusエディションを入手し、実際にWebサービスを作成するだけです（XMLBusエディションは、無料で入手できます。下記のサイトから申し込むことが可能です）。

http://www.iona.co.jp/evaluation/entry_xmlbus.html

　XMLBusエディションには、アプリケーションやサービスにラッピングを行うことで、Webサービスのインターフェイスを提供する機能があります。つまり、既存のサービス群をそのままWebサービス対応にできるのです。

　実行環境に関しては、組み合わせるアプリケーション・サーバによって事情は異なりますが、今回のように実験レベルで触ってみる程度でしたら、スタンドアロンで十分でしょう。本キットにはサーブレット・コンテナも同梱されていますので、それをそのまま利用することで動作が可能です。すでにWebLogicやWebSphere、Orbix E2A アプリケーション・サーバ・プラットフォームを持っている方なら、それをそのまま流用することも可能です。

　まず最初に、Orbix E2A XMLBusエディションをインストールします。インストールの際にはJDKと、使用するアプリケーション・サーバの指定が必要です。XMLBus Web Service Builderを起動すると、エクスプローラのように左側にフォルダ階層構造のようなリストが、右側にその内容が表示されていることが分かります（画面1）。左側のリスト部分には、あらかじめ10個以上のサンプルのWebサービスが一覧表示されていますので、実際にそれぞれの構成を見て研究してみるといいでしょう。

画面1　Orbix E2A XMLBusエディションのメイン画面。ウィンドウの左側がプロジェクトの一覧で、右側がその内容だ（画面をクリックすると拡大表示します）

画面2　Webサービスを作成するためのボタン

　画面上部にあるツール・バーの右側5つのボタンが、Webサービスを作成するためのものです（画面2・3）。それぞれ左から、Javaクラス用、EJB用、CORBAオブジェクト用、オペレーション・フロー用、XMLスキーマ・マップ（データ変換）用となっています。どの種類の環境で作られたサービスなのかによって、作成開始時に押すボタンが変わってきます。それぞれのボタンを押すことで、ウィザードが走ります。

画面3　XMLスキーマ・マップの定義を行っているところ（画面をクリックすると拡大表示します）

　作業手順自体は至極簡単で、Javaクラスを例にとると、アプリケーション名、Webサービス名、ポート名（エンドポイントの情報をひとまとめにしたもので、ここまでは任意の文字列）、クラスファイルおよびクラス名、メソッドなどを、ウィザードに従って入力していくだけです。これだけで、あっという間にWebサービスが出来上がります。細かなオプションはあとで変更できるので、とりあえず作ってみるという程度であれば、説明不要なくらい簡単なものです。出来上がったものの実体は、WSDLファイルや属性を定義したXMLファイルなどですが、これらはXARファイルとして、ZIP方式でひとまとめにアーカイブされます。

　作成したWebサービスは、アプリケーション・サーバ上に配置（デプロイ）しないと使えません。デプロイ作業自体はXMLBus Web Service Builderから行うことが可能です。

　デプロイされたWebサービス（アプリケーション）の一覧は、Web Service Managerを起動することにより確認できます。先ほどの作成画面で表示されていたサンプルは、すでに一覧表示されているはずなので、ここでそれぞれの詳細を見ることができます。作成したWSDLファイルの内容を確認したり、実際のアプリケーションの動作の簡易テストを行うことができます。それだけでなく、サンプル・アプリケーションを使って、ほかの製品で作成されたWebサービスとの簡易接続検証試験を行う、といった使い方も考えられます。

　また、XMLBus Web Service Builderの「Generate」メニューより、実際にWebサービスにアクセスするためのJ2SEおよびJ2MEクライアント・コードや、Javaサーバ・スケルトンクラスを出力できますので、カスタマイズが必要な場合は便利でしょう。

　XMLBusエディションでは、カスタマイズという観点からも多岐にわたる上級開発者向けAPIを提供しており、データの圧縮や暗号化などの柔軟なプログラミングも思いのままです。セキュリティという観点からは、SSLを用いることによりSOAP over HTTPSに対応しており、また既存のディレクトリ・サービスやPKIとの連携が可能です（SAMLおよびXKMSをサポート）。

　複数のクラスやコンポーネントであっても、オペレーション・フローから作成することによって単一のWebサービスとして公開する方法もあります。これは、サーバ、オブジェクト、入出力をパネルに見立て、お絵かきツールのようにドラッグ＆ドロップで組み合わせることで、1つのWebサービスにしてしまうものです（画面4）。一連の処理の流れを1つのサービスとして再利用できるので便利です。

画面4　オペレーション・フローの作成の様子。ドラッグ＆ドロップでパーツを組み合わせることで、簡単にWebサービスの作成が行える（画面をクリックすると拡大表示します）

　プラットフォームに依存せず、ネットワーク経由でどこからでも利用できるのがWebサービスのメリットの1つですが、インターネット上のどこかで公開されている自分に適したサービスを見つけ出すには、どこにどんなサービスがあるかといった情報が、一元管理されてなければなりません。Webブラウザで相手先サーバの指定に「IPアドレスの直打ちしかしません」という人がいないように、Webサービスでも同様のことがいえます。Webサービスにおいて、WebでいうところのDNSに相当するのが、UDDI（Universal Description, Discover and Integration）という仕組みです。Webサービスの公開にあたっては、このUDDIに登録して、初めて意味のある公開となるわけです。XMLBusエディションでは、Registry Managerがこれに相当します。

　これで、あなたもWebサービス・クリエータへの第一歩を踏み出したわけですが、ここまででSOAPやWSDLの専門知識は必要だったでしょうか？ 何か、かなりのシステム構築の作業工数が短縮できるような気がしてきませんか？ 早速トライしてみようと考えている人がいるかもしれません。

　さて、実際にWebサービスを実務で使うことを考えると、サービスが1つしかないようでは、「そんなものわざわざWebサービスでやる必要ない」といわれてしまうでしょう。やはり、複数のサービスを組み合わせたときに、Webサービスの威力が発揮されるのです。すると、優秀なあなたは複数のサービスをワーク・フロー制御できたらいいなと考えることでしょう。XMLBusエディションには、そのためのパスも用意されています。例えば、オンライン・ショップのシステムを作る場合を考えてみましょう。

　顧客は石鹸をカードで買いたかったとします。まず顧客はB社のサイトにアクセスし、カタログ一覧から目的の石鹸を選び、「在庫および納期確認」のボタンを押します。B社ではカタログ情報しか管理していないため、在庫や納期のデータを持っている親会社のI社のシステムに問い合わせなければなりません。I社からの応答が返ってくると、B社はそれをWebページに表示します。「在庫あり」ということで、顧客が「購入」ボタンを押すと決済はM社のサービスを使い、問題がなければB社はI社に発注をかけるといった具合です（図1）。

図1　オンラインショップで買い物をする場合のWebサービスの動作例

　それぞれの会社に「サービス」がありますが、その順番と制御がきちんとしていないと、この購入シナリオは成り立ちません。そして、こういった一連の流れを1つの「サービス」としてまとめて使えればナイスだ、というのも分かるでしょう。XMLBusエディションには、サービスの流れを管理する「プロセス・フロー」という機能があり、オプション・パッケージとして入手することができます。

画面5　オプション・パッケージとして提供される「プロセス・フロー」

　システム間接続では、インターオペラビリティ（Interoperability）は非常に大事です。「異なる会社のWebサービス同士が問題なくつながるのか」「独自の拡張などは本当にないの？」という検証をする必要があり、これはもう接続試験をたくさん行うしかありません。XMLBusエディションの場合は、「Web Services Interoperability Test Results」などを参考にするしかないわけです。この中にRound1やRound2という表現がありますが、数字が増えるほうがテスト項目が厳しいと考えてください。Round1は単純なデータ型が通る状態、Round2はもう少し複雑な配列、構造体といったデータ型がきちんと保証される状態、Round3はそれらがWSDLのレベルで保証されるといったところです。当然、厳しいテストほどそれをクリアできる製品は少なくなってくるわけですが、Round3ともなると、検証できているのは、XMLBusエディションとマイクロソフトの製品だけというのが現状です。

　＠ITに掲載されている「BtoBが大事な本当の理由」という記事を読んで、

• サービス（アプリケーションやプラットフォーム）に依存しない
• 企業間でサーバ同士が通信している

ということで、「お、EAIとかBtoBとかいってるけど、Webサービスとかなり似てるな」と思ったらしめたものです。これが、「新しい概念ではない」と冒頭に書いた理由です。また、Webサービスがなぜ一気にブレイクしないのかという理由でもあります。

http://itpro.nikkeibp.co.jp/free/NC/NEWS/20020516/2/

　文中で、エリック・ニューカマー氏は「同様の機能を実現するEAI製品の存在」を理由にあげています。さらに、「古いものはそのうち淘汰され、必ず日の目を見るものになるが、そのときに独自のベンダー色みたいなものがついていないことが重要」というようにも感じるのですが、皆さんはどのように受け止められたでしょうか。そうだとするとWebサービスの未来は明るいわけで、そうなることを切に願います。Webサービスの普及は、開発者の皆さんの双肩にかかっているといっても過言ではありません。