專利名稱：用于自動(dòng)軟件配置的請求調(diào)度程序的制作方法
技術(shù)領(lǐng)域：
本發(fā)明與在用戶位置使軟件適用于需求設(shè)置的領(lǐng)域相關(guān)聯(lián)。尤其，它關(guān)系到內(nèi)部相互依存的資源的自動(dòng)管理，甚至關(guān)系到軟件程序的自動(dòng)配置。
本發(fā)明覆蓋了較廣的應(yīng)用領(lǐng)域。其基本概念能成功地被用于解決管理資源并行請求的問題--對這些資源的利用在一定程度上影響其它資源的可利用性。為大量請求者所分享的資源之間的相互依賴性就是一個(gè)例子。而且，許多涉及到計(jì)算機(jī)環(huán)境的問題也能得到解決，尤其，在大量資源需求被要求由單一設(shè)備--即系統(tǒng)管理器--滿足的情況下，并且當(dāng)為滿足該需求而完成地工作相當(dāng)復(fù)雜時(shí)。其復(fù)雜度可能基于大量不同的原因，例如，滿足一個(gè)需求時(shí)可能影響到一個(gè)或多個(gè)其它的需求，并引起標(biāo)準(zhǔn)質(zhì)量和數(shù)量的變化?；蛘?，如執(zhí)行所謂撤消(UNDO)操作的困難-即要恢復(fù)在某些需求被滿足之前所處于的狀態(tài)。
潛在應(yīng)用的一個(gè)例子是這樣的管理隊(duì)列，其中資源存取被以下面的方式管理排隊(duì)處理過程以優(yōu)化方式實(shí)現(xiàn)，尤其當(dāng)要求一個(gè)過程完成后再處理另一個(gè)過程時(shí)。
然而，應(yīng)用的一個(gè)特殊領(lǐng)域在于軟件程序的配置和/或用戶化。軟件這一術(shù)語中明確包含各種類型的軟件，即應(yīng)用程序，中間設(shè)備，和操作系統(tǒng)程序。這一應(yīng)用領(lǐng)域--尤其是應(yīng)用程序--在這里被用于討論現(xiàn)有技術(shù)及其相關(guān)的缺點(diǎn)。
通常，一種硬件系統(tǒng)，例如個(gè)人計(jì)算機(jī)、工作站或主機(jī)，被設(shè)計(jì)并計(jì)劃要能容納不止一種商業(yè)應(yīng)用程序。
一般地，邏輯或物理系統(tǒng)資源，如用戶ID、TCP/IP地址或不同的外圍設(shè)備如打印機(jī)、繪圖儀等，被這些程序以分享的方式使用。這樣，通常這種程序必需被用戶化，即使其適用于終端用戶位置上的普遍環(huán)境。這就要求執(zhí)行對使用中的計(jì)算機(jī)的操作系統(tǒng)所應(yīng)用的系統(tǒng)變量進(jìn)行設(shè)置。然而，不同的應(yīng)用程序可能要求不同的系統(tǒng)變量設(shè)置。因?yàn)橐蕾囉诒粻砍兜降南到y(tǒng)變量的類型，所以錯(cuò)誤的設(shè)置可能破壞基礎(chǔ)的計(jì)算機(jī)硬件的正確操作，并最終引起對不應(yīng)受干擾的商業(yè)操作程序異常中斷。
依賴于使用的硬件類型，系統(tǒng)變量的數(shù)量范圍可能從具有現(xiàn)行操作系統(tǒng)的PC機(jī)中的幾百個(gè)到群集主機(jī)系統(tǒng)的系統(tǒng)環(huán)境中所定義的幾十萬個(gè)。因此，僅僅系統(tǒng)變量的數(shù)目就能導(dǎo)致某種復(fù)雜性的存在。
現(xiàn)有技術(shù)中，主機(jī)自動(dòng)用戶化，例如IBM OS/90產(chǎn)品，是不可行的。因此，系統(tǒng)管理員必需手動(dòng)用戶化產(chǎn)品--有時(shí)借助于特定的實(shí)用程序，這既不需要詳細(xì)的了解操作系統(tǒng)的基本組成如何，也不需要了解通常形成操作系統(tǒng)與一個(gè)或多個(gè)應(yīng)用程序之間的中間層的所謂中間設(shè)備產(chǎn)品。上面所提到的系統(tǒng)變量特定設(shè)置之間的相互依賴性可能很復(fù)雜，而保持對所牽扯的問題的整體了解的方法是獨(dú)立的--由系統(tǒng)管理員操作的獨(dú)立性所決定。因而，配置和/或用戶化應(yīng)用程序的任務(wù)是十分困難的。
對于其它的平臺如Windows98或Windows NT，有腳本驅(qū)動(dòng)用戶化過程，如InstallShield。這些腳本被提供以便防止終端用戶動(dòng)手做這些事。這些腳本與這些應(yīng)用程序一起被提供以便能以成功地啟動(dòng)和使用這些程序的方式用戶化計(jì)算機(jī)資源。
這一方法的缺點(diǎn)在于腳本中被執(zhí)行的所有步驟必須由很了解操作系統(tǒng)細(xì)節(jié)的應(yīng)用程序程序員編程。將他們結(jié)合到在一個(gè)腳本中的過程也限制了可靠性和可用性，尤其在由于遺漏細(xì)節(jié)出現(xiàn)失敗的情況下。
因此，本發(fā)明的一個(gè)目的是提供一種方法和系統(tǒng)，使用這種方法和系統(tǒng)，所有以共同管理單元為目標(biāo)的大量并行資源需求可以以一種改進(jìn)的方式被管理，例如，以減少系統(tǒng)管理員參與的方式。
進(jìn)一步的目的是提供能用于自動(dòng)配置和/或用戶化應(yīng)用程序的方法和系統(tǒng)。
本發(fā)明的目的由附在后面的獨(dú)立權(quán)利要求中所陳述的特征實(shí)現(xiàn)。發(fā)明地更為有利的裝置和實(shí)施例在各個(gè)從屬權(quán)利要求中提出。
為了提高說明的清晰度，為了確切地確定本發(fā)明的范圍這些術(shù)語，這里使用的一些特定的術(shù)語被定義本發(fā)明使用到各種類型的軟件上，即應(yīng)用程序、中間設(shè)備和操作系統(tǒng)軟件。
上面提到的使用大量系統(tǒng)資源的任何程序在這里被稱為開發(fā)器產(chǎn)品或開發(fā)器(例如應(yīng)用程序)，因?yàn)樗褂孟到y(tǒng)資源開發(fā)新軟件。
系統(tǒng)資源的支持器應(yīng)理解為一種管理系統(tǒng)資源的程序方法。應(yīng)理解為它包括大量有關(guān)如何恰當(dāng)?shù)靥幚硖囟ㄏ到y(tǒng)資源的知識。當(dāng)系統(tǒng)資源的管理相當(dāng)復(fù)雜時(shí)，這些知識包括對管理資源不同方面的各子任務(wù)的了解和控制。
術(shù)語“連接”應(yīng)在一定意義下理解為用戶化開發(fā)器產(chǎn)品使其可用時(shí)對操作系統(tǒng)中必須被改變的資源的更新。
廣義上講，請求調(diào)度過程的發(fā)明概念能夠用于支持任何類型的支持器維護(hù)的資源的自動(dòng)管理。尤其，它能更具優(yōu)勢地被用于系統(tǒng)管理和軟件產(chǎn)品的用戶化。
根據(jù)其大體上的各方面，發(fā)明方法包括下列步驟存取包括請求的資源庫--各請求定義了一個(gè)應(yīng)被執(zhí)行的動(dòng)作，或一個(gè)應(yīng)達(dá)到的與某一資源相關(guān)的一種預(yù)期狀態(tài)；重新組織這些請求；調(diào)用管理程序方法的資源以用于處理一系列請求。然而，根據(jù)這些請求，支持器執(zhí)行對資源的實(shí)際處理。
自動(dòng)管理基本上包括重新組織這些在某種意義上被要求、被附隨等的請求，并調(diào)用管理程序的資源，即上述提到的支持器，用于處理該請求的服務(wù)。應(yīng)了解到運(yùn)行請求時(shí)觸發(fā)的動(dòng)作變化范圍很廣。
可以提出請求以要求提供其基本的功能內(nèi)容和結(jié)構(gòu)由被討論的計(jì)算機(jī)系統(tǒng)維護(hù)和控制的任何服務(wù)。例如更新文件、在安全數(shù)據(jù)庫中創(chuàng)建用戶ID。更一般的例子如從數(shù)據(jù)庫搜集信息并將結(jié)果寫入資源庫中，調(diào)用其它的軟件程序，觸發(fā)其它硬件設(shè)備以實(shí)現(xiàn)特定的功能性(如通電話)，或啟動(dòng)產(chǎn)品設(shè)備。
上面提到的第二個(gè)問題的解決方法由通過所謂的請求定義而表達(dá)用戶化需求的方法定義，這一請求定義說明了啟動(dòng)開發(fā)器產(chǎn)品時(shí)而必需建立的操作系統(tǒng)資源的資源狀態(tài)。
為了達(dá)到這一目標(biāo)，根據(jù)本發(fā)明的一個(gè)方面，執(zhí)行軟件需要邏輯上通過觸發(fā)各程序執(zhí)行用戶化和/或配置，以便確保資源被要求的狀態(tài)得到設(shè)置，其中各程序?qū)μ囟ǖ牟僮飨到y(tǒng)資源負(fù)責(zé)，例如，如UNIX操作系統(tǒng)目錄中包含的傳統(tǒng)配置文件。
觸發(fā)軟件形成發(fā)明概念的基本部分，在這里被稱為請求調(diào)度程序。被觸發(fā)程序被稱為支持器或支持器程序。
用于配置支持應(yīng)用程序的自動(dòng)配置的本發(fā)明的基本原則是在資源庫中請求被完全具體化，例如包括用戶特定環(huán)境信息的基于LDAP(簡便目錄存取協(xié)議)的目錄。
請求調(diào)度程序和支持器程序在驅(qū)動(dòng)系統(tǒng)中運(yùn)行以更新目標(biāo)系統(tǒng)中的資源，目標(biāo)系統(tǒng)在某種特殊情況下可以是驅(qū)動(dòng)系統(tǒng)本身。例如，如果有Windows用戶在驅(qū)動(dòng)系統(tǒng)中運(yùn)行請求調(diào)度程序，可能觸發(fā)支持器程序更新局域網(wǎng)服務(wù)器(目標(biāo)系統(tǒng))上的資源。在特殊情況中，當(dāng)驅(qū)動(dòng)系統(tǒng)等同于目標(biāo)系統(tǒng)時(shí)，例如，請求調(diào)動(dòng)程序運(yùn)行在如Windows用戶上，因此會(huì)更新Windows用戶上的資源。
在現(xiàn)有技術(shù)中，上面提到的腳本說明何種功能性應(yīng)被執(zhí)行。這暗示了應(yīng)用程序程序員必須在這一領(lǐng)域具有較高的技術(shù)水平。此程序員必須了解如何運(yùn)用操作系統(tǒng)資源以滿足無問題并且不與其它程序沖突運(yùn)行程序需要的前提。
與上面的相比，發(fā)明的程序工具即“請求調(diào)度程序”形式下的發(fā)明方法會(huì)引發(fā)能夠說明開發(fā)器產(chǎn)品預(yù)期先決條件是什么的開發(fā)器請求。根據(jù)本發(fā)明，如何在操作系統(tǒng)中實(shí)現(xiàn)的問題可通過交付實(shí)現(xiàn)的支持器程序得到解決，結(jié)果會(huì)改變由發(fā)明的請求調(diào)度程序驅(qū)動(dòng)的被需求資源。
因此，請求調(diào)度程序的執(zhí)行基于與傳統(tǒng)的腳本處理過程不同的模式腳本說明了做什么以及怎樣做以設(shè)置特定的資源狀態(tài)，但是發(fā)明的請求說明定義出哪種資源狀態(tài)是要求的(僅說明目的而未說明實(shí)現(xiàn)途徑)，因此與寫腳本相比請求更易于指定。這樣，開發(fā)器產(chǎn)品的程序員不需要了解更多的操作系統(tǒng)的特定知識，其次配置和用戶化開發(fā)器產(chǎn)品的工作對于終端用戶隱藏起來了。
總結(jié)本發(fā)明所包括的大致方面，下面的基本條目反映了發(fā)明的請求調(diào)度程序的各獨(dú)立方面。這些基本條目被列如下1．請求調(diào)度程序定義了結(jié)構(gòu)接口，支持器程序必須使用該接口獲得與請求調(diào)度程序通信的統(tǒng)一方式。這樣確保了可擴(kuò)展性，在某種意義上新支持器程序能插接到請求調(diào)度程序上而并不改變請求程序的代碼。
2．請求從資源庫中被讀取并根據(jù)靜態(tài)順序關(guān)系被存儲，靜態(tài)順序關(guān)系定義了支持器將被請求調(diào)用程序調(diào)用時(shí)所遵循的序列。根據(jù)用于說明哪個(gè)請求應(yīng)先于其自身被執(zhí)行的請求前趨屬性，由請求調(diào)用程序?qū)崿F(xiàn)排序。當(dāng)開發(fā)器具有對多個(gè)支持器的請求時(shí)，這一靜態(tài)支持器順序關(guān)系使得為所有請求調(diào)用各個(gè)支持器成為可能，這樣提高了性能。根據(jù)前趨屬性，請求排序允許定義相互依賴的請求的執(zhí)行序列。
3．各支持器獲取經(jīng)排序的請求鏈，這對更新被說明的資源狀態(tài)負(fù)責(zé)。
根據(jù)資源狀態(tài)說明，支持器更新資源對開發(fā)器和產(chǎn)品用戶隱藏了實(shí)現(xiàn)細(xì)節(jié)。開發(fā)器不必?fù)?dān)心如何實(shí)現(xiàn)他們產(chǎn)品中操作系統(tǒng)的特定前提，而相反，他們僅需定義這些前提是什么。
4．資源庫中說明的請求可能屬于不同的開發(fā)器產(chǎn)品，即請求調(diào)度程序能配置更多的開發(fā)器產(chǎn)品并將其調(diào)度到相應(yīng)的支持器上。因此，各支持器的請求鏈可能包含不同開發(fā)器的請求。發(fā)明的請求調(diào)度程序的實(shí)現(xiàn)是靈活的，在某種意義上不同的開發(fā)器產(chǎn)品可以同時(shí)得到配置。
5．支持器程序的一個(gè)已被熟知的特征是其“冪等性”。
基于這一術(shù)語，應(yīng)當(dāng)了解該支持器控制其自身負(fù)責(zé)的資源，支持器可以被多次調(diào)用，而且由于冪等性的原因，支持器知道是否有些東西改變與否。支持器冪等性的這一特征被進(jìn)一步開發(fā)，與請求調(diào)度過程的發(fā)明概念相結(jié)合。這使得請求調(diào)度程序更為強(qiáng)壯并隱藏了實(shí)現(xiàn)細(xì)節(jié)。
6．請求調(diào)度程序允許支持器產(chǎn)生子請求，尤其在為了改進(jìn)現(xiàn)存請求時(shí)。這利用在下面將進(jìn)一步說明的EVALUATE(評估)功能性實(shí)現(xiàn)。通過產(chǎn)生子請求而改進(jìn)請求時(shí)允許更容易地具體化和壓縮請求定義。依據(jù)應(yīng)被配置的特定系統(tǒng)，支持器利用此機(jī)制，通過生成對BIND(連接)步驟中實(shí)現(xiàn)的子目標(biāo)負(fù)責(zé)的新請求，使請求更加細(xì)化。更進(jìn)一步地，它允許將更新功能性部分分派給其它支持器。
7．通過使請求調(diào)度程序登錄機(jī)制可用于協(xié)議執(zhí)行流程并可用于說明支持器能做些什么，請求調(diào)度程序才能使支持器在“SIMULATE”(模擬)模式下運(yùn)行。這意味著模擬過程并不更新資源，但任何支持器都在登錄文件中說明當(dāng)SIMULATE(模擬)模式關(guān)閉時(shí)--即現(xiàn)實(shí)已被模擬--已經(jīng)做了些什么。請求的這種模擬允許支持器在登錄文件中擬定在不真正更新資源的情況下應(yīng)完成何種工作，例如，如果安全管理員不想自動(dòng)的執(zhí)行改變，他可以模擬資源改變，然后檢測登錄文件中哪些動(dòng)作已被自動(dòng)地完成了。然后他可以決定要自動(dòng)還是手動(dòng)完成這些動(dòng)作，或者根本不更新資源狀態(tài)。
8．更新資源，即用下面說明的請求調(diào)度程序選項(xiàng)BIND(連接)來實(shí)現(xiàn)驅(qū)動(dòng)，與資源的激活相分隔開有利。因此，對于在“BIND”(連接)步驟中由支持器生成的激活請求的執(zhí)行，請求調(diào)度程序具有ACTIVATION(激活)功能性。BIND(連接)和ACTIVATE(激活)間相分離的發(fā)明特征并不迫使用戶在一步中同時(shí)完成它們。因此，對于系統(tǒng)管理員來說如果首先檢測資源更新更為有利的話，他可以先檢測，晚一些時(shí)候再激活它們。另一個(gè)優(yōu)點(diǎn)就是兩個(gè)彼此不相關(guān)的不同時(shí)刻可以用來完成此兩項(xiàng)任務(wù)。
9．“UNBIND(拆分)實(shí)現(xiàn)”的發(fā)明特征，依據(jù)上面提到的“BIND”(連接)中使用的靜態(tài)順序關(guān)系和請求的前趨排序，將按相反的順序觸發(fā)具有逆向請求改變的支持器。因而，“UNBIND”(拆分)是一個(gè)重要的功能，能自動(dòng)逆轉(zhuǎn)資源改變而不需要將逆轉(zhuǎn)具體化為一個(gè)新的請求。來自“BIND“(連接)功能的請求將被使用，逆轉(zhuǎn)實(shí)現(xiàn)將自動(dòng)地被執(zhí)行。這樣，系統(tǒng)管理員的工作得到減輕。
10．請求調(diào)度程序在調(diào)用各帶有“BIND”(連接)的任何支持器之前要調(diào)用各帶有“CHECK_BIND”(檢驗(yàn)連接)的支持器。在CHECK_BIND(檢驗(yàn)連接)期間，任何支持器有機(jī)會(huì)在其被再次調(diào)用以真正地執(zhí)行BIND(連接)--即更新資源之前能檢測其前提條件。根據(jù)本發(fā)明的優(yōu)選特征，在執(zhí)行CHECK_BIND(檢測連接)之前，要檢測是否被請求的最小支持器版本已被安裝。如果已安裝，支持器將被調(diào)用，否則版本不匹配的信息將被寫入到登錄文件中，請求調(diào)度程序終止。這一過程同樣適用在“ACTIVATE”(CHECK_BIND(檢測激活))過程中。
在調(diào)用帶有BIND(連接)功能的支持器之前調(diào)用帶有CHECK_BIND(檢測連接)功能的各個(gè)支持器能夠確保只有當(dāng)所有支持器能無誤的實(shí)現(xiàn)更新時(shí)才執(zhí)行真正的資源更新。這樣提高了這種復(fù)雜操作的可靠性，因?yàn)樵贐IND(連接)過程中降低了出錯(cuò)的風(fēng)險(xiǎn)。版本不匹配檢測運(yùn)算法則也是一種品質(zhì)改進(jìn)，因?yàn)樵诂F(xiàn)有技術(shù)系統(tǒng)中這些版本不匹配不能系統(tǒng)化地被檢測出來，只是在運(yùn)行期間出現(xiàn)在基礎(chǔ)的參數(shù)層次上的不匹配除外，而這是很難于辨別出的。
11．支持器能確定支持什么樣的功能性，例如，如果不需要激活請求生成，那么請求調(diào)度程序?qū)⒉粸锳CTIVATE(激活)功能調(diào)用這種支持器，支持器實(shí)現(xiàn)這種類型的功能性將在支持器的服務(wù)說明中被具體明確，即作為具有“supportType”(支持類型)屬性的資源庫的一部分，并因此該功能可通過存取資源庫從請求調(diào)度程序中存取。由請求調(diào)度程序支持的其它功能性，如初始化--這里稱為PRIME，如果不能由特定請求調(diào)度程序功能性的支持器程序設(shè)計(jì)提供，那么能夠被開或關(guān)。處理“supportType”(支持類型)屬性能夠防止對不能實(shí)現(xiàn)特定類型功能性的支持器的不必要的調(diào)用。這樣提高了性能。
12．在用戶化過程中，終端用戶將從請求調(diào)度程序的執(zhí)行中獲利，尤其對于現(xiàn)有技術(shù)IBM OS/390系統(tǒng)，因?yàn)橹钡浆F(xiàn)在對于配置OS/90產(chǎn)品也沒有自動(dòng)的解決方法。另外，與現(xiàn)有技術(shù)腳本程序相比，用戶化步驟的可靠性和可用性由于發(fā)明的請求細(xì)化度而被提高了--這是一個(gè)平臺的獨(dú)立特征，例如，現(xiàn)有技術(shù)中基于WINDOWS系統(tǒng)的IstallShield方法。
13．在與請求調(diào)度程序所運(yùn)行的系統(tǒng)一致的系統(tǒng)中，請求調(diào)度程序可被有利地實(shí)現(xiàn)于使用標(biāo)準(zhǔn)的Java類加載器以調(diào)用支持器程序。然而，遠(yuǎn)程類加載器或Java RMI(遠(yuǎn)程方法調(diào)用)也可被使用，并具有這樣的優(yōu)點(diǎn)，即支持器程序可以同請求調(diào)度程序一樣駐留在其它系統(tǒng)中，這意味著對于使用不同操作系統(tǒng)的不同系統(tǒng)之間的協(xié)同性而言，請求調(diào)度程序的設(shè)計(jì)是開放式的。唯一的假設(shè)在于兩者要對相同的資源庫進(jìn)行存取。
14．請求調(diào)度程序也被用于觸發(fā)能實(shí)現(xiàn)除更新系統(tǒng)資源以外的其它功能的支持器程序的執(zhí)行。請求調(diào)度程序是獨(dú)立于支持器所執(zhí)行的工作種類，但是要對請求進(jìn)行管理而不管它們將在支持器一側(cè)觸發(fā)何種動(dòng)作。
15．生成XML(可擴(kuò)充標(biāo)高語言)的格式的登錄文件，文件中保存著請求的執(zhí)行序列，在出錯(cuò)時(shí)能檢測問題所在，這是一個(gè)重要的優(yōu)點(diǎn)。XML格式本身被選擇以便易于使用標(biāo)準(zhǔn)軟件來瀏覽其內(nèi)容。尤其，追蹤屬于設(shè)計(jì)的結(jié)構(gòu)部分，而且支持器與請求調(diào)度程序能追蹤到相同的文件中，如果該申請調(diào)度程序?qū)⒂兄诖_定問題所在。
本發(fā)明的一個(gè)重要而有利的特征是請求調(diào)度過程的復(fù)雜流程可被登錄或追蹤工具寫下來，而這些工具可以被請求調(diào)度程序和支持器使用。
一個(gè)具有優(yōu)勢的設(shè)計(jì)問題--即使未來的支持器程序能以其自身的代碼插接到請求調(diào)度程序上--已由請求調(diào)度程序和支持器程序之間的用于調(diào)用和結(jié)果提示的結(jié)構(gòu)接口所解決。
總結(jié)請求調(diào)度程序的優(yōu)選結(jié)構(gòu)特征，基本上從兩個(gè)接口來獲取輸入一是命令行調(diào)用接口；二是資源庫存取。命令行接口能被手動(dòng)觸發(fā)或，例如在Windows NT系統(tǒng)中，被GUI驅(qū)動(dòng)工具觸發(fā)。通過可辨識的名稱，命令行接口引用了bindConfiguration(連接配置)，其中bindConfiguration(連接配置)涉及到了明確請求和應(yīng)被執(zhí)行的功能性(EVLUATE評估，BIND連接，ACTIVATE激活，UNBIND拆分)的開發(fā)器服務(wù)。它們被送給請求調(diào)度程序。驅(qū)動(dòng)和目標(biāo)系統(tǒng)的可辨識名稱也作為輸入。
利用bindConfiguration(連接配置)，為資源庫中各開發(fā)器服務(wù)而組織的請求被請求調(diào)度程序讀取到存儲器中。它將這些請求分組到支持器的特定鏈中，由此各請求由支持器負(fù)責(zé)執(zhí)行的“requestedService”(被請求的服務(wù))屬性定義。因?yàn)檫@是請求調(diào)度程序設(shè)計(jì)的一個(gè)重要特征，因此將在下面尤其參考IBM OS/90主機(jī)技術(shù)的例子中解釋設(shè)想有一個(gè)涉及到兩個(gè)開發(fā)器服務(wù)的bindConfiguration(連接配置)，這兩個(gè)服務(wù)為應(yīng)被用戶化的應(yīng)用程序或‘產(chǎn)品’，稱為ParallelSysplex和HomeBanking。開發(fā)器ParallelSysplex定義了對照支持器RACFSecurity和其自身的請求。開發(fā)器HomeBanking定義了兩個(gè)對照支持器RACFSecurity的請求和一個(gè)對照支持器Parmlib的請求。
請求調(diào)度程序發(fā)現(xiàn)了所有的請求并將其排序成三個(gè)鏈。
-RACFSecurity鏈，包括三個(gè)請求，即兩個(gè)HomeBanking請求和一個(gè)RarralleSysplex請求；-Parmlib鏈，包括一個(gè)請求；-ParallelSysplex鏈，包括一個(gè)請求。
請求鏈要被排序以及如何實(shí)現(xiàn)排序這一事實(shí)是另一個(gè)重要的發(fā)明特征。支持器順序關(guān)系在資源庫中被定義，是代表支持器執(zhí)行序列的。
另外，請求調(diào)度程序包括排序機(jī)制，以便根據(jù)請求的前趨屬性指定的前趨屬性對請求鏈進(jìn)行排序。被前趨屬性所引用的請求--前趨屬性具有對具有相同的被請求的服務(wù)名稱的另一個(gè)請求的引用，在請求包括前趨屬性之前存在于請求鏈中。
進(jìn)一步，請求調(diào)度程序能以模塊化形式被有利地實(shí)現(xiàn)。因此，它提供了大量--這里基本上是四個(gè)--主函數(shù)，這些主函數(shù)要在序列EVALUATE(評估)，BIND(連接)，ACTIVATE(激活)和UNBIND(拆分)中被成功地執(zhí)行。因此，請求調(diào)度程序?qū)⒈徽{(diào)用三次以成功地將開發(fā)器服務(wù)連接到操作系統(tǒng)上，并再調(diào)用一次以便將開發(fā)器服務(wù)與操作系統(tǒng)拆分開(UNBIND)。
請求調(diào)度程序通過使用SupporterObject(支持器對象)有利地調(diào)用支持器功能性作為輸入，利用SupporterObject支持器程序能存取請求調(diào)用程序提供的API。這些輸入包括請求鏈和有關(guān)追蹤和登錄的信息，根據(jù)上面描述的以及在資源庫說明中描述的靜態(tài)順序關(guān)系，這是為了使支持器程序易于使用這些工具。
請求調(diào)度程序的另一個(gè)重要的發(fā)明特征在于，在XML登錄文件中登錄執(zhí)行序列。這允許請求調(diào)度程序和支持器程序產(chǎn)生其動(dòng)作的連續(xù)執(zhí)行序列，同時(shí)允許請求模擬。這里模擬并不意味著在資源中執(zhí)行請求，而是在模擬模式關(guān)閉時(shí)說明已經(jīng)做過哪些動(dòng)作。
被應(yīng)用到調(diào)度開發(fā)器請求中的發(fā)明方法的四個(gè)基本功能性概括如下EVALUATE(評估)當(dāng)請求調(diào)度程序通過EVALUATE(評估)被調(diào)用時(shí)，它調(diào)用支持器提供資源庫存取方法，以便產(chǎn)生新的連接請求作為現(xiàn)存連接請求的子請求。這一功能性被設(shè)計(jì)成允許支持器對開發(fā)器請求精選。其原因在于，開發(fā)器產(chǎn)品不了解也不欲關(guān)心太多的支持器細(xì)節(jié)。因此，建議支持器允許具體化高級請求，依賴于操作系統(tǒng)的細(xì)節(jié)最終這些高級請求可以被相應(yīng)的支持器精選。換句話說，一種請求級聯(lián)被建立起來。在實(shí)現(xiàn)成功的評估后，用戶能瀏覽資源庫以審察由該級聯(lián)生成的請求，并改變它們，因?yàn)槭謩?dòng)執(zhí)行干預(yù)是可能的。然后，用BIND調(diào)用請求調(diào)度程序以執(zhí)行被生成的連接請求。
BIND(連接)如果請求調(diào)度程序使用選項(xiàng)BIND(連接)被調(diào)用，根據(jù)上面用CHECK_BIND說明的順序關(guān)系，它首先調(diào)用所有的支持器，參考第10頁。支持器具有查證用選項(xiàng)BIND(連接)執(zhí)行請求是否失敗的可能性。如果所有支持器返回OK--返回代碼，它們將用函數(shù)BIND(連接)以相同的順序被調(diào)用。支持器將在整個(gè)請求鏈上工作，同時(shí)更新資源。這些是被要求配置開發(fā)器產(chǎn)品的資源以使該產(chǎn)品被啟動(dòng)。
通常地，更新資源不足以在操作系統(tǒng)中使更新處于激活狀態(tài)。因此，通過使用與EVALUATE(評估)中所使用的相同的請求調(diào)度程序接口，用于激活的請求可被支持器程序創(chuàng)建。
ACTIVATE(激活)為了激活操作系統(tǒng)中的資源改變，請求調(diào)度程序可用選項(xiàng)ACTIVATE(激活)被調(diào)用。所有的在連接期間被生成的激活請求將以BIND(連接)中使用的相同的形式并按照支持器使用選項(xiàng)ACTIVATE(激活)被調(diào)用時(shí)所遵循的順序關(guān)系被執(zhí)行。支持器實(shí)現(xiàn)激活請求，例如它們通過設(shè)置命令激活OS/390 parmlib中的成員。在設(shè)置完命令之后，被改變后的parmlib處于激活狀態(tài)，在某種意義上其被改變后的參數(shù)正影響著操作系統(tǒng)，例如，它們定義了更多的虛擬存儲器等。
UNBIND(拆分)如果在BIND(連接)過程中，一個(gè)請求不能得到執(zhí)行，整個(gè)bindConfiguration(連接配置)都不能成功地連接。這時(shí)請求調(diào)度程序?qū)⑹〉亟K止。為了使資源改變被成功地執(zhí)行，失敗的請求在這之前必須被清除。因此請求調(diào)度程序能用選項(xiàng)UNBIND(拆分)被調(diào)用，與BIND(連接)過程相比，選項(xiàng)UNBIND(拆分)迫使支持器以相反的順序被調(diào)用，同時(shí)請求鏈也被反向。
結(jié)合前面提到的作為對應(yīng)用程序自動(dòng)配置的請求調(diào)度程序的專利申請，本發(fā)明將得到更為詳細(xì)地說明。本發(fā)明的優(yōu)選方面將通過例示的方式被說明，但是并不限于附圖中圖表的形式。附圖包括

圖1是示意方塊圖，表示發(fā)明請求處理過程和其中涉及到的最基本的要素的總體想法；圖2A和B是示意方塊圖，表示發(fā)明方法的總體控制流程；圖3是示意描述，表示支持器執(zhí)行和登錄步驟的細(xì)節(jié)。
對于下面本發(fā)明優(yōu)選實(shí)施例的詳細(xì)說明，應(yīng)假設(shè)有n個(gè)應(yīng)用程序被容納在主機(jī)中。對于本領(lǐng)域中的技術(shù)人員，他們經(jīng)常遇到大量應(yīng)用程序中的并列配置請求的問題，發(fā)明的優(yōu)點(diǎn)應(yīng)是為他們所理解的。
根據(jù)本發(fā)明所包括的基本想法，大量應(yīng)用程序從操作系統(tǒng)的角度被看成是開發(fā)器E1、E2…En，因?yàn)樗麄冮_發(fā)操作系統(tǒng)的資源。
在圖1中，開發(fā)器或開發(fā)器產(chǎn)品用框10框起來，這樣意在表示出相同的硬件系統(tǒng)和相同的操作系統(tǒng)資源被它們所存取。
另一方面，所說操作系統(tǒng)資源在圖1的右邊用符號描述出來，參看標(biāo)號12、14、16。
當(dāng)開發(fā)器產(chǎn)品將被安裝時(shí)或其配置數(shù)據(jù)必須被更新時(shí)，將導(dǎo)致的系統(tǒng)配置的改變會(huì)引起開發(fā)器產(chǎn)品E1…En向操作系統(tǒng)的資源提出并行請求的問題。
根據(jù)本發(fā)明，所說大量請求在請求資源庫18中被連接。這些請求在圖1中只部分地被說明，用r11，rlj…rn1表示出來。所說這些請求用XML語言定義，和該請求資源庫是一個(gè)基于LDAP目錄。這樣使用通常的瀏覽工具系統(tǒng)管理員就可以看見這些請求。
在所說資源庫18中，請求有利地以樹形結(jié)構(gòu)被存儲。通常，各請求具有一個(gè)或多個(gè)屬性，這些屬性必需用相關(guān)的值填充以定義所說請求。例如，系統(tǒng)中用于確認(rèn)用戶標(biāo)識的請求可能包括下列屬性及其值請求屬性O(shè)bjectclass對象類BindRequest連接請求BindRequest連接請求 Securityl安全1ConfigurationID配置IDParallelSysplex并行SysplexRequestedService被請求的服務(wù) RACFSecurity RACF安全RequestedSupportName被請求的支持名稱 ASSURE_USER確定-用戶RequestParameters請求參數(shù)USER_ID=THEL用戶-ID-THELRequestParameters請求參數(shù)GROUP=D1311組=D1311RequestStatus請求狀態(tài)REQUESTED被請求的ReturnCode返回代碼 0ReasonCode原因代碼 0MinSupportVersion最小支持版本1.0更多的屬性可以被相加成，例如一個(gè)屬性，用于具體指明是否特定請求的服務(wù)對于系統(tǒng)運(yùn)行是必要的或是可選擇的。上面的請求定義應(yīng)僅僅理解為一個(gè)例子，用面向?qū)ο蟮木幊陶Z言實(shí)現(xiàn)。通常，定義請求的任何屬性的類型，數(shù)量以及值對于各個(gè)請求都是特定的。然而，下面的屬性對于應(yīng)用在下列實(shí)施例中的所有請求都是相同的被請求的服務(wù)用于明確指定由請求調(diào)度程序所調(diào)用的支持器程序的名稱。
被請求的支持名稱這里被請求的功能性可被定義，例如用于確認(rèn)用戶。
配置ID定義唯一的字符串，識別包括請求的開發(fā)器配置。
請求參數(shù)是支持器特定的，在上面的例子中它們表示特定的用戶標(biāo)識名和安全支持組。
請求狀態(tài)說明請求的現(xiàn)行狀態(tài)。
REQUESTED意思是請求將被執(zhí)行，其它可能的值為BOUND(連接)，BIND_FAILED(連接-失敗)，EVALUATED(評估)等。
最小支持版本包括為執(zhí)行請求而被要求的支持器版本。
請求調(diào)度程序，即一些程序方法，用參考標(biāo)號20標(biāo)識。所說請求調(diào)度程序20能通過標(biāo)準(zhǔn)化接口22存取請求資源庫18進(jìn)行讀寫操作。
請求調(diào)度程序重新組織這些下面進(jìn)一步詳細(xì)說明的請求。標(biāo)準(zhǔn)化的接口24在請求調(diào)度程序20和大量支持器S1,S2…SM之間被提供以便使請求調(diào)度程序能調(diào)用支持器。請求調(diào)度程序20的一個(gè)任務(wù)是將這些請求重新組織分成子組，在圖1中用rik表示，每個(gè)子組都與各自的支持器S1,…SM相關(guān)聯(lián)。這樣，m個(gè)請求鏈被創(chuàng)建。其優(yōu)點(diǎn)在于來自不同開發(fā)器產(chǎn)品請求的多個(gè)請求被請求調(diào)度程序視為一個(gè)語義單元，該請求調(diào)度程序減輕了解決獨(dú)立請求與相同資源之間以及各不同資源之間的相互依賴關(guān)系的難題。
指向左側(cè)的箭頭表示大量支持器S通過所說被標(biāo)準(zhǔn)化的接口和請求調(diào)度程序?qū)?shù)據(jù)寫到請求資源庫18中，以便將系統(tǒng)資源的任何動(dòng)作及其影響報(bào)告到登錄文件中，登錄文件在圖1中未表示出來。
實(shí)際系統(tǒng)資源12、14、16的操作是僅由支持器實(shí)現(xiàn)的，這用支持器和資源之間的箭頭表示。
通用的支持器/開發(fā)器資源庫17可被支持器使用，以產(chǎn)生輸出信息，這些信息可由開發(fā)產(chǎn)品或在用戶化期間由配置開發(fā)產(chǎn)品的用戶化產(chǎn)品讀取。作為一個(gè)特例，請求資源庫和通用的支持器/開發(fā)器資源庫能在相同的技術(shù)中被結(jié)合起來(例如，基于LDAP的目錄)。
應(yīng)該注意到，根據(jù)本發(fā)明，用于連接大量請求以及重新組織它們的發(fā)明方法能有利地被應(yīng)用在大量應(yīng)用程序即開發(fā)器產(chǎn)品被安裝到硬件系統(tǒng)中的情況下，因?yàn)榘l(fā)明概念允許在系統(tǒng)中被真正執(zhí)行之前檢測系統(tǒng)資源被請求的狀態(tài)的效果。
在相同的情況下，“UNDO”(撤消)功能可被執(zhí)行，該操作逆轉(zhuǎn)在前述的操作系統(tǒng)資源改變期間對系統(tǒng)資源所作的全部改變。
現(xiàn)在參看圖2A和B，對包括大量發(fā)明方法特征的控制流程的總體想法將在下面得到更詳盡地說明。
作為預(yù)備步驟，不必要在第一步210中包含發(fā)明概念，而要準(zhǔn)備對包括由大量請求程序請求的并行請求的適應(yīng)性進(jìn)行連接，即連接請求被存儲在資源庫中。
在步驟220中，發(fā)明請求調(diào)度程序工具經(jīng)由EVALUATE(評估)選項(xiàng)被調(diào)用。該評估步驟使得支持器能讀取用編址的這些支持器的各個(gè)請求的內(nèi)容，并確定是否還能再作些工作以改進(jìn)這些請求。為了實(shí)現(xiàn)這種請求的改進(jìn)，要使支持器本身產(chǎn)生對一個(gè)或多個(gè)不同支持器編址的請求。那些請求也被存儲在請求資源庫中。
應(yīng)當(dāng)了解，在評估步驟中所有的請求都被各自的支持器處理，在評估步驟結(jié)束時(shí)，所有的支持器被徹底地處理過。這些在包括大量支持器的外層程序循環(huán)中和包括被訪問到支持器的所有請求的第二內(nèi)層循環(huán)中實(shí)現(xiàn)。
在步驟230中，請求資源庫18可被系統(tǒng)管理員瀏覽，并且抵觸請求在處理過程早期已被識別出來。
在步驟240中連接步驟被調(diào)用。
尤其，連接步驟被分割成至少兩個(gè)不同的部分在步驟250中執(zhí)行的第一部分和依賴于步驟250的結(jié)果而決定步驟260或步驟270哪個(gè)將被執(zhí)行的第二部分。
尤其，在步驟250中，大量不同請求的相容性被檢測。檢測意味著各支持器被詢問是否它能夠服務(wù)被訪問它的所有請求。根據(jù)這一特征，識別獨(dú)立請求不能得到服務(wù)的情況是很有可能的，而且--如果各個(gè)請求屬性告訴支持器該請求被要求--終止系統(tǒng)的改變以便保持正確地系統(tǒng)運(yùn)行而不冒險(xiǎn)產(chǎn)生由不能被服務(wù)的請求而引發(fā)的系統(tǒng)問題，也是很可能的。這樣，如果請求相容性為OK(是)，決定252生成；否則，就不生成。在結(jié)果為NO(否)的分枝中--步驟254，測試容易得到終止而并不產(chǎn)生系統(tǒng)改變。這樣，系統(tǒng)始終保持未改變。然而，在結(jié)果為YES(是)的分枝中，系統(tǒng)管理員被詢問是否他想要執(zhí)行改變，還是他想要模擬改變的執(zhí)行。256中的各個(gè)決定在圖2中被說明。在YES(是)的分枝中，系統(tǒng)資源的改變被執(zhí)行，但在步驟260中它們卻處于非激活狀態(tài)。然而，在步驟270中改變的執(zhí)行僅僅被模擬。
模擬方針允許終端用戶執(zhí)行連接和激活而并不真正地影響資源，因?yàn)樵谶@種模式下任何支持器將執(zhí)行細(xì)節(jié)寫到所說登錄文件中而并不更新資源。這樣，模擬比前面提到過的檢測預(yù)期的系統(tǒng)改變是否是有用的特征更多--因?yàn)樵谶@方面該工具的答案僅僅包括是和否。在模擬步驟中，所有的細(xì)節(jié)都能從登錄文件中被追蹤回來。
在步驟280中，在轉(zhuǎn)換執(zhí)行完成后，所有的請求能再一次被系統(tǒng)管理員瀏覽并控制。
在步驟290中--步驟290被在命令行中具體化ACTIVATE(激活)選項(xiàng)的發(fā)明工具的新調(diào)用所調(diào)用，被實(shí)現(xiàn)的變化的激活過程被調(diào)用。該步驟反映了發(fā)明方法的重要優(yōu)點(diǎn)，在變化執(zhí)行完后的任意時(shí)刻都可執(zhí)行該步驟，因此可以由系統(tǒng)管理員自由地確定。這樣，激活步驟可以發(fā)生在步驟260執(zhí)行完例如幾個(gè)星期或幾個(gè)月之后。
參考圖2B，在激活之前，請求的相容性在步驟300中再一次被檢測。在步驟310中確定檢測的成功與否。如果不成功，使用戶能瀏覽登錄文件并編輯它以便手動(dòng)地更正潛在的錯(cuò)誤，這是步驟320。隨后相容性將再次被檢測?；蛘?，在步驟310的“YES”(是)分枝上，用戶必需確定在步驟330是否他想要執(zhí)行激活，或者是僅僅在步驟335中模擬激活。在模擬狀態(tài)下，控制被反饋回步驟300中以再次檢測請求的相容性，或者，另一種情況，控制被反饋到步驟320中以手動(dòng)糾正一些錯(cuò)誤。在步驟330的YES(是)分枝上，激活在步驟340中被實(shí)際地執(zhí)行。尤其，在步驟260中被執(zhí)行完的改變被激活，這意味著激活的系統(tǒng)資源狀態(tài)根據(jù)存儲在資源庫18中的請求確實(shí)得到了改變。在步驟350中，用戶被通知成功的實(shí)現(xiàn)激活，隨后該工具終止。
應(yīng)當(dāng)注意到，模擬激活請求的行為與連接請求的模擬是相似的。支持器將激活動(dòng)作的細(xì)節(jié)寫到登錄文件中而并不影響執(zhí)行。
圖2整體上表示了發(fā)明的請求調(diào)度過程方法是模塊化結(jié)構(gòu)，這些模塊可以被獨(dú)立地處理和調(diào)用，參考步驟220、240、290。不同模塊的處理過程在這里作為發(fā)明工具的調(diào)用實(shí)現(xiàn)，而各不同的調(diào)用選項(xiàng)經(jīng)由命令行接口被執(zhí)行。其它接口，例如GUI接口，或面向批量的調(diào)用也能實(shí)現(xiàn)。
參考圖3，支持器執(zhí)行和登錄僅僅通過參考執(zhí)行和登錄一個(gè)支持器所必需的步驟而被更詳盡地說明。支持器執(zhí)行和登錄的整個(gè)任務(wù)在包括所有支持器的循環(huán)中被有利地實(shí)現(xiàn)。
在第一步510中，請求調(diào)度程序訪問請求資料庫18以便獲取調(diào)用支持器所必需的數(shù)據(jù)，尤其是支持器的名稱，如何調(diào)用它以及其它在這里不相關(guān)的細(xì)節(jié)信息。該支持器信息可能包括資料庫18，而它也可以位于任何地方。此外，所有連接請求被讀取，以便準(zhǔn)備好使它們能被現(xiàn)行循環(huán)操作內(nèi)實(shí)際相關(guān)的支持器程序可存取。
在下面的步驟520中，所有的請求被依次地注冊到登錄文件中，即上面提到的XML文件，以便追蹤哪個(gè)請求已被執(zhí)行、哪個(gè)支持器被尋址。
在下面的步驟530中，執(zhí)行與現(xiàn)有循環(huán)操作相關(guān)的支持器的特定進(jìn)入點(diǎn)。如果激活請求確實(shí)存在--回去參考圖2B中步驟340--支持器執(zhí)行實(shí)際工作以激活預(yù)先定義的系統(tǒng)資源的新狀態(tài)。支持器執(zhí)行的所有動(dòng)作被寫入到登錄文件中以便使系統(tǒng)管理員能保持對被執(zhí)行的所有系統(tǒng)改變的全面了解。
在下面的步驟540中，執(zhí)行請求的結(jié)果以能反映請求狀態(tài)的返回代碼的形式被寫入到與定義請求屬性的存儲結(jié)構(gòu)相關(guān)的存儲位置。這樣，“請求成功實(shí)現(xiàn)”或“請求失敗”等的標(biāo)記被存儲。
在下面的步驟550中，由請求調(diào)度程序執(zhí)行的完整登錄，即所有被認(rèn)為是控制前述的動(dòng)作所必需的信息被寫入到登錄文件中以便能被系統(tǒng)管理員追蹤。
對于其余的所有支持器，步驟510到550中的序列被重復(fù)，直到所有支持器根據(jù)靜態(tài)支持器順序關(guān)系已被處理。
在前述的詳細(xì)說明中，參考特定的例示實(shí)施例發(fā)明得到了說明。然而，顯而易見的是各種修改和變化可被實(shí)現(xiàn)而并不背離將在附加權(quán)利要求中提出的發(fā)明的廣義和范圍。因此，這些詳細(xì)說明和附圖應(yīng)被看成是說明性的，而不具有限制意義。
本發(fā)明能在硬件中、軟件中或軟硬件結(jié)合的系統(tǒng)中實(shí)現(xiàn)。根據(jù)本發(fā)明，請求調(diào)用程序工具能在一個(gè)計(jì)算機(jī)系統(tǒng)中以集中的方式被實(shí)現(xiàn)，或在不同組件被分布在幾臺互連的計(jì)算機(jī)系統(tǒng)中的情況下以分布的方式實(shí)現(xiàn)。任何類型的計(jì)算機(jī)系統(tǒng)或其它用來執(zhí)行這里描述的方法的設(shè)備都是適合的。軟硬件的典型結(jié)合可以是一個(gè)通常用途的計(jì)算機(jī)系統(tǒng)，其上的計(jì)算機(jī)程序當(dāng)被加載和被執(zhí)行時(shí)控制計(jì)算機(jī)系統(tǒng)以便它能執(zhí)行這里描述的方法。
本發(fā)明也能被嵌入到計(jì)算機(jī)程序產(chǎn)品中，這種產(chǎn)品包括所有能使這里說明的方法實(shí)現(xiàn)的特征，并且當(dāng)載入到計(jì)算機(jī)系統(tǒng)中時(shí)能執(zhí)行這些方法。
本文中的計(jì)算機(jī)程序方法和計(jì)算機(jī)程序意味著一組指令的任何類型語言的表達(dá)、代碼或符號，這組指令要使具有信息處理能力的系統(tǒng)直接地執(zhí)行特定的功能，或在執(zhí)行完以下兩種之一或全部之后執(zhí)行特定的功能a)轉(zhuǎn)換為另一種語言，代碼或符號；b)不同資料形式的再現(xiàn)。
權(quán)利要求
1．支持自動(dòng)管理支持器自身的資源(12、14、16)的方法包括下列步驟存取(510)包括請求的資源庫(18)，各請求定義了應(yīng)被執(zhí)行的動(dòng)作，或一個(gè)應(yīng)達(dá)到的預(yù)期的狀態(tài)，該狀態(tài)與各自的資源(12、14、16)相關(guān)聯(lián)；重新組織(520)該請求；調(diào)用(530)管理程序方法的資源以處理所說請求鏈。
2．根據(jù)權(quán)利要求1的用于支持程序自動(dòng)配置的方法，其中所說請求定義了由資源(12、14、16)維護(hù)的操作系統(tǒng)的預(yù)期狀態(tài)，該方法包括下列步驟調(diào)用(220、240、260、290)支持器程序方法，以保證該資源根據(jù)這些請求被設(shè)置。
3．根據(jù)權(quán)利要求2的方法包括將標(biāo)準(zhǔn)化接口(24)用于支持器程序的調(diào)用。
4．根據(jù)權(quán)利要求3的方法包括至少下列步驟之一檢測(250、300)由一個(gè)或多個(gè)請求引起的相容性；生成(220)一個(gè)或多個(gè)新的請求作為已存在的請求的子請求；模擬(270、335)所說請求的執(zhí)行；執(zhí)行(260)資源更新，并生成特定的激活請求；使操作系統(tǒng)了解更新；逆向前面所實(shí)現(xiàn)的更新。
5．根據(jù)權(quán)利要求4的方法包括下面的步驟生成用戶可讀取協(xié)議，其中根據(jù)上面的權(quán)利要求，所說一個(gè)步驟的執(zhí)行效果通過使用資源(12、14、16)的各設(shè)置被登錄。
6．根據(jù)權(quán)利要求1-5之一的方法，當(dāng)所說該程序被加載到計(jì)算機(jī)設(shè)備中時(shí)，計(jì)算機(jī)程序包括適用于執(zhí)行步驟的代碼選項(xiàng)。
7．一種存儲在計(jì)算機(jī)可用介質(zhì)中的計(jì)算機(jī)程序產(chǎn)品，包括計(jì)算機(jī)可讀程序方法，用以使計(jì)算機(jī)執(zhí)行權(quán)利要求1至5中之一的任何方法。
8．一種已安裝了程序方法的計(jì)算機(jī)系統(tǒng)，以執(zhí)行權(quán)利要求1至5中的任何方法之一。
全文摘要
本發(fā)明與在用戶位置使軟件適用于需求設(shè)置的領(lǐng)域相關(guān)聯(lián)。它適用于不同系統(tǒng)管理環(huán)境自動(dòng)地配置軟件。尤其,它與資源自動(dòng)管理相關(guān)聯(lián)(12,14,16),甚至與軟件程序的自動(dòng)配置有關(guān)。發(fā)明基本上提出了下面一系列步驟:存取包含請求的資源庫(18);重新組織在某種意義上被排序、被附隨等的所說請求;調(diào)用管理程序資源,例如,處理所說請求的服務(wù)的支持器。
文檔編號G06F9/46GK1302014SQ00135968
公開日2001年7月4日 申請日期2000年12月19日 優(yōu)先權(quán)日1999年12月30日
發(fā)明者N·倫茲, F·米爾克, R·特倫 申請人:國際商業(yè)機(jī)器公司