在過去的數年中
許多開發人員都使用了各種版本的J
EE
使服務器端軟件編程的情形得到了很大的改觀
現在
他們將再次挑戰SOAP
在服務器端軟件編程方面取得更大的進展
SOAP服務的支持者認為
·企業級應用服務器是服務（或事務）的集合
·可以使用的服務應當很方便地列出來供用戶浏覽
搜索和訪問
·象現在的基於組件的開發模式那樣
將應用服務器設計為服務的集合將鼓勵開發人員采用更好的設計模式
·這些事務能夠被重新定位
負載平衡
替代等
而對SOAP持懷疑態度的人認為
SOAP是推廣CORBA和COM的又一次嘗試
他們指出
要簡單地訪問一個對象
需要完成太多的准備性工作
而且
UDDI帶來的好處也被誇大了
那麼
到底哪一種觀點更合理呢？對於一些思想開放的人士而言
在決定是否采用SOAP服務前
他們一定希望了解其中的一些核心技術
解密UDDI
我們首先來看看UDDI代表什麼？UDDI是Universal Description
Discovery and Integration（統一描述
發現和集成）的縮寫
UDDI的意圖是作為一個注冊簿
就象黃頁是一個地區企業的注冊簿一樣
象在黃頁中那樣
在UDDI注冊簿中
企業將在不同的目錄下注冊它們自己或其服務
通過浏覽一個UDDI注冊簿
開發人員能夠查找一種服務或一個公司
並發現如何調用該服務
除了黃頁外
UDDI還使用了白頁和綠頁
白頁是企業實體列表
綠頁是調用一項服務所必需的文檔
UDDI的定義非常全面
足以適應不同種類的服務
一個UDDI服務定義可能代表一個傳真服務或電話服務
作為一種注冊簿
UDDI一般使用數據庫一類的軟件來實現
在該數據庫中
存在一個允許發布或查詢服務的有關信息
UDDI數據模型
UDDI數據模型包括下面的主要元素
·businessEntity
表示一個實際的企業
·businessService
表示一個企業提供的服務
·bindingTemplate
如何調用服務的說明
·tModel>: Good luck understanding this! (Just kidding
I will explain this later
)
為了加深對UDDI數據模型的理解
我們來看看這些數據元素的UML表示法
圖
是這四種主要元素之間的關系圖
educity
cn/img_
/
/
/
gif >
從上面的圖中我們可以知道
一個businessEntity（一家公司）有一個能夠告訴我們更多有關公司信息的描述性URL和聯系人清單
此外
businessEntity還有一個商業服務清單
每種服務可能有多種調用方法
每種調用都由一個綁定模板描述
綁定模板詳細地描述了如何訪問一個服務
它受益於一系列描述用戶如何訪問這一服務的文檔
綁定模板和其必要的文檔之間的聯系是通過所謂的tModel完成的
在上面的圖中
這種聯系被簡單地描述為一個綁定模板有許多tModels
在進一步地解釋tModels與綁定模板的關系前
我們必須先弄清楚tModels是什麼
TModel是什麼？
我們可以把tModel想象成數據庫庫中的一個獨立的表
其中包含下面的字段
名字
描述
URL
唯一的關健字
實際上
tModel就是包括有名字和描述
那麼使用數據庫表表示它是否是一種浪費呢？我們下面就會討論這一問題
下面是一個假想的tModel數據庫表中的二個實體
鍵 名字 描述 URL
Java
class 表示一個具備完全資格的java類的名字
Jndi
home 表示一個JNDI名字
在將tModel比作數據庫表方面
有幾點值得注意
首先
tModel是一個獨立的表
意味著它可以不依賴其他軟件而存在
其次
tModel是查找表
提供了鍵與鍵的表示之間的轉換關系
從這一點來看
tModel象詞典那樣
是一個引用表
在一些數據庫中
這樣的表也被稱作是碼集
因此
如果在上面的tModel中存在下面的記錄
com
mycompany
HelloWorld
com
mycompany
HelloWorldHome
就意味著字符串com
mycompany
HelloWorld是一個有完整資格的Java類
而字符串com
mycompany
HelloWorldHome是一個JNDI名
因此在一定程度上
tModels中唯一的鍵與
名字空間
這個概念差不多
為了進一步地說明這個問題
我們來看一下下面的數字
x
你能夠分清這些數字的意義嗎？我們需要在一個環境或名字空間中來確認
是電話號碼
是傳真號
x是一個ISBN號
因此在tModel數據庫表中
我們將需要定義三個實體
一個是電話號碼
一個是傳真號碼
一個是ISBN號碼
下面我們以mycompany公司公布了一條號碼為
my
helpline的電話支持熱線
並在UDDI中注冊
那麼
我們的數據模型為
company name: mycompany
Service name: helpline
tModel: key=
(representing telephoneline)
name=telephone
description=telephone stuff
url:
some at&t url
binding:
accesspoint:
my
helpline
tModelInstanceInfo:
有了對tModel的基本理解後
我們就可以利用UML圖表來研究綁定模板與tModels之間的關系了
我在上面曾經說過
這將使我們對綁定模板如何完成UDDI的
如何調用一項服務
的要求有一個直觀的理解
educity
cn/img_
/
/
/
gif >
在圖
中
我們討論了一個綁定模板與tModels之間的關系
從圖表中我們可以看出
一個綁定模板可以指向一個由一個tModel確定的技術規格
技術規格有二部分組成
·規格的類型
（例如電子郵件
傳真
WSDL
SOAP等
）
·確定輸入和輸出的文檔（在SOAP服務中
這些文檔可以是XML輸入/輸出消息格式
）
既然我們已經對tModels有了一定程度的詳細了解
就該再討論UDDI中更復雜的東西了
也就是身份包和類別包
理解標識符包和類別包
如果說從概念上理解tModels是理解UDDI需要跨越的第一道障礙
那麼理解標識符包和類別包則是需要跨越的第二道障礙
下面的例子可以幫助我們理解這二個概念
例如
您的公司在美國開展業務需要有一個稅號
如果還在另外的國家（例如墨西哥）開展業務
就需要有一個墨西哥的稅號
為了能夠在UDDI注冊簿中獲取您的公司的這些信息
在UDDI中應當包括下面的內容
公司名字
mycompany
標識符
美國稅號
墨西哥稅號
其他國家稅號
其他的xml內容
UStaxcode
keyName=taxnumber keyValue=>
Mexicotaxcode
keyName=taxnumber keyValue=>
otherstuff
keyName=taxnumber keyValue=>
其他的xml內容
現在明白tModels如何被用作名字空間了吧為了進一步地深化對標識符包的理解我們在下面的圖中再次解釋了標識符和類別包的概念
educitycn/img_///gif >
從上面的圖中我們能夠看出標識符包是一個在特定環境中的鍵/值對集合這個環境從本質上說就是能夠唯一地解析名字/值對兒的名字空間它是由tModel確定的類別包也是如此二者之間唯一的區別就是類別包中由tModel確定的名字空間是一個預先確定好的類別
類別包
我想將公司歸類於飯店其地理位置位於傑克遜維爾
公司名字mycompany
適用類
企業類型飯店
所在城市傑克遜維爾
BusinessTypeClassification
keyName=restaurant keyValue=>
CityClassification
keyName=JAX keyValue=>
現在我們已經搞清楚了tModels是如何用在標識符和類別包中的從本質上說tModels就是名字空間
tModels也能被分類嗎？
我們已經明白了企業實體是如何利用使用了類別包的另外UDDI也允許tModels本身被分類
我們用分層次的文件系統進行說明目錄是用來對文件進行分類的但目錄還可以在父目錄下再被分類象硬盤上的目錄那樣tModels也可以被分層次地進行組織
下面我們來討論名字為getUniversalTime()的服務該服務將返回當前全球任一地方的時間二家存在競爭關系的公司可能會提供這一服務的不同實現商業服務只限於在公司內部使用公司之外的用戶是不可使用的
company:getTime()
company:getCurrentTime()
這二者的作用相同為了表明它們實現的是同一個被稱作getUniversalTime()的服務我們可以定義如下所示的tModel
tModel
name: Get Universal Time
category: uddiorg:types wsdl
[意味著這是一個由WSDL文檔定義的服務]
上面的定義表明getUniversalTime()是一個WSDL服務可以由任何公司實現
既然已經闡明了tModels和包之間的關系我們下面可以看看一個tModel的UML表示
educitycn/img_///gif >
從上面的圖表中我們可以看出tModel基本上就是一個名字和描述另外它也可以包含一個URL以提供更進一步的詳細資料它可以由一個標識符包確定和由一個類別包進行分類
我們已經知道一個t
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19743.html
