Web Services infrastructure for SOA

在早期第一個版本的 Web Services的概念中，當時提出的幾個技術規範包括了有 SOAP , WSDL , UDDI , 這些足可用於建構出鬆散耦合的web services，那麼時至今日來到了 Web Service 2.0之後，我們可以看到的是 WS-BPEL , WS-CDL，這兩者用來建構出將web service 築基於整個業務流程底下，將之看作為整個業務流程的基石，並且透過互動合作關係的允許與協同作業使其完成一組完善的企業流程。 雖然上述二者是達成企業流程服務的最基本要求，但以嚴謹且功能強大的企業服務來看，光只有這兩者還不夠，還需要有幾個議題需要注意，像是 WS-Addressing / WS-Security / WS-Reliability / QoS / WS-Collaboration 等等。 在第一個版本出來的 Web Service SOAP, WSDL , UDDI 提供了一個企業級服務的基礎建設，在後續的 WS-BPEL / WS-CDL 則更進一步的能讓我們更優雅、順暢的進行business process的組織建構，在這裡要特別地強調一件事情，要提供Web Service 只需要有 SOAP / WSDL / UDDI即可，WS-BPEL 與WS-CDL並非是必要的，只是當你考量到要在整個企業服務中執行business process，那麼選擇搭配使用這兩者會是一個很好的選擇。 看書看到這裡有一個感慨，為啥密人家的設計都一直強調兩個重點 ( Robust / Elegant )，可是我們實際在go的時候卻一直很難企及這個目標~(遠目)... 1st web service generation edition 搭配 WS-BPEL / WS-CDL即是期望可以達成這兩個目的，不過這也剛好讓我意識到一件事情，整體需求在 functional的部分就是只靠 1st generation edt Web Service即可達成，而non-functional的部分就是可以考慮用 2nd gen~ ... 在這樣的non-functional的需求下，各種不同的聲音與需要漸漸的被各大IT領頭羊逐步訂下規範與提供實作，以下是幾個標準spec

• WS-Collaboration


• WS-Addressing


• WS-Reliability and WS-Reliable Messaging


• WS-Security

PS : 並非每一個spec 都一定要在你實作SOA服務中都用上，端看你真實的需要，還有你的預算:D Message Exchange PatternsSOAP message的交換可以是 同步/非同步模式，整體(collectively)的看這些多樣的訊息傳遞模式可以用一個term來統稱 -- Message Exchange Patterns( MEPs )，在我們進到2nd gen~ web service之前，先重溫(revisit)一下訊息傳遞的幾種方式：

• Request-Response


• Solicit-Response


• One-Way


• Notification

在新版本的WSDL  2.0 spec當中，支援了八種不同的MEPs

• In-Out pattern -  Equivalent to the Request-Response


• Out-In pattern - Equivalent to Solicit-Response


• In-Only pattern - Equivalent to One-Way or the Push technology of  traditional MEP


• Out-Only pattern - Equivalent to Notification of traditional MEP


• Robust In-Only pattern - 進階版的 In-Only ，在訊息提交的過程中若發生了錯誤，可以進行error handle以及訊息回應


• Robust Out-Only pattern - 進階版的 Out-Only ，在訊息提交的過程中若發生了錯誤，可以進行error handle以及訊息回應


• In-Optional-Out pattern - 更進階版的In-Out MEP，response在整個訊息傳遞過程是optional，同時也支援error handle


• Out-Optional-In pattern - 更進階版的 Out-In MEP，request 在整個訊息傳遞過程是optional，同時也支援error handle

WS-* -- The New Generation

• WS-Addressing

最一開始，WS-Addressing這個spec事由IBM / Micorsoft / BEA / Sun / SAP 定義出來的，目前已經成為了W3C的標準之一，這個規範提供了web service 能夠對 服務位址進行溝通傳遞，這基本上包含了兩個部分

• Structure for communicating a reference to a web service endpoint


• A set of Message Addressing Properties - 通常會與要傳遞的訊息主體有關




• WS-Atomic Transaction

定義出這個protocol是為了可達成分散式交易的process，使其可被使用成為 WS-Coordination的一部分。

• WS-Coordination

Coordination顧名思義是要進行協同合作，使得一個因業務需要的完整bp可以被正常執行，這是一個完整的framework，其中包括了有 WS-Atomic Transaction , WS-Business Activity, WS-BPEL。

• WS-Eventing

Eventing主要是專注於 addressing reqirements時採用 Pub/Sub  web service架構的事件處理，通知每個訂閱者當web service 準備進行執行 或者已完成的事件。

• WS-Metadata Exchange

The specification enables the requester to send a standarized message requesting some or all information regarding the web service being consumed.

• WS-Notification

解決發送訊息時使用 pub/sub web service 架構的通知作業

• WS-Policy Framework

包含了 WS-Policy / WS-Policy Attachments / WS-Policy Assertion

• WS-Reliability / WS-Reliable Messaging

• WS-Security

WS - * -- A Working Definition這裡先記錄一些在2nd gen~ web service常用到的spec 在使用上的概念與說明

• Addressing

定址，在兩個application之間要進行溝通時，我們總會希望這整個溝通傳遞過程是處在一個可被信賴的以及安全的環境下來進行，而這樣的溝通過程通常會伴隨著一連串的交易，WS-Addressing spec 就是企圖要去尋找這整個溝通的過程的目的位址資訊，所以整個addressing 總會包括了有 Source of Message / Dest of Message / Routing details of Message / Instructions for what needs to be done in case of faults and nondelivery and so on ...

WS-Addressing將這樣的需求實作，放在 SOAP header裏頭，詳細的tag 參考W3C規範(目前最新版本是SOAP 1.2)，WS-Addressing spec 定義了兩種不同type的 SOAP Headers如下：

• Message Addressin Properties

這種類型的SOAP header，位址資訊可以包括有標準的header entries -->  destination, source endpoint, reply endpoint, fault endpoint, message ID, relationship, action

• Endpoint References (EPR)

EPR類型的 header 封裝了位址資訊，可使用的entry 包括有 --> address, reference properties, reference parameters, service port, port type, policy

[caption id="attachment_588" align="alignnone" width="483"] ws-addressing[/caption]

• Reliability and Reliable Messaging

在訊息的傳遞方式中web service提供了同步與非同步模式，而一旦我們使用的是非同步模式時，會要考量到幾件事情：

• 確切的將訊息送達至目標系統


• 檢查是否有傳遞失敗的狀況


• 對於訊息傳遞的順序性與優先權的設置是否真的如預期的進行完整傳送

如果訊息無法被傳遞的話，系統將會產出一個你所設置預期的錯誤訊息，並記錄你錯漏的這個message。

[caption id="attachment_590" align="alignnone" width="534"] WS-Reliable Messaging[/caption]

• Security