您正在设计企业应用程序，并且需要能够通过网络使用其部分功能。此功能需要能够被各类系统使用，因此互操作性是设计的重要方面。除互操作性之外，可能还需要支持不同的通信协议，并适应多变的操作要求。
如何确保部分应用程序功能可为其他应用程序使用，同时确保分隔接口机制与应用逻辑？
设计应用程序时，必须考虑下列影响因素：
尽量将应用程序业务逻辑的负责元素与通信协议、数据转换和服务合约履行的负责元素分隔开来。这样即可推进问题分隔的总体设计目标。应用程序使用者可能希望响应根据特定使用方案进行优化。例如，有些使用者可能希望响应根据直接用户显示进行优化，而其他使用者可能希望响应根据软件处理进行优化。应用程序使用者可能希望使用不同技术与应用程序进行通信。例如，公司外部使用者可能希望通过 Internet 利用 SOAP 访问应用程序，而公司内部使用者则可能希望通过 .NET Remoting 处理访问应用程序。应用程序本身对不同使用者可能有不同的运行要求。例如，应用程序可能有这样的安全性要求，即授权公司内部使用者可以执行更新和删除操作，而公司外部使用者只 能得到授权执行只读操作。或者又如，不同的使用者可能需要来自应用程序的不同事务支持。对于一些客户端，特定事务的发生上下文并不重要，而其他客户端则可能需要精确控制事务上下文。然后根据需要，此上下文的句柄可能传递至应用程序的其他元素。如果业务逻辑更改与使用者和应用程序进行交互的所用机制是分隔的，则应用程序及时响应业务环境更改的能力将极大提高。例如，假设自定义构建组件中实现了一组特定业务逻辑，这组逻辑然后实现为打包解决方案的包装器，在理想情况下，这种情况不应影响应用程序使用者。将应用程序设计为软件服务集合，每个服务都有一个服务接口，应用程序使用者可以通过这些接口与该服务进行交互。
软件服务是不连续的应用逻辑单元，这些逻辑单元应当公开适合由其他应用程序访问的、基于消息的接口。[Microsoft02-2] 每个软件服务都有一个可供使用者使用的关联接口。此接口负责在服务使用者和服务提供者之间定义并实现合约。此合约及其关联实现称为服务接口。
图 1 显示了使用服务接口所供服务的服务网关。这两个元素间的协作由合约管理。
图 1:服务元素
如图 1 所示，Service Interface 提供了入口点，使用者可以使用此入口点访问应用程序所提供的功能。Service Interface 通常为网络可寻址，因此使用者可以通过特定类型通信网络对其进行访问。网络地址可以是众所周知的位置，也可以从服务目录（如 UDDI）获取。
设计服务接口的一个重要方面是将和其他系统通信所需的实现与应用程序业务逻辑分隔开来。服务接口提供了更粗粒度的接口，同时保留了应用程序逻辑的语义和细粒度。服务接口还提供了屏障，允许更改应用程序逻辑而不影响接口使用者。
服务接口用于实现使用者和提供者之间的合约。此合约使得它们即使在不同的系统上也能够交换信息。服务接口负责实现在执行这种通信时所需的所有细节。这些细节包括但不限于以下内容：
网络协议。服务接口应该封装使用者和服务通信时所使用的网络协议的所有方面。例如，假设某服务通过 TCP/IP 网络上的 HTTP 向使用者提供。您可以将该服务接口实现为 ASP.NET 组件，并将其发布到一个众所周知的 URL。ASP.NET 组件接收 HTTP 请求、提取服务处理请求时所需的信息、调用服务实现、对服务响应打包，然后将响应作为 HTTP 响应发送给使用者。从服务角度来看，唯一了解 HTTP 的组件是服务接口。服务实现有自己的、与服务接口通信的合约，并且不应当依赖于使用者用来与服务接口通信的技术细节。数据格式。服务接口负责对使用者数据格式和服务所希望的数据格式这二者进行相互转换。例如，在公司外部的使用者可能提供数据，并且希望答复数据采用符合行业标准 XML 架构的 XML 格式。公司内部的使用者可能想使用针对这种特殊服务进行了优化的 XML 格式。服务接口负责以服务可以使用的格式对两种数据格式进行转换和映射。服务实现完全不必知道服务接口可能用于与使用者通信的具体数据格式。安全性。服务接口应该被看作它自己的信任边界。不同的使用者可能有不同的安全性要求，因此应该由服务接口来实现这些使用者特定的要求。例如，公司外部使用者比公司内 部使用者通常具有更加严格的安全要求。外部使用者可能有很强的验证要求，并且可能只得到授权执行一些操作，这些操作只是授权给内部使用者的操作中的一个很有限的子集。内部使用者可能已经得到了显式信任，可以执行大多数的操作，只要求对于最敏感的操作进行授权。服务级别协议。服务接口在保证服务满足它向一组具体使用者所作的服务级别承诺方面起着非常重要的作用。服务接口可能会实现缓存，以缩短响应时间并减少带宽消耗。可以在一组有负荷平衡功能的处理节点上部署多个服务接口实例，以达到可伸缩性、可用性和故障容错的要求。一 般情况下，对于每个唯一的使用方案、技术堆栈、服务级别协议或操作要求来说，都需要一个服务接口。但是，您的应用程序支持的服务接口越多，构建和维护实现 时所涉及的工作也就越多。因此，您应该尝试将应用程序需要支持的服务接口数量减少到最低。例如，某个应用程序可能提供了两个用于访问其功能的服务接口。第 一个服务接口可能已针对公司外部使用者进行了优化。它可能指定了使用 SOAP over HTTP 通信技术的一组粗粒度请求和响应对，并且提出了非常严格的安全性要求。第二个服务接口可能已针对公司内部的使用者进行了优化。它指定的请求和响应对的数量 可能较多，而且它们不具有第一个服务接口中指定的请求和响应对那样的粗粒度，并且强调性能要求比安全要求更重要。
Service Interface 封装了提供服务的所有细节，并且将它与应用逻辑分隔开来。这种分隔使您能够将应用逻辑替换为模拟 [Mackinnon00] 实现。这些模拟实现会将真正的应用程序代码替换为模拟真实代码的模糊实现。使用模拟实现使您能够编写验证代码是否工作的测试，同时不必依赖于实际的应用程 序代码。您还可以扩展模拟实现以模拟错误情况，这些情况可能很难或者不可能使用真实代码进行模拟。
使用 Service Interface 模式会导致下面的优缺点：
优点
服务接口机制与应用逻辑分隔。这种分隔使您能够轻松地添加新的接口以及更改基础应用程序的实现，同时对使用者的影响最小。通过将服务接口代码与服务实现代码分隔开来，您就能够在不同层上部署这两部分代码，这样有可能提高解决方案的部署灵活性。缺点
很多平台使公开应用程序功能变得很简单。但是，这可能会导致作出粒度方面的错误决定。如果接口粒度太细，可能会导致最后必须很多次调用服务，才能执行特定操作。您需要对服务接口进行相应设计，使其适合网络通信或过程外通信。服务所提供的每个新增服务接口都会增加在更改服务所公开的功能时所需的工作量。Service Interface 模式增加了复杂性和性能开销，这对于很简单的面向服务的应用程序来说可能不是很合适。
转载于:https://www.cnblogs.com/ljf10223063/p/4669880.html
相关资源：ServiceInterfaceDemo