BT

インタビュー:MDDとSOAの関わりについてIBMアーキテクトBertrand Portierに聞く

| 作者 Jean-Jacques Dubray フォローする 3 人のフォロワー , 翻訳者 松本 清一 フォローする 0 人のフォロワー 投稿日 2008年4月5日. 推定読書時間: 10 分 |

IBMから最新の製品発表(source)が行われた後、InfoQでは、IBMソフトウェアグループのアーキテクトであり、レッドブック「Building Business Solutions using the Rational SDP」(source)の著者の一人でもあるBertrand Portier氏と話をしました。この本では、サービス構造のためのモデル駆動開発を説明しています。それは、ライフサイクル、参照アーキテクチャ、シナリオを含んだIBMのSOAファウンデーションをベースにしています。しかし、そのコンセプトは他の製品にも十分適用可能です。

その本は、モデリングの概念と開発プロセスの説明の手助けとして、架空のケーススタディ(JKエンタープライズ)をもとに書かれています。

ガバナンスとIBMのSOA参照アーキテクチャに関する簡単な説明の後、RUPに基づいた開発プロセスを定めながら主題へと進みます。レッドブックでは、Eclipse プラットフォーム上にオープンソースを持つIBM Rational Method Composerを利用しています。そのオープンソースとは、EPF (Eclipse Process Framework)(サイト・英語)です。EPFは、OpenUPと呼ばれるRUPを簡易化したものです。

さらに、IBMのSOMA (Service Oriented Modeling and Architecture)(source) によるモデル駆動開発アプローチを利用する前に、モデリングの重要性について説明しています。その後に続く章では、先に定義した開発プロセス(識別化、仕様化、実現、実装、テスト)に、このMDDアプローチを利用しています。つまり、ビジネスモデリング、要求モデリング、トレーサビリティ、サービスモデル、サービスデザインモデルについて説明しています。

InfoQ: Rational Software Delivery Platformはどういうものですか?

Bertrand: これは、アーキテクチャ管理、変更・リリース管理、プロセス・ポートフォリオ管理、品質管理といった、4つの分野におけるツールをハイレベルに統合した製品の最新バージョン(サイト・英語)となります。もちろん、RUPをベースとしています。

InfoQ: SOMAとは何ですか??

Bertrand: SOMAは、サービスの識別化、仕様化、実現をサポートする手法です。それは、ビジネスニーズと既存の資産の分析から始まります。SOMAは、IBM Global Servicesがそれを利用するために開発されました。SOMA用のRUPはプラグインとして、DeveloperWorksで利用可能です(サイト・英語)。これは第3世代のプラグインであり、SOA用の以前のRUPを統合するものです。さらには、IBM Global Business Services (GBS)のサービス指向モデリングやアーキテクチャ(SOMA)(PDF・英語)メソッドの内容も統合しています。

私たちは、モデル駆動開発(MDD)とSOMAを結びつけるためにレッドブックを書きました。私たちのゴールは、生産性を向上し適切なタスクを自動化することにあります。自動化の点をより進めると、MDDによりトランスフォーメーション、バリデーション、トレーサビリティ、変更といったものが分析に影響を与えるようになります。

それは、SOAソリューションを提供するためのMDDアプローチを利用する価値が大いにあるということです。想像してください。例えば、5つの機能を持つ SOAソリューションそれぞれに対するあなたのSOAソリューションモデルがレイヤーを積み重ねていると。そして、それぞれのレイヤーに対する低レベルな抽象モデルから高レベルなものまで変換可能になっています。SOAプロファイル、モデル、トランスフォーメーションが作られ、プロジェクトの中でうまく利用されているのです。それらには、例えば、ソフトウェアサービスのためにUnified Modeling Language (UML)プロファイルや、Webサービス定義言語(WSDL)の変換のためのUMLといったものを含んでいます。継続的に改善されているSOAの内容、様々なステークホルダーがいるという側面を持つSOAにMDDを利用するメリットは、品質や生産性の向上、決定のトレーサビリティにより全てのビジネス要求の方向性が決まることです。

こういったアプローチは、動的なビジネス環境において必要不可欠なものです。要求はしばしば変わるので、「飛行中の(プロジェクトが進行中の)」強化プロジェクトへの影響を理解するということは、重要なタスクとなっています。逆に言えば、もしアーキテクトが計画を変更する必要があるならば、私たちも影響を受ける要求という観点で即座に情報を収集する必要があるということです。

InfoQ: Service Creation Scenario(source)とはどのような関連があるのでしょうか?

Bertrand: そのリンクは、SOA参照アーキテクチャレベル(通称、SOAソリューションスタック)に関するものです。他のレッドブックでは、異なるシナリオのための構成要素とそれらがどのように結合されるべきなのかについてフォーカスしています。一方、私たちのレッドブックでは、ツールやメタモデルをベースとしたエンド・ツー・エンドの手法にフォーカスしています。そのメソドロジーはコンポーネントビジネスモデルから始まり、ビジネスプロセスモデル、サービスモデルに由来する要求や分析、そして最終的には、設計や実装モデルに至ります。そのシナリオでは、入り口としてどのようにしてサービス指向アーキテクチャを始めるか、完成度のレベルを上げるためにどのようなステップを踏むのかについて説明しています。

私たちには、このアプローチをサポートするその他の新しい製品があります。例えば、RAMであり、それは資産管理を再利用可能にするものです(サイト・英語)。それは、ソフトウェア開発資産のライフサイクルの管理を支援する開発時の資産リポジトリです。資産とは、ドキュメント、UMLモデル、コンポーネント、javaコード・・・などです。これらの資産は、パッケージ化されリポジトリに格納されます。そして、それらを後から受け入れ、プロセスの一部で再利用可能な資産として承認されます。将来のプロジェクトで開発ソリューションとして利用するために、今のあなたの開発組織が利用できるようになるのです。

InfoQ: サービスオリエンテーションにおけるアセンブリとサービスコンポーネントの概念は、どのくらい重要なものですか?

Bertrand: アセンブリは重要ですが、リアセンブリはさらに重要です。サービス指向アプローチにおけるキーとなるメリットの1つは、ソフトウェア開発アーティファクトが再利用可能であることです。レッドブックの中で、私たちはアセンブリをデプロイ可能なサービスコンポーネント実装の集まりとして定義しています。私たちは、適切なサービスやサービスコンポーネントの識別、仕様、実現、実装を可能とするソフトウェア開発プロセスに従います。アセンブリは、ソリューションのためのサービスコンポーネント実装(内部やアウトソースで開発したもの、若しくは、外部プロバイダーから得たもの)のインスタンスを組み立てることにあります。アセンブリのデプロイを確かなものとするその開発プロセスは、ビジネス要求を追跡可能、かつ、他のものによって再利用可能なものとします。

IBM は、サービスコンポーネントアーキテクチャ(SCA)やサービスデータオブジェクト(SDO)を含む、SOAプログラミングモデルの標準化と決定に積極的に参加しています。より具体的には、SCAはあなたが選択した言語(例えば、JavaやPHP)でのサービスコンポーネントにおける実装のためのモデルを定義しています。そして、そのコンポーネントのアセンブリがソリューションとなります。さらに詳しいことを知りたければ、Open SOAコラボレーションサイト(www.osoa.org)(英語)を参照してください。

InfoQ: Contract-LastとContract-Firstについて、あなたの考えを教えて頂けないでしょうか?

Bertrand: 例えば、コンポーネントビジネスやビジネスプロセスモデルから始めているトップダウンアプローチから、若しくは、レガシー資産の詳細な分析に基づいたボトムアップアプローチから、その両方によりサービスを特定することができます。サービスを設計・実装するときには、「meet-in-the-middle(MIM)」のアプローチを採用するよう推奨しています。SOAにおける成功要因の鍵となるものの1つは、既存の資産を再利用して、サービス指向アーキテクチャでそれらを統合できるということです。しかし、これはビジネスと一体となって行われる必要があります。これがMIM分析があなたに与えるものなのです。この分析の目的は、システムのインターフェースをビジネスプロセスレベルに合わせることです。トップダウンの視点は、ボトムアップの視点で詳細に調べられるであろう資産を特定するための手助けとなります。実際、私たちは「レガシーからSOAへ」(source)というトピックで書かれたレッドブック (source)もあります。

組織は、伝統的なSOAの慣例に倣いレジストリやリポジトリ(R&R)を採用し始めていますが、十分なものではありません。ここで、Rational Asset Managerが重要な役割を果たします。つまりそれは、SOAにおけるR&R、モデル、設計、コードを結びつけるものです。 

このアプローチは、レッドブックの中で多くのステップに分けて記載されているので、疑問に思うところは無いでしょう。私たちが方法論における全てのステップを特定したので、パターンを利用してそれらの多くを自動化するための基盤ができました。例えば、ユースケースモデルからサービスモデルへの変換をしました。これを私たちは「パターンベースエンジニアリング」と呼んでいます。私たちは12ヶ月にわたり、私たちのツールを利用してこのアプローチを実践してきました。そして、これは私たちのランタイムエンジン(作業を行う動力)を十分に補うものとなっています。

InfoQ: その本では、12のSOAパターンを記載しています。最初のものはプロセスロジックがコンポジションロジックから分解されるべきであるということを主張しています。このパターンは、どれくらい一般的ですか?

Bertrand: 実行可能な資産へとビジネスプロセスを変化させることは、BPELによって最適化されます。もししっかりとした変更を行うのであれば、再利用可能なものが必ず必要というわけではありません。プロセスのいくつかが再利用可能なものであると思うのならば、サブプロセスに基づいたデコンポジションを行う必要があります。これは、ビジネスエンティティのライフサイクルを表しているステートマシーンが出現するところです。一般的に、ビジネスプロセスはシーケンスベース (で順序を持つもの)ですが、ビジネスエンティティのライフサイクルはその殆どが並列ベース(で順序を持たないもの)です。もし、ビジネスエンティティの状態をコントロールするビジネスプロセス全てにおいて一貫したライフサイクルを確保したいのであれば、この2つの要素によってソリューションを分解することができるということは、非常に重要なことです。

InfoQ: 赤本を書かれた経験によって得られた知識を共通して頂けないでしょうか?IBMに関わっていない人に公開して頂けないのでしょうか?

Bertrand: そのプログラムは、レジデンシー(サイト・英語)のコンセプトに基づいています。レジデンシーは、IBM技術者に加え、ビジネスパートナー、顧客、その市場での専門家のために公開されているものです。全ての著者(即ち、レジデンスたち)は、6週間の間一緒に作業します。4週間は現場で、残りの2週間は離れて作業します。その共同作業は非常に実りあるもので、私にとっては一番楽しい活動です。レッドブックの著者らは、互いに自身の経験やベストプラクティスを共有します。さらに、皆が違った視点を持っているのです。皆さんもそれに同意して、一緒に作業すべきだと思います。

InfoQ: 貴重なお時間を割いて頂き、ありがとうございました。 

原文はこちらです:http://www.infoq.com/articles/bertrand-portier-on-mdd-soma
このArticleは2007年10月29日に原文が掲載されました)

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT