隨筆檔案(496)

 

Java代碼實(shí)現(xiàn)

/**
* 查找兩個串的最大公共子串
*
* @param s1
* @param s2
* @return
*/
public static String commonMaxSubString(String s1, String s2) {
?? String maxstr = "";
?? String substring = "";
?? if (s1.length() > s2.length()) { // s1為兩個串中的短串;s2為長串
??? String temp = s1;
??? s1 = s2;
??? s2 = temp;
?? }
?? int len = s1.length();
?? ok: for (int i = len; i > 0; i--) {
??? for (int j = 0; j < len - i + 1; j++) {
???? substring = s1.substring(j, j + i);
???? if (s2.indexOf(substring) != -1) {
????? maxstr = substring;
????? break ok; // 只要一找到最大子串,就退出這個for循環(huán)
???? }
??? }
?? }
?? return maxstr;
}

通常交換兩個整型變量，經(jīng)常會如下做：

public void swap(int a, int b) {
??? int t = a;// 使用第三個變量t

??? a = b;

??? b = t;
}

下面介紹兩種不借助變量，讓兩個整型變量交換的方法

方法一：借助代數(shù)運(yùn)算

public void swap(int a, int b) {
???? a = a + b;

???? b = a - b; // 這個時候a=a+b,b=a

???? a = a - b; // a = b
}

方法二：借助^異或運(yùn)算

public void swap(int a, int b) {
???? a = a^b;

???? b = a^b;

???? a = a^b;
}

OGNL中的#、%和$符號

#、%和$符號在OGNL表達(dá)式中經(jīng)常出現(xiàn)，而這三種符號也是開發(fā)者不容易掌握和理解的部分。在這里筆者簡單介紹它們的相應(yīng)用途。

1．#符號

#符號的用途一般有三種。
>>>
訪問非根對象屬性，例如示例中的#session.msg表達(dá)式，由于Struts 2中值棧被視為根對象，所以訪問其他非根對象時，需要加#前綴。實(shí)際上，#相當(dāng)于ActionContext. getContext()；#session.msg表達(dá)式相當(dāng)于ActionContext.getContext().getSession(). getAttribute("msg")。
>>>
用于過濾和投影（projecting）集合，如示例中的persons.{?#this.age>20}。
>>>
用來構(gòu)造Map，例如示例中的#{'foo1':'bar1', 'foo2':'bar2'}。

2．%符號

%符號的用途是在標(biāo)志的屬性為字符串類型時，計(jì)算OGNL表達(dá)式的值。如下面的代碼所示：

The value of key "foo1" is 

不使用％：

使用％：

運(yùn)行界面如圖8.4所示。

3．$符號

$符號主要有兩個方面的用途。
>>>
在國際化資源文件中，引用OGNL表達(dá)式，例如國際化資源文件中的代碼：reg.agerange=國際化資源信息：年齡必須在${min}同${max}之間。
>>>
在Struts 2框架的配置文件中引用OGNL表達(dá)式，例如下面的代碼片斷所示：

 

10

100

BAction-test校驗(yàn)：數(shù)字必須為${min}為${max}之間！
  

<?xml:namespace prefix = st1 />1.1.1 業(yè)務(wù)控制器

為本示例建立一個業(yè)務(wù)控制器，該控制器用到了代碼8.1中定義的Person人員信息類。該業(yè)務(wù)控制器如代碼8.4所示。

代碼8.4 Struts 2的OGNL示例業(yè)務(wù)控制器

該業(yè)務(wù)控制器分別在application、session和request中存入名為“msg”的字符串信息，另外定義了一個List類型屬性，同時添加了兩個Person類型元素。在配置文件中增加了相應(yīng)的配置，代碼如下：

1.1.2 JSP視圖

showognl.jsp是使用了OGNL表達(dá)式的JSP視圖，視圖用來顯示Action中處理的各種信息，讀者可以看到，使用OGNL表達(dá)式，代碼更加簡潔和直觀，如代碼8.5所示。

代碼8.5使用OGNL表達(dá)式的JSP視圖

http://www.w3.org/TR/ xhtml1/DTD/xhtml1-transitional.dtd">

http://www.w3.org/1999/xhtml">

parameters: 

request.msg: 

session.msg: 

application.msg: 

attr.msg: 

用于過濾和投影(projecting)集合

年齡大于20

1.???????????????????????   - 年齡：

姓名為pla1的年齡: 

構(gòu)造Map

The value of key "foo1" is 

1.1.3 運(yùn)行示例

在瀏覽器中輸入http://localhost:8080/bookcode/ch8/OgnlAction.action?msg=hello，運(yùn)行結(jié)果如圖8.3所示。

★說明★

本示例演示了如何使用OGNL表達(dá)式來訪問OGNL上下文和值棧，同時演示了如何使用OGNL表達(dá)式進(jìn)行集合操作。對讀者深入理解Struts 2中OGNL表達(dá)式的使用有所幫助。

OGNL的集合操作

如果需要一個集合元素的時候（例如List對象或者Map對象），可以使用OGNL中同集合相關(guān)的表達(dá)式。

可以使用如下代碼直接生成一個List對象：

該OGNL表達(dá)式中，直接生成了一個List對象，該List對象中包含3個元素：e1、e2和e3。如果需要更多的元素，可以按照這樣的格式定義多個元素，多個元素之間使用逗號隔開。

如下代碼可以直接生成一個Map對象：

Map類型的集合對象，使用key-value格式定義，每個key-value元素使用冒號標(biāo)識，多個元素之間使用逗號隔開。

對于集合類型，OGNL表達(dá)式可以使用in和not in兩個元素符號。其中，in表達(dá)式用來判斷某個元素是否在指定的集合對象中；not in判斷某個元素是否不在指定的集合對象中，如代碼8.3所示。

代碼8.3使用OGNL集合操作符

除了in和not in之外，OGNL還允許使用某個規(guī)則獲得集合對象的子集，常用的有以下3個相關(guān)操作符。
>>>
?：獲得所有符合邏輯的元素。
>>>
^：獲得符合邏輯的第一個元素。
>>>
$：獲得符合邏輯的最后一個元素。

例如代碼：

該代碼可以獲得person的所有性別為male的relatievs集合。

★注意★

使用索引，并不是直接獲得指定的元素，而是從指定的索引位置搜索。

Struts 2中的OGNL Context是ActionContext，如圖8.2所示。

★說明★

圖8.2只是說明Struts 2的OGNL Context結(jié)構(gòu)，實(shí)際上Context還包含其他對象。

由于值棧是Struts 2中OGNL的根對象，如果用戶需要訪問值棧中的對象，則可以直接通過下面的代碼訪問值棧中的屬性：

如果訪問其他Context中的對象，由于不是根對象，在訪問時，需要加#前綴。
>>
application對象：用于訪問ServletContext，例如#application.userName或者#application['userName']，相當(dāng)于調(diào)用Servlet的getAttribute("username")。
>>
session對象：用來訪問HttpSession，例如#session.userName或者#session['userName']，相當(dāng)于調(diào)用session.getAttribute("userName")。
>>
request對象：用來訪問HttpServletRequest屬性（attribute）的Map，例如#request.userName或者#request['userName']，相當(dāng)于調(diào)用request.getAttribute ("userName")。
>>
parameters對象：用于訪問HTTP的請求參數(shù)，例如#parameters.userName或者#parameters['userName']，相當(dāng)于調(diào)用request.getParameter("username")。
>>
attr對象：用于按page-request-session-application順序訪問其屬性。

OGNL是Struts 2框架的默認(rèn)表達(dá)式語言，增強(qiáng)了Struts 2的數(shù)據(jù)訪問能力，同時簡化了代碼。

Struts 2的OGNL表達(dá)式

標(biāo)準(zhǔn)的OGNL會設(shè)定一個根對象（root對象）。假設(shè)使用標(biāo)準(zhǔn)OGNL表達(dá)式來求值（不使用Struts 2的OGNL表達(dá)式），如果OGNL上下文（OgnlContext Map類型）有兩個對象：foo對象，在OgnlContext中名稱為foo；bar對象，在OgnlContext中名稱為bar。同時foo對象被設(shè)置為根對象（root）。則利用下面的OGNL表達(dá)式求值：

★說明★

使用OGNL是非常簡單的，如果要訪問的對象不是根對象，如示例中的bar對象，則需要使用命名空間，用“#”來標(biāo)識，如“#bar”；如果訪問一個根對象，則不用指定命名空間，可以直接訪問根對象的屬性。

在Struts 2框架中，值棧（Value Stack）就是OGNL的根對象，假設(shè)值棧中存在兩個對對象實(shí)例：Man和Animal，這兩個對象實(shí)例都有一個name屬性，Animal有一個species屬性，Man有一個salary屬性，假設(shè)Animal在值棧的頂部，Man在Animal后面，下面的代碼片斷會幫助讀者更好地理解OGNL表達(dá)式：

最后一行示例代碼，返回的是animal.getName()返回值，即返回了Animal的name屬性，因?yàn)?/span>Animal是值棧的頂部元素，OGNL將從頂部元素搜索，所以會返回Animal的name屬性值。如果要獲得Man的name值，則需要如下代碼：

Struts 2允許在值棧中使用索引，示例代碼如下所示：

??? XFire、Axis

??? XFire、Axis是Webservice的實(shí)現(xiàn)框架，WebService可算是一個完整的SOA架構(gòu)實(shí)現(xiàn)標(biāo)準(zhǔn)了，因此采用XFire、Axis這些也就意味著是采用webservice方式了。

　　1、是基于什么協(xié)議實(shí)現(xiàn)的？

　　基于SOAP協(xié)議。

　　2、怎么發(fā)起請求？

　　獲取到遠(yuǎn)端service的proxy后直接調(diào)用。

　　3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

　　將請求信息轉(zhuǎn)化為遵循SOAP協(xié)議的XML格式，由框架轉(zhuǎn)化為流進(jìn)行傳輸。

　　4、使用什么傳輸協(xié)議傳輸？

　　Http協(xié)議。

　　5、響應(yīng)端基于什么機(jī)制來接收請求？

　　監(jiān)聽Http請求。

　　6、怎么將流還原為傳輸格式的？

　　根據(jù)SOAP協(xié)議進(jìn)行還原。

　　7、處理完畢后怎么回應(yīng)？

　　返回結(jié)果寫入XML中，由框架返回至調(diào)用端。

　　------------------------------------------------------------------------------------------------------------------------------

　　ActiveMQ

　　ActiveMQ是JMS的實(shí)現(xiàn)，基于JMS這類消息機(jī)制實(shí)現(xiàn)遠(yuǎn)程通訊是一種不錯的選擇，畢竟消息機(jī)制本身的功能使得基于它可以很容易的去實(shí)現(xiàn)同步/異步/單向調(diào)用等，而且消息機(jī)制從容錯角度上來說也是個不錯的選擇，這是Erlang能夠做到容錯的重要基礎(chǔ)。

　　1、是基于什么協(xié)議實(shí)現(xiàn)的？

　　基于JMS協(xié)議。

　　2、怎么發(fā)起請求？

　　遵循JMS API發(fā)起請求。

　　3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

　　不太清楚，猜想應(yīng)該是二進(jìn)制流。

　　4、使用什么傳輸協(xié)議傳輸？

　　支持多種傳輸協(xié)議，例如tcp/ip、udp、http等等。

　　5、響應(yīng)端基于什么機(jī)制來接收請求？

　　監(jiān)聽符合協(xié)議的端口。

　　6、怎么將流還原為傳輸格式的？

　　同問題3。

　　7、處理完畢后怎么回應(yīng)？

　　遵循JMS API生成消息，并寫入JMS Queue中。

　　基于JMS此類機(jī)制實(shí)現(xiàn)遠(yuǎn)程通訊的例子有Spring-Intergration、Mule、Lingo等等。

　-----------------------------------------------------------------------------------------------------------------------------

??? Mina

??? Mina是Apache提供的通訊框架，在之前一直沒有提到網(wǎng)絡(luò)IO這塊，之前提及的框架或library基本都是基于BIO的，而Mina是采用NIO的，NIO在并發(fā)量增長時對比BIO而言會有明顯的性能提升，而java性能的提升，與其NIO這塊與OS的緊密結(jié)合是有不小的關(guān)系的。

??? 1、是基于什么協(xié)議實(shí)現(xiàn)的？

??? 可選的傳輸協(xié)議+NIO.

??? 2、怎么發(fā)起請求？

??? 通過Mina提供的Client API.

??? 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

??? Mina遵循java串行化機(jī)制對請求對象進(jìn)行序列化。

??? 4、使用什么傳輸協(xié)議傳輸？

??? 支持多種傳輸協(xié)議，例如tcp/ip、http等等。

??? 5、響應(yīng)端基于什么機(jī)制來接收請求？

??? 以NIO的方式監(jiān)聽協(xié)議端口。

??? 6、怎么將流還原為傳輸格式的？

??? 遵循java串行化機(jī)制對請求對象進(jìn)行反序列化。

??? 7、處理完畢后怎么回應(yīng)？

??? 遵循Mina API進(jìn)行返回。

??? MINA是NIO方式的，因此支持異步調(diào)用是毫無懸念的。

　--------------------------------------------------------------------------------------------------------------------------------

??? EJB

??? EJB最突出的在于其分布式，EJB采用的是ORMI協(xié)議，和RMI協(xié)議是差不多的，但EJB在分布式通訊的安全控制、transport pool、smart proxy等方面的突出使得其在分布式領(lǐng)域是不可忽視的力量。

??? 1、是基于什么協(xié)議實(shí)現(xiàn)的？

??? 基于ORMI協(xié)議。

??? 2、怎么發(fā)起請求？

??? EJB調(diào)用。

??? 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

??? 遵循java串行化機(jī)制對請求對象進(jìn)行序列化。

??? 4、使用什么傳輸協(xié)議傳輸？

??? tcp/ip.

??? 5、響應(yīng)端基于什么機(jī)制來接收請求？

??? 監(jiān)聽協(xié)議端口。

??? 6、怎么將流還原為傳輸格式的？

??? 遵循java串行化機(jī)制對請求對象進(jìn)行反序列化。

??? 7、處理完畢后怎么回應(yīng)？

??? 直接返回處理對象即可。

??? 在之前的分布式服務(wù)框架系列的文章中對于jndi有誤導(dǎo)的嫌疑，在這篇blog中也順帶的提下jndi的機(jī)制，由于JNDI取決于具體的實(shí)現(xiàn)，在這里只能是講解下jboss的jndi的實(shí)現(xiàn)了。

??? 在將對象實(shí)例綁定到j(luò)boss jnp server后，當(dāng)遠(yuǎn)程端采用context.lookup（）方式獲取遠(yuǎn)程對象實(shí)例并開始調(diào)用時，jboss jndi的實(shí)現(xiàn)方法是從jnp server上獲取對象實(shí)例，將其序列化回本地，然后在本地進(jìn)行反序列化，之后在本地進(jìn)行類調(diào)用。

??? 通過這個機(jī)制，就可以知道了，本地其實(shí)是必須有綁定到j(luò)boss上的對象實(shí)例的class的，否則反序列化的時候肯定就失敗了，而遠(yuǎn)程通訊需要做到的是在遠(yuǎn)程執(zhí)行某動作，并獲取到相應(yīng)的結(jié)果，可見純粹基于JNDI是無法實(shí)現(xiàn)遠(yuǎn)程通訊的。

??? 但JNDI也是實(shí)現(xiàn)分布式服務(wù)框架一個很關(guān)鍵的技術(shù)點(diǎn)，因?yàn)榭梢酝ㄟ^它來實(shí)現(xiàn)透明化的遠(yuǎn)端和本地調(diào)用，就像ejb，另外它也是個很好的隱藏實(shí)際部署機(jī)制（就像datasource）等的方案。

??? 總結(jié)

??? 由上一系列的分析可知，在遠(yuǎn)程通訊領(lǐng)域中，涉及的知識點(diǎn)還是相當(dāng)?shù)亩嗟模缬校和ㄐ艆f(xié)議或遠(yuǎn)程調(diào)用協(xié)議（tcp/http/udp/rmi/xml-rpc etc.）、消息機(jī)制、網(wǎng)絡(luò)IO（BIO/NIO/AIO）、MultiThread、本地調(diào)用與遠(yuǎn)程調(diào)用的透明化方案（涉及java classloader、Dynamic Proxy、Unit Test etc.）、異步與同步調(diào)用、網(wǎng)絡(luò)通信處理機(jī)制（自動重連、廣播、異常、池處理等等）、Java Serialization （各種協(xié)議的私有序列化機(jī)制等）、各種框架的實(shí)現(xiàn)原理（傳輸格式、如何將傳輸格式轉(zhuǎn)化為流的、如何將請求信息轉(zhuǎn)化為傳輸格式的、如何接收流的、如何將流還原為傳輸格式的等等），要精通其中的哪些東西，得根據(jù)實(shí)際需求來決定了，只有在了解了原理的情況下才能很容易的做出選擇，甚至可以根據(jù)需求做私有的遠(yuǎn)程通訊協(xié)議，對于從事分布式服務(wù)平臺或開發(fā)較大型的分布式應(yīng)用的人而言，我覺得至少上面提及的知識點(diǎn)是需要比較了解的。

??? 可選實(shí)現(xiàn)技術(shù)

??? 當(dāng)然，在上面的原理中并沒有介紹到所有的java領(lǐng)域可選的遠(yuǎn)程通信協(xié)議了，例如還有EJB采用的ORMI、Spring自己定義的一個簡單的Http Invoker等等。

??? 看完原理后我們再來看看目前java領(lǐng)域可用于實(shí)現(xiàn)遠(yuǎn)程通訊的框架或library，知名的有：JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire（Axis）、ActiveMQ、Mina、Mule、EJB3等等，來對每種做個簡單的介紹和評價，其實(shí)呢，要做分布式服務(wù)框架，這些東西都是要有非常深刻的了解的，因?yàn)榉植际椒?wù)框架其實(shí)是包含了解決分布式領(lǐng)域以及應(yīng)用層面領(lǐng)域兩方面問題的。

??? 當(dāng)然，你也可以自己根據(jù)遠(yuǎn)程網(wǎng)絡(luò)通信原理（transport protocol+Net IO）去實(shí)現(xiàn)自己的通訊框架或library.

??? 那么在了解這些遠(yuǎn)程通訊的框架或library時，會帶著什么問題去學(xué)習(xí)呢？

??? 1、是基于什么協(xié)議實(shí)現(xiàn)的？

??? 2、怎么發(fā)起請求？

??? 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

??? 4、使用什么傳輸協(xié)議傳輸？

??? 5、響應(yīng)端基于什么機(jī)制來接收請求？

??? 6、怎么將流還原為傳輸格式的？

??? 7、處理完畢后怎么回應(yīng)？

??? JBoss-Remoting

??? Jboss-remoting是由jboss編寫的一個java領(lǐng)域的遠(yuǎn)程通訊框架，基于此框架，可以很簡單的實(shí)現(xiàn)基于多種傳輸協(xié)議的java對象的RPC.

??? 直接來回答問題：

??? 1、是基于什么協(xié)議實(shí)現(xiàn)的？

??? JBoss-Remoting是個通訊框架，因此它支持多種協(xié)議方式的通信，例如tcp/ip+io方式、rmi方式、http+io方式等。

??? 2、怎么發(fā)起請求？

??? 在JBoss-Remoting中，只需將需要發(fā)起的請求參數(shù)對象傳入jboss-remoting的InvocationRequest對象即可，也可根據(jù)協(xié)議基于InvocationRequest封裝符合需求的InvocationRequest對象。

??? 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

??? JBoss-Remoting基于Java串行化機(jī)制或JBoss自己的串行化實(shí)現(xiàn)來將請求轉(zhuǎn)化為對象字節(jié)流。

??? 4、使用什么傳輸協(xié)議傳輸？

??? 支持多種傳輸協(xié)議，例如tcp/ip、http等。

??? 5、響應(yīng)端基于什么機(jī)制來接收請求？

??? 響應(yīng)端只需將自己的處理對象注冊到JBoss-Remoting提供的server端的Connector對象中即可。

??? 6、怎么將流還原為傳輸格式的？

??? JBoss-Remoting基于java串行化機(jī)制或jboss自己的串行化實(shí)現(xiàn)來將請求信息還原為java對象。

??? 7、處理完畢后怎么回應(yīng)？

??? 處理完畢后將結(jié)果對象直接返回即可，jboss-remoting會將此對象按照協(xié)議進(jìn)行序列化，返回至調(diào)用端。

??? 另外，jboss-remoting支持多種通信方式，例如同步/異步/單向通信等。

　---------------------------------------------------------------------------------------------------------------------------

??? Spring-Remoting

??? Spring-remoting是Spring提供java領(lǐng)域的遠(yuǎn)程通訊框架，基于此框架，同樣也可以很簡單的將普通的spring bean以某種遠(yuǎn)程協(xié)議的方式來發(fā)布，同樣也可以配置spring bean為遠(yuǎn)程調(diào)用的bean.

　　1、是基于什么協(xié)議實(shí)現(xiàn)的？

　　和JBoss-Remoting一樣，作為一個遠(yuǎn)程通訊的框架，Spring通過集成多種遠(yuǎn)程通訊的library，從而實(shí)現(xiàn)了對多種協(xié)議的支持，例如rmi、http+io、xml-rpc、binary-rpc等。

　　2、怎么發(fā)起請求？

　　在Spring中，由于其對于遠(yuǎn)程調(diào)用的bean采用的是proxy實(shí)現(xiàn)，發(fā)起請求完全是通過服務(wù)接口調(diào)用的方式。

　　3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

　　Spring按照協(xié)議方式將請求的對象信息轉(zhuǎn)化為流，例如Spring Http Invoker是基于Spring自己定義的一個協(xié)議來實(shí)現(xiàn)的，傳輸協(xié)議上采用的為http，請求信息是基于java串行化機(jī)制轉(zhuǎn)化為流進(jìn)行傳輸。

　　4、使用什么傳輸協(xié)議傳輸？

　　支持多種傳輸協(xié)議，例如rmi、http等等。

　　5、響應(yīng)端基于什么機(jī)制來接收請求？

　　響應(yīng)端遵循協(xié)議方式來接收請求，對于使用者而言，則只需通過spring的配置方式將普通的spring bean配置為響應(yīng)端或者說提供服務(wù)端。

　　6、怎么將流還原為傳輸格式的？

　　按照協(xié)議方式來進(jìn)行還原。

　　7、處理完畢后怎么回應(yīng)？

　　處理完畢后直接返回即可，spring-remoting將根據(jù)協(xié)議方式來做相應(yīng)的序列化。

　　-----------------------------------------------------------------------------------------------------------------------------

　　Hessian

　　Hessian是由caucho提供的一個基于binary-RPC實(shí)現(xiàn)的遠(yuǎn)程通訊library。

　　1、是基于什么協(xié)議實(shí)現(xiàn)的？

　　基于Binary-RPC協(xié)議實(shí)現(xiàn)。

　　2、怎么發(fā)起請求？

　　需通過Hessian本身提供的API來發(fā)起請求。

　　3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

　　Hessian通過其自定義的串行化機(jī)制將請求信息進(jìn)行序列化，產(chǎn)生二進(jìn)制流。

??? Hessian基于Http協(xié)議進(jìn)行傳輸。

??? 5、響應(yīng)端基于什么機(jī)制來接收請求？

??? 響應(yīng)端根據(jù)Hessian提供的API來接收請求。

??? 6、怎么將流還原為傳輸格式的？

??? Hessian根據(jù)其私有的串行化機(jī)制來將請求信息進(jìn)行反序列化，傳遞給使用者時已是相應(yīng)的請求信息對象了。

??? 7、處理完畢后怎么回應(yīng)？

??? 處理完畢后直接返回，hessian將結(jié)果對象進(jìn)行序列化，傳輸至調(diào)用端。

　-------------------------------------------------------------------------------------------------------------------------------

??? Burlap

??? Burlap也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC協(xié)議的。

??? 1、是基于什么協(xié)議實(shí)現(xiàn)的？

??? 基于XML-RPC協(xié)議實(shí)現(xiàn)。

??? 2、怎么發(fā)起請求？

??? 根據(jù)Burlap提供的API.

??? 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？

??? 將請求信息轉(zhuǎn)化為符合協(xié)議的XML格式，轉(zhuǎn)化為流進(jìn)行傳輸。

??? 4、使用什么傳輸協(xié)議傳輸？

??? Http協(xié)議。

??? 5、響應(yīng)端基于什么機(jī)制來接收請求？

??? 監(jiān)聽Http請求。

??? 6、怎么將流還原為傳輸格式的？

??? 根據(jù)XML-RPC協(xié)議進(jìn)行還原。

??? 7、處理完畢后怎么回應(yīng)？

??? 返回結(jié)果寫入XML中，由Burlap返回至調(diào)用端。

　-----------------------------------------------------------------------------------------------------------------------------

　　在分布式服務(wù)框架中，一個最基礎(chǔ)的問題就是遠(yuǎn)程服務(wù)是怎么通訊的，在Java領(lǐng)域中有很多可實(shí)現(xiàn)遠(yuǎn)程通訊的技術(shù)，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS 等，這些名詞之間到底是些什么關(guān)系呢，它們背后到底是基于什么原理實(shí)現(xiàn)的呢，了解這些是實(shí)現(xiàn)分布式服務(wù)框架的基礎(chǔ)知識，而如果在性能上有高的要求的話，那深入了解這些技術(shù)背后的機(jī)制就是必須的了，在這篇blog中我們將來一探究竟，拋磚引玉，歡迎大家提供更多的實(shí)現(xiàn)遠(yuǎn)程通訊的技術(shù)和原理的介紹。

　　基本原理

　　要實(shí)現(xiàn)網(wǎng)絡(luò)機(jī)器間的通訊，首先得來看看計(jì)算機(jī)系統(tǒng)網(wǎng)絡(luò)通信的基本原理，在底層層面去看，網(wǎng)絡(luò)通信需要做的就是將流從一臺計(jì)算機(jī)傳輸?shù)搅硗庖慌_計(jì)算機(jī)，基于傳輸協(xié)議和網(wǎng)絡(luò)IO來實(shí)現(xiàn)，其中傳輸協(xié)議比較出名的有 http、tcp、udp等等，http、tcp、udp都是在基于Socket概念上為某類應(yīng)用場景而擴(kuò)展出的傳輸協(xié)議，網(wǎng)絡(luò)IO，主要有bio、 nio、aio三種方式，所有的分布式應(yīng)用通訊都基于這個原理而實(shí)現(xiàn)，只是為了應(yīng)用的易用，各種語言通常都會提供一些更為貼近應(yīng)用易用的應(yīng)用層協(xié)議。

　　應(yīng)用級協(xié)議

　　遠(yuǎn)程服務(wù)通訊，需要達(dá)到的目標(biāo)是在一臺計(jì)算機(jī)發(fā)起請求，另外一臺機(jī)器在接收到請求后進(jìn)行相應(yīng)的處理并將結(jié)果返回給請求端，這其中又會有諸如one way request、同步請求、異步請求等等請求方式，按照網(wǎng)絡(luò)通信原理，需要實(shí)現(xiàn)這個需要做的就是將請求轉(zhuǎn)換成流，通過傳輸協(xié)議傳輸至遠(yuǎn)端，遠(yuǎn)端計(jì)算機(jī)在接收到請求的流后進(jìn)行處理，處理完畢后將結(jié)果轉(zhuǎn)化為流，并通過傳輸協(xié)議返回給調(diào)用端。

　　原理是這樣的，但為了應(yīng)用的方便，業(yè)界推出了很多基于此原理之上的應(yīng)用級的協(xié)議，使得大家可以不用去直接操作這么底層的東西，通常應(yīng)用級的遠(yuǎn)程通信協(xié)議會提供：

　　1. 為了避免直接做流操作這么麻煩，提供一種更加易用或貼合語言的標(biāo)準(zhǔn)傳輸格式;

　　2. 網(wǎng)絡(luò)通信機(jī)制的實(shí)現(xiàn)，就是替你完成了將傳輸格式轉(zhuǎn)化為流，通過某種傳輸協(xié)議傳輸至遠(yuǎn)端計(jì)算機(jī)，遠(yuǎn)端計(jì)算機(jī)在接收到流后轉(zhuǎn)化為傳輸格式，并進(jìn)行存儲或以某種方式通知遠(yuǎn)端計(jì)算機(jī)。

　　所以在學(xué)習(xí)應(yīng)用級的遠(yuǎn)程通信協(xié)議時，我們可以帶著這幾個問題進(jìn)行學(xué)習(xí)：

　　1. 傳輸?shù)臉?biāo)準(zhǔn)格式是什么?

　　2. 怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧?

　　3. 怎么接收和處理流?

　　4. 傳輸協(xié)議是?

　　不過應(yīng)用級的遠(yuǎn)程通信協(xié)議并不會在傳輸協(xié)議上做什么多大的改進(jìn)，主要是在流操作方面，讓應(yīng)用層生成流和處理流的這個過程更加的貼合所使用的語言或標(biāo)準(zhǔn)，至于傳輸協(xié)議則通常都是可選的，在java領(lǐng)域中知名的有：RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS，來具體的看看這些遠(yuǎn)程通信的應(yīng)用級協(xié)議：

　　RMI

　　RMI是個典型的為java定制的遠(yuǎn)程通信協(xié)議，我們都知道，在single vm中，我們可以通過直接調(diào)用java object instance來實(shí)現(xiàn)通信，那么在遠(yuǎn)程通信時，如果也能按照這種方式當(dāng)然是最好了，這種遠(yuǎn)程通信的機(jī)制成為RPC(Remote Procedure Call)，RMI正是朝著這個目標(biāo)而誕生的。

　　來看下基于RMI的一次完整的遠(yuǎn)程通信過程的原理：

　　1. 客戶端發(fā)起請求，請求轉(zhuǎn)交至RMI客戶端的stub類;

　　2. stub類將請求的接口、方法、參數(shù)等信息進(jìn)行序列化;

　　3. 基于socket將序列化后的流傳輸至服務(wù)器端;

　　4. 服務(wù)器端接收到流后轉(zhuǎn)發(fā)至相應(yīng)的skelton類;

　　5. skelton類將請求的信息反序列化后調(diào)用實(shí)際的處理類;

　　6. 處理類處理完畢后將結(jié)果返回給skelton類;

　　7. Skelton類將結(jié)果序列化，通過socket將流傳送給客戶端的stub;

　　8. stub在接收到流后反序列化，將反序列化后的Java Object返回給調(diào)用者。

　　來看jboss-remoting對于此過程的一個更好的圖示：

　　根據(jù)原理來回答下之前學(xué)習(xí)應(yīng)用級協(xié)議帶著的幾個問題：

　　1. 傳輸?shù)臉?biāo)準(zhǔn)格式是什么?

　　是Java ObjectStream。

　　2. 怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧?

　　基于Java串行化機(jī)制將請求的java object信息轉(zhuǎn)化為流。

　　3. 怎么接收和處理流?

　　根據(jù)采用的協(xié)議啟動相應(yīng)的監(jiān)聽端口，當(dāng)有流進(jìn)入后基于Java串行化機(jī)制將流進(jìn)行反序列化，并根據(jù)RMI協(xié)議獲取到相應(yīng)的處理對象信息，進(jìn)行調(diào)用并處理，處理完畢后的結(jié)果同樣基于java串行化機(jī)制進(jìn)行返回。

　　4. 傳輸協(xié)議是?

　　Socket。

　　XML-RPC

　　XML-RPC也是一種和RMI類似的遠(yuǎn)程調(diào)用的協(xié)議，它和RMI的不同之處在于它以標(biāo)準(zhǔn)的xml格式來定義請求的信息(請求的對象、方法、參數(shù)等)，這樣的好處是什么呢，就是在跨語言通訊的時候也可以使用。

　　來看下XML-RPC協(xié)議的一次遠(yuǎn)程通信過程：

　　1. 客戶端發(fā)起請求，按照XML-RPC協(xié)議將請求信息進(jìn)行填充;

　　2. 填充完畢后將xml轉(zhuǎn)化為流，通過傳輸協(xié)議進(jìn)行傳輸;

　　3. 接收到在接收到流后轉(zhuǎn)換為xml，按照XML-RPC協(xié)議獲取請求的信息并進(jìn)行處理;

　　4. 處理完畢后將結(jié)果按照XML-RPC協(xié)議寫入xml中并返回。

　　圖示以上過程：

　　同樣來回答問題：

　　1. 傳輸?shù)臉?biāo)準(zhǔn)格式是?

　　標(biāo)準(zhǔn)格式的XML。

　　2. 怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧?

　　將XML轉(zhuǎn)化為流。

　　3. 怎么接收和處理流?

　　通過監(jiān)聽的端口獲取到請求的流，轉(zhuǎn)化為XML，并根據(jù)協(xié)議獲取請求的信息，進(jìn)行處理并將結(jié)果寫入XML中返回。

　　4. 傳輸協(xié)議是?

　　Http。

　　Binary-RPC

　　Binary-RPC看名字就知道和XML-RPC是差不多的了，不同之處僅在于傳輸?shù)臉?biāo)準(zhǔn)格式由XML轉(zhuǎn)為了二進(jìn)制的格式。

　　同樣來回答問題：

　　1. 傳輸?shù)臉?biāo)準(zhǔn)格式是?

　　標(biāo)準(zhǔn)格式的二進(jìn)制文件。

　　2. 怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧?

　　將二進(jìn)制格式文件轉(zhuǎn)化為流。

　　3. 怎么接收和處理流?

　　通過監(jiān)聽的端口獲取到請求的流，轉(zhuǎn)化為二進(jìn)制文件，根據(jù)協(xié)議獲取請求的信息，進(jìn)行處理并將結(jié)果寫入XML中返回。

　　4. 傳輸協(xié)議是?

　　Http。

　　SOAP

　　SOAP原意為Simple Object Access Protocol，是一個用于分布式環(huán)境的、輕量級的、基于XML進(jìn)行信息交換的通信協(xié)議，可以認(rèn)為SOAP是XML RPC的高級版，兩者的原理完全相同，都是http+XML，不同的僅在于兩者定義的XML規(guī)范不同，SOAP也是Webservice采用的服務(wù)調(diào)用協(xié)議標(biāo)準(zhǔn)，因此在此就不多加闡述了。

　　CORBA

　　Common Object Request Broker Architecture(公用對象請求代理[調(diào)度]程序體系結(jié)構(gòu))，是一組用來定義“分布式對象系統(tǒng)”的標(biāo)準(zhǔn)，由OMG(Object Menagement Group)作為發(fā)起和標(biāo)準(zhǔn)制定單位。CORBA的目的是定義一套協(xié)議，符合這個協(xié)議的對象可以互相交互，不論它們是用什么樣的語言寫的，不論它們運(yùn)行于什么樣的機(jī)器和操作系統(tǒng)。

　　CORBA在我看來是個類似于SOA的體系架構(gòu)，涵蓋可選的遠(yuǎn)程通信協(xié)議，但其本身不能列入通信協(xié)議這里來講，而且CORBA基本淘汰，再加上對CORBA也不怎么懂，在此就不進(jìn)行闡述了。

　　JMS

　　JMS呢，是實(shí)現(xiàn)java領(lǐng)域遠(yuǎn)程通信的一種手段和方法，基于JMS實(shí)現(xiàn)遠(yuǎn)程通信時和RPC是不同的，雖然可以做到RPC的效果，但因?yàn)椴皇菑膮f(xié)議級別定義的，因此我們不認(rèn)為JMS是個RPC協(xié)議，但它確實(shí)是個遠(yuǎn)程通信協(xié)議，在其他的語言體系中也存在著類似JMS的東西，可以統(tǒng)一的將這類機(jī)制稱為消息機(jī)制，而消息機(jī)制呢，通常是高并發(fā)、分布式領(lǐng)域推薦的一種通信機(jī)制，這里的主要一個問題是容錯(詳細(xì)見ErLang論文)。

　　來看JMS中的一次遠(yuǎn)程通信的過程：

　　1. 客戶端將請求轉(zhuǎn)化為符合JMS規(guī)定的Message;

　　2. 通過JMS API將Message放入JMS Queue或Topic中;

　　3. 如為JMS Queue，則發(fā)送中相應(yīng)的目標(biāo)Queue中，如為Topic，則發(fā)送給訂閱了此Topic的JMS Queue。

　　4. 處理端則通過輪訓(xùn)JMS Queue，來獲取消息，接收到消息后根據(jù)JMS協(xié)議來解析Message并處理。

　　回答問題：

　　1. 傳輸?shù)臉?biāo)準(zhǔn)格式是?

　　JMS規(guī)定的Message。

　　2. 怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧?

　　將參數(shù)信息放入Message中即可。

　　3. 怎么接收和處理流?

　　輪訓(xùn)JMS Queue來接收Message，接收到后進(jìn)行處理，處理完畢后仍然是以Message的方式放入Queue中發(fā)送或Multicast。

　　4. 傳輸協(xié)議是?

　　不限。

　　基于JMS也是常用的實(shí)現(xiàn)遠(yuǎn)程異步調(diào)用的方法之一。