サービス指向アーキテクチャ(SOA)に基づくアプリケーション設計の現状と課題

全文

(1)2005−SE−149（10） 2005／7／29. 社団法人情報処理学会研究報告 IPSJ SIG Technical Report. サービス指向アーキテクチャ(SOA)に基づくアプリケーション設計の現状と課題大場克哉†、○橋本誠†、藤倉成太†、宗平順己† †株式会社オージス総研要旨: 近年、サービス指向アーキテクチャ(SOA)が、新しいソフトウェアアーキテクチャとして注目されているが、SOA に基づいたサービスおよびビジネスモデル設計に関する方法論はいまだ確立されているとは言い難い。本稿では、SOA アプリケーション設計のための UML 拡張およびその適用プロセスを提案し、実例とともに、現状の課題を提示する。. The Status Quo and Challenges of Service-Oriented Architecture (SOA) Based Application Design Katsuya OBA†, Makoto Hashimoto†, Shigemoto FUJIKURA†, Toshimi MUNEHIRA† †Osaka Gas Information System Research Institute Co, Ltd Abstract: Service-Oriented Architecture (SOA) is emerging in the area of software architecture. This paper provides a concept of development process, reference architecture and a new UML profile for SOA systems development and integration. The proposed development process allows system architect to cooperate with business analysts by leveraging the UML. SOA profile allows developer to model SOA system including interactions of services and business process that orchestrates services. This paper demonstrates how to use the proposed profile, and discusses issues remaining in the area of SOA.. 1.. はじめに. SOA が注目されており、多数の Web サービス、 SOA 関連仕様がリリースされているが、実際にシステム構築をするためには、標準を理解するのみでは不十分であり、設計のためのガイドラインが必要である。そこで、UML を用いた SOA 設計のための UML 拡張（プロファイル）および適用ガイドラインを考案した。本稿では、その概要を示すとともに、検討過程で明らかになった課題および考えられる解決策を提案する。. 2.. SOA の概要と導入課題. 2.1. SOA とは SOA は「サービス」という概念を中心に据えるソフトウェアアーキテクチャである。サービスは、分散システムにおけるソフトウェアコンポーネントであり、実装プラットフォームに依存しない明示的インタフェースによって定義される[1]。企業経営の観点からは、企業の構造をビジネスモデルとそれを実現するための情報システム等から管理する Enterprise Architecture との親和性が指摘されている[2]。サービスとビジネスの機能を対応付けることにより、ビジネスプロセスが変更された場合にも、情報システムにおける柔軟かつ迅速な対応が可能となる。 SOA の実装技術としては、SOAP[3]など Web サービス関連技術がその代表であるが、中でもサービスインタフェース記述のための WSDL[4]が重要である。WSDL には、メッセージフォーマットの抽象的な定義の記述とランタイムに必要なバイ. ンディング情報が記述され、これによって SOA の特徴である疎結合性、実装プラットフォームとの分離が実現される。 WSDL によって定義されたサービスは、 Business Process Execution Language For Web Services (BPEL) [5]などのビジネスプロセス記述言語によって定義された業務フローに従って呼び出され、システム連携を実現することができる。このほか、W3C や OASIS などの標準化団体によって各種の Web サービス関連仕様が策定、提案されている。これらのカバーする範囲は、トランザクションやセキュリティなど多岐にわたり、堅牢かつ柔軟な業務システムを構築するために、これらをシステムの要求に応じて組み合わせていくことが必要である。. 2.2. SOA 導入の課題このように、すでに SOA を実現するための標準仕様の策定がすすみ、実装を提供する製品、ツール群がソフトウェアベンダーやオープンソースプロジェクトからリリースされているにもかかわらず、現在のところ、SOA の適用は一部の先進的企業にとどまり、多くの企業への導入がすすんでいるとは言いがたい。これは、数多くの標準仕様を理解し、活用することの困難さに加え、これらを統合し、情報システムのアーキテクチャを構築することの困難さに一因があると筆者らは考える。企業の複雑な業務を実現する情報システムにおいては、数多くのソフトウェア部品が複雑に関連しており、SOAP, WSDL などの SOA 関連技術を導入したとしても、. −73−.

(2) それだけでは、SOA のメリットとされている変化に対する柔軟性、部品の再利用性が向上する保証はない。これは、技術の導入と複雑さの低減がかならずしも対応しないためである。従来から、複雑な情報システム開発にあたっては、設計および開発プロセスの重要性が唱えられている[6]。たとえば、オブジェクト指向設計においては、UML[7]を用いて、システム化対象領域のクラスおよびクラス間の関連などをモデル化し、この作業を通じて、クラス間の依存関係を整理するなど、複雑さを減少させる工夫がなされる。また、繰り返し型開発を利用して、システム開発のリスクを下げる手法も普及がすすんでいる。 SOA においても、サービスを同定し、それを組み合わせて、ビジネスプロセスを記述ためのモデル記述法、設計技法、開発プロセスが必要である。しかしながら、従来の設計技法、開発プロセスは、 SOA が提唱される以前に開発されたことから、そのままでの適用が困難であるのが現状である。以上から、筆者らは SOA を実現するための開発プロセス、実行アーキテクチャ、モデル記述法を開発し、仮想企業の業務を例に実証実験を行った。. 3.2. サービス指向アプリケーションの構成サービス指向アプリケーションの構成を考えてみる。サービス指向アプリケーションは図１のように 3 つの層で構成される。上位層はビジネスプロセス層であり、組織内や組織間の複数の既存、新規サービスを連携させてビジネスから要求される機能を実現する。この層が提供するメリットは BPEL に代表される組み合わせ言語を用いた迅速なビジネスプロセスの組み立ておよび組み替え、BPM の実現、およびビジネスモニタリングによるビジネスの迅速な把握である。次のサービス層ではビジネスプロセスを構成する個々のサービスのインタフェースを規定する。このサービスのインタフェースを適切な粒度で設計することにより、他に対してサービスの再利用を可能にし、開発生産性、保守生産性を向上させる。さらにはサービスのインタフェースを WSDL により公開することで実装非依存や疎結合を実現する。ビジネスプロセス層. サービス層. 3.. サービスおよびビジネスモデル設計プロセス. 3.1. プロセス検討にあたっての前提これまでの RUP[8]を中心とする統一プロセスではシステム化すべき業務を中心にビジネスモデリングを行い、この作業分野を元に要求、分析・設計、実装、テストという下位の作業分野を経て実際に動くシステムを開発する。ソフトウェアを本番システムとしてエンドユーザーにリリースするためにはこのサイクルを従来のウォータフォール型のように 1 回だけ実施するのではなく、方向付け、推敲、作成、移行フェーズという 4 つのフェーズで複数回実施することにより、早い段階でリスクを解消したり、エンドユーザーの要求をフィードバックすることで、より安定した、よりエンドユーザーの要求に答えることができるシステムを提供することができる。 RUP の利用は国内においても広がりをみせていると思われるが、RUP が対象としている範囲はあくまでも個別の開発プロジェクトであり、複数の開発プロジェクト間で開発、維持すればいいかという手順とガイドラインは明確に提示していない。しかしながら SOA ではサービスと呼ばれるビジネスの機能単位を単一システムを超えて再利用させることで、生産性、保守性をに高めようと意図するものである。そのためプロセス検討にあたっては次に述べるサービス指向アプリケーションの構成を活かした開発プロセスを検討することにした。. コンポーネント層. 図１ SOAアプリケーションの構成最下位層のコンポーネント層はサービス層で要求される機能を実現するための実装レイヤーであり、JAVA や.Net などの開発言語、もしくは ERP などのパッケージ、メインフレームのレガシーアプリケーションなどで構成される。. 3.3. サービス指向開発プロセス概要筆者らはこのサービス指向のアプリケーションの構成を考慮した図２のようなサービス指向開発プロセスを考えた。まずは戦略アーキテクトがビジネス戦略を検討し、ビジネスの目標設定を行う。それを元にビジネスアーキテクトは具体的な業務の仕組みを明らかにするためのビジネスモデリングを行う。戦略アーキテクト（ビジネスコンサルタント）. 目標設定. ビジネス戦略. ビジネスアーキテクト（BA). アプリケーションアーキテクト（AA). ビジネスモデリング. プロセスモデラー（PM). RFP. アーキテクチャ設計. 業務プロセス図ビジネスユースケース図. アーキテクチャ. サービスコンポーネントプロバイダ（SCP). BPEL プロセスモデリング. コンポーネントI/F. システムテスト担当者. 新規サービスのみ. サービスコンポーネント設計. 設計書 WSDL. ビジネスオブジェクト図. BPEL. システム化計画. BPEL プロセス検証. 開発プロセスアセス. サービススタブ. サービスコンポーネント実装. ＪＡＶＡ .Net. サービスコンポーネント検証システムテスト. Iteration開発. 図２ SOA開発の流れ −74−.

(3) ザクション、信頼性などをサポートすることで非筆者らは UML を用いてビジネスモデリングを機能要件の実現をアプリケーションから切り離す。行うが、業務の対象領域や人、IT などの資産、業また、ESB は複数のシステムが個別に直接接続さ務プロセスをユースケース図、クラス図、アクテれている関係を仲介することにより整理するメディビティ図にてモデリングする[9]。ィエータデザインパターンを提供する。GoF[10] ひとたびビジネスモデルができると、システムによればメディエータデザインパターンはオブジ化計画によりどの業務を IT 化するかを明確にすェクト間の同士の明示的な参照をなくし、結合度ることでシステム開発がはじまる。筆者らのサーを低めることで、両者のオブジェクトの相互作用ビス指向開発プロセスではシステム開発は先に述を独立に変更でき、お互いに影響しないものにでべたプロセス層を開発するプロセス開発とサービきる。ス層・コンポーネント層を開発するサービスコンそれではこの ESB が 3.2 章で定義したサービスポーネント開発に明確に分けて開発する。まず、指向アプリケーションの構成においてどのようにプロセスモデリングでは再利用可能な既存サービこのメディエーションが介入するかを説明する。スおよび新規サービスのインタフェースを明確にメディエーション層は図３ようにサービス層の上し、サービス間のフローを UML のアクティビテ部に位置し、プロセス層からのサービスの呼び出ィ図を用いて設計する。プロセス検証ではこのアしを仲介する。そのことにより異なる通信プロトクティビティ図より BPEL や WSDL に変換し、こコルの吸収し、サービスのロケーションやインタれらを BPEL ランタイムにデプロイすることで実フェースの変更によるプロセス層の影響を排除す際に動かして検証するが、サービスの実装はスタる。また、すべてサービスの呼び出しがメディエブを用いて行う。この検証により、サービスインーション層経由で行われることから、経由するデタフェースとサービス間の連携を表すフローを実ータをキャプチャ、フィルタすることでロギング、装レベルで検証することができる。監査、イベントの通知をアプリケーションで作りサービスコンポーネント開発ではプロセス設こむことなく行うことができる。計・検証により定義・検証された個別のサービスインタフェース定義(WSDL)を元にその機能をサビジネスービスコンポーネントプロバイダが設計・実装・プロセス層検証する。再利用可能なサービスが多ければ多いメディエーション層ほど、実装すべきサービスコンポーネントの数がサービス層少なくなり、サービスコンポーネント開発にかかるコストと時間は少なくなる。すべてのサービスコンポーネントの開発が完了すると、システムテストでは検証済みのプロセスコンポーネント層と検証済みのサービスを組み合わせてテストすることでシステム全体を検証する。プロセス検証に図３ SOA ソフトウェア構成での ESB の位置付けおいてあらかじめサービスのインタフェースとその間のフローが実装レベルで検証されているので、 4.3. サービス指向のリファレンスアーキテクサービスインタフェースの不一致やサービス間のチャフロー定義の誤りによる手戻りが少ないと筆者ら筆者らは SOA に適した企業内のリファレンスは考える。アーキテクチャを考察した。リファレンスアーキ. 4.. サービス指向における実行アーキテクチャ. サービス指向の実行アーキテクチャに求められるものサービス指向の実行アーキテクチャに求められることとしてプロトコルなどの実装や非機能要件の実現をアプリケーションから切り離すこと、さらにはサービスの仕様変更の影響をアプリケーションに波及させないことである。 4.1.. 4.2. ESB とは最近、サービス指向の実行アーキテクチャにおいて ESB(エンタープライズ・サービス・バス)が注目されている。ESB はプロトコルをアプリケーションから隠蔽すること、セキュリティ、トラン. テクチャは企業全体に適用するためのテクノロジーアーキテクチャ標準である。企業においてリファレンスアーキテクチャを作成し、遵守することで、これまでのようにさまざまで不揃いなアプリケーションアーキテクチャが乱立することの弊害を阻止し、企業全体で整合性のあるアーキテクチャを保つことができる。 SOA の実現をターゲットとした典型的なリファレンスアーキテクチャは図 4 のように ESB を核として、その周辺にさまざまなサービスを配置させる形態をとる。サービス間のやり取りはすべてこの ESB を経由して行うことでサービスのロケーションの変更やインタフェースの不整合を ESB により吸収することで、アプリケーションによる必要がなくなることで、より柔軟な IT インフラを提供することができる。. −75−.

(4) ポータルポートレットポートレットポートレット. J2EE、.Netアプリ. プレゼンテーションプレゼンテーションビジネスロジックビジネスロジックデータロジックデータロジック. RDB. ERPパッケージ. J2EE/.Net. アプリ共通サービス（J2EEアプリ） RDB. COBOLビジネスロジック COBOLビジネスロジック. フレームワークポートレット API(WSRP). メインフレーム DB2. モジュール（ABAP）アドオン (ABAP) アドオン. J2EE. CICS. ERP用アダプタ. メインフレームアダプタ. 共通アプリ共通アプリ. J2EE/.Net. 汎用アダプタ JMSインターフェイス. WebServicesインターフェイス（SOAP、RPC/Document）. メディエーション機能（ルーティング、メッセージ変換、ロギングなど）同期通信. 非同期通信. バッチ転送. メッセージングエンジン（JMS）エンタープライズサービスバス. システムイベント. イベントイベントリスト提供収集. 運用監視サービス. WSDL WSDL WSDL. サービスレジストリ. システム管理サービス. イベント定義. 認証、認可機能. BPM エンジン. セキュリティサービス. ビジネスプロセス. LDAP. 管理サービス. セキュリティサービス. イベントイベントリスト提供収集. ビジネスモニタリングサービス. ビジネス管理サービス. アウトバウンドインバウンドサービスサービス. ゲートウェイサービス. 通信サービス. 図４企業内のリファレンスアーキテクチャ. 5.. UML によるサービスおよびビジネスプロセス記述. 5.1. SOA モデリング UML では、プロファイルによって UML の表現方法を拡張する方法が提供されている。 UML プロファイルは、主にモデル要素が特定の実装技術においてどのような意味を持つのかを明示的に記述するのに用いられ、開発者間でのモデルに対する解釈の曖昧さを排除することができる。また、ツールによって部分的にソースコードを自動生成することも可能となる。筆者らは、SOA システムを UML でモデル化するための UML プロファイルを考案した。また、現在の SOA システム開発において業界標準となりつつある WSDL 及び BPEL との変換規則を定義した。この変換規則を UML ツールに実装することにより、WSDL 及び BPEL の生成、UML モデルへの読み込みを可能とする。 5.2. UML によるサービス記述 SOA におけるサービスは、「サービス実装」と「サービスインタフェース」から成る。「サービス実装」とは、サービスの機能を実現するためのソフトウェアコンポーネントであり、新規に開発されるシステムである場合や、再利用されたソフトウェア資産である場合もある。「サービスインタフェース」は、各サービス実装の公開するインタフェースを定義する。SOA では「サービスインタフェース」を標準の方法で定義し、他者との交換を可能とすることが重要となる。現在、WSDL を使って「サービスインタフェース」を定義することが主流となりつつある。また、BPEL による WSDL への拡張機能を使ってサービス間の関係を定義する。「サービスインタフェース」を UML でモデル化する場合、インタフェースが WSDL の portType. であることを意味づけするステレオタイプ portType を割り当てる（図 5）。. 図５サービスインタフェース「サービス実装」である WSDL の service 及び port は、ステレオタイプ service を割り当てられたコンポーネント、port ステレオタイプを割り当てられたインタフェースで表す（図６）。. 図６サービス実装. UML によるサービス間連携のモデル記述サービスには、特定の呼び出し側が想定されない一般公開型のサービスと、呼び出し側との相互呼び出しの関係を持つものがある。WSDL 及び BPEL では、サービス間の関係は partnerLinkType で表現される。partnerLinkType は一つの portType を参照することで一般公開型の関係を表し、二つの portType を参照することで相互呼び出しの関係を表す。他のサービスとの相互呼び出しの関係を持つサービスは、二つの portType を表すインタフェースとそれぞれに関連を持つクラスに partnerLinkType のステレオタイプを割り当てる。この partnerLinkType のクラスが、サービス間の関係を定義するプロパティを持つ（図７）。 5.3.. 図７相互呼び出し型サービス −76−.

(5) 一般公開型のサービスは、関係する先が明示されない特殊なサービス間の関係である。関係の一方は portType を表すインタフェースとし、他方は anonymous ステレオタイプを持つインタフェースとする。. 図８一般公開型サービス. 5.4. UML によるビジネスプロセス記述ビジネスプロセスとは、公開されたサービスを利用することで実現される業務フローである。 BPEL のビジネスプロセスは、それ自身もサービスとして公開される場合もあり、ビジネスプロセスは外部からのメッセージの到着もしくは特定の. イベントが発生した時点で開始される。ビジネスプロセスは UML アクティビティ図を用いてモデル化する。BPEL のビジネスプロセスには外部からのメッセージの到着を待つ receive や到着したメッセージに対する返信を送り返す reply、他のサービスを呼び出す invoke、ある一定時間処理を止める wait などの数種類の基本アクティビティと、それらの直列や並列の連結、繰り返しを表す構造化アクティビティがある。基本アクティビティは UML アクティビティモデルのアクション状態にそれぞれ BPEL の基本アクティビティを表すステレオタイプを割り当てることで表す。また、構造化アクティビティは、UML サブアクティビティにステレオタイプを割り当てることで表現するか、またはアクティビティの構造を使って表現する（図９）。. 図９ビジネスプロセス記述. 6.. モデリング例. 衣料の小売業者を想定した例題を使って、SOA システムの設計方法論やアーキテクチャ及びモデル記述の妥当性や課題を検証した。検証にあたっては、まず、現在のビジネスモデルとその現状問題点を設定し、その問題点を解決するためのビジネスプロセスを作成した。次いでこのプロセスを提案した方法論とモデル表記を適用してモデル化を行い、実際にシステムを実装することでアーキテクチャを検証した。. 6.1. 対象企業のビジネスプロセスモデル想定する企業は、商品を店舗で販売するほか、オンラインでも販売する。商品は協力工場に依頼するが生産管理は自社のシステムにて行い、各店舗には在庫スペースがあまりないため、製造後商品は一旦物流センターに保管される。物流センターに保管された商品は、注文数に応じて各店舗へ配送される。図 10 は、店舗での商品販売のビジネスプロセスモデルを示す。図中のスイムレーンは、企業や企業内の組織に対応する。. 図 10 ビジネスプロセスモデル −77−.

(6) 6.2. システムモデル作成したビジネスモデルを元に、システムモデルを作成した。システムモデルを作成する際には、変数を割り当てるためのアクティビティなど、ビジネスモデルには存在しなかったアクティビティを追加する。また、ビジネスモデルに含まれる人による処理のみで完結するアクティビティをモデルから削除する。ただし、人の意思決定は Web システムや ERP システム、メール等を経由してプロセスと人のインタラクションを実現することになる。プロセスから Web システム等を呼び出すためには、それらの外部サービスとしてのインタフェースを定義する。また、システムモデルではスイムレーンは外部サービスとのインタラクションを表わした。ビジネスモデルにおいて組織を表わしていたスイムレーンを、その組織が運用するシステムに置き換える。図 11 は、前述したビジネスプロセスをシステムモデルに変換したプロセスを示す。システムモデルを作成する際には、定義した. 7.. 課題. UML プロファイルに対応したソフトウェアを UML ツールに組み込み、プロファイルに基づいた UML 図を作成、 BPEL や WSDL を自動生成した。. 6.3. 実行環境 BPEL の実行環境を開発し、動作の検証を行った。また、例題のシステムを実行するために、外部サービスや人による意思決定の部分を実現する Web システムを開発した。検証を開始した当初は、一連のビジネスプロセスを一つの BPEL によって実現した。しかし、このようにすると、システム中に例外が発生した場合の補償動作の記述が煩雑になることが分かった。そこで、外部サービスを EJB システムや BPEL によるプロセスに置き換え、それらのサービス間を ESB でつなぐアーキテクチャに変更した。この変更により、複雑になりがちな補償動作を比較的単純に記述できるようになる。その他、4.で述べたようなメリットが検証できた。. 図 11 対応するシステムモデル. 7.1. SOA 関連仕様の利用に関わる課題 7.1.1 コレオグラフィビジネスプロセスを記述するための言語として、本研究では BPEL を利用したが、BPEL だけで、企業内あるいは企業間に渡るビジネスプロセス全てを記述するのは困難である。たとえば、BPEL では、サービス間の連携を partnerLinkType として定義するが、これは BPEL で記述するプロセスとそこから呼び出される（または呼び出す）サービスとの関連にとどまり、３者以上の主体が相互作用する複雑なサービス依存関係を記述することはできない。特に、B2B のようにそれぞれ独立した関係者が、事前に合意した手順でビジネスプロセスを構成する場合には、 WS-CDL[11]などのコレオグラフィ記述言語を BPEL とあわせて利用する必要がある。. 7.1.2 イベントまた、ビジネスプロセスにおいては、あるメッセージを不特定多数のサービスに配信する必要性が生じるが、これを BPEL だけで記述するのは困難である。イベント指向アーキテクチャ(EDA)[12] では、「イベント」という概念を利用して、 Publisher-Subscriber 型など１対多、多対多のメッセージ配信を実現しようとしている。現在、EDA を実現する仕様が複数提案されているが、未だ業界標準といえるところまで認知されたものは存在しない。 7.1.3 仕様の成熟度 SOA に関連する仕様は 2.にも述べたとおり、数多く提案されているが、W3C 勧告など標準化の最. −78−.

(7) 終段階まで到達したものは少なく、標準化の途中で業界標準として認知され、利用開始されているものが少なくない。そのため仕様の中には、不明確な部分や間違いであると考えられる部分も存在している。また同一使用におけるバージョン間の違いが大きく、さらに仕様間の依存関係が複雑であることから、採用する仕様およびバージョンには注意が必要である。. SOA の実行アーキテクチャに関わる課題今回の実証実験では、当初はすべてをひとつの BPEL プロセスで実現しようとしたが、そもそも異なる組織をまたいでひとつの BPEL で制御しようとすると、どの部門、会社が責任を持ってそのフローを管理、運用するかという問題に直面する。また、組織内のビジネスプロセスはそれぞれの事情で変更されることがあり、その度に全体の BPEL フローを変更することは現実的ではない。このような理由から、途中で方針を変え、3 つの組織でそれぞれが BPEL もしくは J2EE でビジネスプロセスを実現し、その間を ESB を想定し非同期、疎結合でつないだ。組織間を非同期とすることで相手が稼働していなくても、送信側から処理要求を ESB に非同期で送っておけば、相手が稼働した際に処理することで柔軟性が高まる。このような非機能要件の観点から SOA の実装アーキテクチャを検討する必要がある。また、主要ベンダーは BPEL 準拠の製品を出荷しているが、まだまだ製品はこなれていないことや、BPEL の現在の仕様で不十分な部分は独自仕様で実現しているなど問題があると思われる。また、実際にベンダーツールが使われるためには、運用面の機能を充実していく必要があると思われる。例えばビジネスプロセスプロセスが頻繁に変わることを想定し、ひとつの BPEL プロセスに関して複数のバージョンの存在を可能にするなどの配慮が必要である。さらに、ESB に関してはまだまだ概念が先行しており、製品についても各社がまちまちの機能の ESB 製品を出荷しているような状況であるが、今後は J2EE のようなに規格が定まり、それに準拠する製品が提供されることが望ましい。 7.2.. 7.3. SOA モデリングに関わる課題 5. に述べた UML プロファイルを利用することにより、サービスインタフェースとサービス連携、ビジネスプロセスを記述することが可能である。しかし、これをより多くの関係者間の意思の疎通、また実装モデルとの連携に利用するには以下の課題が残る。 7.3.1 ノーテーション UML は情報システムのモデリングへの適用が進んでいるが、ビジネスモデリングの分野への適. 用はまだ一般的とは言いがたい。また、ひとつの汎用的なモデリング言語をあらゆる場面で利用することは、かならずしもビジネスおよび情報システム構築の関係者全てにとってわかりやすく、つかいやすいとは限らない。そのため、UML 以外のモデル記法の導入を検討する必要がある。たとえば、BPMN[13]は、ビジネスプロセスモデルを記述するためのノーテーションであり、あらかじめ定義された豊富なアイコンとセマンティクスで、情報システムの知識を持たない経営層や業務アナリストらによる利用が期待されている。 7.3.2 複数モデル間の連携実際のシステム開発においてはサービスのインタフェースだけでなく、J2EE や.NET などの実装技術を反映した実装モデルを構築する必要がある。そこで実装技術を反映した UML プロファイルによって記述される実装モデルと、SOA 記述のための UML プロファイルで記述した、実装技術に依存しないインタフェースのモデルの整合性を保つ必要がある。また、SOA が業務と情報システムを一体化させるための技術であると考えるならば、ビジネスモデルとシステムモデルの整合性を保ち、相互変換を可能にする必要がある。ビジネスモデルが 7.1.1 に述べた BPMN で記述され、システムモデルが UML で記述されるとすることを想定すると、これらの相互運用性を実現する必要がある。さらに、サービス間で授受されるメッセージフォーマットや、サービス間の関連を BPEL とは異なった視点で捉えるコレオグラフィのモデル化にあたっては、新たな UML プロファイルの適用のほか、これらに特化した Domain Specific Language(DSL)[14]が今後開発されることが考えられる。このように、SOA のモデリングにあたっては複数のプロファイルで定義された UML モデル間、また複数の DSL 間の相互変換および統合が必要である。. 7.4. UML サービス抽出における課題 SOA では、サービスがビジネスプロセスを構成する単位となることから、ビジネスモデルまたシステムモデルを記述する段階でこれを正しく同定することが重要であると考えられる。これにより、サービス間の結合度を小さくし、再利用性を高めることが可能となる。サービスの粒度は、大きくしてしまうとそのサービスの再利用性を低下させ、逆に粒度を小さくするとサービス間の結合度が強めることになる。サービスのユースケースを定義し、そこからサービスの粒度を適切なものにする設計手法が必要である。 SOA システム全体を表現するためには、ビジネスプロセスによるフロー記述やサービスインターフェイスのモデル化のみではなく、ユースケース. −79−.

(8) 図によるサービスユースケースの記述やシーケンス図によるサービスの利用シナリオ等を表現することを可能にする、より抽象度の高い UML プロファイルが必要である。このような UML モデルによって、サービスをより適切に捕らえることができる。 SOA でサービスを組み合わせる場合、ビジネスプロセスを中心とするオーケストレーションと、サービス同士を決められたプロトコルに従って協調させるコレオグラフィと、大きく分けて二通りの方法がある。これらを統一的な UML プロファイルで記述することで、システム間の相互作用モデルを明確に定義することができ、特徴的なモデルをパターンとして収集することも可能となる。. 7.5. その他企業規模でサービスの再利用を促すためにはさまざまなサービスのランタイムや設計情報が保持されているリポジトリが必要となる。このようなリポジトリを整備することで、各部門のシステムを適切なサービスを検索して利用することができる。 SOA が事業部間や会社間で使われることを想定すると、認証、暗号化、署名などのセキュリティが極めて重要となる。 WEB サービスの標準化の動きとしては WS-Security をはじめとするさまざまな仕様が提案されており、その一部はリリースされているが、まだまだ実際に使われている例は少ない。また SOAP のメッセージの認証、暗号化、署名は負荷がかかる処理であり、現段階ではパフォーマンス面で不安を残す. 8.. まとめ. 以上、SOA のシステム実証を踏まえて、実装にあたっての課題を抽出した。この課題は、筆者らが定義したＵＭＬプロファイルや方法論に起因するものではなく、標準化やビジネスモデリングなど SOA の設計の前提課題である。これの問題は、一部には指摘されていたことであるが、方法論やＵＭＬプロファイルを確定したことにより、問題点としてより明確になったものである。これらの課題は、SOA の普及拡大に関わる問題であることから、 7.2 にも指摘したが各ベンダーが独自の方法で解決するのではなく、標準化がなされることが望まれる。これらが解決されれば、サプライチェーンにも SOA のアーキテクチャを拡張適用できるようになる。その結果、企業活動は多くのパートナーとの関係においてなりたっていることから、将来 EA のターゲットアーキテクチャとして、SOA を位置付けることが現実解として可能になる。. 参考文献 [1] Wada, Suzuki, Takada, Doi, ”Leveraging Metamodeling and Attribute-Oriented Programming to Build a Model-driven Framework for Domain Specific Languages”、8th JSSST Conference on Systems Programming and Applications、2005. [2] 加藤正和 “かんたん! エンタープライズ・アーキテクチャ” 翔泳社、2004. [3] W3C, “SOAP Version 1.2 Part 0: Primer”, http://www.w3.org/TR/2003/REC-soap12-part0-2 0030624/, 2003. [4] W3C, “Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language”、 http://www.w3.org/TR/2005/WD-wsdl20-200505 10/, 2005. [5] BEA Systems, IBM, Microsoft et al. “Business Process Execution Language for Web Services Version 1.1” ftp://www6.software.ibm.com/software/developer /library/ws-bpel.pdf, 2003. [6] Ambler, Nalbone, Vizdos “The Enterprise Unified Process”, Prentice Hall, 2005. [7] Object Management Group, “Unified Modeling Language: Superstructure version 2.0”, http://www.omg.org/cgi-bin/doc?ptc/2004-10-02, 2004. [8] フィリップ・クルーシュテン著, 藤井拓訳," ラショナル統一プロセス入門",アスキー,2004 [9] 竹政昭利, 左川聡著「ビジネスマンのための UML 入門」,毎日コミュニケーションズ,2004 [10] Erich Gamma, et al ,"Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Pub Sd, 1995 [11] W3C, “Web Services Choreography Description Language Version 1.0”, http://www.w3.org/TR/2004/WD-ws-cdl-10-2004 0427/, 2004. [12] Hanson, “Event-driven services in SOA”, http://www.javaworld.com/javaworld/jw-01-2005/ jw-0131-soa.html, 2005. [13] Business Process Management Initiative, “Business Process Modeling Notation (BPMN) Version 1.0”, http://www.bpmi.org/bpmn-spec.htm, 2004 [14] Greenfield, Keith, “Software Factories”, Wiley, 2004. −80−.

(9)