zoukankan      html  css  js  c++  java
  • 基于SOA的体系架构设计

          面向服务架构SOA(Service-Oriented Architecture)是一种架构模型和一套设计方法学,其目的是最大限度地重用应用程序中立型的服务以提高IT适应性和效率。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。SOA的关键是“服务”的概念,W3C将服务定义为:“服务提供者完成一组工作,为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化,但也可能使提供者的状态改变,或者双方都产生变化”。

          当我在为全球酒店在线预订系统做架构设计时,我发现一个头疼的问题是如何保证系统与分布在全球各地的酒店之间完成消息的交互?

    一个妥协的办法是,我们为酒店管理者提供管理功能入口,管理人员可以将酒店的客房及客房类型的数据输入到系统的数据库中。发布到在线预订系统中的客房数据必须是预留的,如此方可以避免在线预订者与酒店本身顾客对于客房资源的争用。

    客房资源虽然得到了妥善的安排,但造成的问题是客房可能会被闲置,从而造成资源的浪费。例如,某酒店为在线预订系统预留了50间客房。为了保证在线预订系统的顾客可以顺利地预订到合适的客房,这50间客房不允许非在线预订者预订。假设整个酒店共有200间客房,如果150间客房均已入住了顾客,那么即使酒店还空着这50间客房,对于那些实际到酒店订房的客人而言,酒店的大堂经理也只能抱歉地说客满了。

    我们当然可以及时地更新这些数据,然而这会给管理员带来工作上的负担。考虑全球时区不同的情况,有可能每个酒店的管理员都需要24小时的值守。

    最好的办法当然是让各个酒店的数据与在线预订系统的数据实现共享。然而这会带来三个问题:
    1、 全球的酒店系统需要定义统一的接口标准;
    2、 如何保障酒店数据访问的安全性?
    3、 全球的各个酒店可能会使用不同的系统,如何保障它们与在线预订系统之间的互操作性?

    SOA可以使得这些问题迎刃而解。虽然我们很难要求全球的酒店系统都遵循统一的酒店接口标准,但鉴于酒店的行业特征,定义统一的服务契约(Service Contract)是完全可行的。当然,我们首先需要解决消息的定义,如此我们就可以定义如下的服务契约:
    [ServiceContract]
    ReservationResponse Reserve(ReservationRequest request) ;

    自从Web Service诞生以来,对于Web Service安全性的讨论就没有停止过。例如Microsoft推出的WSE。.NET 3.0下的WCF则完全支持WS-Security、WS-Trust和WS-SecureConversation等安全策略。如果再考虑用户的权限控制,以及WAN和LAN的防火墙配置,数据访问的安全性可以得到较好的保证。

    SOA本身就是为互操作性(interoperability)而生的,这也正是SOA的最大价值体现。只要提供了Web Service,我们就可以通过WCF调用这些服务。如果有的系统无法提供Web Service,例如RPG和COBOL,我们可以通过Host Integration Server(HIS),使得应用程序接口能够实现.NET Web Service。

    全球酒店在线预订系统的体系架构图如图1所示:
     基于SOA的体系架构设计.gif
    图1 全球酒店在线预订系统的体系架构图
       
    用户可以通过PC、laptop或者PDA访问在防火墙保护下的酒店在线预订系统,查询/预订/退订房间。系统通过WCF技术跨应用程序地访问各个酒店提供的Web Service。这些酒店系统分布在世界各地,它们实现Web Service的方式可能是WCF、WebSphere,也可能通过Host Integration Server实现。这些Web Service都遵守一个共同的服务契约,并被定义为统一的服务接口。

    为了定义与管理酒店的业务流程与工作流,系统还必须部署BizTalk Server。此外,该服务器还要负责管理事务,处理异常消息的传递。

    没有SOA和Web Service,要实现这样的全球酒店在线预订系统是很难想象的,特别是新设计的在线预订系统还必须考虑兼容旧有的酒店系统。此外,我们不能奢望酒店的预订服务流程是一成不变的,利用SOA,可以很好地隔离服务的提供者与调用者之间的依赖,实现系统的松散耦合。只要在设计中遵循了“服务是自治的”这一原则,并且能够较好地定义服务的边界,即使服务的实现发生了变化,对于整个系统而言,也不会严重到伤筋动骨的地步。重要的是,我们必须改变系统设计的思路与精神,利用面向服务而非面向对象的方式来考虑架构的整体设计。

  • 相关阅读:
    NYOJ 625 笨蛋的难题(二)
    NYOJ 102 次方求模
    ZJU Least Common Multiple
    ZJUOJ 1073 Round and Round We Go
    NYOJ 709 异形卵
    HDU 1279 验证角谷猜想
    BNUOJ 1015 信息战(一)——加密程序
    HDU 1202 The calculation of GPA
    "蓝桥杯“基础练习:字母图形
    "蓝桥杯“基础练习:数列特征
  • 原文地址:https://www.cnblogs.com/smallmuda/p/1667967.html
Copyright © 2011-2022 走看看