您的位置: 漳州信息港 > 法律

SOA:美学为架构的IT技术_0

发布时间:2019-10-16 12:31:40

近一年多以来,SOA(Service-Oriented Architecture,服务导向架构)成为IT界的当红炸子鸡。

随着媒体与IT大厂的炒作,好像一谈到「整合」就非SOA不可。很多技术词汇(例如:BPEL、ESB、BAM…)也在这个过程中不断地被创造出来,但这些一技术词汇好像并不会帮助我们对于SOA在应用上的了解,甚至只会令人更怀疑这些名词只是IT产业又拿出来营销的噱头而已。

事实上,技术出身的我不得不承认,SOA有一种架构性美很容易让技术人员醉心。但在同事朋友们讨论SOA的时候,总觉得少了什么?这样的美可以帮助我们解决什么样的问题呢?如果只是架构上的美,终究也只限于技术架构的美而已,有什么信息问题是无法用传统EAI(Enterprise Application Integration)技术手法来解决而一定要采用SOA吗?还是它的美只存在于IT学院的象牙塔之中呢?

面对业界许多(非IT领域)朋友的疑惑,我决定写这一篇文章来重新为SOA「正名」,从IT在商业运作上应用的角度来阐述SOA主要所要解决的问题,让大家再从另一个角度来看SOA。

定义:不只是技术,是IT架构

或许已经有读者注意到了,我们通常谈到IT,大部份都会说是XX「技术」,但为什么没有听过有人说SOA「技术」呢?如果我们看SOA(Service-Oriented Architecture)这三个英文字母,会发现SOA中的「A」竟然是Architecture(架构)这个字。单就语句结构上来看,如果在「架构」这个字词后面再扯上「技术」两个字,还真有点奇怪。

严格说来,SOA这一个词并不是指一种「技术」,而是指一种IT架构,当然,这样架构下会有各种不同的技术,来解决企业在面对商业自动化的所面临的各种不同的问题。

本文将先介绍SOA对企业的意义,主要在藉由商业自动化,以协助企业解决一个千古不变的难题:变。

自动化服务组件是商业自动化的步

SOA(Service-Oriented Architecture,服务导向架构)顾名思义,以「服务」做为导向来出发,以设计并建构我们的系统构架。简单来说,我们可以说:「服务导向架构」目的是要达到一个自动化的商业行为。

首先,让我们举个例子说明。澳图美德(Automated)科技是一个系统整合厂商,在他的商业行为中,他需要经常对他的供货商(例如SUN Microsystems)来进行询料(特别是在库存中并没有足够的备料时)。

早期这样的一个行为,是由纯人工的方式来处理,需要再透过SUN业务同仁处理(包括报价及答复商品的Delivery Time),但在整个商业流程中,商品的报价与Delivery Time并不会有经常性的异动,因此这样的做法是一种人力资源的浪费。

为了避免这样的问题,我们可以将上下流两个公司的系统做适当的调整,让SUN公司在系统中建架一个服务组件来提供价格与Delivery Time 的数据查询,直接利用在澳图美德内部的系统来呼叫SUN公司所提供的服务组件,澳图美德的同仁即可完成报价与Delivery Time(交期)的询问。所以可以认知到的是,在商业自动化的前提下,SOA需提供一个「跨系统的数据交换与传递的规范与方法」,以便商业上的信息交换。而在整个架构中,被实做出来以负责信息的交换与传递的程序一个个的模块,我们可称为服务组件。

或许有些读者会发现,这样的做法,不就是几年前 Web Service的技术观念下就已经提出来的做法吗?这跟SOA 有什么关系呢?

当然,如果只是上述的例子中所提到的需求,其实只要用 Web Service就可以做到了。那SOA可以再解决什么样的问题呢?藉由上面的例子,我们再来拉大企业的需求,以再进一步认识 SOA。

「服务组件」结合「流程」提供更多样的自动化服务

由上述的例子,如果单纯从数据流的角度来看,我们可以说:「澳图美德公司与SUN公司在做数据交换的动作,让澳图美德员工可以很轻易得到他需要的数据。」但其实自动化的商业行为并不只是数据交换那么单纯;例如,以身份认证而言:是不是所有的厂商都不需经过认证就可以呼叫SUN公司所提供的组件来取得SUN的报价与 Delivery Time 呢?或者不同的第三方所取得报价会相同吗(不同的第三方有可能会因不同的规范而有不同的报价)?再从流程的角度来看,整个商业行为并不是在取得报价后就结束了–是不是要有询价记录(以便未来的追踪)?

或者,如果价格合理,那就会进入采购的程序。如果价格不被接受,那则有可能进行到议价的程序,如果该项商品还有多个供货商的话,那也有可能进入到询价、比较的不同的程序。甚至不同供货商也有可能有不同的作业流程或程序,有些一定要先下单再出货,有些关系好的则可以先出货再下单。有的商品则有可能要先下样品单,甚至样品交货的同时也要先付货款等等。

因此很单纯地由一个服务组件来进行数据交换,并无法满足商业行为自动化的所有需求。在一个完整的商业自动化行为中,往往需要由一组(多个)可能由多个不同系统提供的服务组件来进行服务。

例如,系统应该先进行身份确认(这里是一个身份确认的服务组件),再来才进行询报价程序(这里应该又是另外一个服务组件),,当买方确认要进行下单的时候,才会进入采购程序(进入采购流程应该又是另外一组服务组件,甚至有可能对应到另外一个独立的系统中)。而组职、整合并决定所有的服务组件的使用顺序地即是「流程」。因此商业自动化的目的下,如何进行跨程序语言、跨系统、跨组织、甚至跨企业的流程架构、规划、设计与实作,也是SOA 要思考与规范的重点项目。

我一开始说SOA有种架构性的美,是指它作为一种IT架构,竟与哲学中的现象学具有同样的世界观 。现象学提到「存有」与「关系」。「存有」在OO(面向对象,Object-Oriented)中(注),可以视为是对象,而在SOA中,我们可以说它是服务组件。而关系,在OO中就是那个方法,而在SOA中,就是跟时间一起被定义在流程之中。SOA即是结合服务组件及流程的很严谨、很工整的架构(待续)。

Service-Oriented 与 Object-Oriented:

看到Service-Oriented,IT产业较熟悉的人应该就会直接觉得想到OO(Object-Oriented,面向对象)。确实,从观念上来说,这两个概念是雷同的,只不过它们所关切并要解决的问题是属于不同层面的:SOA是从商业逻辑成层面来看,以减少系统中服务组件设计与开发的时间;而OO则是关注程序设计与开发的层面,以减少程序组件重新开发的时间。

德州白癜病医院
淄博治疗前列腺增生费用
嘉兴治疗盆腔炎费用
甘肃癫痫病医院哪家好
黑河癫痫病医院哪家好
猜你会喜欢的
猜你会喜欢的