「服务组件」结合「流程」提供更多样的自动化服务
由上述的例子，如果单纯从数据流的角度来看，我们可以说：「澳图美德公司与SUN公司在做资料交换的动作，让澳图美德员工可以很轻易得到他需要的数据。」但其实自动化的商业行为并不只是数据交换那么单纯；例如，以身份认证而言：是不是所有的厂商都不需经过认证就可以呼叫SUN公司所提供的组件来取得SUN的报价与 Delivery Time 呢？或者不同的协力厂商所取得报价会相同吗（不同的协力厂商有可能会因不同的规范而有不同的报价）？再从流程的角度来看，整个商业行为并不是在取得报价后就结束了–是不是要有询价记录（以便未来的追踪）？
或者，如果价格合理，那就会进入采购的程序。如果价格不被接受，那则有可能进行到议价的程序，如果该项商品还有多个供货商的话，那也有可能进入到询价、比较的不同的程序。甚至不同供货商也有可能有不同的作业流程或程序，有些一定要先下单再出货，有些关系好的则可以先出货再下单。有的商品则有可能要先下样品单，甚至样品交货的同时也要先付货款等等。
因此很单纯地由一个服务组件来进行数据交换，并无法满足商业行为自动化的所有需求。在一个完整的商业自动化行为中，往往需要由一组（多个）可能由多个不同系统提供的服务组件来进行服务。
例如，系统应该先进行身份确认（这里是一个身份确认的服务组件），再来才进行询报价程序（这里应该又是另外一个服务组件），最后，当买方确认要进行下单的时候，才会进入采购程序（进入采购流程应该又是另外一组服务组件，甚至有可能对应到另外一个独立的系统中）。而组织、整合并决定所有的服务组件的使用顺序地即是「流程」。因此在商业自动化的目的下，如何进行跨程序语言、跨系统、跨组织、甚至跨企业的流程架构、规划、设计与实作，也是SOA 要思考与规范的重点项目。
我一开始说SOA有种架构性的美，是指它作为一种IT架构，竟与哲学中的现象学具有同样的世界观。现象学提到「存有」与「关系」。「存有」在OO（对象导向，Object-Oriented）中（注），可以视为是对象，而在SOA中，我们可以说它是服务组件。而关系，在OO中就是那个方法，而在SOA中，就是跟时间一起被定义在流程之中。SOA即是结合服务组件及流程的很严谨、很工整的架构。
看到Service-Oriented，IT产业较熟悉的人应该就会直接觉得想到OO（Object-Oriented，对象导向）。确实，从观念上来说，这两个概念是雷同的，只不过它们所关切并要解决的问题是属于不同层面的：SOA是从商业逻辑层面来看，以减少系统中服务组件设计与开发的时间；而OO则是关注程序设计与开发的层面，以减少程序组件重新开发的时间。（责任编辑：朱晶）
<<上一页
1
2
