工具/集成服务环境(Integrated Service Environment，ISE)
在SODA中，有一个称为ISE的概念。ISE是指实际实现SODA概念所需的工具套件，是当前IDE逻辑演变的结果。SODA依赖于健壮工具集来处理接口抽象、发布、发现、模拟（模拟实现）和数据转换。所选择的支持SODA的工具必须支持这些重要概念（SODA的关键区分点），这一点很关键。下文将会描述这些区分点。
开箱即用的服务库——对于常见的企业应用程序功能（表示、业务和集成层）来说，必须存在一个现成的、功能广泛的服务库。这些服务还必须易于扩展和配置。
服务创建——显然，必须能够通过图形向导轻松创建服务。现有的或第三方组件应该能够通过工具轻松导出为服务。
服务组装（编排）——或许在开发人员生产力方面，最重要的就是在图形化的直观环境中，把服务组装（编排）为业务流程流的能力。这必须包括表示（页面/动作导航）和业务服务流。这里也需要声明性异常、安全性和事务划分。
服务库(关联到源控制)——一个集中式的服务库是必要的，它使用像UDDI这样的标准。通过工具把这个库关联到项目源控制系统的功能也是必需的，尽管这是通过外部工具（如：Ant）实现的。
查找和动态发现——服务库必须提供服务浏览、查找和动态运行时发现等功能。使用UDDI服务器作为库通常可以提供上述功能。
外部接口规范(WSDL或其他XML模式)——在SODA环境中，服务通常被公开为基于SOAP的Web services，该特性已经成为该标准的一个固有部分。工具应该为没有被公开为Web services的服务提供同样的功能。
服务转换(版本校正)——动态检测特定服务版本和该服务的客户端版本并提供二者之间的数据转换的能力，是必要的。
BEA WebLogic Workshop和其他工具
BEA WebLogic的Workshop (http://dev2dev.bea.com/wlworkshop/index.html) ISE很可能在（在J2EE环境中）对SODA提供支持方面是做得最全面的。它提供对关键区分点的支持，并允许对接口、接口编排和底层实现进行分离。在这方面无疑还有很多其他的工具。其中一些，比如Collexa的Web services编排产品，是免费赠送的，而且与Workshop集成得很好。其他的产品则直接参加竞争。Workshop有一些潜在的缺点：它当前支持的许多功能都将用户绑定到了BEA WebLogic平台上。许多功能已经被提交给Java Community Process，并被其接受为Java Specification Request (JSR)。借助于在Apache孵化器中发展良好的Beehive（蜂巢）计划，以及相关的Eclipse插件Pollinate，这里应该不存在厂商锁定（vendor lock-in）。“Bridging the Gap: BEA WebLogic Integration”一文(http://dev2dev.bea.com/pub/a/2004/05/Viarengo.html)详细说明了SODA上下文中的WebLogic Workshop。
图2 WebLogic Workshop控件抽象
概念验证(Proof of Concept，POC)
SODA在提高生产力方面具有很大的潜力。然而，它也有缺陷：
缺乏工具支持方面的现行标准，这导致了一定程度的厂商锁定。
SODA把大量的开发负担放在工具上。这意味着工具必须能够熟练生成底层连接代码，这些代码或者完全向开发人员隐藏，或者在可用于定制时可以很容易地进行维护。
最终得到的架构是不是可伸缩和高性能的？它是不是可扩展的？
就所选择的SODA工具对开发人员进行训练需要付出大量的劳动。开发软件过程中的转变并不是无关紧要的。
演示/证明一种SODA方法需要用到POC。该POC过程必须有足够的可扩展性，以便至少演示/证明以下概念：
基于服务的设计范例转换。我们尤其需要深入了解各个服务层（至少实现/利用一个域、业务、用例和表示服务）。
多团队开发。这包括源控制集成和SODA相关特定角色的指派（表示设计人员、用例设计人员、业务/域设计人员、J2EE专家、集成专家，等等）。
一个实现了完整垂直片断的用例场景实现。这个用例场景涉及到所有层，（或许还特别）包括集成层，这一点很重要。
组装和编排以下服务类型的演示：
- 表示和表示流
- 基本的Web services
- 业务流程(工作流)
- 消息收发
- 后端集成(Back-end integration，EAI)
- 安全性
与底层J2EE组件的集成
与现有功能的集成
演示发布、随后的服务查找/发现，以及相关的元数据（文档）
演示开发、构建、部署和发布这个周期
演示服务模拟，以便显示对依赖性瓶颈的缓解
