【TechTarget中国原创】问：我有一些使用 J2EE的经验，现在我对弄清楚如何为.NET平台创建一个多层架构很感兴趣。例如，我如何从网络服务层到使用类似 RPC 这样的协议应用层/ 数据库层之间进行通信，然后返回这个处理结果到网络表示层(例如，像 JSP 这些的)。我从来没有使用过.NET但是现在必须使用这个框架来构建一个网络服务应用。那么，使用.NET框架来构建这种架构的选择方案是什么呢?
答：在 ASP.NET 运行环境中执行.NET Web服务。这些服务通过.asmx终端表现出来，这些终端都拥有被认为是(代码分离)code-behind的文件，该文件和Web服务的派生类相连接。这个派生类从本质上说就是 "这个服务" ，而且它的方法(标记为 [WebMethod] 属性)表示成为自动生成的 WSDL 规范的一部分。
作为边注，对于现在的大多数的典型平台，开发人员都使用构造类和方法的途径来生成 WSDL ，然而更好的途径应该是首先创建 WSDL 规范，然后把这些规范映射到处理加工的业务程序中。现在需要规范来约束开发人员使其遵循这一方法。
那些被Web服务对象封装的代码不应该包含任何的业务逻辑，而是应该遵从其他的可以调用内部过程和外部过程来完成任务的.NET组件，这个任务需要完成:执行请求服务方法，并且返回一个应答(如果不只是一种方法的话)。这通常就是指，需要使用某种形式的faCade (fa?ade: 设计模式之外观模式:为子系统中的一组接口提供一个一致的界面)层来完成从服务类中抽象出所有的业务逻辑和设计调用以实现重用业务逻辑部组件这两个任务(见图1)。
如果你是依据逻辑上的可分配的服务来设计你的业务逻辑的话，那么你应该以一个独立功能集合的联合作为终结，这个功能集合包括:入口点组件，一个或更多的附加支持组件，和某种形式的输出或数据存储。 例如，在图1中，你可以看到应用服务层有3个入口点服务:服务A、B和C。设想服务C是一个日志记录服务，它只是简单记录下Web服务需求“发生了”;服务B是处理实际请求过程的服务，它从数据库中获得数据并且可能导入一些业务信息到数据库中;服务A是一组由信息传递和文件IO服务组成的集合，这些服务处理生成输出文件，该输出文件就像是一个从Web服务请求中生成的PDF或者邮件。每一个这样的业务服务都可以独立存在，并且可以分布到你所需要的任何一层，或者完全在Web服务层上执行，这取决于你的“可伸缩性”需求。
因此，对于你的问题，如何在各个层之间分布组件并调用它们呢?假设你的系统是为重用和分布式而设计的，那么你可以选择企业服务，远程服务或者Web服务(这是三种典型的选择)。
1.如果你想转移到未来技术，例如Indigo，那么企业服务是最好的途径，因为企业服务的程序设计模型将跟随这一路线。这就是说，注册服务A组件(举例说明)作为一个使用COM+的服务组件的话，就意味着A组件会以二进制串行化信息传递格式在DCOM之上被调用。这样做的绝妙之处在于你可以作用于COM+来处理对象合并，加密，权限服务，运行时同一性服务以及分布式事务处理。推荐一个相关资源:Juval Lowy著的《COM 和.NET 组件服务》。
2.下面是一些原因说明为什么企业服务对你而言可能不是一个选择。一个原因可能在于系统调用的限制，该系统调用阻止使用COM+服务和MSMQ。这通常是廉价的主机域(你作为每月十美元的服务提供者所处的困境)或者因为公司强加这些限制(有些时候没有理由，有些时候理由很充分)这些情况下的议题。远程服务对于这些情况而言是一个很好的选择，因为它完全是采用手工操作来解决对于跨越程序边界来调用对象的情况。当然，这意味着你需要自己操作验证，加密，运行时身份扮演，对象合并，但是在这没有提供对分布式事务处理的内部支持。推荐一个远程服务的相关资源:Ingo Rammer著的《高级.NET远程服务》。
3.最后，你可以在应用层所表示的业务服务之前声明Web服务。请注意，我之所以把它们称为业务“服务”是因为在权限范围内，它们确实是按“面向服务”系统设计这种方式设计的服务。系统中的每一个主要功能都应该以面向服务的方式设计，这样的话业务服务组件的分布式才能够实现，并且整个系统如何协作运行对使用者而言是透明的。除此之外，这些服务可以被其他的“系统”重用。
综上所述，业务服务的入口点可以通过远程调用技术，在1和2中所描述的;或者通过Web服务，如果该业务服务是a)由于它在防火墙之外进行重用，已经被表示出来了，或者b)如果该服务的输入是XML，而且你希望降低花费在分析外部的Web服务和业务服务二者上的开销。在防火墙的后面，在高速的TCP/UDP协议层上传输的二进制串行化要比在HTTP上传输的XML性能好。在将来发布的.NET框架(Indigo)版本中，串行化和协议选择这两个选项是天衣无缝的，然而现在它还只是一个需要在系统设计阶段考虑调度和调用模型的设计决策。