SOA思想

SOA思想
SOA思想

支点网独家连载《SOA思想、技术与系统集成应用详解》,转载请注明出处。

17.4 供应链系统的SOA解决方案

SCM系统主要解决企业与上游供应商和下游销售商的集成问题,本质上是追踪自己所订货的原材料或者零部件的生产进度和产品的销售状况,以便作出最优的生产计划和保持最小的库存。图17-6显示了上下游供应链系统的示意图。

图17-6 上下游供应链系统示意图

现代企业很多时候要么处于库存积压的状态,要么处于缺货状态。这主要是因为没有掌握上下游供应链的状态。

如何更好地减少库存和作出最优的生产计划是企业非常关系的问题。其本质上是一个企业内部信息和企业外部信息的集成整合问题,SOA正好可以大显身手。因为每个信息系统的技术大都不一样。SOA是独立于各种技术的。

图17-7显示了供应链的SOA解决方案,主要步骤如下。

企业首先要明确自己需要从上游供应商那里得到什么样的信息,这里假设为“供货信息”,主要包括原材料和零部件的进度,例如什么时候发货,什么时候收到货,会不会有损耗等。

企业要明确自己需要从下游销售渠道和零售店那里得到什么样的信息,这里假设为“销售信息”,例如每种产品的型号,每天的销售数量、退货数量、返修数量等。

需要上游供应商创建“供货信息”的服务接口,以便企业调用。

需要下游销售渠道创建“销售信息”的服务接口,以便企业调用。

创建企业“内部信息”服务接口,包括企业自己内部的订单查询服务、库存查询服务、物料查询服务、机器设备查询服务、生产能力信息服务等。

将上游供应商“供货信息”服务、下游销售渠道的“销售信息”服务,以及“企业内部信息”服务集中到服务总线上来;同时也将APS高级计划系统加入到服务总线上来。

创建BPEL流程管理模块,分别调用上、下游和企业内部的服务,最后将结果作为输入来调用APS 高级计划系统,APS将会用到各种算法得到最优的生产计划。

图17-7 供应链的SOA解决方案

整个架构因为采用服务总线和BPEL流程管理,所以所有上面这些模块都处于一种松散耦合的状态,可以随时更新,不会影响系统的正常运行。APS优化算法也可以根据需要随时更新。

上面介绍了供应链系统的SOA架构方案。下面介绍供应链系统比较关键的技术细节。

追踪下游销售渠道的产品销售细节相对来说比较容易。因为企业完成生产后,会发货(Shipment)给下游的分销商或者销售渠道。每一个产品在出厂的时候,都会有一个唯一的产品编号,企业的ERP系统有每个产品编号的发货记录,下游的销售渠道只要将每天销售的产品编号报上来即可。

追踪上游供货商的原材料和零配件的供货信息相对来说比较困难,主要是产品还没有成型。一件商品从原材料,到加工成各种零配件,到组装,到测试,到最后成型,所经过的上游的厂商可能有多家和多道环节,有点像击鼓传花一样。但是它远远要比击鼓传花复杂,因为击鼓传花传来传去,所传的东西并没有变。

下游销售渠道供应链的产品销售也像击鼓传花。产品从企业出厂到分销商,再到批发商,再到零售商,再到零售店,最后到最终顾客手中,产品本身并没有变,产品编号也没有变。

但是对上游供应商的供应链的产品追踪就完全不一样了。

以服装供应链来说,从纺纱,到布匹,再到布匹染色,再到服装,是由不同的上游产商来完成的。每过一道手,东西都会发生变化。

以半导体供应链来说,先由像台机电这样的企业制造出大的Wafer,再由其他的公司Wafer Sort 将一个大的Wafer切成很多小块。再由另外一家公司进行组装(Assembly),组装好之后将产品送到专门做测试的公司做测试(Final Test)。

如何追踪产品的生产状态呢?从现象上看,是比较困难的。它不像下游销售产品,产品本身不变,产品的编号也不变。作为上游供应链系统,产品本身在变,产品的编号也在变,因为每家公司的生产系统都会有自己的产品编号方式。追踪的方法一般是从最源头的源材料或者产品编号开始的。以服装供应链来说,就从最开始的原料纺纱编号开始追踪。

随着全球经济一体化的深入发展,供应链系统也会变得越来越重要,供应链系统其本质就是上下游企业之间的信息集成。由于各企业的IT实现技术不一致,要在各企业之间实现信息集成,SOA必然是最佳选择。

基于SOA的统一身份认证服务技术

基于SOA的统一身份认证服务技术研究与实现

目录 1.系统特点 (1) 2.主要功能 (1) 3.实现 (1) 4.统一身份认证 (2) 4.1IDS功能概述 (2) 4.2IDS的结构 (3) 4.3IDS的特点 (4)

1. 系统特点 权限管理已经被很多公司做过无数遍了,这个系统的特点是: (1)适合于企业内部拥有多个相互独立的信息系统(B/S,C/S都支持),支持单点登录企业内部用户都由AD进行统一管理。各个信息系统以AD用户识别当前使用者,也就是采用集成身份验证。 (2)采用SOA的设计思想,将权限管理作为一个通用的服务平台,支持在一个权限管理界面中管理多个信息系统的角色和权限。 (3)基于https://www.360docs.net/doc/dc1907017.html,的开发平台,复用了https://www.360docs.net/doc/dc1907017.html,的用户权限管理的部分代码。 2. 主要功能 (1)用户管理。 虽然AD统一管理用户,但不是每个AD用户都是可以使用一个业务系统的。需要判断用户是否是某个业务系统的有效用户。 (2)角色管理。 (3)权限管理。 将权限赋予角色,用户加入角色后,得到需要的权限。 (4)用户认证。 确认用户是否是某个业务系统的合法用户。 (5)个性化信息存储。 (6)权限验证。 分为功能权限和数据权限验证。 3. 实现 (1)AD统一管理用户。 (2)建立一个https://www.360docs.net/doc/dc1907017.html,网站,进行用户用户、权限管理,提供web service作为服务接口。 (3)其它业务系统采用Windows集成身份验证,通过web service进行用户身份和权限验证。 SecurityAdapter具体实现web service对外接口。 利用https://www.360docs.net/doc/dc1907017.html,的用户角色管理的接口和数据库,通过自己定制的MembershipProvider来实现用户,角色的数据存储。通过自定义的ProfileProvider来实现个性化数据的存储。 利用Enterpise Library的security模块的接口,实现权限的管理,功能权限和数据权限的验证。

面向服务的架构标准SOA

面向服务的架构标准领先技术不意味厂商锁定XML和Web服务正在作为面向服务的架构(SOA)的平台来出现,它既可用于企业内部通信,也可用于企业间通信。作为第一个既支持SOA编写,也支持SOA 利用的Java集成开发环境(IDE),WebLogic Workshop天生就带上了专有创新的印记。从那时起,BEA通过多种机制,从开放标准到开放源代码,已经实现了对这些创新进行投资保护的承诺,使得开发人员可以充分利用BEA的尖端生产率和集成特性,而不必担心锁定在某一厂商。下面,让我们一起来看看在Workshop中基于SOA的关键创新,以及在每种情况下是如何保护投资的。 什么是SOA? XML和Web服务是当今的热门技术,因为它们在实现面向服务的架构(SOA)上担当了重要的角色。目前独立的、而且通常是相互孤立的应用程序,制约了业务服务的共享,SOA则正在解决这一问题。通过给单个业务操作进行定义或在表层加上“服务访问点”,IT组织能够: ?使IT资源与其业务功能更密切地结合在一起 ?通过以下方法的最佳组合和匹配,建立更加动态、更有效地利用成本的系统 ?购买和自建 ?自制和外包

?更迅速地发布“组合”应用程序(想想“Web流(Web flows)”和“工作流(work flows)”),提供统一的、面向任务的跨业务视图 ?通过更加细致的增量管理需求和变化,在应用程序生命周期上获得更高的灵活性 ?用提供“业务透明性”的基础架构替换不透明的、“黑盒子”系统更容易—这种基础架构根据流经应用程序的总体信息,提供实时的业务智能。 对象和组件已经成功地在应用内提供了重用性(应用程序的定义是:以单元形式开发和部署的代码)。但是,SOA依赖的是在应用程序之间实现重用。用SOA把不同的应用程序互连起来,这根本不是什么新东西—想想以前定义分布式的、应用间通信架构的一些努力(不用费力想什么新的首字母缩略词):?同步的(面向RPC):CICS分布式程序链接(DPL)、分布式计算环境(DCE)、分布式组件对象模型(DCOM)、公共对象请求代理体系结构(CORBA)IIOP、Java 远程方法调用(RMI)、关系数据库管理系统(RDBMS)存储过程,等等。 ?异步的(面向消息的):CICS临时数据队列(TDQ)、Tuxedo ATM、IBM MQSeries、Tibco Rendezvous、Microsoft消息队列(MSMQ)、Java消息服务(JMS),等等。 是什么使得应用的集成如何困难呢(而且,由此推出,为什么我们作为一个行业,还必须要实现一个统一的SOA)?这是因为,应用程序是由不同的人们,在不同的地点建立的,而且根据不同的计划部署的。任何方法,只要它

SOA面向服务体系概述

SOA(面向服务体系)知识概述 SOA概览 最近半年以来,在企业级应用开发领域,谈论最多的一个词,恐怕非SOA(Service-Oriented Architecture,面向服务架构)莫属。那么SOA究竟拥有什么样的魔力,能够让众多的软件厂商对他趋之若骛,掀起新的一轮企业架构浪潮。让我们在本文中一探SOA的究竟。 那么什么是SOA,让我们先从基本概念开始讲起。 什么是SOA? SOA是一种架构模型,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。 SOA的关键是“服务”的概念,W3C将服务定义为:“服务提供者完成一组工作,为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化,但也可能使提供者的状态改变,或者双方都产生变化”。 https://www.360docs.net/doc/dc1907017.html,将SOA定义为:“本质上是服务的集合。服务间彼此通信,这种通信可能是简单的数据传送,也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。” https://www.360docs.net/doc/dc1907017.html,将SOA定义为:“按需连接资源的系统。在SOA中,资源被作为可通过标准方式访问的独立服务,提供给网络中的其他成员。与传统的系统结构相比,SOA规定了资源间更为灵活的松散耦合关系。” Gartner则将SOA描述为:“客户端/服务器的软件设计方法,一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处,在于它着重强调软件组件的松散耦合,并使用独立的标准接口。” Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益??“SOA极大的得益于BPM技术和方法论,但是SOA面临的真正问题是确立正确的企业意识,即:强化战略化的SOA计划(针对供应和使用)并鼓励重用。” 虽然不同厂商或个人对SOA有着不同的理解,但是我们仍然可以从上述的定义中看到SOA的几个关键特性:一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。 需着重注意的是,SOA并不是新生事物。大型IT组织成功构建和部署SOA应用已有多年的历史??这要比现有的XML和Web服务长很多。IBM CICS和BEA TUXEDO就是过去被用于

向服务架构(SOA)和企业服务总线(ESB)

学习和研究在企业中实施面向服务架构(SOA),简单回顾SOA和ESB,重点关注微软在SOA领域的相关指导和.NET社区的相关开源的解决方案,和大家一起来探讨如何在企业里实现SOA,期望有实施SOA经验的同学发表意见。 一、SOA的历史 1996年,Gartner最早提出SOA。2002年12月,Gartner提出SOA是"现代应用开发领域最重要的课题",SOA并不是一个新事物,IT组织已经成功建立并实施SOA应用软件很多年了,BEA、IBM、等厂商看到了它的价值,纷纷跟进。SOA 的目标在于让IT变得更有弹性,以更快地响应业务单位的需求,实现实时企业(Real-Time Enterprise,这是Gartner为SOA描述的愿景目标)。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA,并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。 SOA是在计算环境下设计、开发、应用、管理分散的逻辑(服务)单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件,即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考,并考虑复用现有的服务,或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法(例如消息机制),通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后,这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发,使得在商业环境许可的时间内对变化的市场条件做出快速的响应。 SOA也不仅仅是一种开发的方法论--它还包含管理。例如,应用SOA后,管理者可以方便的管理这些搭建在服务平台上的企业应用,而不是管理单一的应用模块。其原理是,通过分析服务之间的相互调用,SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息,这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。 SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚,轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的(各种)需求的,即使是一个大型的ERP解决方案,仍然不能满足这个需求在不断膨胀、变化的缺口,对市场快速做出反应,商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上,应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是,基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚:它们会同业务流程结合在一起,因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。 企业流程(enterprise process)是流经企业框架的空气,它赋予业务模型里的组件以生命,并更加清晰地定义了它们之间的关系。流程定义了同业务模

从SOA到微服务架构

从SOA到微服务架构 对于SOA和微服务架构,网上有一篇文章谈到微服务和SOA之间只差了一个ESB,可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线,设计图形应该是星形的,而微服务是去中心化的分布式软件架构。 这句话本身是有问题的,所以有必要再次谈下SOA和微服务架构。 首先要看到SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。因此把两个层面的内容放到一起谈本身就不对。 那么先从架构风格上谈下SOA和微服务架构,对于SOA参考架构强调了两个重点,一个是找到离散,自治,粗粒度和可重用的服务能力,其次是服务本身可以灵活的组合和编排适应业务变化。而当谈到微服务架构的定义的时候谈的更多的是各个微服务模块能够独立自治并在独立的进程中运行,同时微服务之间能够通过轻量的服务接口进行交互和协同。从这个定义我们再展开来看如下: 对于服务本身的自治,离散,无状态特征两种架构模式都需要。 SOA强调粗粒度,而微服务架构不会过分强调,由于模块划分细了,本身想粗粒度更加难。

SOA强调可复用,而服务架构不太强调,要考虑到在分层架构模型中UI到服务层也需要全部走服务接口 对于SOA找到服务只是第一步,强调服务复用性和粗粒度的原因也是后续这些服务要用到服务组合和编排里面去,而对于微服务架构没有过分强调这点,服务是否设计到能够完全灵活编排并不是微服务架构考虑的重点,一考虑这个问题往往使这个微服务架构变重。 再回来看,微服务架构强调单体应用要打散为多个独立自治,可以在独立进程中运行和管理的微服务模块,这个内容本身是属于SOA思想在系统内容的彻底内化以及组件化架构思想的推进,而传统SOA更多的关注的是系统间的协同和服务重用,因此并没有过分强调这点。 由于在微服务架构中没有了服务组合编排这层的太多考虑,但是本身这个事情是要做的,因此很多是单独定义了上层的业务协同或应用类的微服务模块来完成。即在代码中完成了服务组合的编排的事情,但是仍然可以看到要更好的完成这个工作,在底层微服务模块基础上最好能够有提供领域服务能力的模块来实现服务的组合和组装。正式由于这个原因,个人认为领域服务设计思想在微服务架构中有重要的地位。 基于以上思考,从SOA和微服务架构的对比可以理解为: 微服务架构=80%的SOA服务架构思想+100%的组件化架构思想+80%的领域建模思想

面向服务(SOA)技术架构规范

ICS 备案号: Q/CSG 中国南方电网责任有限公司企业标准 面向服务的信息技术架构(SOA )框架规范 中国南方电网责任有限公司 发 布

目次 前言............................................................................ III 1范围. (1) 2规范性引用文件 (1) 3术语与定义 (1) 3.1面向服务的体系结构 (1) 3.2服务 (1) 3.3企业服务总线 (1) 3.4企业资源规划 (1) 3.5企业应用集成 (1) 3.6企业信息门户 (1) 3.7SOA项目 (1) 4总则 (1) 4.1持续发展原则 (1) 4.2先进性原则 (2) 4.3实用性原则 (2) 4.4操作性原则 (2) 5SOA架构模型 (2) 5.1服务体系 (2) 5.1.1服务体系设计依据 (2) 5.1.2服务体系图 (2) 5.1.3服务体系各层定义 (3) 5.2应用体系 (4) 5.3服务部署体系 (5) 5.4技术标准规范体系 (6) 5.4.1技术标准规范体系图 (6) 5.4.2服务开发技术标准规范 (9) 5.4.3服务集成技术标准规范 (13) 5.5SOA架构模型特征 (14) 6SOA服务设计与开发 (14) 6.1服务识别 (14) 6.2服务定义 (14) 6.3服务设计 (16) 6.3.1总体设计原则 (16) 6.3.2访问服务 (16) 6.3.3数据服务 (17) 6.3.4业务服务 (17) 6.3.5流程服务 (17) 6.3.6综合服务 (17) 6.3.7展现服务 (17) 6.4服务实现 (18) 6.4.1服务封装原则 (18) 6.4.2服务封装方式 (18) 7SOA服务集成 (18) I

从SOA到微服务的演进之路

从SOA到微服务的演进之路

SOA是什么,服务导向式架构(SOA)是集成多个较大组件(一般是应用)的一种机制,它们将整体构成一个彼此协作的套件。一般来说,每个组件会从始至终执行一块完整的业务逻辑,通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的,但这并非SOA架构模式的要求。尽管没有严格要求,SOA一般使用某种集中式管理,比如审查委员会、主架构师或架构委员会来严格定义每个系统组件应当做什么,如何执行。相同类型的功能可能会按需在多个组件中分别定义与记录,而每个组件所使用的语言与工具集有可能是集中确定与统一的,也可能不是。SOA可能使用任何类型的SDLC、组织架构或符合这种管理的开发模型;敏捷、瀑布、看板管理或者一些组合形式都是可用而不违反SOA原则的。 此外,现代化的DevOps和云部署对SOA当然很有效,在这种系统中缩减组件数量并非必需。但在这些系统中,就算在最好的情况下,一些较大的组件也可能太过复杂而难以实现自动化,在最坏的情况下甚至完全无法实现。 微服务是什么

微服务是一种架构设计模式。在微服务架构中,业务逻辑被拆分成一系列小而松散耦合的分布式组件,共同构成了较大的应用。每个组件都被称为微服务,而每个微服务都在整体架构中执行着单独的任务,或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用,以执行较大应用需要完成的具体任务;系统还为任务执行——比如搜索或显示图片任务,或者其他可能需要多次执行的任务提供了统一的解决处理方式,并限制应用内不同地方生成或维护相同功能的多个版本。 使用微服务架构还提供这样一种机制:增加新加入开发者的生产效率,并减少新功能的推广时长。每个微服务的代码库与相关工具集都很有限;开发者无需再去了解庞大而复杂的系统,只需理解自己所做的那部分微服务相关子集,便能贡献生产力。由于无需考虑应用的现有部分使用了什么语言或工具集,或者较大应用的其他开发者是否了解这些语言和工具,只需使用当前任务最趁手的工具,因此微服务开发起来非常迅速。

7步实现面向服务架构(SOA)的成功

兰州交通大学 毕业设计(翻译) 英文题目:DATA MINING TRENDS AND DEVELOPMENTS : The Key Data Mining Technologies and Applications for the 21st Century 中文题目: 数据挖掘趋势和发展: 21世纪数据挖掘的关键技术及应用实例 学院:交通运输学院 专业:信息管理与信息系统 姓名:王婉莹

学号:20040721 指导老师:刘林忠李世威二零零八年六月

题记:面向服务架构和它所支持的web服务,是当今最热门的一种软件发展趋势。这亦是对SOA的一种最基本的理解。 7步实现面向服务架构的成功 理论上,面向服务架构(SOA)就像它的名字一样简单。公开组将SOA简单地定义 为“一种支持服务方向的架构风格”——一种可以建立您业务过程的方法,一种可以将 您的应用程序紧紧组合在一起的“万能胶”。然而在实践中,这一原则却极其复杂而混 乱。准备一个面向服务架构的部署简直就像为一座多年待售的房屋修建地下室一样艰 难。你如何才能奠定基础来支持那些已建工程呢?你又如何将已经存在的工程粘在一起 呢? 尽管SOA的前景令人担忧,但与过去相比,如今已有越来越多的公司在SOA服务和 技术上投资。在“2007年至2008年的SOA开支报告”中,AMR研究所发现,投资额正 在以惊人的速度上升:如今,接受调查的公司中的53%都在使用SOA,比去年报告中的 数据——21%增加了一倍以上。另外接受调查的37%表示,他们正在考虑到2011年完成 第一个SOA项目。 虽然在服务和技术方面投资来支持SOA,价格昂贵,但这种做法的好处是这部分支 出将通过提高生产力、业务效率、客户满意度以及通过反复使用来减少成本等很快得到 回报。此外,就长期而言,通过对SOA的投资,公司可以通过避免代价高昂的为每一个 产品升级而反复进行的点对点项目整合而节省金钱。(对SOA技术的更多详细了解,请 参照“简便的SOA”,2006年2月。) 我们已经可以从无数组织中看到商业赢家在申请SOA后的所得,看看纽约健康心理 卫生署,它在部署SOA项目后,在文件处理方面得到了2500%的改善;再来看看参数技 术公司,一家500强软件和服务企业,它能够通过使用Oracle融合中间件为客户实时 实现一个真实的单一版。然而,并非所有公司都如此成功:据AMR介绍,2008年数百万 美元将投资于SOA,“大部分是浪费。”为确保您的公司利益最大化,下面有一个向导来 帮助您浏览SOA棘手的业务。 步骤1:做好你的本职工作 尽管SOA日益普及,围绕着究竟什么是SOA,混乱的旋涡仍然存在。塞斗研究所的 主席和首席分析师保罗·斯托克弗德指出,关于SOA的一种最常见的误解就是认为它是 一种产品。“它不是一种你可以购买的现成的东西,”他说,“相反,SOA指的是为应用的 发展和一体化而设置的原则。”Web服务就是实现这一点的一套标准。

相关主题
相关文档
最新文档