SOA焦虑症

1996年，Gartner提出了SOA概念。

Gartner还曾提出两个很著名的概念：

ERP，企业资源计划。以企业资源的角度来组织企业的人、财、物、信息。此概念产生于大生产时代MRP以后，号召把企业的上下游也归入到企业通盘战略考虑当中。由于社会已经变成了产业链，从原材料到生产到物流到销售到售后服务，每一个环节都影响生产企业。生产已经变的不是第一重要了，供不该求时代已经结束。进入营销渠道的时代。

CRM，客户关系管理。以客户服务的角度出发来从新组织企业的人、业务、流程、信息。此概念在ERP的基础上，把眼光从供应链上游和生产企业转移到了客户终端。生产时代结束，营销推销时代也快结束，不考虑客户感觉，不和客户交互交流，一味生产和推销，是不可能获胜的。

（从什么角度来组织资源和流程，颇像技术界的面向过程、面向对象、面向组件、现在面向服务了）

在这样的大背景下，Web2.0也是顺应这个概念产生的，口碑营销、精确分众、圈子、即时通讯、短信、博客，各类交互工具顺应时代而产生。

ERP和CRM都是应用层面的产物。

这样的应用，在信息化方面如何落地。

因而，SOA概念随即而出。

1996年的美国，互联网已经很发达了。可是互联网技术并无跟上。企业仍然封闭在本身的信息化世界。虽然有CORBA、COM+、RMI/EJB这些技术模型在支撑，但向互联网公众提供信息服务，而非上下游合做伙伴提供信息服务，CORBA、COM+、RIM/EJB仍然在穿透防火墙和通用数据格式传输上仍然存在问题，三个体系都有本身的通信协议和数据传输协议，普通消费者没法参与其中。

2000年，XML产生。随机基于HTTP的SOAP、WSDL、UDDI产生，Webservice做为一个基于互联网通用技术基础上发展的数据通信协议和数据传输访问协议体系产生了。

可是Webservice只是定义了基于通用互联网技术的数据通信和数据传输访问。就至关于底层通路通了。可是基于上面的应用呢，仍是没有一个规范。就至关于，路通了，可是在这条路上什么样规格的车跑起来最顺畅，尚未这个规范。（固然你能够不要规范，本身造个本身的车，之后在和拥有统一规格的车一块儿管理和运行时交互时就有了问题。这个描述也为了回答至关一部份人提出的那个问题：咱们既然有了Webservice，那干嘛还要SCA/SDO呢？）

SOA就是干这件事的。

可是，SOA，业界大佬太急。就如同在.COM大潮中，每一个企业都急于申明咱们是一家.com公司。因而，这个市场混淆了各类视听。

作工做流的、作OA的、作业务基础平台的、作组件的、作中间件的、作EAI的，都号称本身已是SOA了。有的说SOA是为了业务敏捷（能够灵活调整系统以适应快速发生变化的业务竞争。现摘录一段话：SOA经过把传统应用模块分解成更小的构件，并把这些构件看成能够重用的Web服务，CIO们就能经过选择和安排所需构件，来生成最贴合的系统。这和当年咱们作WINDOWS DNA架构是多么类似。但当年SOA已经提出，但并无人说WINDOWS DNA架构是SOA架构。没流行这个名词的缘由？？），有的说SOA是为了系统整合，有的说SOA是企业总线，有的说SOA是种业务分析设计思想，有的说SOA是技术架构模型，有的说SOA相似UML的做用，可使业务设计人员和技术设计人员有共同语言，有人更说SOA就和web2.0同样，就是个概念。颇像当年微软急于把本身全部产品都打上.NET标志同样，最后弄的你们都搞不清楚什么是.NET了。直到2007年发布WPF、WCF、WF以后，.NET的技术走向才算基础架构定型。SOA和当时的.NET很是类似。

现在，SOA规范才真正落地为SCA和SDO。工做流规范业界已经成型，WF也符合业界工做流规范，因此SOA中并无定义工做流规范。而对应WPF的SOA显然也不须要，毕竟SOA考虑的是业务接口服务层面，而非这个服务以什么样的图形界面规范来让客户存取，没有必要（中国普元补上了这一环节。中国普元也是OSOA顶级成员之一。光有接口没有UI，仍是须要程序员动手写这个UI，业务人员不可能没有UI去作灵活改变业务功能和流程，即便有BPEL和DSL也不行。别给业务人员任何技术的东西，别想着DSL和UML就能让业务人员用起来）。因此，SCA和SDO已经够用了，SOA架构真正成型。

但SCA和SDO是2007年8月才定型的（虽然2005年已经草案了）。因此以前急于号称是SOA产品的厂商不知做何感想。

我阅读了SCA和SDO标准，我也对比了过去我研究的CORBA，我也对比了微软的WCF，架构思想竟然很是相似。

当年DEC和IBM主导定义的CORBA，太复杂，SUN和微软都作了定制化裁减，发展了本身的RMI/EJB和COM+。因为Webservice的出现，微软当即发展了基于Webservice的架构体系：WCF。可是JAVA世界因为标准制定牵扯了大量厂商的利益，发展缓慢。而IBM也不肯意尴尬的在SUN的JAVA世界作个影子巨人。IBM一直盘算着如何作领袖。

因而SOA真正架构，吸取了CORBA的教训（IBM因为当年的CORBA没有带起业界标准非常懊恼，此次要卷土重来，更加学聪明了，谁说大象不能跳舞），也结合了Webservice，也借鉴了WCF（WCF也是在Webservice基础上发展起来的架构，不少技术借用了Webservice的技术，而非另起一套底层），终于产生。

而OSOA组织，最近才出现SUN的踪迹，而SCA和SDO标准中并无SUN提交的草案。

JAVA和.NET两大平台，封闭而专有。而IBM须要的是一种业界标准制定者。SOA这回达成了IBM的意愿。不管是JAVA，仍是.NET，甚至是PHP，只要符合SCA和SDO，就能够提供业界标准服务接口。

挣脱了语言和专属平台优缺点的樊笼，IBM蓝色巨人又成为自由的业界之神。

我为何这么关注和信任和理解SOA。其实和我自身所处的软件行业很是有关系。

我是作企业管理软件的。很早业界就都有共识：软件不能这样卖了。咱们把一套办公系统卖给了运营商，人家用咱们的软件作服务，收费比咱们卖软件还多。

因此，就连卖软件老大微软也在喊着软件服务化。

过去是在企业内部运行的软件，一个企业不外乎也就那么多人那么多数据。可是，一旦把软件服务化、互联网化了，就不抵有多少人访问了。

因此，咱们如何应对软件服务化、互联网化。

上亿人访问的Webservice，其架构就不能象搭建企业内部运行的软件架构，你看Google，都有几十万台PC集群的计算资源才能支撑互联网服务。咱们过去的传统的企业内部机房磁盘阵列和计算机集群架构不适合在公网上了，咱们的数据库也不适合服务几亿人了。

因此，我特别关注咱们如何软件服务化，软件服务化的架构是什么样的？

其实，业界都在往一个方向跑，不论是Google、仍是Yahoo、仍是微软、仍是我们的百度、QQ、盛大、阿里，你们都在往软件服务化、互联网的方向跑。（若是你仅仅是把眼光放到SAAS，放到和过去的ASP[应用服务托管]去对比，眼界显然须要更高一些）

应用软件运行须要基础设施。首先，基础硬件设施，几十万台PC的集群如何虚拟文件系统和计算资源分配，这就是云计算要解决的问题。如今云计算是个热门，Yahoo、Google、IBM、微软都在研究和建设。但微软慢了一步（微软在互联网计算上一直不敏感，用传统软件的方式看互联网），因此WFS没有出来（可能没想通做为集群中的一个节点资源，如何加入集群，和集群同构，还能符合我的桌面计算管理）。

有了云计算硬件基础，还须要数据存取软件基础。有了分布式文件系统，文件存取应该没什么问题，但关系数据的存取，这是如今全部数据库产品都没有解决的。Amazon看到了机会，推出了S3服务。全球互联网就是个超级计算机，而S3就是这个计算机上的数据库。

而全部的SOA应用，都必须在一个容器中运行，不然，有外界调用这些服务，这些服务运行中使用的资源谁来管理呢（不少人不明白容器是干什么用的，不明白中间件的来历，也不明白为何JAVA和.NET都要作容器。若是你作应用，你本身还要负责那么多底层的分配与释放与并发，那么你作的既不专业，也累，也不稳定，不如交给系统商去管理）。容器负责内存、资源的分配、调度、回收，负责安全，负责事务，负责并发，负责池化。而这些SOA服务，也必须能随时升级，就必须具有软件热插拔的功能。如今热的OSGi研究就属此类。

有了这些基础设施，咱们的应用就必须SOA化，成为软件服务，让全部人来使用。使用者一方多是一个C#写的客户端，多是一个PHP网站，多是一个JAVA网站，也多是一个FLASH。

全球大大小小的公司提供了这么多Open API，如何调用。用各自的语言？JAVA？C#？PHP？Javascript？

我想会产生一种新的语言来组织这些Open API，而不是这么技术化的程序员使用的开发编码语言。

它，会是DSL。Domain Specific language。它可能会高于Javascript，但和Javascript相似，但又低于JAVA，C#这些重型开发语言。但它确定是动态语言。这样随时改变流程，随时改变应用。这就是业务敏捷。

这就是我预想中的将来SOA时代计算环境。

你，还在用传统的业务基础平台思路搭建企业管理软件架构吗？

将来SOA时代，将来软件服务化时代，你，准备好了吗？

后记：
20%的企业在上第一代系统，不须要SOA。但软件产品提供商须要考虑SOA，以防将来的集成。但如今对于企业没有需求，不会由于SOA加分买单。
30%的企业在所有替掉第一代系统，不须要SOA。但软件产品提供商须要考虑SOA，以防将来的集成。但如今对于企业没有需求，不会由于SOA加分买单。
30%的企业在整合本身内部的第二代系统，可能须要SOA，但实质上采用的少。但软件产品提供商须要考虑SOA，以防将来的集成。客户可能会由于SOA加分买单。
10%的企业在整合本身的上下游，须要SOA。
10%的企业开始为最终客户提供信息交互服务，如同咱们看到的Google API同样，须要SOA。

如今关注和编写SOA时机正确吗？正确，由于你看上面的比例，有50%的企业有SOA需求。 但若是你面临的客户市场偏偏不是这50%，而是另外的50%，那么奉劝你继续作好如今的产品，SOA还不须要。