Emissary Application System Server(1)

现在正在一个J2EE项目上，对EJB进行了深入的研究，一直使用.Net的我终于发现EJB这种企业级组件的设计长处，当我需要设计一个业务组件时，只需要按照EJB规范写一个Bean(从SessionBean继承的普通Java类），然后在这个Bean中实现SessionBean接口中的回调方法和Home接口对应的ejbCreate方法，声明一个Home接口和Remote接口，最后使用部署工具将这个Bean部署到J2EE Application Server中去（Stub,EJBObject,部署描述符等等，全部由部署工具和容器产生，我只是开发了Bean而已,当然声明一个.Net Remoting对象更加简单），在使用时任何客户端都不允许直接访问Bean对象本身，而是通过Remote接口的容器所实现的EJBObject来间接访问Bean，这样EJBObject会自动拦截调用并让容器介入，容器会自动插入一些基础服务，如事务，安全上下文等等。感觉SUN这样的设计还是可以的。但是有些笨重，Bean必须从SeesionBean继承，这是一个侵入式的架构，个人感觉不是很好，因为我没有办法使用自己的继承体系，从应用层面来说，不是所有的应用都是分布式的，而EJB是一个分布式组件的解决方案，对于不是分布式的应用就显得性能等方面有些浪费。我也研究了Spring这样的解决方案，但是这个轻量级容器的.Net版本更像一个框架而不是一个实时的服务，虽然使用这样一个框架不会有太大问题，但是我总是希望有一个.Net Application Server即能提供企业级组件的基础服务，也能提供灵活的配置服务，开发人员只需要关注业务就成了，就像使用J2EE Application Server一样有益处。所以现在正在逐步构思设计一个健壮的.Net应用服务器，使它能够处理大部分基础问题，使得.Net开发人员更有效率地构建他们的系统..但是值得注意的是.Net Application Server绝对不会和J2EE Application Server设计得一样，因为.Net有自己的特点。

想造一个.Net Application Server,得先了解企业级应用需要什么基础服务和开发人员需要什么！我就从这里开始，我给我的.Net Application Server起个名字"emissary",全面基于.Net的Application Server.希望能够成为一个Remoting对象和Web Service的新寄主，但是我不想让它成为一个对象的主宰，对象应该快乐地活着，这意味着emissary虽然可以给与对象想要的一切，包括给它接生，但是这样的老板也不会阻挡一个对象跳槽，即使它跳槽的地方不会是一个.Net容器，也就是说emissary会让对象不会感觉到容器的存在，它也不知道客户是什么人，它的生活很简单，阳光、冰淇淋、比基尼，它都会轻松拥有，并且它可以不依赖emissary而活着，emissary会让Object团队有个家，然后各种客户通过他们的管家emissary来向它们提出业务要求，如果客户是有令牌的，管家会把请求转发给一位业务专家Object，客户也轻松了许多，因为他们不必知道这个业务专家Object的细节，有个管家帮他打理了。我作为emissary的设计者会考虑更多的事情，在最近的日子里搞出一个emissary的概念设计。我要把这个概念设计放上来，让大家提提意见，多多的意见。

以下是一个最基本的想法：
1)对于开发人员，应该能够轻松搞定业务类的部署，以.Net Dll为单位部署组件，.Net容器自动管理依赖关系，也就是说一旦发觉被部署的Dll还依赖别的Dll（自己开发的，或者第三方的），容器照样会自动将所有引用的Dll全部Copy到应用服务器的组件管理目录中（可能是应用服务器所在OS的GAC中）。要能够提供图形化的工具，这个工具能够和IDE紧密结合，能够快速部署一切。
2）开发时，对于一个实现具体业务的Class或一组Class，设计人员可以任意设计这些类的关系和模块的结构，诸如要使用设计模式之类的，容器只要求在部署的时候指明要发布哪些接口作为服务就成了，容器会自动将所有引用的对象纳入到管理序列之中。所以开发人员开发时不必考虑有没有.Net容器，只是部署的时候需要考虑如何写那个部署描述文件（其实也有个工具帮助来干这个活），部署时也可以让专门的部署人员来干！开发人员的日子越来越好了。
3）部署时，具备远程部署的能力，提供一个基于Web的部署工具，只要用IE就可以部署任何想要部署的一切，管理已经部署的一切。
4）容器应该能够自动记录日志。
5）开发人员能够制定容器要给部署的组件什么服务，提供图形化工具来执行这个任务。如果没有制定具体的服务，容器能够自动提供默认的服务，如在客户调用一个方法时容器所插入的安全和事务服务。
6）容器应该提供一个成熟的内存管理机制，让对象全部活在缓存中，即使是一个具有会话能力的对象，也能够将关联的会话信息保存在自身的其他地方，而自己可以回到池中，容器将设计两级缓冲池机制，当一个“十分活跃”的对象必须等待一个即将发生的调用之时，它必须呆在第一级池中，需要它的时候它可以非常快地复活并提供给客户服务，当是一个很少访问的对象时，由于我不敢保证谁还会在什么时候访问它，所以把它放到第二级池中，第二级池会把这些“不活跃于客户服务领域”的对象全部序列化保存在文件系统的一个固定地方，只要没有timeout,这些被钝化了的对象还会被保留，一旦客户很长时间没有理会他们，容器就会把他们杀掉，当然这里有个基本规则，那就是：对于在第一级池中的对象要先移到第二级池中，过一会再把他们枪毙，等于是“死缓”，对于第二级池对象，直接杀死，就是直接把序列化的对象从文件系统上直接删除，等于“斩立决”）。
“斩立决”的方式粗鲁了一些，因为如果一个资源连接还在怎么办？放心容器会管理一切。不过具体细节以后再说。
7）容器不会提供像J2EE中实体委托关系这样服务，理由很简单，不让开发者开发的类依赖于容器任何东西，它们是可以任意移植的。
还有很多idea(会形成原始需求吧），逐步细化中，项目计划正在考虑中。