SOA：美学为架构的IT技术

最近一年多以来，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则是关注程序设计与开发的层面，以减少程序组件重新开发的时间。