はじめに

企業単位のSOA（サービス指向アーキテクチャー、Service-Oriented Architecture）に関する記事のシリーズの第1回（「企業単位のSOAにてWebサービスを扱う 第1回: 複数のSOAで企業システムのギャップを埋める」、参考文献)を参照）では、複数のSOAからWebサービス（データ中心(data-centric)またはビジネス・ロジック）を再利用して企業内の制御のもとにある複合アプリケーションとして結合する方法を示すことにより、企業システムのギャップを埋めるシナリオについて考察しました。

Webサービスが企業の制御の外側にある場合、共有されたセマンティックと契約の義務に沿うかたちでWebサービスが外部的に相互運用することを保証すべきです。（例えばプロプラエタリーのような）セマンティックの誤解そして（マルチプラットフォームの相違点のような）契約上の抜け穴が、外部の企業Webサービス間にあるインターオペラビリティーの問題の原因となります。

この記事では、MRP（Manufacturing Resource Planning）そしてCRM（Customer Relationship Management）サービスを実装する4つの下記の例を示します。

1. 企業のレガシー・アプリケーション
2. 外部Webサービスへのダイナミック・リンク
3. 外部WebサービスへのREST/SOAP（REpresentational State Transfer/Simple Object Access Protocol）要求の共存
4. IBM® WebSphere® Application ServerまたはMicrosoft® Visual Studio .Netを使用するWebサービス・インターオペラビリティー

様々な兼ね合いを考慮するだけではなく、SOAのオーバーロードを回避するためにもシステムが抱え込む事ができる相互作用するSOAの最大数を判断するのも大切な事です。

上に戻る

企業のレガシー・アプリケーション

企業のレガシー・アプリケーションがビジネス・プロセスのモジュラー・コンポーネントに分割されていると想定します（図1を参照）。アプリケーションにある2つの重要なコンポーネント（MRPとCRM）は、長期的なアプリケーションの再コンパイルそして頻繁な変更を必要とします。

上に戻る

Webサービスへのダイナミック・リンク

運用の効率をあげるには、アプリケーションからそれらのコンポーネントを抽出してから外部Webサービスとして再構築するのがより道理にかなっていると思われます。そうすれば、大型で複雑かつ長期的なアプリケーションを再コンパイルせずとも、両方のWebサービスのコードを変更できます。

SOA#1（図2を参照）にてよりコンパクトにまとめられたアプリケーションはSOA#2にある外部企業のMRPのWebサービスとのダイナミック・リンクを確立でき、その次にそれはSOA#3にある外部企業のCRMのWebサービスに向けられます。要求を受信すれば、CRMのWebサービスはさらなる処理のためにアプリケーションに要求と情報を送信します。

それぞれのリンクのメカニズムは、要求またはメッセージの送信、応答の受信、またはSQLやHTTPのオペレーションの実行としての形を成します。MRPのコンポーネントに欠けるアプリケーションをラップして、それがMRPのWebサービスに要求を送信するようにすることも可能です。

上に戻る

ソフトウェア・フレームワーク

ひとつのプロトコルから別のプロトコル、そしてひとつのソフトウェア・フレームワークから別のソフトウェア・フレームワークに切り替える場合に、プラットフォーム間のインターオペラビリティーの問題が発生することもあり得ることを念頭に置いてください。SOAP、REST、.Net Framework、EJB（Enterprise Java Beans）、そしてJMS（Java Messaging Service）は、その例の一部です。

HTTPを介する.NetのWebサービスを呼び出す方法には3種類（HTTP GETオペレーション、HTTP POSTオペレーション、SOAP）あります。Webサービスを早急に呼び出す必要があり直ぐにSOAPクライアントが使用可能ではない場合には、GETとPOSTのオペレーションは便利です。RESTを使うことにより、PerlスクリプトにてHTTPを介してGET、POST、PUT、そしてDELETEを実行できます。このスクリプトでは、SQLクエリーそして簡素なメッセージ・キューを指定できます。

SOAPクライアントが使用可能であれば、RESTとSOAPのどちらを使用するかの簡潔な選択法をここに示します。アプリケーションがリソース・ベース(resource-based)であれば、RESTを選択しましょう。アプリケーションがアクティビティー・ベース(activity-based)であれば、SOAPに決まりです。RESTでは、複数のオペレーションがHTTPを介してリソースのシリーズにて実行されることをクライアントは要求するかも知れません。SOAPベースの要求では、（クライアントが実行を要求する可能性のある）それぞれのアクティビティー指向のサービスに呼び出しオペレーションを1つだけ必要とします。

上に戻る

呼び出しフレームワーク（WSIF）

SOAP要求を構成するには、（Webサービスにどのようにしてアクセスしてそれがどのオペレーションを実行するかを記述する言語である）WSDL（Web Services Description Language）を必要とします。Webサービスのコードをカスタマイズせず、レガシー・アプリケーションを再コンパイルせずとも、サービスの種類を指定できます。

WSDLが多種にわたるソフトウェア・フレームワークと機能することを保証するには、異種類のソフトウェアの正規化された記述としてWSDLを使用することを可能にするIBMのWSIF（Web Services Invocation Framework）を活用する方法があります。それは、記述言語の周辺にあるAPIを介してプロトコルやロケーションと関係ない形でWSDLにアクセスできることを意味します。また、多種にわたる条件や例外のもとにあるプロトコルまたはロケーションの切り替えを可能にするWSDLを使用する複合アプリケーションとして、Webサービスを結合することが可能であることも意味します。

WSIFを構築するには、どのプロバイダーを使用するかに関係なく、最小要件を満たさなくてはなりません。オプションは下記の項目を含みます。

• JAXP XMLパーサー
• Java APIのWSDL
• Apache SOAP
• Apache Axis

上に戻る

RESTとSOAPの共存

SOAP要求と異なり、REST要求はWSDLに依存しませんが、RESTオペレーションを検証するにはXMLスキーマを必要とします。WSDLはスキーマ仕様をサポートしますので、RESTとSOAPは（複合Webサービス・アプリケーションから外部Webサービスへの）要求として共存できます。

例えば、SOA#1にあるアプリケーション（図3参照）はまずSOA#2にあるMRPのWebサービスからアクティビティー指向サービスを呼び出すためにSOAP要求を送信し、それから同一のMRPのWebサービスへリソース指向サービスのシリーズを操作するためのREST要求を送信します。すべてのSOAPベースの要求はIBM WSIFをベースにしています。

ご覧のとおり、SOA #1にあるアプリケーションはUnixまたはLinuxのサーバーにて実行され、SOA#2にあるMRPのWebサービスはIBM WebSphere Application Server（Application Server）にて実行されます。SOAPベースの要求においては、WSDLの正規化されたバージョンにあるロケーションとサービスの種類を変更するのにWSIFを使うことができます。

上に戻る

WebSphereと.Netの製品のインターオペラビリティー

より巨大な企業システムにあるLinuxまたはWindowsのプラットフォームでの開発プロジェクト用に更に複雑なWebサービスを作成するのであれば、IBM Rational® Application Developer for Websphere Softwareを考慮してみてください。それはUML（Universal Modeling Language）Visual Editor for Java™ and EJBと一緒に手に入れられ、Eclipseのオープン・ソース・プラットフォームにて実行できますので、開発環境の拡張を可能にします。Microsoft Visual Studio.Netを使用することもできます。

複数のビジネス・プロセスにあるモジュラーのWebサービス・コンポーネントとしてアプリケーション・ロジックを区切るのに、どちらのソフトウェアを使用するのも大丈夫です。Webサービス・トランザクションと視覚的に相互作用することを可能にするWeb Services Navigator（Rational Application Developerのプラグイン）を提供することにより、IBMはその上のレベルを目指します。

もしもMicrosoft .NetのプラットフォームにてWebサービス作成のためにVisual Studio.Netを使用しているのであれば、Application ServerにてそのWebサービスを実行できます。それは、2つのプラットフォーム（参考文献を参照）の間にてWebサービス・インターオペラビリティーの契約を結べることを意味しますので、あとは両方のプラットフォームに共通するWSDLを作成するのみです。

例えば、UnixまたはLinuxのサーバーにて実行されるアプリケーションはまずSOAP要求を送信し、Application Serverにて実行されるMRPのWebサービスからアクティビティー指向サービスを呼び出します（図4を参照）。それからアプリケーションはリソース指向サービスのシリーズを操作するためにREST要求を同一のMRPのWebサービスに送信します。要求を受信すれば、SOA#3にあるCRMのWebサービスは元々のアプリケーションに向けて要求または情報を送信します。

図のとおり、SOA#3にあるCRMのWebサービスは.Netプラットフォームで実行されApplication Serverにアクセスします。CRMのWebサービスはSOA#1にあるアプリケーションに要求または情報を送信します。Visual Studio.NETにVisual Perlプラグインを追加できます。スクリプトの複雑性によっては、RESTベースのPerlスクリプトのUnix-to-Windows（UnixからWindows）のマイグレーションのコマンド・レベルPerlを使い、Visual Perlの環境に順応させることもできます。

上に戻る

Visual Studio

Visual Studio .Netを使えば、COMコンポーネントとしてUnixアプリケーションをカプセル化するためにKornshell、Visual Basic、C++、またはJavaを使用するよりも事は簡単です。WindowsアプリケーションがUnixのシェル・スクリプトに対して機能するようにアプリケーションを作成したり、WindowsプラットフォームにUnixアプリケーションをマイグレーションして外部Webサービスと接続するようにするよりも、Visual Studio .Netを使って作業する方が簡単です。

ここでいくつかヒントを与えましょう。まず、パブリック・ロケーション（public location）にて独自のWSDLを公開してインターオペラビリティーの相違点を解決すべきです。Rational Application Developerの「ボトムアップ」のアプローチ(Bottom Up approach)または、Visual Studio .Netの「WSDL第一(WSDL First approach)」のアプローチにて、自動生成されたWSDLファイルをスキップできます。Rational Application Developerのスケルトン(Skeleton)または「トップダウン」のアプローチ(Top Down approach)を使ってWSDLファイルから始めてJava Class実装を満たすことも可能です。別の方法として、Visual Studioの「WSDL第一」のアプローチでのWSDLファイルの自動生成を使用不可（disable）にして独自のWSDLを公開することもできます。

次に、作業できるWSDLテンプレートを自らに供給するのでしたら、Rational Application Developerの（Java Beanからの）ボトムアップのアプローチ、（クラス・モデルをベースにしたテンプレート・コードを生成するための）Rational XDE、または（Webサービスのためにコードを書き出すことにより開始した後にテンプレート・コードを生成するための）Visual StudioのImplementation First Approach（実装からのアプローチ）を考慮しましょう。Rational Application DeveloperはWSDLエディターを提供しますが、Visual Studio.Netはそうしないかも知れません。

上に戻る

SOAの数は？

EAIアプリケーションとリンクするのに使えるSOAの数は、プロジェクトの複雑性、インターオペラビリティーの問題、ビジネス・プロセス、そしてローディングのパフォーマンスに関する問題の間で行なわれる兼ね合いに依存します。SOAPオーバーヘッドを回避するように、開発のライフ・サイクルを通してSOAオーバーロードが発生しないことを保証しなくてはなりません。サイクルのそれぞれの時点にてオーバーロードの有無をテストすべきです。

上に戻る

まとめ

マルチプラットフォームSOAの間にある外部Webサービス・インターオペラビリティーの最大化においては、どれだけの数のSOAが作成可能かの制限を設定するなど先回りをして計画することが必要です。ビジネス・アナリストとIT専門家のグループと連絡を取り、多種にわたるパフォーマンスの問題や議論を交わすべきです。インターオペラビリティーの問題の解決が、アプリケーション作成の作業をかなり楽にしてくれることに気付かれることでしょう。それぞれが異なるプラットフォームそして要求されたプロトコルを使用できる外部Webサービスを作成できます。問題の解決がマルチプラットフォームSOAのシステムを設計そして分析するという作業をさらに簡単にしてくれることに、アナリストは気付くでしょう。どのプラットフォームで SOAオーバーロードを背負い込まずに Webサービスが実行可能かを判断することもできます。

参考文献

• 下記のシリーズの記事から、企業単位のSOAにてWebサービスを使用する方法に関する情報を入手しましょう。
  • 「企業単位のSOAにてWebサービスを扱う 第1回: 複数のSOAで企業システムのギャップを埋める」(developerWorks, February 2005)。
  • 「Consolidate your SOAs as a three-dimensional integration hub to improve speed and reliability」(developerWorks, March 2005)。
  
  
  
  
• Rational Application Developerのボトムアップとトップダウン のアプローチについてより多くを学びましょう（developerWorks、2005年01月）。
  
  
• IBM Rational Application Developer をダウンロードして、試してみましょう。そのついでに、CDを注文する事もできます。
  
  
• IBM Web Services Navigatorについてより多くを学習しましょう。
  
  
• Amazon web servicesにて、どのようにして簡素なWebサービスのRESTを使えるかについてより多くを学びましょう。
  
  
• IBMのWSIFとは何でしょうか？ApacheのWebサイト にてその解答を得られます。
  
  
• 「リソース指向Webサービスとアクティビティー指向Webサービスを比較する」　James M. Snell氏の記事をお読みください。
  
  
• 下記のシリーズの記事から、WebサービスのコンテキストでSLAを使用する方法に関する情報を入手しましょう。
  • 「SLAによるWebサービスの保証」（developerWorks 、2002年04月）
  • 「SLAで第二世代Webサービス・アプリケーションを保証」（developerWorks 、2004年08月）
  • 「SLAの保証付きでWebサービスをEAIに統合」（developerWorks 、2004年10月）
  • 「SLAの保証付きで複数のWebサービスを保護」 （developerWorks 、2004年11月）
  • 「SLAの保証付きでWebサービスにファイアウォールを設置」（developerWorks 、2004年12月）
  • 「SLAの保証付きでWebサービスをローカライズする」 （developerWorks 、2005年01月）
  • 「SLAの保証付きで脆弱点のリスクを緩和」（developerWorks 、2005年01月）
  
  
  
  
• システム・デザインの本質的な原理と優先権に焦点を合わせe-commerceと分散統合システムの登場により推進される新たな要件を強調する、Judith M. Myerson著の「The Complete Book of Middleware」をお読みください。
  
  
• 知識欲の袋に底はないのでしょうか？SOA and web services のページは、数百にもわたる情報豊かな記事と、Webサービス・アプリケーションの開発方法についての（初級、中級、そして上級の）チュートリアルを提供します。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 企業のレガシー・アプリケーション
• Webサービスへのダイナミック・リンク
• ソフトウェア・フレームワーク
• 呼び出しフレームワーク（WSIF）
• RESTとSOAPの共存
• WebSphereと.Netの製品のインターオペラビリティー
• Visual Studio
• SOAの数は？
• まとめ
• 参考文献
• 著者について
• コメント