📄 209005.htm
字号:
<html><body><span id=Layer1><a name=209005><font color=#3e70d7 face=arial size=5><b>存取MSMQ</span><span id=Layer2></b></font><p><font size=2 color=#3c3c3c face=arial>MSMQ为应用程式提供了几种不同的存取方式。首先，有两组不同的API可以直接存取MSMQ。其一是针对C与C++程式开发者，定义为一组C函数。另一组是针对Microsoft Visual Basic、JAVA、甚至是C++程式开发者，定义为一组COM物件。两者都可用来建立、传送以及接收讯息，但C API可以存取更多的MSMQ服务。</span><span id=Layer3></font></p><p><font size=2 color=#3c3c3c face=arial>MSMQ有C API以及COM API</span><span id=Layer4></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>MSMQ有C API以及COM API</span><span id=Layer5></font></p><hr><p><font size=2 color=#3c3c3c face=arial>MSMQ 2.0也提供另一个选择－伫列元件 （Queued Components，简写为QC）。QC使得应用程式能较容易地使用MSMQ当作底层机制来呼叫远端物件的method。QC不能使用MSMQ提供的所有特性，但它提供给开发者一个简单、自然的介面。</span><span id=Layer6></font></p><p><font size=2 color=#3c3c3c face=arial>应用程式也能使用伫列元件存取MSMQ</span><span id=Layer7></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>应用程式也能使用伫列元件存取MSMQ</span><span id=Layer8></font></p><hr><font color=#3e72d7 face=arial size=4><b>MSMQ API</span><span id=Layer9></b></font><p><font size=2 color=#3c3c3c face=arial>先来看看MSNQ的C API是有意义的，不只是因为它是功能最强大的选择，也是因为它提供了以COM为基础的API，以及QC的基础。C API中最重要的函数是：</span><span id=Layer10></font></p><font size=2 color=#3c3c3c face=arial><ul><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> MQCreateQueu</span><span id=Layer11> </b></font>在MSMQ伺服器或独立客户端建立一个新的伫列。这伫列可以在建立它的应用程式所在的同一机器上，也可以在其他的机器上。</span><span id=Layer12></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> MQDeleteQueue</span><span id=Layer13> </b></font>删除伫列。</span><span id=Layer14></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> MQOpenQueue</span><span id=Layer15> </b></font>开启一个已经存在的伫列。如前所述，在MSMQ 2.0中可以利用Active Directory找到公用伫列。</span><span id=Layer16></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> MQCloseQueue</span><span id=Layer17> </b></font>关闭伫列。</span><span id=Layer18></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> MQSendMessage</span><span id=Layer19> </b></font>传送讯息到特定的伫列。程式开发者指定讯息的属性值，然後传递它们当作函数的参数。</span><span id=Layer20></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> MQReceiveMessage</span><span id=Layer21> </b></font>由特定的伫列接收讯息。讯息能以同步的方式读取，接收的应用程式会一直等到讯息到达 （或是应用程式设定的时间限制到了），或是以非同步的方式读取，应用程式经由回呼函数 （callback function） 或其他方式收到讯息到达的通知。应用程式可以取出讯息，这会将伫列中的讯息移除；或者检视讯息，应用程式可以检查讯息的属性但不会移除讯息。应用程式也可以选择只接收拥有某些属性的讯息，这不需要读取整个讯息。最後，藉由游标 （cursor） 的使用，应用程式可以检视以及接收目前不在伫列最上端的讯息。</span><span id=Layer22></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>CAPI可以存取所有的MSMQ服务</span><span id=Layer23></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>CAPI可以存取所有的MSMQ服务</span><span id=Layer24></font></p><hr><p><font size=2 color=#3c3c3c face=arial>使用C API的函数时，开发者必须先填好一些结构的值，然後传递它们当作函数的参数。这是建立讯息API的典型做法，所以MSMQ提供这种选择并不奇怪。如果你熟悉其他讯息产品的API，那你对这个MSMQ介面应该不陌生。</span><span id=Layer25></font></p><p><font size=2 color=#3c3c3c face=arial>MSMQ也提供一个更现代化的介面，一个以COM物件定义的介面。这个介面基本上是将MSMQ原有的C API包装为COM物件与介面，让开发者可以藉由设定物件属性和呼叫物件method来存取MSMQ的服务。</span><span id=Layer26></font></p><p><font size=2 color=#3c3c3c face=arial>例如，建立一个伫列可以使用MSMQQueueInfo物件。过程相当简单：开发者可以指定伫列的名称到MSMQQueueInfo物件的PathName属性，然後呼叫 （invoke） 物件的Create method。要开启这个新建的伫列，应用程式可以呼叫MSMQQueueInfo::Open。这个呼叫会传回一个MSMQQueue物件，这物件可以当作开启伫列的参考 （reference）。若要取得参考到已经存在伫列而不是新建伫列的MSMQQueue物件，应用程式可以使用MSMQQuery物件的LookupQueue method。这个method有各式各样的参数，应用程式可以设定特别的准则来寻找伫列。</span><span id=Layer27></font></p><p><font size=2 color=#3c3c3c face=arial>COM API藉由一组COM物件显露出MSMQ的服务</span><span id=Layer28></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM API藉由一组COM物件显露出MSMQ的服务</span><span id=Layer29></font></p><hr><p><font size=2 color=#3c3c3c face=arial>要建造以及传送讯息的话，开发者先建立一个MSMQMessage物件、设定它的属性、然後呼叫它的Send method。至於讯息要送到那个伫列，是经由参数中的MSMQQueue物件决定。要接收讯息的话，应用程式同样呼叫一个适当的method，并以MSMQMessage物件为参数来指出接收那个伫列的讯息。如前所述，有很多接收讯息的方式可以选择，应用程式不一定要傻等讯息到达伫列。</span><span id=Layer30></font></p><font color=#3e72d7 face=arial size=4><b>伫列元件</span><span id=Layer31></b></font><p><font size=2 color=#3c3c3c face=arial>不管使用那种MSMQ API－C介面或COM-based介面－都要了解讯息伫列的基本传送/接收方式。对有经验的讯息程式开发者而言，这不是问题。撰写程式码来开启伫列、建立讯息、传送讯息、然後关闭伫列变得相当自然。但对较习惯RPC风格的开发者，例如COM开发者，经历这些步骤会令人觉得十分累赘。为什麽不让传送讯息就像呼叫COM物件method一样地简单呢？</span><span id=Layer32></font></p><p><font size=2 color=#3c3c3c face=arial>这就是QC要做的事。QC首次出现是在Windows 2000中，属於COM+的一部分。QC使得开发者可以使用MSMQ而不会看到传统的讯息伫列介面。取而代之的，开发者撰写呼叫COM物件method的程式码，而QC会处理利用MSMQ讯息来传递那些method呼叫的细节。</span><span id=Layer33></font></p><p><font size=2 color=#3c3c3c face=arial>QC使得讯息伫列更像RPC</span><span id=Layer34></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>QC使得讯息伫列更像RPC</span><span id=Layer35></font></p><hr><p><font size=2 color=#3c3c3c face=arial>工作原理如图9-3所示。图中，客户端引发一个或更多的COM物件介面的method。然而，直到客户端使用完物件为止，没有method呼叫会真正送到物件。就QC所定义，所谓客户端使用完物件不是method呼叫所参与的异动确认了 （如果呼叫在异动内），就是客户端呼叫了介面指标的Release method。在这发生前，这些method呼叫的资讯就存放在一个QC元件内，称为</span><span id=Layer36><font size=2 face=arial color=#3e80d7><b> Recorder</span><span id=Layer37> </b></font>。</span><span id=Layer38></font></p><p><font size=2 color=#3c3c3c face=arial>Rcorder拦截客户端所做的呼叫</span><span id=Layer39></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Rcorder拦截客户端所做的呼叫</span><span id=Layer40></font></p><hr><p><font size=2 color=#3c3c3c face=arial>QC依赖标准的COM基础架构来执行参数包装（marshaling）动作，而不是强迫开发者了解讯息的资料格式。如此，呼叫能以MSMQ讯息的方式传送到目的地COM物件。另一端，包含目标物件的伺服端倾听进来的讯息，然後分派它们到另一个QC元件，称为Player。标准的COM marshaling再次被使用，而Player转换每个收到的讯息到对应的method呼叫。</span><span id=Layer41></font></p><p><font size=2 color=#3c3c3c face=arial>Player发送呼叫到目标物件</span><span id=Layer42></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Player发送呼叫到目标物件</span><span id=Layer43></font></p><hr><br><center><a target=_new href=imagesh/9-3.gif><img border=0 src='imagesl/9-3.gif'></a></center></span><span id=Layer44><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图9-3</span><span id=Layer45> </b></font>使用QC，客户端可以藉由呼叫COM物件method来传送MSMQ讯息。</span><span id=Layer46></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>当然，使用MSMQ而不是COM的传统机制来转运method呼叫也衍生出一些限制。最重要的是，能透过这种方式引发的method只能有</span><span id=Layer47><font size=2 face=arial color=#3e80d7><b> in</span><span id=Layer48> </b></font>参数，而且不能有传回值。这应该一点都不令人感到意外；毕竟，如果客户端是一个异动的COM物件，呼叫method这个讯息必须等到物件所参与的异动结束後才会被传送。但由於及时启动 （just-in-time activation，JIT），结束异动也会将物件闲置（deactivate），所以即使讯息可以传送，但也收不到传回值了。重点是，QC是一种单向 （one-way） 的沟通方式。如果目标物件想要回应的话，它必须呼叫原始客户端所支援介面上的method或是以其他的方式传回资讯。双向 （two-way） 沟通需要有两条分开的单向路径。</span><span id=Layer49></font></p><p><font size=2 color=#3c3c3c face=arial>QC所使用的介面只能有输入参数</span><span id=Layer50></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>QC所使用的介面只能有输入参数</span><span id=Layer51></font></p><hr><p><font size=2 color=#3c3c3c face=arial>能使用QC来呼叫的元件必须是已设定元件 （configured component）。那就是说，它们必须是COM+应用程式的一部份。就像其他的已设定元件一样，使用QC的元件可以利用COM基於角色的安全性机制做验证动作，即使物件不能模拟它们的客户端。让QC使用的介面中的method也必须遵循前面所述的规则－只能有</span><span id=Layer52><font size=2 face=arial color=#3e80d7><b> in</span><span id=Layer53> </b></font>参数而且不能有传回值。如果符合的话，介面的IDL可以标志为QUEUABLE，而是否以QC或是一般的COM机制呼叫method的决定在於元件的管理过程而不是元件的撰写过程。这会是相当方便的，因为这让相同元件可以利用QC也可以不利用QC，完全取决於如何设定元件。元件甚至可以在不同的时间有不同的行为，执行时才决定用DCOM或QC。</span><span id=Layer54></font></p><p><font size=2 color=#3c3c3c face=arial>只有已设定元件可以使用QC</span><span id=Layer55></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>只有已设定元件可以使用QC</span><span id=Layer56></font></p><hr><p><font size=2 color=#3c3c3c face=arial>QC的客户端并不需要是COM+应用程式的一部分，但QC仍然必须存在客户端的机器上。这意味着那些客户端必须执行在Windows 2000系统上。</span><span id=Layer57></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>QC的客户端并不需要是COM+应用程式的一部分，但QC仍然必须存在客户端的机器上。这意味着那些客户端必须执行在Windows 2000系统上。</span><span id=Layer58></font></p><hr><p><font size=2 color=#3c3c3c face=arial>一些有撰写过讯息伫列应用程式的开发者可以毫无困难地使用MSMQ的API。但对日渐增加的COM导向程式开发者而言，QC可能比较容易使用。两者孰优孰劣很难评断。</span>
</body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -