TW582147B

TW582147B - Inbound connector

Info

Publication number: TW582147B
Application number: TW091120442A
Authority: TW
Inventors: Michael Beisiegel; Jean-Sebastien Michel Delfino; Piotr Przybylski
Original assignee: Ibm
Priority date: 2001-09-10
Filing date: 2002-09-09
Publication date: 2004-04-01
Also published as: KR20040032876A; KR100683812B1; WO2003024054A3; WO2003024054A2; US20040243693A1; CA2357168A1

Description

582147 ⑴ 玖、發明說明 (發明說明應敘明：發明所屬之技術領域、先前技術、内容、實施方式及圖式簡單說明) 發明領域本發明一般與具有一通用介面的連接伺服器及用戶端的領域有關，更特定言之，與提供具有一致介面的伺服器有關，該介面用以與多種中介軟體產品及應用程式介面互動。發明背景由不同類別的硬體建置及在不同類別的軟體之下運作的電腦間相互通訊通常是必要的。其中一種這樣的情況是一用戶端（即一應用程式或其中的一組件）需要存取一伺服器以請求處理或存取資料。從傳統角度而言，稱為「中介軟體」的軟體已經便利了該些互動。許多中介軟體產品能應付對後端系統，如資料庫及交易系統的連接問題。該些中介軟體產品提供了具有多種程式模型，介面及協定以存取後端系統的用戶端。特定言之，中介軟體可作為資料管道，其將資訊及請求從用戶端載送到伺服器並返回。以此方式使用中介軟體的其中一個問題是對一給定的伺服器系統，中介軟體傾向為特定的。因此，為處理一種中介軟體（連接至一特定的伺服器類型）而寫入的一用戶端應用程式（或組件）可能需要修改或重寫以與一不同的伺服器類型連接。開發者會需要知道每個中介軟體產品的細節，該用戶端應用程式與該中介軟體產品互動以寫入代碼。 -6- (2)

Μ· Radestock及S. Eisenbach在發表於98年的中介軟體 (Middleware)的論文「中介款體系統中的組件協調 (Component Coordination in Middleware Systems)」描述了一稱為「陷阱（trap)」的系統，其中會截取並解釋從一組件到另一組件的訊息，然後將之發送到希望的（或一不同的）組件。雖然該論文確實描述了一執行解釋的容器以及截取並重發訊息的陷阱，其要求一中央陷阱系統監控所有外發的訊息，該系統是資源集中的，不能在分散式環境中調停與中介軟體基系統的組件互動。本發明受讓人申請的加拿大專利申請案2,232,626揭示了一用於應付該問題的「共同連接器架構」。一連接器結構使應用組件的開發者隔離各種軟體產品的複雜性，並提供具有出站連接器的用戶端應用程式以及存取後端系統的一致方法。該技術用作該中介軟體及該用戶端應用程式間的一層。根據單一協定（即公共連接器架構所用的協定）寫入用戶端應用程式或組件以產生輸出及接收輸入。因此，從用戶端應用程式的角度而言，其與哪個伺服器或哪個中介軟體互動是無關緊要的。而是只需寫入用戶端應用程式一次，以遵守共同連接器架構所用的協定。該共同連接器架構軟體負貴定義具有中介軟體的介面，解釋輸入及輸出的資料，該資料位於用戶端應用程式所用的協定與中介軟體所用的協定間。加拿大專利申請案2,232,626描述的該共同連接器架構所不能做的疋應付在該些交易的祠服器端上的互動困難。特 582147 (3) 鼕碉尊搏磷頁 —έϊ ϊή 令，?ΤΆ私故公汐ΛU i 足5之’寫入新的伺服器應用程式時，開發者需要知道與該伺服器互動的該中介軟體的細節。這會增加開發新的伺服器應用私式的困難。此外’主從（client-server)交易的伺服器端較複雜’因為伺服器必須提供額外的服務，如服務的安全性及品質。需要額外關注影響該伺服器端的一個問題。企業對企業 (business-to-business:B2B)互動的發展意味著一個企業的饲服器現在不但與用戶應用程式互動，也直接與不同企業的其他伺服器互動。在一企業對企業環境中，應用程式需要推進與其他應用程式的企業對企業互動。用戶端企業對企業應用程式會與使用多種協定及中介軟體以提供企業對企業服務的飼服器企業對企業應用程式通訊互動。只要互動嚴格限制在同一組織内的用戶端及伺服器間，該中介軟體就可以應付具有該伺服器端的介面。不過，一旦需要一個公司的伺服器直接與一不同公司（其可能使用不同的硬體及軟體設定）的飼服器通訊，就會出現問題。例如，並非所有的企業都使用同一協定1此，可能需要不同的中介軟體與每個類別的「夥伴」伺服器通訊。這會增加複雜性，並且開發新的飼服器應用程式需要相關類別的中介軟體的知識。需要一種方法來定義一词環境可以是用戶端應用程式有中介軟體系統的知識來發此吾人希望提供該伺服器端服器系統與其環境的互動，該或其他伺服器，因此不需要現展或修改伺服器應用程式。因應用程式的一連接器結構。 582147 (4) 發明說明續瓦 ί> V，狀發明概要本發明與提供一電腦伺服器的系統及方法有關，該伺服器具有用以與多種中介軟體產品及應用程式介面互動的通用介面。在本發明的一種觀點中，提供了與一通訊網路通訊的電腦系統，其包括： a) 向一或多個服務組件及一或多個入站連接器提供服務的一組件伺服器；

b) 提供應用程式邏輯的每個該服務組件；以及 c) 向複數個電腦系統提供一組介面的該服務組件，該組介面獨立於複數個電腦系統的中介軟體，與該通訊網路通訊的該入站連接器，該組件伺服器以及該服務組件。在本發明的另一種觀點中，提供了一種建立一服務以與一服務組件通訊之方法，該方法包含下列步驟： a) 請求該服務；

b) 如果該服務的一實例是可用的，就利用該服務的該實例；以及 c) 如果未有該服務的實例，就建立該服務的實例。在本發明的另一種觀點中，提供了與一通訊網路通訊的電腦系統，該電腦系統包含： a) 向一或多個服務組件及一或多個入站連接器提供服務的方法； ’ b) 提供每個服務組件的應用程式邏輯的方法；以及 c) 向複數個電腦系統提供一組介面的方法，該組介面 -9- 582147 (5) / .紙、·ν ，':τ爹與爽明緣頁 , 獨立於複數個電腦系統的中介款體，與該通訊網路通訊的該入站連接器，該組件伺服器以及該服務組件。 k 仍然是在本發明的另一種觀點中，提供了一電腦可讀媒體，其包含使一電腦系統與一通訊網路通訊的指令，該媒體包含： a) 一組件伺服器用於向一或多個服務組件及一或多個入站連接器提供服務的指令； b) 具有提供應用程式邏輯的指令的每個該服務組件

；以及 c) 提供指令以實作複數個電腦系統的一組介面的該服務組件，該組介面獨立於複數個電腦系統的中介軟體，與該通訊網路通訊的入站連接器，該組件伺服器以及該服務組件。圖式簡單說明圖1所示的係企業對企業系統的方塊圖；圖2所示的係一伺服器的組件的方塊圖；圖3所示的係用於說明在一伺服器之上堆疊入站連接器的方塊圖，圖4所示的係在一伺服器上實作的一入站連接器的組件的示意圖；圖5所示的係說明一入站連接器建立一服務的過程的流程圖；以及圖6所示的係說明一入站連接器對一請求提供服務的過程的流程圖。 -10-

582147 發明詳細說明本發明提供了一種系統及方法，其用於簡化用戶端與伺服器間及伺服器與伺服器間的互動，其每個伺服器在一網路上相互通訊。這藉由提供一入站連接器而達到，該入站連接器用作中介軟體及一伺服器間之一層。一入站連接器提供了具有一組介面的伺服器組件，該組介面將其從與其他企業對企業的互動通訊的協定及中介軟體的複雜性中隔離出來，並允許其以一致的方式通訊互動。這會使得開發新的伺服器端應用程式，與其他使用不同類別的中介軟體互動，以及與用戶端互動都變得較容易。一入站互動傳送至一伺服器時，發送該交易的系統及傳送該互動的中介軟體層會定義該互動的形式。因此，該入站互動可以採用多種形式。一入站連接器在一伺服器及其環境間定義了一致的介面，因此伺服器應用程式能夠有效地處理多種來源的入站互動，而不必寫入或修改以符合定義該入站互動的特定中介軟體。現在參考圖1，利用本發明的一企業對企業系統的方塊圖一般顯示為10，系統10包含一用戶端12及一伺服器14 。在企業對企業通訊方案中，可能有人會將用戶端12看作「企業A」並將伺服器14看作「企業B」。在一典型的互動中，用戶端1 2請求來自伺服器1 4的資訊。用戶端1 2包含組件伺服器1 6、服務代理1 8及出站連接器 2 0。圖中未顯示的應用程式（請求者）使用組件伺服器1 6 來獲取來自伺服器1 4的資訊。該請求者藉由介面22將一請 582147 讎顯觀求發运至服務代理1 8 (藉由組件伺服器1 6 ),其重新格式化居叫求。重新格式化該請求以一隱藏細節，如與伺服器 1 4的連結的重建及必要的通訊協定。然後服務代理18藉由介面24將該請求轉發至出站連接器20。出站連接器2〇封裝該請求並藉由適當的介面及通訊 | 協疋的使用，同時藉由網路28將該請求發送至伺服器14 。建立該請求時，出站連接器2〇可能利用通用服務，如組件飼服器1 6藉由介面2 6而提供的資料記錄。在某個點，出站連接器2〇會藉由網路28接收對來自伺服鲁备1 4的請求的響應。然後該響應藉由介面24返回至服務代理1 8。然後服務代理丨8藉由介面22將結果返回至請求者。飼服器1 4包含組件伺服器3 〇、入站連接器3 2及服務組件 34。組件伺服器30與組件伺服器16相似，因為其向應用程式提供服務。不過，在本方案中，其不是請求的應用程式 (即請求者）而是提供資料給請求者的應用程式。入站連接器3 2藉由網路2 8接收來自出站連接器2 0的請求。然後入站連接器3 2檢查該請求以決定伺服器丨4需要提 _ 供什麼資訊。在某些案例中，來自連接器2〇的請求可能需要提供服務品質（quality of service:Q〇S)資料。如果是這樣，就會藉由於介面36將此類請求發送至組件词服器30用於處理。術語Q0S廣泛使用於此行業，並採用多種定義。本發明中，發明者所言之Q 〇 S代表組件伺服器3 0 (參見圖、 4)的Q 0 S 9 2所提供的服務。兩個這樣的範例是·· a)安全性，在本例中QOS 92確保只有那些被允許存取 -12- 582147 L·^ - v?^5i 資料者才可以這樣做；以及 b)叉易记錄’在本例中，如果發生失敗或安全性入侵 ’ QOS 92會提供跟縱資料這兩個範例並非一詳盡的列表，而只是本發明的q〇S % 可能提供的服務類別的一指示。然後入站連接器3 2根據需要的資料將資訊傳送到一指足的服務組件3 4 ’其能藉由網路3 8提供資料。服務組件3 4 可能會藉由介面40並利用組件伺服器3 〇提供的服務以滿足請求。服務組件3 4將請求結果返回至入站連接器3 2，並重新格式化以藉由網路28傳輸至連接器20。此處揭不的入站連接器3 2為伺服器組件3 4提供了一明確疋我及一致的介面38。本發明之介面38避免了中介軟體及用以允許通訊的應用程式介面（APIs)的複雜性。特定言服務組件34不需要與不同的中介軟體程式的各種APIs 互動。服務組件34能夠實作相同的介面呼叫以獲取來自一用戶端的請求’執行該請求，並不管該用戶端所用的平台或軟體而返回一響廡。介面36允許入站連接器32使用基礎設施服務，如錯誤處理 '跟縱記錄、安全性控制或組件伺服器3 〇提供的遠端存取服務（RAS) °具有介面2 6的組件伺服器1 6使用一相似的結構。入站連接器32及出站連接器2〇都是明確的實體，如果一、給疋的词服器要同時作為用戶端及伺服器操作（即根據情 -13- 582147

(9) 況擔當不同的角色），那麼就同時需姜兩者。這是因為具有不同的APIs用於出站及入站互動，並且大多數協定不允許重新使用通訊資源（儘管有一些，如國際商業機器提供氦的MQSeries及Sun Microsystems提供的java訊息服務允許這樣做）。因此，如果一特定系統欲只作為一用戶端，那麼只 · 需要出站連接器2 0，如果其欲只作為一伺服器，那麼只需要入站連接器3 2。不過，如果一系統要同時作為一用戶端及一伺服器，那麼就應該同時具有出站連接器2 0及入站連接器3 2。 # 用戶端1 2上的介面24及伺服器1 4上的介面3 8係較佳地相同的。更特定言之，根據欲調用的方法以及欲傳送及返回的元件，介面2 4及3 8較佳的係使用相同的介面，即使用戶端1 2上該介面的實作與在伺服器丨4的實作有所不同。如果介面2 4、3 8是相同的，那麼網路2 8會變成透明的，並可以發展服務代理1 8，就好像其直接呼叫服務組件3 4。另一方面’如果伺服器14之上的介面38不同於伺服器12上的介面24，那麼用戶端應用程式必須處理該些差異，從而會增 ® 加複雜性，並會使發展及修改應用程式變得困難。不過，無論與伺服器14上的介面38中相同的介面是否用於用戶端12上的介面24,使用入站連接器32發展及修改伺服器14 的應用程式的優點都會出現，即使在用戶端丨2上根本就沒 · 有出站連接器20也會出現。該結構允許入站連接器3 2的實作獨立於其所運行的平台’既然其能夠藉由使用一組明確定義並通過介面3 6的系 •14- 582147 mmm (ίο) 統收縮介面請求來自組件伺服器30服務。相似地，組件伺服器30沒有必要H特^的人站連接器實作32的細節 ’因為組件伺服器3 〇能夠接供& y 此夠徒供任何入站連接器32使用的通用服務（如連結及交易管理）。介面36、40在组件祠服器 30及入站連接器32間，在組件伺服器3〇及服務组件B間是相同的。一入站連接器32由一組實作介面36、38的類別組成，並且利用任何必要的中介軟體及Αρι以允許使用一特定的協定與其他應用程式通訊。儘管連接器32的實作對於每種中介軟體或協定是不同的，但是介面36 ' 38保持相同。正疋該特徵使服務組件3 4從中介軟體及Αρι的複雜性中隔離出來，因此大大簡化了伺服器應用程式的發展及修改。現在參考圖2，一伺服器的組件的方塊圖一般顯示為14 。根據圖1的描述，伺服器1 4包含組件伺服器3 〇、入站連接器3 2及服務組件3 4。在企業對企業應用程式中所用的通訊協定，使用在簡易物件存取協定（Simple Object Access Protocol: SOAP)文中一般稱為並在擴充標記語言（XML)中代表的「包絡」及「酬載」來通訊互動。更特定言之’圖2說明的XML通訊採取請求包絡50(從用戶端12到伺服器14的輸入通訊）及響應包絡5 2(從伺服器14到用戶端12的輸出通訊）的形式。請求包絡5 0包含請求酬載5 4，響應包絡5 2包含響應酬載5 6。請求包絡5 0及響應包絡5 2都包含與協定相關之資訊以及各自的服務品質（Q0S)元件58、60，而請求酬載54及響應酬载 -15- ⑼ —淺键:fc滅誠广v4 56包含應用程式資料。服務品質元件58、60通常會包含安全性資訊以及情景及資源協調元件。在將應用程式資料傳送至服務組件3 4之前，需要在組件伺服器3 0上處理Q 〇 S 元件5 8。入站連接器32負貴擷取請求包絡50的Q〇S元件58及執行任何需要的處理，這通常涉及組件伺服器3 0。由於入站連接器3 2使用明確定義的介面3 6調用來自組件伺服器3 0 的服務，因此能夠以一平台獨立的方式實作該處理。在使用HTTP(超文件傳輸協定）從用戶端丨2發送一請求處使用入站連接器32之描述。入站連接器32實作HTTP，其允許用戶端1 2及伺服器1 4使用HTTP作為一通訊協定來實作企業對企業應用程式。組件伺服器30提供服務組件34(如一 Java服務組件34的Java虛擬機器）及基礎設施服務所需要的執行期間環境，而入站連接器32處理與用戶端應用程式的通訊以及通過介面36至組件祠服器30的QOS元件58 的處理。服務組件34提供了一需要暴露為一服務的商業功能（作為應用程式邏輯執行）。以下為伺服器1 4上資訊流之描述。入站連接器3 2使用 HTTP發送及接收一來自一用戶端12並包含請求包絡50白勺服務請求。入站連接器32接收請求包絡50並擷取QOS元件 5 8及請求酬載5 4。然後入站連接器3 2處理從請求包絡5 〇擷取的QOS元件58。特定言之，入站連接器32使用介面36 從組件伺服器3 0請求服務，如建立一安全性情景或開始_ 交易。然後’入站連接器32使用介面38將包含於請求酬載 582147 (12) 54的應用程式資料傳送至服務組件34。服務組件34接收包含於請求酬載54中的應用程式資料，並執行任何需要的應用程式邏輯。在處理包含於請求酬載54中的應用程式資料的過程中’服務組件34也邊夠藉由介面並利用組件伺服器3 0的基礎設施服務。一般而言，服務組件3 4處理q 〇 s 元件5 8時會使用入站連接器3 2設置的一安全性情景或一資源協調情景。服務組件34通過介面38返回一響應至入站

連接器32,其會將該響應封裝為響應酬載56。入站連接器 3 2藉由介面3 6從組件伺服器3 0獲取任何必要的q 〇 s元件 6 〇 ’然後將該些Q 〇 s元件6 0及響應酬載5 6封裝於響應包絡中52中。可能不需要響應包絡52中的q〇s元件60。如果需要QOS元件，其一般係安全性或交易資訊。然後將響應包絡52返回至用戶端12。在較佳具體實施例中，一企業對企業應用程式能夠使用 HTTP向用戶端提供同一組月艮務，並使用一訊息中介軟體（如國際商業機器公司提供的MQSedes)來發送應用程式。為適應該多種協定及中介軟體產品，入站連接器32之結構允許堆叠入站連接器以在不同傳輸通訊協定上實作該相同的介面3 8。圖3所示的係說明在一伺服器丨4上堆疊入站連接器3 2之方塊圖。特定言之，圖3顯示了使用入站連接器32在HTTP 之上貫作該簡易物件存取協定（SOAP)。HTTP是一傳輸通訊 ’ 協定，而SOAP是用於企業對企業交流的較高等級的協定 ’其可用於各種傳輸通訊協定之上，如HTTP，SMTP (簡易 -17- 582147 (13) [mmm 郵件傳輸協定）或Sun Microsystems提供的JMS (Java訊息服務）。飼服器1 4可能包含複數個入站連接器3 2，每一連接器操作不同類別的通訊協定。特定言之，入站連接器3 2可能係刀層的’因此實作一種協定的入站連接器3 2可能會將一請 v 长傳送至貫作不同協定的另一入站連接器32。如圖3所示，入站連接器32a實作HTTP，而入站連接器 32b貫作SOAP。因此，在圖3中，HTTP請求酬載54實際上是SOAP請求包絡54。當伺服器14接收一請求時，入站連鲁接器3 2 a負貴打開HTTP請求包絡5 0，並處理對應的Q 〇 s元件58 ’然後將請求酬載54(s〇Ap請求包絡54)藉由介面38a 傳送至下一入站連接器32b。入站連接器32b接收HTTP酬載54 (SOAP請求包絡54)，並負貴打開SOAP請求包絡54，處理對應的QOS元件62，然後將在SOAP請求包絡54中找到的SOAP請求酬載64發送至下一入站連接器32(如果有的話）。如圖3所示，如果入站連接器32b位於入站連接器32的堆疊之最低處，其會擷取SOAP請求酬載64並將其直接傳送鲁到服務組件3 4。熟習此項技藝者會發現入站連接器3 2能夠遵守任何協定，以及堆疊任何數量的入站連接器，而不脫離本發明。以下是圖3中說明的使用HTTP上的SOAP將一服務請求發 > 送至伺服器14時的功能的邏輯流程。HTTP入站連接器32a ·· 以HTTP請求包絡5 0的形式接收HTTP中的服務請求。然後 HTTP入站連接器32a從HTTP請求包絡50擷取QOS元件58及 -18- 582147

HTTP請求酬載54 (SOAP請求包絡54)。HTTP人站連接器32a 使用介面36a來處理擷取的QOS元件58。然後HTTP入站連接器32a使用介面38a將HTTP請求酬載54( SOAP請求酬載54) 發送至SOAP入站連接器32b。SOAP入站連接器32b使用介面36b擷取並處理特定SOAP的QOS元件62。然後入站連接器3 2b擷取SOAP請求酬載64，並將其發送至執行任何請求的應用程式邏輯的服務組件3 4。然後，服務組件3 4通過介面38b將一響應返回至SOAP入站連接器32b。然後SOAP入站連接器32b使用介面36b來獲取任何必要的Q〇s元件66 並將其與SOAP響應包絡56内部的SOAP響應酬載68 —起封裝。然後SOAP響應包絡56返回至HTTP入站連接器32a ,此處其作為HTTP響應酬載56放置於HTTP響應包絡52中。然後HTTP入站連接器32a使用介面36a將QOS元件60加至 HTTP響應包絡52，然後使用HTTP將HTTP響應包絡52發送回至該用戶端1 2。

HTTP入站連接器32a及SOAP入站連接器32b間的介面 3 8a與SOAP入站連接器32b及服務組件34間的介面38b是相同的。因此可以靈活使用入站連接器。可以根據傳送中使用何種協定而使用不同的入站連接器，如果必要可以使用分層的，無論使用何種協定傳輸，最終都會使用相同的介面38將互動傳送至服務組件34。圖4所示的系一伺服器1 4上實作的入站連接器3 2的組件的示意圖。入站連接器3 2的實作包含下列的類別及相關介面：ServiceFactory 80、Service 82、ManagedServiceFactory 84、 -19- 582147 vA 』

ManagedService 86及ManagedServiceProcessingSpec 87。此夕卜，組件伺服器 30 實作 ServiceManager 88，ServiceEventListener 90 以及QOS服務92的類別。也存在ServiceException(未顯示於圖4中），其係用於報告錯誤的例外類別（使用Java例外機制）。該些類別一起形成發明者所稱的「一處理核心」。

ServiceFactory類別80代表能夠建立Service 82實例的物件。不過，ServiceFactory 80不保存對Service 82的情景的參考〇 ServiceFactory 80與 ServiceManager 88—起運作以分配及控制對用戶端1 2的實體連接的控制數集區。更特定言之，

ServiceFactory 80的一實例保存對 ServiceManager 88的參考，並與 ManagedServiceFactory 84相關。ServiceFactory 80藉由調用 ServiceManager 88之 allocateService 方法得到 Service 82 的一實例（以下將更詳盡地描述）。ServiceFactory 80之介面如下 public interface ServiceFactory extends java.io.Serializable { Service getService();

}

Service 82表示對一用戶端12之實體連接之控制數。 ServiceFactory 80藉由調用 ServiceManager 88之 allocateService 方法建立 Service 82實例。Service 82實例與 ManagedService 86 實例相關。Service 82負貴從用戶端12接收一互動請求並將其傳送至相關的ManagedService 86(結果其調用目標服務組件 34)，以及從 ManagedService 86傳送一響應。Service 82具有以下介面： -20- 582147

發明戴明績頁 public interface Service { public javax.resource.cci.Record execute ( j av ax. re source.cci. Inter act ion Spec interaction Spec, javax. re source, cci. Re cord inputRecord) throws javax .re source .Re sour ceExcept ion; public Boolean execute(

javax. re source, cci. Interact ion Spec interaction Spec, javax.resource.cci.Record inputRecord, javax. re source, cci. Re cord outputRecord) throws javax .re source. Res ourceExcepti on;

Service 82由入站連接器32及服務組件34來實作。Service 82之執行方法執行一入站連接器互動。ManagedService 86 呼叫 ManagedServiceProcessingSpec 87之 getlnteractionSpec方法以得到一 InteractionSpec。一 InteractionSpec 包含指定一互動細節的特性。該組特性是連接器細節。例如，一 HTTP連接器具有HTTP特性，如内容類別、標題欄、動詞（如得到或張貼）。該InteractionSpec之内容允許一入站連接器32選擇適當的服務組件 34。然後 ManagedService 86將 InteractionSpec 傳送至Service 82的執行方法。Service 82之執行方法之 inputRecord包含互動請求資料。一旦從Service 82之執行方法返回，執行方法之outputRecord包含任何互動響應資料。 -21 - 582147 (17) 服務組件34藉由執行適當的應用程式邏輯來實作Service 82的執行方法。發明者所言之應用程式邏輯意味著對實作該執行方法必要之邏輯。通常一開發者會著眼於該

InteractionSpec及資料輸入記錄以實作請求的功能（如查詢一資料庫或更新文件）。一入站連接器3 2會藉由以連接器指定的方式將該互動指派給ManagedService 86之相關實例來執行Service 82類別之執行方法（即以呼叫序列，方法名稱及其它實作因素表示的特定連接器實作特徵）。此結構允許該入站連接器32的實作者利用相關的ManagedService 86來盡力滿足其需要。

ManagedServiceFactory 84 是一能夠建立 ManagedService86 實例的類別。ManagedServiceFactory 84的介面如下： extends

public interface ManagedServiceFactory java.io.Serializable {

ManagedService createManagedService();

Object createServiceFactory();

Object createServiceFactory(ServiceMananger serviceManager);

ManagedServiceFactory 84表示能夠建立 ManagedService 86 實例及 ServiceFactory 80實例之物件。不過 ’ ManagedServiceFactory 84不保存對一建立的 ManagedService 86之參考。ManagedServiceFactory 84之 createManaged Service 方 -22- 582147 VSJ, ^ '如沪， * * v (18) 發嘛明扉' 法建立一新的 ManagedService 86 的實例。 ManagedServiceFactory 84 之 createServiceFactory 建立一新的 ServiceFactory 80的實例，其與 ManagedServiceFactory的實例相關，並將ServiceManager 88的介面的實例傳送至建立的

ServiceFactory 80。

ManagedService 86表示一服務組件34的一連結控制數。 ManagedServiceFactory 84 會建立 ManagedService 86 實例。 ManagedService 86能夠支援多個Service 82，儘管在本實作中每次只有一項Service 82實例能夠與服務組件34互動。熟習此項技藝者會發現多重執行緒及同步使用者的使用是可能的，不過發明者已選擇不提供較佳具體實施例中的該功能。ManagedService 86負貴從輸入請求擴取任何Q0S元件及將任何通過 ServiceEventListener 90的QO S請求通知組件伺服器3 0。組件伺服器3 0負貴建立任何QOS 92的實例以處理來自 ServiceEventListener 90的請求。然後調用

ManagedServiceFactory 84 及 ManagedService 86 。

ManagedServiceFactory 84利用 Q0S 92以建立一 ManagedService 86的實例集區。因此，如果ManagedService 86的一實例存在於該集區中，並滿足特定的安全性或其他Q0S 92指定的交易特徵，那就會使用該實例。如果沒有ManagedService 86 滿足QOS 92的要求，ManagedServiceFactory 84就會建立一新的 ManagedService 86 的實例。ManagedService 86 使用 ServiceEventListener 90之驗證方法來處理任何在Q0S 92指定的安全性。ManagedService 86具有以下介面： -23- 582147

(19) public interface ManagedService { void addServiceEventListener(ServiceEventListener serviceEventListener); java.io. Print Writer getLogWriter(); java.lang.Object getService(); void removeServiceEventListener(ServiceEventListener serviceEventListener);

void setLogWriter(java.io.PrintWriter logWriter);

ManagedService 86包含負貴處理與服務組件34的互動之物件。ManagedService 86呼叫 ManagedServiceProcessingSpec 87 之 getServiceFactory 方法，其藉由呼叫 ManagedServiceFactory 84 之 createServiceFactory 方法而提供一 ServiceFactory 80之實例。然後 ManagedService 86呼叫 ServiceFactory 80的 getService方法，其返回一新的Service 82的實例。為了調用Service 82的執行方法並將必要資訊傳送至目標服務組件34， ManagedService 86 需要 inputRecord 及 outputRecord，以及一 InteractionSpec(包含一互動的與連接器相關之特性）。 ManagedService 86 具有 inputRecord 及 outputRecord，並藉由在 ManagedServiceProcessingSpec 87 中之介面獲取 InteractionSpec 。一旦獲取 InteractionSpec，ManagedService 86就會具有所有必要的資料，並通過Service 82的執行方法將資料傳送至服 •24- 582147

(20) 務組件3 4。

ServiceManager 88 使用 ManagedService86 之 addServiceEventListener方法以註冊一具有 ManagedService 86 的 ServiceEventListener 90 〇 ManagedService 86將任何 QOS 相關事件通知所有的ServiceEventListener 90(例如在處理一入站互動之前需要驗證）。

ManagedServiceProcessingSpec 87是用於保存 InteractionSpec 及 ServiceFactory 80 之參考的一類別。 ManagedServiceProcessingSpec 類別 87 具有下列介面： public interface ManagedServiceProcessingSpec extends java.io.Serializable { javax.resource.cci.InteractionSpec getlnteractionSpec(); com.ibm.service.cci.ServiceFactory getServiceFactory(); void s etlnt eract i on Spe c(javax. res ource.cci. Interact! on Spec

interactionSpec); void set ServiceFactory (com.ibm.service.cci. ServiceFactory

ServiceFactory); 藉由本發明之實作者選擇的方法初始化 ManagedServiceProcessingSpec 87。通常這可藉由設定或配置描述元而完成。

ServiceManager 88是由組件伺服器30實作以支援入站連 -25- 582147 (2〇接器的一類別。ServiceManager 88提供組件伺服器30，其具有協調及控制一伺服器82所用的資源的能力。 ServiceManager 88具有以下介面·· public interface ServiceManager extends java.io.Serializable { java.lang.Object allocateService(ManagedServiceFactory managed ServiceF actory);

ServiceManager 88之 allocateService 方法提供了一種使入站連接器32將服務分配請求發送至組件伺服器30的方式。組件伺服器30提供了服務品質（QOS)92如安全性、交易管理或一服務請求的記錄，然後將Service 82的實例的實際建立委派給 ManagedServiceFactory 84 〇

ServiceEventListener 90是由組件伺服器30實作以支援入站連接器32的一類別。ServiceEventListener 90接收來自

ManagedService 86的實例的事件，並在組件祠服器30内部實作對應的操作，如建立及處理任何需要的QOS 92。 ServiceEventListener 90的介面如下： public interface ServiceEventListener extends java.util.EventListener { void authenticate(javax.security.auth.Subject subject) throws com.ibm.service.ServiceException; -26- 582147 (22) 發明說圈秀Μ

ServiceEventListener 90的介面允許其從 ManagedService 86 的實例接收與QOS有關的事件。使用ManagedService 86之 addServiceEventListener方法將的實例與一 ManagedService 86 一起註冊 ’ ManagedService 86呼叫 ServiceEventListener 90的驗證方法，以在調用Service 82之執行方法及將該互動傳送至目標服務組件3 4之前驗證一入站互動。

該ServiceException類別延伸了 Java例外類別，並用於報告入站連接器錯誤。多個類別在執行期間可能使用 ServiceException類別，其未顯示於圖 4 中。ServiceException 類別9 1的介面如下： public class ServiceException extends Exception { public ServiceException(); public ServiceException(String s);

現在參考圖5，其一般將說明一入站連接器32建立一 Service 82的過程之流程圖顯示為100。從步驟 102 開始，ManagedService 86 17乎叫

ManagedProces sing Spec 87 之 getServiceFactory 方法，其藉由呼叫 ManagedServiceFactory 84之 createServiceFactory 方法而建立 ServiceFactory 80的實例。在步驟 104，ManagedService 86呼叫 -27- 582147

(23)

ManagedServiceFactory 84 之 getService 方法。在步驟 106

ServiceFactory 80 調用 ServiceManager 88 的 allocateService 方法。在步驟1 0 8，作一測試以決定在實例集區中是否存在 ManagedService 86的未使用的實例。如果不存在實例，處理就轉到步驟1 1 0，ManagedServiceFactory 84在此處建立了一新的ManagedService 86的實例，並將處理轉到步驟1 1 2。如果步驟1 0 8的測試指示存在一實例，那麼就會利用該實例，並將處理轉到步驟1 1 2。在步驟1 1 2，ManagedService 86 啤叫 ServiceFactory 80之 getService 方法以建立一新的 Service 82的實例。根據 ManagedService 86的蓄集，ServiceManager 88保存了每個一建立，使用然後釋放（即其不再用於對一請求提供服務）的 ManagedService 86的列表。在不再需要

ManagedService86時，ServiceManager 88不是將其放棄，而是儲存並在必要時再利用，因此就減少了建立新的 ManagedService 86的實例的需要，從而提高組件伺服器30 的效率。熟習此項技藝者會發現所提議之結構只是建議蓄集，但並未執行，是否執行蓄集由每個ServiceManager類別 8 8的實作者來決定。現在參考圖6，其一般將說明一入站連接器32對一請求服務的過程的流程圖顯示為200。從步驟202開始， ManagedService 88從步驟 204 之 ManagedServiceProcessingSpec 87 獲取一 InteractionSpec 實例。然後 ManagedS七rvic0 88 呼叫 Service 82的執行方法，其將InteractionSpec的實例作為一執 -28- 582147 (24) 行參數傳送 (24)

在步騾206選擇了目標服務組件 34 。在步驟2 0 8，作出了目標服務組件3 4的應用程式邏輯是否支援只具有輸入參數的執行方法的調用格式的決定。如果有

NotSupp〇rted例外，那麼在步驟 210 ManagedService 86會建立

OutputRecord並將其傳送至該執行方法，此處處理返回至步驟2 0 6。如果在步驟2 0 8沒有例外，那麼處理繼續前進至步驟212，此處獲得結果並將其返回至ManagedService 86。在圖5及6顯示的特定方案中，未說明連接器（參見圖㈠

的堆疊能力。入站連接器32的堆疊能力意味著會按圖5及6 中說明的序列執行堆疊中每個入站連接器3 2，直到所有的連接器32都已完成處理。儘管此處揭示的發明在Javaw J2EE連接器架構⑽邱 Connector Architecture)文中有所描述，熟習此項技藝者會發現本發明很容易修改以適應其他環境及程式語言，並且這種修改在申請專利範圍所定義的本發明的範疇之内。° 儘管已參照某些特定的明，但熟習此項技藝者仍可作各種的申請專利範圍中概述的本發明的具體實施例對本發明進行了說變更，而不脫離在所附精神及範疇。

•29- 582147 (25) 圖式代表符號說明元件編號中文 10 企業對企業系統 12 用戶端 14 伺服器 16 組件伺服器 18 服務代理 20 出站連接器 22 介面 24 介面 26 介面 28 網路 30 組件伺服器 32 入站連接器 34 服務組件 36 介面 38 介面 40 介面 50 請求包路 52 響應包路 54 請求酬載 56 響應酬載 58 服務品質元件 60 服務品質元件 32a 入站連接器 32b 入站連接器 36a 介面 36b 介面 38a 介面 38b 介面 62 服務品質元件 64 請求酬載

-30- 582147 (26) 發明寧:明續頁 66 服務品質元件 68 響應酬載 80 ServiceFactory 82 Service 84 Manage ServiceFactory 86 ManageService 87 Managed ServiceProcessing Spec 88 ServiceManager 90 ServiceEventListene 92 QOS服務 100 流程圖 102 請求服務 104 獲取服務 106 配置服務 108 未用的 managed service 110 建立新的 managed service 112 建立 service 200 流程圖 202 執行 204 提供服務處理spec 206 目標服務 208 Not supported例夕卜 210 建立輸出記錄 212 返回輸出記錄

-31 ·

Claims

582147 拾、申請專利範圍 1 . 一種與一通訊網路通訊的電腦系統，該電腦系統包括 a) 一組件伺服器，提供服務予一項一或多個服務組件及一或多個入站連接器； b) 每一該服務組件提供應用程式邏輯；以及 c) 該等服務組件提供一組介面予複數個電腦系統，該組介面獨立於該複數個電腦系統，與該通訊網路通訊的該入站連接器，該組件伺服器以及該服務組件所擁有的中介軟體。 2 .如申請專利範圍第1項之電腦系統，其中該入站連接器包含： a) 一用於接收來自一電腦系統的請求的網路介面，該電腦系統連結至該通訊網路； b) —處理核心，該處理核心適用於從該網路介面接收該請求並決定由該一或多個服務組件中的哪個來處理該請求；以及 c) 一與該處理核心及該一或多個服務組件中的每個通訊的介面，藉由該介面傳送該請求並將一響應返回至該處理核心，該處理核心適用於將該響應返回至該電腦系統，其連結至該通訊網路。 3 .如申請專利範圍第2項之系統，其中可能會複製每個該入站連接器以提供一組堆疊入站連接器。 582147 4 .如申請專利範圍第3項之系統，其中該組堆疊入站連接器中的每個入站連接器實作與該組堆疊入站連接器中在其下面的入站連接器不同的通訊協定。 5 .如申請專利範圍第4項之系統，其中位於該組堆疊入站連接器底部的一基礎入站連接器與該服務組件通訊其中之一，並從該服務組件其中之一接收該響應。 6 .如申請專利範圍第5項之系統，其中該響應從該基礎入

站連接器傳達至該組堆疊連接器中的下一最低入站連接器。 7 . —種建立與一服務組件通訊的服務之方法，該方法包含以下步驟： a) 請求該服務； b) 如果該服務的一實例是可用的，就利用該服務之該實例；以及 c) 如果該服務的一實例是無法使用的，就建立該服務的一實例。

8 .如申請專利範圍第7項之方法進一步包括下列步驟： d) 獲取一資訊規格； e) 調用以該資訊規格為參數的該服務； f) 如果需要一輸出記錄，就建立該輸出記錄並返回至步驟b); g) 返回步驟 e) 之結果。 9. 一種與一通訊網路通訊之電腦系統，該電腦系統包含： 582147

a) 向一或多個服務組件及一或多個入站連接器提供服務之裝置； b) 提供每個該服務組件的應用程式邏輯之裝置；以及 c) 向複數個電腦系統提供一組介面之裝置，該組介面獨立於，複數個電腦系統，與該通訊網路通訊的該入站連接器，該組件伺服器以及該服務組件所擁有之中介軟體。

10. 如申請專利範圍第9項之電腦系統，其中該入站連接器包含： a) 實作一網路介面以接收來自一電腦系統之請求的裝置，其中該電腦系統連結至該通訊網路； b) 實作一處理核心之裝置，該處理核心適用於接收來自該網路介面的請求並決定由該一或多個服務組件中的哪個來處理該請求；以及

c) 實作與該處理核心及每個該一或多個服務組件中通訊的介面之裝置，藉由該介面傳送該請求並將一響應返回至該處理核心，該處理核心適用於將該響應返回至該電腦系統，其連結至該通訊網路。 11. 如申請專利範圍第1 0項之系統，其中可能會複製每個該入站連接器以提供一組堆疊入站連接器。 12. 如申請專利範圍第1 1項之系統，其中該組堆疊入站連接器中的每個入站連接器實作與該組堆疊入站連接器中在其下面的入站連接器不同的通訊協定。 582147

13. 如申請專利範圍第1 2項之系統，其中位於該組堆疊入站連接器底部的一基礎入站連接器與該服務組件其中之一通訊，並從該服務組件其中之一接收該響應。 14. 如申請專利範圍第1 3項之系統，其中該響應從該基礎入站連接器傳達至該組堆疊連接器中的下一最低入站連接器。. 15. —種包含使一電腦系統與一通訊網路通訊的指令的電腦可讀媒體，該媒體包含：

a) 向一或多個服務組件以及一或多個入站連接器提供服務的一組件伺服器的指令； b) 具有提供應用程式邏輯的指令的每個該服務組件；以及 c) 提供指令以實作複數個電腦系統的一組介面的該服務組件，該組介面獨立於該複數個電腦系統，與該通訊網路通訊的該入站連接器，該組件伺服器以及該服務組件所擁有的中介軟體。

16. 如申請專利範圍第1 5項之媒體，其中該入站連接器包含： a) 提供一網路介面以接收來自一電腦系統的請求之指令，其中該電腦系統連結至該通訊網路； b) 提供一處理核心之指令，該處理核心適用於接收來自該網路介面的請求並決定由該一或多個服務組件中的哪個來處理該請求；以及 c) 提供與該處理核心及每個該一或多個服務組件 -4- 582147 电鱗讎園績買：中通訊的介面之指令，藉由該介面傳送該請求並將一響應返回至該處理核心，該處理核心適用於將該響應返回至該電腦系統，其連結至該通訊網路。 17. 如申請專利範圍第1 6項之媒體，其進一步提供指令以複製每個該入站連接器來提供一組堆疊入站連接器。 18. 如申請專，利範圍第1 7項之媒體，其中該組堆疊入站連接器中的每個入站連接器實作與該組堆疊入站連接器中在其下面的入站連接器不同的通訊協定。 19. 如申請專利範圍第1 8項之媒體，其中位於該組堆疊的入站連接器底部的一基礎入站連接器與該服務組件其中之一通訊，並從該服務組件其中之一接收該響應。 20. 如申請專利範圍第1 9項之媒體，其中該響應從該基礎入站連接器傳達至該組堆疊的連接器中的下一最低入站連接器。