推薦：使用Data Access Application Block 得到存儲過程的返回值
今天有位朋友問我如何在Data Access Application Block中得到存儲的過程的返回值，我才發(fā)現(xiàn)自己以前寫的文章中確實沒提到這方面的問題，現(xiàn)在來補充一下，具體的解決方法如下： 1、首先建立一

面向服務的業(yè)務環(huán)境

面向服務是一種創(chuàng)建分布式系統(tǒng)的方法。在它最抽象的層面，面向服務作為一個服務提供程序，包含了一切——從大型機應用程序到打印機到碼頭工作人員到隔夜交貨公司。服務提供程序通過接口公開了功能。面向服務的體系結構與這些功能和接口進行了映射，這樣它們就可以編制到流程里。這種服務模型是“不規(guī)則的”：新形成的流程本身就是一個服務，它公開了一種全新的聚合功能。

這種服務模型的基礎是接口與實現(xiàn)之間的分離。服務的調(diào)用者只需要(只應該)了解接口;實現(xiàn)過程可以隨著時間而發(fā)展，而不會干擾到此服務的客戶。有趣的是，許多實現(xiàn)工具都可以提供相同的接口;面向服務的幾個關鍵利益來源于從如何提供功能的角度對功能進行抽象化。

對，這就是面向服務。那么面向服務都對誰有幫助呢?

看到一個雞蛋，農(nóng)民可能會想到一只小雞;廚師可能會想到一盤煎蛋卷;小孩可能會想到一個五光十色的復活節(jié)裝飾品。面向服務就是一個雞蛋。

對于開發(fā)人員和解決方案架構師而言，面向服務是一種創(chuàng)建動態(tài)的協(xié)作應用程序的方法。通過支持運行時選擇的功能提供程序，面向服務允許應用程序?qū)μ囟�業(yè)務流程的內(nèi)容和環(huán)境具有敏感性，并隨著時間的推移適度地合并新的功能提供程序。

對于IT經(jīng)理而言，面向服務是一種有效的集成現(xiàn)代企業(yè)數(shù)據(jù)中心的各種典型系統(tǒng)的方法。面向服務提供了一個模型，可將多個系統(tǒng)的信息和業(yè)務邏輯聚合到一個單獨的接口中，這樣就可以通過通用的、一致的接口集處理各種冗余的系統(tǒng)。

對于首席信息官而言，面向服務是一種在不禁止部署新功能的情況下保護現(xiàn)有IT投資的方法。通過在基于功能的接口之后封裝業(yè)務應用程序，該服務模型允許對關鍵任務應用程序進行控制性訪問，同時它還創(chuàng)造了在此接口之后持續(xù)改善實現(xiàn)過程的機會。面向服務使投資避免了紛繁的變化。

對于業(yè)務分析師而言，面向服務是一種使信息技術投資更符合業(yè)務策略的方法。通過將員工、外部功能提供程序和自動化系統(tǒng)映射到一個單獨的模型中，分析師可以更好地理解與人、系統(tǒng)和來源的投資相關的成本權衡。

對于Microsoft Corporation而言，面向服務是創(chuàng)建互聯(lián)系統(tǒng)的一個重要前提。互聯(lián)系統(tǒng)屬于應用程序，它們可利用網(wǎng)絡來鏈接推動業(yè)務流程的執(zhí)行者和系統(tǒng)。你可以在一種特殊的應用程序模型上構建互聯(lián)系統(tǒng)，這種模型超越了任何設備，適度地跨越了邊界，并抑制了同步性的限制。通過將一系列服務和設備集中到了一起，互聯(lián)系統(tǒng)可以比過去的分離的應用程序更有效地應對業(yè)務挑戰(zhàn)。

企業(yè)的IT部門需要獲得更深入的業(yè)務活動洞察，在此需求的帶動下，它們正在尋找有效、簡便的方法來集成它們的應用程序組合。其目標是透明性和一致性：

•對于我們的客戶和業(yè)務關系，我們是否具有一致的觀點(它能夠讓我們以最佳的方式服務于它們的需求和呈現(xiàn)我們的產(chǎn)品)?

•我們所有的業(yè)務流程是否都符合組織要求和政府規(guī)定?

•我們的系統(tǒng)是否能夠針對我們的業(yè)務目標有效地提供價值?

•我們的技術投資能夠?qū)崿F(xiàn)一般任務的自動化，并對我們的員工的工作進行配合，從而克服復雜的挑戰(zhàn)，這能否使我們最大限度地提高生產(chǎn)力?

為了實現(xiàn)透明性和一致性，組織必須創(chuàng)建各種連接機制。它們必須連接系統(tǒng)，以創(chuàng)建一致的信息管理程序。它們必須連接人和技術功能，以創(chuàng)建一致的業(yè)務流程。它們必須連接工作人員，以創(chuàng)建協(xié)作的工作團隊。它們必須連接組織，以創(chuàng)建有效的價值鏈。

通用的功能調(diào)用模型是面向服務的重點，而面向服務是有效的互聯(lián)系統(tǒng)策略的核心。

服務和互聯(lián)系統(tǒng)

在計算機組件模型的環(huán)境下，服務是一種通過交換消息進行通信的程序。換句話說，服務是一組應用邏輯，它接收和發(fā)送的消息完整地定義了它的接口。

通過以可擴展標記語言(XML)為基礎開發(fā)消息標準，面向服務正迅速成為構建互聯(lián)系統(tǒng)的主流方法。

在連接各種不同的系統(tǒng)的過程中，其固有的挑戰(zhàn)是特定平臺的信息和過程模型的轉換。在理想的世界里，我們將擁有：

•標準語法，在此可以明確地表達來自所有系統(tǒng)的信息。

•標準語義模型，各組織可以通過一種一致的語言表達它們的業(yè)務實踐方法。

•標準協(xié)議，可以跨越操作環(huán)境和組織之間的邊界傳遞信息。

•標準方法，用來綁定行為和業(yè)務文檔。

在理想的世界里，我們的所有系統(tǒng)都將說這種“世界語”(除了它們自身的語言之外)，這樣它們就可以在它們的本地環(huán)境之外進行通信。

XML、XSD、WSDL、UDDI以及WS-*規(guī)范，比如WS-Security和WS-Policy，是這種不斷發(fā)展的通用語言的第一批模型。

以廣泛支持的標準為基礎的虛擬平臺提供了互操作性，如果沒有這種互操作性，面向服務就將是一門需要大量的協(xié)議設計專業(yè)知識的晦澀難懂的學科，同時它也將是一種不可靠的投資回報。如果沒有Web服務跨越各種異類平臺連接你的企業(yè)功能，面向服務對你和你的組織的價值就將大幅度減少。

客戶端是互聯(lián)系統(tǒng)的一個非常重要但是卻經(jīng)常受到忽略的元素。服務只有在受到調(diào)用時才會引起注意。不同的交互要求需要支持各種不同的客戶端模式。Web服務的客戶端包括：

•具有豐富用戶體驗的智能應用程序—它們是具有以下特性的解決方案：與一個或許多服務進行交互;對它們檢索的信息進行智能緩存;既提供了良好的交互性，又對離線信息處理提供了支持。

•智能設備—它們是包括以下范圍的解決方案：從自助式電話亭到手持式庫存跟蹤技術到智能電話聯(lián)系人管理。

•Web用戶界面(UI)—它們屬于企業(yè)門戶解決方案，這些解決方案對業(yè)務與員工和組與組之間的交互進行了統(tǒng)一和協(xié)調(diào)。

•自動化系統(tǒng)—它們屬于客戶端，這些客戶端一般不呈現(xiàn)UI，除非需要引發(fā)異常。

•流程編制服務——它們是調(diào)用其它服務來提供聚合的功能的服務。

不斷發(fā)展的Web服務標準和實現(xiàn)它們的平臺必須支持客戶端驅(qū)動的概念，例如緩存雜注、資源約束設備的頁響應以及長期運行的交互過程的對話環(huán)境管理。

即使面向服務的熱情支持者對于該模型的范圍也無法達成一致。爭論主要集中在以下問題上：“面向服務的基礎還有什么?”(“你想用這些雞蛋做什么?”)下面讓我們探討與此爭論相關的幾個服務友好的概念：

•企業(yè)體系結構—對組織的目標、優(yōu)先級、資源和流程進行系統(tǒng)建模，以實現(xiàn)有控制的改進所需的自我意識。

•企業(yè)信息集成—為業(yè)務實體(復雜的“類型”，例如“客戶”、“員工”和“采購訂單”)創(chuàng)建一套組織標準，它們由你的應用程序組合進行操作。

•面向流程—使業(yè)務流程成為你的企業(yè)體系結構和信息技術組合的設計重點。

•業(yè)務流程編制—這種模型可支持靈活的業(yè)務流程，因為它們能夠使流程中的步驟排序盡可能地實現(xiàn)輕便性和適應性。

•事件驅(qū)動的體系結構—在這種模型中，業(yè)務事件(例如，部件到達碼頭或?qū)Πl(fā)票付款)可觸發(fā)消息發(fā)送到訂閱服務，這樣它們就可以采取適當?shù)拇胧��?/p>

•虛擬企業(yè)—將業(yè)務流程視為價值鏈，這種價值鏈能夠跨越組織進行擴展，這樣每個組織就可以集中精力開發(fā)其核心功能，并將非核心功能外包給外部服務提供商。

•面向方面—提供了一種一致地處理橫切關注點(例如，業(yè)務活動監(jiān)控、服務訪問控制和消息傳遞的可靠性)的方法。

•基于人員的工作流管理—協(xié)調(diào)信息工作者和他們與業(yè)務流程的交互作用，以提高效率并實現(xiàn)對客戶需求的響應。

•非居間化—跨越業(yè)務邊界自動交換非異常信息，以消除信息工作者執(zhí)行常規(guī)任務的需求，例如，通過書面(傳真、郵件、電子郵件)或口頭的信息交換進行數(shù)據(jù)輸入。

•靈活性—這種系統(tǒng)的設計是為了響應業(yè)務請求的特殊環(huán)境和內(nèi)容，以及業(yè)務要求和業(yè)務策略的更廣泛的變化。

•模型驅(qū)動的開發(fā)—通過高級(通常是圖形化的)語言驅(qū)動解決方案的開發(fā)流程，這種語言與正在實現(xiàn)自動化的業(yè)務流程進行了更緊密的綁定(例如，與Visual C#相比)。

Microsoft將靈活性和面向方面視為面向服務在業(yè)務和技術方面取得成功的關鍵因素;在本論文中，將不斷地圍繞這些主題進行討論。不干預性是面向服務解決方案的一個非常普通的目標，因此它可能被視作該體系結構的一個隱含收益。其它任何概念都是對面向服務的補充，它們可能(或不會)對你的互聯(lián)系統(tǒng)策略起到關鍵作用。

你的互聯(lián)系統(tǒng)策略需要成為一種應對機會和難題的標準方法，它們保證了你的IT投資的最佳回報。服務和支持模型的交換使用是無限制的，但是發(fā)展的實例應該證明它具有啟發(fā)意義。

第一步：爬

Typhoon Taylor是Rum Island Industries(RII)的信息樞紐。每份訂單和發(fā)貨報告都要經(jīng)過他的辦公桌，他必須確保數(shù)據(jù)輸入到了主機里。但是，在RII被Worldwide Spirits(WWS)收購之后，Typhoon發(fā)現(xiàn)他必須將相同的信息輸入到RII操作系統(tǒng)和WWS企業(yè)資源計劃(ERP)系統(tǒng)中;不同的信息模型不斷地造成數(shù)據(jù)輸入錯誤，它們導致了兩個系統(tǒng)之間的數(shù)據(jù)不一致。

Typhoon與他的IT搭檔Daiquiri Jones討論了這種情況。Daiquiri不想破壞主機應用程序，但是她又無法獲得WWS ERP系統(tǒng)的修改權限，因此她建議在兩個系統(tǒng)之前添加一個服務層。

通過與Typhoon合作，Daiquiri定義了一個PurchaseOrder(采購訂單)文檔，它包含了該操作系統(tǒng)或ERP系統(tǒng)需要的全部信息，同時它又對二者都需要的公共元素進行了映射。然后，Daiquiri將這份草案交給會計部門的Hurricane Harris和客服部門的Salty Robinson過目。根據(jù)他們的反饋意見，她又在PurchaseOrder架構上添加了若干元素，以便支持Hurricane和Salty的需求。

通過再次與Typhoon合作，Daiquiri確定了兩項服務：

•NewOrder(新訂單)：接收采購訂單文檔，并更新兩個后端系統(tǒng)。

•ProcessShipment(進行發(fā)貨)：接收Shipment(發(fā)貨)文檔，將它與訂單相關聯(lián)，然后更新后端系統(tǒng)。

通過利用DB2數(shù)據(jù)庫和WWS ERP系統(tǒng)現(xiàn)有的適配器，并使用ASP.NET為Typhoon迅速編制一個用戶接口，Daiquiri在BizTalk Server 2004中實現(xiàn)了這些服務。

Typhoon非常高興。此后，他只需要輸入一次數(shù)據(jù)，而且信息不一致的問題也解決了。

第二步：走

然而，Salty和Hurricane卻剛剛開始感覺到麻煩。

由于運輸途中海浪很大，經(jīng)常會打碎幾個瓶子，每當出現(xiàn)這種情況時，Salty就不得不處理客戶的投訴。面對各種不同的系統(tǒng)，Salty甚至不知道該從哪里提取客戶數(shù)據(jù);另外，在客戶需要緊急更換貨物時，他必須與Typhoon協(xié)商酒產(chǎn)品脫離包裝線的改向問題。

對于Daiquiri來說，為Salty提供Typhoon用來檢查訂單完成情況的GetPurchaseOrder (獲得采購訂單)接口非常容易，但是Typhoon堅持認為，在沒有他的批準的情況下，Salty無權擅自更新訂單。因此，Daiquiri為PurchaseOrder業(yè)務服務定義了一套角色，并將Salty映射為“讀取者”的角色。

Daiquiri還擬訂了一份新的CustomerCredit(客戶信用)提案，Salty可以用它來處理關于產(chǎn)品破損的投訴，但是當Hurricane看到這份文檔時，她變得非常憤怒。這份提案根本沒有考慮到Sarbanes-Oxley的合規(guī)性問題。“我們作為一家固定而松散的私人公司的日子已經(jīng)結束了!”她咆哮說。因此，通過使用WWS會計部門已經(jīng)采用的架構，Daiquiri又重新確定了CustomerCredit文檔包含的各項元素，并收入了RegulatoryCompliance(合規(guī)性)元素。

在發(fā)貨過程中重新排列客戶的優(yōu)先次序變得更加復雜，但它也是一次解決問題的機會，在Rum Island(拉姆島)，長期以來這個問題一直限制著生產(chǎn)力的發(fā)展，客戶對這個問題也非常關心。

通過與Typhoon、Salty以及發(fā)貨部門的Mojito Moore進行合作，Daiquiri重新設計了Shipment的架構，以包含對于Customers(客戶)和PurchaseOrders的綁定。然后，她為Shipment文檔實現(xiàn)了一個優(yōu)先級隊列，這樣Mojito就會知道下一個離線的集裝箱應該發(fā)往哪里。(Mojito被映射為隊列接口的“寫入者”角色，因此他可以根據(jù)離港的貨船來優(yōu)化隊列。)

Daiquiri定義了一個工作流，當Salty調(diào)用ReprioritizeShipmentQueue(重新排列發(fā)貨隊列的優(yōu)先次序)接口時，此接口會把相關請求發(fā)送給Typhoon審核，這樣工作流就會得到實例化。

以前的某些工作流程需要手動完成，這會牽涉到Typhoon、Mojito和Salty之間的不準確通信，而現(xiàn)在，這種工作流程可以非常順利地進行。當然，每當Typhoon否決了Salty的一個請求時，Salty還是會發(fā)脾氣。

第三步：跑

當Daiquiri的預算再一次被削減時，她意識到她必須擁有找到資金的創(chuàng)造力。她投入大量資金購買了一條通向WWS的長途電纜，但是這條電纜每天只有幾百KB的電子數(shù)據(jù)交換(EDI)流量。如果……

在WWS總部，Martini Wilson已經(jīng)創(chuàng)建了可提高EDI流量的XML架構;他需要它們將傳入的EDI消息轉換為符合《美國愛國者法案》(USA PATRIOT Act)的數(shù)據(jù)包。通過使用加密的Web服務調(diào)用功能，而不是使用專用的EDI電纜，WSS的大部分子公司都可以降低成本，他同意這一點，因此他實現(xiàn)了一項可將請求映射到EDI處理管道的網(wǎng)關服務。

通過利用她的新基礎結構和專業(yè)知識，Daiquiri還向Rum Island的甘蔗供應商推薦了一組服務接口。Beachcomber Perry是這項服務的受益者之一，他感到非常興奮;他已經(jīng)厭倦了整天與種植園主和船長在電話里打交道。當然，Mojito也參加了這項活動。通過使用這種改善的信息，他可以安排相同的貨船來運糖，以便釀酒。Rum Island的庫存管理從沒像現(xiàn)在這樣好過。

某些種植者和船員對這種變化進行了抵制，但是這僅僅意味著他們以后在Rum Island看到的業(yè)務將越來越少。

面向服務的技術

Microsoft對于面向服務的投入

1999年9月，當時的Microsoft總裁(現(xiàn)在的首席執(zhí)行官)Steve Ballmer首先公開探討了“軟件即服務”的挑戰(zhàn)，并第一次引入了Web服務的概念。隨著Internet的成熟，一種新的編程模型很快就會出現(xiàn)，這一點很明顯;在這種模型里，軟件組件將可以跨越廣域網(wǎng)、跨越平臺、跨越組織邊界進行調(diào)用。到底是什么使這種編程模型成為了一種值得信任的業(yè)務應用平臺?

2000年6月，這種新興的策略獲得了一個名字：“Microsoft .NET”。

緊接著是一段調(diào)整期，與Microsoft有關的組織紛紛對自身進行調(diào)整，以應對.NET提出的新挑戰(zhàn)。出現(xiàn)了一系列與XML Web服務相關的面向服務策略，無論是對于你現(xiàn)有的Microsoft產(chǎn)品，還是對于你的組織技術組合中的所有其它資產(chǎn)，它們都充當了連接Microsoft產(chǎn)品的一致性策略。

Microsoft認識到，為了使技術發(fā)展到與業(yè)務流程相關的下一階段，使技術繼續(xù)促進員工生產(chǎn)力方面的收益，必須跨越相關的邊界。其中一個邊界完全來自于技術人員自身的構成：各執(zhí)行平臺之間的邊界。Microsoft致力于與其它平臺供應商進行合作，以便與他們聯(lián)手將這座墻推倒。

通過與BEA Systems Inc.、IBM Corp.、TIBCO Software Inc.、VeriSign Inc.以及其它技術供應商進行合作，Microsoft創(chuàng)建了一種流程，它可以擴展SOAP消息的跨平臺功能，并實現(xiàn)競爭規(guī)范的合理化。這些規(guī)范以一種免除版稅的方式發(fā)布到了標準的體系中。通過不斷的努力，這些競爭組織達成了合作，為它們的客戶提供了互操作性，這種互操作性對于實現(xiàn)全局消息起到了關鍵作用。

由于認識到了這些規(guī)范的不足——早期的標準無法在實現(xiàn)過程中取得互操作性，Microsoft、IBM和其他贊助商合作創(chuàng)建了Web服務互操作性組織(WS-I)。WS-I為Web服務標準的通用解釋提供了一個論壇，這樣技術客戶就可以相信WS-Security的兩種實現(xiàn)過程其實將會實現(xiàn)互操作。WS-I成立于2002年2月，現(xiàn)在它已經(jīng)擁有了接近150個成員，這些成員包括了各種不同的組織機構：從系統(tǒng)供應商到系統(tǒng)集成商到解決方案提供商到保健服務提供商到政府機構。America Online Inc.、BEA、Fujitsu、HP、NEC Corp.、Oracle Corp.、SAP AG、Siebel Systems Inc.、Sun Microsystems Inc.和TIBCO都是WS-I的成員。

在此基礎之上，Microsoft又將基于標準的互操作性置入了它的企業(yè)計算產(chǎn)品系列中。

面向服務的目前狀況

Microsoft平臺支持創(chuàng)建符合WS-I Basic Profile 1.0的服務和解決方案，同時它也支持對高級的WS-* Web服務規(guī)范進行早期的采用。

使用ASP.NET對于Web服務的支持是Microsoft平臺上創(chuàng)建Web服務的主要方法，ASP.NET Web服務俗稱為“.asmx”或“ASMX”，這是因為Visual Studio對這些可執(zhí)行文件使用了這種文件擴展名。

BizTalk Server 2004允許將編制服務公開為Web服務，對于缺乏本地Web服務支持的業(yè)務應用程序，這大大加快了Web服務網(wǎng)關的開發(fā)過程。

在Web Services Enhancements for Microsoft .NET (WSE)中，可以使用早期實現(xiàn)的高級Web服務功能，例如，使用了WS-Addressing規(guī)范的復雜消息路由，以及WS-Security規(guī)范的消息級安全性。WSE是一種技術預覽程序，可用于特定的客戶——這些客戶希望以推薦的標準為基礎對技術進行實驗。

對于從我們的操作系統(tǒng)(Windows XP、Windows Server 2003和Windows CE)和Microsoft Office系統(tǒng)調(diào)用Web服務，Microsoft提供了豐富的支持。

Microsoft Office InfoPath 2003是Microsoft Office系統(tǒng)中提供的一個新組件，它支持將圖式化的表單用作包含后端服務的交互模型。InfoPath已經(jīng)證明它在結構化的協(xié)作方案(從人力資源注冊到合同協(xié)商)中是非常有用的。

Office的另一個新組件是Microsoft Office Information Bridge Framework (IBF)，有了它，就可以通過Web服務訪問信息。IBF是Visual Studio .NET的一個外接程序，它使開發(fā)人員可以創(chuàng)建基于Web服務的解決方案，這種解決方案能夠訪問企業(yè)業(yè)務數(shù)據(jù)，例如銷售額、庫存數(shù)字、客戶信息等等。在Word、Excel和Outlook的2003版中，可以直接查看這些信息。IBF能夠讓信息工作者在不離開他們熟悉的Office應用程序的情況下檢索和操作信息，從而增強了他們的生產(chǎn)力。

Visual Studio為企業(yè)的行業(yè)應用程序提供了最佳的開發(fā)環(huán)境，它一直保留了這種傳統(tǒng)。Visual Studio .NET支持Web服務的實例包括：

•服務部署

•XSD創(chuàng)作

•WSDL的自動生成

•UDDI注冊

•數(shù)據(jù)中心部署包

•通過UDDI發(fā)現(xiàn)客戶端服務

•客戶端服務綁定

•服務代理的自動生成

同時，Microsoft正努力提供必要的指導，以便開發(fā)人員完善創(chuàng)建過程。傳統(tǒng)上，MSDN為開發(fā)人員提供了較為完善的指導材料，Microsoft對這些指導材料進行了擴展，它以書籍、白皮書、參考應用程序和模式庫的形式提供了體系結構指導。Microsoft的模式與實踐門戶(http://www.microsoft.com/practices/)是體系結構指導的入口，從信息設計到解決方案體系結構到解決方案建模(目的是將這些解決方案部署到企業(yè)的數(shù)據(jù)中心中)，這些指導材料包含了非常豐富的內(nèi)容。

使用SQL Server 2005和Visual Studio .NET 2005實現(xiàn)面向服務Microsoft SQL Server 2005 (代號為“Yukon”)和Visual Studio .NET 2005 (代號為“Whidbey”)將是2005年發(fā)布的兩項關鍵技術。

對于需要應對特殊挑戰(zhàn)(使用Web服務設計分布式系統(tǒng))的架構師，Visual Studio將引入一種新的建模畫布。另外，Visual Studio還將附帶兩個使用了此畫布的設計工具：

•邏輯應用程序設計器，可用來對面向服務的解決方案的各個組件以及它們之間的交互作用進行建模。

•邏輯數(shù)據(jù)中心設計器，可用來對部署服務的處理器以及這些處理器的防火墻所在的安全區(qū)域進行建模。

這些建模工具主要是為了支持解決方案架構師和系統(tǒng)架構師之間的初期通信，從而保證設計階段能夠完整地考慮到解決方案的操作要求。Microsoft不斷地接到以下的客戶反饋：由于部署問題，許多項目都延期進行，并且超過了預算;如果事先進行更好的建模，這些問題本來都是可以避免的。

雙方的設計師都以系統(tǒng)定義模型(SDM)為目標，SDM是一種XML架構，可描述軟件組件、計算機硬件、網(wǎng)絡和交互模型。作為一種用來描述和分析互聯(lián)系統(tǒng)的建模語言，SDM是動態(tài)系統(tǒng)計劃的技術基礎(參見下文)。

SQL Server 2005具有很多改進之處，其中之一是加強了對于XML和Web服務的支持。SQL將提供：

•XML文檔的本地存儲。

•支持XQuery搜索這些文檔。

•在XML中返回結果集。

•將存儲過程公開為Web服務。

SQL Server中的若干體系結構元素將支持面向服務的數(shù)據(jù)中心內(nèi)的解決方案：

•通知服務可用于發(fā)布和訂閱信息源。

•報表服務可執(zhí)行計劃的查詢，并針對分析結果產(chǎn)生XML格式的通知。

•SQL Service Broker可用來支持在分布式數(shù)據(jù)模型上設計的服務，包括超標量的信息存儲庫。

使用“Indigo”和Windows “Longhorn”實現(xiàn)面向服務

“Indigo”將成為Microsoft對于互操作性消息的投資的高峰：

•它將成為Microsoft對于高級Web服務(WS-*規(guī)范)的實現(xiàn)。

•它將成為Microsoft用于分布式計算(從進程間通信到跨組織的Web服務調(diào)用)的統(tǒng)一消息堆棧。

•它將成為Microsoft用來開發(fā)面向服務的業(yè)務應用程序的模型和框架。

根據(jù)協(xié)定、消息、通道和服務的面向服務概念，“Indigo”將提供一個編程模型和一個消息實現(xiàn)程序。“Indigo”將支持更安全、可靠的交易信息交換和功能調(diào)用，同時它們應該符合各參與組織聲明的交換政策。

“Indigo”技術將包含到“Longhorn”客戶端發(fā)行版中，同時可供Windows XP和Windows Server 2003使用。

下一代Windows客戶端(代號為“Longhorn”)將引入創(chuàng)新技術，它們將擴展桌面參與面向服務的業(yè)務協(xié)作的能力。

“Longhorn”將引入XAML，這是一種基于XML的標記語言，可用于智能的Windows應用程序。與HTML一樣，XAML使用了一種描述UI元素的聲明語法，相對于過程聲明，它可以非常容易地通過編程方式進行生成和分析。這種創(chuàng)新將允許用戶接口更好地反映它們表示的信息，這是因為UI能夠基于交互狀態(tài)以編程方式生成。

WinFX完成了到Windows中的托管代碼的過渡，這種過渡是從2002年Visual Studio .NET的引入開始的。WinFX是下一代的系統(tǒng)編程接口。在面向服務方面，WinFX統(tǒng)一了Microsoft的多個消息模型，以檢索自Web服務的信息為基礎對代碼訪問的安全性提供了支持，并向應用程序開發(fā)人員公開了“Indigo”消息堆棧的功能。

通過動態(tài)系統(tǒng)計劃(DSI)，Microsoft正在努力提高IT的生產(chǎn)力，并降低與面向服務的系統(tǒng)的設計、部署和分布式操作相關的成本。作為此計劃的一部分，系統(tǒng)定義模型(SDM)是一項核心技術，通過為應用程序、系統(tǒng)和交互操作定義通用的語義，它使面向服務的規(guī)則可以應用到系統(tǒng)管理中。通過使用這種通用的領域特定語言，應用程序可以表達它們的技術要求，比如CPU周期、內(nèi)存容量和存儲容量，同時系統(tǒng)還可以對其資源進行描述。這種新的建模技術將能夠使業(yè)務更迅速地推出面向服務的應用程序，這種應用程序更容易部署，管理費用也更低。DSI是Microsoft和業(yè)界共同努力的結果，它將對軟件開發(fā)工具和應用程序、操作系統(tǒng)、管理解決方案及硬件平臺產(chǎn)生深遠的影響。欲了解DSI的詳細信息，請參見http://www.microsoft.com/dsi/。

創(chuàng)建面向服務的解決方案

并不是所有的Web服務都是平等創(chuàng)建的。一個雞蛋可能變成美味可口的蛋奶酥;但是如果將它放在荷蘭辣醬油上，就將變成一次讓人反胃的品嘗;或者，如果掉在了地上，它就會變成一團粘糊糊的東西。每個人都可以通過服務構建任何事物：好的，壞的，或丑陋的。

在策劃企業(yè)服務組合時，需要面對三個基本的挑戰(zhàn)：

•面向服務的分析—為了支持組織的業(yè)務優(yōu)先級，應該創(chuàng)建哪些服務?

•服務設計—應該怎樣創(chuàng)建每項服務?

•服務管理—為了支持業(yè)務服務，應該部署哪些基礎結構服務?了解和處理異常需要哪些支持?

本章節(jié)將探討所有這些挑戰(zhàn)，并進行總體的指導，告訴你現(xiàn)在應該怎樣做才能獲得面向服務帶來的直接收益;同時，它還為你提供了一些提示，這樣你就可以預測完成互聯(lián)系統(tǒng)策略所需的未來投資。

面向服務的分析

面向服務的體系結構是組織機構業(yè)務流程的建模藝術，同時它也是網(wǎng)絡可尋址的業(yè)務組件的結構完善的組合。

真正的挑戰(zhàn)來自于那個看似平常的修飾語：結構完善的。在確定對組織功能的建模起關鍵作用的信息集(請將它作為“結構化業(yè)務文檔”的一個令人討厭的同義詞來閱讀)和行為時，總有一種“翻江倒海”的誘惑——設法為組織的所有行為創(chuàng)建一個完整的自上而下的視圖，并在一個一致的企業(yè)體系結構中對其進行建模。同時，那些需要解決方案的業(yè)務單位目前正通過技術和業(yè)務流程重組投資而迅速發(fā)展。

“權宜之計”是一個強大的動力。利用它，但是也要對它進行適度的控制。在不斷的嘗試中學會爬;在不斷的交流中學會走;在不斷的協(xié)作中學會跑。

應該怎樣權宜性地定義一個服務組合呢?這里有幾個原則。

設計長期穩(wěn)定的服務，設計靈活應變的系統(tǒng)

在一個企業(yè)服務體系結構中，功能服務是構成業(yè)務流程和業(yè)務系統(tǒng)的組件。對服務接口進行建模，從而緊密地結合業(yè)務功能模型，這是一個重要的最佳實踐方法。例如，大多數(shù)制造商都有接收訂購請求的業(yè)務需求;定義一個描述訂購請求的信息集和一個接收此信息集實例的終點，即可構成一個井然有序的服務范例。

業(yè)務流程遠比它們處理的信息不穩(wěn)定。在流程中，操作者(人)的判斷甚至是一時沖動都會對處理操作造成很大的影響，同時各種服務異常情況也會對業(yè)務實例造成干擾。每個業(yè)務流程實例都可以構成一條穿過你的服務組合的唯一路線。

因此，系統(tǒng)必須具有靈活性。流程的編制應該易于修改，甚至是完全動態(tài)的。對于成功的業(yè)務系統(tǒng)而言，將硬編碼的業(yè)務流程排入已編譯的可執(zhí)行文件是一種反模式。

事件驅(qū)動的體系結構的概念對于有效的流程設計具有指導意義。流程應該能夠洞察推動其發(fā)展或使其脫離正常路線的業(yè)務事件。當異常事件使某個流程脫離正常的軌道時，應該努力使流程恢復正常，并使其返回主要的軌道;如果對整個流程進行人工監(jiān)控，將導致流程成本的激增，甚至遠遠超過流程本身帶給組織的價值。

從全局著眼，從局部著手

大多數(shù)組織都擁有幾個(也許多達10個)關鍵實體，這些實體在它們的核心業(yè)務流程里運行。一般的例子包括Customer(客戶)、Employee(員工)和BusinessTransaction(業(yè)務交易，或通稱為PurchaseOrder(采購訂單))。應努力對這幾個關鍵實體進行定義，以創(chuàng)建實體類型的組織模式，并開發(fā)實體建模的專業(yè)知識。同時，還應參閱關于指導和重復使用的正式標準和實際標準(如果你所在的垂直行業(yè)中存在著任何滿足要求的標準，那么就可以使用此標準)。

我們已經(jīng)建立了專業(yè)知識和一組觀點，下面我們要更加深入地探討如何應對業(yè)務機會和難題：

•確定進行改進的關鍵機會。

•對目前的業(yè)務方案進行建模，并適當參考現(xiàn)有的標準。

•與三到四個相關業(yè)務科目的專家一起檢查此模型。

•根據(jù)他們的反饋擴展和修改此模型。

•開發(fā)業(yè)務服務。

•重復以上步驟。

結果將不會很完美。稍后就會發(fā)現(xiàn)某些業(yè)務案例需要附加的信息。必須向業(yè)務流程模型中添加步驟。不過，有了下一條原則，你就可以對變化做好充分的準備。

對于可擴展性的設計

在時間的考驗下，任何對于要求的理解都是不充分的。為了進一步證明你的服務和解決方案，你必須將可擴展性設計進來。可擴展性有兩個關鍵領域：實體可擴展性和行為可擴展性。

在實體中擴展模式化信息的主要原則是容納一系列可能包含任何內(nèi)容的Extension(擴展名)元素。這些元素通常都會使用一個名稱來鑒別自己，并引用它們自己的架構。通過在實體定義中包含這種支持功能，你就可以創(chuàng)建多態(tài)實體。一個已擴展的Employee實體仍然可以由任何了解基礎實體的服務進行操作，不過它也可以支持那些了解實體的服務(也就是稱為TravelProfile(旅游資料)的擴展名)進行擴展處理。

不同的地區(qū)需要不同的信息。例如，一個稅號在不同的國家可能會有不同的構成方式。請勿將社會保險號作為你的Employee實體中的頂級元素;正確的做法是，包含一個可能將其子類型標記為“US-SSN”的TaxID(稅號)元素。

與面向?qū)ο蟛煌�，面向服務對行為進行了延遲的綁定——只有在實體被傳送到一個知道如何處理其內(nèi)部包含的信息的服務時，實體的“行為”才會得到綁定。

因此，可通過操作實體增加價值的公開服務基本上實現(xiàn)了行為可擴展性。如果要將新的行為綁定到實體上，可以使用很多有效的模式，但是本文不會介紹這些模式，因為它們超出了本文討論的范圍。不過，一個具有指導意義的實例是，一個服務充當了另一個服務(該服務能夠操作較大實體的元素)的門面。VerifyEmployeeAddress(驗證員工地址)也許可以接收Employee實體，并提取它的Address(地址)元素，然后將它傳送到更通用的VerifyAddress(驗證地址)服務中，VerifyAddress服務是由合適的國家郵政服務提供的。

另外，一個關鍵的指導原則是從標準化的元素組成實體，從而最大限度地提高實用服務的可重用性和通用信息元素處理的一致性。

分開的功能和操作關注點

請將你的業(yè)務服務和基礎結構服務都視作提供的功能。基礎結構服務提供了橫向的功能，它也被稱作橫切關注點或方面(比較深奧)。

在進行面向服務的分析時，你的挑戰(zhàn)是如何確定這些橫切關注點并把它們從你的業(yè)務實體中分解出來。你最需要的是單獨實現(xiàn)每個基礎結構服務，它們可以通過管道傳送，以滿足特殊消息交換的總體操作要求。

你的基礎結構服務組合可能會成為購買和創(chuàng)建行為的綜合體，如果在市場上可以獲得合適的實現(xiàn)工具，它就將以購買為主。下面的“服務管理”一節(jié)將更詳細地討論這個主題。

牢記客戶

進行以用戶為中心的設計練習是面向服務的分析的一個重要部分。這些服務有哪些用例?它們將由誰調(diào)用，為什么?用戶將會在哪些角色里訪問這些服務?誰可以調(diào)用服務，誰又不可以?需要支持哪些類型的設備和體驗?為了簡化從所有這些設備到服務的訪問，我們是否需要開發(fā)服務代理?

為客戶操作進行信息建模時，需要考慮以下幾個方面：

•只能使用XSD類型(以及由XSD類型組成的復雜類型);不要通過特定平臺的數(shù)據(jù)編碼將你自己綁定到操作平臺上。

•架構應該表現(xiàn)出對于數(shù)據(jù)值的約束，以允許客戶端在提交更新請求之前對其進行驗證;客戶端的驗證可大大減少服務拒絕請求由于數(shù)據(jù)值超出限制所帶來的成本和阻礙。(當然，即使在發(fā)布約束時，服務仍然需要驗證數(shù)據(jù)值。)

•參考信息應該具有時間戳或版本標記，以支持緩存、增量更新和連續(xù)的更新請求。

在服務可用時，你的組織里的聰明人會找到辦法來使用它。請不要假設你在設計階段所能夠確定的客戶是所有將會調(diào)用此服務的客戶。請不要寄希望于客戶對服務協(xié)定會有更深入的理解，也不要相信客戶只會向服務發(fā)送有效的請求。

服務設計

面向服務是創(chuàng)建分布式系統(tǒng)的最佳實踐方法的發(fā)展和完善。與此相同，它的模式來自于分布式對象技術和面向消息的中間件解決方案的成功之處，同時它也確定了這些體系結構的不完善之處導致的反模式。“Indigo”小組的Don Box確定了在考慮面向服務時要牢記的四個原則：

•原則1：邊界是顯式的。通過邊界后面的顯式消息傳遞方式，服務可以進行交互。對于服務邊界之后的空間，我們不做任何假設。跨越服務邊界可能需要很高的成本(例如，你可能需要擴展地域、可靠的邊界或執(zhí)行環(huán)境)。通過在服務之間正式地傳遞已定義的消息，我們明確地決定調(diào)用服務。顯式的邊界使我們可以正式地展示獨立于實現(xiàn)過程的交互操作——我們不必明確地選擇實現(xiàn)其它服務所使用的平臺、中間件或編碼語言。

•原則2：服務是自治的。作為獨立的實體，服務采取了合理的行為。對于服務邊界之間的空間，我們不做任何假設。在面向服務的環(huán)境中，并沒有主導的權威。服務的部署、版本控制和管理都是獨立的。執(zhí)行服務的拓撲可能會(也必將會)不斷地發(fā)展。服務應該預料到對等的服務可能會(也必將會)失效，而且它可能會(也必將會)收到殘缺的或惡意的消息。應該使用冗余和故障轉移等技術來創(chuàng)建服務，以避免服務失效。

•原則3：服務對架構和協(xié)定(而不是類)進行共享。服務只在其使用架構的結構表達式和使用協(xié)定的行為表達式上進行交互。服務的協(xié)定描述了消息的結構和消息的排序約束。表達式的形式使機器可以驗證傳入的消息，這樣我們就可以保護服務的完整性。在時間變化時，協(xié)定和架構必須保持穩(wěn)定，因此靈活地創(chuàng)建它們(例如，通過在架構中使用xsd:any)很重要。

•原則4：服務的兼容性是以策略為基礎的。服務提供者和服務消費者都具有與跨邊界交互相關的策略——操作要求。提供端策略的一個簡單示例是，服務可能需要調(diào)用者在服務提供者那里擁有有效的帳戶。從消費端的角度來說，組織可能需要對跨越Internet的服務調(diào)用進行加密，這樣它就只能使用可提供安全性增強的雙向數(shù)據(jù)交換功能的服務。服務使用了機器可讀的策略表達式來表現(xiàn)其功能和要求。策略斷言是由一個穩(wěn)定的全局唯一名稱來標識的。單獨的策略斷言對于整個系統(tǒng)而言是難以理解的;服務必須能夠滿足彼此的策略要求。

在你的服務邊界上進行的通信應該支持以上的原則。對于面向服務的環(huán)境中存在的服務，這些原則需要它們之間的架構、協(xié)定和策略的正規(guī)表達式。可以開發(fā)專門為眼前的問題創(chuàng)建的機制，以表示服務的邊界，但是這些機制僅限于創(chuàng)造者的影響范圍之內(nèi)。例如，如果你開發(fā)了一種系統(tǒng)，這種系統(tǒng)能夠以一種特殊的方式表示架構和協(xié)定，而只有你的部門才能識別這種表示方式，那么你就避免了你的服務在你的部門之外被使用。

為了充分實現(xiàn)面向服務帶來的利益，你的服務邊界表達式必須得到最廣泛的采用，并具有最高的互操作性。本行業(yè)已將SOAP消息中傳播的WS-*協(xié)議明確選定為服務的互操作性標準。在實際應用時，面向服務需要獲得Web服務和SOAP消息，并使用WS-*協(xié)議。

選擇一項支持面向服務的消息技術就相當于選擇了一項能夠支持SOAP和WS-*協(xié)議的消息技術。在目前發(fā)布的Microsoft技術中，這項技術指的是ASP.NET中的.asmx。如果你需要支持不斷發(fā)展的WS協(xié)議，請結合WSE使用.asmx。如果要以一種互操作的方式公開架構、協(xié)定和策略，并且此過程要獨立于實現(xiàn)過程，那么請選擇.asmx，因為它在目前的Microsoft消息技術中提供的支持是最好的。

服務邊界的重點在于，在邊界內(nèi)可以使用任何實現(xiàn)工具。如果你通過ASMX和/或WSE正式指定了你的服務邊界，那么你就可以在這些邊界內(nèi)選用任何技術或消息堆棧執(zhí)行處理和數(shù)據(jù)交換。為了實現(xiàn)簡單性和一致性，我們推薦保留此服務模型，并結合服務邊界使用ASMX。不過，無論是為了支持特定的功能，還是為了支持現(xiàn)有部署工具的使用，MSMQ、Remoting或Enterprise Services都是服務邊界內(nèi)的合理選擇。如果要實現(xiàn)服務的邊界接口，這些技術就不適用了。

服務管理

SOAP規(guī)范的精妙之處在于，它允許從服務的操作要求(例如，與傳送消息相關的指令和對服務的授權訪問)中明確地分離服務的功能要求(服務將要處理的業(yè)務信息)。SOAP消息的正文滿足了功能要求;SOAP消息標題中的元素滿足了操作要求。

就保持這種方式。如果你支持消息登錄到你的Employee實體中，你就需要創(chuàng)建一個可以分析Employee實體的消息登錄實現(xiàn)工具。如果你擁有這樣一個通用的消息登錄實現(xiàn)工具——它可以在SOAP標題里定位合適的元素，而不用去管SOAP正文里包含了什么，你的工作就會方便很多。

可互操作的基礎結構服務的開發(fā)和維護是一個成本很高的項目。基于WS-*規(guī)范創(chuàng)建值得信任的服務實現(xiàn)工具，對它們進行測試并將測試結果與所有合作伙伴組織使用的實現(xiàn)工具相比較，將會超出大多數(shù)IT預算的范圍。系統(tǒng)供應商可以跨越更廣闊的用戶群利用這些開發(fā)成本，并針對其他供應商的補充技術測試互操作性。在創(chuàng)建這些服務(而不是從系統(tǒng)供應商處獲得這些服務)之前，各個組織應該進行認真的思考。

那么，在系統(tǒng)供應商仍然把持著WS-*規(guī)范的實現(xiàn)工具的情況下，為了滿足目前的操作要求，IT部門應該怎樣做呢?

折衷。使用能夠最有效地滿足你的需求的現(xiàn)有技術，如果本地服務技術具有可用性并得到了你的系統(tǒng)供應商的充分支持，那么就計劃向本地服務技術進行移植。如果你需要保證傳輸?shù)陌踩�性，請使用HTTPS;如果你需要可靠的消息功能，請使用MSMQ。

某些操作要求將會簡化組織的服務組合，但是并不會得到系統(tǒng)供應商的良好支持。一部分示例可能來自于垂直行業(yè)的需求，例如，在汽車行業(yè)中需要跟蹤零部件的來源;同時，其它示例可能是完全組織化的，比如主動的跟蹤調(diào)查計劃，其目的是在雇傭和提拔員工的過程中保證平等的機會。

當你需要設計和創(chuàng)建這些服務時，請參照供應商的WS-*協(xié)議實現(xiàn)工具中出現(xiàn)的模式：

•與相關的集團進行合作，以有效地收集需求;對于垂直行業(yè)的需求，可與貿(mào)易伙伴甚至是競爭對手合作。

•為SOAP標題定義架構，這種SOAP標題可以附加到任何消息上，以傳送操作信息。

•考慮一組可有效地重復利用的關注點和因素。例如，一條包含保健信息的消息可能需要傳達多個具有相似結構的隱私聲明。

•通過重復利用處理了真正的橫向關注點(比如對于物理地址的描述)的工作成果來構成你的架構。

•重復構建過程;在時間和預算允許的情況下，努力構建你的消息基礎結構。

面向服務的解決方案的模式

那么，為了創(chuàng)建互聯(lián)系統(tǒng)，你現(xiàn)在應該怎樣做呢?是否應該立即著手圍繞面向服務的模型重新設計你的整個應用程序組合?還是應該先觀望一下?

Microsoft自身的經(jīng)驗通過我們的客戶和合作伙伴的經(jīng)驗得到了加強，它提出了一個更適當?shù)姆椒ā，F(xiàn)在，對于許多的業(yè)務和技術模式，面向服務都提供了明確的利益。

最普遍的模式是信息集成，它在Rum Island crawl(爬)方案中得到了描述。由于技術體系結構在過去的30年里不斷地發(fā)展，組織開始管理或獲得大量的分布式冗余數(shù)據(jù)。例如，一個客戶的完整描述信息可能會傳播到一打業(yè)務應用程序和數(shù)據(jù)庫。這種信息很難完全同步，為了實現(xiàn)最佳的客戶(或合作伙伴或員工)交互而進行的信息聚合也無法得到足夠的支持。信息集成服務是一種有效的方法，它可以使用這些關鍵實體的統(tǒng)一視圖來表示你的應用程序組合，并保證你的所有后端系統(tǒng)之間的信息的一致性。Microsoft的內(nèi)部項目Alchemy就成功地克服了我們在公司信息存儲區(qū)問題上的挑戰(zhàn)。信息集成項目可以從戰(zhàn)術角度(比如Rum Island的例子)到廣泛的戰(zhàn)略角度(逐漸深入的信息訪問再設計和跨企業(yè)管理)運行。

傳統(tǒng)集成模式描述了對于服務的戰(zhàn)術性使用，其目的是保留對業(yè)務應用程序的現(xiàn)有投資，同時擴展它們實現(xiàn)的功能。例如，為了符合新的規(guī)定，服務可能會在現(xiàn)有的ERP包前增加支持功能。應用程序也將得到重新設計，以便與服務交換消息，服務將會提取與合規(guī)性有關的數(shù)據(jù)，然后向ERP包發(fā)送請求。

上一個例子提出了一個更廣泛的面向服務模式：流程管理。在此模式中，“標題”元素用來傳送關鍵的業(yè)務元數(shù)據(jù)——從客戶請求的周轉時間到特殊業(yè)務決策批準者的身份。基礎結構服務將會捕捉到此元數(shù)據(jù)，以用于實時分析和/或聚合分析。“本地服務”流程將會把此信息包含在SOAP標題中，非本地應用程序則需要進行重新設計，以便將元數(shù)據(jù)作為消息傳送到管理服務器。

另一個略有不同的模式(或者可以直接稱為派生的模式)是一致的訪問——在一組不同的應用程序需要連接關鍵的后端資源時，使用服務層來保證各種操作要求得到一致的執(zhí)行。通過命令所有訪問通過一個服務接口進行路由，組織可以執(zhí)行一致的訪問授權、成本分配和負載管理。

許多服務都提供了某種形式的資源虛擬化。這里有一些例子：

•區(qū)分上下文和區(qū)分內(nèi)容的請求路由，比如向指定地區(qū)的農(nóng)場房地產(chǎn)專業(yè)代理商發(fā)送房地產(chǎn)咨詢問題。

•到分區(qū)信息存儲區(qū)的請求路由(請求者無須了解分區(qū)方案)。

•跨越可用資源的負載平衡請求——從客戶服務代表到流視頻源。

最后，各組織都非常成功地使用這些服務實現(xiàn)了流程具體化。目前，通過使用Web服務，使用者可以安全地協(xié)商工資單處理情況、員工費用報銷和后勤支持等事宜。移動電話服務提供商和Internet門戶使用Web服務來聚合各種內(nèi)容。需要面對客戶的組織使用Web服務來創(chuàng)建合成的報價材料，比如包含了飛機票價和租車價格的信息包。基于目前的技術堆棧，流程具體化取得成功的關鍵是對你自己的要求進行管理——根據(jù)現(xiàn)有技術的限制，折衷處理你的要求，這樣你就無須使用你的利潤或儲備資金來創(chuàng)建將會在幾年之內(nèi)更換的基礎結構服務。

這些只是高級模式的幾個例子，你的組織目前可能會用到這些高級模式。你了解你自己的業(yè)務;互聯(lián)系統(tǒng)怎樣才能幫助你呢?

分享：ASP.NET2.0服務器控件之捕獲回傳事件
1、實現(xiàn)捕獲回傳事件 如果服務器控件需要捕獲來自客戶端的回傳事件，并想為該回傳事件自定義服務器端事件處理邏輯，那么控件必須實現(xiàn) System.Web.UI.IPostBackEventHandler接口。下面列舉了該