(57)【特許請求の範囲】
【請求項１】
業務を実現するためにサーバに実装する機能をサービスとし、サービスの実装によりサーバに実行させる処理を定義した実行フローの生成を支援する実行フロー生成プログラムにおいて、
コンピュータを、
サービス毎にスイムレーンを分けて業務の処理の手順が定義された業務プロセスが入力されると、前記業務プロセスをメモリに記憶すると共に、１つのサービスから他のサービスの同期呼び出しを行う第１の連携方式、直接の依存関係があるサービス間で非同期呼び出しを行う第２の連携方式、直接の依存関係があるサービス間でPublish/Subscribe方式で呼び出しを行う第３の連携方式、または直接の依存関係があるサービス間で同期呼び出しを行う第４の連携方式のいずれかを、呼び出し関係のあるサービスの組み合わせ毎に指定する操作入力に基づき、指定された連携方式を、サービス間での連携に適用する連携方式に決定する連携方式決定手段、
前記業務プロセスにおけるスイムレーンを跨って関係づけられた処理の間を入出力部とし、該入出力部に、他のサービスを呼び出す出力インタフェースと、他のサービスからの呼び出しを受け付ける入力インタフェースとを設定し、前記業務プロセス内の前記スイムレーン毎に、スイムレーンで示されるサービスに実行させる処理を定義する実行フローを初期状態で前記メモリ内に生成し、前記メモリ内の前記実行フローに対して、対応するスイムレーンで示された処理を設定すると共に、入出力部に関して前記連携方式決定手段で決定された連携方式による処理を設定する実行フロー生成手段、
として機能させ、
前記実行フロー生成手段は、
前記第１の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、呼び出し元となる一スイムレーンに対応する実行フローに対して、前記一スイムレーンを除く他のスイムレーンへのリクエスト送信を示す出力インタフェースに対応するメッセージ送信処理を設定し、前記一スイムレーン以外のスイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンへの前記一スイムレーンからのリクエスト受信を示す入力インタフェースに対応するメッセージ受信処理、および対応するスイムレーンから前記一スイムレーンへのレスポンス送信を示す出力インタフェースに対応するリプライ処理を設定し、
前記第２の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信とレスポンス送信とのそれぞれを示す出力インタフェースに対応するメッセージ送信処理を設定し、対応するスイムレーンへの他のスイムレーンからのリクエスト受信とレスポンス受信とのそれぞれを示す入力インタフェースに対応するメッセージ受信処理を設定し、
前記第３の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信とレスポンス送信とのそれぞれを示す出力インタフェースに対応するPublish/Subscribe方式によるメッセージ送信処理を設定し、対応するスイムレーンへの他のスイムレーンからのリクエスト受信とレスポンス受信とのそれぞれを示す入力インタフェースに対応するPublish/Subscribe方式によるメッセージ受信処理を設定し、
前記第４の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信を示す出力インタフェースに対応するメッセージ送信処理、対応するスイムレーンへの他のスイムレーンからのリクエスト受信を示す入力インタフェースに対応するメッセージ受信処理、および対応するスイムレーンから他のスイムレーンへのレスポンス送信を示す出力インタフェースに対応するリプライ処理を設定する、
ことを特徴とする実行フロー生成プログラム。
【請求項２】
前記連携方式決定手段は、操作入力による指定がないサービス間については、前記第２の連携方式を適用するものと決定することを特徴とする請求項１記載の実行フロー生成プログラム。
【請求項３】
業務を実現するためにサーバに実装する機能をサービスとし、サービスの実装によりサーバに実行させる処理を定義した実行フローの生成を支援する実行フロー生成方法において、
コンピュータが、
サービス毎にスイムレーンを分けて業務の処理の手順が定義された業務プロセスが入力されると、前記業務プロセスをメモリに記憶すると共に、１つのサービスから他のサービスの同期呼び出しを行う第１の連携方式、直接の依存関係があるサービス間で非同期呼び出しを行う第２の連携方式、直接の依存関係があるサービス間でPublish/Subscribe方式で呼び出しを行う第３の連携方式、または直接の依存関係があるサービス間で同期呼び出しを行う第４の連携方式のいずれかを、呼び出し関係のあるサービスの組み合わせ毎に指定する操作入力に基づき、指定された連携方式を、サービス間での連携に適用する連携方式に決定し、
前記業務プロセスにおけるスイムレーンを跨って関係づけられた処理の間を入出力部とし、該入出力部に、他のサービスを呼び出す出力インタフェースと、他のサービスからの呼び出しを受け付ける入力インタフェースとを設定し、前記業務プロセス内の前記スイムレーン毎に、スイムレーンで示されるサービスに実行させる処理を定義する実行フローを初期状態で前記メモリ内に生成し、前記メモリ内の前記実行フローに対して、対応するスイムレーンで示された処理を設定すると共に、入出力部に関して決定された連携方式による処理を設定すると共に、
前記スイムレーンを跨った入出力に関して決定された連携方式に基づき、
前記第１の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、呼び出し元となる一スイムレーンに対応する実行フローに対して、前記一スイムレーンを除く他のスイムレーンへのリクエスト送信を示す出力インタフェースに対応するメッセージ送信処理を設定し、前記一スイムレーン以外のスイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンへの前記一スイムレーンからのリクエスト受信を示す入力インタフェースに対応するメッセージ受信処理、および対応するスイムレーンから前記一スイムレーンへのレスポンス送信を示す出力インタフェースに対応するリプライ処理を設定し、
前記第２の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信とレスポンス送信とのそれぞれを示す出力インタフェースに対応するメッセージ送信処理を設定し、対応するスイムレーンへの他のスイムレーンからのリクエスト受信とレスポンス受信とのそれぞれを示す入力インタフェースに対応するメッセージ受信処理を設定し、
前記第３の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信とレスポンス送信とのそれぞれを示す出力インタフェースに対応するPublish/Subscribe方式によるメッセージ送信処理を設定し、対応するスイムレーンへの他のスイムレーンからのリクエスト受信とレスポンス受信とのそれぞれを示す入力インタフェースに対応するPublish/Subscribe方式によるメッセージ受信処理を設定し、
前記第４の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信を示す出力インタフェースに対応するメッセージ送信処理、対応するスイムレーンへの他のスイムレーンからのリクエスト受信を示す入力インタフェースに対応するメッセージ受信処理、および対応するスイムレーンから他のスイムレーンへのレスポンス送信を示す出力インタフェースに対応するリプライ処理を設定する、
ことを特徴とする実行フロー生成方法。
【請求項４】
連携方式を決定する際には、操作入力による指定がないサービス間については、前記第２の連携方式を適用するものと決定することを特徴とする請求項３記載の実行フロー生成方法。
【請求項５】
業務を実現するためにサーバに実装する機能をサービスとし、サービスの実装によりサーバに実行させる処理を定義した実行フローの生成を支援する実行フロー生成装置において、
サービス毎にスイムレーンを分けて業務の処理の手順が定義された業務プロセスが入力されると、前記業務プロセスをメモリに記憶すると共に、１つのサービスから他のサービスの同期呼び出しを行う第１の連携方式、直接の依存関係があるサービス間で非同期呼び出しを行う第２の連携方式、直接の依存関係があるサービス間でPublish/Subscribe方式で呼び出しを行う第３の連携方式、または直接の依存関係があるサービス間で同期呼び出しを行う第４の連携方式のいずれかを、呼び出し関係のあるサービスの組み合わせ毎に指定する操作入力に基づき、指定された連携方式を、サービス間での連携に適用する連携方式に決定する連携方式決定手段と、
前記業務プロセスにおけるスイムレーンを跨って関係づけられた処理の間を入出力部とし、該入出力部に、他のサービスを呼び出す出力インタフェースと、他のサービスからの呼び出しを受け付ける入力インタフェースとを設定し、前記業務プロセス内の前記スイムレーン毎に、スイムレーンで示されるサービスに実行させる処理を定義する実行フローを初期状態で前記メモリ内に生成し、前記メモリ内の前記実行フローに対して、対応するスイムレーンで示された処理を設定すると共に、入出力部に関して前記連携方式決定手段で決定された連携方式による処理を設定する実行フロー生成手段と、
を有し、
前記実行フロー生成手段は、
前記第１の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、呼び出し元となる一スイムレーンに対応する実行フローに対して、前記一スイムレーンを除く他のスイムレーンへのリクエスト送信を示す出力インタフェースに対応するメッセージ送信処理を設定し、前記一スイムレーン以外のスイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンへの前記一スイムレーンからのリクエスト受信を示す入力インタフェースに対応するメッセージ受信処理、および対応するスイムレーンから前記一スイムレーンへのレスポンス送信を示す出力インタフェースに対応するリプライ処理を設定し、
前記第２の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信とレスポンス送信とのそれぞれを示す出力インタフェースに対応するメッセージ送信処理を設定し、対応するスイムレーンへの他のスイムレーンからのリクエスト受信とレスポンス受信とのそれぞれを示す入力インタフェースに対応するメッセージ受信処理を設定し、
前記第３の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信とレスポンス送信とのそれぞれを示す出力インタフェースに対応するPublish/Subscribe方式によるメッセージ送信処理を設定し、対応するスイムレーンへの他のスイムレーンからのリクエスト受信とレスポンス受信とのそれぞれを示す入力インタフェースに対応するPublish/Subscribe方式によるメッセージ受信処理を設定し、
前記第４の連携方式が適用されるサービスの組み合わせそれぞれに対応するスイムレーン間の入出力部に関し、スイムレーンそれぞれに対応する実行フローに対して、対応するスイムレーンから他のスイムレーンへのリクエスト送信を示す出力インタフェースに対応するメッセージ送信処理、対応するスイムレーンへの他のスイムレーンからのリクエスト受信を示す入力インタフェースに対応するメッセージ受信処理、および対応するスイムレーンから他のスイムレーンへのレスポンス送信を示す出力インタフェースに対応するリプライ処理を設定する、
ことを特徴とする実行フロー生成装置。
【請求項６】
前記連携方式決定手段は、操作入力による指定がないサービス間については、前記第２の連携方式を適用するものと決定することを特徴とする請求項５記載の実行フロー生成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は実行フロー生成プログラム、実行フロー生成方法、および実行フロー生成装置に関する。
【背景技術】
【０００２】
現在、業務システムをサービス間の連携で実現する手法として、ＳＯＡ（Service Oriented Architecture）というアプリケーション構築手法が注目されている。この手法では、業務を実現するために、業務的に意味のある機能をサービスとして定義する。そして、複数のサービスを連携させて業務システムを構築する。
【０００３】
業務全体の流れを記述したものは、業務プロセスと呼ばれる。業務を実行するための機能をコンピュータシステムに実装する場合、まず、業務プロセスが作成される。そして、作成された業務プロセスに基づいて、実行フローが作成される。
【０００４】
実行フローには、業務内の一部の作業をサーバに実行させるための処理内容が記述されている。作成した実行フローをサーバにデプロイすると、そのサーバは、実行フローに従ったサービス提供が可能となる。
【０００５】
従来、業務プロセスから実行フローを自動的に作成するための、様々な技術が考えられている。例えば、ビジネスプロセス定義を表すビジネスプロセス定義スクリプトに基づいて、マルチスレッドで並列処理可能なプログラムを生成する技術が考えられている（例えば、特許文献１参照）。
【特許文献１】特開２００１−９２６４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、複数のサーバで構築されたネットワークシステムで業務を実行させる場合、サーバ間の連携を取った実行フローを作成する必要があり、そのような実行フローを、業務プロセスから自動で作成するのは難しかった。
【０００７】
分散型のシステムに対する実行フローの作成が困難な理由の１つとして、業務プロセスの作成者が、実行フローを実装するための知識を十分に有していないことが上げられる。すなわち、業務プロセスの作成者が、システム実装時に必要な技術を理解していないことにより、サービス実装の自動化を困難にしていた。具体的には、業務プロセスの作成者の認識と、実際にサービス実装に必要な知識との間で、大きく以下の３点のギャップが存在する。
【０００８】
・第１の相違点（視点の違い）
業務プロセスは、全てのシステムから独立した、第三者視点でのフローとなる。一方、実行フローは、サービス提供の主体となるシステム（サーバ）から、他の直接連携するサービスの呼び出し方法等を指定する必要がある。すなわち、実行フローを作成するには、連携相手が明確である必要があり、連携相手が不明瞭であれば、業務プロセスに基づいて実行フローの自動作成が困難となる。
【０００９】
・第２の相違点（連携方式の有無）
業務プロセスは、処理の順序を指定するのみで、システム間がどのように連携するかを規定しない。一方、実行フローは、連携先サービスとのインタフェースや、同期連携とするか非同期連携とするかが明確でなければならない。
【００１０】
・第３の相違点（非同期の扱い）
業務プロセスの場合、基本的には処理の流れがシーケンシャルに書かれるため、非同期通信は意識されない。一方、実行フローでは、連携先が同期通信を行うのか、非同期通信を行うのかによって、リクエストとレスポンスの関連の定義、返り値を受け取るインタフェースの用意等が必要となる。
【００１１】
以上のようなシステム設計上の考え方のギャップにより、業務プロセスから自動的に実行フローを生成しても、処理の安定性や処理効率等の観点から、最適なシステム構成とすることができなかった。
【００１２】
なお、従来、ＥＡＩ（Enterprise Application Integration）に代表されるようなワークフローシステムを用いたシステム統合の手法がある。ところが、通常ワークフローで記述された業務は、部分的に他の業務から共有するといったことが難しい。
【００１３】
また、従来のＷｅｂサービス同士を連携させる手法として、ＢＰＥＬ（Business Process Execution Language）などのフロー記述言語がある。このようなフロー記述言語では、各サービスから連携先を呼び出す形で連携させるのが一般的である。ただし、各サービスの実装時に、連携する処理や連携先の指定等を行う作業が必要となる。また、全体をフローエンジンで管理するのか、ＲＰＣ（Remote Procedure Call）方式で連携させるのか、Messagingで連携させるのかによって、サービス実装の大きさや連携処理等を手作業で調整していく必要があった。
【００１４】
本発明はこのような点に鑑みてなされたものであり、業務プロセスに応じたサービスを複数のサーバで連携処理させるための実行フローを自動的に生成することができる実行フロー生成プログラム、実行フロー生成方法、および実行フロー生成装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明では上記課題を解決するために、図１に示すようなサービス実装支援プログラムが提供される。本発明に係るサービス実装支援プログラムは、業務内容に応じたサービスの提供機能のコンピュータシステムへの実装を支援するために、図１のサービス実装支援装置１が有する機能をコンピュータに実行させることができる。
【００１６】
連携方式決定手段１ａは、サービスの提供機能毎にスイムレーンを分けて業務の手順が定義された業務プロセス３が入力されると、業務プロセス３をメモリに記憶すると共に、スイムレーン間での連携に適用する連携方式を決定する。実行フロー生成手段１ｂは、業務プロセス３内のスイムレーン毎に、スイムレーンで示されるサービスに対応する実行フロー４ａ，４ｂ，４ｃを初期状態でメモリ内に生成し、メモリ内の実行フロー４ａ，４ｂ，４ｃに対して、対応するスイムレーンで示された処理内容を設定すると共に、スイムレーンを跨った入出力に関して連携方式決定手段１ａで決定された連携方式による処理内容を設定する。
【００１７】
このようなサービス実装支援プログラムをコンピュータに実行させることにより、業務プロセス３が入力されると、連携方式決定手段１ａにより、業務プロセス３がメモリに記憶されると共に、スイムレーン間での連携に適用する連携方式が決定される。そして、実行フロー生成手段１ｂにより、業務プロセス３内のスイムレーン毎に、スイムレーンで示されるサービスに対応する実行フロー４ａ，４ｂ，４ｃが初期状態でメモリ内に生成され、メモリ内の実行フロー４ａ，４ｂ，４ｃに対して、対応するスイムレーン内に設定された処理内容が設定されると共に、スイムレーンを跨った入出力に関して連携方式決定手段１ａで決定された連携方式による処理内容が設定される。
【発明の効果】
【００１８】
本発明では、サービスの機能に対応するスイムレーン毎に実行フローを生成し、スイムレーンを跨った入出力に関して、決定された連携方式に応じた連携処理を実行フロー内に設定するようにした。そのため、機能毎に個別の実行フローが生成できると共に、入力側の連携方式と出力側の連携方式とが統一され、実行フローを実装したサーバは、互いに正しく連携処理を行うことができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態を図面を参照して説明する。
図１は、本実施の形態の概略を示す図である。サービス実装支援装置１は、業務プロセス３に基づいて、サーバ２ａ，２ｂ，２ｃ毎の実行フロー４ａ，４ｂ，４ｃを作成するために、連携方式決定手段１ａ、実行フロー生成手段１ｂ、およびサービス実装手段１ｃを有している。なお、業務プロセス３は、サービスの提供機能毎にスイムレーンを分けて業務の手順が定義されている。
【００２０】
連携方式決定手段１ａは、業務プロセス３が入力されると、業務プロセス３をメモリに記憶する。そして、連携方式決定手段１ａは、スイムレーン間での連携に適用する連携方式を決定する。例えば、連携方式決定手段１ａは、サービス間で同期通信を行う連携方式と、非同期通信を行う連携方式との中から、適用する連携方式を決定する。または、連携方式決定手段１ａは、１つのサービスが他のサービスを集中管理する集中管理方式と、業務プロセス上で直接関連しているサービス間でのみ連携処理を行うサービス分割方式との中から、適用する連携方式を決定する。
【００２１】
実行フロー生成手段１ｂは、業務プロセス３内のスイムレーン毎に、スイムレーンで示されるサービスに対応する実行フロー４ａ，４ｂ，４ｃを初期状態でメモリ内に生成する。そして、実行フロー生成手段１ｂは、メモリ内の実行フロー４ａ，４ｂ，４ｃに対して、対応するスイムレーンで示された処理内容を設定すると共に、スイムレーンを跨った入出力に関して連携方式決定手段１ａで決定された連携方式による処理内容を設定する。
【００２２】
サービス実装手段１ｃは、実行フロー生成手段１ｂで生成された実行フロー４ａ，４ｂ，４ｃを、それぞれのサーバ２ａ，２ｂ，２ｃに実装する。
このようなサービス実装支援装置１によれば、業務プロセス３が入力されると、連携方式決定手段１ａにより、業務プロセス３がメモリに記憶される共に、スイムレーン間での連携に適用する連携方式が決定される。そして、実行フロー生成手段１ｂにより、業務プロセス３内のスイムレーン毎に、スイムレーンで示されるサービスに対応する実行フロー４ａ，４ｂ，４ｃが初期状態でメモリ内に生成される。さらに、実行フロー生成手段１ｂにより、メモリ内の実行フロー４ａ，４ｂ，４ｃに対して、対応するスイムレーン内に設定された処理内容、および他のスイムレーンで示されるサービスとの間の連携部分における連携方式決定手段１ａで決定された連携方式による処理内容が設定される。そして、生成された実行フロー４ａ，４ｂ，４ｃが、サービス実装手段１ｃによってサーバ２ａ，２ｂ，２ｃに実装される。
【００２３】
これにより、機能毎に個別の実行フロー４ａ，４ｂ，４ｃが自動で生成できると共に、入力側の連携方式と出力側の連携方式とが統一され、実行フローを実装したサーバ２ａ，２ｂ，２ｃは、互いに正しく連携処理を行うことができる。
【００２４】
なお、連携方式決定手段１ａは、システム管理者からの操作入力によって、適用する連携方式を決定することができる。また、システム管理者からの操作入力による指示が無い場合に適用すべき連携方式を予め定めておき、連携方式決定手段１ａは、操作入力による指定が無い場合には、予め定められた連携方式を適用することができる。また、連携方式決定手段１ａは、直接関連するサービスの組み合わせ毎に、適用する連携方式を個別に決定することもできる。
【００２５】
次に、本実施の形態の詳細を説明する。
図２は、本実施の形態のシステム構成例を示す図である。システム管理サーバ１００は、ネットワーク１０を介して、クライアント２１，２２，・・・やサーバ３１，３２，３３に接続されている。
【００２６】
クライアント２１，２２，・・・は、サーバ３１，３２，３３で提供されるサービスの利用者が使用するコンピュータである。サーバ３１，３２，３３は、一連の業務プロセスを実現するためのサービスを実行するコンピュータである。サーバ３１，３２，３３は、互いに連携してサービスを実行することで、１つの業務を完遂することができる。
【００２７】
システム管理サーバ１００は、サーバ３１，３２，３３に対して実行フローを実装するためのコンピュータである。システム管理サーバ１００は、システム管理者からの操作入力によって業務プロセスが作成されると、その業務プロセスをサーバ３１，３２，３３で実現するためのサーバ３１，３２，３３毎の実行フローを生成する。そして、システム管理サーバ１００が、各サーバ３１，３２，３３に対して実行フローを設定することで、各サーバ３１，３２，３３は、設定された実行フローに従ったサービスが実行可能となる。
【００２８】
図３は、本実施の形態に用いるシステム管理サーバのハードウェア構成例を示す図である。システム管理サーバ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。
【００２９】
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。
【００３０】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令にしたがって、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。
【００３１】
通信インタフェース１０６は、ネットワーク１０に接続されている。通信インタフェース１０６は、ネットワーク１０を介して、他のコンピュータとの間でデータの送受信を行う。
【００３２】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、システム管理サーバ１００のハードウェア構成例を示したが、クライアント２１，２２，・・・やサーバ３１，３２，３３も同様のハードウェア構成で実現することができる。
【００３３】
図４は、システム管理サーバの機能を示すブロック図である。システム管理サーバ１００は、業務プロセス作成部１１０とサービス実装支援部１２０とを有している。
業務プロセス作成部１１０は、システム管理者からの操作入力に応じて、業務プロセスを作成する。業務プロセスは、業務で行われる作業の流れを図で表したものである。作成された業務プロセスは、ＲＡＭ１０２に格納される。その後、業務プロセス作成部１１０は、作成した業務プロセスをサービス実装支援部１２０に入力する。
【００３４】
サービス実装支援部１２０は、入力された業務プロセスに応じて、実行フローを生成する。生成される実行フローは、ネットワーク１０経由でサーバ３１，３２，３３に送られる。このような機能を実現するために、サービス実装支援部１２０は、連携方式決定部１２１、第１の実行フロー生成部１２２，第２の実行フロー生成部１２３、第３の実行フロー生成部１２４、第４の実行フロー生成部１２５、およびサービス実装部１２６を有している。
【００３５】
連携方式決定部１２１は、入力された業務プロセスに基づいて、サービス間の連携方式を決定する。本実施の形態では、連携方式として「集中管理方式」、「サービス分割Messaging方式」、「サービス分割Pub/Sub方式」、「サービス分割ＲＰＣ方式」が用意されている。
【００３６】
「集中管理方式」は、全てのサービスを１箇所のサービスからＲＰＣ方式で順次呼び出す連携方式である。この連携方式は、全体的な流れの変更が多い場合に有効である。ただし、サービスの再利用性が低くなり、通信の信頼性も劣っている。
【００３７】
「サービス分割Messaging方式」は、直接依存するサービスのみ、Messaging方式（非同期）で呼び出す連携方式である。この連携方式は、部分的なサービスを、他の業務でも供給する場合に有効である。なお、本実施の形態では、任意の指定が無い場合、連携方式が「サービス分割Messaging方式」に決定される。
【００３８】
「サービス分割Pub/Sub方式」は、直接依存するサービスのみ、Publish/Subscribe（Pub/Sub）方式で呼び出す連携方式である。Pub/Sub方式では、送信側のサービスが、予めサブスクライブ（購読）の意思表示を示した全てのサービスに対してのみメッセージを送信する。この連携方式は、１対複数の関係で連携する場合や、送信先が動的に変わる場合などに有効である。ただし、送信側において、受信側を制御できないという不便さがある。
【００３９】
「サービス分割ＲＰＣ方式」は、直接依存するサービスのみをＲＰＣ方式で呼び出す連携方式である。この連携方式は、リアルタイム性が必要な場合、Messagingが必要無い場合に有効である。ただし、呼び出し元のサービスにおいて、呼び出し先の処理の処理待ちが必要となる。
【００４０】
適用する連携方式ついては、それぞれのメリット、デメリットを加味して判断される。
連携方式決定部１２１は、例えば、システム管理者によって指定された連携方式を、入力された業務プロセスの連携方式として決定する。連携方式は、サービス間での連携処理毎に個別に設定することができる。例えば、「serviceA」、「serviceB」、および「serviceC」を生成する場合、「serviceA」と「serviceB」との間の連携方式、「serviceB」と「serviceC」との間の連携方式を、それぞれ異なる連携方式とすることができる。
【００４１】
また、連携方式決定部１２１は、業務プロセスの内容を解析し、最適な連携方式を自動的に決定することもできる。例えば、連携方式決定部１２１は、リプライの存在するサービスが別のサービスを呼び出す場合の連携方式は、「サービス分割ＲＰＣ方式」を採用し、それ以外は、「サービス分割Messaging方式」を採用する。
【００４２】
第１の実行フロー生成部１２２は、入力された業務プロセスに基づいて、集中管理方式（第１の連携方式）による実行フローの生成処理を行う。
第２の実行フロー生成部１２３は、入力された業務プロセスに基づいて、サービス分割Messaging方式（第２の連携方式）によるサービス定義の生成処理を行う。
【００４３】
第３の実行フロー生成部１２４は、入力された業務プロセスに基づいて、サービス分割Pub/Sub方式（第３の連携方式）によるサービス定義の生成処理を行う。
第４の実行フロー生成部１２５は、入力された業務プロセスに基づいて、サービス分割ＲＰＣ方式（第４の連携方式）によるサービス定義の生成処理を行う。
【００４４】
これらの、第１〜４の実行フロー生成部１２２，１２３，１２４，１２５は、以前に作成した実行フローを管理しておくことができる。そして、第１〜４の実行フロー生成部１２２，１２３，１２４，１２５は、実行フローの作成時、既存の再利用可能なサービスがあった場合に、これを１レーンとして取り込み、取り込んだレーンに関しては実行フローを作成しないことが可能である。その場合、第１〜４の実行フロー生成部１２２，１２３，１２４，１２５は、生成した実行フローには、既存の実行フローを連携相手として設定する。これにより、既存サービスの取り込みが容易となる。
【００４５】
また、第１〜４の実行フロー生成部１２２，１２３，１２４，１２５は、実行フローの設計時、各スイムレーンのプロパティに、デプロイ先のサーバ種別、マシン名、ＵＲＬ（Uniform Resource Locator）を指定しておく。これらの情報を元に、生成した実行フローを自動的に実装し、実行可能な状態にすることができる。
【００４６】
なお、第１〜４の実行フロー生成部１２２，１２３，１２４，１２５は、実行フローを生成する際には、まず、初期状態（必要なスイムレーンと開始ノードなどが設定されている）の実行フローをＲＡＭ１０２内に作成する。そして、第１〜４の実行フロー生成部１２２，１２３，１２４，１２５は、初期状態の実行フローに対して、処理内容を示す要素を設定していくことで、実行フローを完成させる。
【００４７】
サービス実装部１２６は、生成された実行フローを、サーバ３１，３２，３３にデプロイする。ここで、デプロイとは、実行フローを用いて、サーバに対してサービスの提供機能を実装する処理である。具体的には、サービス実装部１２６は、実行フローをサーバに転送し、そのサーバに対して、実行フローに従ったサービスを実行するために必要な設定（例えば、連携相手のアドレス設定等）を遠隔で実施する。すると、デプロイの対象となったサーバにおいて、実行フローに従ったサービスが提供される。
【００４８】
以上のような構成のシステムにおいて、システム管理者が業務プロセス作成部１１０を用いて、業務プロセスを作成する。そして、システム管理者が、作成した業務プロセスに応じたサービス実装指示をシステム管理サーバ１００に対して行うと、作成された業務プロセスがサービス実装支援部１２０に入力される。
【００４９】
サービス実装支援部１２０では、入力された業務プロセスが、連携方式決定部１２１に渡される。すると、連携方式決定部１２１において連携方式が決定される。そして、連携方式決定部１２１により、決定された連携方式に対応する実行フロー生成部に対して、業務プロセスが入力される。
【００５０】
例えば、第１の実行フロー生成部１２２に業務プロセスが入力されると、第１の実行フロー生成部１２２により、集中管理方式でサービス間の連携を行う実行フローが生成される。第２の実行フロー生成部１２３に業務プロセスが入力されると、第２の実行フロー生成部１２３により、サービス分割Messaging方式でサービス間の連携を行う実行フローが生成される。第３の実行フロー生成部１２４に業務プロセスが入力されると、第３の実行フロー生成部１２４により、サービス分割Pub/Sub方式でサービス間の連携を行う実行フローが生成される。第４の実行フロー生成部１２５に業務プロセスが入力されると、第４の実行フロー生成部１２５により、サービス分割ＲＰＣ方式でサービス間の連携を行う実行フローが生成される。
【００５１】
生成された実行フローは、サービス実装部１２６に渡される。すると、サービス実装部１２６によって、実行フローがサーバにデプロイされる。
次に、各連携方式を実現するための実行フローの生成方法について、詳細に説明する。
【００５２】
［第１の連携方式］
まず、「集中管理方式」について説明する。集中管理方式は、１箇所のサービスから他のサービスをＲＰＣ方式で順次呼び出すことで、サービス間で連携するものである。
【００５３】
図５は、集中管理方式によるサービスの呼び出し関係を示す図である。図５の例では、集中管理サービス４１が、他のサービス４２，４３を集中管理している。管理される側のサービス４２，４３は、常に集中管理サービス４１から呼び出される。ここで、集中管理サービス４１の名称を「ServiceA」、サービス４２の名称を「ServiceB」、サービス４３の名称を「ServiceC」とする。
【００５４】
図６は、集中管理方式によるメッセージの送受信状況を示す図である。この例では、クライアント２１上で動作するユーザプロセスの名称を「Consumer」としている。また、「ServiceA」はサーバ３１上で実行され、「ServiceB」はサーバ３２上で実行され、「ServiceC」はサーバ３３上で実行されているものとする。
【００５５】
集中管理方式では、集中管理サービス４１である「ServiceA」に対して、クライアント２１のユーザプロセスからリクエスト（1:request()）が出される。すると、サーバ３１では、「ServiceA」による処理が開始される。そして、「ServiceB」との連携処理が発生すると、サーバ３１からサーバ３２に対して、リクエスト（1.1:request()）が出される。サーバ３２では、「ServiceB」による処理が実行され、レスポンスがサーバ３１の「ServiceA」に返される。
【００５６】
次に、サーバ３１では、「ServiceA」による処理中に「ServiceC」との連携処理が発生すると、サーバ３１からサーバ３３に対して、リクエスト（1.2:request()）が出される。サーバ３３では、「ServiceC」による処理が実行され、レスポンスがサーバ３１の「ServiceA」に返される。
【００５７】
その後、「ServiceA」による処理中に再度「ServiceB」との連携処理が発生すると、サーバ３１からサーバ３２に対して、リクエスト（1.3:request()）が出される。サーバ３２では、「ServiceB」による処理が実行され、レスポンスがサーバ３１の「ServiceA」に返される。
【００５８】
このように、集中管理方式でサービスを連携させることで、業務プロセスに従ったサービスを実行できる。このような連携方式は、手順の変更が頻繁に発生する際に有効である。すなわち、サービスの連携は、すべて集中管理サービス４１からのリクエストに基づいて行われるため、集中管理サービス４１の処理手順を示す実行フローにおけるリクエストの発行順を変更すれば、他のサービス４２，４３でのサービスの処理順を変更できる。
【００５９】
次に、集中管理方式によって連携するサービス実行フローの生成方法について説明する。
図７は、集中管理方式の実行フロー生成手順を示すフローチャートである。以下、図７に示す処理をステップ番号に沿って説明する。
【００６０】
［ステップＳ１１］第１の実行フロー生成部１２２は、スイムレーンをすべて展開する。スイムレーンの展開とは、業務プロセスに設けられたスイムレーン内の処理ブロック（Action）に対して、入力と出力とのインタフェースを追加する処理である。
【００６１】
このとき、第１の実行フロー生成部１２２は、業務プロセスの開始ノードを含むスイムレーンを管理元とする。また、第１の実行フロー生成部１２２は、集中管理サービス用の実行フローを生成する。この実行フローには、業務プロセスの各スイムレーンに対応するスイムレーンが設けられている。実行フローのスイムレーンのうち、業務プロセス内で開始ノードを含むスイムレーンに対応するものを、「internal」（管理元の内部サービスを示す）のスイムレーンとする。
【００６２】
［ステップＳ１２］第１の実行フロー生成部１２２は、業務プロセスのアクティビティ（業務プロセスに定義されたノード）を、処理の先頭から順に辿る。すなわち、第１の実行フロー生成部１２２は、開始ノードに接続されたアクティビティを最初に選択する。その後、ステップＳ１２の処理が実行される度に、前回選択したアクティビティの遷移先となるアクティビティを選択する。
【００６３】
［ステップＳ１３］第１の実行フロー生成部１２２は、管理元のスイムレーンか否かを判断する。すなわち、現在の管理元のスイムレーン内での遷移なのか、別のスイムレーンへの遷移なのかが判断される。遷移先が管理元のスイムレーンの場合、処理がステップＳ１４に進められる。遷移先が管理元とは別のスイムレーンの場合、処理がステップＳ１８に進められる。
【００６４】
［ステップＳ１４］第１の実行フロー生成部１２２は、選択したアクティビティの動作種別を判断する。動作種別には、「処理」、「入力」、「出力」、「終了」がある。動作種別が「処理」の場合、処理がステップＳ１５に進められる。動作種別が「入力」の場合、処理がステップＳ１６に進められる。動作種別が「出力」の場合、処理がステップＳ１７に進められる。動作種別が「終了」の場合、処理が終了する。
【００６５】
［ステップＳ１５］第１の実行フロー生成部１２２は、動作種別が「処理」の場合、管理元のスイムレーンに対応する実行フロー内の「internal」のスイムレーンに、invokeのノードを配置する。この際、選択したアクティビティの遷移元に、開始ノードから遷移する「入力」のアクティビティがある場合、アクティビティに対応するreceiveのノードを、invokeのノードの遷移元となる位置に配置する。その後、処理がステップＳ１２に進められる。
【００６６】
［ステップＳ１６］第１の実行フロー生成部１２２は、選択したアクティビティの動作種別が「入力」の場合、実行フローに対する操作を行わず、処理をステップＳ１２に進める。
【００６７】
［ステップＳ１７］第１の実行フロー生成部１２２は、選択したアクティビティの動作種別が「出力」の場合、管理元のスイムレーンに対応する実行フロー内の出力データの送信先のスイムレーンにinvokeのノードを配置する。その後、処理がステップＳ１２に進められる。なお、選択したアクティビティの次の遷移先が終了ノードの場合、実行フローに対する処理は行われない。
【００６８】
［ステップＳ１８］遷移先が別のスイムレーンの場合、第１の実行フロー生成部１２２は、選択したアクティビティの動作種別を判断する。動作種別が「処理」の場合、処理がステップＳ１９に進められる。動作種別が「入力」の場合、処理がステップＳ２０に進められる。動作種別が「出力」の場合、処理がステップＳ２１に進められる。動作種別が「終了」の場合、処理が終了する。
【００６９】
［ステップＳ１９］第１の実行フロー生成部１２２は、遷移先のスイムレーンに対応する実行フロー内の「internal」のスイムレーンに、invokeのノードを配置する。この際、選択したアクティビティの遷移元に「入力」のアクティビティがある場合、アクティビティに対応するreceiveのノードを、invokeのノードの遷移元となる位置に配置する。その後、処理がステップＳ１２に進められる。
【００７０】
［ステップＳ２０］第１の実行フロー生成部１２２は、遷移先のスイムレーンに対応する実行フローを作成し、その実行フロー内にreceiveのノードを配置する。その後、処理がステップＳ１２に進められる。
【００７１】
［ステップＳ２１］第１の実行フロー生成部１２２は、遷移先のスイムレーンに対応する実行フロー内にreplyのノードを作成する。第１の実行フロー生成部１２２は、さらに、集中管理を行うサービスの実行フロー内の送信先となるスイムレーンにinvokeを配置する。その後、処理がステップＳ１２に進められる。
【００７２】
次に、集中管理方式によって連携する実行フローの生成手順を、具体例を用いて説明する。なお、以下の説明において、業務プロセスおよび実行フロー中の実線の矢印はアクティビティの遷移を示しており、破線の矢印はデータの受け渡しを示している。
【００７３】
図８は、業務プロセスの例を示す図である。業務プロセス５０には、複数のスイムレーン５０ａ，５０ｂ，５０ｃが設けられている。各スイムレーンは、業務を実現するために必要な機能毎に処理を分けたものである。例えば、Ｗｅｂ技術を用いた業務であれば、スイムレーン５０ａがＷｅｂサーバ機能に対応し、スイムレーン５０ｂがアプリケーションサーバ機能に対応し、スイムレーン５０ｃがデータベースサーバ機能に対応する。
【００７４】
ここで、スイムレーン５０ａに対応するサービスを「serviceA」とする。また、スイムレーン５０ｂに対応するサービスを「serviceB」とする。さらに、スイムレーン５０ｃに対応するサービスを「serviceC」とする。
【００７５】
業務プロセス５０内には、開始ノード５１から終了ノード５７まで、アクティビティを示すノード５２〜５６の遷移が示されている。なお、ノード５２，５６は、スイムレーン５０ａに対応する機能で実行されるアクティビティを示している。また、ノード５３，５５は、スイムレーン５０ｂに対応する機能で実行されるアクティビティを示している。さらに、ノード５４は、スイムレーン５０ｃに対応する機能で実行されるアクティビティを示している。
【００７６】
図８に示すような業務プロセス５０が作成された場合、まず業務プロセス５０の展開処理が行われる。展開処理では、入力された業務プロセス５０に対して、インタフェース情報が付加される。具体的には、スイムレーンを跨る箇所について、入出力を想定したインタフェースが付加される。
【００７７】
図９は、展開済の業務プロセスを示す図である。業務プロセス５０を展開する場合、まず、スイムレーンをサービスの切れ目とする。そして、第１の実行フロー生成部１２２は、開始ノード５１の遷移先に入力処理のアクティビティ（入力インタフェース）を示すノード６１を追加し、終了ノード５７の遷移元に出力処理のアクティビティ（出力インタフェース）を示すノード７０を追加する。
【００７８】
さらに、第１の実行フロー生成部１２２は、スイムレーンを跨る箇所について、メッセージの送信（出力）と受信（入力）とのアクティビティ（送受信インタフェース）を示すノード６２〜６９を付加する。この際、システム管理者からの操作入力に応じて、送受信インタフェースやメッセージ形式を修正することができる。また、第１の実行フロー生成部１２２は、入力または出力されるデータ７１〜７６を追加する。
【００７９】
このようにして、業務プロセス５０が展開され、展開済業務プロセス６０が生成される。展開処理後、集中管理を行う「serviceA」に対応する実行フローが生成される。
図１０は、生成直後の「serviceA」の実行フローを示す図である。生成された実行フロー２１０には、展開済業務プロセス６０に設けられたスイムレーン５０ａ，５０ｂ，５０ｃそれぞれに対応するスイムレーン２１０ａ，２１０ｂ，２１０ｃが設けられている。ここで、展開済業務プロセス６０内の開始ノード５１を含むスイムレーン５０ａに対応する実行フロー２１０内のスイムレーン２１０ａは、「internal」と定義される。「internal」と定義されたスイムレーン２１０ａ内の処理は、この実行フロー２１０がデプロイされたサーバが実行する処理である。
【００８０】
なお、実行フロー２１０では、「internal」のスイムレーン２１０ａを最も左に配置し、連携先のサービスに対応するスイムレーン２１０ｂ，２１０ｃをその右側に配置している。また、管理元のサービスに対応するスイムレーン２１０ａには、開始ノード２１１と終了ノード２１２とが配置される。
【００８１】
その後、開始ノード５１の遷移先から順に、アクティビティのノードが選択され、選択されたノードに応じて実行フロー２１０が更新される。最初に選択されるノード６１は、動作種別が「入力」のアクティビティであるため、実行フロー２１０の更新処理は行われない。
【００８２】
次の遷移先のノード５２は、動作種別が「処理」のアクティビティである。また、ノード５２は、管理元（serviceA）のスイムレーン５０ａに属している。そのため、ノード５２に応じて、実行フロー２１０の「internal」のスイムレーン２１０ａにノードが追加される。
【００８３】
図１１は、「処理」のアクティビティに応じた実行フローの更新結果を示す図である。図１１に示すように、ノード５２に対応するinvokeのノード２１４が実行フロー２１０の「internal」のスイムレーン２１０ａに追加されている。このとき、スイムレーン２１０ａには、受信インタフェースを示すノード６１に対応するreceiveのノード２１３も追加されている。また、入力されるデータ７１が、ノード２１３からノード２１４に渡されるデータ７１ａとして設定されている。
【００８４】
次に、「出力」のアクティビティを示すノード６２が選択される。このノード６２は、管理元（serviceA）のスイムレーン５０ａに属している。そのため、ノード６２に応じて、実行フロー２１０の送信先のスイムレーン２１０ｂにノードが追加される。
【００８５】
図１２は、「出力」のアクティビティに応じた実行フローの更新結果を示す図である。展開済業務プロセス６０内の「出力」のアクティビティを示すノード６２に対応するinvokeのノード２１５が、実行フロー２１０の「serviceB」のスイムレーンに追加されている。
【００８６】
また、展開済業務プロセス６０内でノード６２からノード６３に渡されるデータ７２が、ノード２１４からノード２１５に渡されるデータ７２ａとして実行フロー２１０に追加される。さらに、展開済業務プロセス６０内でノード６４から出力されるデータ７３が、ノード２１５からの出力されるデータ７３ａとして実行フロー２１０に追加される。
【００８７】
次の遷移先のノード６３は、管理元のスイムレーン５０ａとは別のスイムレーン５０ｂ（「serviceB」を実行する処理）にあり、「入力」のアクティビティを示している。そこで、「serviceB」を実行するための実行フローが新たに生成される。そして、展開済業務プロセス６０内では、スイムレーン５０ｂ内のノード５３、ノード６４の順で遷移するため、これらのノード５３，６４に基づいて、「serviceB」の実行フロー内にノードが配置される。
【００８８】
図１３は、「serviceB」の実行フローの生成結果を示す図である。図１３に示すように、「入力」のアクティビティを示すノード６３に基づいて、「serviceB」の実行フロー２２０が生成される。その際、実行フロー２２０には、開始ノード２２１と終了ノード２２２とが配置される。なお、実行フロー２２０内のスイムレーンは１つだけである。
【００８９】
生成された実行フロー２２０内には、開始ノード２２１の遷移先として、展開済業務プロセス６０内の「入力」のアクティビティを示すノード６３に応じたreceiveのノード２２３が配置されている。また、実行フロー２２０内のノード２２３の遷移先として、展開済業務プロセス６０内の「処理」のアクティビティを示すノード５３に応じたinvokeのノード２２４が配置されている。さらに、実行フロー２２０内のノード２２４の遷移先として、展開済業務プロセス６０内の「出力」のアクティビティを示すノード６４に応じたreplyのノード２２５が配置されている。ノード２２５の遷移先は、終了ノード２２２である。
【００９０】
ここで、図１３に示す実行フローで定義されたサービスを、「serviceB-1」とする。実行フロー２２０には、展開済業務プロセス６０上で間接的に「serviceC」を呼ぶ処理の手前までの処理が定義されている。また、「serviceB-1」は、「serviceA」からの呼び出しに応じて、同期的に応答を返すサービスである。なお、応答の際の返り値は、「serviceC」の呼び出しメッセージである。
【００９１】
このような「serviceB-1」の実行フロー２２０が作成されると、展開済業務プロセス６０内の「出力」のアクティビティを示すノード６４に応じて、「serviceA」の実行フロー２１０の更新が行われる。
【００９２】
図１４は、管理元以外のスイムレーンの「出力」のアクティビティに基づく集中管理の実行フローの更新結果を示す図である。展開済業務プロセス６０におけるスイムレーン５０ｂのノード６４に基づいて、集出管理用の「serviceA」を定義する実行フロー２１０のスイムレーン２１０ｃに、invokeのノード２１６が追加されている。このノード２１６は、スイムレーン２１０ｂのinvokeのノード２１５の遷移先となる。
【００９３】
また、実行フロー２１０のノード２１６への入力として、データ７３ａが設定される。さらに、展開済業務プロセス６０のスイムレーン５０ｃでの処理結果として得られるデータ７４が、実行フロー２１０のノード２１６が出力するデータ７４ａとして設定される。
【００９４】
次の遷移先のノード６５は、管理元のスイムレーン５０ａとは別のスイムレーン５０ｃ（「serviceC」を実行する処理）にあり、「入力」のアクティビティを示している。そこで、「serviceC」を実行するための実行フローが新たに生成される。そして、展開済業務プロセス６０内では、スイムレーン５０ｃ内のノード５４、ノード６６の順で遷移するため、これらのノード５４，６６に基づいて、「serviceC」の実行フロー内にノードが配置される。
【００９５】
図１５は、「serviceC」の実行フローの生成結果を示す図である。図１５に示すように、「入力」のアクティビティを示すノード６５に基づいて、「serviceC」の実行フロー２３０が生成される。その際、実行フロー２３０には、開始ノード２３１と終了ノード２３２とが配置される。なお、実行フロー２３０内のスイムレーンは１つだけである。
【００９６】
生成された実行フロー２３０内には、開始ノード２３１の遷移先として、展開済業務プロセス６０内の「入力」のアクティビティを示すノード６５に応じたreceiveのノード２３３が配置されている。また、実行フロー２３０内のノード２３３の遷移先として、展開済業務プロセス６０内の「処理」のアクティビティを示すノード５４に応じたinvokeのノード２３４が配置されている。さらに、実行フロー２３０内のノード２３４の遷移先として、展開済業務プロセス６０内の「出力」のアクティビティを示すノード６６に応じたreplyのノード２３５が配置されている。ノード２３５の遷移先は、終了ノード２３２である。
【００９７】
実行フロー２３０には、展開済業務プロセス６０上で間接的に「serviceB」を呼ぶ処理の手前までの処理が定義されている。また、「serviceC」は、「serviceA」からの呼び出しに応じて、同期的に応答を返すサービスである。なお、応答の際の返り値は、「serviceB」の呼び出しメッセージである。
【００９８】
このような「serviceC」の実行フロー２３０が作成されると、展開済業務プロセス６０内の「出力」のアクティビティを示すノード６６に応じて、「serviceA」の実行フロー２１０の更新が行われる。
【００９９】
図１６は、管理元以外のスイムレーンの「出力」のアクティビティに基づく集中管理の実行フローの更新結果を示す図である。展開済業務プロセス６０におけるスイムレーン５０ｃのノード６６に基づいて、集中管理用の「serviceA」を定義する実行フロー２１０のスイムレーン２１０ｂに、invokeのノード２１７が追加されている。このノード２１７は、スイムレーン２１０ｃのinvokeのノード２１６の遷移先となる。
【０１００】
また、実行フロー２１０のノード２１７への入力として、データ７４ａが設定される。さらに、展開済業務プロセス６０のスイムレーン５０ｂでの処理結果として得られるデータ７５が、実行フロー２１０のノード２１７が出力するデータ７５ａとして設定される。
【０１０１】
次の遷移先のノード６７は、管理元のスイムレーン５０ａとは別のスイムレーン５０ｂ（「serviceB」を実行する処理）にあり、「入力」のアクティビティを示している。そこで、「serviceB」を実行するための実行フローが新たに生成される。そして、展開済業務プロセス６０内では、スイムレーン５０ｂ内のノード５５、ノード６８の順で遷移するため、これらのノード５５，６８に基づいて、「serviceB」の実行フロー内にノードが配置される。
【０１０２】
図１７は、「serviceB」の実行フローの生成結果を示す図である。図１７に示すように、「入力」のアクティビティを示すノード６７に基づいて、「serviceB」の実行フロー２４０が生成される。その際、実行フロー２４０には、開始ノード２４１と終了ノード２４２とが配置される。なお、実行フロー２４０内のスイムレーンは１つだけである。
【０１０３】
生成された実行フロー２４０内には、開始ノード２４１の遷移先として、展開済業務プロセス６０内の「入力」のアクティビティを示すノード６７に応じたreceiveのノード２４３が配置されている。また、実行フロー２４０内のノード２４３の遷移先として、展開済業務プロセス６０内の「処理」のアクティビティを示すノード５５に応じたinvokeのノード２４４が配置されている。さらに、実行フロー２４０内のノード２４４の遷移先として、展開済業務プロセス６０内の「出力」のアクティビティを示すノード６８に応じたreplyのノード２４５が配置されている。ノード２４５の遷移先は、終了ノード２４２である。
【０１０４】
実行フロー２４０には、展開済業務プロセス６０上で「serviceA」を呼ぶ処理の手前までの処理が定義されている。また、「serviceB」は、「serviceA」からの呼び出しに応じて、同期的に応答を返すサービスである。なお、応答の際の返り値は、「serviceA」の呼び出しメッセージである。
【０１０５】
ここで、図１７に示す実行フローで定義されたサービスを、「serviceB-2」とする。なお、展開済業務プロセス６０のノード６８は、「serviceA」の呼び出し処理を行っているが、管理元以外のサービスから管理元のサービスの呼び出し処理については、該当する処理の実行フローへの展開は行わない。
【０１０６】
次の遷移先のノード６９は、管理元のスイムレーン５０ａにあり、「入力」のアクティビティを示している。そのため、実行フローに対する更新等の処理は行われない。さらに次の遷移先のノード５６は、管理元のスイムレーン５０ａにあり、「処理」のアクティビティを示している。そのため、ノード５６に応じて、実行フロー２１０の「internal」のスイムレーン２１０ａにノードが追加される。
【０１０７】
図１８は、「処理」のアクティビティに応じた実行フローの更新結果を示す図である。図１８に示すように、ノード５６に対応するinvokeのノード２１８が実行フロー２１０の「internal」のスイムレーン２１０ａに追加されている。また、入力されるデータ７５が、ノード２１７からノード２１８に渡されるデータ７５ａとして設定されている。さらに、ノード５６から出力されるデータ７６が、実行フロー２１０のノード２１８から出力されるデータ７６ａとして設定される。
【０１０８】
なお、展開済業務プロセス６０のノード７０は、「出力」のアクティビティを示しているが、その次の遷移先が終了ノード５７である。すなわち、出力されるデータ７６は、クライアントに対する応答データである。したがって、実行フロー２１０では、ノード２１８の遷移先として終了ノード２１２が設定される。
【０１０９】
以上のようにして、集中管理方式によって連携処理を行う複数のサービスそれぞれの処理内容を定義した実行フロー２１０，２２０，２３０，２４０が生成される。「serviceA」の処理内容を定義した実行フロー２１０をサーバ３１にデプロイすることで、サーバ３１によって集中管理サービス４１（図５参照）を提供することができる。また、実行フロー２２０，２４０をサーバ３２にデプロイすることで、サーバ３２によって「serviceB」に対応するサービス４２を提供することができる。さらに、実行フロー２３０をサーバ３３にデプロイすることで、サーバ３３によって「serviceC」に対応するサービス４３を提供することができる。
【０１１０】
［第２の連携方式］
次に、サービス分割Messaging方式について説明する。サービス分割Messaging方式では、直接依存するサービスのみを、Messaging方式で呼び出す。
【０１１１】
図１９は、サービス分割Messaging方式によるサービスの呼び出し関係を示す図である。この方式では、直接の依存関係があるサービス間で呼び出しが行われる。図１９の例では、サービス８１からサービス８２が呼び出される。また、サービス８２からサービス８３が呼び出される。この連携方式では、サービス８１とサービス８３との間には直接の依存関係がないため、サービス８１からサービス８３への呼び出しは行われない。ここで、サービス８１の名称を「ServiceA」、サービス８２の名称を「ServiceB」、サービス８３の名称を「ServiceC」とする。
【０１１２】
図２０は、サービス分割Messaging方式によるメッセージの送受信状況を示す図である。サービス分割Messaging方式では、「ServiceA」を実行するサーバ３１に対して、クライアント２１のユーザプロセスからリクエスト（1:request()）が出される。すると、サーバ３１では、「ServiceA」による処理が開始される。そして、「ServiceB」との連携処理が発生すると、サーバ３１からサーバ３２に対して、リクエスト（1.1:request()）が出される。
【０１１３】
サーバ３２では、「ServiceB」による処理が実行される。そして、「ServiceC」との連携処理が発生すると、サーバ３２からサーバ３３に対して、リクエスト（1.1.1:request()）が出される。サーバ３３では、「ServiceC」による処理が実行され、レスポンス（1.1.1.1:response()）がサーバ３２の「ServiceB」に返される。そのレスポンスに応じてサーバ３２で「ServiceB」による処理が実行され、レスポンス（1.1.1.1.1:response()）がサーバ３１の「ServiceA」に返される。そのレスポンスに応じてサーバ３１で「ServiceA」による処理が実行され、レスポンス（1.1.1.1.1.1:response()）がクライアント２１に返される。
【０１１４】
このように、サービス分割Messaging方式でサービスを連携させることで、業務プロセスに従ったサービスを実行できる。このような連携方式は、部分的なサービスを他の業務でも共有する場合に有効である。
【０１１５】
次に、サービス分割Messaging方式によって連携するサービスの実行フローの生成方法について説明する。
図２１は、サービス分割Messaging方式の実行フロー生成手順を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
【０１１６】
［ステップＳ３１］第２の実行フロー生成部１２３は、業務プロセス５０内の未処理のスイムレーンの中から着目するスイムレーンを決定する。このとき、第２の実行フロー生成部１２３は、着目するスイムレーンで示されるサービス用の実行フローを生成する。この実行フローには、業務プロセス内に各スイムレーンに対応するスイムレーンが設けられている。実行フローのスイムレーンのうち、業務プロセス内で開始ノードを含むスイムレーンに対応するものを、「internal」（着目したスイムレーンの内部サービスを示す）のスイムレーンとする。
【０１１７】
［ステップＳ３２］第２の実行フロー生成部１２３は、業務プロセス５０の全てのスイムレーン間の呼び出し関係を示すインタフェースを追加することで、全てのスイムレーンを展開する。具体的な展開例は、図９に示した通りである。
【０１１８】
［ステップＳ３３］第２の実行フロー生成部１２３は、開始ノードから順にアクティビティを辿り、アクティビティを選択する。
［ステップＳ３４］第２の実行フロー生成部１２３は、選択したアクティビティが着目するスイムレーン内か否かを判断する。着目するスイムレーン内のアクティビティであれば、処理がステップＳ３５に進められる。着目するスイムレーン内のアクティビティでなければ、処理がステップＳ３３に進められる。
【０１１９】
［ステップＳ３５］第２の実行フロー生成部１２３は、選択したアクティビティの動作種別を判断する。動作種別が「処理」の場合、処理がステップＳ３６に進められる。動作種別が「入力」の場合、処理がステップＳ３７に進められる。動作種別が「出力」の場合、処理がステップＳ３８に進められる。動作種別が「終了」の場合、処理がステップＳ３９に進められる。
【０１２０】
［ステップＳ３６］第２の実行フロー生成部１２３は、動作種別が「処理」の場合、着目したスイムレーンに対応する実行フロー内の「internal」のスイムレーンに、invokeのノードを配置する。その後、処理がステップＳ３３に進められる。
【０１２１】
［ステップＳ３７］第２の実行フロー生成部１２３は、動作種別が「入力」の場合、着目したスイムレーンに対応する実行フロー内の「internal」のスイムレーンに、receiveのノードを配置する。その後、処理がステップＳ３３に進められる。
【０１２２】
［ステップＳ３８］第２の実行フロー生成部１２３は、動作種別が「出力」の場合、着目したスイムレーンに対応する実行フロー内の出力データの送信先のスイムレーンに、invokeのノードを配置する。その後、処理がステップＳ３３に進められる。
【０１２３】
［ステップＳ３９］第２の実行フロー生成部１２３は、動作種別が「終了」の場合、業務プロセス５０内の全てのスイムレーンに対して、実行フローの生成処理が行われたか否かを判断する。未処理のスイムレーンがあれば、処理がステップＳ３１に進められる。全てのスイムレーンに対して処理が完了していれば、処理が終了する。
【０１２４】
次に、サービス分割Messaging方式によって連携する実行フローの生成手順を、具体例を用いて説明する。なお、入力される業務プロセス５０の内容は、図８に示した通りとする。
【０１２５】
ここで、最初に着目するスイムレーンとして、「serviceA」のスイムレーン５０ａが選択されてものとする。また、業務プロセス５０の展開結果は、図９に示した通りである。図９に示すような展開済業務プロセス６０が生成された後、着目されたスイムレーンに対応する実行フローが生成される。
【０１２６】
図２２は、「serviceA」の実行フローの作成過程を示す第１の図である。生成された実行フロー３１０には、展開済業務プロセス６０に設けられたスイムレーン５０ａ，５０ｂ，５０ｃのうち、着目するスイムレーン５０ａと、そのスイムレーン５０ａから直接関連するスイムレーン５０ｂとに対応するスイムレーン３１０ａ，３１０ｂが設けられている。ここで、展開済業務プロセス６０内の着目するスイムレーン５０ａに対応する実行フロー３１０内のスイムレーン３１０ａは、「internal」と定義される。「internal」と定義されたスイムレーン３１０ａ内の処理は、この実行フロー３１０がデプロイされたサーバが実行する処理である。
【０１２７】
なお、実行フロー３１０では、「internal」のスイムレーン３１０ａが最も左に配置され、直接関連するスイムレーン３１０ｂがその右側に配置されている。また、スイムレーン３１０ａには、開始ノード３１１が配置される。
【０１２８】
その後、開始ノード５１の遷移先から順に、アクティビティのノードが選択され、選択されたノードに応じて実行フロー３１０が更新される。
最初に選択されるノード６１は、着目するスイムレーン５０ａ内の動作種別が「入力」のアクティビティである。そのため、実行フロー３１０の「internal」のスイムレーン３１０ａにreceiveのノード３１２が配置される。次に選択されるノード５２は、動作種別が「処理」のアクティビティである。そのため、実行フロー３１０の「internal」のスイムレーン３１０ａにinvokeのノード３１３が配置される。このとき、展開済業務プロセス６０内のデータ７１が、ノード３１２からノード３１３に渡されるデータ７１ｂとして設定される。
【０１２９】
次の遷移先のノード６２は、動作種別が「出力」のアクティビティ（送信のインタフェース）である。また、ノード６２は、着目するスイムレーン５０ａに属している。そのため、ノード６２に応じて、実行フロー３１０のデータ送信先のスイムレーン３１０ｂにノードが追加される。
【０１３０】
図２３は、「serviceA」の実行フローの作成過程を示す第２の図である。実行フロー３１０のスイムレーン３１０ｂには、invokeのノード３１４が追加されている。また、展開済業務プロセス６０において、サービスの呼び出しに用いられているデータ７２が、実行フロー３１０内のノード３１３からノード３１４へ入力されるデータ７２ｂとして設定されている。
【０１３１】
以降、展開済業務プロセス６０内のノード６３からノード６８までは、着目しているスイムレーン５０ａの外に配置されている。したがって、これらのノードに応じた実行フロー３１０の更新は行われない。その次のノード６９は、動作種別が「入力」のアクティビティ（受信のインタフェース）である。また、ノード６９は、着目するスイムレーン５０ａに属している。そのため、ノード６９に応じて、実行フロー３１０の「internal」のスイムレーン３１０ａにノードが追加される。
【０１３２】
図２４は、「serviceA」の実行フローの作成過程を示す第３の図である。実行フロー３１０のスイムレーン３１０ａには、receiveのノード３１５が追加されている。なお、実行フロー３１０内のノード間の接続は、「serviceA」側から見たときの連携先を処理（展開済業務プロセス６０のノード６３〜６８）を１つの処理（実行フロー３１０のノード３１４）に置き換えたときの順序に沿って行われる。したがって、実行フロー３１０中のノード３１４からノード３１５に接続される。
【０１３３】
また、展開済業務プロセス６０においてノード６９が受信するデータ７５が、実行フロー３１０内のノード３１５から出力されるデータ７５ｂとして設定される。さらに、スイムレーン３１０ｂのinvokeのノード３１４に対するリクエストのデータ７２ｂと、レスポンスのデータ７５ｂとの間の関連性を示す関連情報７７が設定される。
【０１３４】
以降、ノード５６，７０に基づいて、実行フロー３１０の更新が行われる。なお、ノード７０は、クライアント２１（処理要求の送信元）への送信のインタフェースであり、図２４に示す状態では、クライアント２１に対応するスイムレーンが実行フロー３１０内に設けられていない。そこで、ノード７０に対応するinvokeを配置するためのスイムレーンが、実行フロー３１０に追加される。
【０１３５】
図２５は、「serviceA」の実行フローの作成過程を示す第４の図である。「処理」のアクティビティを示すノード５６に基づいて、実行フロー３１０には、invokeのノード３１６が設定されている。また、「出力」のアクティビティを示すノード７０に基づいて、送信先のスイムレーン３１０ｃが追加されている。
【０１３６】
このスイムレーン３１０ｃには、処理要求の送信元のサービス（Sender）が定義される。スイムレーン３１０ｃには、invokeのノード３１７が設定される。そして、そのノード３１７の遷移先として、終了ノード３１８が設定される。また、展開済業務プロセス６０のノード７０から出力されるデータ７６が、実行フロー３１０のノード３１６からノード３１７に送信されるデータ７６ｂとして設定される。
【０１３７】
このようにして、「serviceA」の実行フロー３１０が作成される。以降、スイムレーン３１０ｂに着目して「serviceB」の実行フローが作成され、スイムレーン３１０ｃに着目して「serviceC」の実行フローが作成される。
【０１３８】
図２６は、「serviceB」の実行フローの作成結果を示す図である。この実行フロー３２０は、展開済業務プロセス６０のスイムレーン５０ｂに着目して作成されている（展開済業務プロセス６０の説明については図９を参照）。そのため、「serviceB」に対応するスイムレーン３２０ａが「internal」のスイムレーンである。また、展開済業務プロセス６０において「serviceB」のスイムレーン５０ｂと直接関係するのは、「serviceA」のスイムレーン５０ａと「serviceC」のスイムレーン５０ｃである。したがって、実行フロー３２０は、「serviceC」に対応するスイムレーン３２０ｂと、「serviceA」に対応するスイムレーン３２０ｃとが設けられている。
【０１３９】
「internal」のスイムレーン３２０ａには、開始ノード３２１が設けられている。開始ノード３２１には、展開済業務プロセス６０のノード６３に対応するreceiveのノード３２２が接続されている。ノード３２２には、展開済業務プロセス６０のノード５３に対応するinvokeのノード３２３が接続されている。また、展開済業務プロセス６０のノード６３へ入力されるデータ７２が、実行フロー３２０のノード３２２からノード３２３へ入力されるデータ７２ｃとして設定されている。
【０１４０】
ノード３２３には、展開済業務プロセス６０のノード６４に対応するinvokeのノード３２４が接続されている。ノード３２４は、「serviceC」のスイムレーン３２０ｂ内に配置されている。また、展開済業務プロセス６０のノード６４から出力されるデータ７３が、実行フロー３２０のノード３２３からノード３２４へ入力されるデータ７３ｃとして設定されている。
【０１４１】
ノード３２４には、展開済業務プロセス６０のノード６７に対応するreceiveのノード３２５が接続されている。ノード３２５は、「internal」のスイムレーン３２０ａ内に配置されている。
【０１４２】
ノード３２５には、展開済業務プロセス６０のノード５５に対応するinvokeのノード３２６が接続されている。また、展開済業務プロセス６０のノード６７に入力されるデータ７４が、実行フロー３２０のノード３２５からノード３２６へ入力されるデータ７４ｃとして設定されている。さらに、スイムレーン３２０ｂのinvokeのノード３２４に対するリクエストのデータ７３ｃと、レスポンスのデータ７４ｃとの間の関連性を示す関連情報７８が設定される。
【０１４３】
ノード３２６には、展開済業務プロセス６０のノード６８に対応するinvokeのノード３２７が接続されている。ノード３２７は、「serviceA」のスイムレーン３２０ｃ内に配置されている。また、展開済業務プロセス６０のノード６８から出力されるデータ７５が、実行フロー３２０のノード３２６からノード３２７へ入力されるデータ７５ｃとして設定されている。さらに、ノード３２７には、終了ノード３２８が接続されている。
【０１４４】
図２７は、「serviceC」の実行フローの作成結果を示す図である。この実行フロー３３０は、展開済業務プロセス６０のスイムレーン５０ｃに着目して作成されている（展開済業務プロセス６０の説明については図９を参照）。そのため、「serviceC」に対応するスイムレーン３３０ａが「internal」のスイムレーンである。また、展開済業務プロセス６０において「serviceC」のスイムレーン５０ｃと直接関係するのは、「serviceB」のスイムレーン５０ｂである。したがって、実行フロー３３０には、「serviceB」に対応するスイムレーン３３０ｂが設けられている。
【０１４５】
「internal」のスイムレーン３３０ａには、開始ノード３３１が設けられている。開始ノード３３１には、展開済業務プロセス６０のノード６５に対応するreceiveのノード３３２が接続されている。ノード３３２には、展開済業務プロセス６０のノード５４に対応するinvokeのノード３３３が接続されている。また、展開済業務プロセス６０のノード６５へ入力されるデータ７３が、実行フロー３３０のノード３３２からノード３３３へ入力されるデータ７３ｄとして設定されている。
【０１４６】
ノード３３３には、展開済業務プロセス６０のノード６６に対応するinvokeのノード３３４が接続されている。ノード３３４は、「serviceB」のスイムレーン３３０ｂ内に配置されている。また、展開済業務プロセス６０のノード６６から出力されるデータ７４が、実行フロー３３０のノード３３３からノード３３４へ入力されるデータ７４ｄとして設定されている。さらに、ノード３３４には、終了ノード３３５が接続されている。
【０１４７】
以上のようにして、サービス分割Messaging方式によって連携処理を行う複数のサービスそれぞれの処理内容を定義した実行フロー３１０，３２０，３３０が生成される。「serviceA」の処理内容を定義した実行フロー３１０をサーバ３１にデプロイすることで、サーバ３１によって「serviceA」に対応するサービス８１（図１９参照）を提供することができる。また、実行フロー３２０をサーバ３２にデプロイすることで、サーバ３２によって「serviceB」に対応するサービス８２を提供することができる。さらに、実行フロー３３０をサーバ３３にデプロイすることで、サーバ３３によって「serviceC」に対応するサービス８３を提供することができる。
【０１４８】
［第３の連携方式］
次に、サービス分割Pub/Sub方式について説明する。サービス分割Pub/Sub方式は、直接依存するサービスのみを、Publish/Subscribe方式によって呼び出す連携方式である。
【０１４９】
サービス分割Pub/Sub方式による実行フローの生成手順は、第２の連携方式とほぼ同様である。ただし、第２の連携方式では、送受信のインタフェースに対応するノードを作成する際に、そのノードによってMessaging方式による通信を行うプログラムモジュールを指定していたが、第３の連携方式では、Pub/Sub方式による通信を行うプログラムモジュールが指定される。
【０１５０】
ここで、「serviceA」と「serviceB」との間の連携をサービス分割Pub/Sub方式で行い、「serviceB」と「serviceC」との間の連携をサービス分割Messaging方式で行う場合の実行フローの例を以下に示す。
【０１５１】
図２８は、第３の連携方式による「serviceA」の実行フローの作成結果を示す図である。この実行フロー３４０は、展開済業務プロセス６０のスイムレーン５０ａに着目して作成されている（展開済業務プロセス６０の説明については図９を参照）。そのため、「serviceA」に対応するスイムレーン３４０ａが「internal」のスイムレーンである。また、展開済業務プロセス６０において「serviceA」のスイムレーン５０ａと直接関係するのは、「serviceB」のスイムレーン５０ｂである。したがって、実行フロー３４０には、「serviceB」に対応するスイムレーン３４０ｂが設けられている。なお、展開済業務プロセス６０において「serviceA」のスイムレーン５０ａには、クライアント２１に対してレスポンスを返す処理が含まれているため、クライアント２１の処理に対応する「Sender」のスイムレーン３４０ｃが設けられている。
【０１５２】
ここで、実行フロー３４０に設定されるノードとデータは、図２５に示した第２の連携方式で生成された実行フロー３１０とほぼ同じである。そこで、同じ要素には図２５と同一の符号を付して説明を省略し、実行フロー３１０と異なる点のみを説明する。
【０１５３】
第２の連携方式で生成された実行フロー３１０と異なる点は、実行フロー３１０内のノード３１５に代えて、ノード３４１が設定された点である。このノード３４１は、「入力」のノード６９（図９参照）に基づいて生成されており、Pub/Sub方式によるメッセージ送信相手の管理機能（subscribe）を含んでいる。
【０１５４】
図２９は、第３の連携方式による「serviceB」の実行フローの作成結果を示す図である。この実行フロー３５０は、展開済業務プロセス６０のスイムレーン５０ｂに着目して作成されている（展開済業務プロセス６０の説明については図９を参照）。そのため、「serviceB」に対応するスイムレーン３５０ａが「internal」のスイムレーンである。
【０１５５】
また、展開済業務プロセス６０において「serviceB」のスイムレーン５０ｂと直接関係するのは、「serviceB」のスイムレーン５０ｂと「serviceC」のスイムレーン５０ｃである。したがって、実行フロー３５０には、「serviceC」に対応するスイムレーン３５０ｂと「serviceA」に対応するスイムレーン３５０ｃとが設けられている。
【０１５６】
ただし、Pub/Sub方式では、「serviceB」にとって、メッセージの送信要求があるまでメッセージの送信相手は未定であるため、実行フロー３５０上では、スイムレーン３５０ｃを「serviceA」ではなく「Receiver」とする。
【０１５７】
ここで、実行フロー３５０に設定されるノードとデータは、図２６に示した第２の連携方式で生成された実行フロー３２０とほぼ同じである。そこで、同じ要素には図２６と同一の符号を付して説明を省略し、実行フロー３２０と異なる点のみを説明する。
【０１５８】
第２の連携方式で生成された実行フロー３２０と異なる点は、実行フロー３２０内のノード３２７に代えて、ノード３５１が設定された点である。このノード３５１は、「出力」のノード６８（図９参照）に基づいて生成されており、Pub/Sub方式によるメッセージの送信機能（publish）を含んでいる。
【０１５９】
なお、第３の連携方式による「serviceC」の実行フローは、第２の連携方式の場合（図２７参照）と同じである。
以上のようにして、サービス分割Pub/Sub方式によって連携処理を行う複数のサービスそれぞれの処理内容を定義した実行フロー３４０，３５０，３３０が生成される。「serviceA」の処理内容を定義した実行フロー３４０をサーバ３１にデプロイすることで、サーバ３１によって「serviceA」に対応するサービスを提供することができる。また、実行フロー３５０をサーバ３２にデプロイすることで、サーバ３２によって「serviceB」に対応するサービスを提供することができる。さらに、実行フロー３３０をサーバ３３にデプロイすることで、サーバ３３によって「serviceC」に対応するサービス８３を提供することができる。
【０１６０】
その結果、サーバ３１とサーバ３２との間の通信がPub/Sub方式で行われる。Pub/Sub方式を採用したことで、例えば、「serviceA」を実行するサーバの増設または廃止が容易となる。すなわち、任意のサーバに「serviceA」の実行フロー３４０をデプロイするだけで、サーバ３２側の実行フロー３５０を変更せずに「serviceA」のサーバの増設が可能となる。
【０１６１】
［第４の連携方式］
次に、サービス分割ＲＰＣ方式について説明する。サービス分割ＲＰＣ方式では、直接依存するサービスのみを、ＲＰＣ方式で呼び出す。
【０１６２】
図３０は、サービス分割ＲＰＣ方式によるメッセージの送受信状況を示す図である。サービス分割ＲＰＣ方式では、「ServiceA」を実行するサーバ３１にして、クライアント２１のユーザプロセスからリクエスト（1:request()）が出される。すると、サーバ３１では、「ServiceA」による処理が開始される。そして、「ServiceB」との連携処理が発生すると、サーバ３１からサーバ３２に対して、リクエスト（1.1:request()）が出される。その後、サーバ３１のサービスは処理を終了せずに、サーバ３２からの応答を待つ。
【０１６３】
サーバ３２では、「ServiceB」による処理が実行される。そして、「ServiceC」との連携処理が発生すると、サーバ３２からサーバ３３に対して、リクエスト（1.1.1:request()）が出される。その後、サーバ３１のサービスは処理を終了せずに、サーバ３２からの応答を待つ。
【０１６４】
サーバ３３では、「ServiceC」による処理が実行され、サーバ３２にレスポンスが返される。そのレスポンスに応じてサーバ３２で「ServiceB」による処理が実行され、サーバ３１にレスポンスが返される。そのレスポンスに応じてサーバ３１で「ServiceA」による処理が実行され、クライアント２１にレスポンスが返される。
【０１６５】
このようにサービス分割ＲＰＣ方式でサービスを連携されることで、業務プロセスに従ったサービスを実行できる。このような連携方式は、リアルタイム性が必要な場合や、Messaging方式の必要がない場合に有効である。
【０１６６】
次に、サービス分割ＲＰＣ方式によって連携するサービスの実行フローの生成方法について説明する。
図３１は、サービス分割ＲＰＣ方式の実行フロー生成手順を示すフローチャートである。以下、図３１に示す処理をステップ番号に沿って説明する。
【０１６７】
［ステップＳ４１］第４の実行フロー生成部１２５は、業務プロセス５０内の未処理のスイムレーンの中から着目するスイムレーンを決定する。このとき、第４の実行フロー生成部１２５は、着目するスイムレーンで示されるサービス用の実行フローを生成する。この実行フローには、業務プロセス内に各スイムレーンに対応するスイムレーンが設けられている。実行フローのスイムレーンのうち、業務プロセス内で開始ノードを含むスイムレーンに対応するものを、「internal」（着目したスイムレーンの内部サービスを示す）のスイムレーンとする。
【０１６８】
［ステップＳ４２］第４の実行フロー生成部１２５は、業務プロセス５０の全てのスイムレーン間の呼び出し関係を示すインタフェースを追加することで、全てのスイムレーンを展開する。具体的な展開例は、図９に示した通りである。
【０１６９】
［ステップＳ４３］第４の実行フロー生成部１２５は、開始ノードから順にアクティビティを辿り、アクティビティを選択する。
［ステップＳ４４］第４の実行フロー生成部１２５は、選択したアクティビティが着目するスイムレーン内か否かを判断する。着目するスイムレーン内のアクティビティであれば、処理がステップＳ４５に進められる。着目するスイムレーン内のアクティビティでなければ、処理がステップＳ４３に進められる。
【０１７０】
［ステップＳ４５］第４の実行フロー生成部１２５は、選択したアクティビティの動作種別を判断する。動作種別が「処理」の場合、処理がステップＳ４６に進められる。動作種別が「入力」の場合、処理がステップＳ４７に進められる。動作種別が「出力」の場合、処理がステップＳ４８に進められる。動作種別が「終了」の場合、処理がステップＳ４９に進められる。
【０１７１】
［ステップＳ４６］第４の実行フロー生成部１２５は、動作種別が「処理」の場合、着目したスイムレーンに対応する実行フロー内の「internal」のスイムレーンに、invokeのノードを配置する。その後、処理がステップＳ４３に進められる。
【０１７２】
［ステップＳ４７］第４の実行フロー生成部１２５は、動作種別が「入力」の場合、呼び出し元のinvokeからの返り値を、着目したスイムレーンに対応する実行フロー内の呼び出し元に対応するスイムレーンに設定する。
【０１７３】
［ステップＳ４８］第４の実行フロー生成部１２５は、動作種別が「出力」の場合、着目したスイムレーンに対応する実行フロー内の出力データの送信先のスイムレーンに、invokeのノードを配置する。その後、処理がステップＳ４３に進められる。
【０１７４】
［ステップＳ４９］第４の実行フロー生成部１２５は、動作種別が「終了」の場合、業務プロセス５０内の全てのスイムレーンに対して、実行フローの生成処理が行われたか否かを判断する。未処理のスイムレーンがあれば、処理がステップＳ４１に進められる。全てのスイムレーンに対して処理が完了していれば、処理が終了する。
【０１７５】
次に、サービス分割ＲＰＣによって連携する実行フローの生成手順を、具体例を用いて説明する。なお、入力される業務プロセス５０の内容は、図８に示した通りとする。
ここで、最初に着目するスイムレーンとして、「serviceA」のスイムレーン５０ａが選択されたものとする。また、業務プロセス５０の展開結果は、図９に示した通りである。図９に示すような展開済業務プロセス６０が生成された後、着目されたスイムレーンに対応する実行フローが生成される。
【０１７６】
図３２は、「serviceA」の実行フローの作成過程を示す第１の図である。生成された実行フロー４１０には、展開済業務プロセス６０に設けられたスイムレーン５０ａ，５０ｂ，５０ｃのうち、着目するスイムレーン５０ａと、そのスイムレーン５０ａから直接関連するスイムレーン５０ｂとに対応するスイムレーン４１０ａ，４１０ｂが設けられている。ここで、展開済業務プロセス６０内の着目するスイムレーン５０ａに対応する実行フロー４１０内のスイムレーン４１０ａは、「internal」と定義される。「internal」と定義されたスイムレーン４１０ａ内の処理は、この実行フロー４１０がデプロイされたサーバが実行する処理である。
【０１７７】
なお、実行フロー４１０では、「internal」のスイムレーン４１０ａが最も左に配置され、直接関連するスイムレーン４１０ｂがその右側に配置されている。また、スイムレーン４１０ａには、開始ノード４１１が配置される。
【０１７８】
その後、開始ノード５１の遷移先から順に、アクティビティのノードが選択され、選択されたノードに応じて実行フロー４１０が更新される。
最初に選択されるノード６１は、着目するスイムレーン５０ａ内の動作種別が「入力」のアクティビティである。そのため、実行フロー４１０の「internal」のスイムレーン４１０ａにreceiveのノード４１２が配置される。次に選択されるノード５２は、動作種別が「処理」のアクティビティである。そのため、実行フロー４１０の「internal」のスイムレーン４１０ａにinvokeのノード４１３が配置される。このとき、展開済業務プロセス６０内のデータ７１が、ノード４１２からノード４１３に渡されるデータ７１ｅとして設定される。
【０１７９】
次の遷移先のノード６２は、動作種別が「出力」のアクティビティ（送信のインタフェース）である。また、ノード６２は、着目するスイムレーン５０ａに属している。そのため、ノード６２に応じて、実行フロー４１０のデータ送信先のスイムレーン４１０ｂにノードが追加される。
【０１８０】
図３３は、「serviceA」の実行フローの作成過程を示す第２の図である。実行フロー４１０のスイムレーン４１０ｂには、invokeのノード４１４が追加されている。また、展開済業務プロセス６０において、サービスの呼び出しに用いられているデータ７２が、実行フロー４１０内のノード４１３からノード４１４へ入力されるデータ７２ｅとして設定されている。
【０１８１】
以降、展開済業務プロセス６０内のノード６３からノード６８までは、着目しているスイムレーン５０ａの外に配置されている。したがって、これらのノードに応じた実行フロー４１０の更新は行われない。その次のノード６９は、動作種別が「入力」のアクティビティ（受信のインタフェース）である。また、ノード６９は、着目するスイムレーン５０ａに属している。そのため、ノード６９に応じて、ノード６９で受信するデータ７５が、実行フロー４１０の「serviceB」のスイムレーン４１０ｂからの戻り値を示すデータ７５ｅとして設定される。
【０１８２】
以降、ノード５６，７０に基づいて、実行フロー４１０の更新が行われる。
図３４は、「serviceA」の実行フローの作成過程を示す第３の図である。「処理」のアクティビティを示すノード５６に基づいて、実行フロー４１０には、invokeのノード４１５が設定されている。また、「出力」のアクティビティを示すノード７０に基づいて、実行フロー４１０には、replyのノード４１６が追加されている。そして、そのノード４１６の遷移先として、終了ノード４１７が設定される。また、展開済業務プロセス６０のノード７０から出力されるデータ７６が、実行フロー４１０のノード４１５からノード４１６に渡されるデータ７６ｅとして設定される。
【０１８３】
このようにして、「serviceA」の実行フロー４１０が作成される。以降、スイムレーン４１０ｂに着目して「serviceB」の実行フローが作成され、スイムレーン４１０ｃに着目して「serviceC」の実行フローが作成される。
【０１８４】
図３５は、「serviceB」の実行フローの作成結果を示す図である。この実行フロー４２０は、展開済業務プロセス６０のスイムレーン５０ｂに着目して作成されている（展開済業務プロセス６０の説明については図９を参照）。そのため、「serviceB」に対応するスイムレーン４２０ａが「internal」のスイムレーンである。また、展開済業務プロセス６０において「serviceB」のスイムレーン５０ｂがリクエストを直接出すのは「serviceC」のスイムレーン５０ｃである。したがって、実行フロー４２０は、「serviceC」に対応するスイムレーン４２０ｂが設けられている。
【０１８５】
「internal」のスイムレーン４２０ａには、開始ノード４２１が設けられている。開始ノード４２１には、展開済業務プロセス６０のノード６３に対応するreceiveのノード４２２が接続されている。ノード４２２には、展開済業務プロセス６０のノード５３に対応するinvokeのノード４２３が接続されている。また、展開済業務プロセス６０のノード６３へ入力されるデータ７２が、実行フロー４２０のノード４２２からノード４２３へ入力されるデータ７２ｆとして設定されている。
【０１８６】
ノード４２３には、展開済業務プロセス６０のノード６４に対応するinvokeのノード４２４が接続されている。ノード４２４は、「serviceC」のスイムレーン４２０ｂ内に配置されている。また、展開済業務プロセス６０のノード６４から出力されるデータ７３が、実行フロー４２０のノード４２３からノード４２４へ入力されるデータ７３ｆとして設定されている。
【０１８７】
ノード４２４には、展開済業務プロセス６０のノード５５に対応するinvokeのノード４２５が接続されている。ノード４２５は、「internal」のスイムレーン４２０ａ内に配置されている。また、展開済業務プロセス６０のノード５５に入力されるデータ７４が、実行フロー４２０のノード４２４からノード４２５へ入力されるデータ７４ｆとして設定されている。
【０１８８】
ノード４２５には、展開済業務プロセス６０のノード６８に対応するreplyのノード４２６が接続されている。また、展開済業務プロセス６０のノード６８から出力されるデータ７５が、実行フロー４２０のノード４２５からノード４２６へ入力されるデータ７５ｆとして設定されている。さらに、ノード４２６には、終了ノード４２７が接続されている。
【０１８９】
図３６は、「serviceC」の実行フローの作成結果を示す図である。この実行フロー４３０は、展開済業務プロセス６０のスイムレーン５０ｃに着目して作成されている（展開済業務プロセス６０の説明については図９を参照）。そのため、「serviceC」に対応するスイムレーン４３０ａが「internal」のスイムレーンである。
【０１９０】
「internal」のスイムレーン４３０ａには、開始ノード４３１が設けられている。開始ノード４３１には、展開済業務プロセス６０のノード６５に対応するreceiveのノード４３２が接続されている。ノード４３２には、展開済業務プロセス６０のノード５４に対応するinvokeのノード４３３が接続されている。また、展開済業務プロセス６０のノード６５へ入力されるデータ７３が、実行フロー４３０のノード４３２からノード４３３へ入力されるデータ７３ｇとして設定されている。
【０１９１】
ノード４３３には、展開済業務プロセス６０のノード６６に対応するinvokeのノード４３４が接続されている。また、展開済業務プロセス６０のノード６６から出力されるデータ７４が、実行フロー４３０のノード４３３からノード４３４へ入力されるデータ７４ｇとして設定されている。さらに、ノード４３４には、終了ノード４３５が接続されている。
【０１９２】
以上のようにして、サービス分割ＲＰＣ方式によって連携処理を行う複数のサービスそれぞれの処理内容を定義した実行フロー４１０，４２０，４３０が生成される。
図３７は、実行フローの実装状況を示す図である。この例では、業務プロセス５０に基づいて、サービス分割ＲＰＣ方式によって連携処理を行う実行フロー４１０，４２０，４３０が作成されている。「serviceA」の処理内容を定義した実行フロー４１０をサーバ３１にデプロイすることで、サーバ３１によって「serviceA」に対応するサービスが提供される。また、実行フロー４２０をサーバ３２にデプロイすることで、サーバ３２によって「serviceB」に対応するサービスが提供される。さらに、実行フロー４３０をサーバ３３にデプロイすることで、サーバ３３によって「serviceC」に対応するサービスが提供される。各サーバ３１，３２，３３間は、サービス分割ＲＰＣ方式によって通信が行われ、互いに連携処理が行われる。
【０１９３】
これにより、全体の業務の流れを把握しつつ、個々のサービスの再利用、共用が容易となる。例えば、業務プロセス５０の一部を他の業務プロセス９０で再利用した場合、業務プロセス９０で再利用した処理については、既にサーバに実装されている。そのため、既に実装されている実行フローを連携相手として、残りの実行フローを生成することで、サービスの共有が可能となる。その結果、サーバの資源の有効利用が可能となる。
【０１９４】
ここで、業務プロセスは、例えば、ＵＭＬ（Unified Modeling Language）で記述することができる。また、実行フローは、例えばＢＰＥＬで記述することができる。実行フローをＢＰＥＬで記述した場合、各サーバ３１，３２，３３には、ＢＰＥＬを解釈できる機能が実装されていればよい。また、サーバ３１，３２，３３をＥＳＢ（Enterprise Service Bus）で接続し、ＥＳＢ経由でサービスの連携を行うことができる。
【０１９５】
なお、実行フローの入出力インタフェースの定義時、入力側と出力側のプロトコルやメッセージ形式が異なる場合、プロトコルやメッセージ形式を変換する実行フローを自動生成し、サービス間に存在するＥＳＢの通信機能に配置することができる。これにより、インタフェースのミスマッチを解決することができる。
【０１９６】
以上説明したように、本発明の実施の形態によれば、システム間を跨る全体の業務の流れを定義する業務プロセス５０から、各サーバ上で動作する実行フローを個別に複数生成される。その結果、全体の業務の流れを把握しながら、各サーバ３１，３２，３３のサービスが自律的に連携することが可能となる。しかも、このようにサービス毎に個別の実行フローが生成されたことにより、サービスの他の業務への再利用、共用も容易となる。
【０１９７】
またこの際、４パターンの連携方式のいずれかを選択して適用することにより、実行フローの自動生成も容易となっている。
なお、従来の業務プロセス作成時の認識と、実行フローに必要な知識とのギャップに関しては、以下のように解決されている。
【０１９８】
視点の違いについては、各スイムレーンに着目した実行フローを個別に出力したことで、解決している。連携方式の有無については、連携方式に基づく連携処理をサービス実装内に展開することで解決している。非同期処理の扱いについては、非同期リクエストの受信処理を実行フローに設定すると共に、メッセージ間の関連情報を設定することで解決している。
【０１９９】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、サービス実装支援装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０２００】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０２０１】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０２０２】
なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
以上説明した実施の形態の主な技術的特徴は、以下の付記の通りである。
【０２０３】
（付記１）  業務内容に応じたサービスの提供機能のコンピュータシステムへの実装を支援するためのサービス実装支援プログラムにおいて、
コンピュータを、
サービスの提供機能毎にスイムレーンを分けて業務の手順が定義された業務プロセスが入力されると、前記業務プロセスをメモリに記憶すると共に、前記スイムレーン間での連携に適用する連携方式を決定する連携方式決定手段、
前記業務プロセス内の前記スイムレーン毎に、前記スイムレーンで示されるサービスに対応する実行フローを初期状態で前記メモリ内に生成し、前記メモリ内の前記実行フローに対して、対応する前記スイムレーンで示された処理内容を設定すると共に、前記スイムレーンを跨った入出力に関して前記連携方式決定手段で決定された前記連携方式による処理内容を設定する実行フロー生成手段、
として機能させることを特徴とするサービス実装支援プログラム。
【０２０４】
（付記２）  コンピュータを、さらに、
前記実行フロー生成手段で生成された前記実行フローを、その実行フローに応じたサービスを実行するサーバに実装するサービス実装手段、
として機能させることを特徴とする付記１記載のサービス実装支援プログラム。
【０２０５】
（付記３）  前記連携方式決定手段は、サービス間で同期通信を行う連携方式と、非同期通信を行う連携方式との中から、適用する連携方式を決定することを特徴とする付記１記載のサービス実装支援プログラム。
【０２０６】
（付記４）  前記連携方式決定手段は、１つのサービスが他のサービスを集中管理する集中管理方式と、前記業務プロセス上で直接関連しているサービス間でのみ連携処理を行うサービス分割方式との中から、適用する連携方式を決定することを特徴とする付記１記載のサービス実装支援プログラム。
【０２０７】
（付記５）  前記連携方式決定手段は、直接関連するサービスの組み合わせ毎に、適用する連携方式を個別に決定することを特徴とする付記１記載のサービス実装支援プログラム。
（付記６）  前記実行フロー生成手段は、前記業務プロセスに対して、他のサービスからの呼び出しを受け付ける入力インタフェースと、他のサービスを呼び出す出力インタフェースとを追加設定し、前記入力インタフェースと前記出力インタフェースとに対応する処理として、決定された前記連携方式に応じた処理を、互いに連携するサービスそれぞれの前記実行フローに設定することを特徴とする付記１記載のサービス実装支援プログラム。
【０２０８】
（付記７）  前記連携方式決定手段は、リプライの存在するサービスから呼び出されるサービスに適用する連携方式をＲＰＣ方式に決定し、それ以外のサービス間の連携に適用する連携方式をMessaging方式に決定することを特徴とする付記１記載のサービス実装支援プログラム。
【０２０９】
（付記８）  前記連携方式決定手段は、呼び出されるときの連携方式が同期方式に決定されたサービスが他のサービスを呼び出す場合に適用する連携方式は、同期方式に決定することを特徴とする付記１記載のサービス実装支援プログラム。
【０２１０】
（付記９）  前記実行フロー生成手段は、既に実装されているサービスと同じ処理を行うサービスについては前記実行フローの生成を行わず、連携相手のサービスの実行フローに対して既に実装されているサービスとの連携処理を設定することを特徴とする付記１記載のサービス実装支援プログラム。
【０２１１】
（付記１０）  コンピュータにより、業務内容に応じたサービスの提供機能のコンピュータシステムへの実装を支援するためのサービス実装支援方法において、
サービスの提供機能毎にスイムレーンを分けて業務の手順が定義された業務プロセスが入力されると、前記業務プロセスをメモリに記憶すると共に、前記スイムレーン間での連携に適用する連携方式を決定し、
前記業務プロセス内の前記スイムレーン毎に、前記スイムレーンで示されるサービスに対応する実行フローを初期状態で前記メモリ内に生成し、前記メモリ内の前記実行フローに対して、対応する前記スイムレーンで示された処理内容を設定すると共に、前記スイムレーンを跨った入出力に関して前記連携方式決定手段で決定された前記連携方式による処理内容を設定する、
ことを特徴とするサービス実装支援方法。
【０２１２】
（付記１１）  業務内容に応じたサービスの提供機能のコンピュータシステムへの実装を支援するためのサービス実装支援装置において、
サービスの提供機能毎にスイムレーンを分けて業務の手順が定義された業務プロセスが入力されると、前記業務プロセスをメモリに記憶すると共に、前記スイムレーン間での連携に適用する連携方式を決定する連携方式決定手段と、
前記業務プロセス内の前記スイムレーン毎に、前記スイムレーンで示されるサービスに対応する実行フローを初期状態で前記メモリ内に生成し、前記メモリ内の前記実行フローに対して、対応する前記スイムレーンで示された処理内容を設定すると共に、前記スイムレーンを跨った入出力に関して前記連携方式決定手段で決定された前記連携方式による処理内容を設定する実行フロー生成手段と、
を有することを特徴とするサービス実装支援装置。
【図面の簡単な説明】
【０２１３】
【図１】本実施の形態の概略を示す図である。
【図２】本実施の形態のシステム構成例を示す図である。
【図３】本実施の形態に用いるシステム管理サーバのハードウェア構成例を示す図である。
【図４】システム管理サーバの機能を示すブロック図である。
【図５】集中管理方式によるサービスの呼び出し関係を示す図である。
【図６】集中管理方式によるメッセージの送受信状況を示す図である。
【図７】集中管理方式の実行フロー生成手順を示すフローチャートである。
【図８】業務プロセスの例を示す図である。
【図９】展開済の業務プロセスを示す図である。
【図１０】生成直後の「serviceA」の実行フローを示す図である。
【図１１】「処理」のアクティビティに応じた実行フローの更新結果を示す図である。
【図１２】「出力」のアクティビティに応じた実行フローの更新結果を示す図である。
【図１３】「serviceB」の実行フローの生成結果を示す図である。
【図１４】管理元以外のスイムレーンの「出力」のアクティビティに基づく集中管理の実行フローの更新結果を示す図である。
【図１５】「serviceC」の実行フローの生成結果を示す図である。
【図１６】管理元以外のスイムレーンの「出力」のアクティビティに基づく集中管理の実行フローの更新結果を示す図である。
【図１７】「serviceB」の実行フローの生成結果を示す図である。
【図１８】「処理」のアクティビティに応じた実行フローの更新結果を示す図である。
【図１９】サービス分割Messaging方式によるサービスの呼び出し関係を示す図である。
【図２０】サービス分割Messaging方式によるメッセージの送受信状況を示す図である。
【図２１】サービス分割Messaging方式の実行フロー生成手順を示すフローチャートである。
【図２２】「serviceA」の実行フローの作成過程を示す第１の図である。
【図２３】「serviceA」の実行フローの作成過程を示す第２の図である。
【図２４】「serviceA」の実行フローの作成過程を示す第３の図である。
【図２５】「serviceA」の実行フローの作成過程を示す第４の図である。
【図２６】「serviceB」の実行フローの作成結果を示す図である。
【図２７】「serviceC」の実行フローの作成結果を示す図である。
【図２８】第３の連携方式による「serviceA」の実行フローの作成結果を示す図である。
【図２９】第３の連携方式による「serviceB」の実行フローの作成結果を示す図である。
【図３０】サービス分割ＲＰＣ方式によるメッセージの送受信状況を示す図である。
【図３１】サービス分割ＲＰＣ方式の実行フロー生成手順を示すフローチャートである。
【図３２】「serviceA」の実行フローの作成過程を示す第１の図である。
【図３３】「serviceA」の実行フローの作成過程を示す第２の図である。
【図３４】「serviceA」の実行フローの作成過程を示す第３の図である。
【図３５】「serviceB」の実行フローの作成結果を示す図である。
【図３６】「serviceC」の実行フローの作成結果を示す図である。
【図３７】実行フローの実装状況を示す図である。
【符号の説明】
【０２１４】
１  サービス実装支援装置
１ａ  連携方式決定手段
１ｂ  実行フロー生成手段
１ｃ  サービス実装手段
２ａ，２ｂ，２ｃ  サーバ
３  業務プロセス
４ａ，４ｂ，４ｃ  実行フロー
【図１】
0004583289.tif 000002
【図２】
0004583289.tif 000003
【図３】
0004583289.tif 000004
【図４】
0004583289.tif 000005
【図５】
0004583289.tif 000006
【図６】
0004583289.tif 000007
【図７】
0004583289.tif 000008
【図８】
0004583289.tif 000009
【図９】
0004583289.tif 000010
【図１０】
0004583289.tif 000011
【図１１】
0004583289.tif 000012
【図１２】
0004583289.tif 000013
【図１３】
0004583289.tif 000014
【図１４】
0004583289.tif 000015
【図１５】
0004583289.tif 000016
【図１６】
0004583289.tif 000017
【図１７】
0004583289.tif 000018
【図１８】
0004583289.tif 000019
【図１９】
0004583289.tif 000020
【図２０】
0004583289.tif 000021
【図２１】
0004583289.tif 000022
【図２２】
0004583289.tif 000023
【図２３】
0004583289.tif 000024
【図２４】
0004583289.tif 000025
【図２５】
0004583289.tif 000026
【図２６】
0004583289.tif 000027
【図２７】
0004583289.tif 000028
【図２８】
0004583289.tif 000029
【図２９】
0004583289.tif 000030
【図３０】
0004583289.tif 000031
【図３１】
0004583289.tif 000032
【図３２】
0004583289.tif 000033
【図３３】
0004583289.tif 000034
【図３４】
0004583289.tif 000035
【図３５】
0004583289.tif 000036
【図３６】
0004583289.tif 000037
【図３７】
0004583289.tif 000038