201030636 «» 六、發明說明： 【發明所屬之技術領域】 本發明關於網路服務領域’特別關於一種服務整合平 台系統及其提供網際網路服務的方法。 【先前技術】 隨著 SOA( Service-Oriented Architecture，服務導向 架構）的不斷成熟，REST ( Representati〇nai State Transfer，表述性狀態遷移）風格的資源調用深入人心， 使得 Open API ( Open Application Program Interface，開 放性應用編程介面）逐漸成爲網際網路新興資源。傳統的 網際網路軟體企業也開始嘗試新角色，作爲服務提供商更 加開放自身服務的資源，擴大自身資料的社會化作用，並 爲網站的發展提供了新的開放模式。Web 2.0時代的到來 ，也造就了許多利用網路服務資源的ISV ( Independent Software Vendor，獨立軟體供應商），他們針對客戶的需 求，將不同 ISP( Internet Service Provider，網際網路服 務提供商）提供的服務組合在一起，設計出豐富多樣的互 動式應用，並產生了聚合後的創新效應。 現在，一些大網站利用Open API吸引ISV針對這些 開放性的API來構建特色應用，帶來群體效應，用以豐富 自身應用，吸引用戶。 但現有技術的不足在於：現有的Open API模式都是 單ISP開放模式，即：由單一 ISP提供一整套服務發佈包 -5- 201030636 括安全，計費，監控等解決方案，該方式下顯然不利於小 型的ISP以及ISV參與利用網際網路路資源。 【發明內容】 本發明提供一種服務整合平台系統及提供網際網路服 務方法，用以解決現有技術中在IS V開發應用過程中，當 多個ISP存在時，對於非業務性功能需求，ISV與ISP都 需要進行多種不同的非業務性功能設計開發，以滿足各種 不同非業務性功能設計要求的問題。 本發明在實施中提供了一種服務整合平台系統，包括 認證模組，用於在至少一個獨立軟體供應商發起業務 請求時，對發起業務請求的獨立軟體供應商進行認證； 回應模組，用於在認證未通過時，對該獨立軟體供應 商的業務請求進行回應； 路由模組，用於認證通過後，將該獨立軟體供應商請 求的業務路由至提供該業務服務的網際網路服務提供商處 進行處理。 較佳地，該路由模組包括： 登錄判斷單元，用於判斷發起業務請求的獨立軟體供 應商請求的業務是否需要登錄； 登錄單元，用於在登錄判斷單元判斷爲需要登錄時， 根據該獨立軟體供應商的業務請求向提供該業務服務的網 際網路服務提供商發起登錄請求，並根據該網際網路服務 -6- 201030636 提供商的處理生成權杖； 轉發單元，用於在登錄判斷單元判斷爲不需要登錄時 ，向提供該業務服務的網際網路服務提供商轉發該獨立軟 體供應商的業務請求，並根據該網際網路服務提供商的處 理進行回應轉發。 較佳地，進一步包括： 記錄模組，用於對認證模組、回應模組、路由模組的 工作進行日誌記錄。 較佳地，進一步包括： 任務模組，用於對該日誌進行分析。 較佳地，進一步包括：監控模組和/或計費模組，其 中： 監控模組，用於根據該日誌分析進行監控； 計費模組，用於根據該日誌分析進行計費。 較佳地，進一步包括：201030636 «» VI. Description of the Invention: [Technical Field of the Invention] The present invention relates to the field of network services, particularly to a service integration platform system and a method thereof for providing internet service. [Prior Art] With the continuous maturity of SOA (Service-Oriented Architecture), REST (Representati〇nai State Transfer) style resource calls are deeply rooted in people's minds, making Open API (Open Application Program Interface, The open application programming interface has gradually become an emerging resource for the Internet. Traditional Internet software companies have also begun to try new roles as service providers to open up their own services, expand the socialization of their own materials, and provide a new open model for the development of the website. The advent of the Web 2.0 era has also created many ISVs (Independent Software Vendors) that use network service resources. They provide different ISPs (Internet Service Providers) for their needs. The services are combined to create a rich and varied interactive application and create an innovative effect after aggregation. Now, some big websites use the Open API to attract ISVs to build featured applications for these open APIs, bringing group effects to enrich their applications and attract users. However, the shortcoming of the prior art is that the existing Open API mode is a single ISP open mode, that is, a set of service release packages provided by a single ISP-5-201030636 includes security, billing, monitoring and other solutions, which is obviously disadvantageous. Participate in the use of Internet resources by small ISPs and ISVs. SUMMARY OF THE INVENTION The present invention provides a service integration platform system and a method for providing an internet service to solve the problem of non-service function when an ISISP exists in an IS V development application process in the prior art. ISPs need to perform a variety of different non-business functional design developments to meet the various non-business functional design requirements. The present invention provides a service integration platform system, including an authentication module, for authenticating an independent software provider that initiates a service request when at least one independent software provider initiates a service request; Responding to the service request of the independent software provider when the authentication fails; the routing module is configured to route the service requested by the independent software provider to the Internet service provider providing the service service after the authentication is passed Processing at the place. Preferably, the routing module includes: a login determining unit, configured to determine whether the service requested by the independent software provider that initiates the service request needs to log in; and a login unit, configured to: when the login determining unit determines that the login is required, according to the independent The software provider's service request initiates a login request to the Internet service provider that provides the service service, and generates a token according to the processing of the Internet service-6-201030636 provider; and a forwarding unit for the login determination unit When it is determined that the login is not required, the service request of the independent software provider is forwarded to the Internet service provider that provides the service service, and the response is forwarded according to the processing of the Internet service provider. Preferably, the method further includes: a recording module, configured to perform log recording on the operations of the authentication module, the response module, and the routing module. Preferably, the method further includes: a task module, configured to analyze the log. Preferably, the method further includes: a monitoring module and/or a charging module, wherein: the monitoring module is configured to perform monitoring according to the log analysis; and the charging module is configured to perform charging according to the log analysis. Preferably, the method further comprises:
SandBox模組，用於連接各ISP提供的SandBox; 測試請求處理模組，用於在至少一個1SV發起測試業 務請求時，將發起測試業務請求的ISV的測試業務透過該 SandBox模組連接至提供該測試業務服務的ISP提供的 SandBox 。 較佳地，進一步包括： 測試請求接收模組，用於在接收到至少一個獨立軟體 供應商發起測試業務請求時，觸發測試模組與測試路由模 組； -7- 201030636 測試模組，用於對發起測試業務請求的獨立軟體供應 商的調試系統流程進行測試； 測試路由模組，用於將該獨立軟體供應商請求的測試 業務路由至提供該測試業務服務的網際網路服務提供商處 進行應用介面測試。 較佳地，路由模組進一步用於該獨立軟體供應商在該 提供該測試業務服務的網際網路服務提供商處進行應用介 面測試完畢後，將該獨立軟體供應商測試完畢後的業務請 求路由至提供該業務服務的網際網路服務提供商處進行處 理。 較佳地，該認證模組進一步用於在該獨立軟體供應商 應用介面測試完畢後，根據該測試模組的調試系統流程測 試結果對該獨立軟體供應商發起的業務請求進行認證。 較佳地，進一步包括： 路由位址獲取模組，用於獲取各網際網路服務提供商 的應用介面測試位址與業務服務位址； 該測試路由模組進一步用於將該測試業務路由至提供 該測試業務服務的網際網路服務提供商處的應用介面測試 位址； 該路由模組進一步用於在應用介面測試完畢後，將該 獨立軟體供應商測試完畢後的業務請求路由至提供該業務 服務的網際網路服務提供商的業務服務位址。 較佳地，進一步包括： 服務文檔模組，用於向至少一個ISV提供各ISP的服 201030636 務說明文檔。 本發明實施中還提供了一種提供網際網路服務的方法 ，包括如下步驟： 在至少一個獨立軟體供應商發起業務請求時，對發起 業務請求的獨立軟體供應商進行認證； 在認證未通過時，對該獨立軟體供應商的業務請求進 行回應； Φ 在認證通過後，將該獨立軟體供應商請求的業務路由 至提供該業務服務的網際網路服務提供商處進行處理。 較佳地，該進行認證具體爲： 對發起業務請求的ISV的參數是否合法、服務是否存 在、是否需要簽名、是否有許可權、簽名是否有效、時間 戳是否過期、權杖是否有效之一或者其組合進行認證。 較佳地，該將該獨立軟體供應商請求的業務路由至提 供該業務服務的網際網路服務提供商處進行處理，具體爲 # 判斷發起業務請求的獨立軟體供應商請求的業務是否 需要登錄，是則根據該獨立軟體供應商的業務請求向提供 該業務服務的網際網路服務提供商發起登錄請求，並根據 該網際網路服務提供商的處理生成權杖，否則向提供該業 務服務的網際網路服務提供商轉發該獨立軟體供應商的業 務請求，並根據網際網路服務提供商的處理進行轉發回應 較佳地，進一步包括： 201030636 對該認證、回應、路由的工作過程進行日誌記錄。 較佳地，進一步包括： 對該日誌進行分析。 較佳地，進一步包括： 根據該日誌分析進行監控； 和/或， 根據該日誌分析進行計費。 較佳地，進一步包括： 連接各網際網路服務提供商提供的SandBox ; 在至少一個IS V發起測試業務請求時，將發起測試業 務請求的ISV的測試業務連接至提供該測試業務服務的 ISP 提供的 SandBox。 較佳地，進一步包括： 在接收到至少一個獨立軟體供應商發起的測試業務請 求時，對發起測試業務請求的獨立軟體供應商的調試系統 流程進行測試；且，將該獨立軟體供應商請求的測試業務 路由至提供該測試業務服務的網際網路服務提供商處進行 應用介面測試。 較佳地，進一步包括： 該獨立軟體供應商在該提供該測試業務服務的網際網 路服務提供商處進行應用介面測試完畢後，將該獨立軟體 供應商測試完畢後的業務請求路由至提供該業務服務的網 際網路服務提供商處進行處理。 較佳地，進一步包括： 201030636 在該獨立軟體供應商應用介面測試完畢後，根據調試 系統流程測試結果對該獨立軟體供應商發起的業務請求進 行認證。 較佳地，進一步包括： 獲取各網際網路服務提供商的應用介面測試位址與業 務服務位址； 將該測試業務路由至提供該測試業務服務的網際網路 φ 服務提供商處的應用介面測試位址； 在應用介面測試完畢後，將該獨立軟體供應商測試完 畢後的業務請求路由至提供該業務服務的網際網路服務提 供商的業務服務位址。 較佳地，進一步包括： 向至少一個獨立軟體供應商提供各網際網路服務提供 商的服務說明文檔。 本發明有益效果如下： 在本發明的服務整合平台系統中提供了對IS V請求進 行認證的認證模組，以及對ISV的業務請求進行回應的回 應模組，將ISV請求的業務路由至ISP的路由模組。從而 透過服務整合平台系統解決了對多方ISP的服務整合和路 由，使得ISP僅需關注於服務提供，無需考慮認證等非業 務性功能需求，也有效的降低了 ISV對多個ISP服務的學 習和接入門檻，簡化了 ISV的開發流程。 【實施方式】 -11 - 201030636 下面結合附圖對本發明的具體實施方式進行說明。 發明人在發明過程中注意到’在當前的單ISP開放模 式下，有如下不足： 1 )、從ISP角度來看： 當前的ISP往往都是有實力的大型網站，其自身就能 提供一套完整的Open API解決方案並組織實施。但中小 型的ISP由於品牌 '技術實力、客戶資源的欠缺，不可能 抽出精力來構造自己的開發者社區，因而無法得到很好的 @ 發展。 同時，Open API需要考慮許多非業務性需求，特別 是安全、監控、計費等方面，而這往往成爲Open API的 技術難點和瓶頸。 2 )、從ISV角度來看： 當前的ISV開發的應用往往只關注於某一個ISP的服 務，但當某一類應用在需要整合商品搜尋、物流支付、電 子地圖等多個ISP的服務時，在已有的模式下，ISV需要 春 付出許多額外的努力與多ISP進行開發，並且還在系統安 全、聯調和整合測試等環節面臨較高門檻。因此，當前常 規的單ISP開放模式，無法將不同的ISP服務整合產生的 聚合效應發揮出來，同時安全策略的不同，會使ISV關注 於一些非業務性的流程中，降低開發效率。 基於此，本發明實施例的服務整合平台系統就是將各 個ISP的服務整合到服務整合平台系統上’由服務整合平 台系統來實現統一的安全、計費、監控、路由等業務性功 -12- 201030636 能。同時對於IS V而言，透過統一的規範和標準，整合和 訪問服務平台上的服務，能大大降低整合異構服務體系的 開銷。下面對服務整合平台系統的實施進行說明。 圖1爲服務整合平台系統結構示意圖，如圖所示，在 服務整合平台系統中可以包括： 認證模組1 01，用於在至少一個isV發起業務請求時 ，對發起業務請求的ISV進行認證，在認證通過後觸發路 由模組，在認證未通過時觸發回應模組； 回應模組102，用於被認證模組觸發後，對發起業務 請求ISV的業務請求進行回應； 實施中，回應模組對業務進行的回應可以是對錯誤處 理後進行的回應，可以根據不同的錯誤資訊作不同的回應 ，例如需要用戶綁定就會回復對應的綁定用戶位址以及相 關資訊，如果是其他的參數交驗錯誤，則返回相關的提示 資訊。 路由模組103，用於被認證模組觸發後，將發起業務 請求的ISV請求的業務路由至提供該業務服務的ISP處理 〇 認證模組101在具體實施中可以對is V的參數是否合 法、服務是否存在、是否需要簽名、是否有許可權、簽名 是否有效、時間戳是否過期、權杖是否有效之一或者其組 合進行認證。 路由模組103在具體實施中可以包括：The SandBox module is configured to connect to the SandBox provided by each ISP; the test request processing module is configured to connect the test service of the ISV that initiates the test service request to the providing through the SandBox module when the at least one 1SV initiates the test service request Test the business service provided by the ISP of SandBox. Preferably, the method further includes: a test request receiving module, configured to trigger a test module and a test routing module when receiving at least one independent software provider to initiate a test service request; -7- 201030636 test module, used for Testing the debug system flow of the independent software vendor that initiated the test service request; testing the routing module for routing the test service requested by the independent software vendor to the Internet service provider providing the test service service Application interface testing. Preferably, the routing module is further used by the independent software provider to perform the application interface test at the Internet service provider that provides the test service service, and then route the service request after the independent software vendor is tested. Processed at the Internet service provider that provides the service. Preferably, the authentication module is further configured to authenticate the service request initiated by the independent software provider according to the debugging system flow test result of the test module after the independent software vendor application interface test is completed. Preferably, the method further includes: a routing address obtaining module, configured to obtain an application interface test address and a service service address of each Internet service provider; the test routing module is further configured to route the test service to An application interface test address of the Internet service provider that provides the test service service; the routing module is further configured to: after the application interface test is completed, routing the service request after the independent software vendor is tested to provide the The service service address of the Internet Service Provider for Business Services. Preferably, the method further includes: a service document module, configured to provide a service 201030636 service description document of each ISP to at least one ISV. The present invention also provides a method for providing an internet service, including the following steps: when at least one independent software provider initiates a service request, the independent software provider that initiates the service request is authenticated; when the authentication fails, Respond to the service request of the independent software vendor; Φ After the authentication is passed, the service requested by the independent software provider is routed to the Internet service provider that provides the service service for processing. Preferably, the performing the authentication is specifically: whether the parameter of the ISV that initiates the service request is legal, whether the service exists, whether the signature is required, whether the license is valid, whether the signature is valid, whether the time stamp expires, whether the token is valid, or The combination is certified. Preferably, the service requested by the independent software provider is routed to an Internet service provider that provides the service service, and specifically, # determines whether the service requested by the independent software provider that initiates the service request needs to log in, Is to initiate a login request to the Internet service provider that provides the service service according to the service request of the independent software provider, and generate a token according to the processing of the Internet service provider, otherwise the Internet is provided to the service service. The network service provider forwards the service request of the independent software provider and forwards the response according to the processing of the Internet service provider. The method further includes: 201030636 Logging the authentication, response, and routing work process. Preferably, the method further comprises: analyzing the log. Preferably, the method further comprises: performing monitoring according to the log analysis; and/or performing charging according to the log analysis. Preferably, the method further includes: connecting a SandBox provided by each Internet service provider; and when the at least one IS V initiates the test service request, connecting the test service of the ISV that initiates the test service request to the ISP providing the test service service SandBox. Preferably, the method further comprises: testing, when receiving the test service request initiated by the at least one independent software provider, the debugging system flow of the independent software provider that initiates the test service request; and requesting the independent software vendor The test service is routed to an application interface test at an internet service provider that provides the test service service. Preferably, the method further comprises: after the application software test is performed by the independent software provider at the Internet service provider that provides the test service service, routing the service request after the independent software vendor is tested to provide the The service is handled by the Internet service provider. Preferably, the method further comprises: 201030636 After the independent software vendor application interface test is completed, the service request initiated by the independent software vendor is authenticated according to the debugging system process test result. Preferably, the method further includes: obtaining an application interface test address and a service service address of each Internet service provider; routing the test service to an application interface of the Internet service provider providing the test service service Test address; After the application interface test is completed, the service request after the independent software vendor is tested is routed to the service service address of the Internet service provider that provides the service service. Preferably, the method further comprises: providing a service description document of each internet service provider to at least one independent software provider. The beneficial effects of the present invention are as follows: In the service integration platform system of the present invention, an authentication module for authenticating an IS V request and a response module for responding to an ISV service request are provided, and the service requested by the ISV is routed to the ISP. Routing module. Therefore, the service integration platform system solves the service integration and routing of the multi-party ISP, so that the ISP only needs to pay attention to the service provision, and does not need to consider the non-service function requirements such as authentication, and effectively reduces the learning of the ISV to multiple ISP services. The access threshold simplifies the ISV development process. [Embodiment] -11 - 201030636 A specific embodiment of the present invention will be described below with reference to the drawings. The inventor noticed in the process of invention that 'in the current single ISP open mode, there are the following shortcomings: 1) From the perspective of ISP: The current ISPs are often large websites with strong capabilities, which can provide a set of Complete Open API solution and organize implementation. However, small and medium-sized ISPs cannot extract their energy to construct their own developer community because of the lack of technical strength and customer resources, so they cannot get good development. At the same time, the Open API needs to consider many non-business requirements, especially security, monitoring, billing, etc., which often become the technical difficulties and bottlenecks of the Open API. 2) From the perspective of ISV: The current ISV development applications tend to focus only on the services of an ISP, but when a certain type of application needs to integrate the services of multiple ISPs such as commodity search, logistics payment, and electronic map, In the existing model, ISV needs a lot of extra effort to develop with multiple ISPs, and it also faces high thresholds in system security, joint debugging and integration testing. Therefore, the current single ISP open mode cannot bring out the aggregation effect generated by the integration of different ISP services. At the same time, the different security policies will make the ISV focus on some non-business processes and reduce the development efficiency. Based on this, the service integration platform system of the embodiment of the present invention integrates the services of each ISP into the service integration platform system. The service integration platform system implements unified security, billing, monitoring, routing and other service functions. 201030636 Yes. At the same time, for IS V, integrating and accessing services on the service platform through unified specifications and standards can greatly reduce the overhead of integrating heterogeneous service systems. The implementation of the service integration platform system is described below. FIG. 1 is a schematic structural diagram of a service integration platform system. As shown in the figure, the service integration platform system may include: an authentication module 01, configured to authenticate an ISV that initiates a service request when at least one isV initiates a service request, After the authentication is passed, the routing module is triggered, and the response module is triggered when the authentication fails; the response module 102 is configured to respond to the service request for initiating the service request ISV after being triggered by the authentication module; The response to the service may be a response to the error processing, and may respond differently according to different error information. For example, if the user binds, the corresponding binding user address and related information are returned, and if other parameters are If the error is submitted, the relevant prompt information will be returned. The routing module 103, after being triggered by the authentication module, routes the service of the ISV requesting the service request to the ISP that provides the service service, and the authentication module 101 can determine whether the parameters of the is V are valid in the specific implementation. Whether the service exists, whether it needs to be signed, whether there is permission, whether the signature is valid, whether the timestamp is expired, whether the token is valid, or a combination thereof for authentication. The routing module 103 may include:
登錄判斷單元1031，用於判斷發起業務請求的1SV -13- 201030636 請求的業務是否需要登錄，是則觸發登錄單元1032，否 則觸發轉發單元1 03 3 ; 登錄單元1032，用於根據發起業務請求的ISV的業 務請求向提供該業務服務的ISP發起登錄請求，並根據 ISP的處理生成權杖； 轉發單元1 03 3，用於向提供該業務服務的ISP轉發 發起業務請求的ISV的業務請求，並根據ISP的處理進行 回應轉發。 進一步的，服務整合平台系統中還可以包括： 記錄模組1〇4，用於對認證模組101、回應模組102 、路由模組103的工作進行日誌記錄。 進一步的，服務整合平台系統中還可以包括： 任務模組105,與記錄模組104相連，用於對記錄模 組記錄的日誌進行分析。 進一步的，服務整合平台系統中還可以包括：與任務 模組105相連的監控模組106和/或計費模組107，其中 監控模組1 06，用於根據任務模組的日誌分析進行監 控： 計費模組1 07，用於根據任務模組的日誌分析進行計 費。 考慮到ISV的應用測試階段的服務，進一步的，服務 整合平台系統中還可以包括：SandBox模組108，用於連 接各ISP提供的SandBox，SandBox是軟體測試中的一個 201030636 常用術語’一般本領域技術人員會將其稱爲測試沙箱環境 ’ Sandbox原字面意思即爲兒童遊戲用的沙坑，類似遊戲 床’兒童可以在其中安全的進行遊戲，類似於軟體可以在 SandBox環境中安全的進行測試； 測試請求處理模組109，用於在至少一個ISV發起測 試業務請求時，將發起測試業務請求的ISV的測試業務透 過該SandBox模組連接至提供該測試業務服務的ISP提供 的 SandBox 。 進一步的，服務整合平台系統中還可以包括：服務文 檔模組1 10，用於向ISV提供ISP的服務說明文檔。 圖2爲含服務整合平台系統的應用環境示意圖，本圖 可以更直觀的描述本系統與環境的關係，實施中，服務整 合平台系統以 SIP (Service Integration Platform，服務互 聯平台）爲基礎進行構建，SIP分別連接ISV與ISP，具 體連接時可以透過網際網路，或者別的網路形式進行連接 。則如圖2所示，用以示意的ISV在圖中由兩台EndUser (終端用戶）及ISV APP (ISV Application，獨立軟體發 展商應用）構成；用以示意的ISP由兩台API server ( API伺服器）構成；ISV應用可以爲普通的網際網路應用 ，也可以是用戶端桌面應用，例如透過HTTP ( HyperText Transfer Protocol，超文件傳送協定）訪問就可以和SIP 建立起交互通道，而SIP和ISP之間也是可以透過HTTP 的方式建立連接，但是在實際應用時考慮到安全等因素， 可以使用 SSL ( Secure Socket Layer，安全套接層）對 -15- 201030636 HTTP來做安全保證或者透過專線方式來做安全保證。在 SIP的服務部署中，SIP硬體方面可以主要包括了兩部分 :API Route Server (應用編程介面路由伺服器）和定時 任務伺服器。即’具體可以將服務整合平台系統的認證模 組、回應模組、路由模組、記錄模組佈置在API Route Server上，由其主要處理服務路由以及安全認證的功能， 同時還可以由記錄模組將對伺服器的訪問記錄直接作爲曰 誌保存在本地。在定時任務伺服器上則可以佈置服務整合 @ 平台系統的定時任務模組，由該伺服器負責收集日誌後， 非同步並行分析日誌，然後由監控模組、計費模組等功能 模組使用，圖2中示出了計費模組，並將其佈置在計費 DB( DataBase，資料庫）上。 按以上佈置後，實施中，API Route Server可以統一 處理安全、認證和訪問記錄，對ISV身份進行驗證、對用 戶身份進行驗證、對服務調用進行回應、對服務調用進行 統計。計費DB則可對支持免費、包月計費、按次計費、 ❹ 按流量計費的多種形式計費。 由圖2可見，由終端用戶（EndUser)發起登錄請求 後 ’ ISV APP 分發請求；API Route Server 呼叫 ISP 的 API server (應用編程介面伺服器），轉發登錄請求，並 接收生成的Token等。在SIP內部定時任務伺服器則採集 曰誌進行分析並提供給計費DB使用。實施中，獨立軟體 發展商應用主要是根據ISP提供的一些基礎性介面獲取資 料’或者獲取計算結果來設計滿足用戶需求的應用。 -16- 201030636 對於生成的Token，Token實施中可以視爲是一種身 份權杖’當用戶登錄以後，就可以將用戶在ISV的系統中 的身份和SIP中的身份關聯起來；在每次請求中，在ISV 體系中的用戶身份都可以對應到某一個已經產生的SIP的 身份權杖，SIP即認爲有權杖的ISV應用使用者有許可權 去操作ISP的用戶相關資訊。 由上述實施可見，在SIP裏實施本發明的服務整合平 Φ 台系統後’便提供了 ISP和ISV之間資料互聯互通的載體 。在這個平台系統上，IS P的資源和服務在開放的環境中 可以深度整合和充分融合，可以爲IS V接入第三方服務， 快速接入軟體互聯平台提供便利，SIP同時還爲ISP提供 完整的安全、計費、授權的統一策略，ISP可以在SIP完 成對自有服務即時監控、發佈、測試、路由等管理工作， 從而產生更高的商業價値。 對於至少一個發起測試業務請求的ISV，本發明還提 Φ 供了一種提供測試服務的實施方式，可以實現基於服務整 合平台系統開發應用時測試和正式環境的無縫對接，下面 對具體的實施方式進行說明》 圖3爲提供測試功能的另一服務整合平台系統結構示 意圖，如圖所示，系統中除上述系統中包括的認證模組 101、路由模組103、回應模組102等功能模組以外，針 對ISV的測試應用還可以包括： 測試請求接收模組3 0 1，用於在接收到至少一個獨立 軟體供應商發起測試業務請求時，觸發測試模組與測試路 -17- 201030636 由模組； 測試模組3 02 ’用於對發起測試業務請求的獨立軟體 供應商的調試系統流程進行測試； 測試路由模組303，用於將該獨立軟體供應商請求的 測試業務路由至提供該測試業務服務的網際網路服務提供 商處進行應用介面測試。 路由模組103在該方案中還可以進一步用於：當發起 測試業務請求的ISV在提供該測試業務服務的ISP處進行 應用介面測試完畢後，將該ISV測試完畢後的業務請求路 由至提供該業務服務的ISP處進行處理。 認證模組1 〇 1則還可以進一步用於：在發起測試業務 請求的ISV應用介面測試完畢後，根據測試模組302的調 試系統流程測試結果對該ISV發起的業務請求進行認證。 在該系統中還可以進一步包括： 路由位址獲取模組304，用於獲取各ISP的應用介面 測試位址與業務服務位址； 則，測試路由模組3 03進一步用於將測試業務路由至 提供該測試業務服務的ISP處的應用介面測試位址； 路由模組103進一步用於在應用介面測試完畢後，將 該ISV測試完畢後的業務請求路由至提供該業務服務的 ISP的業務服務位址。 實施中，系統可以進一步包括：服務文檔模組110, 用於向至少一個ISV提供各ISP的服務說明文檔。 作爲服務整合平台系統，需要提供給ISV測試和正式 201030636 兩套環境，作爲IS V開發應用使用，並且還要求服務整合 平台系統對兩種開發環境都有很高的統一性；因爲，作爲 ISV開發來說，如果在雨個開發環境中變更和差別比較大 的話，那麼就勢必會使得測試的效果降低，無法真正模擬 真實環境，從而增加了正式上線風險。因此需要建立一套 服務測試以及發佈的無縫體系，以盡可能減少服務測試和 發佈的修改內容，實現服務測試開發的平滑過渡。 如果將服務整合平台系統和ISP提供的測試環境以及 正式環境獨立部署和整合的話，那麼IS V的應用開發過程 中相關的業務資料就會在不同的兩個環境中相互隔離，這 樣不僅增加了 ISV的開發成本，同時對於類似應用身份標 示、應用私鑰等固有資料也都會有正式和測試兩份，對於 開發者來說開發成本以及測試成本無疑會增加，同時也增 加了正式上線的風險。 爲了實現共用ISV測試和正式環境業務資料，減少資 料重複創建成本，同時類比相同業務和系統資料保證開發 過程和發佈過程中資料一致性，降低因爲資料改變而帶來 的風險。實施中可以透過應用本身選擇性路由以及硬體位 址的不同來區分測試和正式環境。具體的，如圖4的ISV 開發中測試、應用的實施流程示意圖所示，可以包括如下 步驟= 步驟401、ISP註冊服務資訊，包括服務正式接入 URI ( Universal Resource Identifier，統一資源標識）和 服務測試接入URI。 -19- 201030636 步驟402、ISV透過服務整合平台系統測試環境申請 應用註冊。 步驟403、ISV根據服務整合平台系統提供的ISP服 務開發文檔，開發應用，並對接服務整合平台系統測試環 境進行測試。 步驟404 ' ISV應用透過服務整合平台系統路由到服 務測試URI進行測試。 步驟405、ISV應用透過測試驗收，提交應用正式發 佈申請。 步驟406、ISV應用切換到服務整合平台系統正式環 境，正式發佈應用。 從上述流程中可以看到，ISV在測試過程中完全模擬 正式環境，同時切換到正式環境基本沒有任何代價，僅需 要改變服務整合平台系統請求的入口位址，最大限度地利 用了測試環境中的資料，同時最小成本的切換到了正式環 境，降低ISV開發複雜度和成本，降低了因爲資料改變而 引起的應用缺陷的發生機率》 上述實施的機理在於，服務整合平台系統提供了服務 正式接入URI和服務測試接入URI。ISV透過服務整合平 台系統路由到服務測試URI進行測試。ISV應用透過測試 驗收後，切換到服務整合平台系統正式環境正式發佈應用 ’具體可以透過改變服務整合平台系統請求入口位址爲服 務正式接入URI來實現。 由於IS V開發應用關於最主要的是調試系統流程和應 201030636 用介面’調試系統流程中包括了安全計費等平台控制流程 ，服務整合平台系統會頒發安全相關的認證配置用於正式 測試共用’而ISV在開發過程中只需要調試通過即可以保 證正式環境的正常；至於業務方面的介面調試，僅僅只需 要類比介面業務參數，看是否返回正常資料即可，業務參 數中事實上是沒有共用內容的，因爲暴露的服務都是無狀 態服務，傳遞的參數本身可以自描述和自包含。所以在開 Φ 發、測試過程中，發佈的資料共用主要在於平台級別資料 ’即調試系統流程資料的共用，而業務級的資料，即應用 介面調試資料不共用。可見，透過共用ISV測試和正式環 境業務資料，因而減少了資料重複創建，以及保持了開發 、發佈的資料一致性的。 對於ISP來說，在保證兩個位址下連接的環境彼此一 致時’兩個位址下的環境可以是一個，也可以分成兩個， 這個是由ISP自己決定，兩個環境是否共用資料或者資料 φ 隔離也可以由ISP自己決定。只要ISP保證兩個環境的業 務介面邏輯保持一致即可。 對於ISV來說，在測試中，安全，計費，監控等平台 級別的調試和正常模式下完全一致，而業務性的介面調試 透過ISP對於兩個環境的服務一致性來保證，因此實現了 ISV在測試過程中完全模擬正式環境的效果。當然在ISV 的應用在上正式環境之前，還需要在正式環境作預發佈作 測試，保證其可用性。 可見，透過上述的方式便可以最大限度的複用isV開 -21 - 201030636 發應用的業務資料，降低由於資料不同造成應用上線風險 ，實現測試和正式環境無縫對接。 本發明還提供了一種提供網際網路服務的方法，下面 結合附圖對該方法的實施進行說明。 圖5爲提供網際網路服務的方法實施流程示意圖，如 圖所示，可以包括如下步驟： 步驟501、在至少一個ISV發起業務請求時，對發起 業務請求的ISV進行認證； ^ 步驟502、在認證未通過時，對發起業務請求的ISV 的業務請求進行回應； 步驟503、在認證通過後，將發起業務請求的ISV請 求的業務路由至提供該業務服務的ISP處進行處理。 進一步的，實施中還可以包括： 對實施中的認證、回應、路由的工作過程進行日誌記 錄； 對日誌記錄進行分析； @ 在對該日誌進行記錄並進行分析後，便可以進一步的 用於根據該日誌分析進行監控、根據該日誌分析進行計費 等。 下面對各步驟的具體實施進行說明。 步驟501中，進行認證具體可以包括： 對發起業務請求的ISV的參數是否合法、服務是否存 在、是否需要簽名、是否有許可權、簽名是否有效、時間 戳是否過期、權杖是否有效之一或者其組合進行認證。 -22- 201030636 步驟503中，將該ISV請求的業務路由至提供該業務 服務的ISP處進行處理，具體可以包括： 判斷發起業務請求的IS V請求的業務是否需要登錄， 是則根據該ISV的業務請求向提供該業務服務的ISP發起 登錄請求，並根據該ISP的處理生成權杖，否則向提供該 業務服務的ISP轉發該ISV的業務請求，並根據ISP的處 理進行轉發回應。 圖6爲服務整合平台系統的認證、路由實施流程示意 圖，如圖所示，在進行認證、路由時，具體可以包括如下 步驟： 步驟601、ISV發起業務請求； 步驟602、判斷參數是否合法，是則轉入步驟603， 否則轉入步驟6 1 0 ; 步驟603、判斷服務是否存在，是則轉入步驟604， 否則轉入步驟6 1 0 ; 步驟604、判斷是否需要簽名，是則轉入步驟605， 否則轉入步驟6 1 2 ; 步驟605、判斷是否有許可權，是則轉入步驟606, 否則轉入步驟610 ; 步驟606、判斷簽名是否有效，是則轉入步驟607, 否則轉入步驟6 1 0 ; 步驟607、判斷時間戳是否過期，是則轉入步驟608 ，否則轉入步驟6 1 0 ; 步驟608、判斷TOKEN是否有效，是則轉入步驟609 -23- 201030636 ，否則轉入步驟6 1 0 ; 步驟609、判斷是否需要登錄，是則轉入步驟 否則轉入步驟6 1 2 ; 步驟610、對ISV的業務請求進行回應； 步驟611、根據ISV的業務請求向ISP發起登 * 步驟612、向ISP轉發ISV的業務請求。 下面對ISV的應用開發流程實施進行說明。 爲了實現IS V的應用開發，還可以進一步包括 服務文檔模組向ISV提供ISP的服務說明文檔 在具體應用開發時，可以進一步包括：The login determining unit 1031 is configured to determine whether the service requested by the 1SV-13-201030636 requesting the service request needs to be logged in. If yes, the login unit 1032 is triggered. Otherwise, the forwarding unit 1033 is triggered. The login unit 1032 is configured to initiate the service request according to the request. The service request of the ISV initiates a login request to the ISP that provides the service service, and generates a token according to the processing of the ISP; the forwarding unit 1300 is configured to forward the service request of the ISV that initiates the service request to the ISP that provides the service service, and The response is forwarded according to the processing of the ISP. Further, the service integration platform system may further include: a recording module 1-4 for logging the work of the authentication module 101, the response module 102, and the routing module 103. Further, the service integration platform system may further include: a task module 105, connected to the recording module 104, configured to analyze logs recorded by the recording module. Further, the service integration platform system may further include: a monitoring module 106 and/or a charging module 107 connected to the task module 105, wherein the monitoring module 106 is configured to monitor according to log analysis of the task module. The billing module 107 is configured to perform billing according to log analysis of the task module. In consideration of the service testing phase of the ISV, the service integration platform system may further include: a SandBox module 108 for connecting SandBox provided by each ISP, and the SandBox is a 201030636 in the software test. The technicians will call it the test sandbox environment. 'Sandbox literally means bunker for children's games, similar to the game bed' where children can play safely, similar to software can be safely tested in the SandBox environment. The test request processing module 109 is configured to connect, when the at least one ISV initiates the test service request, the test service of the ISV that initiates the test service request to the SandBox provided by the ISP that provides the test service service through the SandBox module. Further, the service integration platform system may further include: a service document module 1 10, configured to provide an ISV service description document to the ISV. Figure 2 is a schematic diagram of an application environment with a service integration platform system. This figure can more intuitively describe the relationship between the system and the environment. In the implementation, the service integration platform system is built on the basis of SIP (Service Integration Platform). SIP is connected to ISV and ISP respectively. When connecting, you can connect through the Internet or other network. As shown in Figure 2, the ISV used for the illustration is composed of two EndUsers (end users) and ISV APP (ISV Application, independent software developer application); the ISP used to indicate is composed of two API servers (API). The server can be configured as an ordinary Internet application or a client-side desktop application. For example, an HTTP (HyperText Transfer Protocol) access can establish an interactive channel with SIP, and SIP and ISPs can also establish connections through HTTP. However, in consideration of security and other factors in practical applications, SSL (Secure Socket Layer) can be used to secure -15-201030636 HTTP or to use a dedicated line. Do a security guarantee. In the SIP service deployment, the SIP hardware aspect can mainly include two parts: API Route Server (application programming interface routing server) and timing task server. That is to say, the authentication module, the response module, the routing module and the recording module of the service integration platform system can be arranged on the API Route Server, which mainly processes the functions of service routing and security authentication, and can also be recorded by the module. The group saves the access record of the server directly as a local record. On the timed task server, the timed task module of the service integration@platform system can be arranged. After the server is responsible for collecting the log, the asynchronous parallel analysis log is used, and then the function module such as the monitoring module and the charging module is used. The billing module is shown in FIG. 2 and arranged on a billing DB (DataBase). After the above arrangement, in the implementation, the API Route Server can uniformly process security, authentication and access records, verify the ISV identity, verify the user identity, respond to the service call, and count the service calls. The billing DB can be charged in various forms such as support for free, monthly billing, pay-per-view, and billing. As can be seen from Figure 2, the end user (EndUser) initiates the login request after the 'ISV APP distribution request; the API Route Server calls the ISP's API server (application programming interface server), forwards the login request, and receives the generated token. In the SIP internal timed task server, the collection is analyzed and provided to the billing DB. In the implementation, the independent software developer application mainly obtains the information based on some basic interfaces provided by the ISP or obtains the calculation result to design the application that meets the user's needs. -16- 201030636 For the generated Token, the token implementation can be regarded as an identity token. When the user logs in, the identity of the user in the ISV system can be associated with the identity in the SIP; in each request The user identity in the ISV system can correspond to the identity token of an already generated SIP. SIP considers that the ISV application user who has the right stick has the permission to operate the user information of the ISP. It can be seen from the above implementation that the implementation of the service integration platform system of the present invention in SIP provides a carrier for data interconnection between the ISP and the ISV. On this platform system, IS P resources and services can be deeply integrated and fully integrated in an open environment. It can provide IS V access to third-party services and facilitate access to software interconnection platforms. SIP also provides complete ISPs. The unified strategy of security, billing, and authorization allows the ISP to complete the management of real-time monitoring, release, testing, and routing of its own services in SIP, thereby generating higher commercial prices. For at least one ISV that initiates a test service request, the present invention also provides an implementation method for providing a test service, which can realize a seamless connection between the test and the formal environment when the application is integrated based on the service integration platform system, and the following specific implementation FIG. 3 is a schematic structural diagram of another service integration platform system that provides a test function. As shown in the figure, in addition to the functional modules of the authentication module 101, the routing module 103, and the response module 102 included in the system. In addition to the group, the test application for the ISV may further include: a test request receiving module 301 for triggering the test module and the test road -17-201030636 when receiving at least one independent software vendor to initiate a test service request The module; the test module 3 02 ' is used to test the debugging system flow of the independent software provider that initiates the test service request; the test routing module 303 is configured to route the test service requested by the independent software provider to provide the Application interface testing is performed at the Internet service provider that tests the business service. The routing module 103 may be further configured to: when the ISV that initiates the test service request performs the application interface test at the ISP that provides the test service service, routing the service request after the ISV test is completed to provide the The ISP at the business service processes it. The authentication module 1 〇 1 can be further used to: after the ISV application interface test of the test service request is completed, the service request initiated by the ISV is authenticated according to the test system process test result of the test module 302. The system further includes: a routing address obtaining module 304, configured to obtain an application interface test address and a service service address of each ISP; then, the test routing module 303 is further configured to route the test service to Providing an application interface test address of the ISP at the test service service; the routing module 103 is further configured to: after the application interface test is completed, routing the service request after the ISV test is completed to the service service bit of the ISP providing the service service site. In an implementation, the system may further include: a service document module 110, configured to provide a service description document of each ISP to at least one ISV. As a service integration platform system, it needs to be provided to ISV testing and official 201030636 environment, as IS V development application, and also requires service integration platform system to have high uniformity for both development environments; because, as ISV development In the case of changes and differences in the rain development environment, it will inevitably reduce the effectiveness of the test and not really simulate the real environment, thus increasing the risk of formal launch. Therefore, it is necessary to establish a seamless system of service testing and release to minimize the modification of service testing and release, and to achieve a smooth transition of service testing development. If the service integration platform system and the test environment provided by the ISP and the formal environment are independently deployed and integrated, the relevant business data in the IS V application development process will be isolated from each other in different environments, thus not only increasing the ISV. The development cost, as well as the intrinsic data such as application identity and application private key, will be officially and tested. For developers, development costs and test costs will undoubtedly increase, and the risk of formal launch will also increase. In order to achieve shared ISV testing and formal environmental business data, the cost of data duplication is reduced, and the same business and system data are compared to ensure data consistency during the development process and release process, reducing the risk caused by data changes. In practice, the test and formal environment can be distinguished by the application's own selective routing and the difference in hardware addresses. Specifically, as shown in the schematic diagram of the implementation process of the test and application in the ISV development of FIG. 4, the following steps may be included: Step 401: ISP registration service information, including a service official access identifier (Universal Resource Identifier) and a service Test the access URI. -19- 201030636 Step 402, ISV applies for application registration through the service integration platform system test environment. Step 403: The ISV develops an application according to the ISP service development document provided by the service integration platform system, and tests the system test environment of the docking service integration platform. Step 404 'The ISV application is routed through the service integration platform system to the service test URI for testing. In step 405, the ISV application submits an application for formal application through the test and acceptance. In step 406, the ISV application switches to the formal environment of the service integration platform system, and the application is officially released. As can be seen from the above process, the ISV completely simulates the formal environment during the test process, and there is basically no cost to switch to the formal environment. It only needs to change the entry address of the service integration platform system request, and maximize the use of the test environment. Data, while the minimum cost is switched to the formal environment, reducing the complexity and cost of ISV development, and reducing the probability of application defects caused by data changes. The mechanism of the above implementation is that the service integration platform system provides the service official access URI. And the service test access URI. The ISV is routed through the service integration platform system to the service test URI for testing. After the ISV application passes the test acceptance, it switches to the formal integration environment of the service integration platform system to officially release the application. Specifically, it can be implemented by changing the service integration platform system request entry address to the service official access URI. Since the IS V development application is mainly about debugging system processes and the platform control process including the secure billing in the 201030636 interface system, the service integration platform system will issue security-related authentication configurations for formal test sharing. In the development process, the ISV only needs to be debugged to ensure the normal environment. As for the interface debugging of the business, only the analog interface business parameters are needed to see whether the normal data is returned. In fact, there is no shared content in the business parameters. Because exposed services are stateless services, the passed parameters themselves can be self-describing and self-contained. Therefore, in the process of opening and testing, the data sharing is mainly based on the sharing of platform-level data, that is, the debugging system process data, while the business-level data, that is, the application interface debugging data, is not shared. It can be seen that by sharing ISV testing and formal environmental business data, it reduces the duplication of data creation and maintains the consistency of development and release of data. For the ISP, when ensuring that the environments connected under the two addresses are consistent with each other, the environment under the two addresses can be one or two. This is determined by the ISP itself. Whether the two environments share data or The data φ isolation can also be determined by the ISP itself. As long as the ISP guarantees that the business interface logic of the two environments is consistent. For the ISV, during the test, the platform level debugging of security, billing, monitoring, etc. is exactly the same as in the normal mode, and the business interface debugging is guaranteed by the ISP's service consistency for the two environments, thus implementing the ISV. The effects of the formal environment are fully simulated during the test. Of course, before the ISV application is in the formal environment, it needs to be pre-released for testing in the formal environment to ensure its availability. It can be seen that through the above-mentioned methods, the business data of the application of the isV can be maximized, and the application online risk is reduced due to different data, and the test and the formal environment are seamlessly connected. The present invention also provides a method of providing internet service, which will be described below with reference to the accompanying drawings. 5 is a schematic diagram of a method for implementing an Internet service. As shown in the figure, the method may include the following steps: Step 501: When at least one ISV initiates a service request, the ISV that initiates the service request is authenticated; ^ Step 502: When the authentication fails, the service request of the ISV that initiates the service request is responded. Step 503: After the authentication is passed, the service that requests the ISV requesting the service request is routed to the ISP that provides the service service for processing. Further, the implementation may further include: logging the working process of the authentication, response, and routing in the implementation; analyzing the log record; @ after recording and analyzing the log, the file may be further used according to The log analysis is monitored, and billing is performed based on the log analysis. The specific implementation of each step will be described below. In step 501, performing the authentication may specifically include: whether the parameter of the ISV that initiates the service request is legal, whether the service exists, whether the signature is required, whether the license is valid, whether the signature is valid, whether the timestamp is expired, whether the token is valid, or The combination is certified. -22- 201030636 In step 503, the service requested by the ISV is routed to the ISP that provides the service service, and the method may include: determining whether the service requested by the IS V that initiates the service request needs to log in, and according to the ISV The service request initiates a login request to the ISP that provides the service service, and generates a token according to the processing of the ISP. Otherwise, the ISP that provides the service service forwards the service request of the ISV, and forwards the response according to the processing of the ISP. Figure 6 is a schematic diagram of the authentication and routing implementation process of the service integration platform system. As shown in the figure, when performing authentication and routing, the method may include the following steps: Step 601: The ISV initiates a service request. Step 602: Determine whether the parameter is legal. Then, go to step 603, otherwise go to step 6 1 0; step 603, determine whether the service exists, if yes, go to step 604, otherwise go to step 6 1 0; step 604, determine whether signature is required, then go to step 605, otherwise go to step 6 1 2; Step 605, determine whether there is permission, if yes, go to step 606, otherwise go to step 610; Step 606, determine whether the signature is valid, then go to step 607, otherwise go to Step 6 1 0; Step 607, determining whether the timestamp is expired, if yes, go to step 608, otherwise go to step 6 1 0; Step 608, determine whether TOKEN is valid, then go to step 609 -23-201030636, otherwise turn In step 610, step 609, it is determined whether the login is required, if yes, the process proceeds to step 6 1 2; in step 610, the service request of the ISV is responded; Step 611, according to the service of the ISV * ISP to initiate a registration step 612, forwards the request to the ISV business ISP. The following describes the implementation of the ISV application development process. In order to implement the application development of the IS V, the service document module may further be provided with an ISP service description document to the ISV. In specific application development, the method may further include:
SandBox模組連接ISP提供的SandBox; 測試請求處理模組根據接收的ISV測試業務請 ISV的測試業務透過該SandBox模組連接至ISP SandBox 〇 具體實施中，ISV可以首先在服務整合平台系 請創建應用，服務整合平台系統可以頒發應用身份 應用密鎗。 ISV可以在服務文檔模組提供的服務文檔說明 各個ISP的服務說明文檔。 服務整合平台系統根據ISV的服務訪問級別來 要使用的ISP服務。 在開發並測試應用中，ISV透過服務整合平台The SandBox module is connected to the SandBox provided by the ISP; the test request processing module requests the ISV test service to connect to the ISP SandBox through the SandBox module according to the received ISV test service. In the specific implementation, the ISV can first create an application in the service integration platform. The service integration platform system can issue an application identity application gun. The ISV can describe the service documentation for each ISP in the service documentation provided by the Service Document Module. The service integration platform system uses the ISP service to be used according to the service access level of the ISV. ISV through service integration platform in developing and testing applications
SandBox環境連接到各個ISP的SandBox。 61 1 J 錄請求 求，將 提供的 統上申 Id和 中獲取 申請需 系統的 201030636 測試後ISV便可以發佈應用，在服務整合平台系統提 交應用上架申請。 下面以在SIP中的實施來說明，圖7爲在SIP中進行 應用開發的實施流程示意圖，如圖所示，可以按如下步驟 實施： 步驟701、ISV註冊應用申請； 步驟702、SIP頒發應用身份、應用密鎗； 步驟703、ISV開發應用； 步驟704、ISV獲取ISP服務說明文檔； 步驟705、ISV定制需要審核的API ; 步驟706、SIP向ISP提交審核； 步驟707、ISP進行審核； 步驟708、審核通過後，SIP記錄審批結果； 步驟709、ISV進行測試應用； 步驟710、ISV發佈應用； 步驟711、SIP將應用審核上架。 按以上流程進行應用開發實施後，服務整合平台系統 便可以爲ISV快速接入和交付服務，簡化了服務整合和管 理，提供了通用的安全、計費、驗證策略，並透過統一的 Sandbox驗證環境，從而爲Java、.NET、PHP等異構系統 提供了簡約、標準化的接入解決方案。 對於至少一個發起測試業務請求的ISV，本發明還提 供了一種提供測試服務的實施方式，可以實現IS V開發應 用時測試和正式環境的無縫對接，下面對具體的實施方式 -25- 201030636 進行說明。 在接收到至少一個1sv發起的測試業務請求時，對發 起測試業務請求的I s V的調試系統流程進行測試；且’將 該ISV請求的測試業務路由至提供該測試業務服務的ISP 處進行應用介面測試。 進一步的，爲了處理測試完畢後的流程，還可以包括 ISV在該提供該測試業務服務的ISP處進行應用介面 測試完畢後，將該ISV測試完畢後的業務請求路由至提供 該業務服務的ISP處進行處理。 該方案下，還可以進一步包括： 在ISV應用介面測試完畢後，根據調試系統流程測試 結果對該ISV發起的業務請求進行認證。 在實施上述方案時，可以進一步包括： 獲取各ISP的應用介面測試位址與業務服務位址； 將該測試業務路由至提供該測試業務服務的ISP處的 應用介面測試位址； 在應用介面測試完畢後，將該ISV測試完畢後的業務 請求路由至提供該業務服務的ISP的業務服務位址。 由上述實施可以看出，透過服務整合平台系統著重解 決了多方ISP的服務整合和路由，使得ISP關注於服務提 供，無需考慮安全，計費，監控等非業務性功能需求，有 效降低ISV對多個ISP服務的學習和接入門檻，簡化開發 流程。 -26- 201030636 從ISP來看，能夠支援新型ISP的產生，此類ISP會 基於底層服務提供商的服務再次開發和封裝，並將開發的 服務發佈在服務整合平台上。 從ISV來看，服務整合平台系統爲面向開發者的 Open API社區打造基礎的服務接入和管理平台，使得isV 和個人開發者能夠在系統中檢索、學習、調用、測試符合 自己應用場景的ISP提供的API。 φ 從而使得服務整合平台系統不僅能夠讓ISP專注於資 料服務設計，也能讓ISV專注於應用/產品的開發。使服 務能夠在開放、協同、統一的環境中，使ISP與ISV應用 更靈活、高效得融合，擴大了整個生態圈的社會化價値。 進一步的，還會由於大型的ISP以外的，更多的中小型的 ISP加入，而使網際網路服務真正成爲開發者的豐富資源 庫。 進一步的，透過對調試系統流程和應用介面兩部分測 Φ 試的分離處理，即在服務整合平台系統上處理與調試系統 流程相關的測試，並共用該部分資料；而將應用介面部分 的測試交由各ISP處理，從而還可以實現最小成本的切換 到正式環境，降低ISV開發複雜度和成本，降低了因爲資 料改變而引起的應用缺陷的發生機率。 顯然，本領域的技術人員可以對本發明進行各種改動 和變型而不脫離本發明的精神和範圍。這樣，倘若本發明 的這些修改和變型屬於本發明申請專利範圍第及其等同技 術的範圍之內，則本發明也意圖包含這些改動和變型在內 -27- 201030636 【圖式簡單說明】 圖1爲本發明實施例中該服務整合平台系統結構示意The SandBox environment is connected to the SandBox of each ISP. 61 1 J Record Requests, will provide the application for the application and the application for the system 201030636 After the test, the ISV can publish the application and submit the application for application on the service integration platform system. The following is a description of the implementation in the SIP. FIG. 7 is a schematic diagram of an implementation process of application development in SIP. As shown in the figure, the following steps may be implemented: Step 701: The ISV registers an application application; Step 702: SIP issues an application identity. Step 703: The ISV develops the application; Step 704: The ISV obtains the ISP service description document; Step 705: The ISV customizes the API to be audited; Step 706, the SIP submits the audit to the ISP; Step 707, the ISP performs the audit; Step 708 After the audit is passed, the SIP records the approval result; Step 709, the ISV performs the test application; Step 710, the ISV issues the application; Step 711, the SIP app reviews the application. After the application development and implementation according to the above process, the service integration platform system can provide ISV fast access and delivery services, simplify service integration and management, provide a common security, billing, verification strategy, and through a unified Sandbox authentication environment. To provide a simple, standardized access solution for heterogeneous systems such as Java, .NET, and PHP. For at least one ISV that initiates a test service request, the present invention also provides an implementation manner for providing a test service, which can implement a seamless connection between the test and the formal environment when the IS V is developed and applied, and the following specific implementation mode-25-201030636 Be explained. When receiving at least one test service request initiated by the 1sv, testing the debugging system flow of the Is V that initiates the test service request; and 'routing the test service requested by the ISV to the ISP providing the test service service Interface test. Further, in order to process the process after the test is completed, the ISV may further include the service request after the ISV test is completed to the ISP that provides the service service after the application interface test is performed by the ISV that provides the test service service. Process it. The solution may further include: after the ISV application interface test is completed, the service request initiated by the ISV is authenticated according to the debugging system process test result. In the implementation of the foregoing solution, the method may further include: acquiring an application interface test address and a service service address of each ISP; routing the test service to an application interface test address of the ISP that provides the test service service; After the completion, the service request after the ISV test is completed is routed to the service service address of the ISP that provides the service service. It can be seen from the above implementation that the service integration platform system focuses on the service integration and routing of the multi-party ISP, so that the ISP pays attention to the service provision, without considering the non-service function requirements such as security, billing, monitoring, etc., effectively reducing the ISV to many The learning and access thresholds of ISP services simplify the development process. -26- 201030636 From the perspective of ISP, it can support the emergence of new ISPs, which will be re-developed and packaged based on the services of the underlying service providers, and the services developed will be released on the service integration platform. From the perspective of ISV, the service integration platform system provides a basic service access and management platform for the developer's Open API community, enabling isV and individual developers to retrieve, learn, invoke, and test ISPs that match their application scenarios in the system. The API provided. φ thus allows the service integration platform system to not only allow ISPs to focus on data service design, but also enable ISVs to focus on application/product development. The service enables ISPs and ISV applications to be more flexible and efficient in an open, collaborative, and unified environment, expanding the social price of the entire ecosystem. Further, due to the addition of large and small ISPs, more small and medium-sized ISPs will make Internet services truly become a rich resource for developers. Further, through the separation process of the debugging system process and the application interface, the test related to the debugging system process is processed on the service integration platform system, and the part of the data is shared; and the test of the application interface part is handed over. It is handled by each ISP, which can also achieve the minimum cost switching to the formal environment, reduce the complexity and cost of ISV development, and reduce the probability of application defects caused by data changes. It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention are within the scope of the present invention and the equivalents thereof, the present invention is also intended to include such modifications and variations. -27- 201030636 [Simplified Schematic] Figure 1 The structure of the service integration platform system in the embodiment of the present invention is schematic
Ib| · 圖， 圖2爲本發明實施例中該含服務整合平台系統的應用 環境示意圖； 圖3爲本發明實施例中該提供測試功能的另一服務整 合平台系統結構不意圖； 圖4爲本發明實施例中該ISV開發中測試、應用的實 施流程示意圖； 圖5爲本發明實施例中該提供網際網路服務的方法實 施流程示意圖； 圖6爲本發明實施例中該服務整合平台系統的認證、 路由實施流程示意圖； 圖7爲本發明實施例中該在SIP中進行應用開發的實 施流程示意圖。 【主要元件符號說明】 1 〇 1 :認證模組 1〇2 :回應模組 103 :路由模組 103 1 :登錄判斷單元 1 032 :登錄單元 201030636 1 03 3 :轉發單元 104 :記錄模組 105 :任務模組 106 :監控模組 107 :計費模組 108: SandBox 模組 109 :測試請求處理模組 1 1 〇 :服務文檔模組 3 0 1 :測試請求接收模組 3 02 :測試模組 3 03 :測試路由模組 3 04 :路由位址獲取模組FIG. 2 is a schematic diagram of an application environment of the service integration platform system according to an embodiment of the present invention; FIG. 3 is a schematic diagram of another service integration platform system structure for providing a test function according to an embodiment of the present invention; FIG. 5 is a schematic flowchart of a method for implementing an Internet service in an embodiment of the present invention; FIG. 6 is a schematic diagram of a method for implementing an Internet service in an embodiment of the present invention; FIG. 6 is a schematic diagram of a service integration platform system according to an embodiment of the present invention; Schematic diagram of the authentication and routing implementation process; FIG. 7 is a schematic flowchart of the implementation process of the application development in the SIP according to the embodiment of the present invention. [Main component symbol description] 1 〇1: Authentication module 1〇2: Response module 103: Routing module 103 1 : Login judgment unit 1 032 : Login unit 201030636 1 03 3 : Forwarding unit 104: Recording module 105: Task module 106: monitoring module 107: billing module 108: SandBox module 109: test request processing module 1 1 服务: service document module 3 0 1 : test request receiving module 3 02 : test module 3 03: Test Routing Module 3 04: Routing Address Acquisition Module
-29-29