您的位置：middleware->架构师观点：将EJB组件公开为业务服务（二）

架构师观点：将EJB组件公开为业务服务（二）2007-11-23 来自：mp817  [收藏到我的网摘]

如果在开发环境中使用适当的工具(如 Oracle 　应用服务器 和 Oracle JDeveloper)，则公开 EJB 的过程将非常简单。但情况并非绝对如此，而且实际的大型分布式应用程序需要模块化、可重用性、可扩展性、可移植性、版本控制、一致性以及可伸缩性的可持续特性。

有关如何利用标准 J2EE 组件(其中的模块功能面向业务服务上下文)以及 Web 服务中不断涌现的技术改进或增强软件开发过程以高效构建高质量的大型应用程序的信息很少。即使我们能够精确地标识“可以服务”的业务功能并拥有所有必要的应用程序和中间件工具，也无法回答下面这个问题：如何在分布式处理元素中安排应用程序功能或职责，以便在使用 Web 服务时最大限度地增强质量功能?

通常情况下，研究 Web 服务的组织利用其现有 Java 对象并直接使用 Web 接口公开它们。最终的结果是不符合 SOA 的要求，且此类实现可以使组织面临以下比较严重的问题：

低可重用性—为某个项目开发的服务不易于在其他项目中重用，这是因为它们的结构通常过分依赖于 Web 服务接口的实现。某个服务中的组件之间的依赖性降低了该服务在其他上下文中的可用性。
低可扩展性—当出现新功能需要时，很难扩展现有接口，或至少将更改或扩展孤立到一到两个组件。通常情况下必须设计新接口，尤其是当服务控制逻辑集中用于执行消息处理的代码中时。
低可伸缩性—很难存档高容量工作负载(例如，每秒钟 1,000 个以上的服务请求)。直接使用 Web 服务接口公开每个对象的细粒度解决方案无法通过经济有效的方式扩展到这样的级别。
要避免此类问题，组织需要部署正确的体系结构模式来帮助创建粗粒度、高度面向业务的 J2EE 组件。

推荐人评论

如果在开发环境中使用适当的工具(如 Oracle 　应用服务器 和 Oracle JDeveloper)，则公开 EJB 的过程将非常简单。

用户评论

正在载入评论列表...