业务过程开发人员

    在这个业务过程层中有两种截然不同的类型：一种处理业务过程建模，另一种处理业务过程与底层服务和系统的集成。在某些公司里可能会让一个人完成这两项任务，但是更多情况下这会是两个人的工作，因为这两方面需要不同的技能。负责业务过程建模的人甚至可以不是IT人士。某些公司在业务方面设有专门部门，部门中的人主要负责改善并自动化业务过程。（这种公司都是使用6Six Sigma或全员质量管理的公司。）

    业务过程集成是一个技术活，它需要Web服务、REST、JMS队列或其它类似的专业知识。负责集成的人是将业务过程与控制业务服务流程和组合业务应用（通常称为编排）的后端技术联系到一起的人。

    业务规则开发人员

    这一类型有点模糊，并不是所有架构都有一个具体的业务规则层。某些情况下，这些业务规则是在数据层中进行控制的。对于那些有非常动态的业务规则，特别是以客户为中心并且允许终端用户甚至顾客更新规则的公司来说，提取出一个业务规则层来是很有必要的。如果公司有一个业务规则层，并且使用某个工具来管理业务规则，那么这个公司很可能会需要一个技师来管理这一层，就像数据库维护人员维护数据库层一样。在某些情况下，这份工作也可能交给数据库维护人员来做，当然这是灵活的。

    不管由谁来做，他们都必须明白这一层的含义并寻找能让终端用户更快地对业务变化做出反应的办法。比如，一个贷款审批程序需要这样的一个特定状态的业务规则：贷款申请人需要具备多少比例的资产才有可能得到审批。这个比例值经常要根据状态进行改动，所以必须能够尽量快地保持更新。非常好的的办法是把IT从这个过程中剔除出去，让某个具有授权的特定的人（或系统）按需对这个值进行更新。不管是谁负责这个业务规则，他都必须能够与业务部门和/或业务分析员共同协作，明白变动的频率、许可权限以及各种业务规则所带来的影响。另外，与此相关的还有大量与创建和管理规则相关的日常支出，负责人必须能够权衡利弊并做出决定。

    数据服务开发人员

    或许我们应该称他为信息结构工程师。他要负责提取底层的数据层并将其暴露给架构中的其它层，甚至提供给外部的其它系统。比如，假如购物车业务服务允许多种支付方式（美国运通卡、Visa和Pay Pal）。另外，不同产品（书籍、DVD、衣物等）分别由不同的库存系统进行管理。我们需要隐藏这些复杂的东西，并可以随时添加其它的支付服务和库存管理方式。因此，我们使用数据服务来为购物车提供数据的逻辑视图。也就是说，我们创建了一个可以提供给购物车的标准的支付与库存信息。只要购物车使用的是这些标准消息，那么底层的各种支付与库存服务的物理实现就毫无干系。购物车服务只需要识别这些信息的标准格式，而标准信息到接收系统的转换工作就交给数据服务层。

    这一层的开发人员（或架构师）必须具备数据建模和数据库设计领域方面的知识。即使公司有工具可以管理这一层（我们也建议这样做），管理员这一职位也是需要的。

    数据库开发人员

    现在各个企业通常都有这一层，这就是DBA工作的地方。在SOA环境下，DBA必须更紧密地与架构中其它层的开发人员合作。他们必须明白各层的安全与性能要求，并保证底层的数据模型能够满足这些要求。因为旧系统的集成在当前的SOA建设中还很常见，所以通常都会需要DBA创建结构的视图，甚至建立新的ETL过程为架构中的其它层提供数据视图。

    安全开发人员

    虽然安全专家们可以不做实际的开发工作，但是必须有人或者有团队能够了解当前SOA所面临的安全方面的挑战。SOA可能会产生以下威胁：

    · 暴露原本不可暴露在防火墙外的旧系统
    · 多系统之间的免登录切换需要信任
    · 将一条信息分别按不同的安全准则发往多个合作伙伴
    · 将信用卡或其它隐私问题暴露到网络上

    现在的多层安全模型在B2B类型的SOA上尚存在许多不足。这一领域的开发人员必须对信息协议、安全性非常好的实践、网络架构、法案（比如HIPAA、SOX、PCI）和WS-*或其它标准有深入的了解。

    总结

    我们可以看到，成功实现SOA需要多种截然不同的开发技能。要找到一个熟练掌握所有技能的人是不实际的。即使有这么一个人，那么他也只可能在你的架构团队里。这个架构的高明之处在于它能够把各层的问题分解并解决掉。一个业务服务可以由各层的许多人员共同完成。这需要坚固的治理、扎实的技巧和团队协作，而这也正是为什么需要在合适的位置安排合适的人来解决SOA中出现问题的原因。下一篇文章将讨论SOA系统中测试人员所需技能，以及他们与开发团队的关系。