为什么说社会形态影响着SOA面向服务架构思想?

产品将面对的社会形态

新研发的平台产品所面临的问题是:面对激烈的商业竞争形势,使大多数企业都面临着增长业绩、提高生产率和降低成本的压力,而产业的趋势是业务方法不断变化,特别表现在企业重构和解构这两个特征上。

企业重构:传统上的企业管理是一种层次化的垂直结构,打造了一个具有固定业务、确定交互、执行高效的模式。但是当竞争形势和市场需求发生变化的时候,它就与动态业务的趋势相冲突,阻碍了快速反应时间。这种外部压力迫使企业重新定位,向水平集成的业务流改变,这就形成了企业重构的趋势。

产业解构:在企业重构中,企业会根据自己的能力进行业务专业化。企业专注于自己的核心业务,业务以外的任务通常外包给第三方来提供实际的支援和交付,每个第三方再将重点放在提高自身的核心服务上,这就形成了产业的解构,以及新的产业链的形成。

这种业务不断变化的特征,对于以现代物流业为背景的仓库管理系统,同样有明显的表现。换句话说,所设计的仓库管理系统平台应该具有业务敏捷的变化特征。

面向服务的架构(SOA)的思想

软件是一种思维,而思维是受我们自己所处的社会形态影响的。

我们来观察社会形态的变化,随着社会需求趋向于复杂化和多样性,今天的社会形态逐步地向服务型社会转移。基于服务的企业诸如金融、交通、商店、法律等,它们本身有自己的工作流程,而流程的入口是用户需要,输出是用户需要的结果。

用户并不关心这些服务企业内部流程,他们需要的就是输入和输出。用户要做的事情,就是根据自己的需要,编排这些服务,以更方便、更快捷、更高的质量,来满足自己千变万化的需求。对这种基于服务的社会形态的理解,能给我们带来什么启示呢?如下图(A,C)所示。

如果在架构设计的时候也映射这种服务型社会的思想,把具备完整性和稳定性的业务做成一种托管服务,由上层应用业务去编排它们,如上图(B、D)所示。这样,当业务流程发生变化的时候,或者重新编排,或者加入新的服务,就可能使这种技术架构能够适应流程的变化。理解这一点很重要,它为我们的架构思想提供了基本的机制背景。

这就是面向服务的架构(SOA)的基本思想,它的特点是把软件部署为一种托管服务,可以通过网络访问,由客户按需定制和组合不同的服务完成既定的业务(业务敏捷)。还需要注意一点的是,与社会形态一样,服务必须强调规约,没有规约,服务本身也就不存在了。这些对于社会形态的考察,使我们对于软件架构形态与方法论的本源有了更深入的理解。

面向服务的架构(SOA)基本形式

综上所述,在实际产品设计中,技术架构可以分成服务提供、服务编排和服务消费三个层。为了避免点对点服务带来的问题(不能改变信息、难以跟踪服务使用状况、难以验证、安全隐患等),可以通过企业服务总线(Enterprise Service Bus,ESB)对服务进行集中管理。必要的时候,还可以应用云计算服务完成资源的合理配置。基本的面向服务架构如下图所示。

服务应该是无状态的,也就是服务不依赖于任何事先设定的条件和其它服务的状态,是状态无关的,所以它们可以被编排以执行商业逻辑。

时间: 2024-10-11 05:08:20

为什么说社会形态影响着SOA面向服务架构思想?的相关文章

Software-Think SOA 面向服务架构思想

SOA 四项信条 边界明确 服务自治 服务共享数据模式和契约而不是类 基于策略确定服务兼容性 在大规模分布式应用程序(如 SOA系统)领域中,相关联得涉及模式被称为 Messagign 消息传送模式. Messaging 模式(与设计模式类似)为复杂问题提供标准得解决方案. 以一种统一得形式解决在众多彼此分离得系统中共享数据得问题. Document Message 模式使得能够采用一种统一.灵活得方法与服务通信. 该模式并不使用典型得 RPC 风格得参数化方法来暴露服务API,而是采用消息对象

SOA面向服务架构简述

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 在上篇中我们简单谈了下架构设计中服务层的简单理解,在这里我们将继续服务层的架构,在本节我们将重点在于分布式服务.在分布式系统中表现层和业务逻辑层 并不处于同一物理部署,所以我们必须存在分布式服务,以契约方式发布于网络中,我们的关注点在于服务,面向服务编程,这种通过组合业务逻辑暴露可用服务的架构叫做面向服务架构(SOA). SOA强调一个松耦合,基于宏服务的架构,通过契约暴露给服务消费者可用的

学习~SOA面向服务框架

SOA面向服务架构 首先Martin Fowler提出SOA歧义Service Oriented Ambiguity,认为"什么是SOA"是不可能回答,因为不同的人意味着不同的事情,SOA意味服务接口,意味流程整合,意味资源再利用,意味着管制,在下面SOA组件图中,服务和服务消费者(客户端)之间存在多个约束,当一个服务显式暴露后,客户端能够通过绑定定位到该服务,相当于两者签订了合同,规定了合同内容和如何实施,具体合同的描述是通过消息方式进行: 由于Java等传统语言主要是以类表达对象,

SOA——面向服务的体系架构

上一篇博文中提到了"紧耦合"的现象,如何解决?SOA,采用面向服务的体系架构. 一.What? SOA=Service-oriented Architecture面向服务的体系结构 SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来. 我个人更加倾向于这样的一种解释:SOA是指为了解决在Internet环境下业务集成的需要,通过连接能完成特定任务的独立功能实体实现的一种软件系统架构. 所以,SOA是什么?SOA不是一种语言,也不是一

面向服务架构SOA

SOA架构即面向服务架构. 面向服务的体系结构,是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来. 接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互. 这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合.松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,

面向服务架构的一些思考

在谈面向服务架构之前,首先来看看什么是服务.常谈的业务组件,业务方法或操作是否都是服务?真正的服务必须满足两个条件,一个服务本身是能力供给,必须有外界的需求:一个是服务本身是可复用或重用.一般来讲服务应该是可重用的任务,这种任务可以是业务方面的操作组合,也可以是一种技术能力. 面向服务的重点就是一切以服务为中心,从服务识别,服务分析,服务设计,服务开发和服务上线使用一切都是以服务为中心.但是要注意到面向服务本身不是在面向结构或面向对象基础上的一个新方法,而是对面向对象和组件化思想的提升. 面向服

领域驱动设计的面向服务架构

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店 一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列

OSGi——面向服务架构规范简述

OSGi——面向服务架构规范简述 去年我们组要开发一个新的产品,在讨论产品架构路线的时候,美国的架构师向大家征集了架构设计思想(我推荐了SCSF),有一位工程师向他推荐了OSGi.以前我还没有听过OSGi这玩意,虽然我参加工作后,现学了Java和Flex,但非常菜.在工作之前我用了4年的.NET.接触了OSGi后,发现它是一个面向Java的服务规范,还没有一个像样的面向.NET的框架(有个EgeyeAddIn,据说兼容OSGi,我看了源代码了,觉得它离OSGi较远http://www.codep

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店

一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列可以说是刚接触领域驱动设计朋友的福音,本系列将结合领域驱动设计的思想来一步步构建一个网