Web services被大肆宣揚
在市場是隨處可見
也通常被人們誤解
像所有的新技術一樣
Web services用了很短時間就進入了人們的日常生活應用中
由於缺乏實現標准
Web services的發展受到了影響
Web services標准 Web services建立在很多技術標准之上
並由世界上最大的技術公司如微軟和IBM等支持
這些實現Web services的明確標准包括簡單對象訪問協議（SOAP）
Web services描述語言（WSDL）
通用描述
發現和集成（UDDI）
問題就出來了
那些就足夠了嗎？
答案是否定的
雖然Web services技術提供標准的定位
描述以及訪問遠程服務的方法
但是還有一些更重要的問題它沒有涉及到
比如說數據標准
接口標准以及商業過程標准
數據標准 數據標准是指數據一致的格式
一般來說
工業界和應用程序中都會有一個數據標准
例如電子數據交換（EDI）就是一個很流行的數據標准
能被應用到很多行業和應用程序中
在新的應用程序中
這個標准變成了XML
但是XML本身並沒有滿足工業界和應用程序更多的需要
數據標准問題的解決方法是XML應用程序——就是用一組特定的XML語法去描述一個特定的問題空間
比如說人力資源或者保健
但主要的問題是由於競爭這些標准被采用的速度非常快
解決方法就是遵守現行的標准
在不重新使用一個新的XML語法的情況下使其工作
接口標准 XML數據標准之外的另一個問題是接口標准
你可能會說
Web services提供動態定位和服務描述
所以接口標准很容易
但這還不夠
僅僅是因為公司注冊了他們的服務描述並不意味著你不用擔心他們的服務之間的接口的問題
想象你需要集成三個不同的供應商的基本服務
由於他們帶的參數不一樣
每個服務的接口也會有稍微的不同
對你來說很容易從一個UDDI服務器上取得每個服務的WSDL
但是你怎樣將你的數據請求映射到每個服務呢？接口變了又怎麼辦？你的應用程序能自動地知道怎樣重新映射請求嗎？
因為接口只有很少的正式標准
所以公司更樂意將他們自己的接口作為接口標准
僅僅是因為你的接口建立在Web services之上不意味著你不要為每個連接點創建多
連接器
或者至少是
翻譯器
很難說接口的解決方法是什麼樣的
但是現在已經有一些接口標准比較流行
由Sun微系統公司發起的Java團體化進程（JCP）打算建立一個團體來創建和支持標准Java接口
例如JCP包括七個Java規范要求（JSR）用以規范電信運營提供商（OSS）的管理
商業過程標准 公司間的商業過程也是非常困難的
Web services事務通常都是圍繞對話模型建立的
所謂的對話模型是指使用多接口來發送多種類型的XML數據
對於其中一方
它以特定的順序使用一組接口來發送特定的XML數據
而對於另一方
一次發送所有的數據
即使是完成同一個目標的處理也可能非常的不同
有幾個步驟幫助標准化Web services的處理過程
能使處理過程一致對於Web services架構來說意義重大
最流行的解決方案是由IBM
微軟和BEA共同開發的Business Process Execution Language for Web Services(BFEL
WS)
它允許你制定模型或者一組動作來裁剪商業過程
很多集成工具提供商
例如Vitria等在它們的產品中也完全支持BPEL
WS
From:http://tw.wingwit.com/Article/os/fwq/201311/10227.html
