ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソリューション・サービス
  3. SOA
  4. SOA関連製品・サービス
  5. SOAシステム開発方法論
ここから本文です。

SystemDirector EnterpriseのSOAシステム開発方法論のご紹介

1.はじめに

企業は今、事業環境の変化にさらされており、その変化への追随が必要不可欠になっています。それに合わせてシステム側も変化への対応能力が重要視されています。昨今サービスという考え方によりシステムをビジネス的にも意味のあるまとまりに構成し、その変化を柔軟に対応しようとする考え方が発展してきました。最近では、クラウド・コンピューティングという考え方により、そのサービスを自社内で"保有"するだけではなく、一般に公開することで外部への"サービス提供"を実施し、逆に外部から公開されたサービスを"利用"しようとする考え方に代わってきています。実装技術的には、プレゼンテーションレイヤとアプリケーションレイヤもそれぞれサービスという考え方で整理され、それを柔軟に組み合わせることにより、柔軟性を追求するアーキテクチャとして整備されています。

昨今サービスは上記のようにフロントエンドサービス(プレゼンテーションレイヤ)とバックエンドサービス(アプリケーションレイヤ)で整備されるようになりました。NECの開発標準であるSystemDirector Enterpriseはこれらの状況に合わせてシステム開発を行うための開発方法論を整備しています。今回まずはバックエンドサービスのシステム開発手順をまとめた開発方法論についてご紹介いたします。フロントエンドサービス開発についてはまたの機会にご紹介させていただきます。

2.SystemDirector EnterpriseのSOA開発方法論概要

2.1 SOAシステムにおける効果の相関関係

SOAシステムの導入における効果の相関関係について説明します。SOAシステムの導入に当たっては、正しくその効果と限界を把握することが重要になります。SOAシステム開発の各々のフェーズにおいて以下の導入効果があります。

企画フェーズでは、ビジネス戦略へ追随することが可能となることです。サービスをこの戦略に合わせて設計しておくことで、組織の組み換えや業務の変化へ柔軟に追随することができます。また段階的なシステム拡張を可能とするため、初期投資を抑えたスモールスタートのシステム開発からはじめることができます。

設計フェーズでは、開発分散化が可能になる効果があります。サービスという標準化されたインタフェースを持つ単位に設計が行えるため、開発を分散且つコンカレントに実施できます。また標準化されたインタフェースにより、界面の仕様が明確となり、結合時のトラブルリスクを軽減することが可能です。

実装フェーズでは、システム統合を容易性にする効果があります。言い換えると多様なアーキテクチャを持つシステム間の接続・統合が可能となります。また、他のサービスに影響を与えず、サービス単位に再構築(システムの段階的な刷新)することが可能となります。

運用フェーズでは、運用手順の平準化が可能になります。サービス単位の部分的なシステム刷新や、システム拡張が実現できるため、ライフサイクルの長いシステム構築が可能となります。またサービスを他のシステムでも利用可能とする再利用性が向上するため、次ステップのシステム開発において生産性が向上する効果をもたらします。

最後にコスト面では、サービス単位の段階的な開発計画が立案できることで、スモールスタートが実践できます。システムの拡張に伴って、成長型の対投資効果が得られます。

このように各フェーズにおいてSOAシステム導入による効果が得られます。この効果は、一度のシステム開発において得られるものもありますが、サービス開発を蓄積していく次ステップ以降のシステム開発になるほどその効果を享受することができるものも多く含まれています。

2.2 SOAシステム導入の際に起こりがちな問題点

このようにSOAシステム導入によるメリットが享受できる反面、SOAシステム導入の際に起こりがちな問題点もあります。大きくは、以下の4つの課題について留意していただくことが必要です。

  • A)サービス定義が曖昧になりやすい
    サービスの再利用や蓄積することばかりに気をとられ、設計時の手順や指針の標準化がおろそかになり、属人的な設計粒度でサービスが数多く設計されてしまう。というケースです。また、サービスの単位が小さすぎて実装段階の作業工数が増えてしまい、加えて性能問題をも発生させてしまう。逆に今後は粒度が大きすぎて再利用ができず、結局ワンタイムなサービスを数多く実装することになってしまう場合です。
  • B)目的や効果を正しく把握しにくい
    本来は、業務改善を目的としたSOAシステム導入を計画していたのですが、気がつけばSOA対応のツールやミドルウェアの活用が優先となり、企業課題の解決に至らない。というケースです。SOA適用の本来の目的を見失ってしまった結果です。
  • C)従来手法と同等の見積りにしがち
    ファーストステップのSOAシステム開発では、従来のアプリケーション開発時に比べて標準化設計の範囲が従来よりも広範囲に渡る場合が多いことや比較的高価なツールやミドルウェア等を導入が必要なケースが存在するため、従来手法よりもコストがかかるにも関わらず、開発やツール導入に加えて教育等のコスト見積が見誤ってしまうケースです。
  • D)設計後どのようにして実装に結び付けるか路頭に迷う
    設計したサービスの性能を考えた場合の適切な実装方法やミドルウェアの選択、配置方法及び設定方法がわからず手探り状態となるケースです。

このような問題点・リスクを最小限に抑えるために開発方法論・開発基盤の利用が必要となってきます。

2.3 SystemDirector Enterpriseによる解決策

SystemDirector Enterprise(以下SDE)では、上述の問題点に対して、以下により解決します。

「A)サービス定義が曖昧になりやすい」に対してはサービスの設計粒度を定義した開発方法論を適用します。
「B)目的や効果を正しく把握しにくい」に対しては開発方法論のプロセスの中で本来の目的を適宜振り、都度その実現度合いを確認するアクティビティとして整備しています。
「C)従来手法と同等の見積にしがち」に対しては作業の標準化とタスクを明確化し、各タスクの作業ボリュームを把握できるようにすることで見積りを行う方のために材料を提供しています。
「D)設計後どのようにして実装に結びつけるか路頭に迷う」に対しては設計後から実装までの手順を明確にした開発プロセスに加えて実装者の作業を効率化する設計アーキテクチャと統合開発環境を用意しています。

2.4 SDE開発方法論・開発基盤による対応概要

SDEでは、先の問題点に対して、開発方法論・開発基盤によりSOAシステム導入の本来の目的を見失わないような対応を講じています。開発方法論における対応としては、以下の3つがあります。

  1. 属人性を排除したサービス設計手順
    設計したサービスの性能を考えた場合の適切な実装方法やミドルウェアの選択、配置方法及び設定方法がわからず手探り状態となるケースです。
  2. 当初のシステム化目標を確実に実装につなげるアクティビティ・タスク構成
    SOAシステム導入の本来の目的を適宜振り返ってその実現度合いを確認する手順を規定しています。開発プロセスのアクティビティ・タスクとして定義しているため、設計者・実装者はそのアクティビティ・タスクに従って開発することで本来の目的を見失うことはありません。
  3. 開発プロセスをきちんと規定し、ロール及び作業の流れを明確化

開発基盤における対応としては、以下の2つがあります。

  1. 開発者の設計効率を向上する設計アーキテクチャを装備
  2. 設計からのシームレスなサービス実行を実現する統合開発ツールの提供

これらの仕組みにより、先の4つの問題点を解決しています。

2.5 SDEの設計粒度とサービスの対応関係

開発方法論で規定した機能粒度とサービス粒度の関係です。開発方法論では業務分析のための機能階層を4つ定義しています。最上位のレベル1は事業戦略を実現する単位で、例えば販売や生産といったシステム全体を現します。レベル2はビジネスの付加価値連鎖を表現します。サブシステムの単位に相当します。レベル3は組織の単位に相当します。業務主観部門の視点に立った業務フロー図をビジネス形態に対応したシナリオごとに作成します。このレベルでは、この業務フロー図からプロセスサービスを抽出することができます。レベル4は、作業者の単位です。利用者の視点に立った作業内容がレベル3の機能ごとに表現されます。このレベルでは業務フロー図中の機能から基本サービスを抽出することができます。ここでプロセスサービスとは、業務の流れを表現し、画面系とバッチ系の機能が含まれたフローを指します。業務フロー図との違いは、プロセスとしてステータス管理を行わない手作業は含みません。基本サービスとは、公開可能な単位のアプリケーションロジックであり、それ1つでビジネスとして成り立つ単位です。標準インタフェースをもち、データの授受はメッセージ経由で行われます。

SDEの設計粒度とサービスの対応関係

2.6 SOAシステムの設計アプローチ

SOAシステムではプロセスに従ってサービスが呼ばれます。そのため、アプリケーションとプラットフォームの関係は非常に重要でありそれぞれの設計内容が結合して動作するための設計手順として整備されています。アプリケーション開発としての開発手順と、プラットフォーム開発としての開発手順を粛々と進めることで実行時には、それぞれの成果物が結合され、動作するための開発方法論と開発基盤を提供しています。これにより、属人性を排除したサービス設計と、実際にシステムが稼動する際の動作が保証され、品質の高いシステム設計が可能となります。

2.7 SOAシステム開発上流分析手順

SDEのSOAシステムを開発する際の開発プロセスは従来の開発方法論をベースとし、そこにSOAシステム開発のタスクを追加しています。SOAシステム開発を行うためには、大きく分けて5つの設計タスクを実行します。

SDEのSOAシステム開発プロセス

  1. サービス候補抽出
    ここでは通常、業務視点で業務フロー図を作成します。SOAシステム開発では、そこでサービスの候補を抽出します。2.7.1にて詳細を説明します。
  2. メッセージ候補の抽出
    ここでいうメッセージとはサービスを呼び出すためのインタフェースであり、サービスが処理を実行するために必要なデータと処理結果データとなります。外部設計中の共通部品インタフェースを設計するタイミングでメッセージ候補を抽出します。ここでの詳細説明は省略いたします。
  3. 実装方式の決定
    標準化チームによりサービスの実装方式を決定します。開発プロセスとの関係を2.7.2にて、SDEで定義するSOAのシステムレイヤについては2.7.3で説明します。
  4. サービス・メッセージ設計
    抽出したサービス・メッセージの候補の中から実際に採用するものに対して設計を行います。採用に当たってはサービスの公開範囲や、レスポンスを加味することで、サービスにするかどうかの判断も行います。以下の2.7.4で詳細を説明します。
  5. サービス実装
    設計されたサービスを実装します。最終的なサービス化するタスク以外のビジネスロジック部分の実装手順は従来と変わりません。以下の業務フロー図から実行フローへの連携を2.7.5にて説明し、プレゼンテーション層に位置づくアプリケーションフロントエンド設計は2.7.6にて、実装ツールを2.7.7、2.7.8にて説明いたします。

2.7.1 サービスを抽出する

プロセスサービスを抽出するための指針として以下の相反する命題を解決する必要があります。プロセスサービス粒度を小さくする場合、システムの変更時に再ビルドする範囲を狭くすることができます。そのため変更の対応工数を極小化することができます。逆にプロセスサービス粒度を大きくした場合、プロセス中の各ノードの実行ステータスを管理する範囲を広く持つことができるため、例えばステータス管理用のログを広い範囲から収集できるようになります。

また、プロセスサービスの内容は、実装されるBPMプロセスダイアグラム上の記載変更のみでフローの分岐制御を変更することが可能となります。このような要件はプロジェクトによって様々に変化しますが、サービスを切り出すためのシステマティックな方法として、戦略ベースのトップダウン型とルールベースのボトムアップ型の2種類をご紹介します。

  1. 戦略ベース(トップダウン型)
    経営方針や組織論などからプロセスサービスを抽出します。2つの軸が存在します。1つ目は経営戦略軸として今後想定されるアウトソースの単位や組織改変の単位、対象業務がターゲットとするマーケットなどがサービスの単位となります。2つ目の軸はIT戦略軸です。モニタリングを行う単位やパッケージ化を行う単位をサービスの単位とします。
  2. ルールベース(ボトムアップ型)
    ルールベースは開発方法論で規定している手順に従ってサービスを機械的に抽出します。こちらも2つの軸があります。1つ目の業務軸では、まず、業務フロー図記載時にサプライチェーンとしてお客様に近い順に組織を配置します。その結果、起点の組織からプロセスを開始し自組織に戻ってくるまでの一連の流れをサービスの単位とすることができます。このときのプロセスは組織のレーンを跨り横V字となって表現されます。2つ目の軸は運用軸です。こちらはシステムの稼動停止を行う単位を切り出します。この際、保守性の観点から変化の起きやすいプロセスと起きにくいプロセスを分離しておくことが望ましいです。

2.7.2 開発プロセスとシステムレイヤとの対応関係

SDEの開発プロセスは、SDEで従来規定している各アクティビティで設計する内容と、SOAシステムレイヤを対応付けることで当初のシステム化目標を確実に実装につなげる方法論として整備しています。要件定義で設計する業務フロー図からはプロセスサービスを抽出・設計します。外部設計で設計するシステムフローからは基本サービスの抽出・設計と基本サービスを呼び出すためのメッセージを設計します。また、画面設計はアプリケーションフロントエンドの設計として従来どおり設計します。データベース設計についてはSOA化にあたっての特別なタスクは存在しませんが、分散配置したサービスが非同期でアクセスするため非正規化を行うことが必要な場合があります。

2.7.3 SDEのSOAシステムレイヤ

SDEでは、開発者の設計効率を向上する設計アーキテクチャを備えています。まず、SDEのSOAシステムレイヤについて紹介します。SDEによるSOA対応システムでは、以下の5つのシステムレイヤが存在します。

SDEのSOAシステムレイヤ

  • プレゼンテーション層
    ここは、従来の画面UIをあらわします。
  • プロセス層
    この層を新たに設けることにより、ビジネスロジックとは独立したビジネスプロセスを定義することが可能となります。これにより、ビジネスの変化に合わせて短期間に変更可能なビジネスプロセスを定義することが可能となります。
  • HUB製品層
    ここは、標準インタフェースのメッセージが行きかうESB(Enterprise Service Bus)製品等が担当するレイヤです。このレイヤを設けることで、差し替えが容易なサービスを結合することが可能となります。
  • サービス層
    ここはHUB製品との接続を実現する標準インタフェースのレイヤです。
  • アプリケーション層
    ここでは、実際のビジネスロジックのレイヤとなります。単独で業務を実現でき、公開可能な粒度で設計することで、ビジネスロジックの再利用を実現します。各サービスは、非同期処理を基本として設計することがポイントです。
  • データストア層
    ここでは、サービスの粒度に依存して、エンティティのグループ化が行われます。そうすることで、業務フロー図の変更に依存しないアーキテクチャを実現することが可能になります。

2.7.4 サービスを設計する

なぜサービスを切り出す必要があるかについて説明します。サービスを切り出すことでビジネスプロセス変更時の修正インパクトを極小化でき、且つまた、他プラットフォームとの連携性が向上します。

  1. 変更容易性
    変更にはプロセスの変更と機能の変更(データの変更含む)の大きく2つの観点があります。プロセスの変更例としては、受注金額に応じた承認ルートの変更や、製品梱包と納品伝票がそろったタイミングでの配送処理など業務的な作業内容の変更が発生した場合です。プロセスサービスを切り出すことで、業務の流れと機能を分離することが可能となるため、機能に影響を与えることなくプロセスの変更が可能となります。また、プロセスサービスの機能は標準的インタフェースと入力データの妥当性チェック機能を持っているため、機能の独立性を高め、機能修正がシステム全体に与える影響を極小化できます。この他にビジネスルールという観点も考えられます。ここではビジネスルール(例えば、コンプライアンス対応や、料金体系等)はそのルールの内容によりプロセスの変更や機能の変更として整理します。
  2. 接続容易性
    サービスはメッセージを介して呼び出されるため、例えばシステムのマイグレーションを実行する場合、異なるプラットフォーム上の機能を相互利用することが可能となります。

2.7.5 業務フローから実行フローへの連携

先ほどのアーキテクチャを実現するためには、ビジネスモデリングから実装用のアーキテクチャにシームレスに設計を連携する必要があります。業務視点で設計した業務フロー図と実際の実行上の実行フローを連携させることになります。SDEでは、業務視点での業務フロー設計は、ARISやiGrafx等のモデリングツールをベースとしたSDE上流基盤上で行います。設計に当たっては、先に説明したようなL1~L4までの設計階層を伴って設計し、業務フロー図のレベル(L3)を中心に実行フローへと連携します。ビジネスプロセスとしてモニタリングする業務のレベル(業務フロー図(L3,L4))や、組織や担当者が変わる業務単位、システムを再利用する単位を連携する単位と考えます。連携イメージとしては、以下の図のように、BPEL(Business Process Execution Language)等標準化されたファイル形式を介して実行ツール側と連携します。しかし、現時点では、標準化されたファイル仕様の対応状況がモデリングツール側と実装ツール側で違うケースもあり、上流で定義した全ての業務フロー図をそのまま連携することができない場合もあります。そのような場合には、手作業により実行フローを実行ツール上のエディタに入力することで連携を行います。事前にモデリングツール側とBPMサーバとの連携性を確認しておくことが1つのポイントとなります。

業務フローから実行フローへの連携

2.7.6 設計後どのようにして実装に結び付けるか路頭に迷う

次にアプリケーションフロントエンドの設計についてです。SOAシステムにおいてもサービスを呼び出す側の画面UIを持つアプリケーションの設計は必要となります。SDEでは、SOA対応システム開発において、プレゼンテーション層の画面UIを持ち、且つ、サービス本体以外のビジネスロジック(アプリケーション層)を伴ったアプリケーション部分をアプリケーションフロントエンドと称しています。アプリケーションフロントエンドの設計アーキテクチャにより、サービス呼出の開発や、サービス化といった変更を柔軟に行うことが可能となります。本手順は、従来システムの設計と変わらない手順で行うことができます。この設計アーキテクチャにより、設計者の設計効率を向上させることが可能となっています。

2.7.7 オーケストレーションデザイナ

実行フローとして各サービスを連携させるフロー図を描くエディタをオーケストレーションデザイナと称しています。特長としては、オーケストレーションデザイナは、Webサービスインタフェース(WSDL)によるパートナーとのサービス連携をワークフロー記述で定義したものです。メッセージの送受信や条件分岐、ループ処理、ドキュメント変換などのコンポーネントをマウスでドラッグ&ドロップし、それらの関係を図として構成していくことで、ビジネスプロセスをデザインできます。また、オーケストレーションデザイナは、モデリングツールとの連携機能も有しています。このことによりビジネスプロセス設計から、サービス構築、検証までシームレスな開発環境を提供します。オーケストレーションデザイナの詳細については、次回以降で詳しく紹介したいと思います。

2.7.8 ESB構築

各サービスが標準インタフェースにより接続されるESBがあります。ESBでは、さまざまなシステムのデータの違いを吸収する機能を有している必要があります。ほとんどのESB製品では、データ変換処理をGUIで設定することができます。たとえば、あるシステムでは「姓」と「名」を別々に登録。別システムでは、姓と名を統合して「名前」として管理していた場合は、システムに手を加えることなく、簡単にデータ変換処理を行うことができます。また、変換処理の時間など、もともとのデータには存在していなかったデータを付加する機能も有しています。

3.おわりに

以上のようにSDEは企業のビジネスモデリングから実装までの開発手順を提供することで、ビジネス変化へ柔軟に対応するシステム構築を実現し、お客様のビジネスの全体最適とさらに継続的な改善を行うお手伝いをいたします。今回は上流工程のバックエンド部分を中心とした開発手順のご紹介でしたが、この他にも下流工程の実装手順を示したものや、フロントエンド部分のシステム構築手順等含め、クラウド化への対応も着実に進めています。今後の展開にご注目ください。

なお、お客様がシステム構築やビジネス改善を検討する上で疑問点やご相談がありましたら、お気軽にご連絡をお願いします。お客様の現状をお伺いし、最適なご提案をさせていただきます。

関連URL

ページの先頭へ戻る