PHPRPC 讓 SOA 從夢想變成現實
SOA 是一種程式設計思想，其實早在遠古時代（電腦史）它就已經出現了。無非就是把系統分解，將資料和商務邏輯部分盡量獨立出來，然後以服務形式提供給另外的系統共用。
那時也有一些可以實現 SOA 的工具，比如 DCOM、CORBA 等，不過前者僅限於 Windows，後者又太複雜，而且也僅對 C/C++、Delphi、Java 這等語言有較好支援，而且也都是商業開發軟體中才會包含，對於開源的指令碼類語言來說支援很差甚至沒有支援（因為太複雜了，不是什麼人都可以實現的了的，能夠把整個 CORBA 規範完整讀下來，都需要很好的耐心，還不一定都能夠完全理解）。之後互連網發展了，XML-RPC 出現了，XML-RPC 很簡單，但是也太過簡單（因為它只是一個 SOAP 的實驗原型而已），簡單的資料可以傳輸，複雜點的就沒辦法了，所以後來就發展成了 SOAP 這個名字簡單實際卻很複雜的怪物，儘管 SOAP 已經夠複雜了，但它也不過僅僅是定義了資料格式，於是後來就又有了一堆 WS-* 的補充。這樣就變得跟 CORBA 一樣了，不再是什麼人都能理解，什麼人都能實現了，或者說除了大公司和大組織有這個能力外，其他人基本上沒有這個能力介入。再之後人們突然想發現了寶一樣，發現了幾年前就被提出來的 REST，於是一堆號稱 REST 的服務又出現了，這東西看上去簡單，可是實際上卻是把資料轉換、傳輸等等問題全都扔給使用者來自行解決了。最後 REST 教父都把這些號稱 REST 的服務給否定了。除了這些以外，當然還有其它的方案，比如 Hessian、ICE、Adobe 的基於 AMF3 的通訊方案等等，這些不能不說是好的技術，但不是局限於某幾種語言，就是局限於某個特定的應用範圍。所以要搞 SOA 就需要在這些不同的協議和解決方案之間進行轉換，這就出來了 ESB，到這裡之後已經看上去很好很強大了。可是它真的可以解決問題嗎？真的不是在製造新問題嗎？當然它解決了一定的問題，可是同樣也製造了更多新問題。能夠在各種技術之間轉換固然很好，可是本來要掌握這些很複雜的技術中的一種就已經是一件很困難的事了，還要幾種都學，幾種都要用，這是多大的挑戰啊！還有一個問題就是這些協議中本來就有慢的要命的（比如基於 SOAP 的 Web Service），還要再加個轉換的過程，那還有什麼效率可言。所以，ESB 最後就變成了“哦，傻逼”！SOA 也就變成了聽上去很美，做起來很難的東西。
可是實際上我們回過頭來再想想，我們要 SOA 到底是想實現什嗎？不就是要將系統分解，然後異構重組嗎？最後問題就這麼簡單，我們需要的不一定是基於 SOAP 的 Web Service，不一定是將各種協議都能進行轉換的 ESB。我們需要的是一種能夠在異構系統間可以有效進行資料交換的技術，這樣我們就已經可以構建 SOA 的系統了。別的技術我不敢說，至少目前 PHPRPC 做到了這一點，你不但可以在 Java、.NET 這些語言之間方便的交換資料，還可以跟 PHP、Ruby、Python、Perl 這些開源指令碼語言中以同樣的方式交換資料，還可以用 Delphi/BCB 來做 Windows 介面的前台，也可以用 JavaScript 做 Web 前台，還可以用 Flash/Flex/RIA/WPF/SilverLight 這些來做內容更豐富的前台，而所有這些前台都可以共用同一個後台，還不需要關心後台究竟用什麼語言來實現。甚至手機上的 J2ME、.NET CF、Flash Lite 和手機瀏覽器的 JavaScript 都可以完美支援。有了 PHPRPC 之後，你就突然就有了這麼多選擇，甚至隨著 PHPRPC 的發展，你還會有更多更多的選擇，SOA 從現在開始就不再是遙不可及的夢了。
98 樓 kimmking 2009-03-05
mathgl 寫道
不知道對於複雜物件的 序列化如何
hessian 對於 在
class xx
{
IList xx;
}
裡面的 xxx 一律映射為hashmap..變成 IList 這點在有些語言上處理比較麻煩。不知道phprpc 能解決這個問題否。
偶的rpcfx對於List Collection一律序列化成Array，
然後加個實際類型的標籤~
不知道phprpc怎麼處理的~
99 樓 andot 2009-03-05
mathgl 寫道
不知道對於複雜物件的 序列化如何
hessian 對於 在
class xx
{
IList xx;
}
裡面的 xxx 一律映射為hashmap..變成 IList 這點在有些語言上處理比較麻煩。不知道phprpc 能解決這個問題否。
這個是 C# 的吧？C# 的泛型比 Java 的好，可以擷取到 xxx 的實際類型，所以在還原序列化時，完全按照你聲明的類型還原。
100 樓 mathgl 2009-03-05
andot 寫道
mathgl 寫道
不知道對於複雜物件的 序列化如何
hessian 對於 在
class xx
{
IList xx;
}
裡面的 xxx 一律映射為hashmap..變成 IList 這點在有些語言上處理比較麻煩。不知道phprpc 能解決這個問題否。
這個是 C# 的吧？C# 的泛型比 Java 的好，可以擷取到 xxx 的實際類型，所以在還原序列化時，完全按照你聲明的類型還原。
搞錯 是 List 我實驗過 hessian 哪怕 服務端和用戶端都是java 這種 list 還是會映射為list
不知道phprpc對這種有什麼改進。畢竟hashmap效能不好。
101 樓 chenjianjx 2009-03-05
樓主的第一段話說得很好，既簡明又生動
我對輕量級的遠程調用高度興趣。想問一下樓主，拋開效能問題，PHPRPC與XML-RPC和Hession/Burlap相比，在功能上主要有哪些優點？
102 樓 icewubin 2009-03-05
kimmking 寫道
mathgl 寫道
不知道對於複雜物件的 序列化如何
hessian 對於 在
class xx
{
IList xx;
}
裡面的 xxx 一律映射為hashmap..變成 IList 這點在有些語言上處理比較麻煩。不知道phprpc 能解決這個問題否。
偶的rpcfx對於List Collection一律序列化成Array，
然後加個實際類型的標籤~
不知道phprpc怎麼處理的~
因為Java是擦除式的泛型，所以運行時絕對擷取不到泛型的定義xxx類型。
但問題是，通過反射getClass方法不就能得到每個元素的Class類型了嗎？
103 樓 andot 2009-03-05
mathgl 寫道
andot 寫道
mathgl 寫道
不知道對於複雜物件的 序列化如何
hessian 對於 在
class xx
{
IList xx;
}
裡面的 xxx 一律映射為hashmap..變成 IList 這點在有些語言上處理比較麻煩。不知道phprpc 能解決這個問題否。
這個是 C# 的吧？C# 的泛型比 Java 的好，可以擷取到 xxx 的實際類型，所以在還原序列化時，完全按照你聲明的類型還原。
搞錯 是 List 我實驗過 hessian 哪怕 服務端和用戶端都是java 這種 list 還是會映射為list
不知道phprpc對這種有什麼改進。畢竟hashmap效能不好。
那看來是 Java 了，Java 的泛型就沒 C# 那麼好了（沒有運行期類型資訊）。因此只有 xxx 是自訂類時，才可以正確處理。其它的如果是容器，應該是 AssocArray，其它基本類型就別用這種泛型容器方式了，直接用數組才能正確轉型。
104 樓 mathgl 2009-03-05
icewubin 寫道
kimmking 寫道
mathgl 寫道
不知道對於複雜物件的 序列化如何
hessian 對於 在
class xx
{
IList xx;
}
裡面的 xxx 一律映射為hashmap..變成 IList 這點在有些語言上處理比較麻煩。不知道phprpc 能解決這個問題否。
偶的rpcfx對於List Collection一律序列化成Array，
然後加個實際類型的標籤~
不知道phprpc怎麼處理的~
因為Java是擦除式的泛型，所以運行時絕對擷取不到泛型的定義xxx類型。
但問題是，通過反射getClass方法不就能得到每個元素的Class類型了嗎？
hmmm.....上一個項目 用戶端用的 c++/cli。那邊顯示類型就是 hashtable。晚上試試phprpc效果如何。
105 樓 icewubin 2009-03-05
mathgl 寫道
icewubin 寫道
kimmking 寫道
mathgl 寫道
不知道對於複雜物件的 序列化如何
hessian 對於 在
class xx
{
IList xx;
}
裡面的 xxx 一律映射為hashmap..變成 IList 這點在有些語言上處理比較麻煩。不知道phprpc 能解決這個問題否。
偶的rpcfx對於List Collection一律序列化成Array，
然後加個實際類型的標籤~
不知道phprpc怎麼處理的~
因為Java是擦除式的泛型，所以運行時絕對擷取不到泛型的定義xxx類型。
但問題是，通過反射getClass方法不就能得到每個元素的Class類型了嗎？
hmmm.....上一個項目 用戶端用的 c++/cli。那邊顯示類型就是 hashtable。晚上試試phprpc效果如何。
我說的運行期，是指序列化程式（Java端）的運行期，不是rpc用戶端的運行期。
106 樓 raymond2006k 2009-03-09
樓主的分析很有道理。 由於和SOAP，WebService綁定的固有觀念和習慣用法，SOA，ESB等的確變得比較慢，實施效果很難令客戶滿意
應該在底層協議上，讓SOA擺脫束縛，真正回到 服務和服務整合 的思維上。
107 樓 yangyi 2009-05-06
raymond2006k 寫道
樓主的分析很有道理。 由於和SOAP，WebService綁定的固有觀念和習慣用法，SOA，ESB等的確變得比較慢，實施效果很難令客戶滿意
應該在底層協議上，讓SOA擺脫束縛，真正回到 服務和服務整合 的思維上。
SOA的三個問題這個架構一個都沒有解決：
1）怎麼非常快速的通過配置把一個Java,Spring,BPEL修改成這種協議？
2）怎麼把別人用JMS，WS寫好的服務用這種協議去訪問？
3）怎麼通過這個協議之上的架構把滿足相關通訊協定的組件形成一個流程
108 樓 rEloaD_cn 2009-05-07
yangyi 寫道
raymond2006k 寫道
樓主的分析很有道理。 由於和SOAP，WebService綁定的固有觀念和習慣用法，SOA，ESB等的確變得比較慢，實施效果很難令客戶滿意
應該在底層協議上，讓SOA擺脫束縛，真正回到 服務和服務整合 的思維上。
SOA的三個問題這個架構一個都沒有解決：
1）怎麼非常快速的通過配置把一個Java,Spring,BPEL修改成這種協議？
2）怎麼把別人用JMS，WS寫好的服務用這種協議去訪問？
3）怎麼通過這個協議之上的架構把滿足相關通訊協定的組件形成一個流程
我試著解答一下
1：寫代碼。phprpc就是做這個使的
2：還是寫代碼。既然phprpc可以支援多種語言，你就寫java代碼去掉jms唄，ws隨便你了，用什麼語言不行
3：依然是寫代碼。
1）定義一個類似workflow或者bepl的“流程服務”去封裝及這個組件（如果你用java寫的，我建議你使用jbpm；如果是多語言的，那你最好暴露出ws介面後用bpel封裝），然後在phprpc中寫代碼調這個“流程服務”就可以了。
2）直接用phprpc一個一個調，然後自己寫流程邏輯不就可以了嗎。
哈哈，瞎扯的，別當真
109 樓 lottons 2009-06-02
從頭到尾看完了這個文章，真長啊。不過收穫良多，瞭解了很多東西。我覺得PHPRPC還是很有發展前景的，雖然我還沒有試用過（爭取今晚試用一下）。什麼SOA不SOA的，理論這種東西，從來都是為了忽悠人而生的。就好比J2EE規範，這些東西。我的觀點一直都是只要是能夠解決實際問題的東西就是好東西，管他是什麼理論，什麼規範。不過話說回來，好東西也是需要理論支援的。但是現在這個商業的社會，理論已經變味了。IBM應該說是SOA理論的提出者，IBM也就是打著SOA的旗號在到處忽悠。
另外，我記得還看到有人把Tibico看作是訊息佇列，我不知道有沒有實際使用過Tibico，其實Tibico是一個中間融合劑。上面所謂的系統資料異構轉換，完全可以採用Tibico這樣的東西來做。Tibico是可以做資料轉換與映射的，我覺得在SOA這樣的“假、大、空”理論體系中最有用的部分應該就是Tibico這樣的東東（IBM也有好像是叫做Interface change server簡稱ICS）有了這個東西，一開始提出的a1系統的融合就沒有問題。比如如果a1使用的是ws，如果要融合，使用Tibico開發一個響應的適配器就可以很方便的進行融合，Tibico這樣的東西應該說是屏蔽了協議。
還有，樓主確實不必要將PHPRPC與SOA扯上關係，PHPRPC的目的是什嗎？我覺得不是為了SOA，PHPRPC有自己的特色有自己的應用情境。
還有一點，我覺得PHPRPC今後的發展應該逐漸轉移到使用的易用性，方便性，簡潔性上。效能我覺得已經足夠強大，不一定作為主要的目的。看看soap在一開始其目的就是面向易用的，使用xml的訊息，人人都能看得懂，都能用。
樓主還是需要考慮一下如何將服務的定義能夠統一描述，做到類似wsdl一樣的定義。畢竟要做服務整合這個還是很有必要的，且還是很有用處的。
說了一堆廢話，自己的見解不知道對不對，歡迎拍磚！
110 樓 yuzhongzhu110 2009-07-13
我是soa的初學者，謝謝樓主的介紹 下午學習看看
111 樓 whatwhat 2009-07-13
你這題目扯得有點大了
SOA已經成為了現實，
現在的問題是能不能讓這種現實更美好
PHPRPC 跨語言嗎？只是你在不斷支援更多語言
在我看來PHPRPC更像一個RPC架構
112 樓 icewubin 2009-07-23
yangyi 寫道
raymond2006k 寫道
樓主的分析很有道理。 由於和SOAP，WebService綁定的固有觀念和習慣用法，SOA，ESB等的確變得比較慢，實施效果很難令客戶滿意
應該在底層協議上，讓SOA擺脫束縛，真正回到 服務和服務整合 的思維上。
SOA的三個問題這個架構一個都沒有解決：
1）怎麼非常快速的通過配置把一個Java,Spring,BPEL修改成這種協議？
2）怎麼把別人用JMS，WS寫好的服務用這種協議去訪問？
3）怎麼通過這個協議之上的架構把滿足相關通訊協定的組件形成一個流程
JMS是非同步，和WS能放在一起說嗎？理念和應用情境差異很大的。
113 樓 GRDJE 2009-07-23
icewubin 寫道
yangyi 寫道
raymond2006k 寫道
樓主的分析很有道理。 由於和SOAP，WebService綁定的固有觀念和習慣用法，SOA，ESB等的確變得比較慢，實施效果很難令客戶滿意
應該在底層協議上，讓SOA擺脫束縛，真正回到 服務和服務整合 的思維上。
SOA的三個問題這個架構一個都沒有解決：
1）怎麼非常快速的通過配置把一個Java,Spring,BPEL修改成這種協議？
2）怎麼把別人用JMS，WS寫好的服務用這種協議去訪問？
3）怎麼通過這個協議之上的架構把滿足相關通訊協定的組件形成一個流程
JMS是非同步，和WS能放在一起說嗎？理念和應用情境差異很大的。
怎麼不能放在一起說....是你見識少而已， 沒見過什麼大的商業產品
譬如說sap的pi就支援這種情境
114 樓 icewubin 2009-07-24
GRDJE 寫道
icewubin 寫道
yangyi 寫道
raymond2006k 寫道
樓主的分析很有道理。 由於和SOAP，WebService綁定的固有觀念和習慣用法，SOA，ESB等的確變得比較慢，實施效果很難令客戶滿意
應該在底層協議上，讓SOA擺脫束縛，真正回到 服務和服務整合 的思維上。
SOA的三個問題這個架構一個都沒有解決：
1）怎麼非常快速的通過配置把一個Java,Spring,BPEL修改成這種協議？
2）怎麼把別人用JMS，WS寫好的服務用這種協議去訪問？
3）怎麼通過這個協議之上的架構把滿足相關通訊協定的組件形成一個流程
JMS是非同步，和WS能放在一起說嗎？理念和應用情境差異很大的。
怎麼不能放在一起說....是你見識少而已， 沒見過什麼大的商業產品
譬如說sap的pi就支援這種情境
請聯絡上下文看貼，不要雞同鴨講。
我的意思是:PHPRPC又不是非同步，和JMS有什麼好比的，是和SOAP(Web Service)比。
115 樓 yearbaw 2009-09-06
unsid 寫道
我當然瞭解通訊協議和語言無關,但是我在討論一個很現實的問題,如果整個系統都是由你或者你得小組完成,ok,沒問題,但是如果涉及了A1產品,那麼"通訊協議和語言無關"致使你只能自己去實現和A1的借口,但是A1又不是開放的,服務端需要瞭解很多A1地實現細節又是不可能的........
我現在就碰到類似困境.在樓主另一篇大作中,我也諮詢過.phprpc若能推廣,我們都受益,呵呵.
116 樓 thebye85 2009-11-02
andot 寫道
fansofjava 寫道
問一下，在JAVA下，如果伺服器返回一個對象List時，為什麼不能讀取LIST內的資料呢？
如：
List list = new ArrayList();list.add("dfsfsdf");list.add("ggwertewr");list.add("1234ggwertewr");user.setList(list);phprpc_server.add("getList", user);
當在用戶端取資料時，
List list = user.getList();
資料的確在list內，可通過list.size()知道list的大小，但在訪問list內字串資料時，總是報java.lang.ClassCastException: [B.........
請問一下這是什麼原因呢？
我個人認為，應該是用戶端根本就不知道服務端返回的list的資料是什麼類型（就算知道list服務端傳過來的是String List,強行轉型也會出錯），應該是直接以位元組數組的形式傳過來的，
那麼我要擷取list的字串，是不是要挨過的將每一個位元組數群組轉換成字串喲，如果真是這樣，那傳一個自訂對象list
豈不是非常的麻煩。
您的判斷非常的正確，確實字串是以 byte[] 形式返回的，在不能明確獲知字串類型的情況下，字串和字元數組都是以位元組數組的形式表示的。
Java 的泛型只是一個文法糖，所以它的泛型元素類型是無法通過反射來擷取的（這點與 .NET 泛型完全不同），因此，Java 的泛型元素類型如果設定為基本類型（包括String）和容器類型的話，則無法正確接收，只有自訂類型對象才可以用泛型容器來接受，因為自訂類型對象在序列化時是包含準確的類型資訊的。
不過向這種類型，你可以在用戶端通過聲明成 String[] 來接收，因為這樣就可以擷取到元素類型，並自動進行正確的轉換。否則，你就只能用非泛型介面（如List）或非泛型類（如ArrayList）接收了，接收之後，對於元素需要用 org.phprpc.util.Cast.cast 方法來進行類型轉換。
測試時我也遇到這個情況，作者能解決嗎？不然轉換很麻煩
117 樓 andot 2009-11-02
thebye85 寫道
andot 寫道
fansofjava 寫道
問一下，在JAVA下，如果伺服器返回一個對象List時，為什麼不能讀取LIST內的資料呢？
如：
List list = new ArrayList();list.add("dfsfsdf");list.add("ggwertewr");list.add("1234ggwertewr");user.setList(list);phprpc_server.add("getList", user);
當在用戶端取資料時，
List list = user.getList();
資料的確在list內，可通過list.size()知道list的大小，但在訪問list內字串資料時，總是報java.lang.ClassCastException: [B.........
請問一下這是什麼原因呢？
我個人認為，應該是用戶端根本就不知道服務端返回的list的資料是什麼類型（就算知道list服務端傳過來的是String List,強行轉型也會出錯），應該是直接以位元組數組的形式傳過來的，
那麼我要擷取list的字串，是不是要挨過的將每一個位元組數群組轉換成字串喲，如果真是這樣，那傳一個自訂對象list
豈不是非常的麻煩。
您的判斷非常的正確，確實字串是以 byte[] 形式返回的，在不能明確獲知字串類型的情況下，字串和字元數組都是以位元組數組的形式表示的。
Java 的泛型只是一個文法糖，所以它的泛型元素類型是無法通過反射來擷取的（這點與 .NET 泛型完全不同），因此，Java 的泛型元素類型如果設定為基本類型（包括String）和容器類型的話，則無法正確接收，只有自訂類型對象才可以用泛型容器來接受，因為自訂類型對象在序列化時是包含準確的類型資訊的。
不過向這種類型，你可以在用戶端通過聲明成 String[] 來接收，因為這樣就可以擷取到元素類型，並自動進行正確的轉換。否則，你就只能用非泛型介面（如List）或非泛型類（如ArrayList）接收了，接收之後，對於元素需要用 org.phprpc.util.Cast.cast 方法來進行類型轉換。
測試時我也遇到這個情況，作者能解決嗎？不然轉換很麻煩
這個問題產生的原因是PHPRPC所用的序列化格式不能區分二進位字串和Unicode字串，所以這個在PHPRPC裡是硬傷，沒辦法修改。不過好訊息是，我們的商業開源版軟體Hprose中，這個硬傷被解決啦，而且是徹底的解決，所有類型都不需要做類型轉化了（甚至連org.phprpc.util.Cast這樣的協助類都不存在了，因為完全不需要了）。Hprose在效能上還有大幅提升，效率是PHPRPC的10幾倍，在易用性上也有了更大的改善，如果您有興趣的話，可以測試一下。
