@IT|@IT自分戦略研究所|QA@IT|イベントカレンダー+ログ | ||
Loading
|
@IT > RSDCスペシャル・レポート |
企画:アットマーク・アイティ
営業企画局 制作:アットマーク・アイティ 編集局 掲載内容有効期限:2004年12月31日 |
|
|
IBM RATIONAL SOFTWARE DEVELOPMENT CONFERENCE 2004 スペシャル・レポート 2人のIBMエバンジェリストと最新の技術動向 「IBM RATIONAL SOFTWARE DEVELOPMENT CONFERENCE 2004」(RSDC)が10月7日、8日の2日間にわたって開催された。本稿は、IBMソフトウェアの技術動向およびソフトウェア開発を巡る最新議論が展開された同カンファレンスの中から2つのセッションを厳選し、その内容をまとめたものである。
日本IBM シニア・テクノロジー・エバンジェリストの米持幸寿氏は、「SOA」を支えるアーキテクチャと既存のビジネス・プロセス関連製品、SOAの基盤として注目されるESB(Enterprise Service Bus)について解説した。 ◆ SOA=Webサービスではない
SOA(Service-Oriented Architecture:サービス指向アーキテクチャ)が注目されている理由は、ビジネス環境の変化に柔軟に対応できるITシステムが構築可能になるためだ。米持氏は「従来のITはモノシリックな1枚岩で構築されてもその役割を果たせました。しかし、経済環境の変化が激しい現代にあっては、企業のビジネスも、それを支えるITも柔軟に変化する必要があります。例えば、企業の合併によってITの統合に3年も時間をかけてはいられません。旧来の統合技術には限界があり、ビジネスや社内のプロセスの変化に早く追従できる技術が必要です」とSOAの必要性を語った。 従来の統合技術の限界とSOAのメリットについて米持氏は「CORBA(Common Object Request Broker Architecture)やEJB(Enterprise JavaBeans)なども異なる場所にあるサービスを呼び出す仕組みとして考えられましたが、結局、CORBAやJ2EEといったアーキテクチャの中でしか接続することができませんでした。最新のSOAでは、疎結合の技術によって異なる技術でも、あるいは異なるOS間でも接続できるようになりました」と説明する。 SOAは、分散しているソフトウェアの機能(サービス)を、ビジネスプロセスに従ってコンピュータが自動的に呼び出し、利用できるようにする仕組みである。ビジネスプロセスに従って自動的にサービスを呼び出すのは「記述言語」の役割だ。記述言語は特定の言語やプラットフォームに依存するものではなく、独立して稼働するサービスを呼び出し利用する際のルールが記述される。サービスをビジネスプロセスに従って呼び出すという表現は具体的にイメージしづらいが、米持氏は「サービスはサブルーチンのようなものと捉えてください」と理解を促した。 SOAは特定のプロトコルや実装技術に依存したものではない。SOAのポイントは、1つにはサービスがどこにあろうと呼び出せることだという。すなわちサービスの場所は、同一のメモリ空間であろうと、イントラネット、インターネットであろうと、どこでもよい。また、アプリケーションとサービスをつなぐプロトコルもCORBA、EJB、SOAPのどれであってもよい。そしてSOAのもう1つポイントは、サービスを記述言語によって呼び出す点である。 米持氏は、Webサービス=SOAという誤解が存在すると指摘する。WebサービスはHTTP、XML、SOAP、WSDLといったWeb技術を使ってSOAを具現化する技術であって、SOAそのものではない。ただ、Webサービスは異なる技術で実装されたサービスを呼び出す際やファイアウォールを越えた接続を実現する際に有効な接続方法であるとした。さらに、最近ではWS-Securityを始めとするセキュリティやトランザクションのためのフレームワークの標準化が進むことで、Webサービスを使ったSOAを構築しやすい環境が整ってきたと説明する。 ただし、何が何でもSOAをWebサービスで構築すればよいわけではないと米持氏は注意を促した。「以前、企業統合を行ったECサイトからWebサービスを使ってシステム統合をしたいのでレビューをして欲しいという依頼を受けたことがあります。しかし私はこれを断りました。すべてをWebサービスで繋いだのでは、集中するアクセスにシステムのパフォーマンスが追いつかないからです。ローカルにあるものはローカルで呼んだほうがよく、わざわざSOAPで呼ぶ必要はありません。認証や決済処理はローカル呼び出しやEJBのような高速なインターフェイスで接続するのがよいでしょう。在庫管理を外部の倉庫会社にアウトソースしているなら、そこはSOAPで接続したほうがよいでしょう」(米持氏)。 SOAPは低パフォーマンスであるかわりに、最も疎結合な接続が可能で、プラットフォーム間での接続に最適である。この特性が生かせる場所で利用するのが正しい使い方である。しかも、SOAPのランタイムは徐々にパフォーマンスを向上してきている。しかし、SOAPそのものは究極の技術ではなく、将来新しい技術が登場することも考えられる。「SOAを実現するにあたって、Webサービスとしてアプリケーションを作り込んではなりません。サービスとしてアプリケーションを作ってください」と米持氏はまとめる。 ◆ SOA実現の重要な要素:「コレオグラフィー」と「ESB」 SOAを実現するにあたって、サービスを統合しプロセスを組み立てる「コレオグラフィー」の機能が重要になる。コレオグラフィーはベンダによって呼び方が異なり、他のベンダーではオーケストレーションと呼んでいるものだ。 ビジネスプロセスを統合するツールは、実は従来から存在した。例えばIBM製品ではMQ Workflowがあるが、ワークフローの記述言語はMQ独自のものであり、他のプロセスと自在につなぐことは不可能だ。SOAでは、ワークフローの記述言語は標準化される必要がある。そのため現在、ワークフローの標準化言語としてBPEL(Business Process Execution Language)の仕様策定が進んでいる。当初BPELはIBMとマイクロソフトによって仕様の策定が進められていたが、現在はOASISで標準化が進められている。BPELは実装のための言語だが、いまビジネスとITのギャップを埋めるために、BPM関連仕様の整理が進んでいる。 SOAを実現するフレームワークとして、米持氏はESB(Enterprise Service Bus)を紹介した。ESBはもともとガートナーが提唱したコンセプトである。ガートナーの定義によれば“Webサービスやその他の標準仕様に準拠して書かれたコンポーネントを相互に結びつける機能を持つもの”であるが、もう少し具体的にいうなら、サービス間を非同期のメッセージングによる疎結合によって接続するものだ。 例えば、ある企業が規模の拡大によって従来まで自社で管理していた倉庫を外部の物流企業にアウトソースすることになったとしよう。この場合、物流管理のシステムをアウトソース先と接続することになるが、この変更は非常に工数のかかる作業だ。従来のMQ(Message Queuing)であれば、間にハブとなるサーバを置き、異システム間を接続する方法を採用していた。ESBはそれぞれのシステムがバスを持ち、バスを持つシステム間であれば柔軟に接続が実現できるという考え方だ。「アプリケーションサーバを例にすると、アプリケーションサーバ上のビジネスロジックをメッセージング・エンジンで呼び出すインターフェイスで実装します。そして、アプリケーションサーバのメッセージング・エンジン同士をバスによって接続すれば、ほかのサーバからのビジネス・ロジックの呼び出しが、アプリケーションの実装を変更することなく柔軟に実現できます」(米持氏)。 ◆ SOA実現のためにIBMが提供する製品群 日本IBMは「IBM RATIONAL SOFTWARE DEVELOPMENT CONFERENCE 04」で、「WebSphere Application Server Ver.6」を発表した。最大のトピックは、MQでカバーしていた非同期通信をJMSで実現できるようになったことだが、これに加えて、米持氏はSOAを実現するためのIBM製品が続々と登場していることを紹介した。 ビジネス・プロセスをモデリングするための言語であるBPMNのコンセプトに基づいたツール「IBM WebSphere Business Integration Modeler v5.1」は、ビジネスコンサルや、アナリスト、企業の業務担当の人間が行ったモデリングをBPELやUMLにエクスポートできる。このツールが提供されることで、ビジネスモデリングとITのギャップを埋めることが可能になる。 BPELでビジネスロジックを記述するエディタを備え、ビジネスプロセス上にブレークポイントを設定してのデバックを可能にしたツールが「WebSphere Studio Application Developer Integration Edtion v5.1」だ。また、「WebSphere Application Server Ver.6」では、ESB実現のためのバス「サービス統合バス」の機能が追加された。SIバスは前述のJMSで接続される。 SOAを実現するためのミドルウェアがIBM製品によって揃いつつある。またSOAは実装環境が用意されれば実現されるものではなく、ビジネスとITがシームレスにつながることではじめてその目的が達成されるが、そのためのツールもIBMは整えつつある。
オブジェクト指向時代の開発スタイルとして反復型開発がうたわれて久しいが、いまだ誤解が多く、理解不足での安易な実行が失敗も生んでいる。日本IBM ソフトウェア事業部 ラショナル事業部 SDPテクノロジー・エバンジェリスト 藤井智弘氏は、本セッションで現場における反復開発への誤解を整理し、正しい理解に導くヒントを示した。 ◆ 反復型開発にまつわる誤解の数々
藤井氏は反復型開発における典型的な誤解をいくつか紹介した。例えば、ある調査によれば、ウォーターフォール型の開発でも成功率は全体の25%なのに、反復型の失敗を取り上げて単純に効果がないと否定する傾向が強いという意見がある。これは、反復型開発に拒否感を示す開発者が多いことを示すものだが、藤井氏は「反復型の開発は従来の開発スタイルとはまったく違うわけではないことを理解してほしい」と強調する。 反復型開発に対して工数の見積もりやマネジメントが難しく、かつ、開発が最終的に収束しないという常識もまかり通っている。しかし「反復型開発でも工数の見積もりとマネジメントは可能です。なぜなら、すべての変更要求を受け入れるわけではないからです。また、収束しないと考えるのではなく、収束させるにはどうすればよいかを本来考えなければならないのです」と常識となっている誤解の正体を指摘した。 基幹系業務のオープン移行には不向きであるとか、大規模開発には不向きという意見も多い。これらの誤解についても、「基幹系はシナリオに変更がないから反復は不要という見方は間違っています。ヒアリングすれば新しい要望は多いだろうし、業務には裏に隠れた仕様が多く、システムを改善する絶好の機会であるのにチャンスを逸しているといえるでしょう」(藤井氏)と、偏見によって反復型を避けることによるデメリットを示した 藤井氏は、これら現場でよく見られる誤解を整理した後、反復開発を正しく理解するエッセンスを“誤解を解くための種”として紹介した。 ◆ 誤解を解くための種 まず、反復型開発における「反復計画」についての正しい考え方を、「計画としての種」として示した。「反復型開発はたしかに“変更”に強いが、変更がなければ反復は不要という考え方は誤りです」(藤井氏)とした上で、反復型開発の意義はプロジェクトの早期の段階でリスク要因を取り除くことにあると説明する。 例えば、反復型開発手法の1つであるRUP(Rational Unified Process)のキモは“リスク駆動”であり「ネットワークの負荷やデータベースのロックの競合などは反復型であれば事前にテストが可能であり、早期にリスクを回避できます。従来のウォーターフォール型だと、応答性能が悪いシステムが最終的にできあがってから慌てることになるのです」(藤井氏)と、システムのアーキテクチャに起因するリスクを早期に解決できるのが反復型開発の大きなメリットだと強調した。 次に、「反復型の運営」への誤解を解く「運営の種」としてゴルフを例にとって解説した。「反復型開発の進め方は、ゴルフのゲームの進め方に似ています。ある基本軸の上でずれを修正しながらゴールに向かっていくからです。しかし、ゴルフの場合のように定められた穴にボールを入れることが重要ではありません。開発したソフトウェアの“効果”をゴールとすることが重要です」(藤井氏)。すなわち、仕様書は効果を明確化するための手段でしかなく、仕様書が目的ではないということだ。目的のイメージを全員でコミットすることが重要だという。また、顧客からの変更要求を受け入れるか切り捨てるかの基準も、ソフトウェアの効果を目標として考えるべきだという。 ◆ 反復型開発のゴールはROIの最大化 ところで、反復型開発の目的は何だろうか? 藤井氏はそれをシステムのROIの最大化だとし、反復型開発のゴールへの誤解を解く「目的の種」を説明した。「経営層、営業、購買など、それぞれ利害関係者の要望は異なります。誰をサービス対象として誰をサービス対象としないか。多くある問題の中の何を対象として何を対象としないかを基準に開発構想書を作成し、システムの存在価値をきちんと定めることが重要です。さらに、ユースケース・モデルにおいては、変更がユースケースの中の調整で済まない場合は、その変更が定義されたソフトウェアの価値に効果をもたらすか否かというROIの観点で判断すべきです」(藤井氏)。 反復型開発のキモは、システムをシナリオで切り刻み、切れのよいシステムを作ること、ビルディングブロックで組み立てられるシステムにすることだという。これが「反復型の構造」に対する誤解を解く「構造的な種」だ。ユースケースはある目的を達成するために取り得る操作手段の総体であり、かつ全フローの入れ物である。切れのよいシナリオにするには、ブロックを組み合わせてシナリオを作ることが大事である。広義のソフトウェア構造には、実績のあるモノがある。IBMではそれらをパターン化してソリューションを展開しており、最終的にはMDA(モデル駆動型アーキテクチャ)につながっていくだろうと付け加えた。 最後に藤井氏は「システムというコンテキスト(文脈)だけで開発プロセスを考えていては、“果実”は小さいのです。誤解は逆に理解への早道だと思って、ぜひ反復型開発の正しい理解にチャレンジしてほしい」と締めくくった。
|
|