【IT168 技术文章】
采用非常好的实践和正确的架构，以确保共享服务的短期和长期内的成功
面向服务的架构（Service-OrientedArchitecture，SOA)在概念上是简单的，但是它的价值还不是很明显，在分布式企业中实现共享服务基础架构仍然十分困难。构建正确的架构和采用实现共享服务前景所需的非常好的实践可以使过渡变得容易，并有助于确保短期和长期内的成功。
让我们从更广的范围着手。企业需要建立公司级的非常好的实践，以用于构建成功的SOA。“OrganizationalandOperationalBestPractices”中描述了我们在企业内使用的企业级非常好的实践。此外，我们还有六个技术和架构方面的非常好的实践（请参阅“ABetterWaytoBuild”）。现在，让我们看看构建SOA时，企业和技术团队都应该考虑的一些主要的特性、设计注意事项和实现选择。
◆耦合
耦合是指两个软件（应用程序、组件、模块、方法和服务）之间的关系（相关性和依赖性）。耦合可以分类为紧密、松散和去耦三种。两种服务之间的耦合程度主要取决于两个因素：服务提供者的实现和调用，以及消费者对于如何查找和调用服务的了解。对于服务来说，位置和接口定义（包括数据类型定义）组成了耦合。处理不同版本的服务的耦合级别也是必要的。
在计算机或软件系统中，完全解除两个相关系统之间的耦合实际上是不可能的。只要一个系统在任何程度上依赖于其他系统的数据、功能、服务或连通性，那么解除耦合之后，这些系统就无法工作。
在松散耦合中，服务提供者使用一种标准定义语言定义和公布它的服务接口。接口定义服务消费者和服务提供者之间的调用契约。只要服务接口保持一致，就可以修改服务提供者的实现。
消费者对于服务提供者位置的了解也引入了耦合。如果两个服务需要交互，就不能解除它们之间的耦合，而且它们具有100％的位置依赖性。相反，如果消费者能够到达调用服务的确切位置，那么它在位置上是紧密耦合的。因为位置去耦是不可能的（在两个已知的实体之间是不可能的，但是在事件驱动的架构中是可能的），而位置的紧密耦合缺乏灵活性，所以需要一种介于二者之间的中间松散耦合。
位置的松散耦合可以通过使用诸如服务代理或目录服务这样的服务中介来实现。Webservices的松散耦合是通过使用用于服务定义的Webservices描述语言（WebServicesDescriptionLanguage，WSDL）；统一描述、发现和集成（UniversalDescription,Discovery,andIntegration，UDDI）；以及WebLogicIntegration服务代理/服务控制来实现的。
使用网络负载均衡器（硬件和软件）和/或WebLogic集群，您可以实现基于非策略的、基于简单位置的松散耦合，同时无需使用中介。只要WSDL中指定的服务端点是一种分布式名称服务（DNS），而不是一个IP地址，就可以使用标准的HTTP机制来重定向和代理Webservice请求。请求可以由位于任意数量的物理服务器（包括不同的数据中心）上的任意数量的端点提供服务。
◆绑定
选择的服务绑定方法——静态的、代理的还是动态的——决定了服务调用的灵活性和性能。
静态绑定假定服务定义和接口不会频繁变化。服务消费者和服务提供者之间的静态绑定紧密耦合了服务调用的两位参与者。
在代理绑定中，服务消费者发送其请求给服务代理，而代理将基于它对该服务的策略，请求路由到一个或多个服务提供者。在这种模式中，服务消费者无需了解服务提供者。
动态绑定假定服务定义和接口是频繁变化着的。动态绑定要求：对于每次调用，服务消费者都要联系一个服务目录或代理来请求服务定义。消费者基于服务代理返回的信息绑定到服务提供者。由于动态绑定要在执行查找之后进行绑定，所以性能不如静态绑定方法好。
至于选择动态的还是静态的绑定，这要取决于应用程序对于性能和灵活性的要求。Webservice定义的动态变化可以通过使用UDDI或Webservices管理（Webservicesmanagement，WSM）中介服务来实现。
◆粒度
消费者为了完成一项业务操作而对服务提供者进行的服务调用次数决定了服务的粒度。当需要进行许多服务调用时，服务提供者需要实现细粒度的服务。如果需要进行的服务调用只有一个或者很少，那么服务提供者就只需要实现粗粒度的服务。
服务调用的数量与每次调用期间传递的信息量有关。细粒度的服务很少使用本地的类型或对象参数，但是粗粒度的服务使用文档作为参数，参数中包含完成一个业务事务所需的所有数据。
粗粒度的服务可以通过组合或组装细粒度的服务来创建；可以通过使用像Tuxedo、EnterpriseJavaBeans（EJB）、servlet和JavaDatabaseConnectivity（JDBC）这样的方法进行创建；或者通过使用适配器、API或Webservices调用后端系统上的服务进行创建。将细粒度的服务组合成粗粒度的服务提供的优点和对应用程序使用SOA的优点相同。然而，这并不意味着把EJB中的每个方法都公开为Webservice；这是不必要的，而且可能是不正确的。例如，可以把EJB重用为WebLogicIntegration中的控件，或者使用EJB组合粗粒度的服务。把所有细粒度的服务变为Webservices，并通过一个服务接口访问这些服务可能会带来性能开销。
选择粗粒度的、面向文档的服务来满足高层次的业务过程需要。可以使用Webservices、J2EE组件或控件来实现细粒度的服务。粗粒度的服务应该尽可能地使用细粒度的服务进行组合，以便利用整体的服务优势。我们还建议把服务管理层应用于粗粒度和细粒度的服务。
◆调用
SOA支持两种服务调用模型：同步的和异步的（发布/订阅）。选择同步的还是异步的服务调用取决于服务提供者的可用性和性能大小以及消费者的需求。
当需要即时响应，而且消费者在预定的时间段内等待响应时，应该使用同步服务调用。想使这种模型获得成功，就应该把服务提供者实现为针对最大的请求负载实时做出响应。服务应该始终可用。因为同步模型被实现为处理预定的负载，它无法处理意外的、优先级更高的请求。需要把服务器设计为同时处理所有请求。如果服务提供者做出响应的速度开始变慢，它就不能接受其他消费者。这类特性可以通过服务管理策略或者使用服务器虚拟化技术来实现。
在异步模型中，消费者发送请求给服务器，并继续进行其他的处理。服务器完成服务之后马上返回响应，所需时间取决于服务器的负载情况。应该把服务器实现为对预期的最大请求数量进行排队，而且它不需要同时处理所有的服务请求。
如果预期会出现大量的服务请求，而服务器只能同时处理数量有限的服务，那么推荐使用异步服务调用。异步服务可以很容易地向上或向下扩展，只需调整请求的队列长度即可。
如果要求实时响应，那么显然要选择同步模型。然而，应该把系统实现为处理预定数量的服务请求。添加更多的服务器是向上扩展这种实现的惟一途径。
在大多数复合服务中，都涉及到大量的应用程序。在同步服务调用中，在许多应用程序之间确保请求/响应几乎是不可能的。在这种情况下，异步发布/订阅或者点对点的消息收发模型可以确保多个应用程序之间的消息和响应的交付。
异步服务调用模型最适合于高度可靠的、粗粒度的、面向文档的服务。同步服务调用更加适合于细粒度的、轻量级服务调用。异步消息收发的一个缺陷是：响应顺序可能与请求顺序不匹配。
WebLogic平台可以同时支持同步和异步服务调用模型。同步Webservice调用使用基于HTTP的简单对象访问协议（SimpleObjectAccessProtocol，SOAP），而异步模型则使用基于Java消息服务（JavaMessageService，JMS）的SOAP。WebLogicIntegration支持同步的、异步的和Webservice确认（WS-acknowledgement）服务调用模型。
◆共享/公用服务
SOA促进了重用、开发和操作逻辑与任务的划分，以及基于策略的计算。SOA的这些特性只能通过针对重用设计服务和客观化操作策略来实现。
对于多个应用程序有用的服务在被识别、实现和发布之后就能够被重用。可以通过发现通用的服务来识别可重用的服务，而且必须利用重用的特殊注意事项来实现可重用的服务。但是，避免重用和复制率的提高则取决于可用服务的共享信息，以及在企业内部是否鼓励重用。
为了使服务更加易于重用，不要嵌入特定于应用程序的策略，比如安全性（身份验证和授权），服务水平协议，服务质量（QoS）和审计信息。因为策略是跨应用程序通用的，应该在应用程序之外配置和应用策略。
WSM产品提供通用的或共享的基础架构来管理服务、策略配置和管理。为了充分体现SOA的优势，要使用适当的WSM基础架构。下面是共享服务的一些例子：
※ 共享的实用程序，比如安全和业务流程编排（跨公司）。
※ 资源管理，比如目录和代理。
※ 服务管理，比如自动配置、监控、QoS和版本管理。
※ 传输管理，比如可靠的消息收发、测量、路由和审计。
※ 集成/互操作性
针对互操作性、数据（通用数据模型、元数据管理）、语义和安全性建立企业SOA标准，以确保各种基于SOA的解决方案之间的集成和互操作性，这是很重要的。可以使用各种技术（J2EE或.NET）或者使用各家厂商推出的产品的组合来实现基于SOA的解决方案。因为SOA解决方案为了保持一致性和可重用性，通常是由专攻各自领域的分布群组进行构建，而由其他群组进行消费的，在上述群组中建立标准以确保它们之间的互操作性是必要的。您应该把遗留系统封装为服务，并采用面向服务的应用程序开发（Service-OrientedDevelopmentforApplications，SODA）。
基于SOA的解决方案开发使企业能够快速共享它们现有的遗留系统，具体方法是把这些遗留系统封装为服务，然后共享服务。SOA不要求使用服务接口来构建替代系统。“leaveandlayer”方法——通常，现有的系统首先被封装为服务，以便进行重用，然后被新的系统和服务替代——允许企业选择和建立有关如何使用一个服务层封装不同类型的系统的标准和指导方针。
SOA不排除企业应用程序集成（EAI）；SOA要求对后端系统进行集成。利用SOA原理进行集成（面向服务的集成[Service-OrientedIntegration,SOI]）允许企业实现灵活的、可重用的、标准的和共享的集成。我们刚刚讨论过的特性具有不同的实现选择。每个基于SOA的解决方案都要求经过仔细的分析后选择非常好的方法。希望这里给出的信息能够帮助您开始构建成功的SOA。
