【IT168 分析评论】

    自从它达到炒作的顶峰之后，人们就一直在说：早在SOA被普及之前，SOA原则就已经存在很长时间了。针对分布式系统和EAI的松耦合方法就常常被拿来与延迟绑定软件模式进行对比。软件开发原则和实践已经持续进化了几十年，而且常常完全以达尔文的方式进化。我们已经有了好几代编程语言，如象Prolog这样的第五代语言。现在，按照Kirstan Vandersluis（XAware的创始人和首席科学家）的说法，我们应该认清这个事实：我们至少已经经历了4代以服务为基础的架构方法。

    在整个行业中，聪明的架构师一直（多年）以来就将功能暴露为可重用的服务。这让我开始思考这些年来面向服务架构是怎么演变的。我们这些用SOA工具扩展功能的人已经意识到服务和SOA早已存在多年，远比近年出现的那些使SOA变得流行的“Web服务标准”早得多。在软件产业中，很明显我们已经经历了面向服务实现的几个成熟阶段。

    Kirstan回应了这种感受：有时SOA与Web服务联系太紧密了。他认为我们远没有达到能够认识到SOA全部潜力的地步，这些都需要时间。

    传统12或18个月开发周期涉及的分析师和开发者军团被替代成了画新过程流程图的业务分析师，然后就是点击按钮来部署可用在企业中的基础设施。“面向服务”方法使用零碎的工程资源按天或周来衡量工作。

    然而，就像我在其他地方听到的，有时里程数可能变化。并且通过一些隐含/内嵌的万灵药，SOA项目不会自动成功。但是就像Kirstan所暗示的，这是世代的问题，并且随着我们的成长我们会变得更好（或者会出现其他什么东西）。根据Kirstan的说法，我们已经有4代（到目前为止）以服务为基础的架构：

    第一代服务 —— 用第三代语言（如C、C++、C#或Java）编写的简单服务，它们不使用如WS-*或REST这样的现代SOA标准。这些服务倾向于将消费者和底层资源紧密耦合。老的分布式计算技术，如CORBA和DCOM，也属于这一类。

    第二代服务 —— 以标准为基础的服务，而且相当简单。如实现一个检索、修改、创建或删除一个数据库中数据集的操作。这些服务常常可由其他途径（如从Java或C#类、一个EJB、或一个数据库查询）自动产生。这些服务倾向于反映一个对象上的一个方法，或暴露一个底层实现策略（如关系表）。它们很容易创建，但因为它们是以技术为中心而非以业务为中心，难以在一个业务过程中使用。相反，它们需要和其他服务与逻辑结合，为编制提供合适的粒度级别。

    第三代服务 —— 真正的“面向服务”，这些服务在向业务过程靠齐方面前进了一步。松耦合可以通过显式的定义服务请求和响应主体的数据格式来获得，这些格式由了解手边业务过程的分析师驱动，而非试图最优化执行时间和存储需求的技术。为了获得一个适合编制的粗粒度服务，常常需要缝合和转换第一代和第二代服务，同时这样也能获得松耦合。

    第四代服务 —— 制度化的第三代服务，这些制度用来管理、保护、治理和重用服务。第四代SOA涉及一个感知SOA的技术和过程的生态系统，它允许构造和管理业务过程和更高级别服务。一旦达到第四代服务，一个公司将最大化SOA的好处，使他们能迅速地创建和修改过程来满足业务需求的变化。