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

面向服務的業務環境

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

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

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

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

對于開發人員和解決方案架構師而言，面向服務是一種創建動態的協作應用程序的方法。通過支持運行時選擇的功能提供程序，面向服務允許應用程序對特定業務流程的內容和環境具有敏感性，并隨著時間的推移適度地合并新的功能提供程序。

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

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

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

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

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

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

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

•我們的系統是否能夠針對我們的業務目標有效地提供價值?

•我們的技術投資能夠實現一般任務的自動化，并對我們的員工的工作進行配合，從而克服復雜的挑戰，這能否使我們最大限度地提高生產力?

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

通用的功能調用模型是面向服務的重點，而面向服務是有效的互聯系統策略的核心。

服務和互聯系統

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

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

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

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

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

•標準協議，可以跨越操作環境和組織之間的邊界傳遞信息。

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

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

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

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

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

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

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

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

•自動化系統—它們屬于客戶端，這些客戶端一般不呈現UI，除非需要引發異常。

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

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

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

•企業體系結構—對組織的目標、優先級、資源和流程進行系統建模，以實現有控制的改進所需的自我意識。

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

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

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

•事件驅動的體系結構—在這種模型中，業務事件(例如，部件到達碼頭或對發票付款)可觸發消息發送到訂閱服務，這樣它們就可以采取適當的措施。

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

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

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

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

•靈活性—這種系統的設計是為了響應業務請求的特殊環境和內容，以及業務要求和業務策略的更廣泛的變化。

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

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

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

第一步：爬

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

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

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

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

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

•ProcessShipment(進行發貨)：接收Shipment(發貨)文檔，將它與訂單相關聯，然后更新后端系統。

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

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

第二步：走

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

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

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

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

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

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

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

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

第三步：跑

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

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

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

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

面向服務的技術

Microsoft對于面向服務的投入

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

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

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

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

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

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

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

面向服務的目前狀況

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

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

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

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

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

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

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

Visual Studio為企業的行業應用程序提供了最佳的開發環境，它一直保留了這種傳統。Visual Studio .NET支持Web服務的實例包括：

•服務部署

•XSD創作

•WSDL的自動生成

•UDDI注冊

•數據中心部署包

•通過UDDI發現客戶端服務

•客戶端服務綁定

•服務代理的自動生成

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

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

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

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

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

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

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

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

•XML文檔的本地存儲。

•支持XQuery搜索這些文檔。

•在XML中返回結果集。

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

SQL Server中的若干體系結構元素將支持面向服務的數據中心內的解決方案：

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

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

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

使用“Indigo”和Windows “Longhorn”實現面向服務

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

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

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

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

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

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

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

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

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

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

創建面向服務的解決方案

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

在策劃企業服務組合時，需要面對三個基本的挑戰：

•面向服務的分析—為了支持組織的業務優先級，應該創建哪些服務?

•服務設計—應該怎樣創建每項服務?

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

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

面向服務的分析

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

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

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

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

設計長期穩定的服務，設計靈活應變的系統

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

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

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

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

從全局著眼，從局部著手

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

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

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

•對目前的業務方案進行建模，并適當參考現有的標準。

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

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

•開發業務服務。

•重復以上步驟。

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

對于可擴展性的設計

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

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

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

與面向對象不同，面向服務對行為進行了延遲的綁定——只有在實體被傳送到一個知道如何處理其內部包含的信息的服務時，實體的“行為”才會得到綁定。

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

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

分開的功能和操作關注點

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

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

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

牢記客戶

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

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

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

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

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

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

服務設計

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

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

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

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

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

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

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

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

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

服務管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Microsoft自身的經驗通過我們的客戶和合作伙伴的經驗得到了加強，它提出了一個更適當的方法。現在，對于許多的業務和技術模式，面向服務都提供了明確的利益。

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

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

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

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

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

•區分上下文和區分內容的請求路由，比如向指定地區的農場房地產專業代理商發送房地產咨詢問題。

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

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

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

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

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