| ||||
【文章简介】SOA有什么真正的新特性?我对围绕面向服务的体系结构(SOA)的所有喧嚣感到有点迷惑——而您似乎被它迷住了。例如，在EJB倡导者:在面向服务的体系结构中，使用无facade的EJB组件是最佳选择吗?中，您描述了在设计EJB组件以使它们“面向服务”(例如，使它们成为粗粒度的或无状态的)时所应遵循的最佳实践。对我们这些使用诸如CORBA和EnterpriseJavaBeans等分布式对象技术来构建过成功应用程序的人来说，您所描述的原理并不新
请访问以下3个网站，以了解与本文相关的更多内容：【文章正文】
SOA 有什么真正的新特性?
我对围绕面向服务的体系结构 (SOA) 的所有喧嚣感到有点迷惑——而您似乎被它迷住了。
例如，在 EJB 倡导者: 在面向服务的体系结构中，使用无 facade 的 EJB 组件是最佳选择吗? 中，您描述了在设计 EJB 组件以使它们“面向服务”(例如，使它们成为粗粒度的或无状态的)时所应遵循的最佳实践。
对我们这些使用诸如 CORBA 和 Enterprise JavaBeans 等分布式对象技术来构建过成功应用程序的人来说，您所描述的原理并不新鲜。我想我们一直都是“面向服务”的。
我承认您从“面向服务”的体系结构中获得了比“分布式对象”体系结构更好的术语。但除此之外，我还有一个严肃的问题：存在任何有关 SOA 的新特性吗?明确地说，当我能够使用 Enterprise JavaBean 组件来做一切工作时，我为什么要关心新的服务组件体系结构 (Service Component Architecture) 和服务数据对象 (Service Data Objects) 规范?
SCA 代表了服务器端的自然发展
在给定我是 EJB 倡导者的前提下，下面的陈述可能会让您感到震惊——但是，您可以使用 EJB 组件以 Java 语言在服务器端编写任何代码，并不意味着您应该那样做。我的感受是，我们正在看到服务器端技术的自然发展，非常类似于我们在客户端所看到的 Java™ Servlet 的发展。
不知您是否记得，Java Servlet 是作为一个基于标准 Java 的组件来引入的，以统一与特定 Web 服务器相关联的 Java API，如 Microsoft® 的 Internet Server API (ISAPI)。Java Servlet 使得 Java 程序员能够开发组件来生成动态网页，使那些网页能够与来自不同供应商的更广泛 Web 服务器一起运行。
最常用的组件是 HttpServlets，它处理来自 HTTP 请求流中的输入和到 HTTP 响应流中的输出的所有映射详细信息，从而将程序员解放出来以集中于应用程序流程逻辑的详细信息。
尽管这非常不错，然而用户很快发现，使用 Java 代码来生成 HTML 非常繁琐。例如，下面是 HttpServlet doGet() 方法中用于生成简单的动态“Hello world”的代码片段：
String name = request.getAttribute("name");各种“模板”语言很快开始涌现出来，使您能够在 HTML 中嵌入 Java 代码，从而使得该编程模型更加“所见即所得”（WYSIWYG，即声明式的）。标准化这些方法导致了 Java Server Page (JSP) 规范的产生。使用 JSP，您可以将 Java“scriptlet” (<%...%>) 和“表达式” (<%=…%>) 与 HTML 混合使用。例如，下面是某个 JSP 中用于显示相同的“Hello world”的代码片段：
<% String name = request.getAttribute("name"); %>
<HTML>
<BODY>
<P>Hello <%=name%>!</P>
</BODY>
</HTML>"仅只是消除括号、引号和分号本身就可以防止 Web 应用程序程序员的无数错误。此外，消除对编译、打包和部署 HttpServlet 组件的需要还极大地缩短了做出变更(无论是否为修否错误)所需的时间。
但更重要的是，JSP 导致了一种体系结构变更，将呈现视图的关注点与获取数据的关注点分离。网页设计人员和应用程序程序员可以突然地一起工作，分别以更适合其角色的语言和风格来开发他们自己的组件而不会相互冲突。
说句题外话，Enterprise JavaBeans 规范几乎是在同时出现的，以进一步分离那些关注点。添加 EJB 组件实现了 Web 应用程序的真正的模型-视图-控制器 (Model-View-Controller) 体系结构，其中模型由 EJB 组件来封装，视图由 JSP 来封装，控制器由 HttpServlets 来封装。
遗憾的是，若要呈现任何真正有用的东西，Java scriptlet、表达式和静态 HTML 的交互可能变得相当复杂。例如，下面是用于产生订单 ID 和状态列表的代码片段：
<%开始循环的那个 scriptlet 相当复杂。结尾的那个 scriptlet 确实简单，但是常常被遗忘(或放在了错误的位置)。在编辑 JSP 时，不存在用于捕获这个以及其他常见错误的工具(就像在 Java IDE 对“纯粹”HttpServlets 所遇到的情况一样)。
简而言之，问题仍然在于，Java scriptlet 和表达式的正确使用对普通网页设计人员来说要求过高——对于没有接受过编程培训的人来说尤其如此。
于是出现了自定义 JSP 标记的思想并得到了标准化，以最小化甚至消除对 Java 编程的需要。例如，IBM Software Services for WebSphere 开发了一些自定义标记，支持对嵌套结构进行迭代。这些标记与作为基础 JSP 标记库一部分来提供的 USEBEAN 和 GETPROPERTY 标记一起工作，以极大地简化逻辑，如下所示：
<JSP:USEBEAN出现诸如 Struts 等框架以消除对编写 HttpServlets 的需要，这还是不久之前的事情。Struts 包括用于表单处理的丰富自定义标记集，但是还包括一个称为“Tiles”的概念，它支持声明式的页面组合。Tiles 的重要特性是能够非常容易地重新组合页面，而无需更改基础代码组件。Struts 是 Java Server Faces (JSF) 背后的灵感之一，JSF 标准化了从组件进行声明式 UI 组装的概念。
客户端从 Java Servlet 到 JSP 到自定义标记框架再到 JSF 的发展是从过程化编程的组件的逐步偏离，后者必须编译为可解释的声明式组装的组件(或者至少在运行时进行编译)。面向组件的
电子商务模式窄告： |
实名制会员登录
|
载入中…
|
