本發(fā)明涉及用于管理包括web應用服務的服務器的管理服務器系統、系統和系統的方法。
背景技術：
：近些年，通過互聯網上的服務器提供的服務已經變得流行。可以在能夠被來自全世界的用戶使用服務的模式下操作這些服務。在這樣的操作模式下，難以在特定時段期間停止系統來進行服務維護。因此，對在不停止服務的情況下進行維護工作的技術的需求越來越大。日本特許第4083049號和日本特開2004-295605號公報討論了如下傳統技術：通過對來自客戶的請求向服務器的分發(fā)進行控制，在不停止服務的情況下，進行服務器維護或服務器切換。隨著web應用技術的進步，傳統配置(服務器生成超文本標記語言(html)格式的畫面并將該畫面發(fā)送給客戶)正轉變?yōu)槿缦录夹g，例如rest(表述性狀態(tài)轉移)-fulmvc(模型-視圖-控制器)和客戶側mvc。根據這樣的技術，服務器經由rest接口(i/f)執(zhí)行處理并僅將數據返回給客戶。在客戶側生成畫面。技術實現要素：根據本發(fā)明的一方面，一種管理服務器系統，所述管理服務器系統能夠與分發(fā)服務器和一個或更多個dns服務器進行通信，dns服務器返回與伴隨針對名稱解析的請求而一起接收的主機名相對應的ip地址，所述分發(fā)服務器將來自客戶的針對html請求和api請求的處理請求，發(fā)送給與從dns服務器返回的ip地址相對應的系統，所述管理服務器系統包括：構造單元，其用于在信息處理裝置中部署用于構造系統環(huán)境的程序，以構造系統；以及設置單元，其用于針對與html請求相對應的主機名和與api請求相對應的主機名中的各個，設置由所述構造單元構造的系統的ip地址，所述主機名登記在dns服務器中，其中，在所述構造單元構造新系統之后，所述設置單元開始將針對與api請求相對應的主機名而設置的當前ip地址重寫為新系統的ip地址，并且，響應于確認完成了對與來自所述分發(fā)服務器的針對名稱解析的請求相對應的所有dns服務器的重寫，開始將針對與html請求相對應的主機名而設置的ip地址重寫為新系統的ip地址。根據下面參照附圖對示例性實施例的描述，本發(fā)明的其他特征將變得清楚。附圖說明圖1是示出系統構造的框圖。圖2是示出各個裝置的硬件構造的框圖。圖3是示出各個裝置的軟件模塊構造的框圖。圖4是示出從客戶終端到應用服務器的通信的示意圖。圖5是示出當執(zhí)行應用時由客戶服務器進行的處理的流程的序列圖。圖6是示出升級處理的流程圖。圖7a、7b、7c、7d和7e是各自示出在升級處理期間的系統配置的圖。圖8是示出升級處理的流程圖。圖9是示出升級處理的流程圖。具體實施方式存在稱為藍綠部署的方法，作為一種用于在不停止服務的情況下切換系統的技術。藍綠部署是用于在將當前運行的系統維持在運行狀態(tài)的同時構造新系統，然后將客戶的連接切換到新系統的技術。使用藍綠部署的系統切換可以通過改變在dns中登記的主機名的ip地址設置來切換系統。但是，存在這樣的問題。如果存在多個用于名稱解析的dns服務器，則由于在dns服務器之間的ip地址設置的同步中存在時間差，名稱解析的請求者可能會獲得舊系統的ip地址和新系統的ip地址二者。即使切換在dns中登記的主機的ip地址，也并不是所有的訪問都立即指向新系統。因此，被訪問的系統是新系統還是舊系統是不清楚的。本發(fā)明旨在提供防止發(fā)生經由由新系統提供的html畫面而向舊系統進行api調用的系統。根據本發(fā)明，可以防止經由由新系統提供的html畫面而向舊系統進行api調用。下面將參照附圖描述用于執(zhí)行本發(fā)明的模式。在第一示例性實施例中，在互聯網上的服務器中部署應用。應用與客戶終端協作提供各種功能。提供這些功能的應用將被稱為服務。對客戶終端進行的功能的提供將被稱為服務的提供。圖1示出根據本示例性實施例的系統構造。根據本示例性實施例的升級系統包括管理服務器140、dns180和分發(fā)服務器130。應用服務器110和120提供服務。在圖1中，服務器被示出為各自包括一個信息處理裝置。然而，應當注意，不特別限制構成各個服務器的信息處理裝置的數量。客戶終端150使用服務。在本示例性實施例中，將廣域網(wan)100構造為萬維網(worldwideweb)(www)系統。局域網(lan)101連接組件。lan102類似于lan101，但是通常被構造為不能經由wan100訪問的內部網絡。如同lan101，lan102可以被構造為與wan100直接連接并可以從wan100訪問。應用服務器110和120各自包括一個或多個信息處理裝置。在具有如圖1所示的構造的網絡上實施應用服務器110和120。應用服務器110是當前提供服務的應用服務器。應用服務器120是下一個提供服務的系統。應用服務器110和120之間的系統切換不一定僅為升級目的而執(zhí)行。分發(fā)服務器130一般包括多個信息處理裝置，但是可以由單個信息處理裝置構成。分發(fā)服務器130具有從客戶終端150向應用服務器110和120中的合適的應用服務器分發(fā)訪問的功能。管理服務器140一般包括多個信息處理裝置，但是可以由單個信息處理裝置構成。管理服務器140管理構成應用服務器110和120的程序，并進行應用服務器110和120的構建及切換處理。客戶終端150是安裝有web瀏覽器的信息處理裝置。客戶終端150的示例包括個人計算機和諸如智能電話的移動終端。dns180是解析網絡上的服務器的主機名并返回訪問目的地的ip地址的系統。dns180的信息處理裝置可以簡稱為dns，并可以稱為dns服務器。在任一情況下，dns180是具有響應于名稱解析請求而向請求者返回ip地址的功能的系統。利用藍綠部署，通過將與在dns180中登記的主機名相對應的ip地址，從應用服務器110的ip地址重寫為應用服務器120的ip地址，來實現服務切換。分發(fā)服務器130將來自客戶終端150的請求發(fā)送到應用服務器。更具體地，分發(fā)服務器130將與來自客戶150的請求相對應的數據發(fā)送到由dns180進行了名稱解析的應用服務器110和120中的任一個。這意味著，分發(fā)服務器130從dns180獲得與設置的傳輸目的地主機名相對應的應用服務器的ip地址，并且連接到運行中的應用服務器110和120中的任一個。以上是本升級系統中包括的裝置的描述。如上所述，各服務器可以被構造為各自包括一個或多個信息處理裝置。如此處所采用的，服務器因此可稱為服務器系統，以涵蓋這兩種構造。例如，如果將管理服務器140稱為管理服務器系統，則管理服務器140意味著包括單個信息處理裝置或者含有多個信息處理裝置的服務器組。圖2示出了包括應用服務器110和120、分發(fā)服務器130、管理服務器140、客戶終端150和dns180的信息處理裝置的典型的硬件構造。中央處理單元(cpu)231執(zhí)行在只讀存儲器(rom)233的程序rom中存儲的程序或者從諸如硬盤(hd)的外部存儲器241加載到隨機存取存儲器(ram)232中的程序。程序的示例包括在計算機中運行的操作系統(os)以及應用。cpu231還控制連接到系統總線234的塊。通過執(zhí)行os來實現下面將要描述的序列的處理。ram232用作cpu231的主存儲器和工作區(qū)域。操作單元i/f235控制來自操作單元239的輸入。陰極射線管(crt)控制器(crtc)236控制crt顯示器240的顯示。盤控制器(dkc)237控制對存儲各種類型的數據的外部存儲器241(例如hd等)的數據訪問。網絡控制器(nc)238進行與經由wan100和/或lan101和/或102連接的服務器計算機和其他設備的通信控制處理。貫穿下面的所有描述，除非另有指定，否則執(zhí)行軟件的硬件代理是cpu231，軟件代理是安裝在外部存儲器241上的應用程序。在信息處理裝置中安裝和部署應用程序，并且cpu231執(zhí)行部署的應用程序以實現具有圖3中所示的軟件構造的系統環(huán)境。圖3是示出應用服務器110和120、分發(fā)服務器130、管理服務器140、客戶終端150和dns180的各自的軟件構造的圖。應用服務器110和120包括應用服務319。應用服務319包括web服務器模塊310和api模塊311。web服務器模塊310典型地使用jetty或者apachetomcat來分發(fā)html數據和javascript(注冊商標)并且/或者提供用于api模塊311的執(zhí)行環(huán)境。應用服務器110和120執(zhí)行web服務器模塊310以實現與http相關的處理。示例包括生成html格式的顯示畫面并向客戶終端150提供生成的顯示畫面。應用服務器110和120還執(zhí)行api模塊311以實現api處理。web服務器模塊310和api模塊311二者響應于對來自客戶的請求的處理請求的接收，進行各種類型的處理。分發(fā)服務器130包括分發(fā)服務330。分發(fā)服務330包括分發(fā)模塊331和分發(fā)設置332。分發(fā)模塊331基于客戶終端150在對分發(fā)服務器130的訪問中使用的統一資源定位符(url)，根據分發(fā)設置332確定客戶終端150對應用服務器110或120的訪問。下面將描述分發(fā)設置332的詳情。管理服務器140包括管理服務349。管理服務349包括程序管理模塊340、構建模塊341和部署模塊342。程序管理模塊340管理用于構建應用服務器110和120的系統環(huán)境的程序。構建模塊341將由程序管理模塊340管理的程序構建為可執(zhí)行模塊。部署模塊342將由構建模塊341生成的可執(zhí)行模塊部署到信息處理裝置，并且構建應用服務器110和120的系統構造以進行應用服務319的升級處理。dns180包括dns服務380。dns服務380基于ip地址設置381用ip地址應答名稱解析請求。下面將描述ip地址設置381的詳情。客戶終端150包括用于訪問應用服務器110和120的web瀏覽器350。圖4是示意性地示出根據本示例性實施例的客戶終端150訪問應用服務器110的通信路徑的圖。作為示例性實施例，應用服務器110包括分別提供不同服務的應用服務器401、402和403。在圖4中，將描述分發(fā)服務器(分發(fā)服務器系統)130的行為。向應用服務器401分配兩種類型的主機名“app1.local”和“appapi1.local”。類似地，應用服務器402具有主機名“app2.local”和“appapi2.local”。應用服務器403具有主機名“app3.local”和“appapi3.local”。分配兩種類型主機名的原因是將html請求與ap請求分開。下面將描述這種處理的詳情。分發(fā)服務器130具有主機名“www.example.com”。用戶將分配給分發(fā)服務器130的主機名和訪問路徑輸入到客戶終端150的web瀏覽器350中。url的示例是“https：//www.example.com/app1/login”。客戶終端150的web瀏覽器350向分發(fā)服務器130發(fā)出請求。接收請求的分發(fā)服務器130參照分發(fā)設置332并確定要將請求分發(fā)到的服務器(分發(fā)目的地)。將參照表1描述分發(fā)設置332的具體示例。在下面的設置中，對以“/app1”開頭的路徑的訪問被設置為傳輸到“https：//app1.local”服務器，并因此被傳輸到應用服務器401。對以“/appapi1”開頭的路徑的訪問被傳輸到“https：//appapi1.locald”服務器，并因此也被傳輸到應用服務器401。表1分發(fā)設置332路徑傳輸目的地url/app1*https：//app1.local/appapi1*https：//appapi1.local/app2*https：//app2.local/appapi2*https：//appapi2.local/app3*https：//app3.local/appapi3*https：//appapi3.local圖5是示出根據本示例性實施例的客戶終端150的web瀏覽器350從應用服務器110獲得畫面并執(zhí)行應用的處理的流程的序列圖。在步驟s501中，客戶終端150的web瀏覽器350發(fā)出html請求。在步驟s502中，接收html請求的分發(fā)服務器130基于被請求的url和分發(fā)設置332確定應用服務器110為分發(fā)目的地。如果客戶終端150通過包括以“/app1”開頭的路徑的url訪問分發(fā)服務器130，則確定“https：//app1.local”的應用服務器110為分發(fā)目的地。在步驟s503中，為向“https：//app1.local”發(fā)出請求，分發(fā)服務器130向dns180發(fā)送用于名稱解析的請求。dns180管理如表2所示的主機名和ip地址。在步驟s504中，dns180基于這樣的設置信息返回ip地址。如果主機名為“app1.local”，則dns180返回“192.168.0.1”。用于指定主機名的方法不限于本示例性實施例中的方法。可以向dns180發(fā)送包括在url中的主機名的一部分。主機名不一定包括域名。表2ip地址設置381在步驟s505中，獲得ip地址的分發(fā)服務器130向具有該ip地址的服務器發(fā)出針對html請求的處理請求。在步驟s506中，分發(fā)服務器130獲得html數據。在步驟s507中，分發(fā)服務器130向web瀏覽器350返回獲得的html數據。在步驟s511中，在顯示返回的html數據時，web瀏覽器350通過已寫入html數據的javascript(注冊商標)調用api。web瀏覽器350向與畫面上的url不同的url，諸如“https：//www.example.com/appapi1/v1/function1”做出api調用。在步驟s512中，如同對html請求一樣，接收作為api請求的api調用的分發(fā)服務器130確定分發(fā)目的地為“http：//appapi1.local”的應用服務器110。在步驟s513中，為向“http：//appapi1.local”發(fā)送針對api請求的處理請求，分發(fā)服務器130向dns180做出名稱解析的請求。在表2的示例中，“app1.local”和“appapi1.local”對應于相同的ip地址。在步驟s514中，dns180因此返回與步驟s504中相同的值。注意，可以改變設置值使得針對html請求而要被訪問的服務器與針對api調用而要被訪問的服務器不同。在步驟s515至s517的一系列處理中，分發(fā)服務器130向web瀏覽器350返回api的處理結果。在步驟s520中，web瀏覽器350基于步驟s517的api的處理結果顯示畫面。接下來，將參照圖6、圖7a、圖7b、圖7c、圖7d和圖7e描述在根據本示例性實施例的升級系統中，管理服務器140的部署模塊342從應用服務器110切換到應用服務器120的方法。圖6、圖7a、圖7b、圖7c、圖7d和圖7e示出用于將應用服務器110的應用服務319升級為在應用服務器120中部署的新版本的應用服務319的方法。圖6示出了由部署模塊342進行的升級處理的流程圖。圖7a、圖7b、圖7c、圖7d和圖7e各自示出升級處理期間的系統配置。當通過管理服務器140開始升級處理時，部署模塊342進行圖6中示出的一系列處理。在步驟s601中，為構造圖7a、圖7b、圖7c、圖7d和圖7e中示出的應用服務器701，部署模塊342初始配置一個或多個信息處理裝置。通常通過配置虛擬信息處理裝置實現藍綠部署。虛擬信息處理裝置是用于在信息處理裝置的硬件上生成多個虛擬信息處理裝置的技術。可以通過程序控制虛擬信息處理裝置的生成和刪除。例如，可以根據部署需要而生成許多虛擬信息處理裝置，并且可以在虛擬信息處理裝置上部署用于構成應用服務319的模塊，來構造應用服務器701。不再被需要的虛擬信息處理裝置可被立即刪除。這使得能夠快速容易地實現藍綠部署。本發(fā)明不限于虛擬信息處理裝置，并且可以通過一個或多個物理信息處理裝置來構造應用服務器701。在這種情況下，不進行步驟s601的處理，但是需要預先構造打算用于應用服務器701的信息處理裝置。然后對這樣的信息處理裝置進行轉換處理。在步驟s602中，部署模塊342進行模塊部署。部署模塊342在步驟s601中生成的信息處理裝置上部署web服務器模塊310和api模塊311。如果升級是期望的，則向web服務器模塊310添加新的html畫面。向api模塊311添加新的api。新的html畫面可以調用新的api。由此完成了圖7a中示出的應用服務器701的構造。在這個階段，僅將升級的應用服務器701添加到升級系統中。分發(fā)服務器130不向應用服務器701發(fā)送任何處理請求。在本示例性實施例中，dns180包括兩個dns，一級dns702和二級dns703。由于諸如可用性和性能等的原因，dns180一般包括多個dns而不是單個dns。一級dns702是主dns。二級dns703是與一級dns702的設置同步的子dns。對于名稱解析，分發(fā)服務器130可以使用一級dns702或者二級dns703來解析名稱。在這個階段，一級dns702的ip地址設置381包括“192.168.0.1”(應用服務器401的ip地址)，作為html主機設置和api主機設置。由于完成了一級dns702和二級dns703之間的同步，因此，二級dns703的ip地址設置381也包括“192.168.0.1”，作為html主機設置和api主機設置。在這個階段，如同升級之前，分發(fā)服務器130通過路徑711和712向應用服務器401發(fā)送用于請求的處理請求。在步驟s603中，部署模塊342進行針對api主機名的dns切換處理。更具體地，部署模塊342將為主機名“appapi1.local”設置的、與一級dns702中的api請求對應的當前的ip地址重寫為應用服務器701的ip地址的值“192.168.0.2”。圖7b是示出完成了直到步驟s603中的處理的狀態(tài)的框圖。在獲得html數據時，分發(fā)服務器130通過路徑711或712向應用服務器401發(fā)送用于請求的處理請求。在調用api時，如果在步驟s513中，一級dns702被用來進行名稱解析，則分發(fā)服務器130通過路徑713或714向應用服務器701發(fā)送用于請求的處理請求。如果在步驟s513中，二級dns703被用來進行名稱解析，則分發(fā)服務器130通過路徑711或712向應用服務器401發(fā)送用于請求的處理請求。在這個階段，向應用服務器401和701中的任一個發(fā)送api調用。調用哪個api根據請求而變化。由于應用服務器701包括與應用服務器401的api相同的api，所以可以處理在由應用服務器401提供的html數據中指定的api調用而不會出現問題。原因是只要考慮html主機的切換，則一級dns702和二級dns703二者均參照藍應用服務器401的ip地址。在客戶終端150上顯示的顯示畫面是不支持新api的顯示畫面。由于添加到應用服務器701的新html數據不提供給客戶終端150，所以不使用僅添加到應用服務器701的api。在步驟s604中，部署模塊342檢查一級dns702和二級dns703是否針對api主機名同步。更具體的，部署模塊342利用一級dns702和二級dns703進行“appapi1.local”的名稱解析，并確定是否從一級dns702和二級dns703中獲得了在步驟s604中設置的值“192.168.0.2”。如果獲得的值中的任一個是應用服務器401的ip地址“192.168.0.1”(步驟s604中的“否”)，則重復步驟s604。如果獲得的值是應用服務器701的ip地址“192.168.0.2”(步驟s604中的“是”)，則處理進行到步驟s605。如果dns180包括三個或更多個dns，則部署模塊342檢查除了ip地址已被重寫的dns之外的所有dns中的ip地址。圖7c是步驟s604的處理之后和步驟s605的處理開始之前的階段的框圖。二級dns703的ip地址設置381與一級dns702的ip地址設置381同步。在獲得html數據時，分發(fā)服務器130通過路徑711和712向應用服務器401傳輸請求。在調用api時，分發(fā)服務器130通過路徑713和714向應用服務器701發(fā)送所有請求。在步驟s605中，部署模塊342進行針對html主機名的dns切換處理。更具體地，部署模塊342將與一級dns702中的html請求對應的主機名“app1.local”的ip地址重寫為應用服務器701的ip地址的值，“192.168.0.2”。圖7d是示出完成了直到步驟s605的處理的狀態(tài)的框圖。在獲得html數據時，如果使用一級dns702進行步驟s503中的名稱解析，則分發(fā)服務器130通過路徑713或714將請求傳輸到應用服務器701。如果使用二級dns703進行步驟s503中的名稱解析，則分發(fā)服務器130通過路徑711或712將請求傳輸到應用服務器401。在這個階段，在獲得html數據時向應用服務器401和701的哪個部分發(fā)送請求，根據請求而變化。由于向應用服務器701傳輸全部的api調用，所以可以處理從應用服務器701獲得的新html數據中指定的api調用，而不出現問題。由此完成了部署模塊342的處理。經過一定時間之后，將二級dns703的ip地址設置381與一級dns702中的ip地址設置同步，并且將針對html主機名的ip地址設置為“192.168.0.2”。圖7e示出最終配置。在這個階段，分發(fā)服務器130通過路徑713和714將全部請求傳輸到應用服務器701。由此完成了應用服務319的升級處理。分別定義api主機名和html主機名，并且在進行針對html主機名的dns切換之前的一定時間間隔，完成針對api主機名的dns切換。這能夠防止從新系統的html畫面使用舊系統的api。作為該效果的示例，可以避免下列情形。假設在客戶終端150上顯示由升級后的新系統提供的html格式的畫面。從該畫面調用尚未升級的舊系統的api。換言之，通過dns名稱解析向新系統分發(fā)用于獲取畫面的請求，并通過dns名稱解析向舊系統分發(fā)用于經由畫面使用api的請求。在這種情況下，舊系統不包括用于由新系統提供的新功能的新api，并且來自客戶終端150的請求不能被適當地處理，并且不能向用戶返回期望的結果。在第一示例性實施例中，描述了分發(fā)服務器130每次通過dns180進行用于主機名名稱解析處理的步驟s503和s515。在這種情況下，由于向dns180發(fā)送用于名稱解析處理的大量請求，因此存在高負荷的問題。還存在這樣的問題，每次進行名稱解析相應地減小了整個系統的處理量。為此，可以設置分發(fā)服務器130將在步驟s504和s514中獲得的ip地址存儲一定時間段，并且，如果利用相同的主機名訪問，則重復使用前先獲得的ip地址而不進行步驟s503或s513中的處理。在這種情況下，存在這樣的時段，在該時段期間，分發(fā)服務器130不向dns180發(fā)送用于名稱解析的請求，并且通過使用先前獲得的ip地址進行名稱解析，盡管在步驟s604中完成了針對api主機名的dns同步。這會引起如下情形：當dns180已經被切換到關于顯示畫面的新系統時，分發(fā)服務器130沒有立即將訪問目的地的ip地址切換到新系統的ip地址。結果是，在一個分發(fā)服務器130可以根據通過dns180的名稱解析向新系統分發(fā)用于顯示畫面的請求的同時，另一分發(fā)服務器130使用舊系統的緩存ip地址向舊系統分發(fā)api請求。其原因是構成分發(fā)服務器130的服務器組在各自不同的定時存儲ip地址，并且直到新設置值反映在全部分發(fā)服務器130上存在時間間隔。因此，不能防止從新系統的html畫面使用舊系統的api的問題。第二示例性實施例描述了用于解決這種問題的方法。除非下面另有描述，否則第二示例性實施例與第一示例性實施例類似。圖8是示出根據本示例性實施例的由部署模塊342進行的升級處理的流程圖。步驟s601至s605與參照圖6描述的處理中的步驟s601至s605類似。在步驟s801中，部署模塊342以預定的等待時間進行等待處理。例如，如果將對分發(fā)服務器130的dns名稱解析的緩存時間設置為60秒，則在步驟s801中，部署模塊342空閑等待60秒或更久。在本示例性實施例中，假設進行了除緩存時間60秒外還有一定時間的等待處理。這確保分發(fā)服務器130的緩存被升級。在管理服務器140等待的同時，在所有分發(fā)服務器130內的用于dns名稱解析的緩存到期。隨著緩存到期，分發(fā)服務器130在步驟s513中發(fā)出名稱解析請求，從而獲得應用服務器701的ip地址。等待時間可以由用戶或者與分發(fā)服務器130通信的管理服務器140預先設置，以檢查緩存時間的設置。但是，這不是限制性的。本發(fā)明的示例性實施例的實質是：等待直到升級系統的所有分發(fā)服務器130中的緩存到期，并且分發(fā)服務器130準備好向dns180發(fā)出名稱解析請求。如上所述，即使分發(fā)服務器130包括用于名稱解析的緩存，也可以提供預定的等待時間以防止從新系統的hml畫面使用舊系統的api。第三示例性實施例描述了用于更可靠地解決問題的另一種方法。除非下面另有描述，否則第三示例性實施例與第一示例性實施例類似。圖9是示出根據本示例性實施例的由部署模塊342進行的升級處理的流程圖。步驟s601至s605與參照圖6描述的處理中的步驟s601至s605類似。在步驟s901中，部署模塊342進行訪問日志分析處理。應用服務器401一般輸出來自客戶終端150的所有html請求和api請求的、關于在何時訪問了哪個url路徑的日志。部署模塊342分析這類日志并確認，例如以路徑“/app1*”開頭的html畫面已被訪問，但是在一定時間段內沒有做出以路徑“/appapi1*”開頭的api調用。如果日志包括api請求在一定時間段內沒有做出這樣的api調用，則確認分發(fā)服務器130正在向應用服務器701發(fā)送用于api請求的處理請求。如上所述，盡管分發(fā)服務器130包括用于名稱解析的緩存，但是可以分析訪問日志以防止從新系統的html畫面使用舊系統的api。其他實施例還可以通過讀出并執(zhí)行記錄在存儲介質(也可更完整地稱為“非暫時性計算機可讀存儲介質”)上的計算機可執(zhí)行指令(例如，一個或更多個程序)以執(zhí)行上述實施例中的一個或更多個的功能、并且/或者包括用于執(zhí)行上述實施例中的一個或更多個的功能的一個或更多個電路(例如，專用集成電路(asic))的系統或裝置的計算機，來實現本發(fā)明的實施例，并且，可以利用通過由系統或裝置的計算機例如讀出并執(zhí)行來自存儲介質的計算機可執(zhí)行指令以執(zhí)行上述實施例中的一個或更多個的功能、并且/或者控制一個或更多個電路以執(zhí)行上述實施例中的一個或更多個的功能的方法，來實現本發(fā)明的實施例。計算機可以包括一個或更多個處理器(例如，中央處理單元(cpu)、微處理單元(mpu))，并且可以包括分開的計算機或分開的處理器的網絡，以讀出并執(zhí)行計算機可執(zhí)行指令。計算機可執(zhí)行指令可以例如從網絡或存儲介質被提供給計算機。存儲介質可以包括例如硬盤、隨機存取存儲器(ram)、只讀存儲器(rom)、分布式計算系統的存儲器、光盤(諸如壓縮光盤(cd)、數字通用光盤(dvd)或藍光光盤(bd)tm)、閃存裝置以及存儲卡等中的一個或更多個。本發(fā)明的實施例還可以通過如下的方法來實現，即，通過網絡或者各種存儲介質將執(zhí)行上述實施例的功能的軟件(程序)提供給系統或裝置，該系統或裝置的計算機或是中央處理單元(cpu)、微處理單元(mpu)讀出并執(zhí)行程序的方法。雖然已經參照示例性實施例對本發(fā)明進行了描述，但是應該理解，本發(fā)明不限于所公開的示例性實施例。應當對以下權利要求的范圍給予最寬的解釋，以使其涵蓋所有這些變型例以及等同的結構及功能。當前第1頁12