JP2010072951A - サービス処理装置、システム、プログラム及び記録媒体 - Google Patents

サービス処理装置、システム、プログラム及び記録媒体 Download PDF

Info

Publication number
JP2010072951A
JP2010072951A JP2008239773A JP2008239773A JP2010072951A JP 2010072951 A JP2010072951 A JP 2010072951A JP 2008239773 A JP2008239773 A JP 2008239773A JP 2008239773 A JP2008239773 A JP 2008239773A JP 2010072951 A JP2010072951 A JP 2010072951A
Authority
JP
Japan
Prior art keywords
service
processing
unit
request
level
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008239773A
Other languages
English (en)
Other versions
JP4336735B1 (ja
Inventor
Naoki Miura
直樹 三浦
Masumi Yamashita
眞澄 山下
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MUFG Bank Ltd
International Business Machines Corp
Original Assignee
International Business Machines Corp
Bank of Tokyo Mitsubishi UFJ Trust Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp, Bank of Tokyo Mitsubishi UFJ Trust Co filed Critical International Business Machines Corp
Priority to JP2008239773A priority Critical patent/JP4336735B1/ja
Priority to US12/560,849 priority patent/US8103758B2/en
Application granted granted Critical
Publication of JP4336735B1 publication Critical patent/JP4336735B1/ja
Publication of JP2010072951A publication Critical patent/JP2010072951A/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/006—Identification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0775—Content or structure details of the error report, e.g. specific table structure, specific error fields
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】障害発生時に、要求されたサービスの処理履歴を把握可能とすることを、性能低下を抑制しつつ実現する。
【解決手段】上位のサービス処理部から下位のサービス処理部へサービス要求を連鎖させていくにあたり、サービス要求に付加するサービスＩＤを、リクエスタ固有ＩＤ、プロセス毎ＩＤ及びリクエスト毎ＩＤから成るＩＤ要素を各々設定したオリジナルサービスＩＤ、呼出元サービスＩＤ及び呼出先サービスＩＤで構成すると共に、上位のサービス処理部からサービス要求を受信したサービス処理部は、受信したサービスＩＤに対してオリジナルサービスＩＤが同一、呼出元サービスＩＤが受信したサービスＩＤの呼出先サービスＩＤと同一、呼出先サービスＩＤに新たなＩＤ要素を設定したサービスＩＤを生成し、生成したサービスＩＤを付加したサービス要求を下位のサービス処理部へ送信する。
【選択図】図１６

Description

本発明はサービス処理装置、システム、プログラム及び記録媒体に係り、特に、要求されたサービスを実行するサービス処理装置、該サービス処理装置を複数備えたサービス処理システム、コンピュータを前記サービス処理装置として機能させるためのサービス処理プログラム、及び、当該サービス処理プログラムが記録された記録媒体に関する。
多数のサービス要求が入力され、入力された個々のサービス要求に応じた処理を行うコンピュータ・システムでは、障害発生時に、個々のサービス要求が正常に処理されたか否かを確認したり、正常に処理されていないサービス要求に対応する処理を再実行する等の処理を行うために、個々のサービス要求に識別情報を付加して個々のサービス要求を識別する必要がある。これに関連して特許文献１には、クライアント側の通信機構であるＰＡＬＩＢ（識別子付加手段）が、サーバへ送信する全てのＲＰＣ（遠隔手続き呼出し）メッセージに、ＲＰＣ要求の一意性を確保する識別子（ＩＤ）として３種類の識別子を組み合わせたＩＤを付加することで、当該ＩＤをメッセージと同送する技術が開示されている。
また近年、大規模なシステムを「サービス」の集まりとして構築する設計手法であるＳＯＡ(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)という）に、呼出時の引数を設定すると共に、生成したプロセスにおける処理の進行状態を表す状態情報も設定し、対応するプロセスにおける処理の進行状態の変化に応じて状態情報を適宜更新する、という機能を提供している。
このため、上記機能を利用し、例として図１８に示すように、サービス処理部のプログラムのうち、少なくとも処理実行部２６として機能するプログラム（当該プログラムにはサービス受付部２８として機能するプログラムやサービス呼出部３２として機能するプログラムも含まれていてもよい）を、サービスＩＤ及び冪等フラグを引数として呼び出され、起動されると、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在しているか否かを確認する(図１８の「処理結果確認」も参照)ように構成すれば、今回の呼び出しに対応するサービス要求が、過去に受けたサービス要求の再送であるか否かを簡単に確認することができる。また、上記プログラムを、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在している場合に、該当する他プロセス（該当する他プロセスが複数存在している場合は、そのうちの最新の(最後に生成された)他プロセス）のＢＯから状態情報をコピーする(図１８の「ＢＯコピー」も参照)ように構成することで、今回の呼び出しに対応するサービス要求を前回受けた際の処理の状態を継承し、前回の処理の続きから開始することを簡易な処理で実現することができる。また、上記プログラムを、実行が要求されたサービスに対応する非冪等の下位サービスが存在する場合に、当該下位サービスの処理結果を確認し、「処理済」であれば下位サービスの実行要求をスキップする(図１８の「実行済？」も参照)ように構成することで、仮想冪等機能を簡易な処理によって実現することができる。このように、ＢＰＥＬのプラットフォームの特徴を利用することで、サービス処理プログラムの開発負荷を更に削減することが可能となる。
また、本実施形態に係るサービス処理システム１０では、個々のサービス処理部がサービス要求や処理結果確認要求の受信時に、図３や図４に示す処理シーケンスで処理を行うことで、最上位のサービス処理部が送信したサービス要求や処理結果確認要求が複数段のサービス処理部に亘って連鎖することになる。以下、最上位のサービス処理部からサービス要求や処理結果確認要求が送信された場合の、サービス処理システム１０全体としての処理シーケンスを説明する。なお以下では、対象サービスが、プロバイダ４６、パッケージ・ラッパー４８及びＭＢラッパー５０の各々による下位サービスの実行を必要とするサービスであるものとする。
最上位のサービス処理部（リクエスタ４２）に対してサービスの実行が指示された場合のシーケンスの一例を図１９に示す。このシーケンスでは、リクエスタ４２に対してサービスの実行が指示されると、リクエスタ４２のサービスＩＤ生成部３０によって下位サービスのサービスＩＤ（ＢＰＥＬ４４へ送信するサービスＩＤ）が生成され（図１９のステップ２６０も参照）、リクエスタ４２のサービス呼出部３２によってＢＰＥＬ４４へサービス要求が送信される。
サービス要求を受信したＢＰＥＬ４４の処理実行部２６は、実行が要求されたサービスに対応する自サービスが存在している場合には自サービスの処理を行い（図１９のステップ２６２も参照）、サービスＩＤ生成部３０によって下位サービス１のサービスＩＤ（プロバイダ４６へ送信するサービスＩＤ）を生成させ（図１９のステップ２６４も参照）、プロバイダ４６に対応するサービス呼出部３２を呼び出し、プロバイダ４６に対応するサービス呼出部３２によってプロバイダ４６へサービス要求を送信させる。サービス要求を受信したプロバイダ４６では、要求された下位サービス１の処理が処理実行部２６によって行われ（図１９のステップ２６６も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
ＢＰＥＬ４４の処理実行部２６は、プロバイダ４６からの応答が受信され、処理結果が「処理済」であった場合、サービスＩＤ生成部３０によって下位サービス２のサービスＩＤ（パッケージ・ラッパー４８へ送信するサービスＩＤ）を生成させ（図１９のステップ２６８も参照）、パッケージ・ラッパー４８に対応するサービス呼出部３２を呼び出し、パッケージ・ラッパー４８に対応するサービス呼出部３２によってパッケージ・ラッパー４８へサービス要求を送信させる。サービス要求を受信したパッケージ・ラッパー４８では、要求された下位サービス２の処理がパッケージ・システム６６と協働することで行われ（図１９のステップ２７０も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
ＢＰＥＬ４４の処理実行部２６は、パッケージ・ラッパー４８からの応答が受信され、処理結果が「処理済」であった場合、サービスＩＤ生成部３０によって下位サービス３のサービスＩＤ（ＭＢラッパー５０へ送信するサービスＩＤ）を生成させ（図１９のステップ２７２も参照）、ＭＢラッパー５０に対応するサービス呼出部３２を呼び出し、ＭＢラッパー５０に対応するサービス呼出部３２によってＭＢラッパー５０へサービス要求を送信させる。サービス要求を受信したＭＢラッパー５０では、要求された下位サービス３の処理が預為システム６８と協働することで行われ（図１９のステップ２７４も参照）、処理終了後にサービス受付部２８によってＢＰＥＬ４４へ応答が送信される。
ＢＰＥＬ４４では、パッケージ・ラッパー４８からの応答が受信され、処理結果が「処理済」であった場合、処理実行部２６からサービス受付部２８へ処理結果が通知され、サービス受付部２８はリクエスタ４２へ応答を送信して処理結果を通知する。これにより、リクエスタ４２では実行が指示されたサービスの処理結果(「処理済」)を出力する処理が行われる（図１９のステップ２７６も参照）。このように、最上位のリクエスタ４２からＢＰＥＬ４４を経由してプロバイダ４６やパッケージ・ラッパー４８、ＭＢラッパー５０へサービス要求が連鎖していくことで、指示されたサービスが実行される。
次に、サービス処理システム１０に障害が発生した場合のシーケンスを説明する。図２０に示すシーケンスは、ＢＰＥＬ４４がパッケージ・ラッパー４８へサービス要求を送信した直後に障害が発生し、送信したサービス要求がパッケージ・ラッパー４８で受信されなかったことで、パッケージ・ラッパー４８から応答が送信されず、タイマがタイムアウトした場合のシーケンスである。図２０に示すシーケンスでは、ＢＰＥＬ４４からパッケージ・ラッパー４８へのサービス要求の再送信の図示を省略しているが、パッケージ・ラッパー４８へサービス要求を所定回再送信してもパッケージ・ラッパー４８からの応答が受信されなかった場合、ＢＰＥＬ４４の処理実行部２６の業務プログラムから処理実行部ＡＰＩへ制御が戻る。
ここで、処理実行部ＡＰＩは、実行が要求されたサービスの処理結果が「不明(タイムアウト／リトライ回数超過)」であることをサービス受付部２８経由でリクエスタ４２へ通知するようにしてもよいが、図２０に示すシーケンスではパッケージ・ラッパー４８による下位サービス２の処理結果を管理部２４に問い合わせ、この場合、下位サービス２の処理結果が「不明」であることから、パッケージ・ラッパー４８に対応する結果確認呼出部３６によってＢＰＥＬ４４からパッケージ・ラッパー４８へ処理結果確認要求が送信される。 この間にサービス処理システム１０の障害が解消していた場合、この処理結果確認要求がパッケージ・ラッパー４８で受信され、パッケージ・ラッパー４８の処理結果確認部３４によって通知されたサービスＩＤに対応する下位サービス２の処理結果が確認される。この場合は処理結果が「処理未済」であるので、処理結果が「処理未済」であることを通知する処理結果通知がパッケージ・ラッパー４８からＢＰＥＬ４４へ送信される。
パッケージ・ラッパー４８からの処理結果通知を受信し、処理結果が「処理未済」であることを確認すると、ＢＰＥＬ４４の処理実行部２６はパッケージ・ラッパー４８に対応するサービス呼出部３２を呼び出し、サービス呼出部３２によってＢＰＥＬ４４からパッケージ・ラッパー４８へサービス要求が再度送信される。これにより、パッケージ・ラッパー４８では、要求された下位サービス２の処理がパッケージ・システム６６と協働することで行われる（図２０のステップ２７０も参照）。以降のシーケンスは図１９と同一であるので説明を省略する。
また、図２１に示すシーケンスは、ＭＢラッパー５０がＢＰＥＬ４４から受信したサービス要求で要求された下位サービス３の処理を預為システム６８と協働して行った結果、業務エラーが発生した場合（図２１のステップ２７５も参照）のシーケンスである。この場合、処理結果が「業務エラー」であることを通知する応答がＭＢラッパー５０からＢＰＥＬ４４へ送信される。この応答がＢＰＥＬ４４で受信されると、ＢＰＥＬ４４の処理実行部２６は、プロバイダ４６による下位サービス１及びパッケージ・ラッパー４８による下位サービス２が「処理済」で、ＭＢラッパー５０による下位サービス３が「業務エラー」となったことによるデータの不整合を解消するため、まず対応する下位サービス２のサービスＩＤを認識し（図２１のステップ２８２も参照）、パッケージ・ラッパー４８が先に実行した下位サービス２の処理を取り消す処理の実行を要求するサービス要求(図２１では「取消要求」と表記)を、サービス呼出部３２によってパッケージ・ラッパー４８へ送信させる。これにより、パッケージ・ラッパー４８は、実行が正常に終了している下位サービス２の処理をパッケージ・システム６６と協働して取り消す取消処理を行う（図２１のステップ２８４も参照）。
また、上記のサービス要求(取消要求)に対する応答をパッケージ・ラッパー４８から受信すると、ＢＰＥＬ４４の処理実行部２６は、対応する下位サービス３のサービスＩＤを認識し（図２１のステップ２８６も参照）、ＭＢラッパー５０が先に実行した下位サービス３の処理を取り消す処理の実行を要求するサービス要求(図２１では「取消要求」と表記)を、サービス呼出部３２によってＭＢラッパー５０へ送信させる。これにより、ＭＢラッパー５０は、実行が正常に終了している下位サービス２の処理を預為システム６８と協働して取り消す取消処理を行う（図２１のステップ２８８も参照）。
上記のサービス要求(取消要求)に対する応答をＭＢラッパー５０から受信すると、ＢＰＥＬ４４の処理実行部２６はサービス受付部２８へ処理結果を通知し、サービス受付部２８はリクエスタ４２へ応答を送信して処理結果を通知する。これにより、リクエスタ４２では実行が指示されたサービスの処理結果(実行が指示されたサービスは途中で業務エラーが発生したことで取り消された旨を表す「取消済」)を出力する処理が行われる（図１９のステップ２７６も参照）。
また、図２２に示すシーケンスは、ＢＰＥＬ４４がＭＢラッパー５０へサービス要求を送信した直後に障害が発生し、送信したサービス要求がＭＢラッパー５０で受信されなかったことで、ＭＢラッパー５０から応答が送信されず、これに伴いリクエスタ４２からＢＰＥＬ４４へサービス要求が再送信された場合のシーケンスである。ここで、ＢＰＥＬ４４の処理実行部２６等が先に説明した図１８のように構成されているとすると、リクエスタ４２からのサービス要求の受信に伴い、ＢＰＥＬ４４の処理実行部２６では、自プロセスと同一のサービスＩＤを引数として生成された他プロセスが存在しているか否かを確認する処理が行われ(図２２のステップ２９０も参照）、該当するプロセスが存在していることで、今回のサービス要求が過去に受信したサービス要求の再送であることが認識される。
次に、該当するプロセスのＢＯに記憶されている状態情報が自プロセスのＢＯにコピーされる（図２２のステップ２９２も参照）。そして、再送されたサービス要求によって要求されたサービスを実行する処理が処理実行部２６によって行われるが、本実施形態では、プロバイダ４６によって提供されるサービスと、ＭＢラッパー５０(及び預為システム６８)によって提供されるサービスは冪等性を有している一方、パッケージ・ラッパー４８(及びパッケージ・システム６６)によって提供されるサービスは冪等性を有していないので、ＢＰＥＬ４４からは、プロバイダ４６及びＭＢラッパー５０に対してのみサービス要求が送信され、パッケージ・ラッパー４８については、対応する下位サービスの処理結果が「処理済」となっていることに基づき、サービス要求の送信がスキップされる。これにより仮想冪等機能が実現される。
図２３には、リクエスタ４２に対して処理結果の確認が指示された場合のシーケンスの一例を示す。このシーケンスでは、処理結果の確認が指示されると、リクエスタ４２の管理部２４によって確認対象のサービスの処理結果が確認され、処理結果が「不明」であれば確認対象のサービスのサービスＩＤが認識（図２３のステップ２９６も参照）された後に、リクエスタ４２の結果確認呼出部３６によってＢＰＥＬ４４へ処理結果確認要求が送信される。リクエスタ４２から処理結果確認要求を受信したＢＰＥＬ４４では、処理結果確認部３４からの要求に従い、管理部２４によって対応する自サービスの処理結果が確認される（図２３のステップ２９８も参照）と共に、対応する下位サービスの処理結果も確認される（図２３のステップ２９８も参照）。
ここで、対応する下位サービスの中に処理結果が「不明」の下位サービスが存在していた場合（ここでは、ＭＢラッパー５０が提供する下位サービスの処理結果が「不明」であったものとする）、処理結果が「不明」の下位サービスに対応する結果確認呼出部３６が管理部２４によって呼び出され、結果確認呼出部３６は対応する下位のサービス処理部（この例ではＭＢラッパー５０）へ処理結果確認要求を送信する。また、ＢＰＥＬ４４が下位のサービス処理部から処理結果通知を受信すると、ＢＰＥＬ４４の処理結果確認部３４によってリクエスタ４２へ処理結果通知が送信される。これにより、リクエスタ４２では処理結果の確認が指示されたサービスの処理結果を出力する処理が行われる（図２３のステップ２７６も参照）。このように、処理結果の確認が指示された場合も、リクエスタ４２からＢＰＥＬ４４へ処理結果確認要求が送信され、必要に応じてより下位のサービス処理部へ処理結果確認要求が連鎖していくことで、指示されたサービスの処理結果が確認される。
なお、上記では本発明に係るサービス処理システムとして、５個のサービス処理部が３層(３段)に分けられ、３層目(３段目)の３個のサービス処理部が２層目(２段目)の単一のサービス処理部に各々連結され、２層目(２段目)の単一のサービス処理部が１層目(１段目)の単一のサービス処理部に連結された構成のサービス処理システム１０を例に説明したが、サービス処理部の総数や段数、各段（各層）におけるサービス処理部の数は上記に限られるものではなく、例えばサービス処理部がより多数段連結された構成のサービス処理システムにも本発明を適用可能であることは言うまでもない。
また、上記では２段目(２層目)のサービス処理部を実現するためのサービス処理プログラムが、ＢＰＥＬのプラットフォーム上で動作する態様を説明したが、これに限定されるものではなく、本発明に係るサービス処理システムはＢＰＥＬを利用せずに構築することも可能である。
また、上記では個々のサービス処理部が互いに異なるコンピュータ（サービス処理サーバ１２）によって実現される態様を説明したが、これに限定されるものではなく、本発明は単一のコンピュータを互いに異なる複数種のサービス処理部として各々機能させる態様にも適用可能である。
また、上記では本発明に係るプログラムに対応するサービス処理プログラムがサービス処理サーバ１２の記憶部１２Ｃに予め記憶（インストール）されている態様を説明したが、本発明に係るプログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。この態様における記録媒体は本発明に係る記録媒体に対応している。
本実施形態に係るサービス処理システムのハードウェア構成を示す概略ブロック図である。 ＳＯＡリファレンスモデルを説明する説明図である。 サービス要求受信時のサービス処理部の処理シーケンスを説明する概念図である。 処理結果確認要求受信時のサービス処理部の処理シーケンスを説明する概念図である。 本実施形態に係るサービス処理システムのソフトウェア構成を示す機能ブロック図である。 サービス受付部処理を示すフローチャートである。 処理実行部処理の一例(冪等呼び出し、補償無し)を示すフローチャートである。 処理実行部処理の一例(冪等呼び出し、補償無し、内部リトライ)を示すフローチャートである。 処理実行部処理の一例(冪等呼び出し、補償有り)を示すフローチャートである。 処理実行部処理の一例(非冪等呼び出し、補償有り、内部リトライ)を示すフローチャートである。 サービスＩＤ生成部処理を示すフローチャートである。 サービス呼出部処理を示すフローチャートである。 処理結果確認部処理を示すフローチャートである。 管理部処理を示すフローチャートである。 結果確認呼出部処理を示すフローチャートである。 サービスＩＤの体系及び遷移の一例を示す概念図である。 サービスＩＤにおけるＯＳＩＤの有効性を説明するための説明図である。 ＢＰＥＬにおける仮想冪等機能の実現を説明する説明図である。 サービスの実行が指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。 サービスの実行が指示された場合のサービス処理システム全体のシーケンスの他の例を示すシーケンス図である。 サービスの実行が指示された場合のサービス処理システム全体のシーケンスの他の例を示すシーケンス図である。 サービスの実行が複数回指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。 処理結果の確認が指示された場合のサービス処理システム全体のシーケンスの一例を示すシーケンス図である。
符号の説明
１０ サービス処理システム
１２ サービス処理サーバ
１２Ｃ 記憶部
１４ アプリケーション・サーバ
２４ 管理部
２６ 処理実行部
２８ サービス受付部
３０ サービスＩＤ生成部
３２ サービス呼出部
３４ 処理結果確認部
３６ 結果確認呼出部
３８ 処理状況テーブル
４２ リクエスタ
４６ プロバイダ
４８ パッケージ・ラッパー
５０ ＭＢラッパー
６６ 既存システム
６８ 既存システム

Claims (8)

  1. コンピュータによって実現され、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置であって、
    サービスの実行が要求されると、要求されたサービスに対応する自サービスの処理を行うと共に、下位のサービス処理装置による下位サービスの実行が必要な場合は、前記下位サービスの実行を要求するサービス要求を前記下位のサービス処理装置へ送信する処理手段と、
    サービス処理装置毎に相違するＩＤを設定した固有ＩＤと、サービス要求毎に相違するＩＤを設定した要求ＩＤを含むＩＤ要素を生成するＩＤ要素生成手段と、
    自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を各々設定した呼出元ＩＤ及び呼出先ＩＤを含むサービスＩＤを生成し、生成した前記サービスＩＤを前記処理手段が送信するサービス要求に付加し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信した前記サービス要求に付加されたサービスＩＤに呼出先ＩＤとして設定されているＩＤ要素を設定した呼出元ＩＤと、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定した呼出先ＩＤを含むサービスＩＤを生成し、生成した前記サービスＩＤを前記処理手段が送信するサービス要求に付加するサービスＩＤ生成・付加手段と、
    を備えたサービス処理装置。
  2. 前記サービスＩＤ生成・付加手段は、自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信した前記サービス要求に付加されたサービスＩＤにオリジナルＩＤとして設定されているＩＤ要素を設定したオリジナルＩＤも含むサービスＩＤを生成する請求項１記載のサービス処理装置。
  3. 前記サービスＩＤ生成・付加手段は、前記サービスＩＤを生成する毎に、生成したサービスＩＤを、自装置を実現するコンピュータに設けられた記憶手段に記憶させると共に、前記処理手段が、前記生成したサービスＩＤを付加したサービス要求に対応するサービス要求を上位のサービス処理装置から受信していた場合は、受信していたサービス要求に付加されていたサービスＩＤも対応付けて記憶させる請求項１又は請求項２記載のサービス処理装置。
  4. 前記ＩＤ要素生成手段は、前記コンピュータを前記サービス処理装置として機能させるためのプログラムの実行単位に付与された実行単位ＩＤも含むＩＤ要素を生成する請求項１〜請求項３の何れか１項記載のサービス処理装置。
  5. 前記処理手段は、サービス要求を送信した前記下位のサービス処理装置から正常な応答が無い場合に前記サービス要求の再送信を行い、前記ＩＤ情報生成・付加手段は、前記サービス要求の再送信時に前回と同一のサービスＩＤを付加する請求項１〜請求項４の何れか１項記載のサービス処理装置。
  6. 請求項１〜請求項５の何れか１項記載のサービス処理装置が情報を送受可能に複数設けられたサービス処理システム。
  7. コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムであって、
    前記コンピュータを、
    サービスの実行が要求されると、要求されたサービスに対応する自サービスの処理を行うと共に、下位のサービス処理装置による下位サービスの実行が必要な場合は、前記下位サービスの実行を要求するサービス要求を前記下位のサービス処理装置へ送信する処理手段、
    サービス処理装置毎に相違するＩＤを設定した固有ＩＤと、サービス要求毎に相違するＩＤを設定した要求ＩＤを含むＩＤ要素を生成するＩＤ要素生成手段、
    及び、自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を各々設定した呼出元ＩＤ及び呼出先ＩＤを含むサービスＩＤを生成し、生成した前記サービスＩＤを前記処理手段が送信するサービス要求に付加し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信した前記サービス要求に付加されたサービスＩＤに呼出先ＩＤとして設定されているＩＤ要素を設定した呼出元ＩＤと、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定した呼出先ＩＤを含むサービスＩＤを生成し、生成した前記サービスＩＤを前記処理手段が送信するサービス要求に付加するサービスＩＤ生成・付加手段
    として機能させるサービス処理プログラム。
  8. コンピュータを、情報を送受可能な他のサービス処理装置と共にサービス処理システムを構成するサービス処理装置として機能させるサービス処理プログラムが記録された記録媒体であって、
    前記サービス処理プログラムは、前記コンピュータを、
    サービスの実行が要求されると、要求されたサービスに対応する自サービスの処理を行うと共に、下位のサービス処理装置による下位サービスの実行が必要な場合は、前記下位サービスの実行を要求するサービス要求を前記下位のサービス処理装置へ送信する処理手段、
    サービス処理装置毎に相違するＩＤを設定した固有ＩＤと、サービス要求毎に相違するＩＤを設定した要求ＩＤを含むＩＤ要素を生成するＩＤ要素生成手段、
    及び、自装置よりも上位のサービス処理装置が存在しない場合は、前記ＩＤ要素生成手段によって生成されたＩＤ要素を各々設定した呼出元ＩＤ及び呼出先ＩＤを含むサービスＩＤを生成し、生成した前記サービスＩＤを前記処理手段が送信するサービス要求に付加し、自装置よりも上位のサービス処理装置が存在する場合は、前記上位のサービス処理装置から受信した前記サービス要求に付加されたサービスＩＤに呼出先ＩＤとして設定されているＩＤ要素を設定した呼出元ＩＤと、前記ＩＤ要素生成手段によって生成されたＩＤ要素を設定した呼出先ＩＤを含むサービスＩＤを生成し、生成した前記サービスＩＤを前記処理手段が送信するサービス要求に付加するサービスＩＤ生成・付加手段
    として機能させる記録媒体。
JP2008239773A 2008-09-18 2008-09-18 サービス処理装置、システム、プログラム及び記録媒体 Expired - Fee Related JP4336735B1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008239773A JP4336735B1 (ja) 2008-09-18 2008-09-18 サービス処理装置、システム、プログラム及び記録媒体
US12/560,849 US8103758B2 (en) 2008-09-18 2009-09-16 Service processing apparatus, system, and recording medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008239773A JP4336735B1 (ja) 2008-09-18 2008-09-18 サービス処理装置、システム、プログラム及び記録媒体

Publications (2)

Publication Number Publication Date
JP4336735B1 JP4336735B1 (ja) 2009-09-30
JP2010072951A true JP2010072951A (ja) 2010-04-02

Family

ID=41190701

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008239773A Expired - Fee Related JP4336735B1 (ja) 2008-09-18 2008-09-18 サービス処理装置、システム、プログラム及び記録媒体

Country Status (2)

Country Link
US (1) US8103758B2 (ja)
JP (1) JP4336735B1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011138332A (ja) * 2009-12-28 2011-07-14 Canon Software Inc ワークフローシステムおよびワークフローの制御方法およびプログラムおよび記録媒体。

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101246486B (zh) * 2007-02-13 2012-02-01 国际商业机器公司 用于改进的表达式处理的方法和装置
US8380820B1 (en) * 2011-04-08 2013-02-19 Cellco Partnership Sending synchronous responses to requests from frontend applications
US9141351B2 (en) * 2012-05-01 2015-09-22 Oracle International Corporation Indicators for resources with idempotent close methods in software programs
US11102108B2 (en) * 2017-08-31 2021-08-24 Oracle International Corporation System and method for a multicast send duplication instead of replication in a high performance computing environment
US11356327B2 (en) 2017-08-31 2022-06-07 Oracle International Corporation System and method for a single logical IP subnet across multiple independent layer 2 (L2) subnets in a high performance computing environment
JP7127326B2 (ja) 2018-03-28 2022-08-30 日本電気株式会社 冪等性保証機能付き情報処理装置、システム設定方法及びプログラム
EP3751420B1 (de) * 2019-06-11 2023-03-22 TTTech Computertechnik Aktiengesellschaft Wartbares verteiltes ausfallsicheres echtzeitcomputersystem

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2100139C (en) * 1992-09-29 1997-02-18 William Walter Demlow Information display provided to calling party
JPH0962526A (ja) * 1995-08-28 1997-03-07 Fujitsu Ltd 耐故障型ｒｐｃシステムおよび方法
US6185611B1 (en) * 1998-03-20 2001-02-06 Sun Microsystem, Inc. Dynamic lookup service in a distributed system
US6173049B1 (en) * 1997-08-11 2001-01-09 Bellsouth Intellectual Property Corporation System and method for automated provision and customer selection of temporary caller identification services
WO2001055841A1 (fr) * 2000-01-27 2001-08-02 Omron Corporation Procede et systeme relatifs a la distribution de programmes, serveur et client d'execution de programmes, dispositif d'obtention de programmes, et support d'enregistrement
US7895262B2 (en) * 2004-05-27 2011-02-22 Microsoft Corporation Web service application protocol and SOAP processing model
JP2006178658A (ja) * 2004-12-21 2006-07-06 Fujitsu Ltd 情報処理方法及びプログラム
US20070226705A1 (en) * 2006-02-15 2007-09-27 Microsoft Corporation Wrap-up reads for logless persistent components
JP2007304951A (ja) 2006-05-12 2007-11-22 Hitachi Ltd ビジネスプロセス管理方法、ビジネスプロセス管理プログラム、および、ビジネスプロセス管理サーバ
ATE522996T1 (de) * 2007-04-23 2011-09-15 Nokia Corp System und verfahren zum optimieren der herunterlade-benutzerdienstablieferung an roamende clients

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011138332A (ja) * 2009-12-28 2011-07-14 Canon Software Inc ワークフローシステムおよびワークフローの制御方法およびプログラムおよび記録媒体。

Also Published As

Publication number Publication date
US20100070558A1 (en) 2010-03-18
US8103758B2 (en) 2012-01-24
JP4336735B1 (ja) 2009-09-30

Similar Documents

Publication Publication Date Title
JP4336735B1 (ja) サービス処理装置、システム、プログラム及び記録媒体
US7266734B2 (en) Generation of problem tickets for a computer system
US7337427B2 (en) Self-healing cross development environment
US8626526B2 (en) System and method for a healthcare communication framework
US20150066572A1 (en) Identity and access management
JP4495977B2 (ja) 多層ネットワーク通信システム用再試行技術
US7954112B2 (en) Automatic recovery from failures of messages within a data interchange
JP2005346573A (ja) Ｗｅｂサービス提供方法、Ｗｅｂサービスシステムにおけるサーバ装置およびクライアント端末、Ｗｅｂサービスシステム、ならびに、Ｗｅｂサービスプログラムおよび記録媒体
US8468386B2 (en) Detecting and recovering from process failures
JP4401425B1 (ja) サービス処理装置、システム、プログラム及び記録媒体
EP2131279B1 (en) System and method for a generic integration of a database into a high availability cluster
JP2008129628A (ja) 複数のコンピュータシステムでメッセージをやり取りすることによって所定の業務を処理するシステムでの通信方式、及び、メッセージ中継プログラム
JP5086820B2 (ja) サービス管理方法とシステムおよびプログラム
JP4259427B2 (ja) サービス処理システムおよびその処理方法並びにその処理プログラム
JP4599456B2 (ja) サービス処理装置、システム、プログラム及び記録媒体
JP6169485B2 (ja) 分散処理システム
JP2011257994A (ja) 更新ａｐｉ検出システム、更新ａｐｉ検出装置、更新ａｐｉ検出方法、および更新ａｐｉ検出プログラム
JP2006011718A (ja) エラー監視装置、エラー監視システム及びエラー処理方法
JP6511019B2 (ja) サービス継続装置、サービス継続方法およびプログラム
JP2007329564A (ja) ファイル送信端末
JP6111209B2 (ja) 仮想マシン管理システム、仮想マシン管理方法、環境管理サーバ及びプログラム
JP2020027308A (ja) 原子性保証装置および原子性保証方法
US20230316191A1 (en) Workflow consistency ensuring device, workflow consistency ensuring method, and workflow consistency ensuring program
CN117411771A (zh) 基于区块链的数据处理方法及相关设备
JP2005301712A (ja) 遠隔保守管理方法及び遠隔保守管理システム

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090623

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090629

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120703

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150703

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees