SOA概念已经为大多数用户和企业所熟知，同时也有众多企业开始实践SOA，在项目实施过程中不断完善SOA的技术和实施方法。长风联盟内的用户、软件企业和科研院所，在SOA技术研究、产品研发和项目实施过程中，形成若干SOA工作组，共同研究、交流SOA相关技术和规范标准，同时也形成了一些实际的SOA支撑产品和项目实施经验。
本文以联盟SOA参考架构工作组（SOA-RA-TF，由东方通、计算所、华迪、同方、有生博大、神州数码等组成）在SOA技术标准研究、SOA参考架构规范制定、SOA技术支撑产品研发，以及研究成果在实际的SOA项目中的应用经验为基础，对SOA项目实施过程需要注意的关键问题做一些总结和介绍，力图通过本文能够与各方面的SOA实践者，为SOA的应用和推广，相互交流经验，共同发展。
SOA项目实施的过程和特点
SOA项目如同其他IT项目一样，也有类似的实施过程，一个可能的实施过程如下图所示：
SOA项目实施过程
从表面的几个过程看SOA项目的实施没有什么特别的地方，能够体现SOA特点的是在项目实施过程中的每一个具体环节中，如规划阶段对标准的考虑，分析阶段对业务的详细描述和定义，设计阶段技术架构（包括逻辑架构和物理架构）的定义，实现阶段更多依赖于定义而不是编码，以及运维阶段对服务运行情况的重点关注。
下面介绍实施过程中的主要关键点。
规划阶段
在这一阶段有许多重要的事情需要做，这将决定SOA项目实施的成败。
首先是需要确定目标，对于系统的功能目标应该是明确的，除此之外我们需要重点关注的是为什么要采用SOA思想，是为了达到什么目的。在这时我们需要了解SOA能够给我们带来什么，我们希望得到什么，这两者是否匹配；也需要了解SOA适合什么，不适合什么，我们建设项目与SOA适合是否适配。如果这些匹配一致我们就可以放心进行下一步骤了，否则就得考虑是否一定要采用SOA，是否采用其他的思想和技术架构也足以解决问题。
在此我们再看一下SOA特点：
强调业务服务的复用
支持业务灵活重构
强调松耦合
强调标准的采用
我们也需要了解SOA不适合的地方：
开发简单单个应用时，不要使用SOA
构建高吞吐量应用或实时应用是，不要使用SOA
如果网络速度慢，网络不可靠时，不要使用SOA
当服务接口不确定时（即业务服务功能本身不稳定时），不要使用SOA
当安全性极为重要时，暂时不要考虑SOA
业务处理有严格的事务完整性要求时，建议暂时不用SOA
其次需要考虑系统的规模，建议第一个SOA项目不要选择太大，需要限定项目的大小，保证在不长的时间内可以顺利实施完毕，确保项目的成功。通过项目经验的积累，为后续SOA项目开创一个良好的局面和环境。SOA本身特点支持项目的递进式实现，可以采用不断滚动改进的方式实施项目。
接着是考虑标准问题，这里的标准包含两方面：业务标准和技术标准。标准的确定是过程中一直需要考虑的问题，在分析和设计阶段都需要对标准加以考虑，并最终确定项目需要采用和制定的标准。
业务标准可以规范服务、流程和数据；技术标准可以帮助确定技术架构，确定采用的技术，可以确保服务/组件的复用、组装和运行维护。
最后是组建团队，要实施好SOA项目，需要确保合理的团队成员。首先领导的参与是项目成功的保证，SOA项目一般会涉及多个部门，或企业之间的协作，没有领导的参与和重视，这类项目成功的可能性会非常的低。
业务人员参与也是一个重要因素，SOA中强调的服务是业务的服务，而不是技术实现的服务。业务服务的定义、分类，业务流程的确定，业务数据的分析等，如果没有业务人员参与，这些工作基本上是无法开展的。在现阶段让业务人员直接参与设计和实现还不是特别的现实，但随着SOA技术和产品的成熟，业务人员一直参与到设计，甚至实现阶段也是可能的，只有这样才能更好保证SOA项目实施的成功，才能更好体现SOA的价值。
分析阶段
分析阶段主要进行业务的分析和梳理，包括：业务服务定义，业务流程定义、业务数据分析和组织架构。在这一阶段需要确定SOA项目中需要实现哪些业务，业务如何复用，业务如何串接在一起完成一个工作流程，在执行业务和业务流程过程中需要使用哪些数据，以及这些数据的关系。
业务定义时需要考虑下列因素
谁拥有业务服务
谁需要使用业务服务，如何进行授权管理
业务的基本标识信息
业务服务的功能描述
业务服务的使用约束条件
业务服务使用到的数据信息
业务服务的质量特性，如可靠性、安全性和事务性等
业务服务的服务等级信息，如服务响应时间，可提供服务时间，是否收费等
业务服务的生命周期
业务服务运行时需要关注的信息
组织架构分析时需要考虑下列因素
实际的组织架构
组织架构中有哪些角色
角色管理和使用服务、流程和数据的权限。可以使用一个表格进行描述和定义
接着需要结合组织架构和服务，定义业务流程，确定一个业务流程中有哪些服务，这些服务由哪个部门/角色来使用，这可以通过一个图形描述方式来加以定义。同时需要定义业务的流程过程，业务规则等内容。
设计阶段
设计阶段实际上就进入了技术范畴了，在设计阶段首先需要确定采用的技术体系架构，准备采用的具体技术、工具和产品，准备采用和需要制定的技术标准，也需要定义SOA项目的物理环境，以及逻辑架构到物理环境之间的映射，最后需要细化整个项目的设计细节。
在确定技术体系架构时，可以参考长风联盟SOA-RA-TF工作组制定的“SOA的参考架构规范”。在确定技术架构时需要考虑下列因素
服务描述如何存储，如何使用
服务如何实现，是将已有业务系统进行服务化封装，还是重新实现，或者将若干服务进行组装形成新的服务
定义的服务如何使用，如何组装成新的服务或在一个业务流程中应用
服务之间通讯如何实现，使用什么通讯协议，是否需要可靠，是否关注效率
在整个项目中需要考虑哪些安全因素
如何获取服务运行信息，如何应用服务运行信息
在设计阶段需要确定采用的具体技术。在实现SOA项目时可以采用传统技术，也可以采用Web Services技术，具体如何采用需要进行综合考虑。
SOA中的服务与Web Services并不用划等号，采用Web Services一般更多是从标准化角度进行考虑，为了实现异构系统互联，并且更多应用于多部门系统之间，或企业系统之间的互联互通。实现SOA也可以采用已有成熟技术，如通过JMS实现消息通讯，可以保证效率和传输可靠性。
实现技术第二个方面是考虑业务流程实现是否需要使用BPM系统，还是通过服务组装技术，将若干服务通过编码方式进行组合应用。BPM方式一般应用于实时性要求不高的业务流程处理；而对于需要连续加以运行处理的业务过程，则可以通过服务组装方式加以实现。
实现技术第三个方面需要考虑服务如何实现，是利用已有IT系统，通过服务化封装实现，还是重新实现。对已有系统进行服务化封装时不一定要封装成Web serivces，服务描述一般是统一的，具体实现可以是Web Serivces，或EJB，或BPEL，或一般的JAVA或C/C++程序。
在设计阶段需要实现逻辑架构与物理架构之间的映射。在总体体系架构设计时一般更多的从逻辑角度进行考虑，需要将业务转化为IT技术架构。同时也需要进行物理架构的规划，同时确定逻辑架构到物理架构的映射。
物理架构需要考虑整个系统中有多少独立的运行节点，有多少已有的业务系统以及需要建立的新的业务系统，需要考虑这些已有或新的业务系统都在哪些节点上运行。其次需要考虑业务系统之间如何进行通讯，以及业务系统之间的通讯转换到节点之间的通讯。
在业务流程实现时需要考虑是否需要BPM系统，需要多少个。一般一个BPM系统有一个独立的服务器引擎，在服务器引擎上可以运行多个业务流程。在现有技术条件下，一般一个业务流程的执行都在一个服务器引擎上运行，如果需要跨多个服务器引擎，则需将某一流程定义为一个子流程，同时封装为一个服务，供另一个业务流程使用。
在物理架构中需要考虑是否有一个独立的服务注册中心，需要确定服务注册中心与运行节点之间是联机的还是脱机的。
在设计阶段最主要的工作是进行系统设计的细化工作。在细化工作中包括：
服务定义的细化，包括服务接口、质量属性、服务等级等信息，另外的部署信息可以在实现和部署阶段加以定义。
服务的细分和组装，在设计阶段需要确定哪些是原子服务（不可拆分），哪些服务是组装服务，哪些是流程服务。同时需要定义服务的实现方式（原有系统封装，重新实现，服务组织，服务流程）
定义业务流程，通过工具详细定义业务流程，包括异常处理。
定义服务应用到的数据对象。
在设计细化阶段需要对服务进行有效管理，以便能够方便的查找到相关服务，也能保证经过授权的人员才能使用相关服务，或者修改服务。
实现、调试和部署阶段
SOA项目实现与传统IT项目实现有较大差别。在传统项目中几乎所有的代码都需要编写实现，或使用已有的公共代码库。而在SOA实现中，很多工作是通过定义来完成的。如在设计阶段定义服务接口，定义服务流程，这些工作并不需要手工编码，而更多的是通过工具进行图形化操作实现信息的定义。
在实现阶段还有一些其他的定义工作需要进行，如：
数据对象转换的定义。不同服务使用的数据对象可能不完全一样，为了实现服务之间能够顺利通讯，需要在数据对象之间进行数据转换，这些工作也可以通过工具定义来实现，当然也可以通过编码方式实现数据对象的转换。
服务适配器定义，将已有业务系统封装为服务接口。
运行环境的定义
服务程序打包和部署
在SOA实现阶段，有可能有一定的编程工作，如新服务的实现，复杂数据对象之间的转换，负责业务系统的服务化封装等。
在SOA项目中，系统的调试会是一件比较复杂和困难的事情，不同于一般应用系统可以通过单步跟踪来调试整个系统。在SOA项目中可以借助于一些工具实现部分的跟踪调试功能（如BPM的调试），还有很多工作需要通过编写日志方式来跟踪和检查运行是否符合设计要求。
SOA项目的部署一般可以借助于产品工具，实现自动部署。如果没有这些工具的辅助，部署工作就会比较复杂，因为涉及多个分布式的节点，需要连接不同的已有系统。
通过工具进行部署时，也有自动联机部署，和脱机部署两种模式。自动联机部署时，可以在中心通过工具产品自动将打包文件部署到运行节点上，系统可以自动展开并进行运行。手工部署就需要将打包文件手工安装到运行节点上，并运行展开和执行命令，才能使系统正常运行。
在部署过程中需要对运行环境进行定义，并定义服务与运行节点之间的对应关系，同时需要定义相关的运行参数。
运维阶段
SOA项目的运行维护阶段也是整个项目重要的一个环节。
通过对运行过程的跟踪，可以了解整个系统的运行情况，如哪些服务被请求的次数最多，哪些服务运行最稳定，哪些服务的运行不太服务设计要求（如响应时间超过要求）；可以了解哪些节点运行负载比较高，可以了解数据通讯的流量。通过这些信息一方面可以了解整个系统是否满足系统的初始需求，另一方面也为系统的优化提供数据依据。通过这些监控数据，可以更好地对系统进行优化完善，体现SOA逐步改进的特点。
总之SOA项目的实施与传统IT项目建设还是有较大差别的，在项目中首先关注点在于服务，从服务的定义，使用到运行管理；其次强调标准和基于模型的开发过程；再有就是强调实现过程中的定义活动，通过对服务的组合应用，缩短系统建设周期，这些在项目实施过程中是需要加以重点关注的。