BES服务器推送机制分析（一）

最新推荐文章于 2024-07-24 17:28:59 发布

BBturials

最新推荐文章于 2024-07-24 17:28:59 发布

阅读量3.4k

点赞数

文章标签：服务器 blackberry 应用服务器 application url stream

作者: 邓明轩

前言

数据推送是 Bla ck Be rry 应用平台的一大优势，在 Bla ck Be rry 应用平台上部署的应用可以

和 Bla c kBe rr y 推送邮件一样通过推送实时地将数据从服务器端推送到 Bla ck Be rry 手持设备端。所以，对于很多应用开发商而言， Bla c kBe rry 应用平台提供的推送功能是 Bla ck Be rry 应用集成必然会使用到的强大功能。

然而，因为种种原因，有一些开发商发现使用 Bla ck Berr y En t e rpris e S e r ve r ( BE S ) 应用平

台的推送功能并不能保证数据到达 Bla c kBe rry 设备，导致应用层面的种种问题。实际上， Bla ck Be rr y 应用平台提供了从多机制保证数据推送的成功，只要我们充分了解 BE S 中 MD （ S 以下简称 MDS ）的推送机制，我们就可以利用平台提供的机制保证数据到达 Bla ck Be rry 手持设备。

本章节的主要目的是详细分析 MD S 的推送机制，让读者更好地了解 Bla c kB er r y 应用平台，从而可以开发更加强壮，更加稳定的 Bla ck Be rr y 应用。

值得读者注意的是，本章节的内容是结合少量的官方文档，配合于大量的测试总结而来的，旨在为读者提供更多的线索以理解 MD S 推送机制。如果本章节的内容与 RIM 提供的任何官方文档有冲突的话请以官方文档为准。同时，不同版本的 Bla ck Be rry 手持设备在不同场景下也可能有不同的行为，所以读者在生产环境实施 Bla ck Be rry 应用时也要结合用户所使用

的 Bla ck Be rry 设备进行测试，才能最好地保证应用的稳定性。

MDS 推送介绍

M DS 推送架构

在详细讲解 MD S 推送机制之前我们先从整体上了解 MD S 推送的架构，下面是 MD S 推送架构的示意图：

从示意图中可以看到在 Bla ck Be rry 应用平台上的数据推送从整体上可以分为六步，按时间顺序分别为：

1 ．第一步：应用服务器向 MD S /BE S 服务器发送推送请求，所发送的请求为 H T TP 格式的请求，有关请求的详细格式在下一小节中有详细讲解。

2 ．第二步： MDS / BE S 服务器查询相关配置数据库，确定应用服务器所发送的请求是否为合法的请求。此外， M DS /BE S 服务器还会根据资源情况确定是否接收该请求。对于是否接收请求的判断在下一节内容中也有详细讨论。

3 ．第三步： MDS / BE S 服务器向应用服务器返回消息，通知应用服务器是否接受该请求。返回消息以 HT TP 答复的方式返回给应用服务器。

4 ．第四步： MDS / BE S 服务器将数据推送到手持设备端

5 ．第五步：手持设备端对数据进行处理后向 MDS /BE S 服务器返回确认消息

6 ．第六步： MDS / BE S 根据手持设备端返回的消息决定向应用服务器返回什么异步消息，这一步并不是必然发生的，根据推送请求的不同有可能不发生。从这里我们可以看到，从应用服务器到手持设备端的推送通道是由多个不同的通道连接

而成的，这其中有很多个连接点，某一个连接点出现异常都可以导致推送的失败。所以应用开发商需要详细了解这些连接点可能出现的问题，在应用开发过程中进行规避。

在详细描述各个可能出现问题的关键点之前，需要先了解推送的基本实现。对于应用开发人员而言，完成数据推送需要完成的主要程序编写工作有：应用服务器端发出推送请求的程序，手持设备端侦听接收推送数据的程序，和服务器端侦听接收确认消息的程序，如下图橙色框图所显示的：

以下章节将对这三个部分作详细讲解。

数据推送命令格式

在 Bla ck Be rry 应用平台上的数据推送是由应用服务器发起的，应用服务器根据应用逻辑进行判断，发现有数据需要推送到用户的手持设备端时连接 MDS / BE S 服务器进行数据推送。应用服务器与 MDS / BE S 服务器的连接方式为 HTTP 连接，通过 HT TP 连接发送一个 P OS T 请求，将需要推送的数据作为 P OS T 的内容。

该 P OS T 请求的 U RL 格式为：

h t t p:// BE S _ HOS T : BE S _P O R T / pus h?DE S TINA TIO N= D E S INT A TIO N _ADD RE SS &P OR T = HA NDHE L

D_APP LIC A TIO N _P ORT &RE Q U E S TU RI=/

下面是请求中各参数的说明：

参数	描述
BE S _H OS T	Bla ck Be rry En t er p ris e S e r v er 的服务器名或者是 IP
BE S _P OR T	Bla ck Be rry En t er p ris e S e r v e r 的推送端口，一般是 8 08 0
DES TINA TIO N_ A DDRE S S	用户的邮件地址或者是设备码 ( P IN)
HAN DHEL D_APP LI C A TIO N_ P OR T	Bla ck Be rry 手持设备需要帧听的端口

也就是说，应用服务器通过 BE S _ HOS T 和 BE S _ P OR T 指定需要连接的 MDS /BE S 服务器和

需要连接的端口。 BE S 服务器安装后缺省使用 8 08 0 作为推送端口，所以推送应用开发人员一般情况下只需要了解 M DS /BE S 服务器的服务器名或者是 IP 地址就可以了。如果 BE S 管理人员在安装服务器后修改过推送端口，则需要告知开发人员使用新指定的端口。

推送 U R L 中 pus h? 后面的部分用于指定数据的接收者和手持设备需要帧听的端口。 DES TINA TIO N_ A DDRE S S 用于指定数据的接收者，可以使用该用户的邮件地址或者是该用户手持设备的 P IN 码。 HA NDHE LD_APP LIC A TIO N _P OR T 用于指定手持设备需要帧听的端口，这里使用的端口只是一个约定，要求在手持设备上运行的程序从这一端口中读取数据。

除了 U R L 参数以后，在推送过程还可以使用一些规定好的 HTTP 头指定该推送的属性，

HT TP 头参数表如下：

HT T P 头	描述
X - RIM-P us h-ID	用于指定该消息的 ID ，该 I D 需要是一个唯一值，可以用于取消推送或者是查看推送的状态。
X - RIM-P us h-N ot ifyU RL	用于指定确认消息的接收 U RL 。
X - RIM-P us h-R eli ab i lit y -Mo d e	用于指定推送的可靠性。
X - RIM-P us h-D eli v er - Be f o r e	用于指定推送数据的最迟推送时间。
X - RIM-P us h-P rio rit y	用于指定推送数据的优先级。

X - RIM-P us h-ID 属性一般建议使用 U R L 和编号结合的方式，如 1 2 3 @ bl ac kb er r y .c o m 。为

了更好地控制数据的推送，一般不建议使用随机数作为推送 ID 。使用统一的 I D 生成方式更有利于推送数据的取消和状态确定。注意，如果没有指定该参数的话， MDS /BE S 服务器会自动生成一个唯一的 ID ，这样就无法在应用服务器上使用这个 ID 对特定的推送数据进行处理了。此外，推送 ID 不能以 @ ppg .rim .c o m 结束。

X - RIM-P us h-N ot ifyU RL 属性通过 U RL 的形式指定了确认消息的接收地址，如 h t t p://t e s t ings er v er: 7 7 7 8 。指定了这一属性后， MDS / BE S 服务器会将推送的确认消息以 HT TP 请求的形式发送到指定的服务器。也就是说应用开发者需要开发一个 HT TP 服务器端程序监听指定服务器的指定端口（上例中则是服务器 t e s t in gs er v er 的 7 7 7 8 端口），通过这个服务器端程序获取确认消息。在确认消息中会包含 HT TP 头 X -RIM -P us h-ID 和 X -RIM- P us h-S t a t us ，通

过 X - RIM-P us h-ID 告知监听者是哪条推送数据的确认消息，通过 X - RIM-P us h-S t a t us 指明该数据推送的结果， 20 0 代表推送成功， 40 0 代表推送失败。现实环境中对于数据推送是否成功

不能简单地以结果 20 0 或者是 4 0 0 进行判断，需要结合很多因素进行判断，本文的后续章节会详细描述。

属性 X - RIM-P us h-R eli ab i lit y -Mo de 用于指定推送的可靠性，值可以是 T RA NSP OR T 或者是 APP LIC A TIO N ，另外有一个值 APP LIC A TIO NP REF ER RED 涉及更复杂的场景，这里不做描述。如果指定可靠性为 TR ANSP O R T 则以数据到达手持设备准，本文称之为非应用依赖。如果指定可靠性为 APP LI C A TIO N 则以数据被手持设备端应用接收为准，本文称之为应用依赖。对于不同可靠性设置，本文的后续章节会有详细描述。总体而言，非应用依赖的推送更适合于广播性质的不要求应用一定收到数据的场景，而应用依赖更适合于点对点的要求应用一定要收到数据的场景

属性 X - RIM-P us h-Deli v er - Bef o r e 用于指定数据推送的最后时间，如果在指定时间前该数据仍无法被成功推送到手持设备端，则该数据会被视作过期而被 MDS / BE S 服务器丢弃。

属性 X -RIM -P us h-P rio rit y 用于指定推送数据的优先级，指定推送数据的优先级并不能加快数据的推送，指定优先级的结果是推送数据到达手持设备端的行为不同。可以选择的值有： no ne ( 缺省 ) ， lo w ， m e di u m 和 hig h 。如果指定优先级为 lo w ， m e di um 或者是 hig h ，则用户只是接收到数据，如果指定优先级为 hig h ，则用户在接收到数据后还会看到提示对话框。

数据推送关键代码

理论上讲，应用服务器的数据推送代码可以用任何可以提供 HT TP 支持的语言编写，需要实现的不过是通过 HTTP 协议往指定的服务器和端口发送 P OS T 消息。

下面以 ja v a 代码为例讲解数据推送的关键代码部分。本例的代码片段为一个 Ja v a App li ca t io n 的部分代码，该 Ja v a App li ca t io n 在服务器上以 J 2 S E 应用的形式运行，启动一个线程发送 HT TP 的 P OS T 请求。以下代码为该线程的 r un 函数：

public void run() {

Random random = new Random();

String pushId = "pushID:" + random.nextInt(); String data = "What need to be pushed" ;

try {

URL _pushURL = new URL( "http" , "testingBE S.abc.com" , 8080,

"/push?DESTINATION=user1@abc.com&PORT=55100&REQUESTURI=/" );

HttpURLConnection conn = (HttpURLConnecti on) _pushURL.openConnection();

conn.setDoInput( true ); conn.setDoOutput( true ); conn.setRequestMethod( "POST" );

conn.setRequestProperty( "X-RIM-PUSH-ID" , pushId);

conn.setRequestProperty( "X-RIM-Push-NotifyURL" ,

"http://testingserver:7778" );

conn.setRequestProperty( "X-RIM-Push-Reliability -Mode" ,

"APPLICATION" );

OutputStream out = conn.getOutputStream();

out.write(data.getBytes());

out.close();

InputStream ins = conn.getInputStream();

int contentLength = conn.getContentLength();

int responseCode = conn.getResponseCode(); System. out .println( "Response Code is:" + responseCode);

if (contentLength > 0) {

byte [] someArray = new byte [contentLengt h]; DataInputStream dins = new DataInputStream(ins); dins.readFully(someArray);

System. out .println( new String(someArray));

} else {

System. out .println( "Content legth of response is 0" );

}

conn.disconnect();

} catch (IOException e) { System. err .println( "Exception:" + e);

}

在以上代码中，先通过 U R L 类建立一个 H T TP 连接定义， U RL 类的构造函数中第一个参数为协议类型，这里使用“ h t t p ” ，第二个参数为服务器名，第三个参数为请求的端口号。第二个参数和第三个参数对应了数据推送请求中的 BE S _H OS T 和 BE S _P OR T 属性。 U R L 类的构造函数中第四个参数为相对 U R L ，推送属性 DES TI NA TIO N 和 P O R T 都放在相对 U RL 中，代码如下：

URL _pushURL = new URL( "http" , "testin gBES.abc.com" , 8080,

"/push?DESTINATION=user1@abc.com&PORT=55100&REQUESTURI=/" );

建立了 U R L 类的实例后，可以通过该实例的 o p enCo nn ect io n 函数打开连接，返回的是一个 Ht t pU RL Co nn ect io n 实例。

HttpURLConnection conn = (HttpURLConnecti on) _pushURL.openConnection();

打开 h t t p 连接后可以通过连接实例的 s et R eq ues tP r o p e rt y 函数设置 h t t p 头，推送请求中

的 h t t p 头属性在这里设置，如：

conn.setRequestProperty( "X-RIM-PUSH-ID" , pushId);

其中一个关键的 h t t p 头属性是 X - RIM-P us h-R eli ab i lit y -Mo de ，设置该属性为 “ TR AN SP OR T ” 表示该推送是非应用依赖的推送，设置该属性为“ A PP LIC A TIO N ”表示该推送是应用依赖的

推送。两者的具体区别在后面的章节会有详细的讨论。以下代码设置该属性为

“ APP LIC A TIO N ”：

conn.setRequestProperty( "X-RIM-Push-Reliability -Mode" ,

"APPLICATION" );

特别要注意，如果设置推送类型为应用依赖，对于服务器的设置和手持设备有特定的要求。一方面是服务器端必须是 4 .0 以上，同时必须设置允许对所使用的端口进行应用依赖的推送，一方面是要手持设备的 R OM 版本也是 4 . 0 以上，同时服务器必须知道手持设备能否支持应用依赖的推送。对于服务器的端口设置，设置界面如下，可以由 BE S 管理员进行设置：

如果是使用开发环境的 M DS -CS 模拟器模拟应用依赖推送的话，需要修改开发环境的 MDS /c o n fig 目录中的 rim pu bl ic .p r o pe rt y 文件，去除 pus h. ap pl ic a t io n. r eli ab le.po rt s 一行的注释，同时加上需要推送的端口，如“ pus h. ap pl ic a t io n. r eli ab le.po rt s =1 0 0 ， 5 5 1 0 0 ” 。

对于服务器端是否知道手持设备端的版本，需要通过手持设备端的操作完成。只要手持设备端的浏览器通过 BE S 访问过网络，服务器就会记录该手持设备是否支持应用依赖的推送。如果只是测试的话，在测试前通过手持设备端的浏览器打开任何一个网站就可以了。如果是生产环境，则需要考虑客户端应用在第一次启动的时候主动访问一次网络，以保证客户端都可以正常接收应用依赖的推送。

如果以上设置没有完成的话，对 MDS /BE S 服务器发送应用依赖的推送时会被拒绝，服务器端会出现“ The s peci fi e d del iv er y m et ho d is no t p oss i bl e ”的错误。应用服务器的推送程序则会捕获以下异常：

“ java.io.IOException : Server returned H TTP response code: 4 00 for

URL: http://app... ”

设置属性后就需要获取 h t t p 连接的 Out putSt re am ，将需要推送的数据写入 Out p ut St re am

中，写完后关闭连接。

需要注意的是 MDS / BE S 服务器是否接收该推送请求是通过 h t t p 返回码实现的，所以推送应用中需要获取到 h t t p 连接的返回码，通过返回码判断推送是否成功，代码如下：

int responseCode = conn.getResponseCode();

客户端接收关键代码

客户端数据接收程序运行在 Bla ck Be rry 手持设备上，必须通过 ja v a 语言实现，需要调用

Bla ck Be rr y 设备端的 AP I 。

客户端接收程序的主体就是启动一个线程，开启 h tt p:// : <po rt> 连接（其中 po r t 是客户端需要侦听的端口号），然后从该连接中获取 In putSt r e am ，从 In putSt re am 中获取服务器所

推送的数据。

下面是侦听线程的 run 方法，为保持程序的完整，代码中使用到的类属性并没有修改，

从该函数中看到的本函数没有定义的变量都是该类的类属性。有关完整代码，请参考

Bla ck Be rr y 开发环境所提供的标准样例。

public void run(){ StreamConnection stream = null ;

InputStream input = null ; MDSPushInputStream pushInputStream= null ;

while (! _stop )

{

try

{

synchronized ( t his )

{

_notify =

(StreamConnectionNotifier)Connector. open ( "http://:55100" );

}

while (! _stop )

{

stream = _n o ti fy .acceptAndOpen();

try

{

input = stream.openInputStream();

pushInputStream= new

MDSPushInputStream ((HttpServerConnection)stream, input); DataBuffer d b = new DataBuffer();

byte [] data = new byte [256];

int chunk = 0;

while ( - 1 ! = (c hu nk = i np ut .r ea d( da ta )) )

{

db.write (data, 0, chunk);

}

pushInputStr eam.accept(); input.close( ); stream.close ();

data = db.ge tArray();

}

catch (I OE xc ep ti on e 1)

{

System. er r .println(e1.toString());

if ( in pu t != null )

{

try

{

in pu t. cl os e( );

}

ca tc h (IOException e2)

{

}

if ( st re a m != null )

{

try

{

st re am .c lo se () ;

}

ca t ch (IOException e2)

{

}

_notify .close() ;

_notify = null ;

}

catch (IOExceptio n ioe)

{

if ( _notify != null )

{

try

{

_notify .c lo se () ;

_notify = null ;

}

catch ( IO Ex ce pt io n e )

{

}

以上代码中，建立端口侦听的代码如下：

_notify = (StreamConnectionNotifier)Connector. open ( "http:// :55100" ); 其中 U RL “ h t t p:// : 5 5 1 0 0” 是用于侦听推送的特定格式， 5 5 1 0 0 为需要侦听的端口。两个线程不能同时打开同一个端口的侦听，所以在这里使用了 s ync h r o ni z e d 对线程并发进行了

控制。

建立侦听后可以通过函数 ac cept And Op en 开始侦听，当线程调用该方法开始侦听的时候线程会阻塞在这里，直到有推送消息到达。代码如下：

stream = _notify .acceptAndOpen();

侦听之后的代码为获取连接的 In putSt r e am ，从 In putSt re am 中获取服务器端推送的数据。读取完数据后关闭 In putSt r e am 和 St re am Co nn ect io n ，然后重新调用 ac c ept A dn Op en 继续侦听端口，准备接收新的推送数据。

开发人员如果希望使用应用依赖的推送，在客户端必须将 In putSt re a m 转换成 MDSP us hI np ut St re am ，同时在接收完数据后调用 M DSP us hI np ut St re am 的 ac ce pt 函数造知服务器该数据已收到。这也是应用依赖和非应用依赖在代码实现层面的最主要区别。代码如下：

pushInputStream= new

MDSPushInputStream ((HttpServerConnection)stream, input);

……

pushInputStream.accept();

从良好的编程习惯来讲，在连接使用后需要主动关闭所使用的连接和资源，如 In putSt re am 、 St re am Co nn e ct io n 、 St re am Co nn ect io nN ot ifi er 等。所以在样例代码中也可以看到该样例在异常处理阶段都对这些资源进行了关闭操作。在关闭这些连接和资源的时候对 St re am Co nn ect io nN ot ifi er 需要特别注意，有可能在 St re am Co nn ect io nN ot ifi er 中会保留有未读取的推送数据，需要调用 ac ceptA dn Op en 函数将保留的数据读取出来，直到 ac ce ptA dn Op en 处于阻塞状态。

另外，如果使用了应用依赖的推送，客户端程序调用 MDSP us hI np ut St re am 的 ac ce pt 函数后确认消息不会马上发出，而是在对应用 In putSt r e am 和 St r e am Co nn ectio n 关闭后才发出。所以对于应用依赖的推送，保证 In putSt re am 和 St r e am Co nn ect io n 的关闭非常之重要。

异步确认消息接收代码

异步消息的接收代码运行在服务器端，在推送请求的 X -RIM -P us h-Not ifyU RL 属性所指定的服务器上侦听指定端口。和应用服务器端的数据推送代码一样，异步确认消息的接收程序可以通过任何支持 HTTP 的语言编写。主要的工作是侦听指定端口，从指定端口获取 MDS /BE S 发送回来的确认消息，根据 HTTP 协议获取相关属性并返回相关信息。