Loading...

当前位置:资讯中心主页 >站长资讯 >文章内容

  • 设计更好的 SOA
  • 来源：作者： 发布时间:2008-05-09 16:34:37

    • 域名注册

    • 域名惊喜价格 cn域名1元注册
    • com域名39.9元

      虚拟主机

    • 主机按月支付,低至19元/月
    • 超大流量,可开子站点

      VPS主机

    • 特惠VPS168元/月,4-8M独享带宽保证
    • 独立操作系统,无限开站点

    --采用最佳实践和正确的架构，以确保共享服务的短期和长期内的成功

    　　面向服务的架构（ Service-Oriented Architecture ， SOA) 在概念上是简单的，不过他的价值还不是非常明显，在分布式企业中实现共享服务基础架构仍然十分困难。构建正确的架构和采用实现共享服务前景所需的最佳实践能使过渡变得容易，并有助于确保短期和长期内的成功。

    　　让我们从更广的范围着手。企业需要建立公司级的最佳实践，以用于构建成功的 SOA 。“ Organizational and Operational Best Practices ”中描述了我们在企业内使用的企业级最佳实践。此外，我们更有六个技术和架构方面的最佳实践（请参阅“ A Better Way to Build ”）。目前，让我们看看构建 SOA 时，企业和技术团队都应该考虑的一些主要的特性、设计注意事项和实现选择。

    　　◆耦合

    　　耦合是指两个软件（应用程式、组件、模块、方法和服务）之间的关系（相关性和依赖性）。耦合能分类为紧密、松散和去耦三种。两种服务之间的耦合程度主要取决于两个因素：服务提供者的实现和调用，及消费者对于怎么查找和调用服务的了解。对于服务来说，位置和接口定义（包括数据类型定义）组成了耦合。处理不同版本的服务的耦合级别也是必要的。

    　　在计算机或软件系统中，完全解除两个相关系统之间的耦合实际上是不可能的。只要一个系统在所有程度上依赖于其他系统的数据、功能、服务或连通性，那么解除耦合之后，这些系统就无法工作。

    　　在松散耦合中，服务提供者使用一种标准定义语言定义和公开他的服务接口。接口定义服务消费者和服务提供者之间的调用契约。只要服务接口保持一致，就能修改服务提供者的实现。

    　　消费者对于服务提供者位置的了解也引入了耦合。如果两个服务需要交互，就不能解除他们之间的耦合，而且他们具有 100 ％的位置依赖性。相反，如果消费者能够到达调用服务的确切位置，那么他在位置上是紧密耦合的。因为位置去耦是不可能的（在两个已知的实体之间是不可能的，不过在事件驱动的架构中是可能的），而位置的紧密耦合缺乏灵活性，所以需要一种介于二者之间的中间松散耦合。

    　　位置的松散耦合能通过使用诸如服务代理或目录服务这样的服务中介来实现。 Web services 的松散耦合是通过使用用于服务定义的 Web services 描述语言（ Web Services Description Language ， WSDL ）；统一描述、发现和集成（ Universal Description, Discovery, and Integration ， UDDI ）；及 WebLogic Integration 服务代理 / 服务控制来实现的。

    　　使用网络负载均衡器（硬件和软件）和 / 或 WebLogic 集群，你能实现基于非策略的、基于简单位置的松散耦合，同时无需使用中介。只要 WSDL 中指定的服务端点是一种分布式名称服务（ DNS ），而不是个 IP 地址，就能使用标准的 HTTP 机制来重定向和代理 Web service 请求。请求能由位于任意数量的物理服务器（包括不同的数据中心）上的任意数量的端点提供服务。

    　　◆绑定

    　　选择的服务绑定方法??静态的、代理的还是动态的??决定了服务调用的灵活性和性能。

    　　静态绑定假定服务定义和接口不会频繁变化。服务消费者和服务提供者之间的静态绑定紧密耦合了服务调用的两位参和者。

    　　在代理绑定中，服务消费者发送其请求给服务代理，而代理将基于他对该服务的策略，请求路由到一个或多个服务提供者。在这种模式中，服务消费者无需了解服务提供者。

    　　动态绑定假定服务定义和接口是频繁变化着的。动态绑定需求：对于每次调用，服务消费者都要联系一个服务目录或代理来请求服务定义。消费者基于服务代理返回的信息绑定到服务提供者。由于动态绑定要在执行查找之后进行绑定，所以性能不如静态绑定方法好。

    　　至于选择动态的还是静态的绑定，这要取决于应用程式对于性能和灵活性的需求。 Web service 定义的动态变化能通过使用 UDDI 或 Web services 管理（ Web services management ， WSM ）中介服务来实现。

    　　◆粒度

    　　消费者为了完成一项业务操作而对服务提供者进行的服务调用次数决定了服务的粒度。当需要进行许多服务调用时，服务提供者需要实现细粒度的服务。如果需要进行的服务调用只有一个或非常少，那么服务提供者就只需要实现粗粒度的服务。

    　　服务调用的数量和每次调用期间传递的信息量有关。细粒度的服务非常少使用本地的类型或对象参数，不过粗粒度的服务使用文件作为参数，参数中包含完成一个业务事务所需的所有数据。

    　　粗粒度的服务能通过组合或组装细粒度的服务来创建；能通过使用像 Tuxedo 、 Enterprise JavaBeans （ EJB ）、 servlet 和 Java Database Connectivity （ JDBC ）这样的方法进行创建；或通过使用适配器、 API 或 Web services 调用后端系统上的服务进行创建。将细粒度的服务组合成粗粒度的服务提供的好处和对应用程式使用 SOA 的好处相同。然而，这并不意味着把 EJB 中的每个方法都公开为 Web service ； 这是不必要的，而且可能是不正确的。例如，能把 EJB 重用为 WebLogic Integration 中的控件，或使用 EJB 组合粗粒度的服务。把所有细粒度的服务变为 Web services ，并通过一个服务接口访问这些服务可能会带来性能开销。

    　　选择粗粒度的、面向文件的服务来满足高层次的业务过程需要。能使用 Web services 、 J2EE 组件或控件来实现细粒度的服务。粗粒度的服务应该尽可能地使用细粒度的服务进行组合，以便利用整体的服务优势。我们还建议把服务管理层应用于粗粒度和细粒度的服务。

    　　◆调用

    　　SOA 支持两种服务调用模型：同步的和异步的（发布 / 订阅）。选择同步的还是异步的服务调用取决于服务提供者的可用性和性能大小及消费者的需求。

    　　当需要即时响应，而且消费者在预定的时间段内等待响应时，应该使用同步服务调用。想使这种模型获得成功，就应该把服务提供者实现为针对最大的请求负载实时做出响应。服务应该始终可用。因为同步模型被实现为处理预定的负载，他无法处理意外的、优先级更高的请求。需要把服务器设计为同时处理所有请求。如果服务提供者做出响应的速度开始变慢，他就不能接受其他消费者。这类特性能通过服务管理策略或使用服务器虚拟化技术来实现。

    　　在异步模型中，消费者发送请求给服务器，并继续进行其他的处理。服务器完成服务之后马上返回响应，所需时间取决于服务器的负载情况。应该把服务器实现为对预期的最大请求数量进行排队，而且他不必同时处理所有的服务请求。

    　　如果预期会出现大量的服务请求，而服务器只能同时处理数量有限的服务，那么推荐使用异步服务调用。异步服务能非常容易地向上或向下扩展，只需调整请求的队列长度即可。

    　　如果需求实时响应，那么显然要选择同步模型。然而，应该把系统实现为处理预定数量的服务请求。添加更多的服务器是向上扩展这种实现的惟一途径。

    　　在大多数复合服务中，都涉及到大量的应用程式。在同步服务调用中，在许多应用程式之间确保请求 / 响应几乎是不可能的。在这种情况下，异步发布 / 订阅或点对点的消息收发模型能确保多个应用程式之间的消息和响应的交付。

    　　异步服务调用模型最适合于高度可靠的、粗粒度的、面向文件的服务。同步服务调用更加适合于细粒度的、轻量级服务调用。异步消息收发的一个缺陷是：响应顺序可能和请求顺序不匹配。

    　　WebLogic 平台能同时支持同步和异步服务调用模型。同步 Web service 调用使用基于 HTTP 的简单对象访问协议（ Simple Object Access Protocol ， SOAP ），而异步模型则使用基于 Java 消息服务（ Java Message Service ， JMS ）的 SOAP 。 WebLogic Integration 支持同步的、异步的和 Web service 确认（ WS-acknowledgement ）服务调用模型。

    　　◆共享 / 公用服务

    　　SOA 促进了重用、研发和操作逻辑和任务的划分，及基于策略的计算。 SOA 的这些特性只能通过针对重用设计服务和客观化操作策略来实现。

    　　对于多个应用程式有用的服务在被识别、实现和发布之后就能够被重用。能通过发现通用的服务来识别可重用的服务，而且必须利用重用的特别注意事项来实现可重用的服务。不过，避免重用和复制率的提高则取决于可用服务的共享信息，及在企业内部是否鼓励重用。

    　　为了使服务更加易于重用，不要嵌入特定于应用程式的策略，比如安全性（身份验证和授权），服务水平协议，服务质量（ QoS ）和审计信息。因为策略是跨应用程式通用的，应该在应用程式之外设置和应用策略。

    　　WSM 产品提供通用的或共享的基础架构来管理服务、策略设置和管理。为了充分体现 SOA 的优势，要使用适当的 WSM 基础架构。下面是共享服务的一些例子：

    　　※　共享的实用程式，比如安全和业务流程编排（跨公司）。
    　　※　资源管理，比如目录和代理。
    　　※　服务管理，比如自动设置、监视、 QoS 和版本管理。
    　　※　传输管理，比如可靠的消息收发、测量、路由和审计。
    　　※　集成 / 互操作性

    　　针对互操作性、数据（通用数据模型、元数据管理）、语义和安全性建立企业 SOA 标准，以确保各种基于 SOA 的解决方案之间的集成和互操作性，这是非常重要的。能使用各种技术（ J2EE 或 .NET ）或使用各家厂商推出的产品的组合来实现基于 SOA 的解决方案。因为 SOA 解决方案为了保持一致性和可重用性，通常是由专攻各自领域的分布群组进行构建，而由其他群组进行消费的，在上述群组中建立标准以确保他们之间的互操作性是必要的。你应该把遗留系统封装为服务，并采用面向服务的应用程式研发（ Service-Oriented Development for Applications ， SODA ）。

    　　基于 SOA 的解决方案研发使企业能够快速共享他们现有的遗留系统，具体方法是把这些遗留系统封装为服务，然后共享服务。 SOA 不需求使用服务接口来构建替代系统。“ leave and layer ”方法??通常，现有的系统首先被封装为服务，以便进行重用，然后被新的系统和服务替代??允许企业选择和建立有关怎么使用一个服务层封装不同类型的系统的标准和指导方针。

    　　SOA 不排除企业应用程式集成（ EAI ）； SOA 需求对后端系统进行集成。利用 SOA 原理进行集成（面向服务的集成 [Service-Oriented Integration,SOI] ）允许企业实现灵活的、可重用的、标准的和共享的集成。我们刚刚讨论过的特性具有不同的实现选择。每个基于 SOA 的解决方案都需求经过仔细的分析后选择最佳方法。希望这里给出的信息能够帮助你开始构建成功的 SOA 。

    原文出处：

    http://www.fawcette.com/weblogicpro/2005_01/magazine/features/rramanathan/


  • 以上内容由 华夏名网 搜集整理，如转载请注明原文出处，并保留这一部分内容。

    　　“华夏名网” http://www.sudu.cn 和 http://www.bigwww.com 是成都飞数科技有限公司的网络服务品牌，专业经营虚拟主机,域名注册，VPS,服务器租用业务。公司创建于2002年，经过6年的高速发展，“华夏名网”已经成为我国一家知名的互联网服务提供商，被国外权威机构webhosting.info评价为25大IDC服务商之一。

    华夏名网网址导航: 虚拟主机 双线主机 主机 域名注册 cn域名 域名 服务器租用 酷睿服务器 vps vps主机

  • (阅读次数:37)
  • 上一篇： 在现有系统上实现 SOA    下一篇: SOA如何使开发人员受益
  • [收藏] [推荐] [评论] [打印本页] [返回上一页][关闭窗口]
  • 昵称： (为空则显示guest)
  • 评论分数： ★ ★ ★ ★★★ ★★★★ ★★★★★
  • 评论内容：(不能超过250字，需审核后才会公布，请自觉遵守互联网相关政策法规。