一直以来我梦想有这样一个东西，帮助.Net Team选择合适的企业应用软件架构，并且能够轻松解决企业级应用的基础问题。由于新的技术以及新的企业级应用方式的发展，我在原有文章中设想的方式已经有些落伍，所以这几个月来我一直在研究SOA的实现问题，以及IOC和AOP的实现问题，并且对Java EE的EJB 3.0容器规范和JMS,JCA等等规范进行了研究，尤其是微软的WCF给我了很大的启发。我想只有把一些关键技术问题解决了，我才能正式开始emissary的设计工作，因为我想让它开始就具备健壮.Net应用服务的基础，而不想草草从事。
不过我还是可以放出现在的一些想法：
1)对于虚拟运行时（运行在.Net CLR上的“虚拟运行时”，不是真正的运行时，只是起个形象的名字，呵呵,只是为了给App Server提供基础运行环境的基础类库），应该具备完备的对象池机制-能够在对象不被使用时自动钝化，并在请求到来时随便从池中取得一个相符对象提供服务。能够将正在运行的对象暂时钝化（由于客户端远程调用一个方法时产生了堵塞，这种情况及有可能），如果再次被激活，那么对象会从上一次的操作位置恢复并继续执行。除了有强壮的池，更应该有对象生命周期的回调机制，能够让虚拟运行时监视对象运行情况，开发人员能够重载服务回调方法并控制对象的初始化以及销毁的实现，并且在一个对象抛出异常的时候，能够自动判断异常的原因，并试图从池中再取出一个对象接续服务，此接续服务基于对原有对象的调用信息以及状态值得保护以及传递给新继续对象而实现，对于客户端而言它们根本不知道后面发生了什么，除非虚拟运行时认定抛出的异常是一个系统级的没有办法恢复的，才会以一个统一的异常FaultException抛出给客户端，这样作的目的会使客户端对服务器端的细节知之甚少。如果需要由开发人员控制服务回调，应该不会在业务类本身开发任何代码，这样就防止侵入式所带来的问题，事实上我并不想业务类上面出现任何和![]()
业务类上面出现任何和Application Server有关的东西，以便能够保持较高移植性和好的单元测试支持。虚拟运行时还能够根据影射关系自动利用IOC装备对象（将依赖的对象全部自动注入）并自动根据配置信息增强对象能力（AOP）-如需要日志支持等.
2）无论如何没有任何客户端能够直接访问业务对象，只有App Server自己可以，利用Emit自动生成服务器端业务代理对象，并且对客户端是完全透明的，这个代理并自动集成虚拟运行时提供的服务并且提供自动加载事务和安全配置，最直接的改进是能够自动发布契约，此契约是与客户端通信的接口，契约包括：服务契约，数据契约，异常契约...，并且通过配置框架制定通讯协议的基本信息，称之为绑定，帮定于契约无关只影响通信问题,如果需要服务变成Web Service或者其他的什么服务,只要设定帮定就可以了，除此以外，代理在调用虚拟运行时提供服务并实例化一个业务对象时，能够根据业务类对应的配置信息将对象设置成：(1)按调用生成实例,也就是一个调用一个实例,并在调用生命周期结束时,自动销毁对象并释放非托管资源(2)单例生成模式,所有客户端共享一个对象实例(3)会话模式,一个客户端将对应一个服务对象. 业务对象能够利用一个辅助类调用App Server的服务(如:email,Ad-Naming等等),但业务对象本身不会看到任何与App Server有关的代码,那么这个辅助类被叫做影子对象,它的生命周期与业务对象等同,所有与服务环境相关的调用全部在影子类中,只是在运行时会被合并在一起,我叫它服务影子绑定关系,影子对象叫ServicedShadowShell.
至于数据层的实体类，开发人员只需要开发虚字段，如：public abstract string Name(),服务器虚拟运行时会自动生成代码并访问数据库，也就是说自动对ADO.Net进行包装。同时在使用实体类的时候会自动带上事务，保证数据同步，唯一的约束是虚字段的名称必须和数据库中的数据列名称对应，或者启用别名机制与别名对应。也可以开发特殊虚字段，此字段是一个复合字段（类），指定对别的实体的引用，可以形成One-Many,Many-Many,Many-One,One-One之类的关系，然后使用特殊字段可以进行关联查询。提供健全的面向对象查询语言，Entity-QL，可以像使用SQL一样的使用实体类进行查询和其他操作。为了增强实体类的能力，也提供影子支持。
对于以上，如果不需要分布式模式，可以在配置信息中指定关闭远程配置，App Server 自动成为本地模式-进入精简模式，本地客户端直接通过服务器代理（本地代理）调用服务，也就是说所有的东西在一个CLR上并关闭一与远程调用的支持，当然App Server也有一种叫作双模式的东西，自动判断客户端位置，并自动判断是使用全模式执行还是精简模式执行,更加灵活，也许您会看到这样的景象，一个业务服务对象，它不知道自己为什么服务，它只对调用负责，不对客户端负责，然后有个远程请求到来，它的代理就把它翻译成远程服务并传递客户端请求，请求处理完毕后，自己就回到池中，等了一回儿，又一个请求来了，但是是来自同一个CLR的，呵呵，代理自动将业务对象至于本地服务引擎中，并提供本地服务。也就是说一个对象在它的生命周期中有时候是远程服务有时候是本地服务，就像一个员工既可以在本公司工作也可以外派到其他公司工作一样。
3)对于客户端,不管是什么样子的客户端(ASP.Net,WPF Form,Windows Form,Console App,Web service, Applet,JSP,Servlet,POJO,EJB,..........),都能够调用远程服务,客户端不知道服务器用的是什么平台,唯一要作的就是用App Server提供的客户端部署工具生成一个相应的代理,如.Net的客户端会生成.dll文件,J2EE会生成jar包等等.
4)业务类开发时不需要开发人员知道应用服务器的细节,只要像开发一般类一样设计和开发它就可以了,同时让一个熟悉应用服务器API的人开发ServicedShadowShell，再让一个熟悉部署细节的家伙开发部署文件。
...一~二个月以后把上面描述的设计书放上来，届时还会继续讨论有关此服务器的问题.
不过我还是可以放出现在的一些想法：
1)对于虚拟运行时（运行在.Net CLR上的“虚拟运行时”，不是真正的运行时，只是起个形象的名字，呵呵,只是为了给App Server提供基础运行环境的基础类库），应该具备完备的对象池机制-能够在对象不被使用时自动钝化，并在请求到来时随便从池中取得一个相符对象提供服务。能够将正在运行的对象暂时钝化（由于客户端远程调用一个方法时产生了堵塞，这种情况及有可能），如果再次被激活，那么对象会从上一次的操作位置恢复并继续执行。除了有强壮的池，更应该有对象生命周期的回调机制，能够让虚拟运行时监视对象运行情况，开发人员能够重载服务回调方法并控制对象的初始化以及销毁的实现，并且在一个对象抛出异常的时候，能够自动判断异常的原因，并试图从池中再取出一个对象接续服务，此接续服务基于对原有对象的调用信息以及状态值得保护以及传递给新继续对象而实现，对于客户端而言它们根本不知道后面发生了什么，除非虚拟运行时认定抛出的异常是一个系统级的没有办法恢复的，才会以一个统一的异常FaultException抛出给客户端，这样作的目的会使客户端对服务器端的细节知之甚少。如果需要由开发人员控制服务回调，应该不会在业务类本身开发任何代码，这样就防止侵入式所带来的问题，事实上我并不想业务类上面出现任何和
2）无论如何没有任何客户端能够直接访问业务对象，只有App Server自己可以，利用Emit自动生成服务器端业务代理对象，并且对客户端是完全透明的，这个代理并自动集成虚拟运行时提供的服务并且提供自动加载事务和安全配置，最直接的改进是能够自动发布契约，此契约是与客户端通信的接口，契约包括：服务契约，数据契约，异常契约...，并且通过配置框架制定通讯协议的基本信息，称之为绑定，帮定于契约无关只影响通信问题,如果需要服务变成Web Service或者其他的什么服务,只要设定帮定就可以了，除此以外，代理在调用虚拟运行时提供服务并实例化一个业务对象时，能够根据业务类对应的配置信息将对象设置成：(1)按调用生成实例,也就是一个调用一个实例,并在调用生命周期结束时,自动销毁对象并释放非托管资源(2)单例生成模式,所有客户端共享一个对象实例(3)会话模式,一个客户端将对应一个服务对象. 业务对象能够利用一个辅助类调用App Server的服务(如:email,Ad-Naming等等),但业务对象本身不会看到任何与App Server有关的代码,那么这个辅助类被叫做影子对象,它的生命周期与业务对象等同,所有与服务环境相关的调用全部在影子类中,只是在运行时会被合并在一起,我叫它服务影子绑定关系,影子对象叫ServicedShadowShell.
至于数据层的实体类，开发人员只需要开发虚字段，如：public abstract string Name(),服务器虚拟运行时会自动生成代码并访问数据库，也就是说自动对ADO.Net进行包装。同时在使用实体类的时候会自动带上事务，保证数据同步，唯一的约束是虚字段的名称必须和数据库中的数据列名称对应，或者启用别名机制与别名对应。也可以开发特殊虚字段，此字段是一个复合字段（类），指定对别的实体的引用，可以形成One-Many,Many-Many,Many-One,One-One之类的关系，然后使用特殊字段可以进行关联查询。提供健全的面向对象查询语言，Entity-QL，可以像使用SQL一样的使用实体类进行查询和其他操作。为了增强实体类的能力，也提供影子支持。
对于以上，如果不需要分布式模式，可以在配置信息中指定关闭远程配置，App Server 自动成为本地模式-进入精简模式，本地客户端直接通过服务器代理（本地代理）调用服务，也就是说所有的东西在一个CLR上并关闭一与远程调用的支持，当然App Server也有一种叫作双模式的东西，自动判断客户端位置，并自动判断是使用全模式执行还是精简模式执行,更加灵活，也许您会看到这样的景象，一个业务服务对象，它不知道自己为什么服务，它只对调用负责，不对客户端负责，然后有个远程请求到来，它的代理就把它翻译成远程服务并传递客户端请求，请求处理完毕后，自己就回到池中，等了一回儿，又一个请求来了，但是是来自同一个CLR的，呵呵，代理自动将业务对象至于本地服务引擎中，并提供本地服务。也就是说一个对象在它的生命周期中有时候是远程服务有时候是本地服务，就像一个员工既可以在本公司工作也可以外派到其他公司工作一样。
3)对于客户端,不管是什么样子的客户端(ASP.Net,WPF Form,Windows Form,Console App,Web service, Applet,JSP,Servlet,POJO,EJB,..........),都能够调用远程服务,客户端不知道服务器用的是什么平台,唯一要作的就是用App Server提供的客户端部署工具生成一个相应的代理,如.Net的客户端会生成.dll文件,J2EE会生成jar包等等.
4)业务类开发时不需要开发人员知道应用服务器的细节,只要像开发一般类一样设计和开发它就可以了,同时让一个熟悉应用服务器API的人开发ServicedShadowShell，再让一个熟悉部署细节的家伙开发部署文件。
...一~二个月以后把上面描述的设计书放上来，届时还会继续讨论有关此服务器的问题.
