传统的三层架构通常包括一个呈现层、一个中间层或应用层，和一个数据层。在某些情况下，开发人员要负责这三层的所有工作。在较大规模的公司中，可能会有专门的UI开发人员、应用开发人员和数据库开发人员等。在SOA中，除了在集成应用时，可以说应用这个概念已经与SOA毫无干系。在SOA中，我们构建的是独立于应用的业务服务。下图列出了SOA所需要的开发人员的类型。
现在来谈谈业务服务。业务服务是各层所有开发人员所做的工作的集合体。比如一个像在亚马逊上所用的“购物车”这样的业务服务，它很可能是由服务和/或寄存在这个架构中的各层组件所构成。呈现层包含最终的使用方式，也就是用户最终看到并在浏览器上使用的样子。业务过程层包含引导用户从开始到最后付款结束的整套逻辑流。业务规则层包含税收、折扣、会员等规则，而底层的数据元素和结构则是在数据层处理的。在许多情况下，由于合并、兼并、多年的遗留系统、第三方应用的购买等诸多因素，公司会使用多种数据结构提供相似的功能。数据层的存在就是为了提取这些数据结构并以相同的形式呈现出来，掩盖底层的复杂实现方式（可以想像主数据管理）。
所以，要开发这样一个购物车的业务服务，所有工作在架构中不同层上的开发人员都要全力协作，并以满足公司所采用的SOA治理中所定义的业务需求与技术需要为前提。其中的技术需要可能是：
◆遵守WS-*安全标准
◆数据加密策略
◆平台无关
◆满足具体的性能要求
为什么要说这么多呢？因为在面向服务的架构中，一个成功的开发人员需要具备以下特征：
◆灵活、变通
◆协作能力
◆可以与同僚一起检查他们的工作
◆能看清大局
◆不会固执地偏好某种特定技术
◆能接受建设性的批评
◆创新精神
那些不容别人批评自己的工作或偏好某一种技术的人可能会在SOA中遇到不少困难。SOA目标之一就是构建灵活、可维护性好、松耦合、与平台无关的软件。要构建这样一个软件就必须从软件开发转向软件工程。简单来说，我们必须从拖曳的工作方式转向计划建模的工作方式。我们必须能够接受协作、同行审查和治理。如果开发人员不喜欢这些东西，他们要么选择改变，要么选择离开。否则他们将成为巨大隐患，并且一直拖后腿。
好了，现在我们来谈谈开发人员的分类。但是在此之前需要强调一下，这里讨论的是分类，而不是个体。在小型企业里，一个开发人员可能会跨越多个分类。在大型企业中，我们可能会看到非常专业化的开发人员工作在架构中的单独一层。最后声明一点：讨论的默认前提是存在一个架构团队，并且各层中存在一定程度的标准与治理。
UI开发人员
如果公司有能力专门化，那么这会是非常棒的一层。这层的开发人员并不需要非常高深的技术。重要的是他们要明白可用性、UI标准和Web界面的最佳实践。这些人可以从模拟开始，与业务部门或业务分析员合作分析各种情况，最终达到一致的结果。这些开发人员必须能用业务用语和业务部门交流，并且能明白商务用户如何使用网络技术进行交互。
业务过程开发人员
在这个业务过程层中有两种截然不同的类型：一种处理业务过程建模，另一种处理业务过程与底层服务和系统的集成。在某些公司里可能会让一个人完成这两项任务，但是更多情况下这会是两个人的工作，因为这两方面需要不同的技能。负责业务过程建模的人甚至可以不是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系统中测试人员所需技能，以及他们与开发团队的关系。
【编辑推荐】
