SODA方法的作用

    对SODA而言，所有的资源都被认为是服务（从前端的UI组件到与后端外部业务合作伙伴的交互）。在这里，绝大部分开发人员的首要开发行为是编排这些服务。当所选的SODA工具没有提供相应的功能时，则由少数几个J2EE和集成方面的专家负责开发服务的实现和/或扩展。

    依赖性抽象——抽象（以及自描述和发现）是SODA的关键：对服务实现的抽象，对具体数据输入的抽象，以及对诸如在用户接口背后进行连接和业务服务开发之类的行为的抽象。

    重新调整工作划分的重点——SODA方法提供了足够的自动化、实现抽象和模拟支持，从而允许更加逻辑化的垂直工作划分。每个团队都负责相关功能的一个完整垂直片断，而且并不是始终依赖于另一个团队（他们采用另一种方法），当前的水平划分就是这么做的。

    支持业务流程设计——SODA允许设计人员以图形的方式同时开发表示和业务服务，专注于从Web页面到后端集成交互的流程流。可以以图形化的方式开箱即用地配置服务和数据转换。SODA工具在幕后自动实现企业架构和J2EE设计模式。

    服务发布和发现——SODA工具通常提供一个统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）服务器（或另一个类似的注册库），或者与之交互，因此支持把服务及其相关元数据轻松发布到一个集中的注册库。相反地，这些工具可以用于发现以前发布到注册库的服务。这允许设计人员只要通过点击鼠标数下，就可以发现和重用一个服务。如果服务不可用，而设计人员需要配置一个服务，那么就可以发布该服务，以便其他人可以重用。J2EE和集成专家可能需要重新构建一个服务或者扩展现有的服务，而且要使用SODA工具才能做到，这些工具使他们可以一致地访问UDDI注册库。使用所选的IDE和导入到SODA工具中的生成JAR文件，就可以构造EJB和POJO。使用Apache的Ant(http://ant.apache.org/)可以把这个过程整合在一起。

    利用各种技术和不同层次的专业知识——SODA允许所有开发人员快速精通编排用例流程流和公式化发生在流进行时的数据内容和转换，只要求他们对业务域和用例有一点了解。表示专家将执行表示流的编排。集成/EAI专家可以并行地配置一些服务和数据转换，这些服务和数据转换是连接系统和业务之间的流程流所必需的。如果没有提供某种独立功能的开箱即用服务，J2EE专家可以定制该功能部分的实现。他们可以使用SODA工具把这些实现公开为服务，然后发布它们，以便其他人发现。

    集成SODA

    流程

    使开发团队过渡到SODA方法不仅需要改变流程，还需要改变文化。下文描述了所需的关键改变，但是各处改变的基本重点必须是：

    1.重新考虑设计和实现域、业务、用例和表示组件的方式。在传统的流程中，业务服务和用例服务之间通常没有差别，而表示服务实际上根本不被认为是服务。为了实现域的独立性（域可插入性），同时也实现业务的独立性，用例与业务服务之间必须存在差别。另外，组成Web页面表示和页面导航的组件被认为是SODA领域中的首个类服务：页面导航的编排与业务流程流的编排实际上在技术上没有区别。域、业务、用例和标识服务层的编排都是循环复合之一：

    表示服务是这样实现的：在页面流中编排动作服务，将它们与用例服务相交互，最后把控制权转交给用于呈现页面的一个或多个视图服务。
    用例服务是通过编排其他用例服务以及底层的业务和域服务而实现的。
    业务服务是通过编排其他业务服务和底层的域服务（跨多个域）而实现的。
    域服务是通过编排（同一个域中的）其他域服务而实现的。

    2.使用支持SODA的工具的重点在于，为所有域和应用程序交互提供和增强它们实际需要的抽象。

    J2EE/集成组件设计——对于那些在J2EE和集成技术方面的技巧和经验多过在业务和业务建模方面的知识的开发人员来说，应该安排他们去构建和/或扩展作为构建其他服务的基础的底层组件。

    域服务设计——我们需要重点强调域服务设计（即以用例无关的方式与域模型交互的服务）。域服务必须是粘性的、不连续的和作用域有限的，这一点很重要。与特定域关联的服务集合应该允许该域可以独立于其他域使用。

    业务服务设计——如果要求服务是独立于用例的，而且需要与跨域的底层服务交互，那么就应该实现单独的服务层。该层应该不同于且独立于单个的域服务，不应该把它合并到用例服务层中。本文中的业务服务是指跨单个域、同时跨用例实现保持独立性和可重用性的服务。同时，用例服务是特定于应用程序的，不能跨系统进行重用。用例服务和业务服务之间的关系类似于应用程序服务模式(www.corej2eepatterns.com/Patterns2ndEd/ApplicationService.htm)与会话外观（session facade，www.corej2eepatterns.com/Patterns2ndEd/SessionFacade.htm）之间的关系。

    用例服务设计——通过编排其他用例服务和底层的业务和域服务，这些服务实现了特定的应用程序用例场景。这里需要深入理解特定应用程序的需求。

    表示服务设计——这些服务编排页面流并在Web页面上呈现生成的信息。这里需要人为因素和HTML方面的娴熟技巧，并要从页面导航的角度了解应用程序流。

    开发人员角色——如前所述，成功地集成SODA需要基于估计的技术集合明确定义开发人员的角色，而且任务分配也确实会影响到他们在流程中的角色。

    工作划分——在SODA环境中，应该基于相关的/相互依赖的用例分组，从逻辑上对开发团队进行工作划分。

    服务发布和发现——需要传授如何使用UDDI浏览器发现和使用服务，以及发布服务和进行版本控制（对于大部分组件来说，自动化这个流程是更可取的做法）。

    配置管理——比较好的SODA工具与兼容SCC的源控制系统集成得很好，所以从这个角度看，配置管理不会从根本上有所改变。改变出现在处理已发布和确定版本的服务的过程中。基于SOA的系统通常会动态查找和使用服务。因此，服务的UDDI注册库应该与环境（如：开发、集成、QA、生产）进行分离，这和运行时系统本身几乎一样。还应该使用源控制系统对开发注册库进行同步。

    与现有软件的集成——现有的基于组件的软件与基于SODA的新软件在源控制系统中是同等重要的。EJB和utility JAR，以及现有的Web应用程序，都可以被直接导入到大多数SODA工具中。大多数SODA工具还提供与GUI中所提供的功能等效的命令行功能。这是一种标准的需求，所以可以使用像Ant这样的工具来构建整个系统（不论是使用SODA技术开发，还是更加“传统的”基于组件/对象的开发）。