2009年4月27日星期一

Broker模式

Broker模式用于分布式系统,对系统中的各个组件解耦,协作,通信等。服务在Broker中注册自己,使得client可以通过它们提供的接口访问自己,client向Broker发送请求以访问服务提供的功能,Broker根据请求定位合适的服务器,然后将请求发送给它,并将结果和异常等信息返回。

我的理解,这个Broker模式就好比生意场中的代理人或者中间人,他负责联系买卖双方,通风报信,促成生意。也可以这么理解,Broker是一个中间层,它封装了各个服务的实现细节,client不必(估计也不想)知道服务的细节,只要给Broker发送请求,剩下的事情由它去办,这就使得client和server的耦合很松,整个系统的扩展性有了大的提高。

Broker模式包括六种主要的组件:clients,servers,brokers,bridges,client-side proxies和server-side proxies。

server实现某些功能并通过接口向外提供之。server的责任包括:实现服务,在本地的broker中注册自己,通过server端的proxy向client发送响应和异常信息。server的协作者包括server端的proxy和broker。

client的责任包括:实现用户的功能,通过客户端的proxy向server发送请求。它的协作者包括客户端的proxy和broker。

在文中用messenger描述broker,它是client和server之间通信的桥梁,它将client的请求发送给server,也将server的回应和异常发送给client。因此,broker必须通过某种方式实现唯一的标识,来分辨和定位数据的来源和目的地。它提供接口使得client和server都能在它那儿注册。其实这很好理解,因为只要这样,broker才能统领全局,了解所有已经存在的client和server。前段时间看了Android,现在想起来,它很可能也使用的这个模式,Android工程里的AndroidManifest.xml的功能应该就是这样,所有在工程添加的类,无论是Activity,service,还是broadcast receiver等等,都必须在AndroidManifest.xml中注册,否则应用不能实现相关的功能。我推测Android里应该专门有一个模块来管理AndroidManifest.xml,每当一个应用被按照进系统后,这个模块就检查AndroidManifest.xml,收集信息,将里面的类,服务,过滤器等等信息都收集后保存,这样当有Intent(特别的隐式的Intent)被抛出后,系统才能够定位相应的Activity或者service,否则系统是找不到的。

client端的proxy是client和broker之间的中间层,它封装系统指定的功能,例如client和broker之间的具体通信机制,内存块的分配和删除,参数和结果的排列等,可以这么说,client的proxy是一个打包器,将client的请求进行封包。而与之相对的是server端的proxy,就是一个拆包器了,同时将server的结果和异常信息打包发给client。

Bridge是一个可选组件,在Broker系统里,很可能是一个异构的系统,存在多个Broker,各个Broker之间如果要通信,就需要使用Bridge,它在各个Broker之间找出路由。

Broker模式分为两类:一类是没有broker,client端的proxy和server端的proxy之间直接通信,不用broker来中转通信,这类broker模式的好处是性能高,因为省去了一道中转,但是在两端的proxy之间需要使用同样的数据格式或者协议来传输。另一类就是有broker,两端的proxy使用不同协议或者数据格式不要紧,由broker来统一。

没有评论:

发表评论