摘要：SOA和SaaS(SoftwareasaService)之后，下一个自然的演化--当位于堆栈上层的应用(CRM,SFA,...)被服务化、租出去之后(即SaaS)，接着下来就是下层的服务基础设施了。

　　以前写过一个关于Amazon Web Services(AWS)的帖子，这应该算是第一个对Web2.0/SOA基础设施租赁市场的大规模尝试。不久前接受采访，起因于微软的Internet Service Bus，一个小规模、提供给开发者作实验性的尝试。
　　
　　我对AWS、以及它所试探的潜在市场，基本上乐观其成，自从AWS推出S3,SQS和EC2后，已经出现了许多有趣的加值应用，例如有人用它来建构新一代的B2B/EDIVAN，DougKaye在这个podcast中，则侃侃而谈，说明如何利用AWS的基础设施，设计出GigaVox这个podcast平台的架构。在podcast讨论中，Kaye除了讲解他如何善用Amazon出租的数据服务S3，中介消息服务SQS，和建立在Xen上的虚拟化平台EC2，来设计出他的应用架构外，还谈到作为一个earlyadopter，所遇到的种种限制问题，如何克服，更提供了Amazon未来对AWS的改进参考。不意外，就像所有软件一样，这种直接通过网络租用的软件服务，目前仍属于非常早的阶段，当然还有不少可进一步完善的空间。这类的案例，非常有助于我们对此类服务的完备和成熟程度，进行更客观的理解。
　　
　　如果从投资/管理的角度，AWS的确是比较大胆的尝试，所以我之前曾以“豪赌”来形容。我们看它最近的财报，对AWS运营的情形，只敢简单提提有几十万的注册开发者，数据库被存了十几亿个对象，但不敢提实际的损益情形。这就像默多克的新闻集团一样，买下了MySpace，但现在MySpace在整个集团的财报中，还只能隐含在“其他杂项收入”中，占非常小的比例，其他的几乎都来自它的本业(传统媒体)收入。但话说回来，许多商场上的一代枭雄，凭藉的不正是快、准、狠的大胆投资气魄吗?而历史上后来大发利市的商业模式，当初也有不少是误打误撞的结果。
　　
　　不扯那些了，来谈谈这个新模式本身所代表的意义，这种服务基础设施的租赁，可以视为是SOA和SaaS(Software as a Service)之后，下一个自然的演化--当位于堆栈上层的应用(CRM,SFA,...)被服务化、租出去之后(即SaaS)，接着下来就是下层的服务基础设施了。Salesforce.com现在强力主打的Force.com平台(稍早曾称为SalesforceSOA、Apex)，正是最好的例子，最近更打出"Platform as a Service"(PaaS)的顺口新词。SaaS现在已经有许多的媒体讨论，不再多提，SAP最近宣布正式进入这个市场，也让它更加热闹起来。而PaaS，可以说是进一步把支撑应用的下面几层功能，可以从中间件一直到数据库、还有虚拟化的OS环境，也分别通过网络出租出去，通过网络来进行远程开发、配置、部署，最后直接执行在提供hosting服务的厂商的计算中心内。
　　
　　Salesforce.com号称，客户不只利用他们的Force.com平台做mashups，集成GoogleMap这类Web2.0网站的Webservices;而更已经有客户，利用它来成功集成了企业防火墙内的SAP应用。当租用SaaS的那些企业的IT，对“服务”的概念和实践经验，有了愈来愈深的领悟和掌握后，自然而然将促进企业内更多非租用、自行维护的系统的服务化。所以SaaS和PaaS的出现，对SOA是非常正面的发展。可想而知的是，先期采用PaaS模式的企业，绝大多数会是那些现有的SaaS客户，他们对于直接通过网络进行远程操作和管理的模式、对效能和可靠性等RASP(Reliability,Availability,Scalability,&Performance)方面的顾虑，租用合同相关事宜等方面，都有比较大的信心和比较好的掌握。再者，因为他们已经有某个重要系统(CRM,SFA,PLM)是以SaaS方式向人租用，很自然地会逐渐有各种业务需求，需要把这些外租的SaaS应用和内营的其他应用，如ERP等，进行集成。这时候，PaaS业者会游说：与其你自己花工夫去购买、学习、管理整套SOA的基础设施，何不干脆也向我们租用，反正你要集成的主要对象之一--你的{CRM|SFA|PLM}系统现在已经跑在我的中心里了，从你内网的集成平台来远程整合我的{CRM|SFA|PLM}，和租用我的集成平台去远程整合你的ERP不也差不多吗?而且，你过去在租用我的{CRM|SFA|PLM}时，就已经用过我们的开发工具箱了，对我们的开发、配置环境已经很熟悉，你现在可以不需要学习新的语言、工具，便可很快上手使用我的集成平台，何乐而不为?
　　
　　从学术的角度，如果拿我们常讲的SOA层次化架构(参考架构)，堆栈中的各个部件：
　　
　　来和Force.com的架构(如下)相比，会发现很多有趣的相似处。至少在概念上，这些"XXX as a Service"中的XXX，把典型SOA中间件所提供的展现层、集成层，和数据服务层的功能，都划进来了。当然，其功能性到底能达到什么程度，还有待检验，但由于模式和设计目标的不同，加上目前仍处于非常前期的阶段，我们不用期待它会有一般SOA平台产品中的portal,ESB,integrationserver,数据服务平台等来得那么丰富、强大--实际上可能恰好想反--AWS的S3和SQS就是很好的例子，由于它们在先天的设计上，必须高度的松耦合;与传统中间件相比，“极简”反而成为它们主要的卖点和价值，这是S3,SQS从命名上便想强调的特性--Simple(当然，Force.com相较之下，会比AWS来得紧耦合得多，和它既有的应用平台有相当程度的捆绑，因为它当前主要的客户目标，是针对租用它CRM应用的客户，通用性上不如AWS)。此外，与上图相对照，我们看到Force.com目前还少了业务流程服务(BPM)这层，还有ESB也尚未出现，不过将Intergration-as-a-Service这层加以延伸，增加ESB功能的相关讨论，已经出现了。
　　
　　责任编辑：小楠