📄 208006.htm
字号:
<html><body><span id=Layer1><a name=208006><font color=#3e70d7 face=arial size=5><b>COM+其它技术</span><span id=Layer2></b></font><p><font size=2 color=#3c3c3c face=arial>COM+引进相当丰富的特性（有个特性还蛮复杂的）。这一节将简单描述更多的服务技术。</span><span id=Layer3></font></p><font color=#3e72d7 face=arial size=4><b>更多关於存取Context资讯的议题</span><span id=Layer4></b></font><p><font size=2 color=#3c3c3c face=arial>COM runtime提供的服务都是围绕在context的概念。在IObjectContext中的method（第一个在MTS引进的介面）存取物件的context，不过在Windows 2000中，新介面同样也提供这个功能以便与这些资讯一起运作。举例来说，IObjectContextInfo介面提供下面的method∶</span><span id=Layer5></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> IsInTransaction</span><span id=Layer6> </b></font>如同IObjectContext::IsInTransaction一样，若发出呼叫的物件目前为某个交易的一部份，则回传True。</span><span id=Layer7></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> GetTransaction</span><span id=Layer8> </b></font>回传目前交易中指向ITransaction介面的介面指标。ITransaction已定义为OLE Transactions的一部份，因此它的method允许存取关於目前交易更详细的资讯。举例来说，这个介面指标可能用在一个放入连线共用区的物件（pooled object），而这个物件需要明确地将一个资源管理者加入一个交易中。</span><span id=Layer9></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> GetTransactionId</span><span id=Layer10> </b></font>回传目前交易的交易识别码（一个GUID）。</span><span id=Layer11></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> GetActivityId</span><span id=Layer12> </b></font>回传目前activity的识别码（一个GUID）。</span><span id=Layer13></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> GetContextId</span><span id=Layer14> </b></font>回传目前context的识别码（一个GUID）。</span><span id=Layer15></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>IObjectContext-Info允许存取更详细的交易资讯</span><span id=Layer16></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>IObjectContext-Info允许存取更详细的交易资讯</span><span id=Layer17></font></p><hr><p><font size=2 color=#3c3c3c face=arial>同样地，COM+引进的IContextState介面允许你精确控制何时物件将被闲置，以及物件是否为交易的一部份，以及是否投票确认交易或取消交易。大部份的COM+应用程式可能不会呼叫这些method，使用IObjectContext的SetComplete与SetAbort通常就已足够。不过必要时可以使用它们。这个介面中的method包含∶</span><span id=Layer18></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> SetDeactivateOnReturn</span><span id=Layer19> </b></font>这个呼叫会设定done位元，控制method回传时是否将物件闲置。</span><span id=Layer20></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> GetDeactivateOnReturn</span><span id=Layer21> </b></font>回传done位元的值。</span><span id=Layer22></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> SetMyTransactionVote</span><span id=Layer23> </b></font>这个呼叫会设定consistent位元，控制物件是否要确认自己所属的交易。</span><span id=Layer24></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> GetMyTransactionVote</span><span id=Layer25> </b></font>回传consistent位元的值。</span><span id=Layer26></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>IContextState允许更精确地存取done位元与consistent位元</span><span id=Layer27></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>IContextState允许更精确地存取done位元与consistent位元</span><span id=Layer28></font></p><hr><p><font size=2 color=#3c3c3c face=arial>COM runtime依赖这两个位元的值来判断在method回传时要采取什麽行动。当一个使用JIT启动的交易性物件开始执行时，consistent位元是设定为TRUE，而done位元则设定为FALSE。在预设情况下，method回传时若没有更动这些值，便指示这个物件愿意确认这个交易（因为consistent位元是设定为TRUE），且未曾表示希望闲置这个元件（因为done位元设定为FALSE）。这些位元可以很精确地使用列示於上的method进行设定，而本章前面描述的method也同样会设定这些位元。这些呼叫以及设定的结果为∶</span><span id=Layer29></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> SetComplete</span><span id=Layer30> </b></font>同时将done位元与consistent位元设定为TRUE。这个物件希望被闲置，同时投票确认交易。</span><span id=Layer31></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> SetAbort</span><span id=Layer32> </b></font>将done位元设定为TRUE，并将consistent位元设定为FALSE。这个物件希望被闲置，同时投票取消交易。</span><span id=Layer33></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> EnableCommit</span><span id=Layer34> </b></font>将done位元设定为FALSE，然後将consistent位元设定为TRUE。这个物件不希望被闲置，同时投票确认交易。</span><span id=Layer35></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> DisableCommit</span><span id=Layer36> </b></font>将done位元设定为FALSE，然後将consistent位元设定为FALSE。这个物件不希望被闲置，同时投票取消交易。</span><span id=Layer37></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>SetComplete、SetAbort，与其它的method同样会设定done位元与consistent位元</span><span id=Layer38></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>SetComplete、SetAbort，与其它的method同样会设定done位元与consistent位元</span><span id=Layer39></font></p><hr><p><font size=2 color=#3c3c3c face=arial>设定method的auto-done属性同样会影响这些位元的值。在这个method呼叫之前，它更改done位元的预设设定，将其设定为TRUE，指明当method回传时，物件希望被闲置。当method确实回传後，COM runtime判断method是否完全地成功执行。若一切顺利，runtime便将consistent位元设定为TRUE，而这个物件将会投票确认交易。若回传错误，runtime就会将consistent位元设定为FALSE，而物件就会投票取消这个交易。</span><span id=Layer40></font></p><font color=#3e72d7 face=arial size=4><b>建构者 （Constructor）</span><span id=Layer41></b></font><p><font size=2 color=#3c3c3c face=arial>许多物件导向程式化语言提供建构者，当一个物件建立时，可携带一些资讯用来初始化新物件。Windows 2000将这个能力到新增到身为COM+应用程式一部份的COM物件上。若要享受这个能力带来的好处，可使用元件服务管理工具，来设定已设定元件（configured component）的建构者字串。举例来说，若元件必须从资料库存取顾客的资料，而资料库的名称则因应用程式中元件欲使用的不同而有所不同，这时便可以使用建构者字串来提供资料库的名称。</span><span id=Layer42></font></p><p><font size=2 color=#3c3c3c face=arial>COM物件可以使用建构者(Constructor)</span><span id=Layer43></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM物件可以使用建构者(Constructor)</span><span id=Layer44></font></p><hr><p><font size=2 color=#3c3c3c face=arial>若要使用建构者，物件必须实作IObjectConstruct介面。当一个新物件建立时，COM runtime将会呼叫IObjectConstruct::Construct method，将建构者字串当做参数传入。然後物件便可以存取这个字串，然後用来进行必要的初始化步骤。</span><span id=Layer45></font></p><font color=#3e72d7 face=arial size=4><b>COM+应用程式Proxy</span><span id=Layer46></b></font><p><font size=2 color=#3c3c3c face=arial>COM客户端依赖proxy，有时也依赖型态程式库来包装对物件发出的method call。传统上，这些proxy与型态程式库是手动安装、注册到客户端的机器上，这样做是非常合理的。然而在Windows 2000中，所有的proxy、型态程式库与其它存取包含在特定COM+应用程式中的所有类别、所有介面的资讯都可放到一个称做应用程式 proxy的档案中。</span><span id=Layer47></font></p><p><font size=2 color=#3c3c3c face=arial>COM+应用程式 proxy包含proxy、型态程式库与存取COM+应用程式时所需的资讯</span><span id=Layer48></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM+应用程式 proxy包含proxy、型态程式库与存取COM+应用程式时所需的资讯</span><span id=Layer49></font></p><hr><p><font size=2 color=#3c3c3c face=arial>应用程式 Proxy可以使用元件服务管理工具建立，它们通常都包装成MSI档案，以便使用Windows Installer进行部署。这代表了只要设定好适当的群组原则（Group Policy），应用程式 proxy就可透过Active Directory，以指派（assign）、或公告（publish）应用程式的方式进行部署。一旦完成这个动作，COM客户端唯一需要做的事情便是透过Active Directory找到COM+应用程式，并与其沟通，然後自动安装。虽然整个COM+应用程式可以依选择而下载，最有趣（也是最平常）的情况便是在当COM+应用程式执行在和客户端不同的机器上时。从现在开始，下面的章节中，我将会假设这个情况。</span><span id=Layer50></font></p><p><font size=2 color=#3c3c3c face=arial>在必要时，应用程式 proxy可以组态设定为指派(ass-ign)或公告(publish)应用程式，然後在需要时安装</span><span id=Layer51></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>在必要时，应用程式 proxy可以组态设定为指派(ass-ign)或公告(publish)应用程式，然後在需要时安装</span><span id=Layer52></font></p><hr><p><font size=2 color=#3c3c3c face=arial>回顾</span><span id=Layer53> <a target='_new' href=202.htm#>第二章</span><span id=Layer54></a> 中介绍的，指派（assign）与公告（publish）应用程式能够针对每台电脑或每个使用者。首先我先描述当一个应用程式 proxy经由群组原则的指派（assign）方式组态後会发生什麽事，然後看看当它使用公告（publish）时的改变。</span><span id=Layer55></font></p><p><font size=2 color=#3c3c3c face=arial>最简单的情况是当应用程式proxy组态为指派（assign）到一台电脑的应用程式时。 在这个情况下，将使用Active Directory找到应用程式proxy，然後在电脑开机时自动下载。当客户端试着建立一个这个应用程式proxy参考到的COM+应用程式时，则所有存取这个应用程式所需资讯都已存在。</span><span id=Layer56></font></p><p><font size=2 color=#3c3c3c face=arial>若应用程式组态为指派（assign）给一个使用者的应用程式，则当使用者登入，便会发行一个Active Directory查询。这样将会进行最简化的安装动作：将资讯放到客户端的系统登录（registry）之中，不过应用程式proxy并不会真正下载或进行安装。当这个使用者执行的应用程式呼叫到CoCreateInstance或其它建立物件的函数时，COM runtime将会直接到包含应用程式proxy的档案伺服器进行下载，完成安装的动作，然後建立物件。没有再次查询Active Directory的必要。</span><span id=Layer57></font></p><p><font size=2 color=#3c3c3c face=arial>若应用程式proxy组态为一个公告（publish）给客户端电脑或使用者的应用程式，则会发生何事是依赖於套用到发出这个呼叫使用者的群组原则设定，以及客户端在呼叫CoCreateInstance与CoCreateInstanceEx时指定的旗标值所决定的。在COM+中，这些呼叫中多了两个新的旗标：ENABLE_CODE_DOWNLOAD，允许客户端明确地要求下载应用程式proxy（或其它的COM元件），以及NO_CODE_DOWNLOAD，允许客户端明确地要求不要下载应用程式proxy。一个客户端也可以不指定旗标，这也是在Windows 2000出来之前每个COM客户端预设的行为（因为这个旗标在COM+之前并不存在的缘故。）</span><span id=Layer58></font></p><p><font size=2 color=#3c3c3c face=arial>群组原则设定与客户端指定的旗标可以控制是否下载一个设定为发行(publish)的应用程式</span><span id=Layer59></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>群组原则设定与客户端指定的旗标可以控制是否下载一个设定为发行(publish)的应用程式</span><span id=Layer60></font></p><hr><p><font size=2 color=#3c3c3c face=arial>若客户端在呼叫CoCreateInstance或CoCreateInstanceEx时指定了ENABLE_CODE_DOWNLOAD，则群组原则设定的值并不重要。若建立物件的呼叫中包含这个物件CLSID的应用程式，proxy是以公告（Publish）应用程式的型式存在，则应用程式proxy将会被下载并进行安装。若客户端指定NO_CODE_DOWNLOAD，则群组原则设定值同样的也不重要，即使应用程式 proxy存在，也不会进行下载。</span><span id=Layer61></font></p><p><font size=2 color=#3c3c3c face=arial>只有在客户端没有指定这些旗标，以及应用程式proxy是一个公告（Publish）到使用者或电脑的应用程式情况下，群组设定才能够控制要发生的事情。在这个情况下，若群组原则的设定中允许进行下载的动作，便会下载应用程式，proxy，若群组原则设定不允许下载，则不会进行下载的动作。</span><span id=Layer62></font></p><p><font size=2 color=#3c3c3c face=arial>为了进一步了解运作的情况，图8-24与8-25展示一个范例，以阐述当应用程式是一个公告（publish）到使用者或电脑的应用程式时，所发生的事情。如图8-24的步骤一与步骤二中所示，客户端呼叫了CoCreateInstance，使得COM runtime到单机系统登录中查询CLSID_X。若找到这个CLSID，则所有的事情都会如常运行，同时并依据此类别建立一个实例，这个实例依赖於客户端机器中系统登录的设定，可能会建立在本机（local）或是远端（remote）的机器上。若客户端系统登录中找不到这个CLSID，如目前的范例所示，则COM runtime便检查上述的旗标，以及群组原则的设定以判断是否允许下载这个类别。</span><span id=Layer63></font></p><p><font size=2 color=#3c3c3c face=arial>COM runtime能自动地下载、并安装应用程式 proxy</span><span id=Layer64></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM runtime能自动地下载、并安装应用程式 proxy</span><span id=Layer65></font></p><hr><p><font size=2 color=#3c3c3c face=arial>若允许下载，则COM runtime便自动向Active Directory发行一个查询，要求CLSID_X的应用程式proxy所在位置，如步骤叁所示。接下来Active Directory回传位於某台伺服器上的此档案之路径名称，如步骤四与五，客户端机器便下载应用程式 proxy并进行安装的步骤。</span><span id=Layer66></font></p><p><font size=2 color=#3c3c3c face=arial>在安装的过程中，所有的proxy、型态程式库、系统登录设定值，以及使用COM+应用程式中这个类别所需的其它资讯都会正确地设定好。若COM+应用程式执行在其它的系统上，如此范例，则这些资讯中将会包含远端机器的名称。在安装应用程式 proxy的过程中，远端机器名称将会复制到客户端的系统登录中， 如步骤五所示。</span><span id=Layer67></font></p><p><font size=2 color=#3c3c3c face=arial>应用程式pro-xy能复制远端机器名称到客户端的系统登录中</span><span id=Layer68></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>应用程式pro-xy能复制远端机器名称到客户端的系统登录中</span><span id=Layer69></font></p><hr><br><center><a target=_new href=imagesh/8-24.gif><img border=0 src='imagesl/8-24.gif'></a></center></span><span id=Layer70><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图8-24</span><span id=Layer71> </b></font>在一个公告（publish）应用程式上呼叫CoCreateInstance会导致应用程式 proxy下载并进行安装的动作。</span><span id=Layer72></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>截至此刻，事情运作的状况看起来就如同客户端已有了所有的资讯，包含远端伺服器的名称等。如图8-25的步骤六与七阐示，客户端的COM runtime与另一台伺服器机器沟通，然後在此机器的系统登录中找寻特定的 CLSID。建立物件的过程在步骤八到十中完成，并让客户端能够自由地呼叫新物件上的method。</span><span id=Layer73></font></p><p><font size=2 color=#3c3c3c face=arial>这就是</span><span id=Layer74> <a target='_new' href=201.htm#>第一章</span><span id=Layer75></a> 范例中所描述的机制，客户端使用Active Directory找寻欲建立COM物件的机器所在位置。</span><span id=Layer76></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>这就是</span><span id=Layer77> <a target='_new' href=201.htm#>第一章</span><span id=Layer78></a> 范例中所描述的机制，客户端使用Active Directory找寻欲建立COM物件的机器所在位置。</span><span id=Layer79></font></p><hr><p><font size=2 color=#3c3c3c face=arial>值得特别注意的是，将应用程式proxy或其它的COM元件设定为公告（publish）应用程式，然後允许不在预期之内的客户端（指非ENABLE_CODE_DOWNLOAD，也不是NO_CODE_DOWNLOAD）进行下载是很危险的。</span><span id=Layer80></font></p><p><font size=2 color=#3c3c3c face=arial>一旦远端伺服器名称安装後，物件建立的程序就和平常一样</span><span id=Layer81></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>一旦远端伺服器名称安装後，物件建立的程序就和平常一样</span><span id=Layer82></font></p><hr><br><center><a target=_new href=imagesh/8-25.gif><img border=0 src='imagesl/8-25.gif'></a></center></span><span id=Layer83><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图8-25</span><span id=Layer84> </b></font>一旦远端伺服器名称已放到客户端的系统登录中，远端物件就如平常的方式建立</span><span id=Layer85></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>首先，每当所要求的CLSID不存在本机系统登录中时，这样会导致Active Directory进行搜寻的动作，影响执行的效能，这是因为这个CLSID通常无法在目录中找到的缘故。同样地，所要求的CLSID可能是透过目录找到的，不过实作这个类别的程式码可能为某些大型应用程式的一部份，而非是客户端感兴趣的特殊元件。不过，这项找寻应用程式proxy、下载并进行安装应用程式proxy、或随要求安装其它元件的能力是相当有用的。</span><span id=Layer86></font></p><font color=#3e72d7 face=arial size=4><b>Bring Your Own Transaction</span><span id=Layer87></b></font><p><font size=2 color=#3c3c3c face=arial>一个COM元件成为一个既存交易的一部份，最平常的方式是COM runtime基於物件异动属性的设定，以及物件建立者的交易状态，然後将目前交易的资讯复制到物件的context中。举例来说，物件若标示为必需的（Required），当它接收到物件建立者的method call时，若建立者已为某个交易的一部份，此时将会从呼叫者的context把交易的资讯复制到自己的context中。换句话说，它将会加入交易之中。</span><span id=Layer88></font></p><p><font size=2 color=#3c3c3c face=arial>允许下载程式码可能会产生非预期的边际效应</span><span id=Layer89></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>允许下载程式码可能会产生非预期的边际效应</span><span id=Layer90></font></p><hr><p><font size=2 color=#3c3c3c face=arial>不过，假设客户端希望建立一个COM物件，同样也希望明确地让这个物件成为既存交易的一部份，而不要依赖於COM runtime所提供的自动交易处理机制。为了让此目的得以实现，Window 2000中包含一个服务，称为Bring Your Own Transaction （BYOT）。客户端可以藉由建立一个系统提供的物件，称BYOT物件来使用它。然後呼叫这个物件的QueryInterface取得ICreateWithTransaction或ICreateWithTIPTransaction介面的指标。这些介面都只有提供一个单一的method，CreateInstance。当客户端呼叫上述任一个介面的method时，它将会传递欲建立的物件之CLSID，物件欲回传的第一个介面之介面识别码（IID），以及一个指向既存的DTC或Transaction Internet Protocol （TIP）交易的参考（reference）。COM runtime建立物件，然後修改物件context内的交易资讯，并使此物件成为特定交易的一部份。</span><span id=Layer91></font></p><p><font size=2 color=#3c3c3c face=arial>物件通常透过COM runtime加入交易之中</span><span id=Layer92></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>物件通常透过COM runtime加入交易之中</span><span id=Layer93></font></p><hr><p><font size=2 color=#3c3c3c face=arial>到底为什麽要这样做呢？为何不正确地设定这个新物件的异动属性，让这个新物件以平常的方式自动地加入既存的交易中呢？其中一种可能性是你希望将物件加入交易管理者（transaction manager）启动的交易之中，而不是由支援OLE Transaction的DTC所启动的交易之中。即使此时没有这些交易管理者，但可能性仍旧存在。另一个例子是选择在COM+之外启动一个交易（或者是为了与旧有的程式码整合），然後需要在交易中包含一个COM物件。若没有类似BYOT的东西存在，就无法使其成为可能。或者说，一家厂商希望在Windows 2000的交易（由DTC控管）与其它的交易协调者之间建立一个闸道。因为建立这类的产品并非一件易事，BYOT使其成为可能。你可以说BYOT并不是一个广泛使用的技术，不过在某些情况下，它是必要的。</span><span id=Layer94></font></p><p><font size=2 color=#3c3c3c face=arial>BYOT允许你明确地指定物件建立时欲加入哪一个交易</span><span id=Layer95></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>BYOT允许你明确地指定物件建立时欲加入哪一个交易</span><span id=Layer96></font></p><hr><font color=#3e72d7 face=arial size=4><b>COM+事件</span><span id=Layer97></b></font><p><font size=2 color=#3c3c3c face=arial>假设你要撰写一个或多个COM物件，在某些事件发生时欲采取特定的行动。举例来说，想像一下QwickBank银行若发生处理某张支票而造成某些帐户透支时，会发生什麽事。QwickBank系统中某个COM物件可能会回应这个事件，并传送一封邮件给顾客，通知发生透支的情况。另一个物件可能会在资料库中写入一笔记录，以维护透支的资料。而第叁个物件可能会检查这个顾客最近发生了多少透支的情况，或许将此顾客标示为问题客户。重点是需接收某些事件，并由许多物件来处理这个事件。</span><span id=Layer98></font></p><p><font size=2 color=#3c3c3c face=arial>允许不同的元件学习一个特定的事件，然後让每个物件以自己的方式来处理之，似乎俨然成为软体系统中习以为常的样式。通常称之为公告（publish）与订阅（subscribe），这个范例出现在许多应用程式之中。这样的结果让许多软体开发者建立自订的系统，以提供这类的服务。对程式设计师来说，以不同的方法来处理相同的问题并不具任何意义。较好的解决方法是让作业系统提供一个标准的机制来接收事件，订阅事件，以便让大量的应用程式使用。在Windows 2000中，这个服务是由COM+事件所提供的。</span><span id=Layer99></font></p><p><font size=2 color=#3c3c3c face=arial>COM+事件提供一个发行与订阅的服务</span><span id=Layer100></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM+事件提供一个发行与订阅的服务</span><span id=Layer101></font></p><hr><p><font size=2 color=#3c3c3c face=arial>因为COM+事件是以 COM为基础，每个可传送的事件便以一个method来表示。换句话说，传送一个事件到一个COM 物件真正的意义，便是呼叫此物件某个介面上的method。事件的传送者就称之为发行者（publisher），而接收事件的COM物件就称为订阅者（subscriber）。一个事件可以有很多的订阅者，因此当一个发行者呼叫了代表这个事件的method（有时称为触发事件）後，一或多个订阅者就会接收到method的呼叫。因为这样的缘故，COM+事件所能使用的method只可以使用[in]参数，它们无法从接收事件的物件回传任何结果。因为相同的事件可以传送给多个订阅者，回传结果并不具有任何意义。同样地，一个拥有多个订阅者的事件可以以任何顺序传递到这些订阅者身上。事实上，每回事件传递时顺序可能会改变，COM+事件并不做任何的保证。</span><span id=Layer102></font></p><p><font size=2 color=#3c3c3c face=arial>发行者(Publi-sher) 呼叫method以传送事件到订阅者(subscri-ber)</span><span id=Layer103></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>发行者(Publi-sher) 呼叫method以传送事件到订阅者(subscri-ber)</span><span id=Layer104></font></p><hr><p><font size=2 color=#3c3c3c face=arial>为了要控制欲接收的各种事件，物件可以在事件储存体（event store）建立一或多个订阅项目（subscription）。事件储存体是COM+目录的一部份，这些订阅项目可使用元件服务管理工具建立。若要传送一个事件，发行者依赖一个EventClass物件。使用COM+事件的程式设计师同样也可以建立筛选标准（filter）来控制欲传送哪些事件。下面的章节将描述者些概念。</span><span id=Layer105></font></p><p><font size=2 color=#3c3c3c face=arial>COM同样提供Connection Points，一个让元件传送事件到另一个元件的简单方式。通常用在ActiveX控制项与其它的技术上。这个机制依赖於标准的IConnectionPoint与IConnectionPointContainer介面。Connection Points需要事件的发行者与接收者在事件传送时同时执行，同样的，它也有其它的需求以便将发行者与接收者系结在一起。这种机制就是所谓的紧密结合事件（tightly-coupled event）。COM+事件并没有这些需求，事件的发行者与接收者的结合度不须这麽高，称为松散结合事件（loosely-coupled event）。</span><span id=Layer106></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>COM同样提供Connection Points，一个让元件传送事件到另一个元件的简单方式。通常用在ActiveX控制项与其它的技术上。这个机制依赖於标准的IConnectionPoint与IConnectionPointContainer介面。Connection Points需要事件的发行者与接收者在事件传送时同时执行，同样的，它也有其它的需求以便将发行者与接收者系结在一起。这种机制就是所谓的紧密结合事件（tightly-coupled event）。COM+事件并没有这些需求，事件的发行者与接收者的结合度不须这麽高，称为松散结合事件（loosely-coupled event）。</span><span id=Layer107></font></p><hr><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 事件类别</span><span id=Layer108> </b></font>（</span><span id=Layer109><font size=2 face=arial color=#3e80d7><b> Event Class</span><span id=Layer110> </b></font>） 若要传送事件，发行者必需在COM+事件中注册一个适当的EventClass。一个EventClass可使用元件服务管理工具进行注册，可以以透过程式使用标准的介面进行注册。每个EventClass都必需拥有一个CLSID与一个ProgID，允许客户端建立这个类别的实例，每个类别也需具备型态程式库描述此类别支援的介面与method。这些method就是使用此特定EventClass来传送的事件。</span><span id=Layer111></font></p><p><font size=2 color=#3c3c3c face=arial>一个Event-Class将一或多个事件结合在一起</span><span id=Layer112></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>一个Event-Class将一或多个事件结合在一起</span><span id=Layer113></font></p><hr><p><font size=2 color=#3c3c3c face=arial>不过，EventClass唯一不需要的便是使用者自行撰写的程式码。使用COM+事件的程式设计师从来就不需要真正去实作一个EventClass。取代的作法是，一旦EventClass注册後，发行者便可以呼叫CoCreateInstance，传入此类别的CLSID建立实例（或者使用一个适当的Visual Basic函数传入这个类别的ProgID）。因为已提供这个类别的型态程式库，COM+事件系统便能够建立这个显露出适当介面与method的物件。</span><span id=Layer114></font></p><p><font size=2 color=#3c3c3c face=arial>程式设计师不须为Event-Class物件撰写程式码</span><span id=Layer115></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>程式设计师不须为Event-Class物件撰写程式码</span><span id=Layer116></font></p><hr><p><font size=2 color=#3c3c3c face=arial>发行者并不需要为EventClass撰写任何的程式码，因为每个EventClass物件所做的事都相同。发行者呼叫EventClass物件某个介面上适当的method以便传送一个事件。为了回应这个事件，这个物件传递这个事件到每一个订阅者（透过呼叫在订阅者上实作介面之method来达成这个目的。）这些method呼叫的方式就像一般的COM method一样，你可以使用COM标准的RPC呼叫机制，或使用COM+伫列元件。无论如何，工作结束後，订阅者将会接收到令人感兴趣的事件。</span><span id=Layer117></font></p><p><font size=2 color=#3c3c3c face=arial>当一个发行者呼叫Event-Class物件上的method，这个物件便会呼叫实作在订阅者上对应的method</span><span id=Layer118></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>当一个发行者呼叫Event-Class物件上的method，这个物件便会呼叫实作在订阅者上对应的method</span><span id=Layer119></font></p><hr><p><font size=2 color=#3c3c3c face=arial>如果你希望的话，建立发行者（publisher）的程式设计师可以实作发行者筛选标准。这个选项可让发行者干预特定的EventClass物件传送的每个事件。发行者很可能需要这样做，举例来说，若一个特定的事件永远都需要以特定的顺序来传送，或者发行者希望验证每一个订阅者是否拥有接收这个事件的权限，或者为了其它的理由。发行者筛选标准需要额外的作业，不过对於某些类型的应用程式来说这是很有用的。</span><span id=Layer120></font></p><p><font size=2 color=#3c3c3c face=arial>发行者可以在传送事件之前进行筛选</span><span id=Layer121></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>发行者可以在传送事件之前进行筛选</span><span id=Layer122></font></p><hr><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 订阅</span><span id=Layer123> </b></font>（</span><span id=Layer124><font size=2 face=arial color=#3e80d7><b> Subscription</span><span id=Layer125> </b></font>） 类似一个EventClass物件，一个订阅的动作可以透过管理工具或者透过一个执行的物件来设定。然而设定完成後，每个订阅项目可辨视订阅者，列出订阅者感兴趣的事件清单，并参考到发出事件的发行者与EventClass。一个订阅项目也可以指明订阅者希望接收到特定介面发送出来的任何事件。</span><span id=Layer126></font></p><p><font size=2 color=#3c3c3c face=arial>订阅项目将发行者与订阅者关联在一起</span><span id=Layer127></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>订阅项目将发行者与订阅者关联在一起</span><span id=Layer128></font></p><hr><p><font size=2 color=#3c3c3c face=arial>订阅有很多种类型。就如名称所暗示，永久订阅（Persistent subscription）储存在硬碟上，在系统故障时还能保留下来。你可以透过管理人员手动设定或者透过执行的物件设定，同时也允许你使用CLSID或Moniker（Moniker是一个标准的COM机制，用来为一个特定类别的实例命名。）来为订阅者命名。当传送一个永久订阅事件时，EventClass物件将会建立适当类别的实例，然後呼叫这个事件的method。</span><span id=Layer129></font></p><p><font size=2 color=#3c3c3c face=arial>永久订阅会建立一个物件以接收事件</span><span id=Layer130></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>永久订阅会建立一个物件以接收事件</span><span id=Layer131></font></p><hr><p><font size=2 color=#3c3c3c face=arial>与永久订阅不同的是暂时订阅（transient subscription）。暂时订阅只能透过执行的物件建立，在系统故障时就不存在了。它并不使用CLSID或Moniker来辨识订阅者，建立暂时订阅的物件会在事件储存体上新增一个介面指标指向自己。当一个EventClass物件传送这类型的订阅时，它便使用这个指标找到目标的订阅者。虽然永久订阅会导致EventClass物件建立一个订阅类别的新实例，但对暂时订阅来说就不是这麽一回事了。因为建立订阅的实例仍旧在执行的缘故，所以暂时订阅并不需要建立一个新实例来接收这个事件。</span><span id=Layer132></font></p><p><font size=2 color=#3c3c3c face=arial>暂时订阅会传送一个事件到一个执行中的物件</span><span id=Layer133></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>暂时订阅会传送一个事件到一个执行中的物件</span><span id=Layer134></font></p><hr><p><font size=2 color=#3c3c3c face=arial>订阅也可以包含筛选条件。举例来说，假设QwickBank支票处理系统中一个特定的物件只希望观察特定顾客的透支的情况。为了达到这个目的，它在订阅中加入测试透支情况的逻辑，如CustomerNumber = 7498，并可使用AND、OR与NOT进行多重条件的测试。只有满足这些条件的事件才会传送到这个物件。</span><span id=Layer135></font></p><p><font size=2 color=#3c3c3c face=arial>订阅可以指定筛选标准</span><span id=Layer136></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>订阅可以指定筛选标准</span><span id=Layer137></font></p><hr><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 使用COM+事件</span><span id=Layer138> </b></font>为了要 清COM+事件系统运作的情形，透过一个范例来解释是需要的。如图8-26所示，程序开始於一个使用者或一个执行的行程注册一个EventClass。一旦注册完成，便可以建立关联到EventClass 的订阅（虽然在EventClass 存在之前也可能建立订阅）。在这个范例中，这些订阅是永久的，每一个订阅者可透过CLSID识别。当发行者希望传送这些事件的其中一个时，它会先建立一个EventClass物件的实例。一旦实例存在後，这个物件将会检视事件储存体（event store）判断它的属性，以及事件的订阅者是谁，并将这些资讯储存在记忆体，以便在必要时能快速地存取。</span><span id=Layer139></font></p><br><center><a target=_new href=imagesh/8-26.gif><img border=0 src='imagesl/8-26.gif'></a></center></span><span id=Layer140><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图8-26</span><span id=Layer141> </b></font>一旦EventClass注册并建立订阅後，发行者便可以传送事件。</span><span id=Layer142></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>若要传送一个事件，发行者便呼叫EventClass 物件上对应的method，如图8-27中步骤五所示。在这个范例中，事件以介面X上的OverDraft method来表示。当它接收到这个呼叫时，EventClass物件便建立两个订阅这个事件的类别之实例，如步骤六中显示，然後个别呼叫这些物件的X::OverDraft，如步骤七。若这个事件拥有任何暂时订阅，则EventClass物件便采取替代方案，呼叫正在执行的订阅者之X::OverDraft，使用订阅者储存的介面指标来找到它。</span><span id=Layer143></font></p><br><center><a target=_new href=imagesh/8-27.gif><img border=0 src='imagesl/8-27.gif'></a></center></span><span id=Layer144><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图8-27</span><span id=Layer145> </b></font>EventClass物件可以建立订阅者，然後透过呼叫适当的method来传送事件</span><span id=Layer146></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>COM+事件对许多应用程式来说可能是个很有用的工具。事实上，它是使用某些内建在Windows 2000中的服务。如果你需要这类的服务，则使用标准及支援的开发技术是很有意义的。那麽为何要重新建造已经存在的东西呢？</span><span id=Layer147></font></p><font color=#3e72d7 face=arial size=4><b>元件负载平衡（Component Load Balancing）</span><span id=Layer148></b></font><p><font size=2 color=#3c3c3c face=arial>COM+其中一个主要的目标，便是允许程式设计师建立可延展的应用程式。其中一个可让应用程式广受使用者支援的方法便是将应用程式分散在多台机器上，分享这些使用者建立的处理负载。在叁层式的情节中，也是COM+应用程式最常见的方案便是客户端将可以在多台机器上建立并存取应用程式的物件。</span><span id=Layer149></font></p><p><font size=2 color=#3c3c3c face=arial>跨多台伺服器机器分散客户端要求能让应用程式更具延展性</span><span id=Layer150></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>跨多台伺服器机器分散客户端要求能让应用程式更具延展性</span><span id=Layer151></font></p><hr><p><font size=2 color=#3c3c3c face=arial>为了要尽可能提升效率，我们将均衡地将这些物件分散到多台伺服器系统上。客户端发出的要求是无法预期的，通常没有办法事先得知哪个客户端何时需要这些服务。手动地将客户端的要求分散到伺服器并不是有效分散负载的方式。虽然这类静态的组态设定仍旧可以运作，不过它只是个次等的解决方案。</span><span id=Layer152></font></p><p><font size=2 color=#3c3c3c face=arial>较好的解决方案是动态地将客户端的要求分散到可用的伺服器机器上。如此将允许你选择最适合来处理这个要求的机器，如选择目前最闲的机器。这一类的动态负载平衡才是元件负载平衡（Component Load Balancing，CLB）的精神所在。如图8-28中展示，客户端使用CLB发行一个标准的CoCreateInstance要求到一个远端系统。不过使用CLB後，所有的客户端会将要求直接导引到一台Windows 2000电脑上。称做CLB伺服器。这个系统将会追踪在特定的CLB丛集中所有机器目前的负载情形。当它接收到来自客户端建立物件的要求时，CLB伺服器判断CLB丛集中最适用的机器，然後将要求转送到此机器上。接着这个系统建立所要求的类别之实例，同时便以平常的方式回传一个或多个指向这个新物件的介面指标到客户端。截至目前为止，客户端直接呼叫物件上的method，CLB伺服器不再牵涉在其中。</span><span id=Layer153></font></p><p><font size=2 color=#3c3c3c face=arial>元件负载平衡动态平衡客户端建立物件的要求到一群伺服器上</span><span id=Layer154></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>元件负载平衡动态平衡客户端建立物件的要求到一群伺服器上</span><span id=Layer155></font></p><hr><p><font size=2 color=#3c3c3c face=arial>CLB负载平衡仅是建立要求，它并不会牵涉到JIT启动。这代表的涵意是某些客户端将从中获得一些好处。举例来说，在本章电话中心的范例中，我指出客户端可能会在早晨建立一个物件，然後在这天中重复地使用。在每个交易後，物件便闲置（deactivate）了，然後在发行下一个呼叫之前重新建立。在这个情况下，CLB可能会牵涉到判断物件一开始会在哪一台机器上建立，此物件在这一整天会存活在哪一台机器上，而不会有任何负载平衡的情况发生。</span><span id=Layer156></font></p><p><font size=2 color=#3c3c3c face=arial>负载平衡与JIT启动无关</span><span id=Layer157></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>负载平衡与JIT启动无关</span><span id=Layer158></font></p><hr><br><center><a target=_new href=imagesh/8-28.gif><img border=0 src='imagesl/8-28.gif'></a></center></span><span id=Layer159><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图8-28</span><span id=Layer160> </b></font>一个客户端对CLB伺服器的CoCreateInstance要求将会被导向CLB丛集中最闲的伺服器</span><span id=Layer161></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>想像一下，若客户端是一个ASP script而不是一个DCOM客户端。ASP script每回使用呼叫的物件後通常会将物件摧毁。现在浏览器所发出的每个要求都会导致ASP发行一个建立物件的要求，这代表的涵意是每次都会使用到CLB。重点是，这项技术是否有用，部份依赖於应用程式是如何架构的。</span><span id=Layer162></font></p><p><font size=2 color=#3c3c3c face=arial>就像本章所描述的其它特性一样，只有已设定元件才能使用CLB，已设定元件是COM+应用程式的一部份。并非COM+应用程式中所有的元件都需要标示成Load Balanced，不过这些元件将获得下面的好处：在最不忙碌的机器上建立物件。为了要判断哪一台机器最不忙碌，CLB伺服器追纵每台机器回应到这些要求的时间长短。哪台机器回应的最快，就代表它的CPU周期最可用，也代表它的负载最轻。在这些回应时间更改时，CLB伺服器继续调整它的记录指明哪一台机器最不忙碌。</span><span id=Layer163></font></p><p><font size=2 color=#3c3c3c face=arial>CLB仅能和已设定元件一起使用</span><span id=Layer164></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>CLB仅能和已设定元件一起使用</span><span id=Layer165></font></p><hr><p><font size=2 color=#3c3c3c face=arial>就如同本章开宗明义地阐明，CLB并没有在Windows 2000正式版中发行。在这个技术的预览版本可用时，CLB的完整版本成为另一个产品的一部份，将在Windows 2000正式产品发行数月後出货。这个产品将会包含许多工具以管理分散式、进行负载平衡的环境，以及包含在Windows 2000中CLB技术的加强版本。在这些加强功能中，主要强调在CLB用来测量CLB丛集中伺服器负载的能力。</span><span id=Layer166></font></p><p><font size=2 color=#3c3c3c face=arial>CLB将在Windows 2000技术预览版本中可用</span><span id=Layer167></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>CLB将在Windows 2000技术预览版本中可用</span><span id=Layer168></font></p><hr><p><font size=2 color=#3c3c3c face=arial>虽然CLB并不包含在内，但在这个章节中描述的许多服务一开始都是由MTS所提供的，将MTS提供的这些功能与标准的COM runtime合并，Windows 2000提供更为一致、更合理的方式实作这些服务。这使得COM+别具一番意义，因为Windows中的COM实际上就是COM再加上一些额外的服务。新版本的变动为COM带来的好处是功能更强大，且更容易使用。</span><span id=Layer169></font></p><p><font size=2 color=#3c3c3c face=arial>COM+就是COM再加上一些额外的服务</span><span id=Layer170></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM+就是COM再加上一些额外的服务</span><span id=Layer171></font></p><hr><p><font size=2 color=#3c3c3c face=arial>元件负载平衡的功能将在Microsoft今年将要推出的新产品 Application Center Server 2000中出现。可让你透过一致的管理介面动态地新增伺服器到丛集中以分散元件建立的负载工作，增加系统的延展性。此外它还可进行Web应用程式的部署，Web应用程式变动时能够自动同步丛集中的伺服器，以及提供监控工具。</span><span id=Layer172></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>元件负载平衡的功能将在Microsoft今年将要推出的新产品 Application Center Server 2000中出现。可让你透过一致的管理介面动态地新增伺服器到丛集中以分散元件建立的负载工作，增加系统的延展性。此外它还可进行Web应用程式的部署，Web应用程式变动时能够自动同步丛集中的伺服器，以及提供监控工具。</span>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -