サービス処理装置、システム、プログラム及び記録媒体
【課題】簡易な構成で、障害発生時のデータの整合性保証を容易に実現可能とする。
【解決手段】３段に分けられて連結された個々のサービス処理部に、サービスの処理状況を管理する管理部24、要求されたサービスに関する処理を行う処理実行部26を設けると共に、上位のサービス処理部が存在するサービス処理部に、サービス要求を受信し処理終了すると応答を返すサービス受付部28、処理結果確認要求を受信するとサービスの処理結果を確認して応答を返す処理結果確認部34を設け、下位のサービス処理部が存在するサービス処理部に、一意なサービスＩＤを生成するサービスＩＤ生成部30、下位サービスの実行が必要な場合に下位のサービス処理部へサービス要求を送信するサービス呼出部32、下位サービスの処理結果の確認が必要な場合に下位のサービス処理部へ処理結果確認要求を送信する結果確認呼出部36を設ける。
【解決手段】３段に分けられて連結された個々のサービス処理部に、サービスの処理状況を管理する管理部24、要求されたサービスに関する処理を行う処理実行部26を設けると共に、上位のサービス処理部が存在するサービス処理部に、サービス要求を受信し処理終了すると応答を返すサービス受付部28、処理結果確認要求を受信するとサービスの処理結果を確認して応答を返す処理結果確認部34を設け、下位のサービス処理部が存在するサービス処理部に、一意なサービスＩＤを生成するサービスＩＤ生成部30、下位サービスの実行が必要な場合に下位のサービス処理部へサービス要求を送信するサービス呼出部32、下位サービスの処理結果の確認が必要な場合に下位のサービス処理部へ処理結果確認要求を送信する結果確認呼出部36を設ける。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサービス処理装置、システム、プログラム及び記録媒体に係り、特に、要求されたサービスを実行するサービス処理装置、該サービス処理装置を複数備えたサービス処理システム、コンピュータを前記サービス処理装置として機能させるためのサービス処理プログラム、及び、当該サービス処理プログラムが記録された記録媒体に関する。
【背景技術】
【０００２】
近年、大規模なシステムを「サービス」の集まりとして構築する設計手法であるＳＯＡ(Service Oriented Architecture：サービス指向アーキテクチャ)が普及してきている。このＳＯＡに関連して特許文献１には、多くのデータベースを有するシステムにＳＯＡを適用して連携させる場合に、多くのデータベースに亘るデータ整合性の確立について述べられている。
【０００３】
また特許文献２には、ＳＯＡモデルを実現するウェブサービスを実行するコンピュータにおいて、認証・権限処理のための制御の流れをサービス提供処理の流れと独立して設けることにより、サービスと、そのサービスに対する認証・権限処理サービスの疎結合を実現する技術が開示されている。
【０００４】
また特許文献３には、サービスＩＤを含むサービス定義、ビジネスプロセスＩＤ及びサービスＩＤの対応情報を示しビジネスプロセス定義を格納しておき、入力されたサービスを検索キーとしてサービス定義を検索しサービスＩＤを取得し、当該サービスＩＤを検索キーとしてビジネスプロセス定義を検索しビジネスプロセスＩＤを取得し、対応する情報を出力する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００８−５１１９３４号公報
【特許文献２】特開２００６−７２５４８号公報
【特許文献３】特開２００７−３０４９５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＳＯＡを適用して構築されたコンピュータ・システムは、機能単位でプログラムが分割されると共に、分割した個々の機能のうちの一部機能を実現するプログラムが既に開発済みであれば、開発済みのプログラムを流用して構築されるので、互いに異なる機能を実現するプログラム（サービス処理部）が疎結合によって複数段連結され、コンピュータ・システムに入力された個々のサービス要求を複数段のサービス処理部が連携して処理する構成となることが一般的である。このような構成のコンピュータ・システムで障害が発生した場合、個々のサービス処理部が保持するデータや、異なるサービス処理部に接続されたデータベース(ＤＢ)が保持するデータに不整合が生じる可能性がある。
【０００７】
これに対し、サービス処理部が複数段連結された構成のコンピュータ・システムにデータの整合性を保証するための機能を設けようとすると、システムの設計や開発が非常に複雑となり、多大な工数を必要とするという問題がある。そして特許文献１〜３には、上述した問題を解決する技術は何ら開示されていない。
【０００８】
本発明は上記事実を考慮して成されたもので、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現できるサービス処理装置、サービス処理システム、サービス処理プログラム及び記録媒体を得ることが目的である。
【課題を解決するための手段】
【０００９】
上記目的を達成するために請求項１記載の発明に係るサービス処理装置は、コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能を備えている。
【００１０】
請求項１記載の発明に係るサービス処理装置はコンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成している。なお、サービス処理システムの典型的な構成は、個々のサービス処理装置が互いに異なるコンピュータによって実現される構成であるが、一部又は全てのサービス処理装置が同一のコンピュータによって実現される構成であってもよい。また、請求項１記載の発明に係るサービス処理装置は、以下で説明する第１機能〜第３機能を各々備えている。
【００１１】
すなわち、本発明に係る第１機能は、サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ下位サービスの処理結果を前記生成したサービスＩＤと対応付けて記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する機能である。ここで、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合（個々のサービス処理装置が上記の第１機能を各々備えている場合）、最上位のサービス処理装置に対してサービスの実行を要求すると、要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理が行われると共に、必要に応じて下位のサービス処理装置へサービス要求が送信され、当該サービス要求を受信したサービス処理装置でも必要に応じて下位にサービス処理装置へサービス要求が送信される。これにより、サービス処理装置の連結数等に拘わらず、サービスの実行が必要に応じて自動的に連鎖することになる。
【００１２】
また、本発明に係る第２機能は、サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する機能である。ここで、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合（個々のサービス処理装置が上記の第２機能を各々備えている場合）、最上位のサービス処理装置に対して処理結果の確認を要求すると、要求されたサービスに関する処理の処理結果が確認され、必要に応じて下位のサービス処理装置へ処理結果確認要求が送信され、当該処理結果確認要求を受信したサービス処理装置でも必要に応じて下位にサービス処理装置へ処理結果確認要求が送信される。これにより、サービス処理装置の連結数等に拘わらず、処理結果確認要求が必要に応じて自動的に連鎖した後に確認した処理結果が通知されるので、障害等の発生により以前のサービス要求に対する応答が返ってきていない等の場合に、以前に実行を要求したサービスの処理結果を確認することが可能となる。
【００１３】
また、本発明に係る第３機能は、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する機能である。
【００１４】
なお、冪等性を有するサービスは、何回実行しても同じ結果が得られるサービスであり、参照系のサービス(例えばデータベースからデータを読み出して出力するサービス等)がこれに該当する。一方、冪等性を有しないサービスは、実行する度に結果が変化するサービスであり、更新系のサービス(例えば実行の都度、データベースのデータに値を加算するサービス等)がこれに該当する。ここで、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合（個々のサービス処理装置が上記の第３機能を各々備えている場合）、仮想冪等機能（実際のサービスが冪等性を有しているか否かに拘わらず、サービスの実行が何度要求されても同じ結果が得られるようにする機能）が実現され、障害等の発生により以前に要求したサービスの実行に対する応答が返ってきていない等の場合に、対応する下位サービスの中に冪等性を有しないサービスが存在しているか否かを考慮せずに、サービスの実行を再度要求することが可能となるので、本発明に係るサービス処理装置を含んで構成されたサービス処理システムの構成を簡略化することが可能となる。また、冪等性を有する下位サービスを実行させる際には当該下位サービスの処理結果の確認が省略されるので、サービス処理装置を実現するコンピュータに加わる負荷を軽減することができる。
【００１５】
このように、請求項１記載の発明に係るサービス処理装置は、上述した第１機能〜第３機能が設けられていることで、障害発生時にデータの整合性を保証することを容易に実現することができる。また、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合、サービス処理システムを構成する個々のサービス処理装置の基本構成を同一とすることができるので、サービス処理システムを簡易な構成とすることができ、設計や開発に要する工数も大幅に削減することができる。従って、請求項１記載の発明によれば、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００１６】
請求項２記載の発明に係るサービス処理装置は、コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、を備え、前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させる。
【００１７】
請求項２記載の発明に係るサービス処理装置は、請求項１記載の発明と同様に、コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成している。また、請求項２記載の発明に係るサービス処理装置は、上記のサービス実行手段及び処理結果管理手段を各々備えている。
【００１８】
上記構成により、請求項２記載の発明に係るサービス処理装置に対してサービスの実行を要求すると、実行が要求されたサービスに関する処理がサービス実行手段で行われる。また、自装置よりも下位のサービス処理装置が存在し、実行が要求されたサービスが下位のサービス処理装置による下位サービスを含むサービスである場合、実行が要求されたサービスに関する処理として、サービスＩＤ生成手段によって下位サービスのサービスＩＤを生成させ、生成された下位サービスのサービスＩＤを付加したサービス要求をサービス呼出手段によって下位のサービス処理装置へ送信し、サービス呼出手段が下位のサービス処理装置から受信した応答によって通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させる処理が行われる。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、上位のサービス処理装置からのサービス要求をサービス受付手段で受信した個々のサービス処理装置において、受信したサービス要求に応じてサービス実行手段で上記処理が行われることが繰り返されることで、サービス処理装置の連結数等に拘わらず、サービスの実行が必要に応じて自動的に連鎖することになる。
【００１９】
また、自装置よりも上位のサービス処理装置が存在する場合、サービス実行手段は、サービスＩＤが付加されたサービス要求をサービス受付手段が上位のサービス処理装置から受信することで実行が要求されたサービスに関する処理を行い、当該処理の処理結果をサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させた後に、サービス受付手段によって上位のサービス処理装置へ応答を送信する。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、下位のサービス処理装置から応答を受信した個々のサービス処理装置において、サービス実行手段で上記処理が行われ、上位のサービス処理装置へ応答を送信することが繰り返されることで、サービス処理装置の連結数等に拘わらず、サービス要求に対する応答も自動的に連鎖することになる。
【００２０】
また、請求項２記載の発明に係るサービス処理装置は サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段を備えているが、処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合、サービスＩＤが付加された処理結果確認要求を処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認する。また、自装置よりも下位のサービス処理装置が存在し、かつ下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合、処理結果管理手段は、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を結果確認呼出手段によって下位のサービス処理装置へ送信する。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、上位のサービス処理装置からの処理結果確認要求を処理結果確認手段で受信した個々のサービス処理装置において、受信した処理結果確認要求に応じて処理結果管理手段で上記処理が行われることが繰り返されることで、サービス処理装置の連結数等に拘わらず、処理結果の確認要求が必要に応じて自動的に連鎖することになる。
【００２１】
また、自装置よりも下位のサービス処理装置が存在する場合、処理結果管理手段は、下位のサービス処理装置から結果確認呼出手段へ通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて記憶手段に記憶させる。また、自装置よりも上位のサービス処理装置が存在する場合、処理結果管理手段は、処理結果の確認が終了すると確認した処理結果を処理結果確認手段によって上位のサービス処理装置へ通知する。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、下位のサービス処理装置から結果確認呼出手段へ下位サービスの処理結果が通知された個々のサービス処理装置において、処理結果管理手段で上記処理が行われることが繰り返されることで、サービス処理装置の連結数等に拘わらず、処理結果の通知も自動的に連鎖することになり、障害等の発生により以前のサービス要求に対する応答が返ってきていない等の場合に、以前に実行を要求したサービスの処理結果を確認することが可能となる。
【００２２】
更に、請求項２記載の発明において、下位のサービス処理装置へのサービス要求の送信は、より詳しくは、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に冪等性を有する下位サービスが存在している場合、冪等性を有する下位サービスの処理結果を処理結果管理手段に確認することなく、冪等性を有する下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信することによって行われ、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に非冪等の下位サービスが存在している場合は、非冪等の下位サービスの処理結果を処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、非冪等の下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了するとサービス受付手段によってサービス要求の送信元の上位のサービス処理装置へ確認した処理結果に応じた応答が送信される。
【００２３】
これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合、仮想冪等機能が実現され、障害等の発生により以前に要求したサービスの実行に対する応答が返ってきていない等の場合に、対応する下位サービスの中に冪等性を有しないサービスが存在しているか否かを考慮せずに、サービスの実行を再度要求することが可能となるので、本発明に係るサービス処理装置を含んで構成されたサービス処理システムの構成を簡略化することが可能となる。また、冪等性を有する下位サービスを実行させる際には当該下位サービスの処理結果の確認が省略されるので、サービス処理装置を実現するコンピュータに加わる負荷を軽減することができる。
【００２４】
このように、請求項２記載の発明に係るサービス処理装置システムは、上記のサービス実行手段及び処理結果管理手段を備えているので、障害発生時にデータの整合性を保証することを容易に実現することができる。また、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合、サービス処理システムを構成する個々のサービス処理装置の基本構成を同一とすることができるので、サービス処理システムを簡易な構成とすることができ、設計や開発に要する工数も大幅に削減することができる。従って、請求項２記載の発明によれば、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００２５】
なお、請求項２記載の発明において、サービス実行手段は、例えば請求項３に記載したように、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在しており、かつサービス受付手段が上位のサービス処理装置からサービス要求を受信することで実行が要求されたサービスが、対応する下位サービスが存在しているサービスである場合、サービスＩＤ生成手段によって生成された下位サービスのサービスＩＤを付加したサービス要求をサービス呼出手段によって下位のサービス処理装置へ送信すると共に、サービス呼出手段が下位のサービス処理装置から応答を受信した後に、サービス受付手段によって上位のサービス処理装置へ応答を送信するように構成することができる。
【００２６】
また、請求項２又は請求項３記載の発明において、サービス実行手段は、例えば請求項４に記載したように、実行が要求されたサービスが自サービスを含むサービスである場合に、実行が要求されたサービスに関する処理として、自サービスの処理を行い、自サービスの処理結果を通知されたサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させるように構成することができる。
【００２７】
また、請求項２〜請求項４の何れかに記載の発明において、サービス実行手段は、例えば請求項５に記載したように、自装置よりも下位のサービス処理装置が複数存在する場合、サービス呼出手段を下位のサービス処理装置と同数個備えており、自装置よりも下位のサービス処理装置が複数存在し、かつ実行が要求されたサービスが複数の下位のサービス処理装置による複数の下位サービスを含むサービスである場合に、実行が要求されたサービスに関する処理として、複数の下位のサービス処理装置のうちの特定の下位のサービス装置による特定の下位サービスのサービスＩＤをサービスＩＤ生成手段によって生成させ、生成された下位サービスのサービスＩＤを付加したサービス要求を、特定の下位のサービス装置に対応する特定のサービス呼出手段によって特定の下位のサービス処理装置へ送信し、特定のサービス呼出手段が特定の下位のサービス処理装置から受信した応答によって通知された特定の下位サービスの処理結果を、特定の下位サービスのサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させる処理を、複数の下位のサービス処理装置について各々行う（逐次行うようにしてもよいし、並列に行うようにしてもよい）ように構成することができる。これにより、単一のサービス処理装置の下位にサービス処理装置が複数存在している場合にも、複数存在している下位のサービス処理装置の各々に対し、サービスの実行を自動的に連鎖させることができる。
【００２８】
また、請求項５記載の発明において、サービス実行手段は、例えば請求項６に記載したように、複数の下位のサービス処理装置のうちの何れかからの応答によって通知された下位サービスの処理結果がエラーであった場合、複数の下位のサービス処理装置の中に要求された下位サービスが「処理済」の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応するサービス呼出手段により、「処理済」の下位サービスの取消を要求するサービス要求を、下位サービスが「処理済」の下位のサービス処理装置へ送信させるように構成することが好ましい。実行が要求されたサービスが複数の下位のサービス処理装置による複数の下位サービスを含むサービスである場合、複数の下位サービスが全て正常に処理されないとデータの不整合等の不具合が生ずる可能性がある。これに対して請求項６記載の発明では、「処理済」の下位サービスの取消を要求するサービス要求を対応する下位のサービス処理装置へ送信させるので、複数の下位サービスを含むサービスの実行が要求され、複数の下位サービスのうちの一部の下位サービスでエラーが発生した場合に、データの不整合等の不具合が発生することを自動的に防止することができる。
【００２９】
また、請求項５記載の発明において、サービス実行手段は、例えば請求項７に記載したように、複数の下位のサービス処理装置のうちの何れかからの応答によって通知された下位サービスの処理結果がエラーであった場合、複数の下位のサービス処理装置の中にサービス要求を未送信の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応するサービス呼出手段によるサービス要求の送信を中止するように構成してもよい。これにより、複数の下位サービスを含むサービスの実行が要求され、複数の下位サービスのうちの一部の下位サービスでエラーが発生した場合に、下位サービスの実行を要求するサービス要求が無駄に送信されることを防止することができる。
【００３０】
また、請求項２〜請求項７の何れかに記載の発明において、自装置よりも下位のサービス処理装置が存在し、コンピュータをサービス処理装置として機能させるためのプログラムがＢＰＥＬのプラットフォーム上で動作する場合、サービス実行手段は、例えば請求項８に記載したように、サービスＩＤが通知されてサービスの実行が要求される毎に生成され、通知されたサービスＩＤを保持すると共に、処理の進行状態を表す状態情報を記憶しかつ処理の進行状態の変化に応じて前記状態情報を適宜更新するインスタンスよって実現され、前記インスタンスが新たに生成される毎に、当該新たに生成されたインスタンスにおいて、過去に生成され同一のサービスＩＤを保持しているインスタンスを検索し、該当するインスタンスが存在していた場合は前記該当するインスタンスの状態情報を自インスタンスの状態情報として複写し、複写した状態情報に従って処理を行うように構成することが好ましい。これにより、コンピュータをサービス処理装置として機能させるためのプログラムがＢＰＥＬのプラットフォーム上で動作する構成において、以前に実行が要求されたサービスの実行が再度要求され、前回の処理が途中で停止していた場合に、今回の処理を前回の処理の続きから開始することを、ＢＰＥＬのプラットフォームの特徴を利用して簡易な処理で実現することができる。
【００３１】
また、請求項２記載の発明において、処理結果管理手段は、例えば請求項９に記載したように、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在し、かつ処理結果確認手段が上位のサービス処理装置から処理結果確認要求を受信することで処理結果の確認が要求されたサービスに対応する下位サービスが存在しており、かつ記憶手段に記憶されている対応する下位サービスの処理結果が「不明」の場合に、下位サービスのサービスＩＤを付加した処理結果確認要求を結果確認呼出手段によって下位のサービス処理装置へ送信し、下位のサービス処理装置から結果確認呼出手段へ処理結果が通知された後に、処理結果の確認が要求されたサービスの処理結果を処理結果確認手段によって上位のサービス処理装置へ通知するように構成することができる。
【００３２】
また、請求項２〜請求項９の何れかに記載の発明において、サービスＩＤ生成手段は、例えば請求項１０に記載したように、サービス処理装置毎に相違するＩＤを設定した固有ＩＤと、サービス要求毎に相違するＩＤを設定した要求ＩＤを含むＩＤ要素を生成するＩＤ要素生成手段と、自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を各々設定した呼出元ＩＤ及び呼出先ＩＤを含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤに呼出先ＩＤとして設定されているＩＤ要素を設定した呼出元ＩＤと、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定した呼出先ＩＤを含むサービスＩＤを生成するＩＤ要素組合せ手段と、を含んで構成されていることが好ましい。
【００３３】
これにより、ＩＤ要素生成手段によって生成される個々のＩＤ要素は、少なくともサービス処理装置（ＩＤ要素生成手段）を単位とする一意性が確保される（他のＩＤ要素と重複していないことが保証される）と共に、サービス処理装置（ＩＤ要素生成手段）内における個々のサービス要求を単位とする一意性も確保される。また、サービス処理システムを構成する個々のサービス処理装置に請求項１０記載の発明を各々適用した場合、上位のサービス処理装置が存在する個々のサービス処理装置において、上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤにおける呼出先ＩＤと、下位のサービス処理装置へ送信するサービス要求に付加されるサービスＩＤにおける呼出元ＩＤが一致されることになるので、障害等が発生した場合にも、個々のサービス処理装置の処理結果管理手段の記憶手段に記憶されているサービスＩＤを参照し、呼出先ＩＤと呼出元ＩＤが一致しているサービスＩＤ（対応するサービス要求に付加されたサービスＩＤ）を順に辿っていくことで、実行が要求されたサービスの処理履歴を把握することが可能となる。
【００３４】
また、請求項１０記載の発明において、ＩＤ要素組合せ手段は、例えば請求項１１に記載したように、自装置よりも上位のサービス処理装置が存在しない場合は、ＩＤ要素生成手段によって生成されたＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤにオリジナルＩＤとして設定されているＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成するように構成することが好ましい。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項１１記載の発明を各々適用した場合、対応するサービス要求に付加されるサービスＩＤはオリジナルＩＤが同一とされることになるので、個々のサービス要求に付加されたサービスＩＤのうちのオリジナルＩＤが同一か否かに基づいて、対応するサービス要求を識別することができ、前述のようにサービスＩＤの呼出元ＩＤ及び呼出先ＩＤに設定されているＩＤ要素に基づいて同一のサービス要求を辿っていくことが困難となった場合にも、オリジナルＩＤを参照することで、要求されたサービスの処理履歴を確実に把握することができる。
【００３５】
また、請求項１０又は請求項１１記載の発明において、ＩＤ要素生成手段は、例えば請求項１２に記載したように、コンピュータをサービス処理装置として機能させるためのプログラムの実行単位に付与された実行単位ＩＤも含むＩＤ要素を生成するように構成することが好ましい。なお、上記の実行単位は、例えばプロセス、タスク、スレッド等の何れであってもよい。これにより、上記の実行単位が単一のコンピュータ内に複数存在している場合にも、個々の実行単位（サービス処理装置）によってサービス要求に付加されるサービスＩＤ（の少なくとも実行単位ＩＤ）が相違することになり、サービス要求に付加されたサービスＩＤのうちの実行単位ＩＤを参照することで、対応するサービス要求が複数のサービス処理装置のうちの何れの実行単位（サービス処理装置）で処理されたのかを判断することが可能となる。
【００３６】
また、請求項１３記載の発明に係るサービス処理システムは、請求項１〜請求項１２の何れか１項記載のサービス処理装置が情報を送受可能に複数設けられて構成されているので、請求項１記載の発明や請求項２記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００３７】
請求項１４記載の発明に係るサービス処理プログラムは、コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、前記コンピュータを、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、を備え、前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させるサービス処理装置として機能させる。
【００３８】
請求項１４記載の発明に係るサービス処理プログラムは、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータを、上記のサービス実行手段及び処理結果管理手段を備えたサービス処理装置として機能させるためのプログラムであるので、前記コンピュータが請求項１４記載の発明に係るサービス処理プログラムを実行することで、前記コンピュータが請求項２に記載のサービス処理装置として機能することになり、請求項２記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００３９】
請求項１５記載の発明に係るサービス処理プログラムは、コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、前記コンピュータを、請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能させる。
【００４０】
請求項１５記載の発明に係るサービス処理プログラムは、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータを、請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能させるためのプログラムであるので、前記コンピュータが請求項１５記載の発明に係るサービス処理プログラムを実行することで、前記コンピュータが請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能することになり、請求項２〜請求項１２の何れか１項記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００４１】
請求項１６記載の発明に係る記録媒体は、コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムが記録された記録媒体であって、前記サービス処理プログラムは、前記コンピュータを、サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能を備えたサービス処理装置として機能させる。
【００４２】
請求項１６記載の発明に係る記録媒体は、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータを、上記の第１〜第３機能を備えたサービス処理装置として機能させるためのサービス処理プログラムが記録されているので、前記コンピュータが請求項１６記載の発明に係る記録媒体に記録されているサービス処理プログラムを読み出して実行することで、前記コンピュータが請求項１に記載のサービス処理装置として機能することになり、請求項１記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００４３】
請求項１７記載の発明に係る記録媒体は、請求項１４又は請求項１５記載のサービス処理プログラムが記録されている。これにより、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータが請求項１７記載の発明に係る記録媒体に記録されているサービス処理プログラムを読み出して実行することで、前記コンピュータが請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能することになり、請求項２〜請求項１２の何れかに記載の記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【発明の効果】
【００４４】
以上説明したように本発明は、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置に、サービスの実行の連鎖を実現する第１機能、以前に実行を要求したサービスの処理結果の確認を可能とする第２機能、及び、障害等の発生時に冪等性を有しないサービスの存在を考慮せずにサービスの実行を再度要求することを可能とする第３機能を各々設けたので、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる、という優れた効果を有する。
【００４５】
また本発明は、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置に、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段を設け、サービス実行手段を、自装置よりも上位のサービス処理装置が存在する場合に、自装置よりも上位のサービス処理装置が存在する場合に、サービス受付手段が上位のサービス処理装置からサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理を行い、処理結果をサービスＩＤと対応付けて記憶手段に記憶させた後に、サービス受付手段によって上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在し、下位のサービス処理装置による下位サービスを含むサービスの実行が要求された場合に、サービスＩＤ生成手段によって下位サービスのサービスＩＤを生成させ、生成されたサービスＩＤを付加したサービス要求をサービス呼出手段によって前記下位のサービス処理装置へ送信し、サービス呼出手段が下位のサービス処理装置から受信した応答によって通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に冪等性を有する下位サービスが存在している場合、冪等性を有する下位サービスの処理結果を処理結果管理手段に確認することなく、冪等性を有する下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に非冪等の下位サービスが存在している場合は、非冪等の下位サービスの処理結果を処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、処理結果管理手段により非冪等の下位サービスを行うサービス処理装置へ処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、非冪等の下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信した後に、非冪等の下位サービスの処理結果を処理結果管理手段に再度確認する処理を行い、当該処理が終了するとサービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信するように構成すると共に、処理結果管理手段を、自装置よりも上位のサービス処理装置が存在する場合に、サービスＩＤが付加された処理結果確認要求を処理結果確認手段が上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果をサービスＩＤに基づいて確認し、処理結果の確認が終了すると処理結果を処理結果確認手段によって上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在し、かつ下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した結果確認要求を結果確認呼出手段によって下位のサービス処理装置へ送信し、下位のサービス処理装置から結果確認呼出手段へ通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて記憶手段に記憶させるように構成したので、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる、という優れた効果を有する。
【図面の簡単な説明】
【００４６】
【図１】本実施形態に係るサービス処理システムのハードウェア構成を示す概略ブロック図である。
【図２】ＳＯＡリファレンスモデルを説明する説明図である。
【図３】サービス要求受信時のサービス処理部の処理シーケンスを説明する概念図である。
【図４】処理結果確認要求受信時のサービス処理部の処理シーケンスを説明する概念図である。
【図５】本実施形態に係るサービス処理システムのソフトウェア構成を示す機能ブロック図である。
【図６】サービス受付部処理を示すフローチャートである。
【図７】処理実行部処理の一例(冪等呼び出し、補償無し)を示すフローチャートである。
【図８】処理実行部処理の一例(冪等呼び出し、補償無し、内部リトライ)を示すフローチャートである。
【図９】処理実行部処理の一例(冪等呼び出し、補償有り)を示すフローチャートである。
【図１０】処理実行部処理の一例(非冪等呼び出し、補償有り、内部リトライ)を示すフローチャートである。
【図１１】サービスＩＤ生成部処理を示すフローチャートである。
【図１２】サービス呼出部処理を示すフローチャートである。
【図１３】処理結果確認部処理を示すフローチャートである。
【図１４】管理部処理を示すフローチャートである。
【図１５】結果確認呼出部処理を示すフローチャートである。
【図１６】サービスＩＤの体系及び遷移の一例を示す概念図である。
【図１７】サービスＩＤにおけるＯＳＩＤの有効性を説明するための説明図である。
【図１８】ＢＰＥＬにおける仮想冪等機能の実現を説明する説明図である。
【図１９】サービスの実行が指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。
【図２０】サービスの実行が指示された場合のサービス処理システム全体のシーケンスの他の例を示すシーケンス図である。
【図２１】サービスの実行が指示された場合のサービス処理システム全体のシーケンスの他の例を示すシーケンス図である。
【図２２】サービスの実行が複数回指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。
【図２３】処理結果の確認が指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。
【発明を実施するための最良の形態】
【００４７】
以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には本実施形態に係るサービス処理システム１０が示されている。サービス処理システム１０は、複数台のサービス処理サーバ１２及び複数台のアプリケーション・サーバ１４がコンピュータ・ネットワーク１６を介して接続されて構成されている。
【００４８】
個々のアプリケーション・サーバ１４は、ＣＰＵ１４Ａ、ＲＯＭやＲＡＭ等から成るメモリ１４Ｂ、ＨＤＤ(Hard Disk Drive)等から成る記憶部１４Ｃ、ネットワークＩ／Ｆ(インタフェース)部１４Ｄを各々備えており、ネットワークＩ／Ｆ部１４Ｄを介してコンピュータ・ネットワーク１６に接続されている。個々のアプリケーション・サーバ１４は、既存の別のコンピュータ・システムの一部を構成するコンピュータであり（なお既存の別のコンピュータ・システムとしては、例えば金融機関の基幹系システム(預為システムやその他のパッケージ・システム)が挙げられる）、個々のアプリケーション・サーバ１４の記憶部１４Ｃには、既存の別のコンピュータ・システム向けに所定のサービスを提供するための互いに異なるアプリケーション・プログラムがインストールされている。
【００４９】
一方、個々のサービス処理サーバ１２は、ＣＰＵ１２Ａ、ＲＯＭやＲＡＭ等から成るメモリ１２Ｂ、ＨＤＤ等から成る記憶部１２Ｃ、ネットワークＩ／Ｆ(インタフェース)部１２Ｄを各々備えており、ネットワークＩ／Ｆ部１２Ｄを介してコンピュータ・ネットワーク１６に接続されている。また、記憶部１２Ｃにはサービス処理プログラムがインストールされており、更に処理状況テーブル(後述)も記憶されている。サービス処理プログラムは本発明に係るプログラムに対応しており、サービス処理サーバ１２は、ＣＰＵ１２Ａがサービス処理プログラムを実行することで、後述するサービス処理部（本発明に係るサービス処理装置）として機能する。
【００５０】
なお、図１では、複数台のサービス処理サーバ１２のうち最上位のサービス処理部として機能するサービス処理サーバ１２に、最上位のサービス処理部に対してサービスの実行を要求することを可能とする機器の一例として、オペレータが任意の情報を入力可能なキーボード１８と、任意の情報を表示可能なディスプレイ２０が接続された態様を示している。この態様では、オペレータがキーボード１８を操作することで、オペレータから最上位のサービス処理部へサービスの実行が要求され、実行が要求されたサービスの処理結果はディスプレイ２０に表示されてオペレータに視認される。但し、本発明は図１に示した態様に限られるものではなく、最上位のサービス処理部として機能するサービス処理サーバ１２には、最上位のサービス処理部に対してサービスの実行を要求する機器が接続されていてもよい。前記サービスの実行を要求する機器としては、例えばバッチジョブのコントローラや、他のコンピュータ・システム、インターネット、ウェブサーバ等が挙げられる。この態様では、前記機器から最上位のサービス処理部へサービスの実行がオペレータの操作等を経ずに直接要求され、実行が要求されたサービスの処理結果は最上位のサービス処理部から前記機器へ直接通知される。
【００５１】
次に本実施形態の作用を説明する。本実施形態に係るサービス処理システム１０は、ＳＯＡを適用し、提供すべきサービスを機能単位で分割し、分割した個々の機能のうち開発済みの機能（本実施形態では、サービス処理システム１０に接続された個々のアプリケーション・サーバ１４が提供するサービスがそれに相当する）についてはそれを流用して構築されており、互いに異なる機能を実現するサービス処理サーバ１２（によって実現されるサービス処理部）が疎結合によって複数段連結され、サービス処理システム１０に入力された個々のサービス要求を複数段のサービス処理部が連携して処理する構成とされている。また、本実施形態に係るサービス処理システム１０は、個々のサービス処理サーバ１２によって実現されるサービス処理部が図２に示すリファレンスモデルに準拠した構成となるように、個々のサービス処理サーバ１２の記憶部１２Ｃにインストールされるサービス処理プログラムが開発されている。
【００５２】
以下、まずサービス処理部のリファレンスモデルについて説明する。このリファレンスモデルでは、サービス処理部を、管理部２４、処理実行部２６、サービス受付部２８、サービスＩＤ生成部３０、サービス呼出部３２、処理結果確認部３４及び結果確認呼出部３６の各機能ブロックに分割し、各機能ブロック毎の機能を規定することで、サービス処理システム１０における障害等の発生時にデータの整合性を保証することを可能とするためにサービス処理部が備えているべき機能を規定している。
【００５３】
サービス処理部のリファレンスモデルにおいて、管理部２４は、処理状況テーブル３８を記憶する記憶部(ここでいう記憶部は、記憶部１２Ｃの記憶領域のうち処理状況テーブル３８等を記憶するために管理部２４に割当てられた記憶領域を指す)を備え、サービス処理部に対して実行が要求されたサービス（に対応する自サービス及び下位サービス）の処理結果を、前記サービスを識別するサービスＩＤと対応付けて処理状況テーブル３８で管理すると共に、下位サービスの処理結果の確認が必要な場合は、下位サービスの処理結果の確認を結果確認呼出部３６へ要求する機能を備えている。また処理実行部２６は、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに対応する自サービスが有れば自サービスの処理を実行し、対応する下位サービスが有ればサービスＩＤ生成部３０でサービスＩＤを生成させ、下位サービスの実行をサービス呼出部３２へ要求する機能を備えている。
【００５４】
また、サービス受付部２８は上位のサービス処理部が存在している場合に設けられ、サービスＩＤが付加されたサービス要求を上位のサービス処理部から受信することでサービスの実行が要求されると、実行が要求されたサービスの実行を処理実行部２６に要求し、処理終了後に上位のサービス処理部へ応答を送信する機能を備えている。また、サービスＩＤ生成部３０は下位のサービス処理部が存在している場合に設けられ、処理実行部２６からの要求に応じて一意性を有するサービスＩＤを生成する機能を備えている。また、サービス呼出部３２は下位のサービス処理部が存在している場合に下位のサービス処理部と同数個設けられ、処理実行部２６からの要求に応じて下位サービスのサービスＩＤを付加したサービス要求を下位のサービス処理部へ送信する機能を備えている。
【００５５】
また、処理結果確認部３４は上位のサービス処理部が存在している場合に設けられ、サービスＩＤが付加された処理結果確認要求を上位のサービス処理部から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果をサービスＩＤを用いて管理部２４に確認し、処理結果の確認が終了すると確認した処理結果を上位のサービス処理部へ通知する機能を備えている。更に、結果確認呼出部３６は下位のサービス処理部が存在している場合に下位のサービス処理部と同数個設けられ、要求に応じて、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理部へ送信する機能を備えている。
【００５６】
次に、サービス処理部の各機能ブロック（管理部２４、処理実行部２６、サービス受付部２８、サービスＩＤ生成部３０、サービス呼出部３２、処理結果確認部３４及び結果確認呼出部３６）が上述した機能を備えていることで実現される、サービス処理部内における典型的な処理シーケンスを説明する。
【００５７】
上位のサービス処理部が存在するサービス処理部が、上位のサービス処理部からサービス要求を受信した場合、サービス要求を受信したサービス処理部では、各機能ブロックが連動することで図３に示す処理シーケンスで処理が行われる。すなわち、上位のサービス処理部からサービスＩＤが付加されたサービス要求を受信すると((1)参照)、サービス受付部２８は、処理実行部２６に対してサービスＩＤを通知してサービスの実行を要求する((2)参照)。処理実行部２６は実行が要求されたサービスの処理結果を管理部２４に確認する((3)参照)。そして、確認した処理結果が「処理済」であればサービス受付部２８へ直ちに応答を返す((12)参照)が、確認した処理結果が「未済」で、かつ実行が要求されたサービスに対応する自サービスが存在している場合は、自サービスの処理を実行し、処理結果をサービスＩＤと対応付けて処理状況テーブル３８に記録させる((4)参照）。
【００５８】
また、実行が要求されたサービスに対応する下位サービスが存在しており、かつ当該下位サービスが「処理済」でない場合、処理実行部２６はサービスＩＤ生成部３０によって下位サービスのサービスＩＤを生成させ((5)参照)、生成された下位サービスのサービスＩＤを処理状況テーブル３８に記録させ((6)参照)、。サービス呼出部３２に対して下位サービスのサービスＩＤを通知して下位サービスの実行を要求する((7)参照)。これにより、サービス呼出部３２は通知された下位サービスのサービスＩＤを付加したサービス要求を下位のサービス処理部へ送信する((8)参照)。また、下位のサービス処理部から応答を受信すると((9)参照)、受信した応答によって通知された下位サービスの処理結果を処理状況テーブル３８に記録させ((10)参照）、処理終了を処理実行部２６へ通知する((11)参照)。これを受けて処理実行部２６はサービス受付部２８へ処理結果を通知し((12)参照)、サービス受付部２８は上位のサービス処理部へ応答を送信することで処理結果を通知する((13)参照)。
【００５９】
また、上位のサービス処理部が存在するサービス処理部が、上位のサービス処理部から処理結果確認要求を受信した場合、サービス要求を受信したサービス処理部では、各機能ブロックが連動することで図４に示す処理シーケンスで処理が行われる。すなわち、上位のサービス処理部から処理結果確認要求を受信すると((1)参照)、処理結果確認部３４は、受信した処理結果確認要求によって処理結果の確認が要求されたサービスに対応する各サービスの処理結果を管理部２４に確認する((2)参照)。そして、対応する各サービスの中に処理結果が「不明」の下位サービスが無ければ上位のサービス処理部へ直ちに応答を返す((8)参照)が、処理結果が「不明」の下位サービスが存在している場合は、対応する結果確認呼出部３６に対し、下位サービスの処理結果の確認を要求する((3)参照)。
【００６０】
結果確認呼出部３６は、下位サービスの処理結果の確認が要求されると、下位のサービス処理部へ処理結果確認要求を送信する((4)参照)。また、下位のサービス処理部から下位サービスの処理結果を通知する応答を受信すると((5)参照)、通知された下位サービスの処理結果を処理状況テーブル３８に記録させ((6)参照)、管理部２４から処理結果確認部３４に確認された処理結果が通知される((7)参照)。これを受けて処理結果確認部３４は、通知された下位サービスの処理結果を含む処理結果を通知する応答を上位のサービス処理部へ送信する((8)参照）。
【００６１】
次に図５を参照し、上記のサービス処理部のリファレンスモデルに準拠して構築されたサービス処理システム１０のソフトウェアの構成の一例を説明する。図５に示すように、本実施形態に係るサービス処理システム１０は、５個のサービス処理部が３層(３段)に分けられており、３層目(３段目)の３個のサービス処理部が２層目(２段目)の単一のサービス処理部に各々連結され、２層目(２段目)の単一のサービス処理部が１層目(１段目)の単一のサービス処理部に連結されて構成されている。
【００６２】
１層目(最上位)のサービス処理部は、より上位のサービス処理部が存在しないため、サービス処理部のリファレンスモデルに対してサービス受付部２８及び処理結果確認部３４が省略されている。なお、以下では最上位のサービス処理部を便宜上「リクエスタ４２」と称する。リクエスタ４２として機能するサービス処理サーバ１２にキーボード１８及びディスプレイ２０が接続されている場合、リクエスタ４２は、オペレータによってキーボード１８が操作されることで入力された指示に応じて、下位のサービス処理部へサービス要求や処理結果確認要求を送信すると共に、下位のサービス処理部からの応答に基づきディスプレイ２０に処理結果等を表示する処理を行う。なお、リクエスタ４２として機能するサービス処理サーバ１２にサービスの実行を要求する機器(例えばバッチジョブのコントローラや、他のコンピュータ・システム、インターネット、ウェブサーバ等)が接続されている場合には、リクエスタ４２により、前記機器から要求を受信し、受信した要求に応じて下位のサービス処理部へサービス要求や処理結果確認要求を送信すると共に、下位のサービス処理部からの応答に基づき処理結果等を前記機器へ通知する処理が行われることになる。
【００６３】
また、２層目のサービス処理部は、下位のサービス処理部が３個存在しているため、サービス呼出部３２及び結果確認呼出部３６の組が３組設けられている。本実施形態では、２層目のサービス処理部のプログラムが、ＢＰＥＬエンジンと称されるＢＰＥＬ(Business Process Execution Language)のプラットフォーム上で動作するプログラムとして開発されており、２層目のサービス処理部として機能するサービス処理サーバ１２の記憶部１２Ｃには、上記のプラットフォームとして機能する所定のプログラムもインストールされている。以下では２層目のサービス処理部を便宜上「ＢＰＥＬ４４」と称する。ＢＰＥＬ４４は、リクエスタ４２から受信したサービス要求や処理結果確認要求に従い、下位の個々のサービス処理部へサービス要求や処理結果確認要求を送信したり、障害発生時にデータの整合性を保証するための処理を行う。
【００６４】
また３層目には、３個のサービス処理部として、既存の別のコンピュータ・システム(のアプリケーション・サーバ１４)と接続されていないサービス処理部と、既存の別のコンピュータ・システムとしてのパッケージ・システム６６(のアプリケーション・サーバ１４)と接続されたサービス処理部と、既存の別のコンピュータ・システムとしての預為システム６８(のアプリケーション・サーバ１４)と接続されたサービス処理部が存在している。これらのサービス処理部は、より下位のサービス処理部が存在しないため、サービス処理部のリファレンスモデルに対してサービス呼出部３２及び結果確認呼出部３６が省略されている。
【００６５】
３層目の３個のサービス処理部のうち、既存システムと接続されていないサービス処理部は、処理実行部２６によって行われる処理単独で一定のサービスが実現されるサービス処理部であり、以下では当該サービス処理部を便宜上「プロバイダ４６」と称する。
【００６６】
また３層目の３個のサービス処理部のうち、パッケージ・システム６６(のアプリケーション・サーバ１４)と接続されたサービス処理部には、サービス処理システム１０とパッケージ・システム６６とのインタフェースを司る機能ブロックとして、サービス処理システム１０内のサービスＩＤを代替するＩＤとしてパッケージ・システム６６固有のＩＤの採番を行うＩＤ変換部５２と、データ形式の相互変換を行う機能を各々備えパッケージ・システム６６と通信を行うことでサービスを実行させたり処理結果の確認を行うパッケージ呼出部５４及び結果確認呼出部５６が設けられている。以下では当該サービス処理部を便宜上「パッケージ・ラッパー４８」と称する。
【００６７】
また３層目の３個のサービス処理部のうち、預為システム６８(のアプリケーション・サーバ１４)と接続されたサービス処理部には、サービス処理システム１０と預為システム６８とのインタフェースを司る機能ブロックとして、サービス処理システム１０内のサービスＩＤを代替するＩＤとして預為システム６８固有のＩＤである端末番号の採番を行う端末管理部５８と、データ形式の相互変換を行う機能を各々備え預為システム６８と通信を行うことでサービスを実行させたり処理結果の確認（取引状況の照会）を行うＭＢ通信部６０及び取引状況照会部６２が設けられている。以下では当該サービス処理部を便宜上「ＭＢラッパー５０」と称する。
【００６８】
なお、本実施形態では説明の都合上、サービス処理システム１０の３層目のサービス処理部であるプロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０のうち、プロバイダ４６によって提供されるサービスと、ＭＢラッパー５０(及び預為システム６８)によって提供されるサービスは冪等性を有している一方、パッケージ・ラッパー４８(及びパッケージ・システム６６)によって提供されるサービスは冪等性を有していないものとする。なお、冪等性を有するサービスは何度実行しても結果が同じになるサービスであり、例えばＤＢ(データベース)の一定領域に格納されているデータを読み出して出力するサービス等が挙げられる。また、冪等性を有しないサービス（非冪等のサービス）は実行の度に結果が相違するサービスであり、例えばＤＢの一定領域に格納されている数値を実行の度に１ずつインクリメントして結果を出力するサービス等が挙げられる。
【００６９】
また、図５において、サービス受付部２８は本発明に係るサービス受付手段に、サービスＩＤ生成部３０は本発明に係るサービスＩＤ生成手段に、サービス呼出部３２は本発明に係るサービス呼出手段に、処理実行部２６、サービス受付部２８、サービスＩＤ生成部３０及びサービス呼出部３２は本発明に係る処理実行手段に、処理結果確認部３４は本発明に係る処理結果確認手段に、結果確認呼出部３６は本発明に係る結果確認呼出手段に、管理部２４、処理結果確認部３４及び結果確認呼出部３６は本発明に係る処理結果管理手段に各々対応している。また、ＢＰＥＬ４４、プロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０は本発明に係る「上位のサービス処理装置が存在するサービス処理装置」に対応しており、リクエスタ４２及びＢＰＥＬ４４は本発明に係る「下位のサービス処理装置が存在するサービス処理装置」に対応している。
【００７０】
次に、サービス処理部の各機能ブロックにおける処理について、図６〜図１５のフローチャートを参照して説明する。上位のサービス処理部が存在するサービス処理部は、上位のサービス処理部から、サービスの実行を要求するサービス要求及び実行を要求したサービスの処理結果の確認を要求する処理結果確認要求を受信するが、上位のサービス処理部が存在するサービス処理部にはサービス受付部２８が設けられており、このサービス受付部２８は、上位のサービス処理部からサービス要求を受信する際に図６に示すサービス受付部処理を行う。
【００７１】
このサービス受付部処理では、まずステップ８０で上位のサービス処理部からサービス要求の電文を受信し、次のステップ８２において、上位のサービス処理部からサービス要求の電文を受信したことを表すステータス情報を、受信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。なお、受信した電文には、実行が要求されたサービスのサービスＩＤが付加されており、上記処理によりサービスＩＤも処理状況テーブル３８に記憶される。次のステップ８４では受信した電文の内容をチェックし、受信した電文の内容を適正か否か判定する。判定が否定された場合はステップ８６へ移行し、上位のサービス処理部へ送信する応答電文にエラーメッセージを設定し、ステップ９０へ移行する。
【００７２】
一方、受信した電文の内容が適正であった場合は、ステップ８４の判定が肯定されてステップ８８へ移行し、受信したサービス要求の電文に付加されていたサービスＩＤを引数として処理実行部２６のＡＰＩを呼び出し、サービスの実行を要求する。これにより、処理実行部２６で処理実行部処理(後述)が行われる。処理実行部２６による処理実行部処理が終了し、実行を要求したサービスの処理結果が通知されると、通知された処理結果を上位のサービス処理部へ送信する応答電文に設定した後にステップ９０へ移行する。ステップ９０では、ステップ８６又はステップ８８で生成した応答電文を上位のサービス処理部へ送信する。またステップ９２では、上位のサービス処理部へ応答電文を送信したことを表すステータス情報を、送信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させ、サービス受付部処理を終了する。
【００７３】
次に、サービスの実行が要求されると処理実行部２６で行われる処理実行部処理について説明する。なお、処理実行部処理の内容は、上位のサービス処理部の有無や、下位のサービス処理部の有無及び数、下位のサービス処理部による下位サービスの冪等性の有無、サービスの実行を要求する呼び出しが仮想冪等機能(実際のサービスが冪等性を有しているか否かに拘わらず、サービスの実行が何度要求されても同じ結果が得られるようにする機能)を利用する呼び出し(以下、これを冪等呼び出しと称する)か仮想冪等機能を利用しない呼び出し(以下、これを非冪等呼び出しと称する)か、補償処理(後述)を行うか否か、等の条件に応じて大きく相違する。このため、以下では処理実行部処理の一例として、ＢＰＥＬ４４の処理実行部２６における代表的な処理を、図７〜図１０を参照して順に説明する。なお、図７〜図１０に示した処理実行部処理は、何れも、プロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０の各々による下位サービスの実行を必要とするサービスの実行が要求されることを前提としている。なお、処理実行部２６の呼び出し時には引数として冪等フラグ(ＦＬＧ)も処理実行部２６に引き渡され、この冪等フラグの値が１か０かによって冪等呼び出しと非冪等呼び出しが区別される。
【００７４】
図７に示す処理実行部処理は、ＢＰＥＬ４４の処理実行部２６に対して冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行わない、という条件での処理実行部処理の一例である。図７に示す態様では、処理実行部２６のプログラムが、処理実行部ＡＰＩと業務プログラムに分かれている。処理実行部ＡＰＩは、処理実行部２６の機能を実現する処理のうちの定型処理を行うプログラムであり、図７の例では、下位のサービス処理部(この例ではプロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０)からの応答のタイムアウトの監視(サービス要求を送信してから応答未受信の状態が規定時間以上継続したかを監視)、下位のサービス処理部へのサービス要求等のリトライ(例えば処理結果が「不明」等の場合のサービス要求の再送信等)、リトライ回数の監視(サービス要求等の送信回数が規定回数に達した場合に「異常」として処理する)等の処理が処理実行部ＡＰＩによって行われる。
【００７５】
なお、上記のように処理実行部のプログラムを処理実行部ＡＰＩと業務プログラムに分けることで、処理実行部ＡＰＩを部品化し、業務プログラムの処理内容が相違する処理実行部２６の開発する際にも、部品化した処理実行部ＡＰＩを流用することで、プログラム開発者が業務プログラムの開発に専念できるので、プログラム開発者の負担の軽減、プログラム開発に要する期間の短縮を実現することができる。
【００７６】
図７において、処理実行部２６のプログラムのうち業務プログラムによって実現される処理(以下、この処理を単に処理実行部処理と称する)は、処理実行部ＡＰＩ経由で外部から呼び出されることで起動される。仮想冪等機能を利用する冪等呼び出しでは、同一のサービスＩＤのサービスの実行が繰り返し要求される可能性があるので、まずステップ２００では、呼出時に引数として引き渡されたサービスＩＤを管理部２４に通知し、通知したサービスＩＤのサービスの実行が前回要求された際の処理結果(状況)を管理部２４に問い合わせる。次のステップ２０２では管理部２４から通知された情報に基づき、同一のサービスＩＤのサービスの実行が前回要求された際の処理が「処理中」か否か判定し、「処理中」であれば処理実行部ＡＰＩに制御を戻す。
【００７７】
また、同一のサービスＩＤのサービスの実行が前回要求された際の処理が「処理中」でない場合(引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていない場合や、同一のサービスＩＤのサービスの実行が前回要求された際の処理が終了している場合がこの条件に該当する)はステップ２０４へ移行する。下位サービス１は冪等性を有しているので、ステップ２０４では、下位サービス１の処理状況に拘わらず(下位サービス１が今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスとして過去に実行されているか否かや、下位サービス１が今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスとして過去に実行されている場合の処理結果等に拘わらず)、下位サービス１(ここではプロバイダ４６による下位サービス)の実行を、下位サービス１に対応するサービス呼出部３２へ指示する。これにより、下位サービス１に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、プロバイダ４６へサービス要求が送信される。
【００７８】
なお、今回引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていない場合は、サービス呼出部３２への指示に先立ち、引数として引き渡されたサービスＩＤをサービスＩＤ生成部３０へ通知して下位サービス１のサービスＩＤの生成を要求し、サービスＩＤ生成部３０で生成された下位サービス１のサービスＩＤを、管理部２４を通じ、引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させると共に、当該下位サービス１のサービスＩＤをサービス呼出部３２へ通知する処理も行われる。また、同一のサービスＩＤのサービスの実行が過去に要求されている場合は、サービス呼出部３２への指示に先立ち、管理部２４から通知された情報より対応する下位サービス１のサービスＩＤを抽出し、抽出したサービスＩＤをサービス呼出部３２へ通知する処理も行われる。
【００７９】
また、下位サービス１に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２０６において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「不明」又は「処理未済」である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによってリトライやリトライ回数の監視等の処理が行われる。また、通知された処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス２,３の実行を要求するサービス要求の送信はスキップされる。
【００８０】
一方、通知された処理結果が「処理済」である場合は、下位サービス１の処理が正常に終了しているのでステップ２１０へ移行する。下位サービス２(ここではパッケージ・ラッパー４８による下位サービス)は冪等性を有していないので、まずステップ２１０では、今回引数として引き渡されたサービスＩＤを管理部２４に通知し、通知したサービスＩＤのサービスの処理結果(状況)を管理部２４に問い合わせる。そして、次のステップ２１２では、管理部２４から通知された情報に基づいて、下位サービス２が今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスとして過去に実行されている場合の処理結果を判定し、判定した処理結果に応じて処理を分岐する。なお、先のステップ２００,２０２において、今回引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていないことが判明した場合は、ステップ２１０の実行をスキップし、ステップ２１２で処理結果は「処理未済」と判定するようにしてもよい。
【００８１】
ステップ２１２で判定した処理結果が「不明」又は「確認不能」(例えば管理部２４から結果確認呼出部３６へ下位サービス２の処理結果の確認が要求されたものの、パッケージ・ラッパー４８との通信リンクが確立していなかった等の場合))である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによって(処理結果確認の)リトライやリトライ回数の監視等の処理が行われる。また、判定した処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。また、判定した処理結果が「処理済」である場合は、下位サービス２の実行を要求するサービス要求の送信をスキップしてステップ２２０へ移行する。
【００８２】
一方、判定した処理結果が「処理未済」である場合はステップ２１４へ移行し、まず引数として引き渡されたサービスＩＤをサービスＩＤ生成部３０へ通知して下位サービス２のサービスＩＤの生成を要求し、サービスＩＤ生成部３０で生成された下位サービス２のサービスＩＤを、管理部２４を通じ、引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させると共に、当該下位サービス２のサービスＩＤを下位サービス２に対応するサービス呼出部３２へ通知し、下位サービス２の実行を指示する。これにより、下位サービス２に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、パッケージ・ラッパー４８へサービス要求が送信される。
【００８３】
また、下位サービス２に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２１６において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「不明」又は「処理未済」である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによってリトライやリトライ回数の監視等の処理が行われる。また、通知された処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。
【００８４】
一方、通知された処理結果が「処理済」である場合は、下位サービス２の処理も正常に終了しているのでステップ２２０へ移行する。下位サービス３は冪等性を有しているので、ステップ２２０では、先のステップ２０４と同様に下位サービス３の処理状況に拘わらず、下位サービス３(ここではＭＢラッパー５０による下位サービス)の実行を、下位サービス３に対応するサービス呼出部３２へ指示する。これにより、下位サービス３に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、ＭＢラッパー５０へサービス要求が送信される。
【００８５】
なお、今回引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていない場合は、サービス呼出部３２への指示に先立ち、引数として引き渡されたサービスＩＤをサービスＩＤ生成部３０へ通知して下位サービス３のサービスＩＤの生成を要求し、サービスＩＤ生成部３０で生成された下位サービス３のサービスＩＤを、管理部２４を通じ、引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させると共に、当該下位サービス３のサービスＩＤをサービス呼出部３２へ通知する処理も行われる。また、同一のサービスＩＤのサービスの実行が過去に要求されている場合は、サービス呼出部３２への指示に先立ち、管理部２４から通知された情報より対応する下位サービス３のサービスＩＤを抽出し、抽出したサービスＩＤをサービス呼出部３２へ通知する処理も行われる。
【００８６】
また、下位サービス３に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２２２において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「不明」又は「処理未済」である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによってリトライやリトライ回数の監視等の処理が行われる。また、通知された処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。また、一方、通知された処理結果が「処理済」である場合は、下位サービス３の処理も正常に終了しているので、処理結果が「処理済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【００８７】
続いて、図８に示す処理実行部処理について、図７に示す処理実行部処理と異なる部分のみ説明する。図８に示す処理実行部処理は、図７に示す処理実行部処理と同様に、ＢＰＥＬ４４の処理実行部２６に対して冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行わない、という条件に対応しており、下位のサービス処理部へのサービス要求等のリトライ及びリトライ回数の監視が、処理実行部ＡＰＩに代えて業務プログラムによって行われる点で図７に示す処理実行部処理と相違している。
【００８８】
すなわち、図８に示す処理実行部処理では、ステップ２０４で下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を指示し、ステップ２０６で下位サービス１に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合に、ステップ２０８において、下位サービス１を行うプロバイダ４６へサービス要求を送信した回数が規定値に達したか否かを判定することで、プロバイダ４６へのサービス要求の再送信(リトライ)を行うか否か判定する。プロバイダ４６へのサービス要求の送信回数が規定値未満の場合はステップ２０４に戻り、下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を再度指示することで、プロバイダ４６へサービス要求を再送信させる。また、プロバイダ４６へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス２,３の実行を要求するサービス要求の送信はスキップされる。
【００８９】
また、図８に示す処理実行部処理では、ステップ２１０でサービスの処理結果(状況)を管理部２４に問い合わせ、ステップ２１２で判定した下位サービス２の処理結果が「不明」又は「確認不能」であった場合、及び、ステップ２１４で下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を指示し、ステップ２１６で下位サービス２に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合に、ステップ２１８において、下位サービス２の処理結果を確認した回数又はパッケージ・ラッパー４８へサービス要求を送信した回数が規定値に達したか否かを判定することで、上記処理を再度行うか否か判定する。下位サービス２は冪等性を有していないので、下位サービス２の処理結果を確認した回数又はパッケージ・ラッパー４８へサービス要求を送信した回数が規定値未満の場合はステップ２１０に戻り、下位サービス２の処理結果確認以降の処理を再度行う。また、下位サービス２の処理結果を確認した回数又はパッケージ・ラッパー４８へサービス要求を送信した回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。
【００９０】
また、図８に示す処理実行部処理では、ステップ２２０で下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を指示し、ステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合に、ステップ２２４において、下位サービス３を行うＭＢラッパー５０へサービス要求を送信した回数が規定値に達したか否かを判定することで、ＭＢラッパー５０へのサービス要求の再送信(リトライ)を行うか否か判定する。ＭＢラッパー５０へのサービス要求の送信回数が規定値未満の場合はステップ２２０に戻り、下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を再度指示することで、ＭＢラッパー５０へサービス要求を再送信させる。また、ＭＢラッパー５０へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【００９１】
続いて、図９に示す処理実行部処理について、図７に示す処理実行部処理と異なる部分のみ説明する。図９に示す処理実行部処理は、ＢＰＥＬ４４の処理実行部２６に対して冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行う、という条件に対応しており、下位のサービス処理部からの応答のタイムアウトの監視、下位のサービス処理部へのサービス要求等のリトライ及びリトライ回数の監視等の処理は、図７に示す処理実行部処理と同様に処理実行部ＡＰＩによって行われる。
【００９２】
図９に示す処理実行部処理では、ステップ２１０でサービスの処理結果(状況)を管理部２４に問い合わせ、ステップ２１２で判定した下位サービス２の処理結果が「業務エラー」であった場合、及び、ステップ２１４で下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を指示し、ステップ２１６で下位サービス２に対応するサービス呼出部３２から通知された処理結果が「業務エラー」であった場合にステップ２３０へ移行する。この場合、今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスのうち、下位サービス１は処理結果が「処理済」であるのに対し、下位サービス２は処理結果が「業務エラー」で処理が未了であるので、データに矛盾が生じている。
【００９３】
このため、ステップ２３０では、データの整合性をとるために、下位サービス１に対応するサービス呼出部３２に対し、下位サービス１のサービスＩＤとして先のステップ２０４と同一のサービスＩＤを通知し、当該サービスＩＤの下位サービス１として先に実行した処理を取り消す処理の実行を要求するサービス要求の送信を指示する。これにより、下位サービス１に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、プロバイダ４６へ上記のサービス要求が送信される。そして、先に実行した処理を取り消す処理がプロバイダ４６によって行われることで、先に実行した処理で更新されたデータがあれば当該データが元のデータへ復元され、データの矛盾が解消される(データの整合性が確保される)ことになる。
【００９４】
また、下位サービス１に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２３２において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「処理済」の場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。また通知された処理結果が「業務エラー」又は「処理未済」又は「不明」の場合は、処理結果が「取消失敗」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合は、データの矛盾が解消して整合性が確保する処理は、バッチ処理等の別処理によって行われることになる。
【００９５】
また、図９に示す処理実行部処理では、ステップ２２０で下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を指示し、ステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「業務エラー」であった場合にステップ２２６へ移行する。この場合、今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスのうち、下位サービス１,２は処理結果が「処理済」であるのに対し、下位サービス３は処理結果が「業務エラー」で処理が未了であるので、データに矛盾が生じている。
【００９６】
このため、ステップ２２６では、データの整合性をとるために、下位サービス２に対応するサービス呼出部３２に対し、下位サービス２のサービスＩＤとして先のステップ２１４と同一のサービスＩＤを通知し、当該サービスＩＤの下位サービス２として先に実行した処理を取り消す処理の実行を要求するサービス要求の送信を指示する。これにより、下位サービス２に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、パッケージ・ラッパー４８へ上記のサービス要求が送信される。そして、先に実行した処理を取り消す処理がパッケージ・ラッパー４８によって行われることで、先に実行した処理で更新されたデータがあれば、当該データが元のデータへ復元される。
【００９７】
また、下位サービス２に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２２８において、通知された処理結果に応じて処理を分岐する。通知された処理結果が「業務エラー」又は「処理未済」又は「不明」の場合は、処理結果が「取消失敗」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合は、データの矛盾が解消して整合性が確保する処理は、バッチ処理等の別処理によって行われる。また、通知された処理結果が「処理済」の場合はステップ２３０へ移行し、ステップ２３０で前述した処理が行われることで、先に実行した処理を取り消す処理の実行を要求するサービス要求がプロバイダ４６へも送信される。そして、先に実行した処理を取り消す処理がプロバイダ４６でも行われ、先に実行した処理で更新されたデータがあれば当該データが元のデータへ復元されることでデータの矛盾が解消される(データの整合性が確保される)ことになる。
【００９８】
続いて、図１０に示す処理実行部処理について、図７〜図９に示す処理実行部処理と異なる部分のみ説明する。図１０に示す処理実行部処理は、ＢＰＥＬ４４の処理実行部２６に対して非冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行う、という条件に対応している。また、図１０に示す処理実行部処理では、図７に示す処理実行部処理と同様に、下位のサービス処理部へのサービス要求等のリトライ及びリトライ回数の監視等の処理が業務プログラムによって行われる一方、タイムアウトの監視が処理実行部ＡＰＩによって行われる。
【００９９】
仮想冪等機能を利用しない非冪等呼び出しでは、同一のサービスＩＤのサービスの実行が複数回要求されることはないので、図１０に示す処理実行部処理ではステップ２００,２０２が省略されており、まずステップ２０４で下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を指示する。また、次のステップ２０６で下位サービス１に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合、図８に示す処理実行部処理と同様に、ステップ２０８でプロバイダ４６へのサービス要求の再送信(リトライ)を行うか否か判定する。プロバイダ４６へのサービス要求の送信回数が規定値未満の場合はステップ２０４に戻り、下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を再度指示することで、プロバイダ４６へサービス要求を再送信させる。また、プロバイダ４６へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス２,３の実行を要求するサービス要求の送信はスキップされる。
【０１００】
また、図１０に示す処理実行部処理では、ステップ２０６で下位サービス１に対応するサービス呼出部３２から通知された処理結果が「処理済」であった場合、次のステップ２３６で下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を指示する。また、下位サービス２に対応するサービス呼出部３２から処理結果が通知されるとステップ２３８へ移行し、通知された下位サービス２の処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「業務エラー」の場合はステップ２３０へ移行し、図９に示す処理実行部処理と同様に、下位サービス１の実行要求に従ってプロバイダ４６が先に実行した処理を取り消す処理をプロバイダ４６によって行わせる。また、通知された処理結果が「処理済」の場合はステップ２２０へ移行する。
【０１０１】
一方、通知された処理結果が「不明」又は「処理未済」の場合は、下位サービス２が冪等性を有しておらず、かつ図１０に示す処理実行部処理が非冪等呼び出しで呼び出されることを考慮し、ステップ２４０で下位サービス２の処理結果を管理部２４に問い合わせ、次のステップ２４２で下位サービス２の処理結果を判定し、判定した処理結果に応じて処理を分岐する。そして、ステップ２４０,２４２の処理を経て下位サービス２の処理結果が「業務エラー」に切り替わった場合はステップ２３０へ移行する。また、ステップ２４０,２４２の処理を経て下位サービス２の処理結果が「処理済」に切り替わった場合はステップ２２０へ移行する。下位サービス２の処理結果が「不明」の場合は対処の判断が困難であるが、上記のように処理結果を再確認した結果、処理結果が「業務エラー」又は「処理済」に切り替わった場合は対処の判断が容易となる。また、ステップ２４２で判定した下位サービス２の処理結果が「不明」又は「確認不能」であった場合はステップ２４０に戻り、ステップ２４０,２４２の処理を再度行う。
【０１０２】
一方、ステップ２４２で判定した下位サービス２の処理結果が「処理未済」であった場合はステップ２４４へ移行し、パッケージ・ラッパー４８へのサービス要求の再送信(リトライ)を行うか否か判定する。パッケージ・ラッパー４８へのサービス要求の送信回数が規定値未満の場合はステップ２３６に戻り、下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を再度指示することで、パッケージ・ラッパー４８へサービス要求を再送信させる。また、パッケージ・ラッパー４８へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。
【０１０３】
また、ステップ２２０では下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を指示する。また、次のステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合、図８に示す処理実行部処理と同様に、ステップ２２４でＭＢラッパー５０へのサービス要求の再送信(リトライ)を行うか否か判定する。ＭＢラッパー５０へのサービス要求の送信回数が規定値未満の場合はステップ２２０に戻り、下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を再度指示することで、ＭＢラッパー５０へサービス要求を再送信させる。また、ＭＢラッパー５０へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【０１０４】
また、図１０に示す処理実行部処理では、ステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「業務エラー」の場合はステップ２２６へ移行し、図９に示す処理実行部処理と同様に、下位サービス２の実行要求に従ってパッケージ・ラッパー４８が先に実行した処理を取り消す処理をパッケージ・ラッパー４８によって行わせ、続いて、下位サービス１の実行要求に従ってプロバイダ４６が先に実行した処理を取り消す処理をプロバイダ４６によって行わせる。また、通知された処理結果が「処理済」の場合は処理結果が「処理済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【０１０５】
なお、図７〜図１０では、実行が要求されたサービスに対応する自サービスが存在しない場合の処理実行部処理を示しているが、実行が要求されたサービスに対応する自サービスが存在する場合は、処理実行部２６により、対応する自サービスの処理を実行し、処理結果を引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させる処理も行われる。
【０１０６】
また、下位のサービス処理部が存在するサービス処理部にはサービスＩＤ生成部３０が設けられており、サービスＩＤ生成部３０は処理実行部２６からサービスＩＤの生成が要求される毎に、図１１に示すサービスＩＤ生成部処理を行う。
【０１０７】
このサービスＩＤ生成部処理では、まずステップ１００において、自身（サービスＩＤ生成部３０）を含むサービス処理部（自サービス処理部）に固有のＩＤをリクエスタ固有ＩＤとして取得する。自サービス処理部に固有のＩＤとしては、例えば自サービス処理部が動作しているサービス処理サーバ１２のネットワークＩＤ等を適用することができる。また、ステップ１０２では自サービス処理部を実現するサービス処理プログラムを実行しているプロセスに割当てられているＩＤをプロセス毎ＩＤとして取得する。またステップ１０４では、リクエスト毎ＩＤとして、サービスＩＤを生成する毎に異なるＩＤを決定する。なお、リクエスト毎ＩＤとしては、例えば単純な通番、或いはＩＤ決定時の時刻等を適用することができる。そしてステップ１０６では、各ＩＤを組み合わせたＩＤ要素として、例として図１６(Ａ)に示すように、リクエスタ固有ＩＤ、プロセス毎ＩＤ及びリクエスト毎ＩＤを直列に並べたＩＤ要素を生成する。
【０１０８】
次のステップ１０８では、自サービス処理部が、より上位のサービス処理部が存在しない最上位のサービス処理部か否か判定する。判定が肯定された場合はステップ１１０へ移行し、新たなリクエスト毎ＩＤ（先のステップ２１４で決定したリクエスト毎ＩＤとは異なるＩＤ）を決定する。次のステップ１１２では、ステップ１１０で決定した新たなリクエスト毎ＩＤを、先のステップ１００で取得したリクエスタ固有ＩＤ、先のステップ１０２で取得したプロセス毎ＩＤと組み合わせ、新たなＩＤ要素（第２のＩＤ要素）を生成する。図１６(Ａ)に示すように、本実施形態に係るサービスＩＤは、オリジナルサービスＩＤ(ＯＳＩＤ)、呼出元サービスＩＤ(ＳＳＩＤ)及び呼出先サービスＩＤ(ＮＳＩＤ)から構成されており、次のステップ１１４では、先のステップ１０６で生成したＩＤ要素をオリジナルサービスＩＤ及び呼出元サービスＩＤに各々設定すると共に、ステップ１１２で生成した第２のＩＤ要素を呼出先サービスＩＤに設定したサービスＩＤを生成し(図１６(Ｂ)に示すサービス処理部Ａも参照）、生成したサービスＩＤを処理実行部２６へ通知して処理を終了する。
【０１０９】
なお、最上位のサービス処理部に設けられたサービスＩＤ生成部３０によって生成されるサービスＩＤは、上記のように、オリジナルサービスＩＤ及び呼出元サービスＩＤに設定するＩＤ要素と、呼出先サービスＩＤに設定するＩＤ要素を相違させることに限られるものではなく、オリジナルサービスＩＤ、呼出元サービスＩＤ及び呼出先サービスＩＤに全て同一のＩＤ要素を設定したサービスＩＤを生成するようにしてもよい。
【０１１０】
一方、自サービス処理部よりも上位のサービス処理部が存在しており、自サービス処理部が最上位のサービス処理部ではない場合は、ステップ１０８の判定が否定されてステップ１１６へ移行する。自サービス処理部が最上位のサービス処理部ではない場合は、自サービス処理部が上位のサービス処理部から受信したサービス要求に付加されていたサービスＩＤが処理実行部２６から通知され、ステップ１１６では、処理実行部２６より通知されたサービスＩＤから、オリジナルサービスＩＤとして設定されているＩＤ要素と、呼出先サービスＩＤとして設定されているＩＤ要素を各々抽出する。そしてステップ１１８では、通知されたサービスＩＤにオリジナルサービスＩＤとして設定されていたＩＤ要素をオリジナルサービスＩＤに設定すると共に、通知されたサービスＩＤに呼出先サービスＩＤとして設定されていたＩＤ要素を呼出元サービスＩＤに設定し、更に、先のステップ２１６で生成したＩＤ要素を呼出先サービスＩＤに設定したサービスＩＤを生成し(図１６(Ｂ)に示すサービス処理部Ｂ〜Ｄも参照）、生成したサービスＩＤを処理実行部２６へ通知して処理を終了する。
【０１１１】
本実施形態に係るサービス処理システム１０では、サービスＩＤ生成部３０が、下位のサービス処理部が存在しているサービス処理部に各々設けられており、個々のサービスＩＤ生成部３０でサービスＩＤの生成が各々行われるが、上記のように、ＩＤ要素にリクエスタ固有ＩＤを含めることで、個々のサービス処理部のサービスＩＤ生成部３０で生成されるＩＤ要素は、少なくとも個々のサービス処理部を単位とする一意性が確保される。また、ＩＤ要素にプロセス毎ＩＤを含めることで、個々のサービス処理部のサービスＩＤ生成部３０で生成されるＩＤ要素は、個々のサービス処理部内での一意性も確保される。従って、個々のサービス処理部のサービスＩＤ生成部３０で生成されるＩＤ要素は、サービス処理システム１０内における一意性が確保されている（他のＩＤ要素と重複していないことが保証されている）ので、一意性が確保されたＩＤ要素（サービスＩＤ）を生成するために排他制御を伴う採番処理を行う必要はなく、排他制御を伴う採番処理を行うことでサービス処理システム１０の性能が著しく低下することを回避できる。
【０１１２】
なお、ＩＤ要素にはプロセスＩＤも含まれているので、同一のサービス処理部として機能するプロセスが単一のサービス処理サーバ１２内に複数存在している場合にも、サービス要求に付加されたサービスＩＤのうちのプロセスＩＤを参照することで、対応するサービス要求が複数のサービス処理部のうちの何れのサービス処理部で処理されたのかを判断することも可能となる。
【０１１３】
また、上記のサービスＩＤ生成部処理を行うことで、最上位のサービス処理部を起点として下位のサービス処理部へ受け渡されるサービスＩＤは、例として図１６(Ｂ)に示すように遷移し、オリジナルサービスＩＤは一定で、上位のサービス処理部が存在する或るサービス処理部から出力される（サービス要求に付加される）サービスＩＤのうちの呼出元サービスＩＤには、上位のサービス処理部から受け取ったサービスＩＤにおける呼出先サービスＩＤと同一のＩＤ要素が設定され、前記或るサービス処理部から出力されるサービスＩＤのうちの呼出元サービスＩＤには、前記或るサービス処理部を識別可能なＩＤ要素が設定されることになる。これにより、サービス処理システム１０内で障害が発生し、特定のサービス処理部に処理未了のサービス要求が滞留した場合にも、滞留しているサービス要求に付加されたサービスＩＤに呼出元サービスＩＤとして設定されているＩＤ要素から、滞留しているサービス要求を送信したサービス処理部を識別することができ、この識別処理を、対応するサービスＩＤ（呼出元サービスＩＤが呼出先サービスＩＤと同一のサービスＩＤ）を辿りながら繰り返すことで、滞留している処理未了のサービス要求の処理履歴を把握することが可能となる。
【０１１４】
また、サービスＩＤが呼出元サービスＩＤ及び呼出先サービスＩＤのみから構成されていた場合、例えば図１７に示すように、サービス要求がサービス処理部Ａからサービス処理部Ｂ,Ｃを経由してサービス処理部Ｄ,Ｅに伝わった後で、サービス処理部Ｂ,Ｃに障害が発生し、サービス処理部Ｂ,Ｃに記録されていた情報が消失したときに、サービス処理部Ｄ,Ｅに呼出元サービスＩＤ及び呼出先サービスＩＤのみから成るサービスＩＤが記録されていたとすると、当該サービスＩＤの呼出元ＩＤ及び呼出先ＩＤに設定されているＩＤ要素に基づいて同一のサービス要求を辿っていくことは不可能である。これに対し、サービスＩＤにオリジナルサービスＩＤも加えておくことで、障害発生時もオリジナルＩＤを参照し、オリジナルサービスＩＤが同一のサービスＩＤと対応付けられた情報を同一のサービス要求に対応する情報とみなすことができ、例えばバッチ処理等により、オリジナルサービスＩＤをキーにして同一のサービス要求に対応する情報を検索・抽出し、データの矛盾を解消して整合性をとるための処理を行うことが可能となる。
【０１１５】
また、下位のサービス処理部が存在するサービス処理部には、サービス呼出部３２が下位のサービス処理部と同数個設けられており、サービス呼出部３２は、処理実行部２６から下位サービスのサービスＩＤが通知されて下位サービスの実行が要求される毎に、図１２に示すサービス呼出部処理を行う。このサービス呼出部処理では、まずステップ１３０において、下位のサービス処理部に対して下位サービスの実行を要求するサービス要求の電文を作成する。なお、この電文には処理実行部２６から通知された下位サービスのサービスＩＤが付加される。次のステップ１３２では、ステップ１３０で作成したサービス要求の電文を対応する下位のサービス処理部へ送信する。またステップ１３４では、対応する下位のサービス処理部へサービス要求の電文を送信したことを表すステータス情報を、送信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。
【０１１６】
ステップ１３２で送信したサービス要求の電文に対し、対応する下位のサービス処理部から応答電文が送信されると、次のステップ１３６で下位のサービス処理部から送信された応答電文を受信する。またステップ１３８では、下位のサービス処理部からサービス要求に対する応答電文を受信したことを表すステータス情報を、受信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させる。受信した応答電文には下位サービスのサービスＩＤと下位サービスの処理結果を表す情報が含まれており、上記処理によりこれらの情報も処理状況テーブル３８に記憶されることになる。そしてステップ１４０では、下位のサービス処理部からサービス要求に対する応答電文を受信したことを、受信した応答電文に設定されている下位サービスのサービスＩＤ及び下位サービスの処理結果と共に処理実行部２６へ通知し、サービス呼出部処理を終了する。
【０１１７】
また、上位のサービス処理部が存在するサービス処理部には処理結果確認部３４が設けられており、この処理結果確認部３４は、上位のサービス処理部から処理結果確認要求の電文を受信する際に図１３に示す処理結果確認部処理を行う。この処理結果確認部処理では、まずステップ１５０で上位のサービス処理部から処理結果確認要求の電文を受信し、次のステップ１５２において、上位のサービス処理部から処理結果確認要求の電文を受信したことを表すステータス情報を、受信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。次のステップ１５４では受信した電文の内容をチェックし、受信した電文の内容を適正か否か判定する。判定が否定された場合はステップ１５６へ移行し、上位のサービス処理部へ送信する応答電文にエラーメッセージを設定し、ステップ１６０へ移行する。
【０１１８】
一方、受信した電文の内容が適正であった場合は、ステップ１５４の判定が肯定されてステップ１５８へ移行し、受信した処理結果確認要求の電文に付加されている処理結果確認対象のサービスのサービスＩＤを抽出し、抽出したサービスＩＤを管理部２４に通知して対応するサービスの処理結果を管理部２４に問い合わせる。これにより、管理部２４では管理部処理(後述)が行われる。管理部２４による管理部処理が終了し、問い合わせた処理結果が通知されると、通知された処理結果を上位のサービス処理部へ送信する応答電文に設定した後にステップ１６０へ移行する。ステップ１６０では、ステップ１５６又はステップ１５８で生成した応答電文を上位のサービス処理部へ送信する。またステップ１６２では、上位のサービス処理部へ応答電文を送信したことを表すステータス情報を、送信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させ、処理結果確認部処理を終了する。
【０１１９】
また、管理部２４では、処理結果確認部３４や処理実行部２６からサービスＩＤが通知され、通知されたサービスＩＤのサービスの処理結果の問い合わせがある毎に、図１４に示す管理部処理を行う。
【０１２０】
この管理部処理では、まずステップ１７０において、処理結果確認部３４又は処理実行部２６から通知されたサービスＩＤをキーにして処理状況テーブル３８を検索し、通知されたサービスＩＤと対応付けて処理状況テーブル３８に登録されている処理結果情報（対応する自サービスや下位サービスの処理結果を各々表す情報）を抽出する。次のステップ１７２では抽出した処理結果情報を参照し、通知されたサービスＩＤに対応するサービスの中に、処理結果が「不明」の下位サービスが存在しているか否か判定する。処理結果確認対象のサービス（通知されたサービスＩＤのサービス）に対応する下位サービスが存在しない場合や、対応する下位サービスが存在しているものの、当該下位サービスの処理結果が「処理済」等の場合は判定が否定されてステップ１７６へ移行し、ステップ１７０で抽出した処理結果情報が表す処理結果を問い合わせ元の処理結果確認部３４又は処理実行部２６に通知し、処理を終了する。なお、通知されたサービスＩＤが処理状況テーブル３８に未登録の場合は未登録であることを表す情報を問い合わせ元へ通知する。
【０１２１】
また、処理結果確認対象のサービスに対応する下位サービスが存在しており、かつ当該下位サービスの処理結果が「不明」の場合は、ステップ１７２の判定が肯定されてステップ１７４へ移行し、処理結果が「不明」の下位サービスに対応する結果確認呼出部３６に対し、処理結果が「不明」の下位サービスのサービスＩＤを通知し、対応する下位サービスの処理結果の確認を要求する。これにより、結果確認呼出部３６では結果確認呼出部処理(後述)が行われる。また、結果確認呼出部３６における結果確認呼出部処理が完了し、結果確認呼出部３６によって確認された下位サービスの処理結果が通知されるとステップ１７２に戻る。これにより、処理結果確認対象のサービスに対応するサービスの中に処理結果が「不明」の下位サービスが複数存在している場合はステップ１７４が繰り返され、該当する全ての下位サービスの処理結果の確認が対応する結果確認呼出部３６で各々行われる。そしてステップ１７２の判定が否定されるとステップ１７６へ移行し、結果確認呼出部３６から通知された下位サービスの処理結果を含め、 処理結果確認対象のサービスの処理結果を問い合わせ元の処理結果確認部３４又は処理実行部２６に通知し、処理を終了する。
【０１２２】
また、下位のサービス処理部が存在するサービス処理部には、結果確認呼出部３６が下位のサービス処理部と同数個設けられており、結果確認呼出部３６は、管理部２４から下位サービスのサービスＩＤが通知されて下位サービスの処理結果の確認が要求される毎に、図１５に示す結果確認呼出部処理を行う。この結果確認呼出部処理では、まずステップ１８０において、下位のサービス処理部に対して下位サービスの処理結果の通知を要求する処理結果確認要求の電文を作成する。なお、この電文には管理部２４から通知された下位サービスのサービスＩＤが付加される。次のステップ１８２では、ステップ１８０で作成した処理結果確認要求の電文を対応する下位のサービス処理部へ送信する。またステップ１８４では、対応する下位のサービス処理部へ処理結果確認要求の電文を送信したことを表すステータス情報を、送信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。
【０１２３】
ステップ１８２で送信した処理結果確認要求の電文に対し、対応する下位のサービス処理部から応答電文が送信されると、次のステップ１８６で下位のサービス処理部から送信された応答電文を受信する。またステップ１８８では、下位のサービス処理部から処理結果確認要求に対する応答電文を受信したことを表すステータス情報を、受信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させる。受信した応答電文には下位サービスのサービスＩＤと下位サービスの処理結果を表す情報が含まれており、上記処理によりこれらの情報も処理状況テーブル３８に記憶されることになる。そしてステップ１９０では、下位のサービス処理部から処理結果確認要求に対する応答電文を受信したことを、受信した応答電文に設定されている下位サービスのサービスＩＤ及び下位サービスの処理結果と共に管理部２４へ通知し、処理結果確認呼出部処理を終了する。
【０１２４】
なお、上記では、サービス処理部の機能を便宜的に各機能ブロック毎に分けて説明したが、個々のサービス処理サーバ１２をサービス処理部として機能させるサービス処理プログラムは、各機能ブロック毎に分けられていてもよいし、一体化されていてもよい。
【０１２５】
また、個々のサービス処理部をリファレンスモデルに準拠して構築することで、個々のサービス処理部における処理はその大部分が定型処理になり、サービス処理部を実現するプログラムのうち、サービス受付部２８やサービスＩＤ生成部３０、サービス呼出部３２、処理結果確認部３４、結果確認呼出部３６を実現するプログラム、及び、処理実行部２６を実現するプログラムのうちの処理実行部ＡＰＩは部品化することが可能である。これにより、プログラム開発者は、部品化したプログラムを流用してサービス処理プログラムを開発することができ、個々のサービス処理部毎に異なる特有処理を実現するプログラム(例えば処理実行部２６の業務プログラム)の開発に専念できるので、プログラム開発者の負担の大幅な軽減、プログラム開発に要する期間の大幅な短縮を実現することができる。
【０１２６】
また、サービス処理システム１０における各サービス処理部のうち、ＢＰＥＬ４４ではサービス処理プログラムがＢＰＥＬのプラットフォーム上で動作するので、ＢＰＥＬが提供する機能を利用することで、仮想冪等機能を実現する処理実行部２６のプログラムをより容易に開発することが可能となる。すなわち、ＢＰＥＬのプラットフォームは、或るプログラムが呼び出される毎に、呼び出されたプログラムを実行するプロセス（インスタンスともいう）を生成し、メモリ１２Ｂ等の記憶手段の記憶領域のうち生成したプロセスに対応する所定領域（ＢＯ(Business Objects)という）に、呼出時の引数を設定すると共に、生成したプロセスにおける処理の進行状態を表す状態情報も設定し、対応するプロセスにおける処理の進行状態の変化に応じて状態情報を適宜更新する、という機能を提供している。
【０１２７】
このため、上記機能を利用し、例として図１８に示すように、サービス処理部のプログラムのうち、少なくとも処理実行部２６として機能するプログラム（当該プログラムにはサービス受付部２８として機能するプログラムやサービス呼出部３２として機能するプログラムも含まれていてもよい）を、サービスＩＤ及び冪等フラグを引数として呼び出され、起動されると、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在しているか否かを確認する(図１８の「処理結果確認」も参照)ように構成すれば、今回の呼び出しに対応するサービス要求が、過去に受けたサービス要求の再送であるか否かを簡単に確認することができる。また、上記プログラムを、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在している場合に、該当する他プロセス（該当する他プロセスが複数存在している場合は、そのうちの最新の(最後に生成された)他プロセス）のＢＯから状態情報をコピーする(図１８の「ＢＯコピー」も参照)ように構成することで、今回の呼び出しに対応するサービス要求を前回受けた際の処理の状態を継承し、前回の処理の続きから開始することを簡易な処理で実現することができる。また、上記プログラムを、実行が要求されたサービスに対応する非冪等の下位サービスが存在する場合に、当該下位サービスの処理結果を確認し、「処理済」であれば下位サービスの実行要求をスキップする(図１８の「実行済？」も参照)ように構成することで、仮想冪等機能を簡易な処理によって実現することができる。このように、ＢＰＥＬのプラットフォームの特徴を利用することで、サービス処理プログラムの開発負荷を更に削減することが可能となる。
【０１２８】
また、本実施形態に係るサービス処理システム１０では、個々のサービス処理部がサービス要求や処理結果確認要求の受信時に、図３や図４に示す処理シーケンスで処理を行うことで、最上位のサービス処理部が送信したサービス要求や処理結果確認要求が複数段のサービス処理部に亘って連鎖することになる。以下、最上位のサービス処理部からサービス要求や処理結果確認要求が送信された場合の、サービス処理システム１０全体としての処理シーケンスを説明する。なお以下では、対象サービスが、プロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０の各々による下位サービスの実行を必要とするサービスであるものとする。
【０１２９】
最上位のサービス処理部（リクエスタ４２）に対してサービスの実行が指示された場合のシーケンスの一例を図１９に示す。このシーケンスでは、リクエスタ４２に対してサービスの実行が指示されると、リクエスタ４２のサービスＩＤ生成部３０によって下位サービスのサービスＩＤ（ＢＰＥＬ４４へ送信するサービスＩＤ）が生成され（図１９のステップ２６０も参照）、リクエスタ４２のサービス呼出部３２によってＢＰＥＬ４４へサービス要求が送信される。
【０１３０】
サービス要求を受信したＢＰＥＬ４４の処理実行部２６は、実行が要求されたサービスに対応する自サービスが存在している場合には自サービスの処理を行い（図１９のステップ２６２も参照）、サービスＩＤ生成部３０によって下位サービス１のサービスＩＤ（プロバイダ４６へ送信するサービスＩＤ）を生成させ（図１９のステップ２６４も参照）、プロバイダ４６に対応するサービス呼出部３２を呼び出し、プロバイダ４６に対応するサービス呼出部３２によってプロバイダ４６へサービス要求を送信させる。サービス要求を受信したプロバイダ４６では、要求された下位サービス１の処理が処理実行部２６によって行われ（図１９のステップ２６６も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
【０１３１】
ＢＰＥＬ４４の処理実行部２６は、プロバイダ４６からの応答が受信され、処理結果が「処理済」であった場合、サービスＩＤ生成部３０によって下位サービス２のサービスＩＤ（パッケージ・ラッパー４８へ送信するサービスＩＤ）を生成させ（図１９のステップ２６８も参照）、パッケージ・ラッパー４８に対応するサービス呼出部３２を呼び出し、パッケージ・ラッパー４８に対応するサービス呼出部３２によってパッケージ・ラッパー４８へサービス要求を送信させる。サービス要求を受信したパッケージ・ラッパー４８では、要求された下位サービス２の処理がパッケージ・システム６６と協働することで行われ（図１９のステップ２７０も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
【０１３２】
ＢＰＥＬ４４の処理実行部２６は、パッケージ・ラッパー４８からの応答が受信され、処理結果が「処理済」であった場合、サービスＩＤ生成部３０によって下位サービス３のサービスＩＤ（ＭＢラッパー５０へ送信するサービスＩＤ）を生成させ（図１９のステップ２７２も参照）、ＭＢラッパー５０に対応するサービス呼出部３２を呼び出し、ＭＢラッパー５０に対応するサービス呼出部３２によってＭＢラッパー５０へサービス要求を送信させる。サービス要求を受信したＭＢラッパー５０では、要求された下位サービス３の処理が預為システム６８と協働することで行われ（図１９のステップ２７４も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
【０１３３】
ＢＰＥＬ４４では、パッケージ・ラッパー４８からの応答が受信され、処理結果が「処理済」であった場合、処理実行部２６からサービス受付部２８へ処理結果が通知され、サービス受付部２８はリクエスタ４２へ応答を送信して処理結果を通知する。これにより、リクエスタ４２では実行が指示されたサービスの処理結果(「処理済」)を出力する処理が行われる（図１９のステップ２７６も参照）。このように、最上位のリクエスタ４２からＢＰＥＬ４４を経由してプロバイダ４６やパッケージ・ラッパー４８、ＭＢラッパー５０へサービス要求が連鎖していくことで、指示されたサービスが実行される。
【０１３４】
次に、サービス処理システム１０に障害が発生した場合のシーケンスを説明する。図２０に示すシーケンスは、ＢＰＥＬ４４がパッケージ・ラッパー４８へサービス要求を送信した直後に障害が発生し、送信したサービス要求がパッケージ・ラッパー４８で受信されなかったことで、パッケージ・ラッパー４８から応答が送信されず、タイマがタイムアウトした場合のシーケンスである。図２０に示すシーケンスでは、ＢＰＥＬ４４からパッケージ・ラッパー４８へのサービス要求の再送信の図示を省略しているが、パッケージ・ラッパー４８へサービス要求を所定回再送信してもパッケージ・ラッパー４８からの応答が受信されなかった場合、ＢＰＥＬ４４の処理実行部２６の業務プログラムから処理実行部ＡＰＩへ制御が戻る。
【０１３５】
ここで、処理実行部ＡＰＩは、実行が要求されたサービスの処理結果が「不明(タイムアウト／リトライ回数超過)」であることをサービス受付部２８経由でリクエスタ４２へ通知するようにしてもよいが、図２０に示すシーケンスではパッケージ・ラッパー４８による下位サービス２の処理結果を管理部２４に問い合わせ、この場合、下位サービス２の処理結果が「不明」であることから、パッケージ・ラッパー４８に対応する結果確認呼出部３６によってＢＰＥＬ４４からパッケージ・ラッパー４８へ処理結果確認要求が送信される。 この間にサービス処理システム１０の障害が解消していた場合、この処理結果確認要求がパッケージ・ラッパー４８で受信され、パッケージ・ラッパー４８の処理結果確認部３４によって通知されたサービスＩＤに対応する下位サービス２の処理結果が確認される。この場合は処理結果が「処理未済」であるので、処理結果が「処理未済」であることを通知する処理結果通知がパッケージ・ラッパー４８からＢＰＥＬ４４へ送信される。
【０１３６】
パッケージ・ラッパー４８からの処理結果通知を受信し、処理結果が「処理未済」であることを確認すると、ＢＰＥＬ４４の処理実行部２６はパッケージ・ラッパー４８に対応するサービス呼出部３２を呼び出し、サービス呼出部３２によってＢＰＥＬ４４からパッケージ・ラッパー４８へサービス要求が再度送信される。これにより、パッケージ・ラッパー４８では、要求された下位サービス２の処理がパッケージ・システム６６と協働することで行われる（図２０のステップ２７０も参照）。以降のシーケンスは図１９と同一であるので説明を省略する。
【０１３７】
また、図２１に示すシーケンスは、ＭＢラッパー５０がＢＰＥＬ４４から受信したサービス要求で要求された下位サービス３の処理を預為システム６８と協働して行った結果、業務エラーが発生した場合（図２１のステップ２７５も参照）のシーケンスである。この場合、処理結果が「業務エラー」であることを通知する応答がＭＢラッパー５０からＢＰＥＬ４４へ送信される。この応答がＢＰＥＬ４４で受信されると、ＢＰＥＬ４４の処理実行部２６は、プロバイダ４６による下位サービス１及びパッケージ・ラッパー４８による下位サービス２が「処理済」で、ＭＢラッパー５０による下位サービス３が「業務エラー」となったことによるデータの不整合を解消するため、まず対応する下位サービス２のサービスＩＤを認識し（図２１のステップ２８２も参照）、パッケージ・ラッパー４８が先に実行した下位サービス２の処理を取り消す処理の実行を要求するサービス要求(図２１では「取消要求」と表記)を、サービス呼出部３２によってパッケージ・ラッパー４８へ送信させる。これにより、パッケージ・ラッパー４８は、実行が正常に終了している下位サービス２の処理をパッケージ・システム６６と協働して取り消す取消処理を行う（図２１のステップ２８４も参照）。
【０１３８】
また、上記のサービス要求(取消要求)に対する応答をパッケージ・ラッパー４８から受信すると、ＢＰＥＬ４４の処理実行部２６は、対応する下位サービス３のサービスＩＤを認識し（図２１のステップ２８６も参照）、ＭＢラッパー５０が先に実行した下位サービス３の処理を取り消す処理の実行を要求するサービス要求(図２１では「取消要求」と表記)を、サービス呼出部３２によってＭＢラッパー５０へ送信させる。これにより、ＭＢラッパー５０は、実行が正常に終了している下位サービス２の処理を預為システム６８と協働して取り消す取消処理を行う（図２１のステップ２８８も参照）。
【０１３９】
上記のサービス要求(取消要求)に対する応答をＭＢラッパー５０から受信すると、ＢＰＥＬ４４の処理実行部２６はサービス受付部２８へ処理結果を通知し、サービス受付部２８はリクエスタ４２へ応答を送信して処理結果を通知する。これにより、リクエスタ４２では実行が指示されたサービスの処理結果(実行が指示されたサービスは途中で業務エラーが発生したことで取り消された旨を表す「取消済」)を出力する処理が行われる（図１９のステップ２７６も参照）。
【０１４０】
また、図２２に示すシーケンスは、ＢＰＥＬ４４がＭＢラッパー５０へサービス要求を送信した直後に障害が発生し、送信したサービス要求がＭＢラッパー５０で受信されなかったことで、ＭＢラッパー５０から応答が送信されず、これに伴いリクエスタ４２からＢＰＥＬ４４へサービス要求が再送信された場合のシーケンスである。ここで、ＢＰＥＬ４４の処理実行部２６等が先に説明した図１８のように構成されているとすると、リクエスタ４２からのサービス要求の受信に伴い、ＢＰＥＬ４４の処理実行部２６では、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在しているか否かを確認する処理が行われ(図２２のステップ２９０も参照）、該当するプロセスが存在していることで、今回のサービス要求が過去に受信したサービス要求の再送であることが認識される。
【０１４１】
次に、該当するプロセスのＢＯに記憶されている状態情報が自プロセスのＢＯにコピーされる（図２２のステップ２９２も参照）。そして、再送されたサービス要求によって要求されたサービスを実行する処理が処理実行部２６によって行われるが、本実施形態では、プロバイダ４６によって提供されるサービスと、ＭＢラッパー５０(及び預為システム６８)によって提供されるサービスは冪等性を有している一方、パッケージ・ラッパー４８(及びパッケージ・システム６６)によって提供されるサービスは冪等性を有していないので、ＢＰＥＬ４４からは、プロバイダ４６及びＭＢラッパー５０に対してのみサービス要求が送信され、パッケージ・ラッパー４８については、対応する下位サービスの処理結果が「処理済」となっていることに基づき、サービス要求の送信がスキップされる。これにより仮想冪等機能が実現される。
【０１４２】
図２３には、リクエスタ４２に対して処理結果の確認が指示された場合のシーケンスの一例を示す。このシーケンスでは、処理結果の確認が指示されると、リクエスタ４２の管理部２４によって確認対象のサービスの処理結果が確認され、処理結果が「不明」であれば確認対象のサービスのサービスＩＤが認識（図２３のステップ２９６も参照）された後に、リクエスタ４２の結果確認呼出部３６によってＢＰＥＬ４４へ処理結果確認要求が送信される。リクエスタ４２から処理結果確認要求を受信したＢＰＥＬ４４では、処理結果確認部３４からの要求に従い、管理部２４によって対応する自サービスの処理結果が確認される（図２３のステップ２９８も参照）と共に、対応する下位サービスの処理結果も確認される（図２３のステップ２９８も参照）。
【０１４３】
ここで、対応する下位サービスの中に処理結果が「不明」の下位サービスが存在していた場合（ここでは、ＭＢラッパー５０が提供する下位サービスの処理結果が「不明」であったものとする）、処理結果が「不明」の下位サービスに対応する結果確認呼出部３６が管理部２４によって呼び出され、結果確認呼出部３６は対応する下位のサービス処理部（この例ではＭＢラッパー５０）へ処理結果確認要求を送信する。また、ＢＰＥＬ４４が下位のサービス処理部から処理結果通知を受信すると、ＢＰＥＬ４４の処理結果確認部３４によってリクエスタ４２へ処理結果通知が送信される。これにより、リクエスタ４２では処理結果の確認が指示されたサービスの処理結果を出力する処理が行われる（図２３のステップ２７６も参照）。このように、処理結果の確認が指示された場合も、リクエスタ４２からＢＰＥＬ４４へ処理結果確認要求が送信され、必要に応じてより下位のサービス処理部へ処理結果確認要求が連鎖していくことで、指示されたサービスの処理結果が確認される。
【０１４４】
なお、上記では本発明に係るサービス処理システムとして、５個のサービス処理部が３層(３段)に分けられ、３層目(３段目)の３個のサービス処理部が２層目(２段目)の単一のサービス処理部に各々連結され、２層目(２段目)の単一のサービス処理部が１層目(１段目)の単一のサービス処理部に連結された構成のサービス処理システム１０を例に説明したが、サービス処理部の総数や段数、各段（各層）におけるサービス処理部の数は上記に限られるものではなく、例えばサービス処理部がより多数段連結された構成のサービス処理システムにも本発明を適用可能であることは言うまでもない。
【０１４５】
また、上記では２段目(２層目)のサービス処理部を実現するためのサービス処理プログラムが、ＢＰＥＬのプラットフォーム上で動作する態様を説明したが、これに限定されるものではなく、本発明に係るサービス処理システムはＢＰＥＬを利用せずに構築することも可能である。
【０１４６】
また、上記では個々のサービス処理部が互いに異なるコンピュータ（サービス処理サーバ１２）によって実現される態様を説明したが、これに限定されるものではなく、本発明は単一のコンピュータを互いに異なる複数種のサービス処理部として各々機能させる態様にも適用可能である。
【０１４７】
また、上記では本発明に係るプログラムに対応するサービス処理プログラムがサービス処理サーバ１２の記憶部１２Ｃに予め記憶（インストール）されている態様を説明したが、本発明に係るプログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。この態様における記録媒体は本発明に係る記録媒体に対応している。
【符号の説明】
【０１４８】
１０ サービス処理システム
１２ サービス処理サーバ
１２Ｃ 記憶部
１４ アプリケーション・サーバ
２４ 管理部
２６ 処理実行部
２８ サービス受付部
３０ サービスＩＤ生成部
３２ サービス呼出部
３４ 処理結果確認部
３６ 結果確認呼出部
３８ 処理状況テーブル
４２ リクエスタ
４６ プロバイダ
４８ パッケージ・ラッパー
５０ ＭＢラッパー
６６ 既存システム
６８ 既存システム
【技術分野】
【０００１】
本発明はサービス処理装置、システム、プログラム及び記録媒体に係り、特に、要求されたサービスを実行するサービス処理装置、該サービス処理装置を複数備えたサービス処理システム、コンピュータを前記サービス処理装置として機能させるためのサービス処理プログラム、及び、当該サービス処理プログラムが記録された記録媒体に関する。
【背景技術】
【０００２】
近年、大規模なシステムを「サービス」の集まりとして構築する設計手法であるＳＯＡ(Service Oriented Architecture：サービス指向アーキテクチャ)が普及してきている。このＳＯＡに関連して特許文献１には、多くのデータベースを有するシステムにＳＯＡを適用して連携させる場合に、多くのデータベースに亘るデータ整合性の確立について述べられている。
【０００３】
また特許文献２には、ＳＯＡモデルを実現するウェブサービスを実行するコンピュータにおいて、認証・権限処理のための制御の流れをサービス提供処理の流れと独立して設けることにより、サービスと、そのサービスに対する認証・権限処理サービスの疎結合を実現する技術が開示されている。
【０００４】
また特許文献３には、サービスＩＤを含むサービス定義、ビジネスプロセスＩＤ及びサービスＩＤの対応情報を示しビジネスプロセス定義を格納しておき、入力されたサービスを検索キーとしてサービス定義を検索しサービスＩＤを取得し、当該サービスＩＤを検索キーとしてビジネスプロセス定義を検索しビジネスプロセスＩＤを取得し、対応する情報を出力する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００８−５１１９３４号公報
【特許文献２】特開２００６−７２５４８号公報
【特許文献３】特開２００７−３０４９５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＳＯＡを適用して構築されたコンピュータ・システムは、機能単位でプログラムが分割されると共に、分割した個々の機能のうちの一部機能を実現するプログラムが既に開発済みであれば、開発済みのプログラムを流用して構築されるので、互いに異なる機能を実現するプログラム（サービス処理部）が疎結合によって複数段連結され、コンピュータ・システムに入力された個々のサービス要求を複数段のサービス処理部が連携して処理する構成となることが一般的である。このような構成のコンピュータ・システムで障害が発生した場合、個々のサービス処理部が保持するデータや、異なるサービス処理部に接続されたデータベース(ＤＢ)が保持するデータに不整合が生じる可能性がある。
【０００７】
これに対し、サービス処理部が複数段連結された構成のコンピュータ・システムにデータの整合性を保証するための機能を設けようとすると、システムの設計や開発が非常に複雑となり、多大な工数を必要とするという問題がある。そして特許文献１〜３には、上述した問題を解決する技術は何ら開示されていない。
【０００８】
本発明は上記事実を考慮して成されたもので、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現できるサービス処理装置、サービス処理システム、サービス処理プログラム及び記録媒体を得ることが目的である。
【課題を解決するための手段】
【０００９】
上記目的を達成するために請求項１記載の発明に係るサービス処理装置は、コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能を備えている。
【００１０】
請求項１記載の発明に係るサービス処理装置はコンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成している。なお、サービス処理システムの典型的な構成は、個々のサービス処理装置が互いに異なるコンピュータによって実現される構成であるが、一部又は全てのサービス処理装置が同一のコンピュータによって実現される構成であってもよい。また、請求項１記載の発明に係るサービス処理装置は、以下で説明する第１機能〜第３機能を各々備えている。
【００１１】
すなわち、本発明に係る第１機能は、サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ下位サービスの処理結果を前記生成したサービスＩＤと対応付けて記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する機能である。ここで、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合（個々のサービス処理装置が上記の第１機能を各々備えている場合）、最上位のサービス処理装置に対してサービスの実行を要求すると、要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理が行われると共に、必要に応じて下位のサービス処理装置へサービス要求が送信され、当該サービス要求を受信したサービス処理装置でも必要に応じて下位にサービス処理装置へサービス要求が送信される。これにより、サービス処理装置の連結数等に拘わらず、サービスの実行が必要に応じて自動的に連鎖することになる。
【００１２】
また、本発明に係る第２機能は、サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する機能である。ここで、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合（個々のサービス処理装置が上記の第２機能を各々備えている場合）、最上位のサービス処理装置に対して処理結果の確認を要求すると、要求されたサービスに関する処理の処理結果が確認され、必要に応じて下位のサービス処理装置へ処理結果確認要求が送信され、当該処理結果確認要求を受信したサービス処理装置でも必要に応じて下位にサービス処理装置へ処理結果確認要求が送信される。これにより、サービス処理装置の連結数等に拘わらず、処理結果確認要求が必要に応じて自動的に連鎖した後に確認した処理結果が通知されるので、障害等の発生により以前のサービス要求に対する応答が返ってきていない等の場合に、以前に実行を要求したサービスの処理結果を確認することが可能となる。
【００１３】
また、本発明に係る第３機能は、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する機能である。
【００１４】
なお、冪等性を有するサービスは、何回実行しても同じ結果が得られるサービスであり、参照系のサービス(例えばデータベースからデータを読み出して出力するサービス等)がこれに該当する。一方、冪等性を有しないサービスは、実行する度に結果が変化するサービスであり、更新系のサービス(例えば実行の都度、データベースのデータに値を加算するサービス等)がこれに該当する。ここで、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合（個々のサービス処理装置が上記の第３機能を各々備えている場合）、仮想冪等機能（実際のサービスが冪等性を有しているか否かに拘わらず、サービスの実行が何度要求されても同じ結果が得られるようにする機能）が実現され、障害等の発生により以前に要求したサービスの実行に対する応答が返ってきていない等の場合に、対応する下位サービスの中に冪等性を有しないサービスが存在しているか否かを考慮せずに、サービスの実行を再度要求することが可能となるので、本発明に係るサービス処理装置を含んで構成されたサービス処理システムの構成を簡略化することが可能となる。また、冪等性を有する下位サービスを実行させる際には当該下位サービスの処理結果の確認が省略されるので、サービス処理装置を実現するコンピュータに加わる負荷を軽減することができる。
【００１５】
このように、請求項１記載の発明に係るサービス処理装置は、上述した第１機能〜第３機能が設けられていることで、障害発生時にデータの整合性を保証することを容易に実現することができる。また、サービス処理システムを構成する個々のサービス処理装置に請求項１記載の発明を適用した場合、サービス処理システムを構成する個々のサービス処理装置の基本構成を同一とすることができるので、サービス処理システムを簡易な構成とすることができ、設計や開発に要する工数も大幅に削減することができる。従って、請求項１記載の発明によれば、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００１６】
請求項２記載の発明に係るサービス処理装置は、コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、を備え、前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させる。
【００１７】
請求項２記載の発明に係るサービス処理装置は、請求項１記載の発明と同様に、コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成している。また、請求項２記載の発明に係るサービス処理装置は、上記のサービス実行手段及び処理結果管理手段を各々備えている。
【００１８】
上記構成により、請求項２記載の発明に係るサービス処理装置に対してサービスの実行を要求すると、実行が要求されたサービスに関する処理がサービス実行手段で行われる。また、自装置よりも下位のサービス処理装置が存在し、実行が要求されたサービスが下位のサービス処理装置による下位サービスを含むサービスである場合、実行が要求されたサービスに関する処理として、サービスＩＤ生成手段によって下位サービスのサービスＩＤを生成させ、生成された下位サービスのサービスＩＤを付加したサービス要求をサービス呼出手段によって下位のサービス処理装置へ送信し、サービス呼出手段が下位のサービス処理装置から受信した応答によって通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させる処理が行われる。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、上位のサービス処理装置からのサービス要求をサービス受付手段で受信した個々のサービス処理装置において、受信したサービス要求に応じてサービス実行手段で上記処理が行われることが繰り返されることで、サービス処理装置の連結数等に拘わらず、サービスの実行が必要に応じて自動的に連鎖することになる。
【００１９】
また、自装置よりも上位のサービス処理装置が存在する場合、サービス実行手段は、サービスＩＤが付加されたサービス要求をサービス受付手段が上位のサービス処理装置から受信することで実行が要求されたサービスに関する処理を行い、当該処理の処理結果をサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させた後に、サービス受付手段によって上位のサービス処理装置へ応答を送信する。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、下位のサービス処理装置から応答を受信した個々のサービス処理装置において、サービス実行手段で上記処理が行われ、上位のサービス処理装置へ応答を送信することが繰り返されることで、サービス処理装置の連結数等に拘わらず、サービス要求に対する応答も自動的に連鎖することになる。
【００２０】
また、請求項２記載の発明に係るサービス処理装置は サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段を備えているが、処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合、サービスＩＤが付加された処理結果確認要求を処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認する。また、自装置よりも下位のサービス処理装置が存在し、かつ下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合、処理結果管理手段は、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を結果確認呼出手段によって下位のサービス処理装置へ送信する。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、上位のサービス処理装置からの処理結果確認要求を処理結果確認手段で受信した個々のサービス処理装置において、受信した処理結果確認要求に応じて処理結果管理手段で上記処理が行われることが繰り返されることで、サービス処理装置の連結数等に拘わらず、処理結果の確認要求が必要に応じて自動的に連鎖することになる。
【００２１】
また、自装置よりも下位のサービス処理装置が存在する場合、処理結果管理手段は、下位のサービス処理装置から結果確認呼出手段へ通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて記憶手段に記憶させる。また、自装置よりも上位のサービス処理装置が存在する場合、処理結果管理手段は、処理結果の確認が終了すると確認した処理結果を処理結果確認手段によって上位のサービス処理装置へ通知する。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合（個々のサービス処理装置を請求項２記載の発明に係るサービス処理装置で構成した場合）、下位のサービス処理装置から結果確認呼出手段へ下位サービスの処理結果が通知された個々のサービス処理装置において、処理結果管理手段で上記処理が行われることが繰り返されることで、サービス処理装置の連結数等に拘わらず、処理結果の通知も自動的に連鎖することになり、障害等の発生により以前のサービス要求に対する応答が返ってきていない等の場合に、以前に実行を要求したサービスの処理結果を確認することが可能となる。
【００２２】
更に、請求項２記載の発明において、下位のサービス処理装置へのサービス要求の送信は、より詳しくは、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に冪等性を有する下位サービスが存在している場合、冪等性を有する下位サービスの処理結果を処理結果管理手段に確認することなく、冪等性を有する下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信することによって行われ、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に非冪等の下位サービスが存在している場合は、非冪等の下位サービスの処理結果を処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、非冪等の下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了するとサービス受付手段によってサービス要求の送信元の上位のサービス処理装置へ確認した処理結果に応じた応答が送信される。
【００２３】
これにより、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合、仮想冪等機能が実現され、障害等の発生により以前に要求したサービスの実行に対する応答が返ってきていない等の場合に、対応する下位サービスの中に冪等性を有しないサービスが存在しているか否かを考慮せずに、サービスの実行を再度要求することが可能となるので、本発明に係るサービス処理装置を含んで構成されたサービス処理システムの構成を簡略化することが可能となる。また、冪等性を有する下位サービスを実行させる際には当該下位サービスの処理結果の確認が省略されるので、サービス処理装置を実現するコンピュータに加わる負荷を軽減することができる。
【００２４】
このように、請求項２記載の発明に係るサービス処理装置システムは、上記のサービス実行手段及び処理結果管理手段を備えているので、障害発生時にデータの整合性を保証することを容易に実現することができる。また、サービス処理システムを構成する個々のサービス処理装置に請求項２記載の発明を適用した場合、サービス処理システムを構成する個々のサービス処理装置の基本構成を同一とすることができるので、サービス処理システムを簡易な構成とすることができ、設計や開発に要する工数も大幅に削減することができる。従って、請求項２記載の発明によれば、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００２５】
なお、請求項２記載の発明において、サービス実行手段は、例えば請求項３に記載したように、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在しており、かつサービス受付手段が上位のサービス処理装置からサービス要求を受信することで実行が要求されたサービスが、対応する下位サービスが存在しているサービスである場合、サービスＩＤ生成手段によって生成された下位サービスのサービスＩＤを付加したサービス要求をサービス呼出手段によって下位のサービス処理装置へ送信すると共に、サービス呼出手段が下位のサービス処理装置から応答を受信した後に、サービス受付手段によって上位のサービス処理装置へ応答を送信するように構成することができる。
【００２６】
また、請求項２又は請求項３記載の発明において、サービス実行手段は、例えば請求項４に記載したように、実行が要求されたサービスが自サービスを含むサービスである場合に、実行が要求されたサービスに関する処理として、自サービスの処理を行い、自サービスの処理結果を通知されたサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させるように構成することができる。
【００２７】
また、請求項２〜請求項４の何れかに記載の発明において、サービス実行手段は、例えば請求項５に記載したように、自装置よりも下位のサービス処理装置が複数存在する場合、サービス呼出手段を下位のサービス処理装置と同数個備えており、自装置よりも下位のサービス処理装置が複数存在し、かつ実行が要求されたサービスが複数の下位のサービス処理装置による複数の下位サービスを含むサービスである場合に、実行が要求されたサービスに関する処理として、複数の下位のサービス処理装置のうちの特定の下位のサービス装置による特定の下位サービスのサービスＩＤをサービスＩＤ生成手段によって生成させ、生成された下位サービスのサービスＩＤを付加したサービス要求を、特定の下位のサービス装置に対応する特定のサービス呼出手段によって特定の下位のサービス処理装置へ送信し、特定のサービス呼出手段が特定の下位のサービス処理装置から受信した応答によって通知された特定の下位サービスの処理結果を、特定の下位サービスのサービスＩＤと対応付けて処理結果管理手段の記憶手段に記憶させる処理を、複数の下位のサービス処理装置について各々行う（逐次行うようにしてもよいし、並列に行うようにしてもよい）ように構成することができる。これにより、単一のサービス処理装置の下位にサービス処理装置が複数存在している場合にも、複数存在している下位のサービス処理装置の各々に対し、サービスの実行を自動的に連鎖させることができる。
【００２８】
また、請求項５記載の発明において、サービス実行手段は、例えば請求項６に記載したように、複数の下位のサービス処理装置のうちの何れかからの応答によって通知された下位サービスの処理結果がエラーであった場合、複数の下位のサービス処理装置の中に要求された下位サービスが「処理済」の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応するサービス呼出手段により、「処理済」の下位サービスの取消を要求するサービス要求を、下位サービスが「処理済」の下位のサービス処理装置へ送信させるように構成することが好ましい。実行が要求されたサービスが複数の下位のサービス処理装置による複数の下位サービスを含むサービスである場合、複数の下位サービスが全て正常に処理されないとデータの不整合等の不具合が生ずる可能性がある。これに対して請求項６記載の発明では、「処理済」の下位サービスの取消を要求するサービス要求を対応する下位のサービス処理装置へ送信させるので、複数の下位サービスを含むサービスの実行が要求され、複数の下位サービスのうちの一部の下位サービスでエラーが発生した場合に、データの不整合等の不具合が発生することを自動的に防止することができる。
【００２９】
また、請求項５記載の発明において、サービス実行手段は、例えば請求項７に記載したように、複数の下位のサービス処理装置のうちの何れかからの応答によって通知された下位サービスの処理結果がエラーであった場合、複数の下位のサービス処理装置の中にサービス要求を未送信の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応するサービス呼出手段によるサービス要求の送信を中止するように構成してもよい。これにより、複数の下位サービスを含むサービスの実行が要求され、複数の下位サービスのうちの一部の下位サービスでエラーが発生した場合に、下位サービスの実行を要求するサービス要求が無駄に送信されることを防止することができる。
【００３０】
また、請求項２〜請求項７の何れかに記載の発明において、自装置よりも下位のサービス処理装置が存在し、コンピュータをサービス処理装置として機能させるためのプログラムがＢＰＥＬのプラットフォーム上で動作する場合、サービス実行手段は、例えば請求項８に記載したように、サービスＩＤが通知されてサービスの実行が要求される毎に生成され、通知されたサービスＩＤを保持すると共に、処理の進行状態を表す状態情報を記憶しかつ処理の進行状態の変化に応じて前記状態情報を適宜更新するインスタンスよって実現され、前記インスタンスが新たに生成される毎に、当該新たに生成されたインスタンスにおいて、過去に生成され同一のサービスＩＤを保持しているインスタンスを検索し、該当するインスタンスが存在していた場合は前記該当するインスタンスの状態情報を自インスタンスの状態情報として複写し、複写した状態情報に従って処理を行うように構成することが好ましい。これにより、コンピュータをサービス処理装置として機能させるためのプログラムがＢＰＥＬのプラットフォーム上で動作する構成において、以前に実行が要求されたサービスの実行が再度要求され、前回の処理が途中で停止していた場合に、今回の処理を前回の処理の続きから開始することを、ＢＰＥＬのプラットフォームの特徴を利用して簡易な処理で実現することができる。
【００３１】
また、請求項２記載の発明において、処理結果管理手段は、例えば請求項９に記載したように、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在し、かつ処理結果確認手段が上位のサービス処理装置から処理結果確認要求を受信することで処理結果の確認が要求されたサービスに対応する下位サービスが存在しており、かつ記憶手段に記憶されている対応する下位サービスの処理結果が「不明」の場合に、下位サービスのサービスＩＤを付加した処理結果確認要求を結果確認呼出手段によって下位のサービス処理装置へ送信し、下位のサービス処理装置から結果確認呼出手段へ処理結果が通知された後に、処理結果の確認が要求されたサービスの処理結果を処理結果確認手段によって上位のサービス処理装置へ通知するように構成することができる。
【００３２】
また、請求項２〜請求項９の何れかに記載の発明において、サービスＩＤ生成手段は、例えば請求項１０に記載したように、サービス処理装置毎に相違するＩＤを設定した固有ＩＤと、サービス要求毎に相違するＩＤを設定した要求ＩＤを含むＩＤ要素を生成するＩＤ要素生成手段と、自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を各々設定した呼出元ＩＤ及び呼出先ＩＤを含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤに呼出先ＩＤとして設定されているＩＤ要素を設定した呼出元ＩＤと、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定した呼出先ＩＤを含むサービスＩＤを生成するＩＤ要素組合せ手段と、を含んで構成されていることが好ましい。
【００３３】
これにより、ＩＤ要素生成手段によって生成される個々のＩＤ要素は、少なくともサービス処理装置（ＩＤ要素生成手段）を単位とする一意性が確保される（他のＩＤ要素と重複していないことが保証される）と共に、サービス処理装置（ＩＤ要素生成手段）内における個々のサービス要求を単位とする一意性も確保される。また、サービス処理システムを構成する個々のサービス処理装置に請求項１０記載の発明を各々適用した場合、上位のサービス処理装置が存在する個々のサービス処理装置において、上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤにおける呼出先ＩＤと、下位のサービス処理装置へ送信するサービス要求に付加されるサービスＩＤにおける呼出元ＩＤが一致されることになるので、障害等が発生した場合にも、個々のサービス処理装置の処理結果管理手段の記憶手段に記憶されているサービスＩＤを参照し、呼出先ＩＤと呼出元ＩＤが一致しているサービスＩＤ（対応するサービス要求に付加されたサービスＩＤ）を順に辿っていくことで、実行が要求されたサービスの処理履歴を把握することが可能となる。
【００３４】
また、請求項１０記載の発明において、ＩＤ要素組合せ手段は、例えば請求項１１に記載したように、自装置よりも上位のサービス処理装置が存在しない場合は、ＩＤ要素生成手段によって生成されたＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤにオリジナルＩＤとして設定されているＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成するように構成することが好ましい。これにより、サービス処理システムを構成する個々のサービス処理装置に請求項１１記載の発明を各々適用した場合、対応するサービス要求に付加されるサービスＩＤはオリジナルＩＤが同一とされることになるので、個々のサービス要求に付加されたサービスＩＤのうちのオリジナルＩＤが同一か否かに基づいて、対応するサービス要求を識別することができ、前述のようにサービスＩＤの呼出元ＩＤ及び呼出先ＩＤに設定されているＩＤ要素に基づいて同一のサービス要求を辿っていくことが困難となった場合にも、オリジナルＩＤを参照することで、要求されたサービスの処理履歴を確実に把握することができる。
【００３５】
また、請求項１０又は請求項１１記載の発明において、ＩＤ要素生成手段は、例えば請求項１２に記載したように、コンピュータをサービス処理装置として機能させるためのプログラムの実行単位に付与された実行単位ＩＤも含むＩＤ要素を生成するように構成することが好ましい。なお、上記の実行単位は、例えばプロセス、タスク、スレッド等の何れであってもよい。これにより、上記の実行単位が単一のコンピュータ内に複数存在している場合にも、個々の実行単位（サービス処理装置）によってサービス要求に付加されるサービスＩＤ（の少なくとも実行単位ＩＤ）が相違することになり、サービス要求に付加されたサービスＩＤのうちの実行単位ＩＤを参照することで、対応するサービス要求が複数のサービス処理装置のうちの何れの実行単位（サービス処理装置）で処理されたのかを判断することが可能となる。
【００３６】
また、請求項１３記載の発明に係るサービス処理システムは、請求項１〜請求項１２の何れか１項記載のサービス処理装置が情報を送受可能に複数設けられて構成されているので、請求項１記載の発明や請求項２記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００３７】
請求項１４記載の発明に係るサービス処理プログラムは、コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、前記コンピュータを、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、を備え、前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させるサービス処理装置として機能させる。
【００３８】
請求項１４記載の発明に係るサービス処理プログラムは、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータを、上記のサービス実行手段及び処理結果管理手段を備えたサービス処理装置として機能させるためのプログラムであるので、前記コンピュータが請求項１４記載の発明に係るサービス処理プログラムを実行することで、前記コンピュータが請求項２に記載のサービス処理装置として機能することになり、請求項２記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００３９】
請求項１５記載の発明に係るサービス処理プログラムは、コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、前記コンピュータを、請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能させる。
【００４０】
請求項１５記載の発明に係るサービス処理プログラムは、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータを、請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能させるためのプログラムであるので、前記コンピュータが請求項１５記載の発明に係るサービス処理プログラムを実行することで、前記コンピュータが請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能することになり、請求項２〜請求項１２の何れか１項記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００４１】
請求項１６記載の発明に係る記録媒体は、コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムが記録された記録媒体であって、前記サービス処理プログラムは、前記コンピュータを、サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能を備えたサービス処理装置として機能させる。
【００４２】
請求項１６記載の発明に係る記録媒体は、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータを、上記の第１〜第３機能を備えたサービス処理装置として機能させるためのサービス処理プログラムが記録されているので、前記コンピュータが請求項１６記載の発明に係る記録媒体に記録されているサービス処理プログラムを読み出して実行することで、前記コンピュータが請求項１に記載のサービス処理装置として機能することになり、請求項１記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【００４３】
請求項１７記載の発明に係る記録媒体は、請求項１４又は請求項１５記載のサービス処理プログラムが記録されている。これにより、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するコンピュータが請求項１７記載の発明に係る記録媒体に記録されているサービス処理プログラムを読み出して実行することで、前記コンピュータが請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能することになり、請求項２〜請求項１２の何れかに記載の記載の発明と同様に、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる。
【発明の効果】
【００４４】
以上説明したように本発明は、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置に、サービスの実行の連鎖を実現する第１機能、以前に実行を要求したサービスの処理結果の確認を可能とする第２機能、及び、障害等の発生時に冪等性を有しないサービスの存在を考慮せずにサービスの実行を再度要求することを可能とする第３機能を各々設けたので、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる、という優れた効果を有する。
【００４５】
また本発明は、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置に、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段を設け、サービス実行手段を、自装置よりも上位のサービス処理装置が存在する場合に、自装置よりも上位のサービス処理装置が存在する場合に、サービス受付手段が上位のサービス処理装置からサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理を行い、処理結果をサービスＩＤと対応付けて記憶手段に記憶させた後に、サービス受付手段によって上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在し、下位のサービス処理装置による下位サービスを含むサービスの実行が要求された場合に、サービスＩＤ生成手段によって下位サービスのサービスＩＤを生成させ、生成されたサービスＩＤを付加したサービス要求をサービス呼出手段によって前記下位のサービス処理装置へ送信し、サービス呼出手段が下位のサービス処理装置から受信した応答によって通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に冪等性を有する下位サービスが存在している場合、冪等性を有する下位サービスの処理結果を処理結果管理手段に確認することなく、冪等性を有する下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に非冪等の下位サービスが存在している場合は、非冪等の下位サービスの処理結果を処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、処理結果管理手段により非冪等の下位サービスを行うサービス処理装置へ処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、非冪等の下位サービスを行うサービス処理装置へサービス呼出手段によってサービス要求を送信した後に、非冪等の下位サービスの処理結果を処理結果管理手段に再度確認する処理を行い、当該処理が終了するとサービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信するように構成すると共に、処理結果管理手段を、自装置よりも上位のサービス処理装置が存在する場合に、サービスＩＤが付加された処理結果確認要求を処理結果確認手段が上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果をサービスＩＤに基づいて確認し、処理結果の確認が終了すると処理結果を処理結果確認手段によって上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在し、かつ下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した結果確認要求を結果確認呼出手段によって下位のサービス処理装置へ送信し、下位のサービス処理装置から結果確認呼出手段へ通知された下位サービスの処理結果を、下位サービスのサービスＩＤと対応付けて記憶手段に記憶させるように構成したので、簡易な構成で、障害発生時にデータの整合性を保証することを容易に実現することができる、という優れた効果を有する。
【図面の簡単な説明】
【００４６】
【図１】本実施形態に係るサービス処理システムのハードウェア構成を示す概略ブロック図である。
【図２】ＳＯＡリファレンスモデルを説明する説明図である。
【図３】サービス要求受信時のサービス処理部の処理シーケンスを説明する概念図である。
【図４】処理結果確認要求受信時のサービス処理部の処理シーケンスを説明する概念図である。
【図５】本実施形態に係るサービス処理システムのソフトウェア構成を示す機能ブロック図である。
【図６】サービス受付部処理を示すフローチャートである。
【図７】処理実行部処理の一例(冪等呼び出し、補償無し)を示すフローチャートである。
【図８】処理実行部処理の一例(冪等呼び出し、補償無し、内部リトライ)を示すフローチャートである。
【図９】処理実行部処理の一例(冪等呼び出し、補償有り)を示すフローチャートである。
【図１０】処理実行部処理の一例(非冪等呼び出し、補償有り、内部リトライ)を示すフローチャートである。
【図１１】サービスＩＤ生成部処理を示すフローチャートである。
【図１２】サービス呼出部処理を示すフローチャートである。
【図１３】処理結果確認部処理を示すフローチャートである。
【図１４】管理部処理を示すフローチャートである。
【図１５】結果確認呼出部処理を示すフローチャートである。
【図１６】サービスＩＤの体系及び遷移の一例を示す概念図である。
【図１７】サービスＩＤにおけるＯＳＩＤの有効性を説明するための説明図である。
【図１８】ＢＰＥＬにおける仮想冪等機能の実現を説明する説明図である。
【図１９】サービスの実行が指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。
【図２０】サービスの実行が指示された場合のサービス処理システム全体のシーケンスの他の例を示すシーケンス図である。
【図２１】サービスの実行が指示された場合のサービス処理システム全体のシーケンスの他の例を示すシーケンス図である。
【図２２】サービスの実行が複数回指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。
【図２３】処理結果の確認が指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。
【発明を実施するための最良の形態】
【００４７】
以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には本実施形態に係るサービス処理システム１０が示されている。サービス処理システム１０は、複数台のサービス処理サーバ１２及び複数台のアプリケーション・サーバ１４がコンピュータ・ネットワーク１６を介して接続されて構成されている。
【００４８】
個々のアプリケーション・サーバ１４は、ＣＰＵ１４Ａ、ＲＯＭやＲＡＭ等から成るメモリ１４Ｂ、ＨＤＤ(Hard Disk Drive)等から成る記憶部１４Ｃ、ネットワークＩ／Ｆ(インタフェース)部１４Ｄを各々備えており、ネットワークＩ／Ｆ部１４Ｄを介してコンピュータ・ネットワーク１６に接続されている。個々のアプリケーション・サーバ１４は、既存の別のコンピュータ・システムの一部を構成するコンピュータであり（なお既存の別のコンピュータ・システムとしては、例えば金融機関の基幹系システム(預為システムやその他のパッケージ・システム)が挙げられる）、個々のアプリケーション・サーバ１４の記憶部１４Ｃには、既存の別のコンピュータ・システム向けに所定のサービスを提供するための互いに異なるアプリケーション・プログラムがインストールされている。
【００４９】
一方、個々のサービス処理サーバ１２は、ＣＰＵ１２Ａ、ＲＯＭやＲＡＭ等から成るメモリ１２Ｂ、ＨＤＤ等から成る記憶部１２Ｃ、ネットワークＩ／Ｆ(インタフェース)部１２Ｄを各々備えており、ネットワークＩ／Ｆ部１２Ｄを介してコンピュータ・ネットワーク１６に接続されている。また、記憶部１２Ｃにはサービス処理プログラムがインストールされており、更に処理状況テーブル(後述)も記憶されている。サービス処理プログラムは本発明に係るプログラムに対応しており、サービス処理サーバ１２は、ＣＰＵ１２Ａがサービス処理プログラムを実行することで、後述するサービス処理部（本発明に係るサービス処理装置）として機能する。
【００５０】
なお、図１では、複数台のサービス処理サーバ１２のうち最上位のサービス処理部として機能するサービス処理サーバ１２に、最上位のサービス処理部に対してサービスの実行を要求することを可能とする機器の一例として、オペレータが任意の情報を入力可能なキーボード１８と、任意の情報を表示可能なディスプレイ２０が接続された態様を示している。この態様では、オペレータがキーボード１８を操作することで、オペレータから最上位のサービス処理部へサービスの実行が要求され、実行が要求されたサービスの処理結果はディスプレイ２０に表示されてオペレータに視認される。但し、本発明は図１に示した態様に限られるものではなく、最上位のサービス処理部として機能するサービス処理サーバ１２には、最上位のサービス処理部に対してサービスの実行を要求する機器が接続されていてもよい。前記サービスの実行を要求する機器としては、例えばバッチジョブのコントローラや、他のコンピュータ・システム、インターネット、ウェブサーバ等が挙げられる。この態様では、前記機器から最上位のサービス処理部へサービスの実行がオペレータの操作等を経ずに直接要求され、実行が要求されたサービスの処理結果は最上位のサービス処理部から前記機器へ直接通知される。
【００５１】
次に本実施形態の作用を説明する。本実施形態に係るサービス処理システム１０は、ＳＯＡを適用し、提供すべきサービスを機能単位で分割し、分割した個々の機能のうち開発済みの機能（本実施形態では、サービス処理システム１０に接続された個々のアプリケーション・サーバ１４が提供するサービスがそれに相当する）についてはそれを流用して構築されており、互いに異なる機能を実現するサービス処理サーバ１２（によって実現されるサービス処理部）が疎結合によって複数段連結され、サービス処理システム１０に入力された個々のサービス要求を複数段のサービス処理部が連携して処理する構成とされている。また、本実施形態に係るサービス処理システム１０は、個々のサービス処理サーバ１２によって実現されるサービス処理部が図２に示すリファレンスモデルに準拠した構成となるように、個々のサービス処理サーバ１２の記憶部１２Ｃにインストールされるサービス処理プログラムが開発されている。
【００５２】
以下、まずサービス処理部のリファレンスモデルについて説明する。このリファレンスモデルでは、サービス処理部を、管理部２４、処理実行部２６、サービス受付部２８、サービスＩＤ生成部３０、サービス呼出部３２、処理結果確認部３４及び結果確認呼出部３６の各機能ブロックに分割し、各機能ブロック毎の機能を規定することで、サービス処理システム１０における障害等の発生時にデータの整合性を保証することを可能とするためにサービス処理部が備えているべき機能を規定している。
【００５３】
サービス処理部のリファレンスモデルにおいて、管理部２４は、処理状況テーブル３８を記憶する記憶部(ここでいう記憶部は、記憶部１２Ｃの記憶領域のうち処理状況テーブル３８等を記憶するために管理部２４に割当てられた記憶領域を指す)を備え、サービス処理部に対して実行が要求されたサービス（に対応する自サービス及び下位サービス）の処理結果を、前記サービスを識別するサービスＩＤと対応付けて処理状況テーブル３８で管理すると共に、下位サービスの処理結果の確認が必要な場合は、下位サービスの処理結果の確認を結果確認呼出部３６へ要求する機能を備えている。また処理実行部２６は、サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに対応する自サービスが有れば自サービスの処理を実行し、対応する下位サービスが有ればサービスＩＤ生成部３０でサービスＩＤを生成させ、下位サービスの実行をサービス呼出部３２へ要求する機能を備えている。
【００５４】
また、サービス受付部２８は上位のサービス処理部が存在している場合に設けられ、サービスＩＤが付加されたサービス要求を上位のサービス処理部から受信することでサービスの実行が要求されると、実行が要求されたサービスの実行を処理実行部２６に要求し、処理終了後に上位のサービス処理部へ応答を送信する機能を備えている。また、サービスＩＤ生成部３０は下位のサービス処理部が存在している場合に設けられ、処理実行部２６からの要求に応じて一意性を有するサービスＩＤを生成する機能を備えている。また、サービス呼出部３２は下位のサービス処理部が存在している場合に下位のサービス処理部と同数個設けられ、処理実行部２６からの要求に応じて下位サービスのサービスＩＤを付加したサービス要求を下位のサービス処理部へ送信する機能を備えている。
【００５５】
また、処理結果確認部３４は上位のサービス処理部が存在している場合に設けられ、サービスＩＤが付加された処理結果確認要求を上位のサービス処理部から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果をサービスＩＤを用いて管理部２４に確認し、処理結果の確認が終了すると確認した処理結果を上位のサービス処理部へ通知する機能を備えている。更に、結果確認呼出部３６は下位のサービス処理部が存在している場合に下位のサービス処理部と同数個設けられ、要求に応じて、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理部へ送信する機能を備えている。
【００５６】
次に、サービス処理部の各機能ブロック（管理部２４、処理実行部２６、サービス受付部２８、サービスＩＤ生成部３０、サービス呼出部３２、処理結果確認部３４及び結果確認呼出部３６）が上述した機能を備えていることで実現される、サービス処理部内における典型的な処理シーケンスを説明する。
【００５７】
上位のサービス処理部が存在するサービス処理部が、上位のサービス処理部からサービス要求を受信した場合、サービス要求を受信したサービス処理部では、各機能ブロックが連動することで図３に示す処理シーケンスで処理が行われる。すなわち、上位のサービス処理部からサービスＩＤが付加されたサービス要求を受信すると((1)参照)、サービス受付部２８は、処理実行部２６に対してサービスＩＤを通知してサービスの実行を要求する((2)参照)。処理実行部２６は実行が要求されたサービスの処理結果を管理部２４に確認する((3)参照)。そして、確認した処理結果が「処理済」であればサービス受付部２８へ直ちに応答を返す((12)参照)が、確認した処理結果が「未済」で、かつ実行が要求されたサービスに対応する自サービスが存在している場合は、自サービスの処理を実行し、処理結果をサービスＩＤと対応付けて処理状況テーブル３８に記録させる((4)参照）。
【００５８】
また、実行が要求されたサービスに対応する下位サービスが存在しており、かつ当該下位サービスが「処理済」でない場合、処理実行部２６はサービスＩＤ生成部３０によって下位サービスのサービスＩＤを生成させ((5)参照)、生成された下位サービスのサービスＩＤを処理状況テーブル３８に記録させ((6)参照)、。サービス呼出部３２に対して下位サービスのサービスＩＤを通知して下位サービスの実行を要求する((7)参照)。これにより、サービス呼出部３２は通知された下位サービスのサービスＩＤを付加したサービス要求を下位のサービス処理部へ送信する((8)参照)。また、下位のサービス処理部から応答を受信すると((9)参照)、受信した応答によって通知された下位サービスの処理結果を処理状況テーブル３８に記録させ((10)参照）、処理終了を処理実行部２６へ通知する((11)参照)。これを受けて処理実行部２６はサービス受付部２８へ処理結果を通知し((12)参照)、サービス受付部２８は上位のサービス処理部へ応答を送信することで処理結果を通知する((13)参照)。
【００５９】
また、上位のサービス処理部が存在するサービス処理部が、上位のサービス処理部から処理結果確認要求を受信した場合、サービス要求を受信したサービス処理部では、各機能ブロックが連動することで図４に示す処理シーケンスで処理が行われる。すなわち、上位のサービス処理部から処理結果確認要求を受信すると((1)参照)、処理結果確認部３４は、受信した処理結果確認要求によって処理結果の確認が要求されたサービスに対応する各サービスの処理結果を管理部２４に確認する((2)参照)。そして、対応する各サービスの中に処理結果が「不明」の下位サービスが無ければ上位のサービス処理部へ直ちに応答を返す((8)参照)が、処理結果が「不明」の下位サービスが存在している場合は、対応する結果確認呼出部３６に対し、下位サービスの処理結果の確認を要求する((3)参照)。
【００６０】
結果確認呼出部３６は、下位サービスの処理結果の確認が要求されると、下位のサービス処理部へ処理結果確認要求を送信する((4)参照)。また、下位のサービス処理部から下位サービスの処理結果を通知する応答を受信すると((5)参照)、通知された下位サービスの処理結果を処理状況テーブル３８に記録させ((6)参照)、管理部２４から処理結果確認部３４に確認された処理結果が通知される((7)参照)。これを受けて処理結果確認部３４は、通知された下位サービスの処理結果を含む処理結果を通知する応答を上位のサービス処理部へ送信する((8)参照）。
【００６１】
次に図５を参照し、上記のサービス処理部のリファレンスモデルに準拠して構築されたサービス処理システム１０のソフトウェアの構成の一例を説明する。図５に示すように、本実施形態に係るサービス処理システム１０は、５個のサービス処理部が３層(３段)に分けられており、３層目(３段目)の３個のサービス処理部が２層目(２段目)の単一のサービス処理部に各々連結され、２層目(２段目)の単一のサービス処理部が１層目(１段目)の単一のサービス処理部に連結されて構成されている。
【００６２】
１層目(最上位)のサービス処理部は、より上位のサービス処理部が存在しないため、サービス処理部のリファレンスモデルに対してサービス受付部２８及び処理結果確認部３４が省略されている。なお、以下では最上位のサービス処理部を便宜上「リクエスタ４２」と称する。リクエスタ４２として機能するサービス処理サーバ１２にキーボード１８及びディスプレイ２０が接続されている場合、リクエスタ４２は、オペレータによってキーボード１８が操作されることで入力された指示に応じて、下位のサービス処理部へサービス要求や処理結果確認要求を送信すると共に、下位のサービス処理部からの応答に基づきディスプレイ２０に処理結果等を表示する処理を行う。なお、リクエスタ４２として機能するサービス処理サーバ１２にサービスの実行を要求する機器(例えばバッチジョブのコントローラや、他のコンピュータ・システム、インターネット、ウェブサーバ等)が接続されている場合には、リクエスタ４２により、前記機器から要求を受信し、受信した要求に応じて下位のサービス処理部へサービス要求や処理結果確認要求を送信すると共に、下位のサービス処理部からの応答に基づき処理結果等を前記機器へ通知する処理が行われることになる。
【００６３】
また、２層目のサービス処理部は、下位のサービス処理部が３個存在しているため、サービス呼出部３２及び結果確認呼出部３６の組が３組設けられている。本実施形態では、２層目のサービス処理部のプログラムが、ＢＰＥＬエンジンと称されるＢＰＥＬ(Business Process Execution Language)のプラットフォーム上で動作するプログラムとして開発されており、２層目のサービス処理部として機能するサービス処理サーバ１２の記憶部１２Ｃには、上記のプラットフォームとして機能する所定のプログラムもインストールされている。以下では２層目のサービス処理部を便宜上「ＢＰＥＬ４４」と称する。ＢＰＥＬ４４は、リクエスタ４２から受信したサービス要求や処理結果確認要求に従い、下位の個々のサービス処理部へサービス要求や処理結果確認要求を送信したり、障害発生時にデータの整合性を保証するための処理を行う。
【００６４】
また３層目には、３個のサービス処理部として、既存の別のコンピュータ・システム(のアプリケーション・サーバ１４)と接続されていないサービス処理部と、既存の別のコンピュータ・システムとしてのパッケージ・システム６６(のアプリケーション・サーバ１４)と接続されたサービス処理部と、既存の別のコンピュータ・システムとしての預為システム６８(のアプリケーション・サーバ１４)と接続されたサービス処理部が存在している。これらのサービス処理部は、より下位のサービス処理部が存在しないため、サービス処理部のリファレンスモデルに対してサービス呼出部３２及び結果確認呼出部３６が省略されている。
【００６５】
３層目の３個のサービス処理部のうち、既存システムと接続されていないサービス処理部は、処理実行部２６によって行われる処理単独で一定のサービスが実現されるサービス処理部であり、以下では当該サービス処理部を便宜上「プロバイダ４６」と称する。
【００６６】
また３層目の３個のサービス処理部のうち、パッケージ・システム６６(のアプリケーション・サーバ１４)と接続されたサービス処理部には、サービス処理システム１０とパッケージ・システム６６とのインタフェースを司る機能ブロックとして、サービス処理システム１０内のサービスＩＤを代替するＩＤとしてパッケージ・システム６６固有のＩＤの採番を行うＩＤ変換部５２と、データ形式の相互変換を行う機能を各々備えパッケージ・システム６６と通信を行うことでサービスを実行させたり処理結果の確認を行うパッケージ呼出部５４及び結果確認呼出部５６が設けられている。以下では当該サービス処理部を便宜上「パッケージ・ラッパー４８」と称する。
【００６７】
また３層目の３個のサービス処理部のうち、預為システム６８(のアプリケーション・サーバ１４)と接続されたサービス処理部には、サービス処理システム１０と預為システム６８とのインタフェースを司る機能ブロックとして、サービス処理システム１０内のサービスＩＤを代替するＩＤとして預為システム６８固有のＩＤである端末番号の採番を行う端末管理部５８と、データ形式の相互変換を行う機能を各々備え預為システム６８と通信を行うことでサービスを実行させたり処理結果の確認（取引状況の照会）を行うＭＢ通信部６０及び取引状況照会部６２が設けられている。以下では当該サービス処理部を便宜上「ＭＢラッパー５０」と称する。
【００６８】
なお、本実施形態では説明の都合上、サービス処理システム１０の３層目のサービス処理部であるプロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０のうち、プロバイダ４６によって提供されるサービスと、ＭＢラッパー５０(及び預為システム６８)によって提供されるサービスは冪等性を有している一方、パッケージ・ラッパー４８(及びパッケージ・システム６６)によって提供されるサービスは冪等性を有していないものとする。なお、冪等性を有するサービスは何度実行しても結果が同じになるサービスであり、例えばＤＢ(データベース)の一定領域に格納されているデータを読み出して出力するサービス等が挙げられる。また、冪等性を有しないサービス（非冪等のサービス）は実行の度に結果が相違するサービスであり、例えばＤＢの一定領域に格納されている数値を実行の度に１ずつインクリメントして結果を出力するサービス等が挙げられる。
【００６９】
また、図５において、サービス受付部２８は本発明に係るサービス受付手段に、サービスＩＤ生成部３０は本発明に係るサービスＩＤ生成手段に、サービス呼出部３２は本発明に係るサービス呼出手段に、処理実行部２６、サービス受付部２８、サービスＩＤ生成部３０及びサービス呼出部３２は本発明に係る処理実行手段に、処理結果確認部３４は本発明に係る処理結果確認手段に、結果確認呼出部３６は本発明に係る結果確認呼出手段に、管理部２４、処理結果確認部３４及び結果確認呼出部３６は本発明に係る処理結果管理手段に各々対応している。また、ＢＰＥＬ４４、プロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０は本発明に係る「上位のサービス処理装置が存在するサービス処理装置」に対応しており、リクエスタ４２及びＢＰＥＬ４４は本発明に係る「下位のサービス処理装置が存在するサービス処理装置」に対応している。
【００７０】
次に、サービス処理部の各機能ブロックにおける処理について、図６〜図１５のフローチャートを参照して説明する。上位のサービス処理部が存在するサービス処理部は、上位のサービス処理部から、サービスの実行を要求するサービス要求及び実行を要求したサービスの処理結果の確認を要求する処理結果確認要求を受信するが、上位のサービス処理部が存在するサービス処理部にはサービス受付部２８が設けられており、このサービス受付部２８は、上位のサービス処理部からサービス要求を受信する際に図６に示すサービス受付部処理を行う。
【００７１】
このサービス受付部処理では、まずステップ８０で上位のサービス処理部からサービス要求の電文を受信し、次のステップ８２において、上位のサービス処理部からサービス要求の電文を受信したことを表すステータス情報を、受信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。なお、受信した電文には、実行が要求されたサービスのサービスＩＤが付加されており、上記処理によりサービスＩＤも処理状況テーブル３８に記憶される。次のステップ８４では受信した電文の内容をチェックし、受信した電文の内容を適正か否か判定する。判定が否定された場合はステップ８６へ移行し、上位のサービス処理部へ送信する応答電文にエラーメッセージを設定し、ステップ９０へ移行する。
【００７２】
一方、受信した電文の内容が適正であった場合は、ステップ８４の判定が肯定されてステップ８８へ移行し、受信したサービス要求の電文に付加されていたサービスＩＤを引数として処理実行部２６のＡＰＩを呼び出し、サービスの実行を要求する。これにより、処理実行部２６で処理実行部処理(後述)が行われる。処理実行部２６による処理実行部処理が終了し、実行を要求したサービスの処理結果が通知されると、通知された処理結果を上位のサービス処理部へ送信する応答電文に設定した後にステップ９０へ移行する。ステップ９０では、ステップ８６又はステップ８８で生成した応答電文を上位のサービス処理部へ送信する。またステップ９２では、上位のサービス処理部へ応答電文を送信したことを表すステータス情報を、送信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させ、サービス受付部処理を終了する。
【００７３】
次に、サービスの実行が要求されると処理実行部２６で行われる処理実行部処理について説明する。なお、処理実行部処理の内容は、上位のサービス処理部の有無や、下位のサービス処理部の有無及び数、下位のサービス処理部による下位サービスの冪等性の有無、サービスの実行を要求する呼び出しが仮想冪等機能(実際のサービスが冪等性を有しているか否かに拘わらず、サービスの実行が何度要求されても同じ結果が得られるようにする機能)を利用する呼び出し(以下、これを冪等呼び出しと称する)か仮想冪等機能を利用しない呼び出し(以下、これを非冪等呼び出しと称する)か、補償処理(後述)を行うか否か、等の条件に応じて大きく相違する。このため、以下では処理実行部処理の一例として、ＢＰＥＬ４４の処理実行部２６における代表的な処理を、図７〜図１０を参照して順に説明する。なお、図７〜図１０に示した処理実行部処理は、何れも、プロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０の各々による下位サービスの実行を必要とするサービスの実行が要求されることを前提としている。なお、処理実行部２６の呼び出し時には引数として冪等フラグ(ＦＬＧ)も処理実行部２６に引き渡され、この冪等フラグの値が１か０かによって冪等呼び出しと非冪等呼び出しが区別される。
【００７４】
図７に示す処理実行部処理は、ＢＰＥＬ４４の処理実行部２６に対して冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行わない、という条件での処理実行部処理の一例である。図７に示す態様では、処理実行部２６のプログラムが、処理実行部ＡＰＩと業務プログラムに分かれている。処理実行部ＡＰＩは、処理実行部２６の機能を実現する処理のうちの定型処理を行うプログラムであり、図７の例では、下位のサービス処理部(この例ではプロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０)からの応答のタイムアウトの監視(サービス要求を送信してから応答未受信の状態が規定時間以上継続したかを監視)、下位のサービス処理部へのサービス要求等のリトライ(例えば処理結果が「不明」等の場合のサービス要求の再送信等)、リトライ回数の監視(サービス要求等の送信回数が規定回数に達した場合に「異常」として処理する)等の処理が処理実行部ＡＰＩによって行われる。
【００７５】
なお、上記のように処理実行部のプログラムを処理実行部ＡＰＩと業務プログラムに分けることで、処理実行部ＡＰＩを部品化し、業務プログラムの処理内容が相違する処理実行部２６の開発する際にも、部品化した処理実行部ＡＰＩを流用することで、プログラム開発者が業務プログラムの開発に専念できるので、プログラム開発者の負担の軽減、プログラム開発に要する期間の短縮を実現することができる。
【００７６】
図７において、処理実行部２６のプログラムのうち業務プログラムによって実現される処理(以下、この処理を単に処理実行部処理と称する)は、処理実行部ＡＰＩ経由で外部から呼び出されることで起動される。仮想冪等機能を利用する冪等呼び出しでは、同一のサービスＩＤのサービスの実行が繰り返し要求される可能性があるので、まずステップ２００では、呼出時に引数として引き渡されたサービスＩＤを管理部２４に通知し、通知したサービスＩＤのサービスの実行が前回要求された際の処理結果(状況)を管理部２４に問い合わせる。次のステップ２０２では管理部２４から通知された情報に基づき、同一のサービスＩＤのサービスの実行が前回要求された際の処理が「処理中」か否か判定し、「処理中」であれば処理実行部ＡＰＩに制御を戻す。
【００７７】
また、同一のサービスＩＤのサービスの実行が前回要求された際の処理が「処理中」でない場合(引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていない場合や、同一のサービスＩＤのサービスの実行が前回要求された際の処理が終了している場合がこの条件に該当する)はステップ２０４へ移行する。下位サービス１は冪等性を有しているので、ステップ２０４では、下位サービス１の処理状況に拘わらず(下位サービス１が今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスとして過去に実行されているか否かや、下位サービス１が今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスとして過去に実行されている場合の処理結果等に拘わらず)、下位サービス１(ここではプロバイダ４６による下位サービス)の実行を、下位サービス１に対応するサービス呼出部３２へ指示する。これにより、下位サービス１に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、プロバイダ４６へサービス要求が送信される。
【００７８】
なお、今回引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていない場合は、サービス呼出部３２への指示に先立ち、引数として引き渡されたサービスＩＤをサービスＩＤ生成部３０へ通知して下位サービス１のサービスＩＤの生成を要求し、サービスＩＤ生成部３０で生成された下位サービス１のサービスＩＤを、管理部２４を通じ、引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させると共に、当該下位サービス１のサービスＩＤをサービス呼出部３２へ通知する処理も行われる。また、同一のサービスＩＤのサービスの実行が過去に要求されている場合は、サービス呼出部３２への指示に先立ち、管理部２４から通知された情報より対応する下位サービス１のサービスＩＤを抽出し、抽出したサービスＩＤをサービス呼出部３２へ通知する処理も行われる。
【００７９】
また、下位サービス１に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２０６において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「不明」又は「処理未済」である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによってリトライやリトライ回数の監視等の処理が行われる。また、通知された処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス２,３の実行を要求するサービス要求の送信はスキップされる。
【００８０】
一方、通知された処理結果が「処理済」である場合は、下位サービス１の処理が正常に終了しているのでステップ２１０へ移行する。下位サービス２(ここではパッケージ・ラッパー４８による下位サービス)は冪等性を有していないので、まずステップ２１０では、今回引数として引き渡されたサービスＩＤを管理部２４に通知し、通知したサービスＩＤのサービスの処理結果(状況)を管理部２４に問い合わせる。そして、次のステップ２１２では、管理部２４から通知された情報に基づいて、下位サービス２が今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスとして過去に実行されている場合の処理結果を判定し、判定した処理結果に応じて処理を分岐する。なお、先のステップ２００,２０２において、今回引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていないことが判明した場合は、ステップ２１０の実行をスキップし、ステップ２１２で処理結果は「処理未済」と判定するようにしてもよい。
【００８１】
ステップ２１２で判定した処理結果が「不明」又は「確認不能」(例えば管理部２４から結果確認呼出部３６へ下位サービス２の処理結果の確認が要求されたものの、パッケージ・ラッパー４８との通信リンクが確立していなかった等の場合))である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによって(処理結果確認の)リトライやリトライ回数の監視等の処理が行われる。また、判定した処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。また、判定した処理結果が「処理済」である場合は、下位サービス２の実行を要求するサービス要求の送信をスキップしてステップ２２０へ移行する。
【００８２】
一方、判定した処理結果が「処理未済」である場合はステップ２１４へ移行し、まず引数として引き渡されたサービスＩＤをサービスＩＤ生成部３０へ通知して下位サービス２のサービスＩＤの生成を要求し、サービスＩＤ生成部３０で生成された下位サービス２のサービスＩＤを、管理部２４を通じ、引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させると共に、当該下位サービス２のサービスＩＤを下位サービス２に対応するサービス呼出部３２へ通知し、下位サービス２の実行を指示する。これにより、下位サービス２に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、パッケージ・ラッパー４８へサービス要求が送信される。
【００８３】
また、下位サービス２に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２１６において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「不明」又は「処理未済」である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによってリトライやリトライ回数の監視等の処理が行われる。また、通知された処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。
【００８４】
一方、通知された処理結果が「処理済」である場合は、下位サービス２の処理も正常に終了しているのでステップ２２０へ移行する。下位サービス３は冪等性を有しているので、ステップ２２０では、先のステップ２０４と同様に下位サービス３の処理状況に拘わらず、下位サービス３(ここではＭＢラッパー５０による下位サービス)の実行を、下位サービス３に対応するサービス呼出部３２へ指示する。これにより、下位サービス３に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、ＭＢラッパー５０へサービス要求が送信される。
【００８５】
なお、今回引数として引き渡されたサービスＩＤのサービスの実行が過去に要求されていない場合は、サービス呼出部３２への指示に先立ち、引数として引き渡されたサービスＩＤをサービスＩＤ生成部３０へ通知して下位サービス３のサービスＩＤの生成を要求し、サービスＩＤ生成部３０で生成された下位サービス３のサービスＩＤを、管理部２４を通じ、引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させると共に、当該下位サービス３のサービスＩＤをサービス呼出部３２へ通知する処理も行われる。また、同一のサービスＩＤのサービスの実行が過去に要求されている場合は、サービス呼出部３２への指示に先立ち、管理部２４から通知された情報より対応する下位サービス３のサービスＩＤを抽出し、抽出したサービスＩＤをサービス呼出部３２へ通知する処理も行われる。
【００８６】
また、下位サービス３に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２２２において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「不明」又は「処理未済」である場合は、処理実行部ＡＰＩに制御を戻す。この場合、処理実行部ＡＰＩによってリトライやリトライ回数の監視等の処理が行われる。また、通知された処理結果が「業務エラー」である場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。また、一方、通知された処理結果が「処理済」である場合は、下位サービス３の処理も正常に終了しているので、処理結果が「処理済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【００８７】
続いて、図８に示す処理実行部処理について、図７に示す処理実行部処理と異なる部分のみ説明する。図８に示す処理実行部処理は、図７に示す処理実行部処理と同様に、ＢＰＥＬ４４の処理実行部２６に対して冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行わない、という条件に対応しており、下位のサービス処理部へのサービス要求等のリトライ及びリトライ回数の監視が、処理実行部ＡＰＩに代えて業務プログラムによって行われる点で図７に示す処理実行部処理と相違している。
【００８８】
すなわち、図８に示す処理実行部処理では、ステップ２０４で下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を指示し、ステップ２０６で下位サービス１に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合に、ステップ２０８において、下位サービス１を行うプロバイダ４６へサービス要求を送信した回数が規定値に達したか否かを判定することで、プロバイダ４６へのサービス要求の再送信(リトライ)を行うか否か判定する。プロバイダ４６へのサービス要求の送信回数が規定値未満の場合はステップ２０４に戻り、下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を再度指示することで、プロバイダ４６へサービス要求を再送信させる。また、プロバイダ４６へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス２,３の実行を要求するサービス要求の送信はスキップされる。
【００８９】
また、図８に示す処理実行部処理では、ステップ２１０でサービスの処理結果(状況)を管理部２４に問い合わせ、ステップ２１２で判定した下位サービス２の処理結果が「不明」又は「確認不能」であった場合、及び、ステップ２１４で下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を指示し、ステップ２１６で下位サービス２に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合に、ステップ２１８において、下位サービス２の処理結果を確認した回数又はパッケージ・ラッパー４８へサービス要求を送信した回数が規定値に達したか否かを判定することで、上記処理を再度行うか否か判定する。下位サービス２は冪等性を有していないので、下位サービス２の処理結果を確認した回数又はパッケージ・ラッパー４８へサービス要求を送信した回数が規定値未満の場合はステップ２１０に戻り、下位サービス２の処理結果確認以降の処理を再度行う。また、下位サービス２の処理結果を確認した回数又はパッケージ・ラッパー４８へサービス要求を送信した回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。
【００９０】
また、図８に示す処理実行部処理では、ステップ２２０で下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を指示し、ステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合に、ステップ２２４において、下位サービス３を行うＭＢラッパー５０へサービス要求を送信した回数が規定値に達したか否かを判定することで、ＭＢラッパー５０へのサービス要求の再送信(リトライ)を行うか否か判定する。ＭＢラッパー５０へのサービス要求の送信回数が規定値未満の場合はステップ２２０に戻り、下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を再度指示することで、ＭＢラッパー５０へサービス要求を再送信させる。また、ＭＢラッパー５０へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【００９１】
続いて、図９に示す処理実行部処理について、図７に示す処理実行部処理と異なる部分のみ説明する。図９に示す処理実行部処理は、ＢＰＥＬ４４の処理実行部２６に対して冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行う、という条件に対応しており、下位のサービス処理部からの応答のタイムアウトの監視、下位のサービス処理部へのサービス要求等のリトライ及びリトライ回数の監視等の処理は、図７に示す処理実行部処理と同様に処理実行部ＡＰＩによって行われる。
【００９２】
図９に示す処理実行部処理では、ステップ２１０でサービスの処理結果(状況)を管理部２４に問い合わせ、ステップ２１２で判定した下位サービス２の処理結果が「業務エラー」であった場合、及び、ステップ２１４で下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を指示し、ステップ２１６で下位サービス２に対応するサービス呼出部３２から通知された処理結果が「業務エラー」であった場合にステップ２３０へ移行する。この場合、今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスのうち、下位サービス１は処理結果が「処理済」であるのに対し、下位サービス２は処理結果が「業務エラー」で処理が未了であるので、データに矛盾が生じている。
【００９３】
このため、ステップ２３０では、データの整合性をとるために、下位サービス１に対応するサービス呼出部３２に対し、下位サービス１のサービスＩＤとして先のステップ２０４と同一のサービスＩＤを通知し、当該サービスＩＤの下位サービス１として先に実行した処理を取り消す処理の実行を要求するサービス要求の送信を指示する。これにより、下位サービス１に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、プロバイダ４６へ上記のサービス要求が送信される。そして、先に実行した処理を取り消す処理がプロバイダ４６によって行われることで、先に実行した処理で更新されたデータがあれば当該データが元のデータへ復元され、データの矛盾が解消される(データの整合性が確保される)ことになる。
【００９４】
また、下位サービス１に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２３２において、通知された処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「処理済」の場合は、処理結果が「業務エラー」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。また通知された処理結果が「業務エラー」又は「処理未済」又は「不明」の場合は、処理結果が「取消失敗」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合は、データの矛盾が解消して整合性が確保する処理は、バッチ処理等の別処理によって行われることになる。
【００９５】
また、図９に示す処理実行部処理では、ステップ２２０で下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を指示し、ステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「業務エラー」であった場合にステップ２２６へ移行する。この場合、今回引数として引き渡されたサービスＩＤのサービスに対応する下位サービスのうち、下位サービス１,２は処理結果が「処理済」であるのに対し、下位サービス３は処理結果が「業務エラー」で処理が未了であるので、データに矛盾が生じている。
【００９６】
このため、ステップ２２６では、データの整合性をとるために、下位サービス２に対応するサービス呼出部３２に対し、下位サービス２のサービスＩＤとして先のステップ２１４と同一のサービスＩＤを通知し、当該サービスＩＤの下位サービス２として先に実行した処理を取り消す処理の実行を要求するサービス要求の送信を指示する。これにより、下位サービス２に対応するサービス呼出部３２ではサービス呼出部処理(後述)が行われ、パッケージ・ラッパー４８へ上記のサービス要求が送信される。そして、先に実行した処理を取り消す処理がパッケージ・ラッパー４８によって行われることで、先に実行した処理で更新されたデータがあれば、当該データが元のデータへ復元される。
【００９７】
また、下位サービス２に対応するサービス呼出部３２から処理結果が通知されると、次のステップ２２８において、通知された処理結果に応じて処理を分岐する。通知された処理結果が「業務エラー」又は「処理未済」又は「不明」の場合は、処理結果が「取消失敗」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合は、データの矛盾が解消して整合性が確保する処理は、バッチ処理等の別処理によって行われる。また、通知された処理結果が「処理済」の場合はステップ２３０へ移行し、ステップ２３０で前述した処理が行われることで、先に実行した処理を取り消す処理の実行を要求するサービス要求がプロバイダ４６へも送信される。そして、先に実行した処理を取り消す処理がプロバイダ４６でも行われ、先に実行した処理で更新されたデータがあれば当該データが元のデータへ復元されることでデータの矛盾が解消される(データの整合性が確保される)ことになる。
【００９８】
続いて、図１０に示す処理実行部処理について、図７〜図９に示す処理実行部処理と異なる部分のみ説明する。図１０に示す処理実行部処理は、ＢＰＥＬ４４の処理実行部２６に対して非冪等呼び出しによってサービスの実行が要求され、処理実行部２６で補償処理を行う、という条件に対応している。また、図１０に示す処理実行部処理では、図７に示す処理実行部処理と同様に、下位のサービス処理部へのサービス要求等のリトライ及びリトライ回数の監視等の処理が業務プログラムによって行われる一方、タイムアウトの監視が処理実行部ＡＰＩによって行われる。
【００９９】
仮想冪等機能を利用しない非冪等呼び出しでは、同一のサービスＩＤのサービスの実行が複数回要求されることはないので、図１０に示す処理実行部処理ではステップ２００,２０２が省略されており、まずステップ２０４で下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を指示する。また、次のステップ２０６で下位サービス１に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合、図８に示す処理実行部処理と同様に、ステップ２０８でプロバイダ４６へのサービス要求の再送信(リトライ)を行うか否か判定する。プロバイダ４６へのサービス要求の送信回数が規定値未満の場合はステップ２０４に戻り、下位サービス１に対応するサービス呼出部３２へ下位サービス１の実行を再度指示することで、プロバイダ４６へサービス要求を再送信させる。また、プロバイダ４６へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス２,３の実行を要求するサービス要求の送信はスキップされる。
【０１００】
また、図１０に示す処理実行部処理では、ステップ２０６で下位サービス１に対応するサービス呼出部３２から通知された処理結果が「処理済」であった場合、次のステップ２３６で下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を指示する。また、下位サービス２に対応するサービス呼出部３２から処理結果が通知されるとステップ２３８へ移行し、通知された下位サービス２の処理結果に応じて処理を分岐する。すなわち、通知された処理結果が「業務エラー」の場合はステップ２３０へ移行し、図９に示す処理実行部処理と同様に、下位サービス１の実行要求に従ってプロバイダ４６が先に実行した処理を取り消す処理をプロバイダ４６によって行わせる。また、通知された処理結果が「処理済」の場合はステップ２２０へ移行する。
【０１０１】
一方、通知された処理結果が「不明」又は「処理未済」の場合は、下位サービス２が冪等性を有しておらず、かつ図１０に示す処理実行部処理が非冪等呼び出しで呼び出されることを考慮し、ステップ２４０で下位サービス２の処理結果を管理部２４に問い合わせ、次のステップ２４２で下位サービス２の処理結果を判定し、判定した処理結果に応じて処理を分岐する。そして、ステップ２４０,２４２の処理を経て下位サービス２の処理結果が「業務エラー」に切り替わった場合はステップ２３０へ移行する。また、ステップ２４０,２４２の処理を経て下位サービス２の処理結果が「処理済」に切り替わった場合はステップ２２０へ移行する。下位サービス２の処理結果が「不明」の場合は対処の判断が困難であるが、上記のように処理結果を再確認した結果、処理結果が「業務エラー」又は「処理済」に切り替わった場合は対処の判断が容易となる。また、ステップ２４２で判定した下位サービス２の処理結果が「不明」又は「確認不能」であった場合はステップ２４０に戻り、ステップ２４０,２４２の処理を再度行う。
【０１０２】
一方、ステップ２４２で判定した下位サービス２の処理結果が「処理未済」であった場合はステップ２４４へ移行し、パッケージ・ラッパー４８へのサービス要求の再送信(リトライ)を行うか否か判定する。パッケージ・ラッパー４８へのサービス要求の送信回数が規定値未満の場合はステップ２３６に戻り、下位サービス２に対応するサービス呼出部３２へ下位サービス２の実行を再度指示することで、パッケージ・ラッパー４８へサービス要求を再送信させる。また、パッケージ・ラッパー４８へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。この場合、下位サービス３の実行を要求するサービス要求の送信はスキップされる。
【０１０３】
また、ステップ２２０では下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を指示する。また、次のステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「不明」又は「処理未済」であった場合、図８に示す処理実行部処理と同様に、ステップ２２４でＭＢラッパー５０へのサービス要求の再送信(リトライ)を行うか否か判定する。ＭＢラッパー５０へのサービス要求の送信回数が規定値未満の場合はステップ２２０に戻り、下位サービス３に対応するサービス呼出部３２へ下位サービス３の実行を再度指示することで、ＭＢラッパー５０へサービス要求を再送信させる。また、ＭＢラッパー５０へのサービス要求の送信回数が規定値に達した場合は、処理結果が「不明」又は「処理未済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【０１０４】
また、図１０に示す処理実行部処理では、ステップ２２２で下位サービス３に対応するサービス呼出部３２から通知された処理結果が「業務エラー」の場合はステップ２２６へ移行し、図９に示す処理実行部処理と同様に、下位サービス２の実行要求に従ってパッケージ・ラッパー４８が先に実行した処理を取り消す処理をパッケージ・ラッパー４８によって行わせ、続いて、下位サービス１の実行要求に従ってプロバイダ４６が先に実行した処理を取り消す処理をプロバイダ４６によって行わせる。また、通知された処理結果が「処理済」の場合は処理結果が「処理済」であることを処理実行部ＡＰＩを通じて処理実行部２６の呼出元へ通知する。
【０１０５】
なお、図７〜図１０では、実行が要求されたサービスに対応する自サービスが存在しない場合の処理実行部処理を示しているが、実行が要求されたサービスに対応する自サービスが存在する場合は、処理実行部２６により、対応する自サービスの処理を実行し、処理結果を引数として引き渡されたサービスＩＤと対応付けて処理状況テーブル３８に記憶させる処理も行われる。
【０１０６】
また、下位のサービス処理部が存在するサービス処理部にはサービスＩＤ生成部３０が設けられており、サービスＩＤ生成部３０は処理実行部２６からサービスＩＤの生成が要求される毎に、図１１に示すサービスＩＤ生成部処理を行う。
【０１０７】
このサービスＩＤ生成部処理では、まずステップ１００において、自身（サービスＩＤ生成部３０）を含むサービス処理部（自サービス処理部）に固有のＩＤをリクエスタ固有ＩＤとして取得する。自サービス処理部に固有のＩＤとしては、例えば自サービス処理部が動作しているサービス処理サーバ１２のネットワークＩＤ等を適用することができる。また、ステップ１０２では自サービス処理部を実現するサービス処理プログラムを実行しているプロセスに割当てられているＩＤをプロセス毎ＩＤとして取得する。またステップ１０４では、リクエスト毎ＩＤとして、サービスＩＤを生成する毎に異なるＩＤを決定する。なお、リクエスト毎ＩＤとしては、例えば単純な通番、或いはＩＤ決定時の時刻等を適用することができる。そしてステップ１０６では、各ＩＤを組み合わせたＩＤ要素として、例として図１６(Ａ)に示すように、リクエスタ固有ＩＤ、プロセス毎ＩＤ及びリクエスト毎ＩＤを直列に並べたＩＤ要素を生成する。
【０１０８】
次のステップ１０８では、自サービス処理部が、より上位のサービス処理部が存在しない最上位のサービス処理部か否か判定する。判定が肯定された場合はステップ１１０へ移行し、新たなリクエスト毎ＩＤ（先のステップ２１４で決定したリクエスト毎ＩＤとは異なるＩＤ）を決定する。次のステップ１１２では、ステップ１１０で決定した新たなリクエスト毎ＩＤを、先のステップ１００で取得したリクエスタ固有ＩＤ、先のステップ１０２で取得したプロセス毎ＩＤと組み合わせ、新たなＩＤ要素（第２のＩＤ要素）を生成する。図１６(Ａ)に示すように、本実施形態に係るサービスＩＤは、オリジナルサービスＩＤ(ＯＳＩＤ)、呼出元サービスＩＤ(ＳＳＩＤ)及び呼出先サービスＩＤ(ＮＳＩＤ)から構成されており、次のステップ１１４では、先のステップ１０６で生成したＩＤ要素をオリジナルサービスＩＤ及び呼出元サービスＩＤに各々設定すると共に、ステップ１１２で生成した第２のＩＤ要素を呼出先サービスＩＤに設定したサービスＩＤを生成し(図１６(Ｂ)に示すサービス処理部Ａも参照）、生成したサービスＩＤを処理実行部２６へ通知して処理を終了する。
【０１０９】
なお、最上位のサービス処理部に設けられたサービスＩＤ生成部３０によって生成されるサービスＩＤは、上記のように、オリジナルサービスＩＤ及び呼出元サービスＩＤに設定するＩＤ要素と、呼出先サービスＩＤに設定するＩＤ要素を相違させることに限られるものではなく、オリジナルサービスＩＤ、呼出元サービスＩＤ及び呼出先サービスＩＤに全て同一のＩＤ要素を設定したサービスＩＤを生成するようにしてもよい。
【０１１０】
一方、自サービス処理部よりも上位のサービス処理部が存在しており、自サービス処理部が最上位のサービス処理部ではない場合は、ステップ１０８の判定が否定されてステップ１１６へ移行する。自サービス処理部が最上位のサービス処理部ではない場合は、自サービス処理部が上位のサービス処理部から受信したサービス要求に付加されていたサービスＩＤが処理実行部２６から通知され、ステップ１１６では、処理実行部２６より通知されたサービスＩＤから、オリジナルサービスＩＤとして設定されているＩＤ要素と、呼出先サービスＩＤとして設定されているＩＤ要素を各々抽出する。そしてステップ１１８では、通知されたサービスＩＤにオリジナルサービスＩＤとして設定されていたＩＤ要素をオリジナルサービスＩＤに設定すると共に、通知されたサービスＩＤに呼出先サービスＩＤとして設定されていたＩＤ要素を呼出元サービスＩＤに設定し、更に、先のステップ２１６で生成したＩＤ要素を呼出先サービスＩＤに設定したサービスＩＤを生成し(図１６(Ｂ)に示すサービス処理部Ｂ〜Ｄも参照）、生成したサービスＩＤを処理実行部２６へ通知して処理を終了する。
【０１１１】
本実施形態に係るサービス処理システム１０では、サービスＩＤ生成部３０が、下位のサービス処理部が存在しているサービス処理部に各々設けられており、個々のサービスＩＤ生成部３０でサービスＩＤの生成が各々行われるが、上記のように、ＩＤ要素にリクエスタ固有ＩＤを含めることで、個々のサービス処理部のサービスＩＤ生成部３０で生成されるＩＤ要素は、少なくとも個々のサービス処理部を単位とする一意性が確保される。また、ＩＤ要素にプロセス毎ＩＤを含めることで、個々のサービス処理部のサービスＩＤ生成部３０で生成されるＩＤ要素は、個々のサービス処理部内での一意性も確保される。従って、個々のサービス処理部のサービスＩＤ生成部３０で生成されるＩＤ要素は、サービス処理システム１０内における一意性が確保されている（他のＩＤ要素と重複していないことが保証されている）ので、一意性が確保されたＩＤ要素（サービスＩＤ）を生成するために排他制御を伴う採番処理を行う必要はなく、排他制御を伴う採番処理を行うことでサービス処理システム１０の性能が著しく低下することを回避できる。
【０１１２】
なお、ＩＤ要素にはプロセスＩＤも含まれているので、同一のサービス処理部として機能するプロセスが単一のサービス処理サーバ１２内に複数存在している場合にも、サービス要求に付加されたサービスＩＤのうちのプロセスＩＤを参照することで、対応するサービス要求が複数のサービス処理部のうちの何れのサービス処理部で処理されたのかを判断することも可能となる。
【０１１３】
また、上記のサービスＩＤ生成部処理を行うことで、最上位のサービス処理部を起点として下位のサービス処理部へ受け渡されるサービスＩＤは、例として図１６(Ｂ)に示すように遷移し、オリジナルサービスＩＤは一定で、上位のサービス処理部が存在する或るサービス処理部から出力される（サービス要求に付加される）サービスＩＤのうちの呼出元サービスＩＤには、上位のサービス処理部から受け取ったサービスＩＤにおける呼出先サービスＩＤと同一のＩＤ要素が設定され、前記或るサービス処理部から出力されるサービスＩＤのうちの呼出元サービスＩＤには、前記或るサービス処理部を識別可能なＩＤ要素が設定されることになる。これにより、サービス処理システム１０内で障害が発生し、特定のサービス処理部に処理未了のサービス要求が滞留した場合にも、滞留しているサービス要求に付加されたサービスＩＤに呼出元サービスＩＤとして設定されているＩＤ要素から、滞留しているサービス要求を送信したサービス処理部を識別することができ、この識別処理を、対応するサービスＩＤ（呼出元サービスＩＤが呼出先サービスＩＤと同一のサービスＩＤ）を辿りながら繰り返すことで、滞留している処理未了のサービス要求の処理履歴を把握することが可能となる。
【０１１４】
また、サービスＩＤが呼出元サービスＩＤ及び呼出先サービスＩＤのみから構成されていた場合、例えば図１７に示すように、サービス要求がサービス処理部Ａからサービス処理部Ｂ,Ｃを経由してサービス処理部Ｄ,Ｅに伝わった後で、サービス処理部Ｂ,Ｃに障害が発生し、サービス処理部Ｂ,Ｃに記録されていた情報が消失したときに、サービス処理部Ｄ,Ｅに呼出元サービスＩＤ及び呼出先サービスＩＤのみから成るサービスＩＤが記録されていたとすると、当該サービスＩＤの呼出元ＩＤ及び呼出先ＩＤに設定されているＩＤ要素に基づいて同一のサービス要求を辿っていくことは不可能である。これに対し、サービスＩＤにオリジナルサービスＩＤも加えておくことで、障害発生時もオリジナルＩＤを参照し、オリジナルサービスＩＤが同一のサービスＩＤと対応付けられた情報を同一のサービス要求に対応する情報とみなすことができ、例えばバッチ処理等により、オリジナルサービスＩＤをキーにして同一のサービス要求に対応する情報を検索・抽出し、データの矛盾を解消して整合性をとるための処理を行うことが可能となる。
【０１１５】
また、下位のサービス処理部が存在するサービス処理部には、サービス呼出部３２が下位のサービス処理部と同数個設けられており、サービス呼出部３２は、処理実行部２６から下位サービスのサービスＩＤが通知されて下位サービスの実行が要求される毎に、図１２に示すサービス呼出部処理を行う。このサービス呼出部処理では、まずステップ１３０において、下位のサービス処理部に対して下位サービスの実行を要求するサービス要求の電文を作成する。なお、この電文には処理実行部２６から通知された下位サービスのサービスＩＤが付加される。次のステップ１３２では、ステップ１３０で作成したサービス要求の電文を対応する下位のサービス処理部へ送信する。またステップ１３４では、対応する下位のサービス処理部へサービス要求の電文を送信したことを表すステータス情報を、送信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。
【０１１６】
ステップ１３２で送信したサービス要求の電文に対し、対応する下位のサービス処理部から応答電文が送信されると、次のステップ１３６で下位のサービス処理部から送信された応答電文を受信する。またステップ１３８では、下位のサービス処理部からサービス要求に対する応答電文を受信したことを表すステータス情報を、受信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させる。受信した応答電文には下位サービスのサービスＩＤと下位サービスの処理結果を表す情報が含まれており、上記処理によりこれらの情報も処理状況テーブル３８に記憶されることになる。そしてステップ１４０では、下位のサービス処理部からサービス要求に対する応答電文を受信したことを、受信した応答電文に設定されている下位サービスのサービスＩＤ及び下位サービスの処理結果と共に処理実行部２６へ通知し、サービス呼出部処理を終了する。
【０１１７】
また、上位のサービス処理部が存在するサービス処理部には処理結果確認部３４が設けられており、この処理結果確認部３４は、上位のサービス処理部から処理結果確認要求の電文を受信する際に図１３に示す処理結果確認部処理を行う。この処理結果確認部処理では、まずステップ１５０で上位のサービス処理部から処理結果確認要求の電文を受信し、次のステップ１５２において、上位のサービス処理部から処理結果確認要求の電文を受信したことを表すステータス情報を、受信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。次のステップ１５４では受信した電文の内容をチェックし、受信した電文の内容を適正か否か判定する。判定が否定された場合はステップ１５６へ移行し、上位のサービス処理部へ送信する応答電文にエラーメッセージを設定し、ステップ１６０へ移行する。
【０１１８】
一方、受信した電文の内容が適正であった場合は、ステップ１５４の判定が肯定されてステップ１５８へ移行し、受信した処理結果確認要求の電文に付加されている処理結果確認対象のサービスのサービスＩＤを抽出し、抽出したサービスＩＤを管理部２４に通知して対応するサービスの処理結果を管理部２４に問い合わせる。これにより、管理部２４では管理部処理(後述)が行われる。管理部２４による管理部処理が終了し、問い合わせた処理結果が通知されると、通知された処理結果を上位のサービス処理部へ送信する応答電文に設定した後にステップ１６０へ移行する。ステップ１６０では、ステップ１５６又はステップ１５８で生成した応答電文を上位のサービス処理部へ送信する。またステップ１６２では、上位のサービス処理部へ応答電文を送信したことを表すステータス情報を、送信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させ、処理結果確認部処理を終了する。
【０１１９】
また、管理部２４では、処理結果確認部３４や処理実行部２６からサービスＩＤが通知され、通知されたサービスＩＤのサービスの処理結果の問い合わせがある毎に、図１４に示す管理部処理を行う。
【０１２０】
この管理部処理では、まずステップ１７０において、処理結果確認部３４又は処理実行部２６から通知されたサービスＩＤをキーにして処理状況テーブル３８を検索し、通知されたサービスＩＤと対応付けて処理状況テーブル３８に登録されている処理結果情報（対応する自サービスや下位サービスの処理結果を各々表す情報）を抽出する。次のステップ１７２では抽出した処理結果情報を参照し、通知されたサービスＩＤに対応するサービスの中に、処理結果が「不明」の下位サービスが存在しているか否か判定する。処理結果確認対象のサービス（通知されたサービスＩＤのサービス）に対応する下位サービスが存在しない場合や、対応する下位サービスが存在しているものの、当該下位サービスの処理結果が「処理済」等の場合は判定が否定されてステップ１７６へ移行し、ステップ１７０で抽出した処理結果情報が表す処理結果を問い合わせ元の処理結果確認部３４又は処理実行部２６に通知し、処理を終了する。なお、通知されたサービスＩＤが処理状況テーブル３８に未登録の場合は未登録であることを表す情報を問い合わせ元へ通知する。
【０１２１】
また、処理結果確認対象のサービスに対応する下位サービスが存在しており、かつ当該下位サービスの処理結果が「不明」の場合は、ステップ１７２の判定が肯定されてステップ１７４へ移行し、処理結果が「不明」の下位サービスに対応する結果確認呼出部３６に対し、処理結果が「不明」の下位サービスのサービスＩＤを通知し、対応する下位サービスの処理結果の確認を要求する。これにより、結果確認呼出部３６では結果確認呼出部処理(後述)が行われる。また、結果確認呼出部３６における結果確認呼出部処理が完了し、結果確認呼出部３６によって確認された下位サービスの処理結果が通知されるとステップ１７２に戻る。これにより、処理結果確認対象のサービスに対応するサービスの中に処理結果が「不明」の下位サービスが複数存在している場合はステップ１７４が繰り返され、該当する全ての下位サービスの処理結果の確認が対応する結果確認呼出部３６で各々行われる。そしてステップ１７２の判定が否定されるとステップ１７６へ移行し、結果確認呼出部３６から通知された下位サービスの処理結果を含め、 処理結果確認対象のサービスの処理結果を問い合わせ元の処理結果確認部３４又は処理実行部２６に通知し、処理を終了する。
【０１２２】
また、下位のサービス処理部が存在するサービス処理部には、結果確認呼出部３６が下位のサービス処理部と同数個設けられており、結果確認呼出部３６は、管理部２４から下位サービスのサービスＩＤが通知されて下位サービスの処理結果の確認が要求される毎に、図１５に示す結果確認呼出部処理を行う。この結果確認呼出部処理では、まずステップ１８０において、下位のサービス処理部に対して下位サービスの処理結果の通知を要求する処理結果確認要求の電文を作成する。なお、この電文には管理部２４から通知された下位サービスのサービスＩＤが付加される。次のステップ１８２では、ステップ１８０で作成した処理結果確認要求の電文を対応する下位のサービス処理部へ送信する。またステップ１８４では、対応する下位のサービス処理部へ処理結果確認要求の電文を送信したことを表すステータス情報を、送信した電文と共に管理部２４の処理状況テーブル３８に記憶させる。
【０１２３】
ステップ１８２で送信した処理結果確認要求の電文に対し、対応する下位のサービス処理部から応答電文が送信されると、次のステップ１８６で下位のサービス処理部から送信された応答電文を受信する。またステップ１８８では、下位のサービス処理部から処理結果確認要求に対する応答電文を受信したことを表すステータス情報を、受信した応答電文と共に管理部２４の処理状況テーブル３８に記憶させる。受信した応答電文には下位サービスのサービスＩＤと下位サービスの処理結果を表す情報が含まれており、上記処理によりこれらの情報も処理状況テーブル３８に記憶されることになる。そしてステップ１９０では、下位のサービス処理部から処理結果確認要求に対する応答電文を受信したことを、受信した応答電文に設定されている下位サービスのサービスＩＤ及び下位サービスの処理結果と共に管理部２４へ通知し、処理結果確認呼出部処理を終了する。
【０１２４】
なお、上記では、サービス処理部の機能を便宜的に各機能ブロック毎に分けて説明したが、個々のサービス処理サーバ１２をサービス処理部として機能させるサービス処理プログラムは、各機能ブロック毎に分けられていてもよいし、一体化されていてもよい。
【０１２５】
また、個々のサービス処理部をリファレンスモデルに準拠して構築することで、個々のサービス処理部における処理はその大部分が定型処理になり、サービス処理部を実現するプログラムのうち、サービス受付部２８やサービスＩＤ生成部３０、サービス呼出部３２、処理結果確認部３４、結果確認呼出部３６を実現するプログラム、及び、処理実行部２６を実現するプログラムのうちの処理実行部ＡＰＩは部品化することが可能である。これにより、プログラム開発者は、部品化したプログラムを流用してサービス処理プログラムを開発することができ、個々のサービス処理部毎に異なる特有処理を実現するプログラム(例えば処理実行部２６の業務プログラム)の開発に専念できるので、プログラム開発者の負担の大幅な軽減、プログラム開発に要する期間の大幅な短縮を実現することができる。
【０１２６】
また、サービス処理システム１０における各サービス処理部のうち、ＢＰＥＬ４４ではサービス処理プログラムがＢＰＥＬのプラットフォーム上で動作するので、ＢＰＥＬが提供する機能を利用することで、仮想冪等機能を実現する処理実行部２６のプログラムをより容易に開発することが可能となる。すなわち、ＢＰＥＬのプラットフォームは、或るプログラムが呼び出される毎に、呼び出されたプログラムを実行するプロセス（インスタンスともいう）を生成し、メモリ１２Ｂ等の記憶手段の記憶領域のうち生成したプロセスに対応する所定領域（ＢＯ(Business Objects)という）に、呼出時の引数を設定すると共に、生成したプロセスにおける処理の進行状態を表す状態情報も設定し、対応するプロセスにおける処理の進行状態の変化に応じて状態情報を適宜更新する、という機能を提供している。
【０１２７】
このため、上記機能を利用し、例として図１８に示すように、サービス処理部のプログラムのうち、少なくとも処理実行部２６として機能するプログラム（当該プログラムにはサービス受付部２８として機能するプログラムやサービス呼出部３２として機能するプログラムも含まれていてもよい）を、サービスＩＤ及び冪等フラグを引数として呼び出され、起動されると、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在しているか否かを確認する(図１８の「処理結果確認」も参照)ように構成すれば、今回の呼び出しに対応するサービス要求が、過去に受けたサービス要求の再送であるか否かを簡単に確認することができる。また、上記プログラムを、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在している場合に、該当する他プロセス（該当する他プロセスが複数存在している場合は、そのうちの最新の(最後に生成された)他プロセス）のＢＯから状態情報をコピーする(図１８の「ＢＯコピー」も参照)ように構成することで、今回の呼び出しに対応するサービス要求を前回受けた際の処理の状態を継承し、前回の処理の続きから開始することを簡易な処理で実現することができる。また、上記プログラムを、実行が要求されたサービスに対応する非冪等の下位サービスが存在する場合に、当該下位サービスの処理結果を確認し、「処理済」であれば下位サービスの実行要求をスキップする(図１８の「実行済？」も参照)ように構成することで、仮想冪等機能を簡易な処理によって実現することができる。このように、ＢＰＥＬのプラットフォームの特徴を利用することで、サービス処理プログラムの開発負荷を更に削減することが可能となる。
【０１２８】
また、本実施形態に係るサービス処理システム１０では、個々のサービス処理部がサービス要求や処理結果確認要求の受信時に、図３や図４に示す処理シーケンスで処理を行うことで、最上位のサービス処理部が送信したサービス要求や処理結果確認要求が複数段のサービス処理部に亘って連鎖することになる。以下、最上位のサービス処理部からサービス要求や処理結果確認要求が送信された場合の、サービス処理システム１０全体としての処理シーケンスを説明する。なお以下では、対象サービスが、プロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０の各々による下位サービスの実行を必要とするサービスであるものとする。
【０１２９】
最上位のサービス処理部（リクエスタ４２）に対してサービスの実行が指示された場合のシーケンスの一例を図１９に示す。このシーケンスでは、リクエスタ４２に対してサービスの実行が指示されると、リクエスタ４２のサービスＩＤ生成部３０によって下位サービスのサービスＩＤ（ＢＰＥＬ４４へ送信するサービスＩＤ）が生成され（図１９のステップ２６０も参照）、リクエスタ４２のサービス呼出部３２によってＢＰＥＬ４４へサービス要求が送信される。
【０１３０】
サービス要求を受信したＢＰＥＬ４４の処理実行部２６は、実行が要求されたサービスに対応する自サービスが存在している場合には自サービスの処理を行い（図１９のステップ２６２も参照）、サービスＩＤ生成部３０によって下位サービス１のサービスＩＤ（プロバイダ４６へ送信するサービスＩＤ）を生成させ（図１９のステップ２６４も参照）、プロバイダ４６に対応するサービス呼出部３２を呼び出し、プロバイダ４６に対応するサービス呼出部３２によってプロバイダ４６へサービス要求を送信させる。サービス要求を受信したプロバイダ４６では、要求された下位サービス１の処理が処理実行部２６によって行われ（図１９のステップ２６６も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
【０１３１】
ＢＰＥＬ４４の処理実行部２６は、プロバイダ４６からの応答が受信され、処理結果が「処理済」であった場合、サービスＩＤ生成部３０によって下位サービス２のサービスＩＤ（パッケージ・ラッパー４８へ送信するサービスＩＤ）を生成させ（図１９のステップ２６８も参照）、パッケージ・ラッパー４８に対応するサービス呼出部３２を呼び出し、パッケージ・ラッパー４８に対応するサービス呼出部３２によってパッケージ・ラッパー４８へサービス要求を送信させる。サービス要求を受信したパッケージ・ラッパー４８では、要求された下位サービス２の処理がパッケージ・システム６６と協働することで行われ（図１９のステップ２７０も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
【０１３２】
ＢＰＥＬ４４の処理実行部２６は、パッケージ・ラッパー４８からの応答が受信され、処理結果が「処理済」であった場合、サービスＩＤ生成部３０によって下位サービス３のサービスＩＤ（ＭＢラッパー５０へ送信するサービスＩＤ）を生成させ（図１９のステップ２７２も参照）、ＭＢラッパー５０に対応するサービス呼出部３２を呼び出し、ＭＢラッパー５０に対応するサービス呼出部３２によってＭＢラッパー５０へサービス要求を送信させる。サービス要求を受信したＭＢラッパー５０では、要求された下位サービス３の処理が預為システム６８と協働することで行われ（図１９のステップ２７４も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
【０１３３】
ＢＰＥＬ４４では、パッケージ・ラッパー４８からの応答が受信され、処理結果が「処理済」であった場合、処理実行部２６からサービス受付部２８へ処理結果が通知され、サービス受付部２８はリクエスタ４２へ応答を送信して処理結果を通知する。これにより、リクエスタ４２では実行が指示されたサービスの処理結果(「処理済」)を出力する処理が行われる（図１９のステップ２７６も参照）。このように、最上位のリクエスタ４２からＢＰＥＬ４４を経由してプロバイダ４６やパッケージ・ラッパー４８、ＭＢラッパー５０へサービス要求が連鎖していくことで、指示されたサービスが実行される。
【０１３４】
次に、サービス処理システム１０に障害が発生した場合のシーケンスを説明する。図２０に示すシーケンスは、ＢＰＥＬ４４がパッケージ・ラッパー４８へサービス要求を送信した直後に障害が発生し、送信したサービス要求がパッケージ・ラッパー４８で受信されなかったことで、パッケージ・ラッパー４８から応答が送信されず、タイマがタイムアウトした場合のシーケンスである。図２０に示すシーケンスでは、ＢＰＥＬ４４からパッケージ・ラッパー４８へのサービス要求の再送信の図示を省略しているが、パッケージ・ラッパー４８へサービス要求を所定回再送信してもパッケージ・ラッパー４８からの応答が受信されなかった場合、ＢＰＥＬ４４の処理実行部２６の業務プログラムから処理実行部ＡＰＩへ制御が戻る。
【０１３５】
ここで、処理実行部ＡＰＩは、実行が要求されたサービスの処理結果が「不明(タイムアウト／リトライ回数超過)」であることをサービス受付部２８経由でリクエスタ４２へ通知するようにしてもよいが、図２０に示すシーケンスではパッケージ・ラッパー４８による下位サービス２の処理結果を管理部２４に問い合わせ、この場合、下位サービス２の処理結果が「不明」であることから、パッケージ・ラッパー４８に対応する結果確認呼出部３６によってＢＰＥＬ４４からパッケージ・ラッパー４８へ処理結果確認要求が送信される。 この間にサービス処理システム１０の障害が解消していた場合、この処理結果確認要求がパッケージ・ラッパー４８で受信され、パッケージ・ラッパー４８の処理結果確認部３４によって通知されたサービスＩＤに対応する下位サービス２の処理結果が確認される。この場合は処理結果が「処理未済」であるので、処理結果が「処理未済」であることを通知する処理結果通知がパッケージ・ラッパー４８からＢＰＥＬ４４へ送信される。
【０１３６】
パッケージ・ラッパー４８からの処理結果通知を受信し、処理結果が「処理未済」であることを確認すると、ＢＰＥＬ４４の処理実行部２６はパッケージ・ラッパー４８に対応するサービス呼出部３２を呼び出し、サービス呼出部３２によってＢＰＥＬ４４からパッケージ・ラッパー４８へサービス要求が再度送信される。これにより、パッケージ・ラッパー４８では、要求された下位サービス２の処理がパッケージ・システム６６と協働することで行われる（図２０のステップ２７０も参照）。以降のシーケンスは図１９と同一であるので説明を省略する。
【０１３７】
また、図２１に示すシーケンスは、ＭＢラッパー５０がＢＰＥＬ４４から受信したサービス要求で要求された下位サービス３の処理を預為システム６８と協働して行った結果、業務エラーが発生した場合（図２１のステップ２７５も参照）のシーケンスである。この場合、処理結果が「業務エラー」であることを通知する応答がＭＢラッパー５０からＢＰＥＬ４４へ送信される。この応答がＢＰＥＬ４４で受信されると、ＢＰＥＬ４４の処理実行部２６は、プロバイダ４６による下位サービス１及びパッケージ・ラッパー４８による下位サービス２が「処理済」で、ＭＢラッパー５０による下位サービス３が「業務エラー」となったことによるデータの不整合を解消するため、まず対応する下位サービス２のサービスＩＤを認識し（図２１のステップ２８２も参照）、パッケージ・ラッパー４８が先に実行した下位サービス２の処理を取り消す処理の実行を要求するサービス要求(図２１では「取消要求」と表記)を、サービス呼出部３２によってパッケージ・ラッパー４８へ送信させる。これにより、パッケージ・ラッパー４８は、実行が正常に終了している下位サービス２の処理をパッケージ・システム６６と協働して取り消す取消処理を行う（図２１のステップ２８４も参照）。
【０１３８】
また、上記のサービス要求(取消要求)に対する応答をパッケージ・ラッパー４８から受信すると、ＢＰＥＬ４４の処理実行部２６は、対応する下位サービス３のサービスＩＤを認識し（図２１のステップ２８６も参照）、ＭＢラッパー５０が先に実行した下位サービス３の処理を取り消す処理の実行を要求するサービス要求(図２１では「取消要求」と表記)を、サービス呼出部３２によってＭＢラッパー５０へ送信させる。これにより、ＭＢラッパー５０は、実行が正常に終了している下位サービス２の処理を預為システム６８と協働して取り消す取消処理を行う（図２１のステップ２８８も参照）。
【０１３９】
上記のサービス要求(取消要求)に対する応答をＭＢラッパー５０から受信すると、ＢＰＥＬ４４の処理実行部２６はサービス受付部２８へ処理結果を通知し、サービス受付部２８はリクエスタ４２へ応答を送信して処理結果を通知する。これにより、リクエスタ４２では実行が指示されたサービスの処理結果(実行が指示されたサービスは途中で業務エラーが発生したことで取り消された旨を表す「取消済」)を出力する処理が行われる（図１９のステップ２７６も参照）。
【０１４０】
また、図２２に示すシーケンスは、ＢＰＥＬ４４がＭＢラッパー５０へサービス要求を送信した直後に障害が発生し、送信したサービス要求がＭＢラッパー５０で受信されなかったことで、ＭＢラッパー５０から応答が送信されず、これに伴いリクエスタ４２からＢＰＥＬ４４へサービス要求が再送信された場合のシーケンスである。ここで、ＢＰＥＬ４４の処理実行部２６等が先に説明した図１８のように構成されているとすると、リクエスタ４２からのサービス要求の受信に伴い、ＢＰＥＬ４４の処理実行部２６では、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在しているか否かを確認する処理が行われ(図２２のステップ２９０も参照）、該当するプロセスが存在していることで、今回のサービス要求が過去に受信したサービス要求の再送であることが認識される。
【０１４１】
次に、該当するプロセスのＢＯに記憶されている状態情報が自プロセスのＢＯにコピーされる（図２２のステップ２９２も参照）。そして、再送されたサービス要求によって要求されたサービスを実行する処理が処理実行部２６によって行われるが、本実施形態では、プロバイダ４６によって提供されるサービスと、ＭＢラッパー５０(及び預為システム６８)によって提供されるサービスは冪等性を有している一方、パッケージ・ラッパー４８(及びパッケージ・システム６６)によって提供されるサービスは冪等性を有していないので、ＢＰＥＬ４４からは、プロバイダ４６及びＭＢラッパー５０に対してのみサービス要求が送信され、パッケージ・ラッパー４８については、対応する下位サービスの処理結果が「処理済」となっていることに基づき、サービス要求の送信がスキップされる。これにより仮想冪等機能が実現される。
【０１４２】
図２３には、リクエスタ４２に対して処理結果の確認が指示された場合のシーケンスの一例を示す。このシーケンスでは、処理結果の確認が指示されると、リクエスタ４２の管理部２４によって確認対象のサービスの処理結果が確認され、処理結果が「不明」であれば確認対象のサービスのサービスＩＤが認識（図２３のステップ２９６も参照）された後に、リクエスタ４２の結果確認呼出部３６によってＢＰＥＬ４４へ処理結果確認要求が送信される。リクエスタ４２から処理結果確認要求を受信したＢＰＥＬ４４では、処理結果確認部３４からの要求に従い、管理部２４によって対応する自サービスの処理結果が確認される（図２３のステップ２９８も参照）と共に、対応する下位サービスの処理結果も確認される（図２３のステップ２９８も参照）。
【０１４３】
ここで、対応する下位サービスの中に処理結果が「不明」の下位サービスが存在していた場合（ここでは、ＭＢラッパー５０が提供する下位サービスの処理結果が「不明」であったものとする）、処理結果が「不明」の下位サービスに対応する結果確認呼出部３６が管理部２４によって呼び出され、結果確認呼出部３６は対応する下位のサービス処理部（この例ではＭＢラッパー５０）へ処理結果確認要求を送信する。また、ＢＰＥＬ４４が下位のサービス処理部から処理結果通知を受信すると、ＢＰＥＬ４４の処理結果確認部３４によってリクエスタ４２へ処理結果通知が送信される。これにより、リクエスタ４２では処理結果の確認が指示されたサービスの処理結果を出力する処理が行われる（図２３のステップ２７６も参照）。このように、処理結果の確認が指示された場合も、リクエスタ４２からＢＰＥＬ４４へ処理結果確認要求が送信され、必要に応じてより下位のサービス処理部へ処理結果確認要求が連鎖していくことで、指示されたサービスの処理結果が確認される。
【０１４４】
なお、上記では本発明に係るサービス処理システムとして、５個のサービス処理部が３層(３段)に分けられ、３層目(３段目)の３個のサービス処理部が２層目(２段目)の単一のサービス処理部に各々連結され、２層目(２段目)の単一のサービス処理部が１層目(１段目)の単一のサービス処理部に連結された構成のサービス処理システム１０を例に説明したが、サービス処理部の総数や段数、各段（各層）におけるサービス処理部の数は上記に限られるものではなく、例えばサービス処理部がより多数段連結された構成のサービス処理システムにも本発明を適用可能であることは言うまでもない。
【０１４５】
また、上記では２段目(２層目)のサービス処理部を実現するためのサービス処理プログラムが、ＢＰＥＬのプラットフォーム上で動作する態様を説明したが、これに限定されるものではなく、本発明に係るサービス処理システムはＢＰＥＬを利用せずに構築することも可能である。
【０１４６】
また、上記では個々のサービス処理部が互いに異なるコンピュータ（サービス処理サーバ１２）によって実現される態様を説明したが、これに限定されるものではなく、本発明は単一のコンピュータを互いに異なる複数種のサービス処理部として各々機能させる態様にも適用可能である。
【０１４７】
また、上記では本発明に係るプログラムに対応するサービス処理プログラムがサービス処理サーバ１２の記憶部１２Ｃに予め記憶（インストール）されている態様を説明したが、本発明に係るプログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。この態様における記録媒体は本発明に係る記録媒体に対応している。
【符号の説明】
【０１４８】
１０ サービス処理システム
１２ サービス処理サーバ
１２Ｃ 記憶部
１４ アプリケーション・サーバ
２４ 管理部
２６ 処理実行部
２８ サービス受付部
３０ サービスＩＤ生成部
３２ サービス呼出部
３４ 処理結果確認部
３６ 結果確認呼出部
３８ 処理状況テーブル
４２ リクエスタ
４６ プロバイダ
４８ パッケージ・ラッパー
５０ ＭＢラッパー
６６ 既存システム
６８ 既存システム
【特許請求の範囲】
【請求項１】
コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、
サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、
サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、
及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能
を備えたサービス処理装置。
【請求項２】
コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、
サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、
サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、
を備え、
前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、
前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させる
サービス処理装置。
【請求項３】
前記サービス実行手段は、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在しており、かつ前記サービス受付手段が前記上位のサービス処理装置からサービス要求を受信することで実行が要求されたサービスが、対応する下位サービスが存在しているサービスである場合、前記サービスＩＤ生成手段によって生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信すると共に、前記サービス呼出手段が前記下位のサービス処理装置から応答を受信した後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信する請求項２記載のサービス処理装置。
【請求項４】
前記サービス実行手段は、前記実行が要求されたサービスが自サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記自サービスの処理を行い、前記自サービスの処理結果を前記通知されたサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行う請求項２又は請求項３記載のサービス処理装置。
【請求項５】
前記サービス実行手段は、自装置よりも下位のサービス処理装置が複数存在する場合、前記サービス呼出手段を前記下位のサービス処理装置と同数個備えており、自装置よりも下位のサービス処理装置が複数存在し、かつ実行が要求されたサービスが前記複数の下位のサービス処理装置による複数の下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記複数の下位のサービス処理装置のうちの特定の下位のサービス装置による特定の下位サービスのサービスＩＤを前記サービスＩＤ生成手段によって生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を、前記特定の下位のサービス装置に対応する特定のサービス呼出手段によって前記特定の下位のサービス処理装置へ送信し、前記特定のサービス呼出手段が前記特定の下位のサービス処理装置から受信した応答によって通知された前記特定の下位サービスの処理結果を、前記特定の下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を、前記複数の下位のサービス処理装置について各々行う請求項２〜請求項４の何れか１項記載のサービス処理装置。
【請求項６】
前記サービス実行手段は、前記複数の下位のサービス処理装置のうちの何れかからの応答によって通知された前記下位サービスの処理結果がエラーであった場合、前記複数の下位のサービス処理装置の中に要求された下位サービスが「処理済」の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応する前記サービス呼出手段により、「処理済」の下位サービスの取消を要求するサービス要求を、前記下位サービスが「処理済」の下位のサービス処理装置へ送信させる請求項５記載のサービス処理装置。
【請求項７】
前記サービス実行手段は、前記複数の下位のサービス処理装置のうちの何れかからの応答によって通知された前記下位サービスの処理結果がエラーであった場合、前記複数の下位のサービス処理装置の中にサービス要求を未送信の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応する前記サービス呼出手段による前記サービス要求の送信を中止する請求項５記載のサービス処理装置。
【請求項８】
自装置よりも下位のサービス処理装置が存在し、コンピュータをサービス処理装置として機能させるためのプログラムがＢＰＥＬのプラットフォーム上で動作する場合、
前記サービス実行手段は、サービスＩＤが通知されてサービスの実行が要求される毎に生成され、通知されたサービスＩＤを保持すると共に、処理の進行状態を表す状態情報を記憶しかつ処理の進行状態の変化に応じて前記状態情報を適宜更新するインスタンスよって実現され、前記インスタンスが新たに生成される毎に、当該新たに生成されたインスタンスにおいて、過去に生成され同一のサービスＩＤを保持しているインスタンスを検索し、該当するインスタンスが存在していた場合は前記該当するインスタンスの状態情報を自インスタンスの状態情報として複写し、複写した状態情報に従って処理を行う請求項２〜請求項７の何れか１項記載のサービス処理装置。
【請求項９】
前記処理結果管理手段は、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在し、かつ前記処理結果確認手段が前記上位のサービス処理装置から処理結果確認要求を受信することで処理結果の確認が要求されたサービスに対応する下位サービスが存在しており、かつ前記記憶手段に記憶されている前記対応する下位サービスの処理結果が「不明」の場合に、前記下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ処理結果が通知された後に、前記処理結果の確認が要求されたサービスの処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知する請求項２記載のサービス処理装置。
【請求項１０】
前記サービスＩＤ生成手段は、
サービス処理装置毎に相違するＩＤを設定した固有ＩＤと、サービス要求毎に相違するＩＤを設定した要求ＩＤを含むＩＤ要素を生成するＩＤ要素生成手段と、
自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を各々設定した呼出元ＩＤ及び呼出先ＩＤを含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤに呼出先ＩＤとして設定されているＩＤ要素を設定した呼出元ＩＤと、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定した呼出先ＩＤを含むサービスＩＤを生成するＩＤ要素組合せ手段と、
を含んで構成されている請求項２〜請求項９の何れか１項記載のサービス処理装置。
【請求項１１】
前記ＩＤ要素組合せ手段は、自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤにオリジナルＩＤとして設定されているＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成する請求項１０記載のサービス処理装置。
【請求項１２】
前記ＩＤ要素生成手段は、前記コンピュータを前記サービス処理装置として機能させるためのプログラムの実行単位に付与された実行単位ＩＤも含むＩＤ要素を生成する請求項１０又は請求項１１記載のサービス処理装置。
【請求項１３】
請求項１〜請求項１２の何れか１項記載のサービス処理装置が情報を送受可能に複数設けられたサービス処理システム。
【請求項１４】
コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、
前記コンピュータを、
サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、
サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、
を備え、
前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、
前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させる
サービス処理装置として機能させるためのサービス処理プログラム。
【請求項１５】
コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、
前記コンピュータを、請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能させるためのサービス処理プログラム。
【請求項１６】
コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムが記録された記録媒体であって、
前記サービス処理プログラムは、前記コンピュータを、
サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、
サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、
及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能
を備えたサービス処理装置として機能させる記録媒体。
【請求項１７】
請求項１４又は請求項１５記載のサービス処理プログラムが記録された記録媒体。
【請求項１】
コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、
サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、
サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、
及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能
を備えたサービス処理装置。
【請求項２】
コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、
サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、
サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、
を備え、
前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、
前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させる
サービス処理装置。
【請求項３】
前記サービス実行手段は、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在しており、かつ前記サービス受付手段が前記上位のサービス処理装置からサービス要求を受信することで実行が要求されたサービスが、対応する下位サービスが存在しているサービスである場合、前記サービスＩＤ生成手段によって生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信すると共に、前記サービス呼出手段が前記下位のサービス処理装置から応答を受信した後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信する請求項２記載のサービス処理装置。
【請求項４】
前記サービス実行手段は、前記実行が要求されたサービスが自サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記自サービスの処理を行い、前記自サービスの処理結果を前記通知されたサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行う請求項２又は請求項３記載のサービス処理装置。
【請求項５】
前記サービス実行手段は、自装置よりも下位のサービス処理装置が複数存在する場合、前記サービス呼出手段を前記下位のサービス処理装置と同数個備えており、自装置よりも下位のサービス処理装置が複数存在し、かつ実行が要求されたサービスが前記複数の下位のサービス処理装置による複数の下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記複数の下位のサービス処理装置のうちの特定の下位のサービス装置による特定の下位サービスのサービスＩＤを前記サービスＩＤ生成手段によって生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を、前記特定の下位のサービス装置に対応する特定のサービス呼出手段によって前記特定の下位のサービス処理装置へ送信し、前記特定のサービス呼出手段が前記特定の下位のサービス処理装置から受信した応答によって通知された前記特定の下位サービスの処理結果を、前記特定の下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を、前記複数の下位のサービス処理装置について各々行う請求項２〜請求項４の何れか１項記載のサービス処理装置。
【請求項６】
前記サービス実行手段は、前記複数の下位のサービス処理装置のうちの何れかからの応答によって通知された前記下位サービスの処理結果がエラーであった場合、前記複数の下位のサービス処理装置の中に要求された下位サービスが「処理済」の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応する前記サービス呼出手段により、「処理済」の下位サービスの取消を要求するサービス要求を、前記下位サービスが「処理済」の下位のサービス処理装置へ送信させる請求項５記載のサービス処理装置。
【請求項７】
前記サービス実行手段は、前記複数の下位のサービス処理装置のうちの何れかからの応答によって通知された前記下位サービスの処理結果がエラーであった場合、前記複数の下位のサービス処理装置の中にサービス要求を未送信の下位のサービス処理装置が存在していれば、当該下位のサービス処理装置に対応する前記サービス呼出手段による前記サービス要求の送信を中止する請求項５記載のサービス処理装置。
【請求項８】
自装置よりも下位のサービス処理装置が存在し、コンピュータをサービス処理装置として機能させるためのプログラムがＢＰＥＬのプラットフォーム上で動作する場合、
前記サービス実行手段は、サービスＩＤが通知されてサービスの実行が要求される毎に生成され、通知されたサービスＩＤを保持すると共に、処理の進行状態を表す状態情報を記憶しかつ処理の進行状態の変化に応じて前記状態情報を適宜更新するインスタンスよって実現され、前記インスタンスが新たに生成される毎に、当該新たに生成されたインスタンスにおいて、過去に生成され同一のサービスＩＤを保持しているインスタンスを検索し、該当するインスタンスが存在していた場合は前記該当するインスタンスの状態情報を自インスタンスの状態情報として複写し、複写した状態情報に従って処理を行う請求項２〜請求項７の何れか１項記載のサービス処理装置。
【請求項９】
前記処理結果管理手段は、自装置よりも上位のサービス処理装置及び下位のサービス処理装置が各々存在し、かつ前記処理結果確認手段が前記上位のサービス処理装置から処理結果確認要求を受信することで処理結果の確認が要求されたサービスに対応する下位サービスが存在しており、かつ前記記憶手段に記憶されている前記対応する下位サービスの処理結果が「不明」の場合に、前記下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ処理結果が通知された後に、前記処理結果の確認が要求されたサービスの処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知する請求項２記載のサービス処理装置。
【請求項１０】
前記サービスＩＤ生成手段は、
サービス処理装置毎に相違するＩＤを設定した固有ＩＤと、サービス要求毎に相違するＩＤを設定した要求ＩＤを含むＩＤ要素を生成するＩＤ要素生成手段と、
自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を各々設定した呼出元ＩＤ及び呼出先ＩＤを含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤに呼出先ＩＤとして設定されているＩＤ要素を設定した呼出元ＩＤと、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定した呼出先ＩＤを含むサービスＩＤを生成するＩＤ要素組合せ手段と、
を含んで構成されている請求項２〜請求項９の何れか１項記載のサービス処理装置。
【請求項１１】
前記ＩＤ要素組合せ手段は、自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信したサービス要求に付加されたサービスＩＤにオリジナルＩＤとして設定されているＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成する請求項１０記載のサービス処理装置。
【請求項１２】
前記ＩＤ要素生成手段は、前記コンピュータを前記サービス処理装置として機能させるためのプログラムの実行単位に付与された実行単位ＩＤも含むＩＤ要素を生成する請求項１０又は請求項１１記載のサービス処理装置。
【請求項１３】
請求項１〜請求項１２の何れか１項記載のサービス処理装置が情報を送受可能に複数設けられたサービス処理システム。
【請求項１４】
コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、
前記コンピュータを、
サービスＩＤが通知されてサービスの実行が要求されると、実行が要求されたサービスに関する処理を行うサービス実行手段と、
サービスの処理結果をサービスＩＤと対応付けて記憶するための記憶手段を備えた処理結果管理手段と、
を備え、
前記サービス実行手段は、自装置よりも上位のサービス処理装置が存在する場合はサービス受付手段を備え、サービスＩＤが付加されたサービス要求を前記サービス受付手段が前記上位のサービス処理装置から受信することでサービスの実行が要求されると、前記実行が要求されたサービスに関する処理を行い、当該処理の処理結果を前記サービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させた後に、前記サービス受付手段によって前記上位のサービス処理装置へ応答を送信し、自装置よりも下位のサービス処理装置が存在する場合は、一意性を有するサービスＩＤを生成するサービスＩＤ生成手段と、サービス呼出手段と、を備え、実行が要求されたサービスが前記下位のサービス処理装置による下位サービスを含むサービスである場合に、前記実行が要求されたサービスに関する処理として、前記サービスＩＤ生成手段によって前記下位サービスのサービスＩＤを生成させ、生成された前記下位サービスのサービスＩＤを付加したサービス要求を前記サービス呼出手段によって前記下位のサービス処理装置へ送信し、前記サービス呼出手段が前記下位のサービス処理装置から受信した応答によって通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記処理結果管理手段の前記記憶手段に記憶させる処理を行うと共に、冪等性を有する下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記冪等性を有する下位サービスが存在している場合、前記冪等性を有する下位サービスの処理結果を前記処理結果管理手段に確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信し、冪等性を有しない非冪等の下位サービスを行うサービス処理装置が自装置よりも下位に存在し、かつ実行が要求されたサービスに対応する下位サービスの中に前記非冪等の下位サービスが存在している場合は、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記処理結果管理手段により前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信させることで処理結果の確認を再度試行させ、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へ前記サービス呼出手段によってサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を前記処理結果管理手段に再度確認する処理を行い、当該処理が終了すると前記サービス受付手段によってサービス要求の送信元の前記上位のサービス処理装置へ確認した処理結果に応じた応答を送信し、
前記処理結果管理手段は、自装置よりも上位のサービス処理装置が存在する場合は処理結果確認手段を備え、サービスＩＤが付加された処理結果確認要求を前記処理結果確認手段が前記上位のサービス処理装置から受信することでサービスの処理結果の確認が要求されると、処理結果の確認が要求されたサービスの処理結果を前記サービスＩＤに基づいて確認し、処理結果の確認が終了すると確認した処理結果を前記処理結果確認手段によって前記上位のサービス処理装置へ通知し、自装置よりも下位のサービス処理装置が存在する場合は結果確認呼出手段を備え、前記下位のサービス処理装置による下位サービスの処理結果の確認が必要な場合に、確認対象の下位サービスのサービスＩＤを付加した処理結果確認要求を前記結果確認呼出手段によって前記下位のサービス処理装置へ送信し、前記下位のサービス処理装置から前記結果確認呼出手段へ通知された前記下位サービスの処理結果を、前記下位サービスのサービスＩＤと対応付けて前記記憶手段に記憶させる
サービス処理装置として機能させるためのサービス処理プログラム。
【請求項１５】
コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、
前記コンピュータを、請求項２〜請求項１２の何れか１項記載のサービス処理装置として機能させるためのサービス処理プログラム。
【請求項１６】
コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムが記録された記録媒体であって、
前記サービス処理プログラムは、前記コンピュータを、
サービスＩＤが付加されたサービス要求を受信することでサービスの実行が要求されると、実行が要求されたサービスに関する処理として、実行が要求されたサービスに対応する自サービスが存在する場合は、当該自サービスの処理を行い、自サービスの処理結果を前記サービスＩＤと対応付けて記憶手段に記憶させると共に、実行が要求されたサービスに対応する下位サービスが存在する場合は、前記下位サービスのサービスＩＤを生成し生成したサービスＩＤを付加したサービス要求を下位のサービス処理装置へ送信し、かつ前記下位サービスの処理結果を前記生成したサービスＩＤと対応付けて前記記憶手段に記憶させる処理を行い、サービス要求の送信元へ応答を送信する第１機能、
サービスＩＤが付加された処理結果確認要求を受信することでサービスの処理結果の確認が要求されると、前記記憶手段に記憶されている情報に基づいて、処理結果の確認が要求されたサービスに対応するサービスの処理結果を確認し、対応する下位サービスの処理結果の確認が必要な場合は、対応する下位サービスのサービスＩＤを付加した処理結果確認要求を下位のサービス処理装置に送信し、処理結果の確認が終了すると確認した処理結果を処理結果確認要求の送信元へ送信する第２機能、
及び、以前に受信したサービス要求と同一のサービスＩＤが付加されたサービス要求を受信することで、以前に実行が要求されたサービスの再実行が要求されると、再実行が要求されたサービスに対応する１つ以上のサービスのうち、冪等性を有する下位サービスについては、前記冪等性を有する下位サービスの処理結果を確認することなく、前記冪等性を有する下位サービスを行うサービス処理装置へサービス要求を送信し、冪等性を有しない非冪等の下位サービスについては、前記非冪等の下位サービスの処理結果を確認し、確認した処理結果がサービス要求に対する応答が未受信であることを表す「不明」の場合は、前記非冪等の下位サービスを行うサービス処理装置へ前記処理結果確認要求を送信することで処理結果の確認を再度試行し、処理結果として「処理未済」が得られたときにのみ、前記非冪等の下位サービスを行うサービス処理装置へサービス要求を送信した後に、前記非冪等の下位サービスの処理結果を再度確認する処理を行い、当該処理が終了するとサービス要求の送信元へ確認した処理結果に応じた応答を送信する第３機能
を備えたサービス処理装置として機能させる記録媒体。
【請求項１７】
請求項１４又は請求項１５記載のサービス処理プログラムが記録された記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１０−７３２１１（Ｐ２０１０−７３２１１Ａ）
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【出願番号】特願２００９−２１７６５３（Ｐ２００９−２１７６５３）
【出願日】平成２１年９月１８日（２００９．９．１８）
【分割の表示】特願２００８−２３９７７４（Ｐ２００８−２３９７７４）の分割
【原出願日】平成２０年９月１８日（２００８．９．１８）
【出願人】（５９８０４９３２２）株式会社三菱東京ＵＦＪ銀行 (200)
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成２２年４月２日（２０１０．４．２）
【国際特許分類】
【出願日】平成２１年９月１８日（２００９．９．１８）
【分割の表示】特願２００８−２３９７７４（Ｐ２００８−２３９７７４）の分割
【原出願日】平成２０年９月１８日（２００８．９．１８）
【出願人】（５９８０４９３２２）株式会社三菱東京ＵＦＪ銀行 (200)
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]