组合。对于 EJB 组件，Java 是可用于实现的唯一语言，因此服务到更大组装的所有组合都是通过 Java 以过程化的方式完成的。SCA 不仅支持 Java 作为实现语言，而且还支持业务流程执行语言(Business Process Execution Language，BPEL)，后者正在扩展到处理诸如状态机、业务规则和人工任务等概念。

　　调用。使用无状态会话 Bean 的方式不同于使用有状态会话 Bean、实体 Bean、自定义实体 Home 方法或消息驱动 Bean 的方式。明确地说，每种组件类型都有不同的方法来定位和调用其方法。SCA 组件支持客户机的公共调用模型，而与实现类型无关数据。实体 EJB 组件从未打算成为可序列化的以供在容器和事务边界范围之外进行高效利用。因此数据传输对象 (Data Transfer Object，SDO) 的发展填补了这个空缺。SDO 组件提供了组件间数据流的公共抽象，而与范围无关。
　　正是对“组合”、“调用”和“数据”选择的简化，使得 SCA 中从服务到应用程序的声明式组装的发展成为可能——就像 JSP 和自定义标记实现了 UI 的声明式组装这个趋势一样。

　　总而言之，关心 SOA 的主要原因在于，它最终将使业务分析人员能够在具有最少程序员支持的情况下组合应用程序。

　　EJB 组件是否会重蹈恐龙的覆辙?

　　我还真的未曾考虑过客户端的声明式语言趋势可能会如何适用于服务器端。现在您更让我感到疑惑是否应该使用 EJB 组件了!

　　EJB 组件更像是 DNA：进化的构件

　　我在总结陈述中的最重要措辞是“最终”和“最少”。

　　“最终”意味着 BPEL 的运行时解释器还需要相当长时间才能达到企业应用程序的所有方面所需要的功能和性能。例如，很可能“微流程”(旨在以单个工作单元运行的逻辑)作为 EJB 组件会执行得更好。

　　“最少”则意味着，即使在 BPEL 标准已扩展到使业务分析人员能够通过声明式概念(如状态机、人工任务和业务规则)来指定逻辑时，也始终存在一些可以通过过程方式来更容易地指定的逻辑模式。虽然可以创建某种“过程化”标记或可视编程语言，但是这并不比 Java 更简单——给定所有要输入的额外标记语法或要在组件之间绘制的线条，结果甚至可能更复杂。

　　总之，减少对人工编写 EJB 组件代码的需要是可以实现的，但是复杂的企业级应用程序中可能仍然需要一些 EJB 组件。因此，应该将 EJB 组件视为构件，服务器端组件的扩展将基于这些构件。