SOAプログラミング・モデルのシリーズ

現在、ソフトウェアに関する技術や習慣、ツール、プラットフォームなどは、警告を発したくなるほど広範になりつつあり、個々のプログラマーがそれらを効果的に習得し応用することが次第に困難になっています。ましてやプログラマーでない人にとっては、習得や応用は一層困難です。しかしビジネス・プロセスの変換が成功するためには、かなりの数の非プログラマーが、既存のIT資産を使って仕事を遂行する必要があります。そのため、その基礎となっている技術の、ごく詳細部分まで彼らに理解するように求めることはできなくなっています。このシリーズでは、コンサーン（concern）の分離を実現する、新しいSOA（Service-Oriented Architecture）プログラミング・モデルについて説明します。SOAによって、企業内の人達、つまりIT専門家に限らず、様々なスキル・レベルや役割を持った人達が、ソフトウェアの開発ライフサイクルのあらゆる段階においてIT資産を作成し、使用できるようになります。その結果、オンデマンド企業におけるビジネスの敏捷性を、劇的に高めることができるのです。

上に戻る

はじめに

IBM製品は、次第にSOAやSOAプログラミング・モデルを実装するようになっています。プログラマーは、サービスを構築し、使用し、そしてサービスを集約するソリューションを開発します。ここでは、「プログラマー」という言葉の意味を曖昧にしています。SOAプログラミング・モデルで鍵となっているのは、「プログラミング」の概念が拡張されていることであり、そこにはビジネス・アナリストやスクリプト言語のユーザーなど、より広い意味の、伝統的開発者とは異なる開発者の持つ役割やスキルまで含まれるようになっているためです。

Webサービスに関する資料は、サービス・インターフェースや、その使い方に焦点を当てたものがほとんどです。IBMでは、インターフェース標準とベスト・プラクティスとを補完するために、サービスを実装し、ソリューションの中に組み込むためのプログラミング・モデルを導入しています。このモデルは、IBMのソフトウェア・プラットフォームが対象とする範囲を、（非伝統的なプログラマーを含めて）より広いユーザー・コミュニティーにまで広げるために、ユーザーの役割やゴール、スキル、概念的なフレームワークなどに一致させるための『コンポーネント・タイプ』を提供しています。こうしたコンポーネント・タイプによって、より直感的な開発ツールが可能となります。プログラミング・モデルのもう一つの大きなテーマとして、このモデルの機能や能力を順次開示することによって、利用しやすさを高める、ということがあります。

この記事は、特にソフトウェア開発の専門家を対象とした、IBMによるSOAプログラミング・モデルに関するシリーズの第1回です。このシリーズでは、上記のゴールを実現するための新しいプログラミング・モデル要素を幾つか示します。そして、それらを利用することによって、皆さんが選択し、開発し、デプロイし、推薦し、そして管理するソフトウェアの開発や再利用、そして使用が容易になることを説明します。サービスとして構成されたソフトウェアは、オンデマンド企業にとって特に貴重です。なぜなら、そうしたソフトウェアは、それほどスキルのない開発者によるソリューションの中に「つなぎ込まれる」かも知れず、あるいは、急速に変化するビジネス要求に応えるためにビジネス・プロセスのコレオグラフィー・フロー（choreography flow）の中に取り込まれるかも知れないからです。皆さんが大企業の開発者であれ小企業の開発者であれ、ISV（independent software vendor）であれアプリケーション・プロバイダーであれ、あるいはミドルウェアのベンダーであれ、このようにソフトウェアを構成することによって、非常に大きな恩恵が得られるのです。では早速、SOAの原則の応用を始めることにしましょう。

上に戻る

SOAプログラミング・モデルのハイライト

まず、SOAプログラミング・モデルの主な特徴をハイライトすることから始めましょう。

SDO（Service Data Object）は、IBM SOAの基本概念です。SDOによって、開発者はより生産的になり、特定なバックエンド・データ・ソースやアプリケーション、サービスなどにアクセスするための技術的な詳細を気にせずに済むようになります。またSDOによって単純な抽象化が可能になり、プログラマーは、主にビジネス・ロジックのみに集中すればよくなります。さらにSDOでは、サービスと対話動作するメッセージを統一的に表現することができるため、データを表現するための迷宮のような技術を回避でき、単一の、統一的なモデルを使ってメッセージにアクセスできるようになります。

SOAプログラミング・モデルでは、ビジネス・ロジックを作成し、そこにアクセスするための、統一された仕組みも必要です。サービスが使いやすいものであるためには、実装技術の違いが見えないようになっている必要があり、EJB（Enterprise Java™Beans）のような既存のプログラミング構成体よりも高いレベルで抽象化されている必要があります。サービスはコンポーネントによって実装されると考えてください。コンポーネントは組み合わされてモジュールとなり、そのモジュールが今度はソリューションになるかも知れません。コンポーネントは、呼び出されるサービスを、アドレス可能インターフェースを使って公開します。インターフェースは、WSDL（Web Services Description Language）やJava、その他の言語を使って記述することができます。この実装スタイルは、必要なサービスに対する未解決参照を持つことができます（この参照は、コンポーネントをつなぎ合わせることによって、実行の前に満足されます）。

このプログラミング・モデルでは、開発者が作成しソリューションの中にデプロイするような一般的種類の成果物をモデル化した、よく定義されたコンポーネント・タイプも導入されています。こうした例としては、「Plain old Java object: 昔ながらの単純Javaオブジェクト」やBPEL（Business Process Execution Language）プロセス、SQL（structured Query Language）サービス、Adaptive Business Object、 J2C（Java Connector Architecture）リソース・アダプターを通してアクセスされるCICS®プログラム、SAPのビジネスAPIを使ったアプリケーション、J2EE（Java 2 Enterprise Edition）ステートレス・セッションbean、そしてMQSeries®アプリケーションなどがあります。

ESB（Enterprise Service Bus）はマルチ・プロトコルの骨組みとして、様々なサービス・コンポーネントを織り合わせて継ぎ目のない対話動作にする上で、鍵となる役割を担います。しかもESBによって、企業の持つコンサーン、つまり監査やロギング、ルーティング、ミスマッチ・インターフェースに対する調整、等価なコンポーネントへの順次置き換え、セキュリティー、等々に対して、バックボーン・レベルで、企業全体に渡って対応することができます。既存のエンドポイントを変更することなく、『調停（mediation）』と呼ばれる特別なコンポーネントをサービス間のブローカー対話動作へのメッセージ・パスに挿入することによって、それを実現するのです。

また、新しいプロセス言語によって、ITの概念とビジネス成果物との隙間を縮めることができます。その鍵となるのが『BPEL』です。プロセスは、ビジネス・アナリストが理解できるようなグラフィカル・ツールを使って定義することもできますが、プロセスは実行可能プログラムでもあります。プロセスは、オンデマンド・ビジネスへの変換において重要な役割を果たすようになっています。例えば拡張バリュー・チェーンに対して、長期間実行する実行可能プロセスを記述する、などの場合です。ここで言う拡張バリュー・チェーンは、複数のサプライヤーやITドメイン（つまり小売業者と、それに関わる数多くの個別サプライヤーや保険会社、無数のサードパーティー調整機構、ITアウトソーシングの状況など）にまたがる、ビジネス上の取り決めを指しています。

『ビジネス状態マシン（business state machine）』も、ビジネス・アナリストがグラフィカル・ツールを使って作成でき、しかもプロセス・コレオグラフィー・エンジンを実行するための、プログラム的な表現方法です。状態マシンは、ビジネス成果物（注文書や保険の請求書など）を表現しており、また特定なライフサイクル『イベント』に応答して、よく定義された幾つかの状態の間を遷移します。

再利用の対象となるコンポーネントは、ソリューションの中に置く際に調整される変更可能ポイント（points of variability）と共に、テンプレートとしてパッケージすることができます。こうした種類の調整は、『ルール言語（rules language）』や関連ツールを追加することによって私達のプログラミング・モデルでのファーストクラス部分となるため、新しい種類のユーザーに対してカスタム化機能を提供することができます。

もう一つ、革新的な部分は、新しい『ソリューション・モデル』です。これによって、デプロイを行う人や管理者、その他のビジネス・ユーザーは、コンポーネントを組み合わせてソリューションを作り上げることができます。開発時には、サービス実装をホストするトポロジー（システム・アーキテクトがモデル化するデプロイメント・トポロジー）と、サービス実装とを関連付けることができます。モデルが捉えたシステム要求や、環境に関する想定は、初期の段階で実装に対して検証されるため、アプリケーションのライフサクル・コストは削減される一方、信頼性と責任能力は大幅に改善されます。遅延バインディングや、データ変換のための調停、既存アプリケーション用のアダプターなどは、このモデルの特徴であり、これらによってESBを介したサービス指向の対話動作が可能となります。

要約すると、SOAプログラミング・モデルは、開発のアクティビティーとデプロイメントのアクテクビティーとを、別々のフェーズ（別々の時間に発生し、別々な人が別々なスキルを使って行います）に分離するのです。これによって、真の意味でのコンサーン分離ができ、その結果、ソフトウェア・コンポーネントの再利用が可能になります。また、このモデルによって、個々のユーザーのビジネス上の役割やスキル、課題などに合わせて、ソフトウェアの使い方を調製することができます。最後に、オンデマンド企業がビジネスの敏捷性を高めるためにITプロセスの再エンジニアリングを行い、また利益の増大を図ろうとする中で、このモデルは、ソフトウェア・ライフサイクルと彼らの必要とするものを一致させるために非常に有効なのです。

上に戻る

プログラミング・モデルの概念

『プログラミング・モデル』は、IBMのSOAとIBM製品全般の中心となるものです。プログラミング・モデルは、開発者が構築し使用する、概念や抽象化を定義しています。WebSphere® Application ServerやDB2®、CICSなどのランタイム製品は、プログラミング・モデル成果物を実行、あるいはホストします。開発ツールは、プログラミング・モデル成果物のモデル化や実装、アプリケーション（ソリューション）への組み込み、そしてランタイムへのデプロイをサポートしています。最後にシステム管理用の製品やエージェント、実装などは、それらがホストするランタイムやプログラミング・モデル成果物の管理を行います。

では、プログラミング・モデルとは何でしょう。一般的に受け入れられている定義は無いようですが、私達は次のように定義しています。

• プログラマーが構築する、一連の『パート・タイプ（part type）』。パート・タイプには、様々な種類のプログラミング・モデル成果物があります。例えばHTML（Hypertext Markup Language）ファイルや、データベースに保存されたプロシージャー、Javaクラス、XML（Extensible Markup Language）スキーマ定義、MQSeries メッセージを定義するC構成体などです。
• 同じようなスキルや知識を持つ、開発や管理のコミュニティー・メンバーをグループ分けするための、一連の『ロール（role）』。このように開発者をグループ分けすることによって、ロールに適したツールを作りやすくなります。また、こうしたツールを使うことによって、プログラマーではない人がサービスを実装し、サービスからソリューションを組み立てることができるようになります。ビジネス・プロセスを定義するビジネス・アナリストや、顧客を分類し製品値引きを計算するためのポリシーを定義するマーケティング専門家などは、皆さんの対象となるべき新しい種類の開発者を表しています。こうしたロールに含まれるものとしては、次のようなものがあります。
  • ロールの持つ『スキル』。例えばユーザー・インターフェースの開発者は、アプリケーションやソリューションの機能成果物を表現するためのインターフェースを開発します。このロールであれば、開発中のアプリケーションとそのビジネス・ゴールを知っている必要があり、アプリケーションのユーザーと彼らの課題を充分に理解している必要があり、しかも様々なユーザー・インターフェース設計法のエキスパートである必要があり、それぞれの課題に適切なユーザー・インターフェースを選択して使いやすいユーザー・インターフェースを作成できる、ということが必要です。
  • ロールとの対話動作（使用、生成）の相手となる『パート・タイプとアプリケーション・インターフェース』。例えば、動的ページの設計者、というロールであれば、JSP（JavaServer Pages）を生成し、既存の情報ソースやアプリケーションをラップするEJB、というパート・タイプを使用します。
  • ロールが使用する『ツール』。Web開発者が使うための、ロールに合ったツールの例としては、動的ページを構成するためのWYSIWYG（what-you-see-is-what-you-get）型のページ設計ツールがあります。（こうしたツールでは、HTMLやJSPタグ・ライブラリーに関連したコントロールを使い、そのコントロールをEJBにつなぎ込みます。）

Webサービスの実装、使用を容易にするための鍵は、その人が既に持っているスキルや知識を徐々に拡張することです。そうすれば、SOAが使いやすいものになります。CICS COBOLトランザクション・プログラムという形式でのサービスは、BPELで書かれたトランザクション・プログラムとは大きく異なります。データベースに保存されたプロシージャーからサービスを呼ぶことと、JSPからサービスを呼ぶこととは異なり、当然スキルや、そこで行われることも異なります。利用のしやすさを実現するためには、様々なスキルや開発プロセスの各段階にパート・タイプを適応させるための、様々なツールを提供する必要があります。

このシリーズの今後の記事では、このSOAプログラミング・モデルを構成するパート・タイプの幾つかを、より詳しく調べて行きます。

上に戻る

製品アーキテクチャー

SOAに関するIBMの考え方を実現する製品群は、大きく分けて2つのカテゴリー、つまりサービス・エンドポイントと、それらを相互に連結するメッセージ・トランスポート機構に分類されます。この一般的なアーキテクチャーは、多くの製品（図1）から成りますが、それらはどれも、単体ではIBMのSOAを実現することはできません。

このアーキテクチャーの中核には、サービス間の接続性を実現するESBがあります。ESBはマルチ・プロトコルであり、ポイント・ツー・ポイント・スタイルや公開/購読スタイルのコミュニケーションを処理し、また飛び交うメッセージを処理するための調停サービスをサポートしています。IBM WebSphere MQやIBM WebSphere MQ Integrator Broker、Webサービス用WebSphereサポート、JMS（Java Message Services）などは、すべて最初のカテゴリーに属してます。

サービスは、コンテナーとして知られる抽象的なホスト環境の中にあり、ある特定な、プログラミング的な概念を表します。コンテナーはサービスの実装コードをロードし、ESBへの接続を行い、サービス・インスタンスを管理します。様々なコンテナーの中に、様々なタイプのサービスが存在しています。（最も顕著な設計反復の例では、ESB自体を、調停サービスに対するコンテナーと考えることができます。）表1は、IBM SOAホスト環境の主なものの幾つかと、ホストされるコンポーネントの種類をリストアップしたものです。

上に戻る

まとめ

IBM SOAプログラミング・モデルに関するシリーズ第1回目の今回は、このモデルとIBMのツールや製品との関係の概要、それらをアプリケーション開発の中で効果的に利用するための方法について説明しました。

今後の記事では、次のような話題に関して取り上げる予定です。

• SDOを使った、簡略データ・アクセス
• サービスの定義と、新たなコンポーネント・モデルの導入
• 開発を単純化するためのコンポーネント・タイプ
• 基本的なコンポーネント・タイプ
• サービスの組み立てとカスタム化
• プロセス・コンポーネント: BPELとビジネス状態マシン
• サービスのカスタム化: 設計パターン、テンプレート、変更可能ポイントなど
• サービス指向のユーザー・インターフェース
• SOA的な管理手法
• SOAソフトウェア・ライフサイクル用の開発ツール
• SOAでのセキュリティー

参考文献

• Java Message Serviceの仕様をよく調べてみてください。
  
  
• J2EE Connectorアーキテクチャーは、多くのアプリケーション・サーバーと今日の企業におけるITシステムとの間で発生する接続性問題に対する、Java技術によるソリューションです。
  
  
• IBM developerWorksのチュートリアル、Introduction to the J2EE Connector Architectureは、J2EEコネクター・アーキテクチャーの概要を知るための格好の資料です。
  
  
• このサイトには、この記事で取り上げた話題や、その他の技術的話題に関する本が豊富に取り揃えられています。
  
  
• developerWorks ブログに参加して、developerWorksのコミュニティーに加わってください。
  
  
• developerWorks の SOA and web services ゾーンでは、豊富な記事と、初心者から中級者、そして上級者まで幅広い方々に役立つ、Webサービス・アプリケーションの開発に関するチュートリアルを提供しています。
  
  

著者について

Donald F. Ferguson博士は、20万人にものぼる技術専門家から成るIBMのエンジニアリング・コミュニティーの中で技術的に最高の地位である、IBM Fellowsを持つ55人の一人であり、IBM Software Group製品ファミリー（Lotus, Rational, WebSphere, DB2, and Tivoliなどが含まれています）のChief Architect and Technical Leadです。SWG Architecture Boardの議長として、SWGに関する指導的な製品アーキテクトを取りまとめています。最近焦点を当ててきた業務には、Webサービスやビジネス・プロセス管理、クライアント・プラットフォーム、アウトソーシング/ホスティング・プラットフォーム、グリッド・サービス、WebSphere用のアプリケーション開発などがあります。WebSphere製品ファミリーが開始された時から2003年に彼がSWGのChief Architectとなるまで、Chief Architectを務めていました。

Marcia L. Stocktonは、ノースキャロライナ州Research Triangle ParkにあるIBM Software GroupのSenior Technical Staff Memberであり、Master Inventorでもあり、またIEEEのシニア・メンバーでもあります。Software Group Architecture BoardのProgramming Model Workgroupのリーダーとして水平統合の活動を推進しており、LotusやRational、WebSphere、DB2、Tivoliなどの製品群全体に渡るプログラミング・モデルの単純化を図ろうとしています。彼女が合衆国に申請したの73件の特許は、ネットワーキングやWeb、セキュリティー、プライバシー、マルチメディア、ワイヤレス、パーベイシブ・デバイス、無線周波数IDなど、広範に渡っています。最近は、ID管理やエッジ・サーバー分散プログラミング用アーキテクチャーを定義するための活動の中心として活躍してきました。彼女はネットワーキング・ソフトウェアの開発に5年間の経験を経た後、1988年にIBMに加わりました。1975年に、Swarthmore Collegeにて学位を取得しています。

この記事を評価する

コメント

上に戻る

目次

• SOAプログラミング・モデルのシリーズ
• はじめに
• SOAプログラミング・モデルのハイライト
• プログラミング・モデルの概念
• 製品アーキテクチャー
• まとめ
• 参考文献
• 著者について
• コメント