自下而上估算_Web服务自下而上的开发-CSDN博客

自下而上估算

用于Java的第一代Web服务工具旨在将现有代码公开为Web服务。这种方法称为自下而上，因为起点是被抽象为接口定义并随后作为实现该接口的Web服务公开的代码。许多Web服务从业者都熟悉这种模式，甚至最新一代的Web服务工具也都支持这种模式。

自下而上的开发模式包括以下开发步骤

标识或创建代表服务接口的输入和输出参数的数据类型的JavaBean。这些可以是现有的也可以是新的JavaBean。由于这些JavaBean用于在服务之间传输数据，因此有时将它们称为数据传输对象（DTO）。注意，只有遵循JavaBean模式的属性（此类属性具有getter方法和setter方法）才在Web服务接口中公开。您可以使用标准Java开发工具来创建或修改所需的JavaBean。
标识或创建成为Web服务实现的Java类，可以是普通Java对象（POJO）或无状态会话EJB。 Java类必须包括要在Web服务接口中公开的方法。这些方法必须使用步骤1中的DTO作为输入和输出参数。注意，实现Web服务中公开的业务逻辑的方法必须标记为public。同样，您可以根据需要使用标准Java开发工具来创建或修改Java类。此类不必遵守JavaBean的规则。根据需要，该类可以在公开的方法中引发任何异常。
使用Web服务工具从Java类生成Web服务实现。有几种复杂程度各异的候选工具，因为它们可能会产生JAX-RPC部署和使用Web服务所需的全部或部分工件。这些工具都基于步骤2中Java类的签名生成WSDL文档。这些工具为Java类的公共方法中使用的每种数据类型（JavaBean）创建嵌入在WSDL types元素中的复杂类型定义。他们还在portType中为Java类中的每个公共方法创建一个操作元素。这些工具还可以生成在应用程序服务器中将实现部署为Web服务所需的任何其他提供程序方工件。
使用Web服务工具使用步骤3中生成的WSDL为Web服务请求者生成构件。该工具为WSDL types元素（服务端点接口（SEI））中定义的每个复杂类型生成Java类（DTO）。有一个针对portType中包含的每个操作的方法，以及一个实现SEI的存根，客户端可以使用SEI向Web服务实现发送请求和从Web服务实现接收响应。这些工具可能会生成其他工件，这取决于请求者（是否为J2EE容器）的性质以及工具本身。生成提供者实现的相同工具通常也将具有请求者版本。因此，从Apache Axis或Application Server的命令行驱动的WSDL2Java到WebSphere Studio Application Developer中的Web服务向导，都存在相同范围的工具。

自下而上方法的评估

自底向上方法的优点是：

这是将旧版实现公开为Web服务的快速方法。

它几乎不需要WSDL或XML知识，因为WSDL文档是由工具生成的。

它具有出色的工具支持。实际上，复杂的工具完成了所有工作，以在提供者端创建可部署的，可执行的Web服务实现，并且完成了所有工作以允许请求访问请求者端的实现。

自下而上方法的缺点是：

生成的定义WSDL文档中数据类型的模式仅源自提供者环境中的Java类，而不源自任何基于标准的模式（请参见上面的清单3）。

提供者端数据类型可能不是简单的DTO，因为它们包含其他业务逻辑。此类逻辑无法在请求方进行重构。

生成的模式嵌入到WSDL中，这使模式的重用（可能在其他Web服务的定义中）更加困难。当然，可以从原始WSDL文档中提取模式。

服务器端Web服务实现和客户端Web服务请求者的开发不能并行进行。必须先开发服务器端框架和DTO，然后才能生成可用于生成客户端存根和DTO的WSDL。

对界面的增量更改更难以管理。例如，如果更改了实现服务的类的接口并重新生成了WSDL，则WSDL中可能会发生更重大的更改，从而导致与现有客户端的互操作性失败。基本问题是，在服务器端，实现服务的类被视为主接口，而在客户端，由服务器端提供的WSDL是主接口。这两个不同的主机可能导致接口不同步，并且难以调试和修复。

嵌入式模式类型的名称空间通常是从服务器端JavaBean的Java包名称生成的。因此，如果更改了程序包名称，则名称空间也将更改，这意味着类型不再兼容。大多数工具都允许包到名称空间的映射，但这必须在工具执行期间明确设置。