TW201519099A - 資訊處理伺服器、資訊處理系統、資訊處理方法及程式記錄媒體 - Google Patents

Abstract

為了不設置多餘的伺服器、不停止提供之服務，而執行應用程式之更新、切換，本發明的資訊處理伺服器，包含對於客戶之請求提供相同服務的複數之應用程式，並具備管理裝置；該管理裝置，在接收了應用程式的更新檔案時，將更新檔案適用於複數之應用程式中未正在提供服務之至少一個應用程式，並切換應用程式以使適用了更新檔案之應用程式提供服務。

Description

資訊處理伺服器、資訊處理系統、資訊處理方法及程式記錄媒體

本發明係關於可以不停止提供中之服務而更新應用程式之資訊處理伺服器、資訊處理系統、資訊處理方法及程式記錄媒體。尤其，本發明係關於實現以下技術之資訊處理伺服器：於資訊處理伺服器上將TCP(Transmission Control Protocol，傳輸控制協定)埠作為收聽埠動作之應用程式中，能不停止服務而更新應用程式。

一般的應用程式服務中，在更新於資訊處理伺服器上動作之應用程式時，會伴隨著因應用程式之停止、再啟動所造成之服務停止。因此，在不允許服務停止的系統中，必須取用以下方法：準備兩台能進行相同處理之伺服器，並使一台為運行狀態，而使另一台為待命狀態而動作。

又，由應用程式提供服務之實際環境，與實施應用程式之開發、試驗的試驗環境完全不同，故在機器構成或各種設定上往往有差異。因此，在應用程式更新後，吾人希望能確認系統於實際環境是否也正常地動作。現狀中，若為以單一之機器構成的系統，有必要於應用程式更新後停止服務進行動作確認。又，若為準備有複數台能進行相同處理之機器的系統，則可以退出服務而以一部分之機器進行動作確認。

專利文獻1中揭露關於可以不中斷服務而進行應用程式的更新等維護作業之資訊處理系統。專利文獻1的資訊處理系統，包含客戶與伺服器為相同之應用程式提供裝置，並包含執行客戶端與伺服器端之用戶資料的同步之同步裝置。因此，在伺服器或是客戶側更新應用程式的同時，可以在另一側繼續執行應用程式。又，若在伺服器或是客戶側的應用程式的更新結束，可由更新結束之方負責應用程式之執行，而更新另一側的應用程式。 【先前技術文獻】 【專利文獻】

【專利文獻1】日本特開2010-134702號公報

【發明所欲解決之問題】

一般的應用程式服務中，可準備複數台可進行相同處理的伺服器，而使任一台伺服器為運行狀態，並將非運行之伺服器為待命狀態而動作。然而，一般的應用程式服務中存在以下問題：在狀態切換時會伴隨數分鐘左右服務停止、必需準備複數台提供相同服務之伺服器、需要等待直到所有伺服器的應用程式更新完畢。

又，一般的應用程式服務中，在應用程式更新後的動作確認中，不論伺服器為單數或複數，都會對服務產生影響。因此，存在以下課題：無法不給予服務影響而確認更新後之應用程式的正常性。

雖然專利文獻1之資訊處理系統中，可以繼續服務同時更新應用程式，然而，需要提供伺服器及客戶雙方相同的應用程式服務提供裝置。又，在複數之客戶共有應用程式之場合，若伺服器在更新或執行某客戶的應用程式，則無法使用此伺服器於其他客戶更新或執行動作中的應用程式。

本發明之目的在於提供一種資訊處理伺服器，其無需設置多餘的伺服器，且不用停止提供之服務，即可以執行應用程式之更新、切換。 【解決問題的方式】

本發明的資訊處理伺服器，包含對於客戶之請求提供相同服務的複數之應用程式，並具備管理裝置，該管理裝置在接收了應用程式的更新檔案時，將更新檔案適用於複數之應用程式中未正在提供服務之至少一個應用程式，並切換應用程式以使適用了更新檔案之應用程式提供服務。

本發明的資訊處理系統，包含資訊處理伺服器及應用程式更新伺服器；該資訊處理伺服器，包含對於客戶之請求提供相同服務的複數之應用程式，及管理裝置，該管理裝置在接收了應用程式的更新檔案時，將更新檔案適用於複數之應用程式中未正在提供服務的至少一個應用程式，並切換應用程式以於適用了更新檔案之應用程式提供服務；該應用程式更新伺服器，經由管理裝置確認應用程式動作之動作區域，並依照登錄之更新排程及更新情景(scenario)，將應用程式的更新檔案傳送到管理裝置。

本發明之資訊處理方法，為更新對於客戶之請求提供相同服務的複數之應用程式的資訊處理方法，並在接收了應用程式的更新檔案時，將更新檔案適用於複數之應用程式中未正在提供服務之至少一個應用程式，並切換應用程式以使適用了更新檔案之應用程式提供服務。

本發明之程式記錄媒體，係用以記錄資訊處理程式；該資訊處理程式更新對於客戶之請求提供相同服務的複數之應用程式；且該資訊處理程式的特徵為使電腦執行以下處理：在接收了應用程式的更新檔案時，將更新檔案適用於複數之應用程式中未正在提供服務的至少一個應用程式之處理；及切換應用程式以使適用了更新檔案的應用程式提供服務之處理。 【發明的效果】

依本發明提供之資訊處理伺服器，無需設置多餘的伺服器，且不用停止提供之服務，即可執行應用程式的更新、切換。

以下，就本實施方式使用圖面說明。但在下述實施態樣中，雖然為實施本發明，而做了於技術上較佳之限定，但發明之範圍並非限定於以下者。

(第1實施態樣) (構成) 首先，使用圖1就依本發明之第1實施態樣的資訊處理系統1之構成加以說明。

圖1中，依第1實施態樣的資訊處理系統1，包含：伺服器10、應用程式更新伺服器30及操作終端40。

伺服器10(亦稱為「資訊處理伺服器」)因應來自客戶之請求執行應用程式，並向客戶提供服務。伺服器10並經由網際網路(internet)等網路(network)，接收客戶之請求。

應用程式更新伺服器30，係用以進行應用程式更新檔案之管理、更新情景之管理、更新排程之管理、及對伺服器10之面管理機能的各種指令之執行等。應用程式更新伺服器30，能以電纜等直接與伺服器10連接，或經由網際網路等網路與伺服器10連接。

操作終端40為服務之提供者或管理者等操作者進行操作之終端。操作終端40為登入應用程式更新伺服器30並進行各種操作用之終端。操作終端40可以登錄、保持更新應用程式用之更新資訊。

所謂應用程式之更新資訊，係指用以顯示與包含更新排程、更新情景及更新檔案之應用程式之更新相關的資訊。更新排程包含更新應用程式之時序等時間分配。更新情景包含以下資訊：在依照更新排程而更新應用程式時，因應應用程式的動作狀況等，該採取何種對應處理方法。例如，本實施態樣中，以依照更新排程之時序確認應用程式之動作狀況，並適用因應應用程式之動作狀況的更新情景而更新應用程式。

又，操作終端40，亦得以電纜等直接與應用程式更新伺服器30連接，或經由網際網路等網路與應用程式更新伺服器30連接。

伺服器10包含A面應用程式11(亦稱為「第1應用程式」)及B面應用程式12(亦稱為「第2應用程式」)。A面應用程式11為在A面(亦稱為「第1動作區域」)動作之應用程式，B面應用程式12為在B面(亦稱為「第2動作區域」)動作之應用程式。A面應用程式11及B面應用程式12，例如，係安裝於不同的目錄(directory)。

本實施態樣中，A面應用程式11係保存於第1目錄，並在第1動作區域動作。又，本實施態樣中，B面應用程式12係保存於第2目錄，並在第2動作區域動作。

又，伺服器10包含A面應用程式11之收聽埠13(亦稱為「第1埠」)，及B面應用程式12之收聽埠14(亦稱為「第2埠」)。

進而，伺服器10包含：收聽埠15(亦稱為「第1介面」)，及面管理API16(亦稱為「管理裝置」)(API：Application Programming Interface，應用程式設計介面)。

伺服器10包含A面應用程式11及B面應用程式12動作之兩個啟動側。在伺服器10上，可在A面與B面其中一面，或是在雙面啟動應用程式。又，所謂啟動側，表示可使A面應用程式11及B面應用程式12分別各自動作之動作區域。

又，本實施態樣中，將「在可對客戶提供服務之狀態上為啟動著的狀態」稱為「啟動中」，而將「在可對客戶提供服務之狀態上為非啟動著的狀態」稱為「待命中」。設定為由面管理API16來受理客戶之請求的這種啟動中的應用程式，成為對客戶提供服務之應用程式。

又，本實施態樣中，在應用程式為啟動中之啟動側中，將正在對客戶提供服務的應用程式，稱為提供服務中之應用程式。又，將未正在對客戶提供服務的應用程式，稱為未提供服務中之應用程式。未正在提供服務之應用程式，包含的態樣有：在可向客戶提供服務之狀態啟動，但未與客戶連接之應用程式；或是，在可向客戶提供服務的狀態未啟動之應用程式。

A面應用程式11，將收聽埠13作為收聽埠啟動。又，B面應用程式12，將收聽埠14作為收聽埠啟動。

一旦在收聽埠13接收來自客戶的請求，便會在A面應用程式11執行處理。又，一旦在收聽埠14接收來自客戶的請求，便會在B面應用程式12執行處理。

收聽埠15為接收自來客戶之請求的第1介面。收聽埠15若接收到請求，便會進行埠變換，並將請求傳遞至提供服務中的應用程式之收聽埠(收聽埠13或收聽埠14)。提供服務中的應用程式，會因應接收之請求而執行處理。

例如，在A面應用程式11為提供服務中的應用程式時，在A面應用程式11執行處理。又，在B面應用程式12為提供服務中的應用程式時，在B面應用程式12執行處理。

面管理API16，為包含伺服器10之面管理機能的管理裝置，主要係用以進行應用程式之啟動側的管理。具體而言，面管理API16依照應用程式更新伺服器30的要求，而進行收聽埠15之變換目標埠的切換，及A面應用程式11及B面應用程式12的啟動、停止。

又，面管理API16係在更新應用程式時，進行待命中的應用程式之更新。所謂待命中的應用程式，係指未正在執行客戶之請求側(未正在提供服務的一側)之應用程式。例如，當A面應用程式11為提供服務中的場合，便更新待命中之B面應用程式12。

其後，面管理API16啟動更新後的應用程式，並將收聽埠15之埠變換目標，切換為更新後的應用程式之收聽埠。例如，在更新了待命中之B面應用程式12後，啟動B面應用程式12，並將收聽埠15的埠變換目標，切換為收聽埠14。亦即，一旦面管理API16(管理裝置)將更新檔案適用於待命中的應用程式，便會切換應用程式，以使適用了更新檔案的應用程式提供服務。

依上述本發明之第1實施態樣的資訊處理系統，可以不停止服務而更新應用程式。又，由於無需區分更新與執行應用程式的伺服器，故無需準備複數台伺服器，且應用程式的更新僅需在1次時序實施即可。

(動作) 接著，參照圖2之流程圖，說明依第1實施態樣的資訊處理系統1之動作。

圖2中，首先，操作終端40登入應用程式更新伺服器30，並在應用程式更新伺服器30登錄應用程式之更新資訊(步驟S11)。應用程式之更新資訊，係指關於更新檔案、更新情景及更新排程的資訊。

應用程式更新伺服器30對於面管理API16確認啟動側(步驟S12)。

面管理API16從應用程式更新伺服器30，取得非啟動中側(待命中)之應用程式用更新檔案(應用程式更新檔案)，並更新待命側的應用程式(步驟S13)。

一旦應用程式的更新結束，面管理API16會將收聽埠15之變換目標埠，變更為更新結束後一側的應用程式側之收聽埠(收聽埠13或14)，並切換啟動側(步驟S14)。在此階段，更新完畢側的應用程式，會變成啟動中。

面管理API16，因應應用程式更新伺服器30的剩餘連接確認要求，確認啟動中側(未更新的一側)之應用程式的剩餘連接(步驟S15)。

剩餘連接不為0的場合(在步驟S16為「否」)，面管理API16，會對於直到「剩餘連接」變成0為止之剩餘連接進行確認(回到步驟S15)。

當剩餘連接為0的場合(在步驟S16為「是」)，面管理API16通知應用程式更新伺服器30：連接全部已開放(步驟S17)。

面管理API16，因應應用程式更新伺服器30之應用程式停止要求，停止處於啟動中側(未更新的一側)之應用程式(步驟S18)。

以上，為依第1實施態樣的資訊處理系統1之動作的說明。

進而，參照圖3之序列圖，詳細說明在提供服務中的應用程式為A面應用程式11時，開始應用程式的更新之動作。又，啟動中的應用程式為B面應用程式12時，在以下之說明中，僅需將A面與B面交替即可。

圖3中，操作終端40遠程登入應用程式更新伺服器30(步驟S101)。

一旦操作終端40登入應用程式更新伺服器30，便將更新資訊登錄應用程式更新伺服器30(步驟S102) 步驟S102中，首先，操作終端40將應用程式的更新檔案，登錄至應用程式更新伺服器30。接著，操作終端40將更新情景與更新排程，登錄至應用程式更新伺服器30。

應用程式更新伺服器30係依照登錄之更新排程自動執行步驟S103以後之處理。

應用程式更新伺服器30對於面管理API16，進行啟動側之確認(步驟S103)。

面管理API16通知應用程式更新伺服器30：A面應用程式11係啟動中(步驟S104)。

由於在應用程式更新伺服器30，現正提供服務中的應用程式為A面，故判斷為：將非啟動中側(待命側)之B面應用程式12的檔案，進行更新。又，應用程式更新伺服器30將應用程式的更新檔案，傳輸至面管理API16(步驟S105)。

面管理API16在接收應用程式的更新檔案後，會將B面應用程式12現在的應用程式檔案進行備份(步驟S106)。

在B面應用程式12的應用程式檔案備份完成後，面管理API16會將應用程式的更新檔案於B面展開(步驟S107)。

若應用程式之展開完成，面管理API16會向應用程式更新伺服器30進行展開完成通知(步驟S108)。又，展開完成通知，亦可從B面應用程式12向應用程式更新伺服器30進行通知。

在向B面之更新檔案展開完成後，應用程式更新伺服器30對於面管理API16，進行啟動側切換要求(步驟S109)。

因應應用程式更新伺服器30的啟動側切換要求，面管理API16將更新完畢的B面應用程式12啟動(步驟S110)。

一旦B面應用程式12之啟動完成，B面應用程式12便對於面管理API16通知啟動完成(步驟S111)。

一旦接收啟動完成的通知，面管理API16便會執行以下「啟動側切換處理」：對於收聽埠15，將變換目標埠從A面應用程式11的收聽埠13，變更至B面應用程式12的收聽埠14(步驟S112)。

在啟動側切換處理後，收聽埠15所接收到之請求，會改為在更新完畢之B面應用程式12，進行處理。

若B面應用程式12之啟動及收聽埠15的變換目標埠之變更完成，面管理API16便對於應用程式更新伺服器30，進行應用程式啟動完成之通知(步驟S113)。

在此，在依第1實施態樣的資訊處理系統1中，會執行處於啟動中(提供著服務)的A面應用程式11的連接開放之處理。

若接收B面應用程式12之啟動完成通知，則應用程式更新伺服器30會向面管理API16，進行剩餘連接確認開始要求(步驟S114)。

面管理API16對於A面應用程式11，進行剩餘連接的確認(步驟S115)。

A面應用程式11對於面管理API16，進行剩餘連接的應答(步驟S116)。又，步驟S115之確認與步驟S116之應答的處理，會在剩餘連接變為0為止重覆進行。

一旦A面的連接全部開放，則面管理API16便會對於應用程式更新伺服器30，進行連接開放通知(步驟S117)。

一旦接收連接開放通知，應用程式更新伺服器30便會對於面管理API16，進行A面應用程式11之停止要求(步驟S118)。

面管理API16會因應應用程式更新伺服器30的停止要求，停止A面應用程式11(步驟S119)。

A面應用程式11係藉由面管理API16之停止控制而停止，並進行停止完成通知(步驟S120)。

面管理API16對於應用程式更新伺服器30，進行A面應用程式11的停止完成通知(步驟S121)。

又，直到A面應用程式11的停止完成為止，應用程式更新伺服器30不會實施下一個應用程式更新。

以上，為依使用了圖3的序列圖之第1實施態樣的資訊處理系統1的動作之詳細說明。

依第1實施態樣的資訊處理系統1中，更新B面應用程式12後，預先將A面應用程式11(更新前)及B面應用程式12(更新完畢)同時設定為已啟動之狀態。又，將收聽埠15之變換目標埠，從A面應用程式11的收聽埠13，變更為B面應用程式12的收聽埠14。因此，在變換目標埠變更後接收之請求，係在已更新完畢之B面應用程式12進行處理。亦即，因藉由變更收聽埠15之變換目標埠來進行啟動側的切換，故可以不停止服務而進行應用程式之更新。

如此，依本發明之第1實施態樣的資訊處理系統，可以不停止服務而更新應用程式。

使用依以上本發明之第1實施態樣的方法之任意的資訊處理方法，係涵蓋於本發明之範圍者。又，在電腦執行與依本發明之第1實施態樣的資訊處理方法相關之處理的程式、或儲存有該程式之程式記錄媒體，亦為涵蓋於本發明之範圍者。

(變形例) 於圖4表示第1實施態樣之變形例。

變形例之資訊處理系統1-1，除具備包含3個以上之動作區域的伺服器17外，係與圖1之資訊處理系統1相同。因此，關於同樣之構成元素，係使用相同的符號。

伺服器17除了具有A面應用程式11及B面應用程式12外，更包含至少一個N面應用程式18。圖4中繪有N面應用程式18及收聽埠19。又，雖然圖4中僅繪出一個N面應用程式，但是變形例之伺服器17，可包含複數之N面應用程式。亦即，變形例之伺服器17係包含3個以上的應用程式。

資訊處理系統1-1，例如，亦可由面管理API16設定優先提供服務之應用程式，同時，設定優先更新之應用程式。又，關於更新之應用程式，亦可依序更新所有應用程式，或將未正在提供服務的應用程式一併更新。此時，亦可設定為：由從面管理API16取得了更新檔案之應用程式，將更新檔案傳輸至不同的應用程式。又，亦可設定為：總是只將位於確定的動作區域之應用程式更新到最新，或是針對位於確定的動作區域之應用程式，保持確定的舊的備份。進而，亦可設定為：一面在複數相異之應用程式接收並列而相異之請求，一面在其他應用程式進行更新。

依變形例之資訊系統，藉由將啟動側定為3個以上，可以在將複數之請求並行處理的同時，不停止服務而更新應用程式。

(第2實施態樣) 接著，使用圖5說明依本發明之第2實施態樣的資訊處理系統2之構成。依第2實施態樣之資訊處理系統2，在具有正常性確認伺服器50及收聽埠27這點上，係與依第1實施態樣的資訊處理系統1不同。

(構成) 圖5中，依第2實施態樣之資訊處理系統2，包含：伺服器20、應用程式更新伺服器30、操作終端40及正常性確認伺服器50。又，由於應用程式更新伺服器30及操作終端40，係與依第1實施態樣的資訊處理系統1之構成相同，故附加相同符號並省略說明。

伺服器20包含A面應用程式21(亦稱為「第1應用程式」)及B面應用程式22(亦稱為「第2應用程式」)。又，伺服器20包含A面應用程式21之收聽埠23(亦稱為「第1埠」)及B面應用程式22之收聽埠24(亦稱為「第2埠」)。又，伺服器20包含來自客戶之請求收聽埠25(亦稱為「第1介面」)及面管理API26(亦稱為「管理裝置」)。進而，伺服器20包含對應於B面應用程式22之收聽埠27。伺服器20在具有收聽埠27這點上，係與依第1實施態樣的資訊處理系統1之伺服器10不同。

圖5之A面應用程式21、B面應用程式22、收聽埠23～25及面管理API26，係分別對應圖1之A面應用程式11、B面應用程式12、收聽埠13～15及面管理API16。

正常性確認伺服器50為進行自動實施正常性確認試驗用之腳本(script)的執行之伺服器。

收聽埠27為接收實施正常性確認時之請求的收聽埠(亦稱為「第2介面」)。藉由將埠做區分，而使「提供中的服務為收聽埠25，正常性確認為收聽埠27」，可在提供服務的同時，實施應用程式更新後的正常性確認。又，雖然圖5中顯示，在伺服器20內部，收聽埠27係連接於收聽埠23及24，然而收聽埠27亦可與收聽埠25或面管理API26連接。

若藉由依照如上述第2實施態樣的資訊處理系統2，在A面應用程式21進行服務提供之期間，可以更新B面應用程式22，並進行更新完畢之B面應用程式22的正常性確認。

(動作) 接著，參照圖6的流程圖，說明依第2實施態樣的資訊處理系統2之動作。

圖6中，操作終端40登入應用程式更新伺服器30，並將應用程式的更新資訊登錄至應用程式更新伺服器30(步驟S21)。應用程式的更新資訊係關於更新檔案、更新情景及更新排程的資訊。

應用程式更新伺服器30對於面管理API26確認啟動側(步驟S22)。

面管理API26從應用程式更新伺服器30，取得非啟動中側(待命中)之應用程式用的更新檔案，並更新非啟動中側(待命中)之應用程式(步驟S23)。

一旦應用程式的更新結束，面管理API26便會將收聽埠27的變換目標埠，變更為已更新完畢側之應用程式側的收聽埠(收聽埠23或24)(步驟S24)。在此階段，應用程式於兩面成為動作中之狀態，並可以在一面進行服務提供，同時，在另一面實施更新應用程式的正常性確認。例如，當在A面應用程式21已提供著服務時，在更新了B面應用程式22後，可以在藉由A面應用程式21繼續提供服務的同時，實施B面應用程式22的正常性確認。

正常性確認伺服器50因應應用程式更新伺服器30的正常性確認要求，對於更新後的應用程式，執行正常性確認腳本，並進行正常性確認(步驟S25)。

所謂正常性確認，例如，若為利用HTTP協定之應用程式，係指在應用程式傳送HTTP請求並確認是否返回期待之HTTP回應(HTTP：Hypertext Transfer Protocol，超文件傳送協定)。又，本實施態樣中之正常性確認，只要為能確認更新後之應用程式的正常性之處理即可，並不限定於上述之方式。

一旦正常性確認結束，面管理API26因應應用程式更新伺服器30的應用程式停止要求，停止進行過正常性確認那方(更新後的一側)的應用程式(步驟S26)。

以上，為依第2實施態樣的資訊處理系統2之動作的說明。又，本發明之範圍，並不限於圖6之流程圖，亦可做各種變更、追加。

進而，參照圖7之序列圖，將本實施例之動作記載如下。在此，就提供服務中的應用程式為A面應用程式21之場合，詳細說明開始應用程式的更新之動作。又，啟動中的應用程式為B面應用程式22之場合，於以下之說明中，僅需將A面與B面交替即可。

圖7中，首先，操作終端40遠程登入至應用程式更新伺服器30(步驟S201)。

一旦操作終端40登入應用程式更新伺服器30，便會將更新資訊登錄至應用程式更新伺服器30(步驟S202) 步驟S202中，首先，操作終端40將應用程式的更新檔案登錄至應用程式更新伺服器30。接著，操作終端40將更新情景及更新排程登錄至應用程式更新伺服器30。

應用程式更新伺服器30依照登錄之更新排程，自動執行步驟S203以後之處理。

應用程式更新伺服器30對於面管理API26，進行啟動側之確認(步驟S203)。

面管理API26通知應用程式更新伺服器30：A面應用程式21係啟動中(步驟S204)。

由於應用程式更新伺服器30中，現正起動中的應用程式為A面，故判斷為更新非啟動中側(待命側)之B面應用程式22的檔案。又，應用程式更新伺服器30將應用程式的更新檔案，傳輸至面管理API26(步驟S205)。

面管理API26在接收到應用程式的更新檔案後，將B面應用程式22現在的應用程式檔案進行備份(步驟S206)。

在B面應用程式22之應用程式檔案備份完成後，面管理API26將應用程式的更新檔案，於B面展開(步驟S207)。

若應用程式之展開完成，面管理API26對於應用程式更新伺服器30，進行展開完成通知(步驟S208)。又，展開完成通知亦可從B面應用程式12，向應用程式更新伺服器30進行通知。

在向B面的更新檔案展開完成後，應用程式更新伺服器30對於面管理API26，進行變換目標埠變更要求(步驟S209)。

因應應用程式更新伺服器30的變換目標埠變更要求，面管理API26啟動更新完畢之B面應用程式22(步驟S210)。

一旦B面應用程式22之啟動完成，B面應用程式22便會通知面管理API26啟動已完成(步驟S211)。

一旦接收啟動完成的通知，面管理API26便會對於收聽埠27，執行將變換目標埠從A面應用程式21的收聽埠23，變更至B面應用程式22的收聽埠24之變換目標埠變更處理(步驟S212)。

變換目標埠變更處理以後，由收聽埠27接收之請求，係於更新完畢的B面應用程式22進行處理。

若B面應用程式22的啟動及收聽埠27之變換目標埠的變更完成，則面管理API26會對於應用程式更新伺服器30，進行變換目標埠變更完成之通知(步驟S213)。

此時，在A面及B面兩面應用程式成為動作中之狀態，而可以在A面應用程式21進行服務提供的同時，亦在B面應用程式22實施更新應用程式的正常性確認。

在此，在依第2實施態樣的資訊處理系統2中，執行應用程式的更新已結束之B面應用程式22的正常性確認處理。

應用程式更新伺服器30於正常性確認伺服器50，進行B面應用程式22的正常性確認要求(步驟S214)。

正常性確認伺服器50執行正常性確認腳本，並對於B面應用程式22實施正常性確認。此時，藉由正常性確認腳本向執行之B面應用程式22的請求，係於收聽埠27被接收(步驟S215)，並在收聽埠24受到埠變換後，被傳送至B面應用程式22(步驟S216)。

B面應用程式進行從收聽埠27被傳送之請求的處理，並將回應返回正常性確認伺服器50(步驟S217)。

正常性確認伺服器50將正常性確認的結果，通知應用程式更新伺服器30(步驟S218)。

應用程式更新伺服器30對於面管理API26，進行B面應用程式22的停止要求(步驟S219)。

面管理API26因應應用程式更新伺服器30之停止要求，停止B面應用程式22(步驟S220)。

B面應用程式22，由面管理API26之停止控制而停止，並對於面管理API26進行停止完成通知(步驟S221)。又，停止完成通知亦可設定為在B面應用程式22即將停止前，對於面管理API26進行通知，或是設定為在停止完成後，對於面管理API26通知。

面管理API26對於應用程式更新伺服器30，進行B面應用程式22之停止完成通知(步驟S222)。

又，直到B面應用程式22停止完畢為止，應用程式更新伺服器30不會實施下一個應用程式更新。

以上，詳細說明依圖7的序列圖之第2實施態樣的資訊處理系統2之動作。

如上所述，依第2實施態樣之資訊處理系統2中，在更新前之A面應用程式21提供服務的同時，可實施更新完畢之B面應用程式22的正常性確認。又，第2實施態樣之說明中，雖就使兩個應用程式動作之例加以說明，但就與第1實施態樣之變形例同樣地使複數之應用程式動作之場合，亦能適用於依第2實施態樣之手法。

使用依上述本發明之第2實施態樣的方法之任意資訊處理方法，係涵蓋於本發明之範圍。又，於電腦執行關於本發明的資訊處理方法之處理的程式、儲存有該程式之程式記錄媒體，亦涵蓋於本發明之範圍。

以上，雖然參照實施態樣說明了本發明，但本發明並非限定於上述實施態樣者。本發明之構成或細節上，在本發明的範圍內，可進行通常知識者能理解之各種變更。

本申請案，係以2013年7月3日提出申請之日本申請案「日本特願2013-139779」為基礎主張優先權，故其揭露內容均涉及於此。

1，2‧‧‧資訊處理系統
10，20‧‧‧伺服器
11，21‧‧‧A面應用程式
12，22‧‧‧B面應用程式
13，14，23，24‧‧‧收聽埠
15，25，27‧‧‧收聽埠
16，26‧‧‧面管理API
30‧‧‧應用程式更新伺服器
40‧‧‧操作終端
50‧‧‧正常性確認伺服器
S11~S18，S21~S26，S101~S121，S201~S222‧‧‧步驟

【圖1】表示依本發明之第1實施態樣的資訊處理系統之構成的方塊圖。 【圖2】表示依本發明之第1實施態樣的資訊處理系統之動作的流程圖。 【圖3】表示依本發明之第1實施態樣的資訊處理系統之動作的序列圖。 【圖4】表示依本發明之第1實施態樣之變形例的資訊處理系統之構成的方塊圖。 【圖5】表示依本發明之第2實施態樣的資訊處理系統之構成的方塊圖。 【圖6】表示依本發明之第2實施態樣的資訊處理系統之動作的流程圖。 【圖7】表示依本發明之第2實施態樣的資訊處理系統之動作的序列圖。

1‧‧‧資訊處理系統

10‧‧‧伺服器

11‧‧‧A面應用程式(第1應用程式)

12‧‧‧B面應用程式(第2應用程式)

13‧‧‧收聽埠(第1埠)

14‧‧‧收聽埠(第2埠)

15‧‧‧收聽埠(第1介面)

16‧‧‧面管理API(管理裝置)

30‧‧‧應用程式更新伺服器

40‧‧‧操作終端

Claims (10)

1. 一種資訊處理伺服器，包含對於客戶之請求提供相同服務之複數應用程式，該資訊處理伺服器之特徵在於具有： 管理裝置，該管理裝置在接收了該應用程式的更新檔案時，將該更新檔案適用於該複數之應用程式中未正在提供該服務之至少一個應用程式，並切換應用程式以使適用了該更新檔案之該應用程式提供該服務。
2. 如申請專利範圍第1項所述之資訊處理伺服器，更包含： 第1應用程式，在第1動作區域動作； 第2應用程式，在與該第1動作區域不同的第2動作區域動作； 第1及第2埠，分別向該第1及第2應用程式傳送該請求；及 第1介面，接收該請求而進行埠變換，並將該請求分配給該第1及第2埠； 該資訊處理伺服器之特徵在於：該管理裝置， 對於該第1介面輸出切換分配該請求給該第1及第2埠之哪一者的指示，並控制該第1及第2應用程式之啟動及停止，同時， 當該第1應用程式於啟動中取得了該應用程式的更新檔案時，在將該更新檔案適用於待命中的該第2應用程式後，將提供該服務的應用程式，從該第1應用程式，切換到該第2應用程式。
3. 如申請專利範圍第1或2項所述之資訊處理伺服器，其中， 該管理裝置， 在適用該更新檔案前，取出適用該更新檔案之該應用程式的備份。
4. 如申請專利範圍第2項所述之資訊處理伺服器，其中， 該管理裝置， 在更新了該第2應用程式後，啟動待命中之該第2應用程式，並在該第1應用程式的剩餘連接變為0的階段，將提供該服務的應用程式，從該第1應用程式，切換到該第2應用程式。
5. 如申請專利範圍第1或2項所述之資訊處理伺服器，其中， 該管理裝置，在該應用程式中任一者於啟動中取得了該更新檔案時，會在執行待命中之任一該應用程式的更新後，啟動適用了該更新檔案之該應用程式之任一者；且 該管理裝置切換應用程式，以使適用了該更新檔案之該應用程式提供該服務。
6. 一種資訊處理系統，包含資訊處理伺服器及應用程式更新伺服器， 該資訊處理伺服器，包含對於客戶之請求提供相同服務的複數之應用程式；並具備管理裝置，該管理裝置在接收了該應用程式的更新檔案時，將該更新檔案適用於該複數之應用程式中未正在提供該服務之至少一個應用程式，並切換應用程式以使適用了該更新檔案的該應用程式提供該服務； 該應用程式更新伺服器，經由該管理裝置確認該應用程式動作之動作區域，並依照登錄之更新排程及更新情景，將該應用程式的更新檔案傳送到該管理裝置。
7. 如申請專利範圍第6項所述之資訊處理系統，更包含操作終端，該操作終端將該更新檔案、該更新排程及該更新情景，登錄至該應用程式更新伺服器。
8. 如申請專利範圍第6或7項所述之資訊處理系統，更包含正常性確認伺服器，該正常性確認伺服器對於適用了該更新檔案之該應用程式，執行正常性確認之腳本； 該資訊處理伺服器，更包含第2介面，用以接收在實施正常性確認時之請求； 該正常性確認伺服器，因應來自該應用程式更新伺服器之請求，經由該第2介面，執行適用了該更新檔案的該應用程式之正常性確認的腳本。
9. 一種資訊處理方法，更新對於客戶之請求提供相同服務的複數之應用程式，包含以下步驟： 在接收了該應用程式的更新檔案時， 將該更新檔案適用於該複數之應用程式中未正在提供該服務的至少一個應用程式；及 切換應用程式以使適用了該更新檔案之該應用程式提供該服務。
10. 一種程式記錄媒體，其記錄有將對於客戶之請求提供相同服務之複數應用程式更新的資訊處理程式； 該資訊處理程式之特徵為使電腦執行以下處理： 在接收了該應用程式的更新檔案時， 將該更新檔案適用於該複數之應用程式中未正在提供該服務的至少一個應用程式之處理；及 切換應用程式以於適用了該更新檔案的該應用程式提供該服務之處理。