當(dāng)前位置:工程項(xiàng)目OA系統(tǒng) > 泛普各地 > 河北O(jiān)A系統(tǒng) > 石家莊OA系統(tǒng) > 石家莊OA信息化
bindingTemplate與Web服務(wù)調(diào)用
bindingTemplate與Web服務(wù)調(diào)用
柴曉路 (fennivel@uddi-china.org)
Chief System
Architect
2001年11月22日
本文通過介紹UDDI數(shù)據(jù)模型中的bindingTemplate數(shù)據(jù)實(shí)體,對如何使用bindingTemplate中的信息實(shí)施Web服務(wù)調(diào)用進(jìn)行了討論,闡明了利用緩存bindingTemplate加速服務(wù)多次調(diào)用的方法,也介紹了在災(zāi)難恢復(fù)的情況下如何再次緩存的方法。同時(shí)通過對hostingRedirector的功能的分析,介紹了簡單間接模式和重定向模式對于非直接提供服務(wù),而是由ASP供應(yīng)商提供服務(wù)這一模式的重要性。
Web服務(wù)的技術(shù)描述是通過單獨(dú)包含的bindingTemplate結(jié)構(gòu)的實(shí)例來實(shí)現(xiàn)的。這些結(jié)構(gòu)提供對決定技術(shù)入口點(diǎn)的支持,或者可選地支持遠(yuǎn)端主機(jī)宿主的服務(wù),同時(shí)還提供一個(gè)輕量級的工具用于描述指定服務(wù)實(shí)現(xiàn)的唯一技術(shù)特征。技術(shù)和應(yīng)用相關(guān)的參數(shù)和配置文件也同時(shí)被支持。
由于UDDI的主要作用是用來描述和發(fā)現(xiàn)Web服務(wù)信息,所以bindingTemplate被用來描述最令人感興趣的技術(shù)信息。
每一個(gè)bindingTemplate結(jié)構(gòu)都有一個(gè)單一的businessService邏輯父結(jié)構(gòu),并且該businessService也有一個(gè)單一的businessEntity邏輯父結(jié)構(gòu)。
bindingTemplate結(jié)構(gòu)規(guī)范
下層子結(jié)構(gòu)說明
下面用粗體表示的字段是必要字段,必須出現(xiàn)。
accessPoint和hostingRedirector子元素應(yīng)當(dāng)必須出現(xiàn)一種,并且僅能出現(xiàn)一種。
名為tModelInstanceDetails 的結(jié)構(gòu)的內(nèi)容可以在bindingTemplate結(jié)構(gòu)中被發(fā)現(xiàn)同時(shí)是作為技術(shù)指紋服務(wù)于服務(wù)描述的。這一技術(shù)指紋是一系列對可唯一標(biāo)識的規(guī)范和/或概念的引用。為了實(shí)現(xiàn)一個(gè)與某個(gè)tModel兼容的新的服務(wù),該tModel所對應(yīng)的規(guī)范是必須被正確理解的。而為了注冊一個(gè)服務(wù)并聲明它是與某個(gè)規(guī)范相兼容的,那么應(yīng)當(dāng)在該服務(wù)下的bindingTemplate實(shí)例中的tModelInstanceDetails下包含一個(gè)對該規(guī)范的tModel的引用,引用的鍵值是tModelKey。
accessPoint
accessPoint元素是一個(gè)由屬性修飾的指向服務(wù)入口點(diǎn)的指針。在這里表示的元數(shù)據(jù)層次的服務(wù)概念是相當(dāng)抽象的,同時(shí)在這里出現(xiàn)很多服務(wù)入口點(diǎn)的類型都是合適的。
一個(gè)名為URLType的屬性被提供用于修飾accessPoint元素。設(shè)置該屬性的目的是為了查找匹配指定服務(wù)入口點(diǎn)類型的那些特定服務(wù)入口點(diǎn)。例如,一個(gè)采購訂單服務(wù)提供了3個(gè)入口點(diǎn),一個(gè)是基于HTTP,一個(gè)是基于SMTP的,還有一個(gè)是基于FAX的。在這個(gè)例子中,我們就可以去查找一個(gè)businessService元素,該元素包含有個(gè)3個(gè)bindingTemplate條目,每一個(gè)都包含相同的數(shù)據(jù),除了accessPoint的值及其附帶的URLType的值是不同的。
URLType的有效值包括:
mailto: 表明accessPoint的內(nèi)容字符串是電子郵件的格式。(例如,mailto:program@uddi-china.org)
http:
表明accessPoint的內(nèi)容字符串是一個(gè)兼容HTTP規(guī)范的URL(統(tǒng)一資源定位符)的格式。(例如,http://www.fabrikam.com/purchasing)
https: 表明accessPoint的內(nèi)容字符串是一個(gè)兼容安全HTTP規(guī)范的URL(統(tǒng)一資源定位符)的格式。(例如,https://www.fabrikam.com/purchasing)
ftp:
表明accessPoint的內(nèi)容字符串是一個(gè)可寫的FTP目錄地址的格式。 (例如,ftp://ftp.dealeasy.com/public)
fax:
表明accessPoint的內(nèi)容字符串是一個(gè)可連入某個(gè)傳真機(jī)的電話號碼的格式。(例如,1 425 555 5555)
phone:
表明accessPoint的內(nèi)容字符串是一個(gè)可與某人聯(lián)系或與某個(gè)語音/音頻響應(yīng)系統(tǒng)相關(guān)聯(lián)的電話號碼的格式。 (例如,1 425 555 5555)
other:
表明accessPoint的內(nèi)容字符串是其他的尋址格式。當(dāng)使用該值時(shí),一個(gè)或多個(gè)在tModelInstanceInfo聚集中的tModel必須蘊(yùn)含一個(gè)必需的特定格式或傳輸類型。
hostingRedirector
hostingRedirector元素被用來表明這個(gè)bindingTemplate條目是一個(gè)指向另外一個(gè)bindingTemplate的指針。當(dāng)一個(gè)商業(yè)實(shí)體想發(fā)布一個(gè)服務(wù)描述(例如,宣布他們有一個(gè)特定用途的服務(wù)已經(jīng)可用了),而這個(gè)服務(wù)已經(jīng)在另一個(gè)獨(dú)立的bindingTemplate中被描述了,此時(shí)就會使用這種機(jī)制。該情況可能發(fā)生于,當(dāng)服務(wù)是部署在遠(yuǎn)端主機(jī)上的(這也是本元素名字的由來),或是當(dāng)很多的服務(wù)描述可以基于一個(gè)單一的服務(wù)描述。
hostingRedirector元素只有一個(gè)單一的屬性而沒有元素的內(nèi)容。這個(gè)屬性是一個(gè)bindingKey值(UUID),這個(gè)bindingKey值可以用于在同一個(gè)UDDI注冊中心實(shí)例中查詢和獲取將要被使用的bindingDetail數(shù)據(jù)。
關(guān)于hostingRedirector元素的使用,我們將在后面詳細(xì)給出。
tModelInstanceDetails
這個(gè)結(jié)構(gòu)是一個(gè)或多個(gè)tModelInstanceInfo結(jié)構(gòu)的簡單容器。當(dāng)以一個(gè)信息組的形式被使用的時(shí)候,在tModelInstanceDetails結(jié)構(gòu)中描述的數(shù)據(jù)就形成一個(gè)描述性的技術(shù)指紋,這個(gè)技術(shù)指紋是通過在這個(gè)結(jié)構(gòu)中包含了一個(gè)無順序的tModelKey引用的列表而表現(xiàn)的。也就是說,如果有用戶注冊了一個(gè)bindingTemplate(在一個(gè)businessEntity數(shù)據(jù)集內(nèi)),那么它就會包含一個(gè)或多個(gè)對于特定的并且是可標(biāo)識的規(guī)范的引用,這些規(guī)范是在注冊過程中通過tModelKey值所蘊(yùn)含的。在對于一個(gè)服務(wù)的查詢過程中,有興趣的用戶會利用這些信息來尋找一個(gè)特定的包含有一個(gè)甚至多個(gè)指定的tModel引用的bindingTemplate。如果通過這個(gè)方式來注冊特定的技術(shù)指紋,那么軟件開發(fā)人員就能夠很容易地以這種方式表示出他們所提供的服務(wù)能夠與tModelKey所蘊(yùn)含的規(guī)范相兼容。
基于bindingTemplate的服務(wù)調(diào)用模式
當(dāng)我們需要編制實(shí)現(xiàn)一個(gè)應(yīng)用程序:這個(gè)應(yīng)用程序需要使用一個(gè)已被其它商業(yè)實(shí)體注冊在UDDI注冊中心的遠(yuǎn)端Web服務(wù),那么你需要從注冊中心中發(fā)現(xiàn)為調(diào)用指定服務(wù)所需要的調(diào)用規(guī)范信息,并在程序編制時(shí)使用。這種類型的跨商業(yè)實(shí)體的服務(wù)調(diào)用在傳統(tǒng)上將被視為是開發(fā)階段的任務(wù)。盡管,這樣的開發(fā)模式并不會因UDDI注冊信息的出現(xiàn)而完全改變,但起碼,如果使用了UDDI注冊所支持的特別的調(diào)用模式,將可以解決一個(gè)非常顯著而重要的問題。
從UDDI注冊中心中獲得的bindingTemplate信息集中的數(shù)據(jù)表示了一個(gè)指定的遠(yuǎn)端Web服務(wù)的調(diào)用規(guī)范實(shí)例。程序應(yīng)當(dāng)緩存該信息并且使用這個(gè)調(diào)用規(guī)范通過該Web服務(wù)注冊的地址來訪問這個(gè)Web服務(wù)。使用以前流行的遠(yuǎn)程過程調(diào)用技術(shù)的工具已經(jīng)能夠?qū)⑦@樣一種工作自動化地實(shí)現(xiàn),無論是通過緩存其調(diào)用位置或是通過寫入固定代碼的方式,都可以做到。然而,當(dāng)遠(yuǎn)程服務(wù)在沒有通知調(diào)用者的情形下發(fā)生了遷移,那么就會引起問題,該程序無法自動地更新訪問代碼或訪問地址。這樣的遷移可以是由各種原因造成的,包括服務(wù)器升級,災(zāi)難恢復(fù)以及服務(wù)入口或企業(yè)名稱的改變等。
當(dāng)使用從UDDI注冊表中獲得并緩存下來的信息進(jìn)行調(diào)用發(fā)生失敗時(shí),正確的做法是去查詢當(dāng)初獲得該數(shù)據(jù)的UDDI注冊中心并獲取與其對應(yīng)的更新了的bindingTemplate信息。正確的調(diào)用是使用get_bindingDetails,并傳入原始的bindingKey鍵值。如果返回的數(shù)據(jù)與緩存的信息不同,那么應(yīng)該使用新的調(diào)用信息來重新嘗試服務(wù)調(diào)用。如果這一重試操作獲得成功的話,新的信息應(yīng)當(dāng)取代原先緩存的信息進(jìn)入當(dāng)前的緩存。
在使用Web服務(wù)中,使用這樣的調(diào)用模式,那么使用UDDI操作入口站點(diǎn)(Operator Site)的商業(yè)實(shí)體就得以在不加重通信與協(xié)調(diào)開銷的情況下自動完成與大量合作伙伴的服務(wù)恢復(fù)。例如,如果一個(gè)企業(yè)激活了一個(gè)災(zāi)難恢復(fù)站點(diǎn)以取代某個(gè)崩潰的原服務(wù)提供站點(diǎn),來自合作伙伴的大部分調(diào)用想訪問那個(gè)已經(jīng)崩潰的服務(wù)提供站點(diǎn)時(shí),會遭遇失敗。通過把新的提供服務(wù)的地址更新到UDDI信息中,那些使用調(diào)用模式的合作者將可以自動地獲取新的服務(wù)調(diào)用信息并在無需管理員介入的情況下恢復(fù)系統(tǒng)連接。
這一過程的詳細(xì)程序式描述如下:
服務(wù)提供者使用save_xx在UDDI注冊中心中注冊了Web服務(wù)S;
調(diào)用者使用find_xx查詢UDDI注冊中心,獲得所需的服務(wù)S的概要信息;
調(diào)用者使用get_xx再一次查詢UDDI注冊中心,獲得所需服務(wù)S的詳細(xì)信息;
調(diào)用者緩存服務(wù)S的bindingTemplate信息,通過服務(wù)綁定,實(shí)施對服務(wù)S的調(diào)用;
服務(wù)S由于某種原因出現(xiàn)問題,無法繼續(xù)提供服務(wù);
服務(wù)提供者在新的位置重新部署了服務(wù)S,同時(shí)更新了UDDI注冊中心的關(guān)于Web服務(wù)S的技術(shù)描述;
調(diào)用者使用緩存的服務(wù)S的bindingTemplate信息再一次進(jìn)行調(diào)用,調(diào)用失??;(服務(wù)S的部署位置已經(jīng)更改)
調(diào)用者使用緩存的bindingTemplate的bindingKey鍵值查詢UDDI注冊中心,獲得服務(wù)S的更新后的bindingTemplate信息。
調(diào)用者緩存服務(wù)S的新的bindingTemplate信息,通過服務(wù)綁定,重新實(shí)施對服務(wù)S的調(diào)用。
服務(wù)重定向
在許多情況下,在get_bindingDetail消息中定義的API是直接的。當(dāng)一個(gè)企業(yè)或應(yīng)用程序知道需要調(diào)用的服務(wù)時(shí),該服務(wù)相關(guān)的bindingTemplate信息就可以被緩存以供使用。如果緩存信息在真正需要被調(diào)用時(shí)發(fā)生失敗的話(比如被緩存的bindingTemplate結(jié)構(gòu)的accessPoint信息被用于調(diào)用一個(gè)遠(yuǎn)程的合作伙伴所提供的服務(wù)),該應(yīng)用可以通過被緩存的信息中的bindingKey來得到一個(gè)bindingTemplate信息的最新副本。這種緩存操作可以避免多余的對注冊中心的訪問。
然而在一些情況下,通過get_bindingDetail消息獲得的bindingTemplate所描述的信息并非是直接的某個(gè)Web服務(wù)的綁定信息,在這個(gè)bindingTemplate中可能通過hostingRedirector機(jī)制指向了另一個(gè)bindingTemplate,而由這個(gè)bindingTemplate完成對目標(biāo)服務(wù)的最終描述。這就是間接描述的使用方式。
需要使用hostingRedirector的特殊情況
兩種不能被bindingTemplate中accessPoint信息直接支持的特殊需求是:
Web服務(wù)在技術(shù)上由第三方提供主機(jī):一個(gè)企業(yè)可以選擇這樣一種方式來發(fā)布一種服務(wù),該服務(wù)邏輯上屬于本企業(yè),但實(shí)際上該服務(wù)是在遠(yuǎn)程的或者第三方的主機(jī)上運(yùn)行的(比如ASP模式的企業(yè)應(yīng)用)。應(yīng)用服務(wù)提供商和網(wǎng)絡(luò)交易市場運(yùn)營商是這種情況的典型代表。在這種情況下,實(shí)際上是作為第三方的應(yīng)用服務(wù)提供商和網(wǎng)絡(luò)交易市場運(yùn)營商實(shí)際上控制了綁定信息bindingTemplate的運(yùn)行時(shí)態(tài)的取值。
由用戶指定的對綁定位置的訪問控制:在其他情況中,比如與調(diào)用上下文相關(guān)的重定向是基于調(diào)用者的用戶標(biāo)識的(比如具備某種權(quán)限的用戶被重定向入一個(gè)管理入口,而其他用戶被重定向入一個(gè)普通入口),或者甚至是每天的路由,此時(shí),提供更動態(tài)的對遠(yuǎn)程服務(wù)的實(shí)際聯(lián)絡(luò)信息的方式是非常必需的,相比起緩存accessPoint數(shù)據(jù)以支持調(diào)用的方式更為必要。
由于這些原因,bindingTemplate結(jié)構(gòu)包括了另一個(gè)數(shù)據(jù)元素,被稱為hostingRedirector。hostingRedirector元素的存在表明了調(diào)用者如果需要調(diào)用由指定bindingTemplate所表示的Web服務(wù)時(shí)必須使用一個(gè)額外的步驟去獲得accessPoint信息(即,調(diào)用地址)。當(dāng)在解析一個(gè)hostingRedirector引用時(shí),需要經(jīng)過兩個(gè)步驟。
使用hostingRedirector數(shù)據(jù)
當(dāng)一個(gè)包含hostingRedirector元素的、同時(shí)表示了一個(gè)服務(wù)入口(稱為服務(wù)綁定)的bindingTemplate被UDDI注冊中心返回時(shí),程序員可以使用該信息來定位實(shí)際的描述站點(diǎn)服務(wù)的bindingTemplate,這個(gè)實(shí)際的描述站點(diǎn)服務(wù)的bindingTemplate包含了描述真正提供服務(wù)的主機(jī)的相關(guān)的accessPoint信息。
一般的,hostingRedirector元素的內(nèi)容包括一個(gè)bindingKey,該鍵引用了另一個(gè)bindingTemplate。這個(gè)包含在hostingRedirector元素中的、引用了在同一個(gè)UDDI注冊中心中的另一個(gè)bindingTemplate的可解析的bindingKey是在最初的get_bindingDetail消息返回的。
在訪問這第二個(gè)綁定信息(稱為間接綁定)之后,調(diào)用者就可以完全著眼于這個(gè)間接綁定的技術(shù)指紋。如果這個(gè)間接綁定的技術(shù)指紋與服務(wù)綁定的技術(shù)指紋是一樣的,那么這個(gè)間接綁定中的accessPoint就可以用來與最終的Web服務(wù)交互。hostingRedirector的這種使用方式稱為簡單間接模式(simple indirection)。如果,這個(gè)間接綁定的技術(shù)指紋表明這個(gè)間接綁定是實(shí)現(xiàn)了一個(gè)hostingRedirector服務(wù),那么需要再一次使用get_bindingDetail消息,這個(gè)消息被發(fā)往在這個(gè)間接綁定信息中包含的accessPoint所指明的地址,以獲得真正的服務(wù)綁定信息。hostingRedirector的這種使用方式稱為重定向模式(redirection)。
在簡單間接模式中,描述最終服務(wù)的bindingTemplate將簡單地被初始的服務(wù)綁定所引用。在這種場合下,并沒有復(fù)雜的邏輯。(參見下圖)
Figure 1. 簡單間接模式示意
而對于重定向模式,以下的具體描述表述了重定向使用的步驟:
一個(gè)商業(yè)實(shí)體為一個(gè)寄宿于遠(yuǎn)程站點(diǎn)或需重定向的商業(yè)服務(wù)S注冊了一個(gè)bindingTemplate A。這個(gè)bindingTemplate包括一個(gè)bindingKey值Q來引用另外一個(gè)bindingTemplate B。這個(gè)bindingTemplate B典型地由提供重定向服務(wù)的組織來控制。這個(gè)bindingTemplate B包含了指向?qū)嶋H上的hostingResirector服務(wù)R的accessPoint元素。
應(yīng)用程序需要調(diào)用步驟一中注冊的服務(wù)S,首先需要得到公布的服務(wù)的綁定信息。這個(gè)bindingTemplate信息包含了一個(gè)hostingRedirector元素,該元素同時(shí)包含了對應(yīng)于bindingTemplate B的bindingKey值K。
程序員使用bindingKey值K對原始bindingTemplate A所在的UDDI注冊中心發(fā)送get_bindingDetail消息。這樣就能得到返回的bindingTemplate B?,F(xiàn)在程序員就能得到實(shí)現(xiàn)重定向的服務(wù)的地址。這個(gè)信息就是在bindingTemplate B中所能找到的accessPoint元素。該服務(wù)知道如何響應(yīng)get_bindingDetail消息。
使用最初的bindingKey值Q,并發(fā)送一個(gè)get_bindingDetail消息到重定向服務(wù)R。這個(gè)服務(wù)負(fù)責(zé)返回被重定向的商務(wù)服務(wù)S的實(shí)際綁定信息或者返回一個(gè)錯(cuò)誤信息。如果需要,程序員可以選擇緩存這個(gè)bindingTemplate。
使用上述這個(gè)算法,一個(gè)為其他企業(yè)提供主機(jī)服務(wù)的機(jī)構(gòu)可以控制實(shí)際訪問該服務(wù)的信息。這不僅可以幫助提供主機(jī)服務(wù)的組織對各種情況實(shí)施有效管理,比如災(zāi)難恢復(fù),而且可以讓他們定義訪問實(shí)際上被調(diào)用的商務(wù)服務(wù)所使用的URL。這個(gè)URL可以由調(diào)用者來指定,也可以是一個(gè)宿主機(jī)或重定向服務(wù)的通用地址。(參見下圖)
Figure 2. 重定向模式示意
使用重定向服務(wù)的意義就在于那些提供ASP或者在線交易市場服務(wù)的服務(wù)提供商能夠動態(tài)地使用自身的重定向服務(wù)來決定某一企業(yè)的應(yīng)用的入口,這對于使用動態(tài)路由的網(wǎng)絡(luò)應(yīng)用環(huán)境或是動態(tài)的企業(yè)應(yīng)用解決方案的服務(wù)提供商來說,是至關(guān)重要的。
在任何情況下,原始的調(diào)用者可以在不知道任何重定向存在的情況下,找到實(shí)際商業(yè)伙伴所發(fā)布的Web服務(wù)(通過bindingTemplate),并通過該服務(wù)找到實(shí)際商業(yè)伙伴的數(shù)據(jù)。
小結(jié)
本文通過介紹UDDI數(shù)據(jù)模型中的bindingTemplate數(shù)據(jù)實(shí)體,對如果使用bindingTemplate中的信息實(shí)施Web服務(wù)調(diào)用進(jìn)行了討論,闡明了利用緩存bindingTemplate加速服務(wù)多次調(diào)用的方法,也介紹了在災(zāi)難恢復(fù)的情況下如何再次緩存的方法。同時(shí)通過對hostingRedirector的功能的分析,介紹了簡單間接模式和重定向模式對于非直接提供服務(wù),而是由ASP供應(yīng)商提供服務(wù)這一模式的重要性。
參考資料
- UDDI執(zhí)行白皮書,
UDDI-China.org, UDDI.org
- UDDI技術(shù)白皮書,
UDDI-China.org, UDDI.org
- UDDI程序員API規(guī)范
v2.0, UDDI-China.org, UDDI.org
- UDDI數(shù)據(jù)結(jié)構(gòu)參考
v2.0, UDDI-China.org, UDDI.org
- UDDI程序員API規(guī)范
v1.0, UDDI-China.org, UDDI.org
- UDDI數(shù)據(jù)結(jié)構(gòu)參考 v1.0, UDDI-China.org, UDDI.org
- Microsoft UDDI Resource Center &
UDDI Operator, Microsoft Cooperation
- Web Service and UDDI,
IBM
- SOAP Version 1.2 中文版, W3C Working Draft 9 July 2001/UDDI-China Translation
作者簡介
- 1ColdFusion MX增加對J2EE、XML和Web服務(wù)的兼容
- 2IBM推新工具包助用戶跨平臺開發(fā)Web服務(wù)
- 3微軟在宣布.Net計(jì)劃進(jìn)入第二階段時(shí)預(yù)測——Web服務(wù)掀起下一次IT泛普
- 4理解Web服務(wù)互操作性
- 5石家莊OA信息化的基本XML和RDF技術(shù)(二):將文件合并到RDF模型和基本的RDF查詢
- 6知識發(fā)現(xiàn)與數(shù)據(jù)挖掘
- 7炎黃盈動AWS石家莊OA信息化應(yīng)用套件
- 8XML Web Service 安全性
- 9知識經(jīng)濟(jì)時(shí)代的知識、競爭與制度演化
- 10Web服務(wù)網(wǎng)絡(luò):簡化企業(yè)間工程的中介
- 11Web Services 及其技術(shù)(上)
- 12一波“三折”:我的OA選型經(jīng)歷(下)
- 13泛普軟件石家莊OA信息化實(shí)施階段劃分
- 14創(chuàng)造性的Intranet:Factors for Corporate Knowledge Creation
- 15由知識螺旋看知識創(chuàng)新(BY AMT 夏敬華 編譯)
- 16互聯(lián)網(wǎng)聯(lián)盟(W3C )發(fā)布Web服務(wù)體系新規(guī)范草案
- 17從九點(diǎn)連線談創(chuàng)新及對石家莊OA信息化的再思考(by AMT 夏敬華)
- 18鼓勵(lì)創(chuàng)新的文化的十個(gè)規(guī)則
- 19SOAP與RDF--超越遠(yuǎn)程過程調(diào)用
- 20如何認(rèn)識和實(shí)施石家莊OA信息化系統(tǒng)的集成(BY AMT 夏敬華)
- 21不僅看投資回報(bào),還要看“知識回報(bào)”
- 22石家莊OA信息化的基本XML和RDF 技術(shù)(五):定義RDF和DAML+OIL圖示
- 23大型集團(tuán)公司OA辦公系統(tǒng)平臺建設(shè)實(shí)施計(jì)劃
- 24走出石家莊OA信息化的迷思(BY AMT 夏敬華)
- 25石家莊OA信息化:挖掘企業(yè)的隱藏資源(姜鐵虎)
- 26面向21世紀(jì)的知識發(fā)展戰(zhàn)略
- 27Web服務(wù):WS-Inspection 1.0
- 28架構(gòu)Web Service:描述與注冊,發(fā)布Web服務(wù)
- 29[編譯] 石家莊OA信息化測度:目標(biāo)、過程及方法(夏敬華譯)
- 30石家莊OA信息化的基本XML和RDF技術(shù)(一):使用XSLT生成RDF
成都公司:成都市成華區(qū)建設(shè)南路160號1層9號
重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務(wù)大廈18樓
版權(quán)所有:泛普軟件 渝ICP備14008431號-2 渝公網(wǎng)安備50011202501700號 咨詢電話:400-8352-114