基于SOA的体系架构设计

简介:

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

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

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

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

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

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

C#语言
[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所示:

 

图1 全球酒店在线预订系统的体系架构图

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

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

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








本文转自wayfarer51CTO博客,原文链接:http://blog.51cto.com/wayfarer/279916,如需转载请自行联系原作者

相关文章
|
7月前
|
缓存 监控 数据格式
信息系统架构模型(2) SOA
信息系统架构模型(2) SOA
148 0
面向服务架构(SOA)吐血整理
面向服务架构(SOA)吐血整理
面向服务架构(SOA)吐血整理
|
4月前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
128 6
|
5月前
|
Kubernetes API 微服务
「架构风格」SOA(面向服务)和微服务
**SOA与微服务对比摘要**: - **SOA**:企业级,服务粒度大,重用性强,常通过ESB通信,服务部署集中,技术栈统一。 - **微服务**:服务粒度小,单一职责,轻量级协议如REST,独立部署,技术多样性,去中心化治理。 - **区别**:服务大小、独立性、通信协议、部署方式和技术栈不同,微服务更强调敏捷和独立性。 - **示例**:Python Flask简单示例展示了服务创建,SOA服务间通过HTTP请求通信,微服务每个服务独立运行。 - **权衡**:涉及服务发现、负载均衡、容错和安全,常用技术如Docker、Kubernetes和API网关。
458 0
|
6月前
|
边缘计算 Cloud Native
“论SOA在企业集成架构设计中的应用”必过范文,突击2024软考高项论文
SOA架构,即面向服务的架构,它将系统中的所有功能都拆分为一个个独立的服务单元。这些服务通过相互间的沟通与配合,共同完成了整体业务逻辑的运作。在SOA架构中有几个核心概念:服务提供者、服务使用者、服务注册中心、服务规范、服务合同,这些概念清晰地阐述了服务应如何被提
232 6
“论SOA在企业集成架构设计中的应用”必过范文,突击2024软考高项论文
|
5月前
|
消息中间件 安全 NoSQL
「架构」SOA(面向服务的架构)
**SOA**是构建灵活企业IT系统的架构模式,基于服务组件进行设计。它强调服务的自包含、模块化,通过服务识别、抽象、组合和交互实现业务流程。特点包括松耦合、重用性、互操作性和标准化。优点是灵活性、可维护性、可扩展性和成本效益,但也有复杂性、性能和治理问题。设计策略涉及业务能力识别、服务契约定义和服务目录建立。技术栈涵盖Java EE、.NET、SOAP、REST、服务治理工具和各种数据库、消息队列及安全标准。SOA旨在适应变化,但也需妥善管理和规划。
225 0
|
6月前
|
边缘计算 Cloud Native IDE
“论SOA在企业集成架构设计中的应用”写作框架,系统架构设计师
企业应用集成(Enterprise Application Integration, EAI)是每个企业都必须要面对的实际问题。面向服务的企业应用集成是一种基于面向服务体系结构(Service-OrientedArchitecture,SOA)的新型企业应用集成技术,强调将企业和组织内部的资源和业务功能暴露为服务,实现资源共享和系统之间的互操作性,并支持快速地将新的应用以服务的形式加入到已有的集成环境中,增强企业IT环境的灵活性。
130 0
|
7月前
|
消息中间件 Kubernetes 供应链
软件体系结构 - 架构风格(14)SOA架构风格
【4月更文挑战第21天】软件体系结构 - 架构风格(14)SOA架构风格
180 0
|
前端开发 Java 应用服务中间件
单体架构、垂直应用架构、分布式、SOA、微服务之间有什么关系和区别
单体架构、垂直应用架构、分布式、SOA、微服务之间有什么关系和区别
299 5
|
Dubbo Java 应用服务中间件
09分布式电商项目 - SOA架构演变
09分布式电商项目 - SOA架构演变
129 0