現實中的 SOA 與 PHP

edited 十月 2013 in 進階PHP討論
3. SOAP 和 ATOM 的協定的支援 , 若貴司為商店街客戶 , 可與該頻道恰談 . 人際面和業務面上的溝通不是在背後的 complain .
4. 您懂 SOA 的實做嗎? 在下到 PCHOME 不久 , 但在 SOA 這一塊實做金融和電信產業有實做經驗 . 但我是在 IBM 和 BEA 的平台上用 Java 實作相關協定的.

關於 pchome 後台電子商務系統...

SOA 的基本概念,是將一個已上線的 system 視為一個 class/object ,使 programmer 可以訊息驅動的方式編寫新的軟體功能。從 CORBA, DCOM 的觀點, SOA 是它們的實踐。雖然現實上的 SOA 大多不是用這兩種技術實作,但 SOA 概念仍然是 OOP 的延伸,是一種在 software/system 層次上的 OOP 。 (初學者接觸的是 source code, library 層次上的OOP) 因此,一個號稱支援 SOA 的系統,應該要有 public method ,不需要調用者了解其實作細節。我不需要知道 pchome 的系統是用 java 還是 .net ,也不需要知道它們的訊息傳遞機制是用 ESB, BizTalk 還是什麼樣的 message queue 機制。我只看 public 的部份。

就訊息格式來看:
1. 不提供 XML 格式的查詢結果。
2. 不提供 JSON 格式的查詢結果。
3. 僅提供 HTML 格式的查詢結果,而且是給人看的,所以要換頁、夾雜許多格式化內容。

就方法調用來看:
1. 不提供 SOAP+WSDL 。
2. 不提供 REST 。HTTP GET method 當然有提供,但無相關資訊,要自己判斷,例如 url 上的參數就要自己試驗。

就訊息發佈來看:
1. 不提供 ATOM publishing
2. 僅提供 HTTP POST method ,但無相關資訊,要自己看 html 。

不用問到實作細節,先看看 service 的 public method ,我所知道的 standard 方式皆不提供。試問協作廠商如何將 pchome 的電子商務系統視為一個 service component 呢?喔,當然可以,只是我寫得很煩;反應過又沒回應,只好 complain 。

ex. programmer 將整個 system 視為一個 class/object 封裝起來 ,透過 public method 調用,其概念會像這樣:

class PchomeService {
protected SOAService pchome;
public Product getProduct(ProductId id);
public ProductId createProduct(Product product);
public boolean updateProduct(Product product);
}


如果我還要先知道他的系統是如何實作的,那概念就變成這樣:
class XXXService { //某系統實作內容
}

/*
我要先繼承 (可接觸到該系統的實作細節) ,才能實作我要的 method 。而我在實作過程中必須調用父類別的保護方法與成員,才能完成工作。
*/
class PchomeService extends XXXService {
protected SOAService pchome;
public Product getProduct(ProductId id);
public ProductId createProduct(Product product);
public boolean updateProduct(Product product);
}

用 PHP 當然可以作 SOA ,甚至本來就應該這麼用。我們反而要先感謝其他人用 Java 實作 ESB 這些 message queue 機制。用 PHP, Ruby 實作 message queue 這些底層內容不是個好主意;PHP, Ruby 的強項在調用 service ,快速組合出新的軟體功能。當然不透過特殊的 message queue ,而僅將 http server 視為 message queue 也是可以的,例如 RoR + light httpd 這樣的組合已經在實務上被廣泛應用 (例如 Hemidemi)。不需要用到 XML, SOAP, WSDL, ESB 那些正規軍, RoR, PHP 也可以用輕量級的方式實踐 SOA 。

原始討論: http://twpug.net/x/modules/newbb/viewtopic.php?topic_id=2359

評論

  • edited 一月 2007
    看完了~
    我個人是覺得,如果沒有「標準」,你得定一個出來,以你的例子來說,就是要定義「什麼是PChome」、「PCHome提供哪些服務」、「如何和PCHome溝通」等等任務。

    假設目前的現行架構不變,你可以獲得內部資源的協助作為前提,最快的方式是另外弄一台Application Server,透過這台AP去實做上述的任務,並提供統一的接口對外服務。
    至於是否要用PHP或是Ruby來作,這倒不一定,看你習慣用哪個工具就用吧~

    當然,實做上如果趕著上線的話,初版不要提供太多的服務,因為你必須去hack收到的HTML,把有用的資訊「抽」出來,轉換成你要的格式。

    之後就得開會跟其他小組的人協調,要求他們撰寫Interface文件,大家根據文件來寫程式。

    總歸一句話:無規矩不成方圓。
  • edited 一月 2007
    「什麼是PChome」、「PCHome提供哪些服務」、「如何和PCHome溝通」

    呃,我這篇文章主要是回應 pchome 資訊人員在商業版上的回覆內容,因此 PCHome 是很明確的定義。再者,我任職於零售業的資訊部門,公司和 pchome 簽約,在其線上購物及商店街系統上賣商品,所以要透過「pchome 後台電子商務系統」(或更白話些說即後台管理系統) ,管理商品及訂單資訊。我談的是一個實際運作的系統。對於曾跟那些後台管理系統打過交道的人,PCHome提供哪些服務是很明確的事物。

    pchome 也不是我唯一 complain 的業者,東森也是,參見:
    http://blog.roodo.com/rocksaying/archives/2538021.html


    說到標準, SOAP, XML, JSON, HTTP, REST, ATOM 等,就是標準。SOA 訊息驅動的基礎,建立在這些訊息格式與傳送的標準之上。
    因為你必須去hack收到的HTML,把有用的資訊「抽」出來,轉換成你要的格式。
    由於 PCHome 後台電子商務系統不提供這些內容,因此我們「不得不」去hack html 。這種作法是不得已的,不能視為 SOA 的作法。
    就得開會跟其他小組的人協調,要求他們撰寫Interface文件,大家根據文件來寫程式。
    嚴格來說,這是 intranet 層級的作法。我公司和 pchome 是不同公司,不能小組協調。再者,你希望所有 web service 都能像 Google API 那樣,提供為各種開發工具所包裝好的 class ,然後在自己程式中 extends 後使用。亦即我上文的第二個程式碼部份所示。

    但現實中,如 pchome 這種規模的公司,不可能為你準備好 class 。所以,一個可查詢的 WSDL 或是明確的 publish 資訊反而更重要,如此我們才能把對方的 service 包裝成一個 class 。

    舉個例子,像現在的 digg, hemidemi, myshare.url.com.tw 等共享書籤服務,都會告訴你,只要在自己的網頁上加上像: xxx.com/bookmark/new?url=abc 這類 url ,或是 javascript code 就可以進行加入書籤的動作。這其實也是一種 SOA ,那些 url 就是這個 service 的 public method (RoR 就是這樣實作,或 CakePHP 這些 framework 也是) 。在現實中,對方的資訊系統只提供這類資訊的情形,比提供如同 Google API 這類完整 class 的情形更常見。
  • edited 一月 2007
    我看下來覺得這是個大麻煩,因為PCHome的開發人員不一定會去生出你要的東西,而用Hack網頁的HTML的方式,在PCHome改版時你們也要跟著改,這會是很大的麻煩。

    我個人覺得比較可行的方法是,雙方還是要談出一套標準,但模式改用「推」的方式來實做。

    請PCHome那邊更新資料時,也把同一份資料「推」給你們,你們提供一個標準以及寫好的程式模組給他們,請他們把這個模組放到他們的程式中。

    這樣對PCHome來說,可能會是不動到現有架構下比較快的方式。
  • edited 一月 2007
    光看一個 pch?me 的例子 ,你就覺得這會是個大問題,但實際情況更糟。

    實際情形是我一個人要面對5個不同的後台電子商務系統, pch?me 有2個,yah?? 也是2個,東x 1個。全部都要自己 hack html ,真的被搞的很煩。

    至於你說的作法在實務上也被認為不可行。例如一個 pch?me 就有上百個像我公司這樣的合作廠商。要每個廠商都把自己的模組推給 pch?me 放入,對雙方而言都是不可能的事,雙方都會感覺自己的資訊系統被 inject 、被暴露了。就像是一個 class 被迫將 private/protected 成員開放為 public 成員。在 OOP 中,當一項軟體功能被迫改成這麼做才能完成時 (解除成員保護權限或是將使用關係變成繼承關係) ,往往是因為這兩個 class 的 instance 之間沒有交換足夠而良好的訊息。

    因此在現實中,我們傾向先做到資料格式可用 XML/JSON 這類結構化文件進行交換。因為一份 xml 文件本身可自我描述,我即不需要去 hack ,也不需要 對方告訴我這份文件如何解讀。如此一來,雙方便可將彼此視為黑盒子。雙方的 service component 之間的關係維持在「使用關係」而非「繼承關係」。 對方不需要知道我在幹嘛,我也不需要知道對方在幹嘛,我們純粹透過資料交換進行協同作業,讓資料自己說話。
  • edited 一月 2007
    問題是客戶會不會理你...
    在台灣,廠商通常很弱勢,我想你會去hack HTML也是不得已的作法。
    人都是很自私的,誰要為了你把工作負擔加重?
    能談是最好,不能談就硬著頭皮接下,難不成要跟自己的荷包過不去?

    既然連談都不能談,別想要對方吐JSON/XML這些中介資料出來,這跟要求對方把資料推給你沒啥差別。

    我之所以說沒啥差別,是因為不管你用什麼資料交換技術,你還是得去針對特定廠商、服務去解析這些資料,轉成程式語言的資料結構再做進一步處理,即便用BizTalk之類的工具也不會輕鬆到哪裡去。

    既然如此,我個人就傾向讓客戶自己決定要吐什麼東西出來,當然啦,也必須確認這些資訊是否足夠讓我們處理,這就需要雙方協調。

    不談的話,就是賭只做這一次,否則會累死自己。

    我個人覺得這是台灣人的悲哀,想賺錢就得低頭...
  • edited 一月 2007
    唉,我們可以說 SOA 是個被炒作的名詞,但我想我們還是要承認 XML 這種結構化文件格式早在 6,7 年前就出現的東西,現在已經是很成熟的技術。然而現實上,許多線上資訊系統,作業方式還是「人工導向」的,我們依賴「人」作為許多線上資訊系統之間的「message bus」,由人把資料從a系統複製出來,再貼到b系統去。
    我個人就傾向讓客戶自己決定要吐什麼東西出來,當然啦,也必須確認這些資訊是否足夠讓我們處理,這就需要雙方協調。
    從資料的觀點來看,我的要求完全沒有超過他們現在所公開的資訊內容。他們現在吐給我們的資料確實足夠讓我們進行下一步作業,但那是指人工作業的情形,如果要用資訊系統自動接手處理,那麼資訊內容的「格式」,僅僅是格式,需要的是 xml 而不是 html 。

    再說到程式修改,以我的經驗,在 MVC 架構下要增加一種資料輸出格式,只要加一個 view 就 ok 了。我先前在一間資訊公司作入口網站的專案時,一開始只輸出 html 跟 json 兩種格式 (json 還是我個人為了方便用 ajax 設計前端介面而偷加的) 。然後客戶說要加 rss 格式,我不過花了3分鐘加了 view 就搞定。甚至XML式的做法是,後端一律輸出成 XML 格式,再依使用者需求調用不用的 XSLT 轉換為前端的呈現內容。

    如果對方的資訊架構是好的,那麼加一個 xml 格式其實對雙方有利。我們方便使用,他們也方便內部實踐 SOA 。如果對方的資訊架構就有問題,那麼這種需求自然就變成很大的軟體需求變更工作。
  • edited 一月 2007
    我個人可能是比較悲觀吧~
    有技術的人做的要死,沒技術的人出一張嘴,雙手一攤就沒事了~
  • edited 一月 2007
    我的看法是,這些困難所在,換個角度看,其實可以是另一種商機?!
  • edited 一月 2007
    補充一下,我以前負責入口網站 (主要是後台模組) 的例子。
    MVC 架構,每個模組都是一個 control 和 model 配上好幾個 view 。

    預設格式: XML格式
    http://www.kcg.gov.tw/modules/navigator/index.php/xml
    (可用於 ajax 或其他)

    html格式:
    http://www.kcg.gov.tw/modules/navigator/index.php/left/xhtml
    (可用於 php 在 server 調用,做為一個block直接嵌入在頁面中)

    JSON格式
    http://www.kcg.gov.tw/modules/navigator/index.php/json/top
    (可用於ajax)

    參數循序不重要。

    查詢...
    http://www.kcg.gov.tw/modules/navigator/index.php/help

    客戶沒要求查詢功能。但我每個模組都是這樣寫,每當我想查這個模組怎麼用時就加個help,不用翻 memo 。因為是加給自己看的,也就懶得做成 WSDL 。我不用說,你不用問,網址加個 help ,你就知道怎麼用。

    看了我的例子,我抱怨 pch?me 是很合理,也很正常的 XD
  • edited 一月 2007
    說實話,可用的技術跟標準越來越多,我也沒心力一個一個去實做。
    我比較在乎的是量產與自動化的部份,你說啥?客製化?我沒聽到...

    REST某個程度是好東西,不過有些動作需要依賴XMLHTTP去作這點就不太好了... 雖說如此我還是會用~

    JSON之前我講過了,雖然應該是假設沒人把Server攻破再去偷改網頁程式,不過我對JS直接eval這件事還是很感冒,我寧願收XML自己解碼...

    我自己的話只實做XML跟XHTML而已,算是很保守。

    至於你說的多個Views我個人倒是很贊同~
  • edited 一月 2007
    呃,關於 JSON 的安全性,你可能被某些不當用法誤導了。
    其實在 JSON 規範 (RFC4627) 第六節就有提到。調用 eval() 的方法不當時會有 inject 風險。安全喚起 JSON 的方法是,至少要用括號 '(',')' 括起 JSON 字串,例如:

    jsonString = '[], alert("HA HA HA!")';

    var i = eval('('+ jsonString + ')'); // Safe
    var j = eval(jsonString); //DANGER!

    而 RFC4627 的官方建議是:

    /*
    A JSON text can be safely passed into JavaScript's eval() function
    (which compiles and executes a string) if all the characters not
    enclosed in strings are in the set of characters that form JSON
    tokens. This can be quickly determined in JavaScript with two
    regular expressions and calls to the test and replace methods.
    */

    var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
    text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');
  • edited 一月 2007
    對!我說的就是這個!
    問題在於不是每個程式設計師都會注意到這個細節,所以除了自己寫出來的東西,沒有看到Source Code,我都持保留的態度。
Sign In or Register to comment.