不会先谈论部署的方式以及用户得作些什么，我之所以先说明这个问题，是因为部署的问题致关重要，但是我想把这个问题靠后一些谈论，并不是我偷懒，因为很多人一开始会对下列问题感兴趣：被用户（开发人员）已经部署好的对象是如何被外界（确切地说是被客户端程序）访问的，服务器如何确保访问的安全、高效、可拓展等等这些的问题。下面我看一下设计中涉及的问题，然后解决对应的问题：
|
问题
|
解决方案
|
|
1
直接访问对象不太好，因为会有潜在的安全性问题，因为任何“人”都可以访问对象（这里访问的含义是“调用一个方法”），而且，没有时机去插入一些对象想要的服务，如日志服务，如果有时机的话，我也不想让开发人员把业务逻辑无关的代码和实现业务逻辑的代码放在一起（我想您肯定有过这样的经验），也许会有人建议使用AOP，但是那样的话开发人员开发的类不得不使用一些“声明性编程”的办法，类又与某些框架有关系了，这样移植性不好！
|
设计一个“保镖”，“保镖”也是一个对象，它的生命会与业务对象的生命在一定条件下同期化，也就是说只要业务对象活着，“保镖”也会活着，但是也有例外，这个例外下一文章再解释。客户端程序（可能是任何客户端）直接访问“保镖”的客户端代理程序（相当于Remoting的透明代理，它知道如何处理网络协议），而“保镖”的客户端代理程序通过网络访问“保镖”对象，这时“保镖”会验证访问者的身份，一旦通过，服务会被插入（如何插入？具体细节下一文章考虑），并且将调用转发给实际干活的业务对象。这里的设计还很粗糙，但是可看到基本的下列好处：
“保镖”本身是一个符合Remoting规范的远程对象，也就是说它必须是可以串行化的，或者必须从MashalRefObject继承，它本身带有很多.Net框架中的东西，客户程序通过其透明代理与其通信（客户程序不会知道服务器提供的结构，它会认为它访问的就是业务对象本身），“保镖”会与实际的业务对象进行通信，这个业务对象不必是一个Remoting远程对象，只要和“保镖”在一个地方就成，这样开发人员就不必按照Remoting规范设计具体的业务对象了，业务类的设计完全与Remoting无关。这里给“保镖”起个名字-ECO（Enterprise Component Object）.顺便说一句，这个ECO是部署业务组件时由服务器生成的，不需要开发人员考虑它的细节。
|
|
对于上面这样的设计您可能会有如下问题，不过这些问题我在下一文章中给与答案：
1）ECO或者业务对象对象的生命周期如何管理，在它们的一生中发生了什么？
如：客户端如何创建与ECO的连接，在客户程序不在访问服务时，如何处置对象？如果与服务的交互是一个Session的一部分，服务体系结构如何令服务对象记录客户状态？(要利用Remoting基础设施了)
2）ECO的结构以及原理？
3）服务如何被插入的？对象需要什么服务？这些服务可以配置吗？
|
可能还会有很多问题，一定会有问题，请大家提一些意见或者需要解决的问题。