[Develop]Lab4-Orchestration
| Lab4 、 協調流程 |
| 在接下去的開發專案中，浩呆想花點時間跟大家分享一些我的心得。Biztalk 有一個很重要的核心元件叫做 [ 協調流程]。浩呆一直認為這個名子取得很好。 首先我們要把這四個字拆開來看，[ 協調 ] 與 [ 流程 ]。我們先來討論後者 [ 流程 ] 這件事 。浩呆在開發過程中喜歡用下列的方式來拆解我遇到的問題。 首先我們來舉一個例子，" 訂 Pizza 流程 "( 我的範例中好像常常出現訂Pizza這件事 ><||| 假如當我們要訂購 Pizza 時( 我們要外送 )，我們用下圖來描述這個流程。 1 . 我們先打了電話給櫃檯人員訂購我們要的口味，並且告知地址還有聯絡電話。 2 . 櫃檯人員會產生一張訂單。 3 . 櫃檯人員將訂單交給廚房工作人員。 4 . 廚房人員在收到單子後，按照單子來製作出顧客要的口味Pizza。 5 . 廚房人員做好 Pizza 後，會將Pizza 一併交給外送人員。 6 . 外送人員將Pizza送到我們家裡。 7. 我們付款給外送人員。 8. 外送人員回到店裡後交回從顧客那收到的錢。
接者我會習慣用合作圖來表示這個流程，也常常在這個過程中會出現許多流程中原本沒有看見的物件。例如整個訂Pizza流程其實櫃檯人員還要輸入資料， 並且產出資料的是POS系統或是列表機…等。假設我們要撰寫這樣的流程時，我們發現整串流程就是一個個的服務所建立起來的。 每一個節點都是一個服務，並且這個服務又可能自有另一個流程。或是程序。好比說外送人員這個服務提供一個收取費用的功能，但是收取費用 本身可能又可以展開成一個流程去判斷；萬一超過30分鐘才送達要再扣100元…等這類的判斷。所以我喜歡依據服務將他們拆成一個個獨立功能別來設計。 所以我通常都認為流程是一個邏輯，他由許多必要的服務組成。所以流程因該要被造的很彈性。而就物件導向觀念而言，這些有功能的服務就是用類別來 表現。所以我都將流程想像成下列這種公式。 1. 流程 = ( 服務 + 服務 + 服務 ) 。 2. 流程 = ( 服務 + 服務 + 服務 ) + 流程。 2. 服務 > = 類別。
在設計過程中我們可以依據功能別，將這些腳色一一的獨立開來做設計。就SOA的精神他也應該要這麼做。使得原件與元件 之間有高相關性，卻是低耦合性的存在。每個元件到最後都各司其職 ( 人類的生活模式不也很類似這樣 )。這樣所有腳色只要清楚的定義 他的Input 與 Output ，我們就可以很容易的取用他的功能( 至於元件間到底怎麼要傳輸資料，這就牽扯到所選用的通訊協定，除了Web 也可以選擇WCF來協助我們。)。 協調 接著，我們來思考協調的概念。剛剛我們討論到我們把流程拆成一個個的服務，以服務角度出發撰寫每個元件。這時一個訂Pizza的流程 就可能被我們分成許多獨立的元件，那我們又要怎麼將這個流程給實踐出來呢? 。這時就是 Biztalk 協調流程元件的魅力所在。他可以為我們來做流程 的連結。就剛剛訂Pizza的流程中，其實還有許多我們會遇到的問題。例如這個流程是一個至少要持續10~15分鐘的流程，所以在協調轉遞資料時。 常常會面臨一些等待應用程式回應的情況，所以在因為協調流成的彈性，為過去的開發方式省下不少的工。
在協調流程中的左右兩邊各有連接埠介面與接收埠介面，這就是邏輯位置。也就是說我們在協調流程中可以拉出很多對外的 連接埠設定，但是這邊卻不針對實體位址或是通訊協定多做什麼設定。實際上在我們可以在後續的作業在我們建立出來的連接埠位置 上去綁定真正要用的實體位置。他可以是一個FTP協定，也可以是一個Web Service。這個觀念有點像我們在WWF中介紹的 Lab12 Lab1。這樣的作法保留了我在協調一個流程時，可能會遇到的各式不同的元件。並且不會受限於元件指定的通訊協定。因為很多 東西不一定都有提供支援Web Service。所以這樣的設計方式保留了SOA精神的彈性。因為雖然是以服務為導向精神為出發，但是你避免不了 流程是由一群中不同通訊協定所組織而成的一個邏輯架構。 因此在 [ Biztalk 組態資料庫 ]我們可以點選我們所設計出的協調流程。
展開後可以看到在連接埠右邊都有對應的實體位置，而左邊就是我們在協調流程中拉出來的連接埠。而輸入的接收位置還可以指定到許多 不同的通訊協定上，只要傳送進來的檔案格式是一致的即可。
|
