分散-集中範例運作方式

發行項
10/14/2023

範例應用程式會建置一組 SOAP 標頭，其中包含從 Scatter-Gather 路線檔案載入的路線、從磁片載入指定的訊息檔、將路線標頭附加至訊息，以及透過斜道將它提交至 ESB 進行處理。如果路線產生回應，應用程式會收集此回應，並在應用程式視窗中顯示它。

為了協助您瞭解路線服務如何使用訊息中的路線資訊，下列清單會顯示名為 ScatterGatherItinerary.xml 的範例路線組態檔。此行程的第一個區段會指定兩個服務調用步驟。

<Itinerary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" uuid="" beginTime=""   
    completeTime="" state="Pending" isRequestResponse="false"   
    xmlns="http://schemas.microsoft.biztalk.practices.esb.com/itinerary">  
  <ServiceInstance uuid="" name="ScatterGather" type="Orchestration"  
                   state="Pending" position="0"   
                   isRequestResponse="false" xmlns="" />  
  <Services xmlns="">  
    <Service uuid="" beginTime="" completeTime="" name="ScatterGather"  
             type="Orchestration" state="Pending" isRequestResponse="false"  
             position="0" serviceInstanceId="" />  
  </Services>  
  <Services xmlns="">  
    <Service uuid="" beginTime="" completeTime="" name="DynamicTest"  
             type="Messaging" state="Pending" isRequestResponse="false"  
             position="1" serviceInstanceId="" />  
  </Services>  
</Itinerary>  
...

遵循路線中的服務調用步驟清單是包含解析程式和連接字串的詳細資料區段，可讓路線服務找出路線中定義的每項服務，如下列 XML 所示。

<ResolverGroups xmlns="">  
 <Resolvers serviceId="ScatterGather0"><![CDATA[BRE:\\policy=ResolveEndPointScatterGather;version=;useMsg=;]]><![CDATA[UDDI3:\\serverUrl=http://localhost/uddi;bindingKey=uddi:esb:purchaseordersubmitorderservicebinding;credentialType=Ntlm]]></Resolvers>  
<Resolvers serviceId="DynamicTest1"><![CDATA[UDDI3:\\serverUrl=http://localhost/uddi;bindingKey=uddi:esb:orderfileservicebinding;credentialType=Ntlm]]>  
</Resolvers>  
  </ResolverGroups>

在此範例中，應用程式會執行 SubmitPOService Web 服務兩次，因為兩個解析程式連接字串都會解析為此服務的位置 (http://localhost/ESB.CanadianServices/SubmitPOService.asmx). 訊息內容會將 Broker 協調流程指定為要啟動的第一個路線服務，如下列範例所示。

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "ScatterGather")  
     && (Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState ==   
    "Pending") && (Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType   
    == "Orchestration")

Broker 協調流程會分析其路線步驟的設定，並擷取與路線步驟相關聯的解析程式集合。針對這些解析程式，協調流程會使用 Microsoft BizTalk ESB 工具組解析程式和配接器架構來解析服務端點。 Broker 協調流程接著會以非同步 (方式啟動 n 個 ServiceDispatcher 協調流程，其中 n 是行程中與 ScatterGather 服務相關聯的解析程式數目) ，以下列參數分派要求訊息：

TransportLocation。解析程式會填入此參數。
TransportType。解析程式會填入此參數。
ResolverDictionary。此參數包含具體解析程式實例所填入的解析程式事實集合。
InboundMessage。此參數包含包含路線的原始訊息。
ServiceResponsePort。此參數是自我關聯回應埠的名稱，可接收來自 ServiceDispatcher 協調流程實例的回應。

ServiceDispatcher 協調流程的每個實例都會使用 ResolveMapScatterGather 原則，根據 TransportType 和 TransportLocation 屬性來解析要求和回應訊息的 Microsoft BizTalk 對應類型。協調流程實例會使用已解析的對應，將輸入訊息轉換成 Web 服務呼叫的要求訊息。

ESB 配接器管理員會在要求訊息上設定輸出傳輸內容屬性，BizTalk 接著會轉送到名為 ServiceRequestPort 的 solicit-response port。

當服務收到回應訊息時，ServiceDispatcher 協調流程會使用解析的對應資訊，將輸入回應訊息轉換成標準格式。然後它會將修改過的回應包裝在 ServiceResponse 信封中，並透過自我關聯埠將其轉送至 Broker 協調流程。 Broker 協調流程會匯總所有傳入的回應，並使用 GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline 準備最終回應訊息，如下列程式碼所示。

AggregatedResponse.Body = null;  
AggregatedResponse(*) = InboundMessage(*);  
Microsoft.XLANGs.Pipeline.XLANGPipelineManager.ExecuteSendPipeline(  
    typeof(GlobalBank.ESB.ScatterGather.Processes.AggregatingPipeline),  
    messageAggregator,AggregatedResponse);

此程式碼會將整個回應批次包裝在預先定義的信封內。 Broker 協調流程接著會將路線前進到 DynamicTest 路線步驟，如下列程式碼所示。

// Copy the context and advance the itinerary.  
OutboundMessage = AggregatedResponse.Body;  
OutboundMessage(*) = AggregatedResponse(*);  
// Advance the Itinerary to the next step.  
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep);

因為名為 DynamicTest 的服務類型屬性設定為 Messaging， 所以 TravelyHelper 類別會將解析程式屬性升階為名為 OutboundMessage的訊息內容。 Broker 協調流程會將此訊息傳送至 BizTalk 直接系結埠。 BizTalk 接著會將訊息轉送至 ServiceName 訂用帳戶所代表的動態傳送埠，也就是 DynamicTest。此傳送埠會將最終匯總的回應序列化為 \Source\Samples\DynamicResolution\Test\Filedrop\Out 資料夾。

共用方式為

分散-集中範例運作方式

意見反應

其他資源