ozzzzzz论SOA

现在流行这两种Architecture,一个是MDA,一个是SOA.首先我们应该认识到MDA和SOA一样都是一种技术,其带来了很多新的想法和思路.而实现这些新的技术概念,都是在某些老的技术的发展的基础上的.由于SOA这个概念非常的新,我也是最近半年才开始在IBM的dw上开始关注这个领域的，所以很多的东西我也不明白，只能把自己的一些想法贡献给大家。不过我首先要声明，我的关于SOA的观点都是来自我自己的思考，即没有具体的实际操作的基础，也没有任何的学术基础，单纯只是我自己的，所以错误一定很多，请大家注意思考辨别。
首先我们必须明白SOA是为了满足什么具体的客户需要的，这个问题最为关键。简单说SOA是为了满足客户快速改变他们的业务所依赖的IT支持系统的。而这个概念可以说是从网络泡沫以后，各个软件开发商所关注的，也正式因为这个关注带来了敏捷快速成为主流的开发潮流。可以说现在大家所关注的，已经从前期的仔细构思决策以减少前进过程中走弯路的这种不切实际的空想主义，变成了以加快应变速度快速修正前进路线的务实主义。
SOA的应用目前IBM和BEA都把目光针对于EAI上。原因其实也简单：由于前期刚刚过去的泡沫破裂，很多项目和设备都在闲置，更多的是系统互相之间没有联系，企业的新投资欲望也不明显，所以如果要客户接受一个新的应用是很困难的，而使用一种技术把现有的资源更好的利用符合一个节流为多数企业经营和许司令的商业现实。而同时SOA这个概念又满足了将来和现在快速的改进企业内部流程和企业外部服务过程的业务要求，所以从这个意义上说SOA对于客户是有价值的
上面是我对于SOA这个概念从业务层面上的观点，这也是我关注这个概念的核心思想。
待续。

下面谈谈SOA涉及的技术基础。
实际上SOA的实现可以采用三种主要的技术思路：CORBA（基本上都是面向消息的中间件解决思路），WSDL（也就是webservices的方式），服务代理注册方式（此种方式的解决仅仅是一些个别的人和小社区的想法，具体的实现你很难找到，因为这些信息大概都是存在于一些非公开的私下讨论中，如果SOA真的可以流行起来，我想这种方式可能会更加流行，但是现在基本上可以不考虑）。
这三种方式中我认为WSDL应该是我们关注的核心。首先我们说说CORBA为什么不是新的热点。其实这个问题简单的可以不去考虑，大家看看是IBM和BEA以及MS在搞SOA这个概念，而他们我看不出谁会想在这个时候去拉一把borland，而采取CORBA显然就是他们都不会考虑的商业思维方式了。而其次CORBA的复杂也是有目共睹的，所以推广这个技术会给IBM以及BEA带来不必要的麻烦。但是就我看来使用基于CORBA的各种MQ中间件构建SOA，是目前最实际也是最便宜的做法，毕竟很多公司和客户都在这个方面做过投资和储备。
待续。

现在说说现在流行的SOA。
当我看第一次看到SOA的时候，马上想到了前年我看到的BPEL4WS，于是我就去看看是不是他们真的存在什么关联。一看原来就是如此（大家可以自己看看WSDL和BPEL4WS的关系）。这也在一次证实了我在2000年就说过的XML将是未来20年的所有新商业应用技术的核心。而实际上实现SOA还可能需要另外的一些标准的支持，比如SOAP(缩写都暗示了他们的关系，哈哈）。
不过现在几乎IBM的SOA都是建立在WS的基础上的，BEA的我还没有去研究，不过我想BEA大概也不会花费很多的资金去制定更多的标准。
实际上可以说SOA没有提供任何新的东西，也没有做成任何新的承诺。它只是在现有技术上的一种重新组织，一种新的内部的协调机制。

最后我说我认为的SOA的未来。
我认为SOA没有未来，它只是一个过渡性的热点。现在任何技术如果要有持续的热度，首先不是看它是否满足了最终客户的需求（不能满足客户需求的技术会成为热点吗？），而是要看它背后是不是有什么新的开发方式和技术变革。实际上作为我们这些软件开发者都明白，改变我们的编程习惯是多么的困难，所以几乎所有的敏捷方法学家对于敏捷的突然走红都表示足够的惊讶。而这些习惯一旦养成，就会对于他们开发中所使用的技术产生很强的反作用。比如敏捷的客户参与原则，现在基本上不会有任何的方法学家敢于出来说，这个原则是错误的，而只能说敏捷做法可能在客户那里得到的支持不能满足敏捷的要求。而敏捷方法对于测试和快速发布的要求，又使许多的需要大量前期准备和后期部署的技术根本就得不到任何人去关注。而一旦一种技术思想成为一种开发思维习惯，这样的影响也是长久的。比如面向对象技术，到现在已经20多年的方法学历史，但是还不断的被人从新包装，比如这个SOA其实就是一种面向对象的扩展。
但是SOA背后所代表的东西几乎没有新的，这会在今后某个经济大发展的时候造成销售热点的缺失，这不会有利于各大厂商面对下一次的经济大发展。因此上若想SOA得到长期的被关注，唯一的条件就是经济一直这样不温不火的颓废下去。

实际上分析现在任何技术热点的思路，其实方法非常简单，无非就是XML和构件。SOA就是这两点的一种组合方式，随后会在适当的时候被新的组合方式代替。而xml实际上就是数据库新的包装形式，再加上使用xml定义的一堆标准。而构件化则就是以Architecture为核心的构建的企业核心资产系统。一个软件公司在今后的竞争中没有这样一个企业核心资产系统将没有存在的可能性，而如果按照一个所谓的公开的标准去简单的建立一个这样的系统将也会很快的死亡。企业如果想生存就必须建立起以自己独有的技术所支持的自己掌握支配和控制权的Architecture，这个结构可以支持别的标准结构，但是绝对不能是一种依赖于其他标准的结构。

当然我还有必要说说商业流程在企业应用中的地位。实际上流程这个东西在日本的企业中是核心，而在美国的企业中只是一种记录。也就是说日本的企业关注于你办事情的过程，他们认为如果你按照规定的流程进行了工作，你的任务就被认为完成了。而美国的企业则认为如果你按照一定的流程进行了工作，但是没有达到开始的目标，你一样没有完成任务。而不管任何的管理体系对于BPR的重视都是十分显著的。而作为现代企业运作的支持系统的IT软件，基本上都是为了满足能更简单更便宜的BPR。
而实际上对于商业流程来说很多的企业都是在追求一种随需而变，随人而变，随时而变，这样一个理想的状态。而企业经营和商业流程的不可重复正在愈来愈多的被各个管理学派认识，特别是现在的同质化的竞争更加加剧了企业对于一个可变流程的渴望。实际上对于商业流程的可复用性，是上一代企业信息系统的关注点，而现在的企业更关注的是流程自动化改革和智能化的流程可再造。
而SOA由于其对BPEL4WS的支持可以很简单的快速定义一个商业流程，而且这种xml语言会很容易的被以某种逻辑去生成和改变。

说完了流程还有必要说说数据。
数据是企业商业活动的各种记录。企业的经营的历史和状况需要这些数据来表达，这些基本上是所有的企业应用系统的必备功能。但是由于企业越来越追求客户的个性化服务，使得这些单纯的记录变得价值不大。而依照这些记录按照某种方法进行的预测和及时地流程优化，才是这个时期企业应用的关注核心。而对这些数据的分析就是datamining，而需要做到智能化的商业流程就必须以数据挖掘为核心进行建设。
但是现在请大家注意，有一个问题几乎没有人提起过。由于企业的流程的智能化和流程的可变性，会带来流程的多元化和多样化，从而带来数据的多样化的，这个时候传统的关系数据库是否能够面对这样的多样化的个体化的数据，很让我怀疑。而对于这些更加零散和结构联系不紧密地数据该采取什么分析的方式也会变得困难起来。当然从数学和统计学来看这样的问题不是问题，但是如何把这些理论的解决方式应用到实际的商业运营中确实是一个难题。
SOA由于其对流程的友善，可以很好的去完成流程改变的任务。但是SOA并不能给你的商业分析和决策支持带来什么明显的好处，唯一的优势只是能更快的掌握数据和流程的状态，但是这个优势如果不能转化为智能化的决策支持就将变得毫无应用价值。企业会因为存在的太多的流程，造成管理的混乱。而由于存在流程的简单设立，会使各种以前不可想象的复杂流程变得简单起来，但是建造流程的简单并不等于控制这个流程的简单。

最后作一个总结，SOA提出了一些新的想法和思路，但是没有提出新的技术和方法。同时由于SOA所需要依赖的很多企业数据处理系统的滞后，所以这个概念将会很快的被新的概念所代替。
但是就目前来说，使用SOA去EAI还是一个时髦的做法。不过由于原有系统的复杂，单纯的SOA并不是一个好主意。同时由于SOA我们只看到了IBM和BEA的牌，还没有看到MS的牌，所以现在就判断SOA是否真的能在最近火一把还早一些。不过如果MS还是对SOA态度这么暧昧，我想在最近SOA热一下还是可能性很大的。

我提一个问题。你提出数据挖掘是企业应用最应该关注的。

不过就当前的实际情况来说，那些积累了海量数据的大型公司往往不是你可以打入进去的，他们都有固定的客户关系和合作伙伴，不会轻易信任你的。也就是说这些大型公司就算有需求也有很高的非技术壁垒，使一般的软件公司无法分到一杯羹。而那些小型公司，仍然在企业信息化的进程之中，数据积累不够海量，还提不到数据挖掘的需求。

我说一下SOA在我们公司的使用情况, 我们的主要业务给retailer和vendor提供是data warehouse和基于其上的reporting和olap service,
客户包括walmart, target等全美主要大的retailer chain.

我们的数据库用oracle, data loading和data minning都是stored proc实现的, reporting engine是用delphi和excel做的, web publishing和olap是用java struts和data beacon. 由于我们有很多异构环境, 一直以来我们面临的主要问题就是domain model的共享, 早前我们都是用oracle stored proc来解决
model共享, stored proc可以返回一个flat的ref cursor供java或delphi使用, 但这个model不是object based, java和delphi里都得用各自的OR mapper去再包装, 我们曾看过CORBA, java com bridge, 但结果都不理想, 不是太复杂, 就是太慢, 没有用起来的, .net出来后, delphi也支持.net了, 我们就开始试.net和java的interop方法, 试过borland的janeva, 他用的是ejb rmi 和.net连接, 还有JaNET, 他用的是net remoting, 也都不work, 原因一是他们都是单向的, 二是在term里使用时遇到的问题较多.
最后我们用web service, 用asp.net web service和java Axis, 目前我们的domain都是用asp.net web service结合我写的一个和stored proc连接的很好的OR mapper来实现的, java 和delphi client端使用的都不错
我们还实现了在oracle里用java stored proc调用web service, 提供给stored proc client用, 不过这种性能不好, 用的比较少.oracle 10g提供了native plsql调用web service的sdk, 还没试

MS的EAI产品是Biztalk，从2000年开始的第一版到2004年第三版，都是基于WebService, XML的，我知道的国内一个非常大的数据报文交接系统（不知道是不是国内最大的？）就是基于Biztalk、MQ的，每天有1亿多条数据在上面跑。

现在微软的全线产品都在加入WebService的支持，比如Infopath, SharePoint, Reporting Service等等。