【IT168 技术文章】

    面向服务的应用程序开发(SODA)

    Gartner把SOA和SODA看作是未来计算的基本元素。SODA是一种开发软件的新方式，旨在专门用于SOA范例中。SOA代表了松散耦合的、粗粒度的异构组件的集合，可以使用Web services把这些组件结合在一起。从而提高开发人员的生产力、代码重用程度和业务灵活性。SOA 蓝图(www.middlewareresearch.com/soa-blueprints/)是行业的非常好的实践和相关参考实现的集合，对于那些想转而使用SOA的人来说，它是非常不错的资源。

    SODA首先以创建和组装服务和服务合同为中心，而把设计和实现用于实现服务的对象和组件推迟到解决粗粒度服务合同之后。SODA开发人员更多地注重应用程序内部及其相互之间的流程流，而对于创建底层系统的代码就没那么关心了。参见www.serviceoriented.org/soda.html，其中有对SODA的简要描述。

    主要问题

    下面描述的问题虽并非巨细无遗，却也说明了通常会影响开发过程的一些问题（特别是对于拥有多个开发团队的大型企业），通过转向基于SODA的开发方法可以缓解这些问题。

    依赖性/瓶颈

    与依赖性次序相关的瓶颈通常是最重要的问题。开发人员通常必须等待某处依赖性内容的设计和/或实现完成之后，才能够继续执行任务。其中一个问题就是多团队环境中的工作划分问题。在这种环境中采用的一种标准工作划分是，让不同的团队实现不同层中的相同垂直功能片断。这导致了这些与依赖性相关的问题的出现。

    管理和缓解与依赖性相关的问题，对于确保开发人员继续在整个开发过程中保持高效至关重要；然而，如果依赖性问题的多个部分是并行开发的（当项目有固定的最后期限时通常如此），那么要“管理”它是不可能的。

    针对企业的每次发布（迭代），数据模型的创建总是与相应的软件开发差不多同时开始，不会早很多，这种模式虽说不理想，但通常也无法避免。类似的，发布的域模型也不会在使用它的开发迭代之前完成。在构造数据和域模型的过程中，正确的规划对于避免这些问题是至关重要的，但是如果项目已经启动，就无法更改了（“下一次我们会采用正确的做法”）。这些问题会导致业务服务、对象/关系持久性映射出现瓶颈，而且会使企业应用集成（enterprise application integration，EAI）/企业到企业（business-to-business，B2B）开发人员要求，在他们能够开始大部分工作之前，必须完成数据和域模型。

    工作划分

    开发团队通常按照层进行水平划分（尤其是对于那些地理位置分散的团队）。可能一个团队工作在表示层，而另一个则工作在业务层。这种划分通常不是必要的，因为异地的团队可能无法访问业务层需要与之交互的后端系统。表示层功能的开发不需要访问这些系统（至少在设计和迭代的初始实现阶段中不需要）。但是这种工作划分本身就存在问题，即独立的功能（用例）部分的开发是由独立（通常是地理位置独立）的团队来完成的。这些团队通常通过到业务服务的接口和通过它们公开的数据传输对象（data transfer object，DTO）(http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)进行通信——这是一条标准的Java 2 Enterprise Edition (J2EE)非常好的实践。在开发迭代期间，随着表示和业务服务的开发人员对他们的设计和随后的实现的深入理解，DTO的结构和内容通常都会改变。另外，DTO的结构/内容（通常）是由域模型的结构驱动的，而且随着它的发展，这种做法更加流行。如果同一个团队致力于一个端到端功能片断的开发（这个团队应该能够控制域模型、DTO、业务服务接口和相关表示的结构/内容），这些问题就可能会稍微缓解。这种方法的主要瓶颈在于一致地模拟与后端系统的接口的能力，以便异地的团队也可以获得完整的垂直片断。当布置好团队时，这类后端系统通常具有使用限制，尤其是当后端系统连接到另一个项目、部门或业务，并且/或者被它们所拥有时。

    图1 使用WebLogic Workshop进行开发的连续性