用于Java的第一代Web服务工具旨在将现有代码公开为Web服务。 这种方法称为自下而上,因为起点是被抽象到接口定义中并随后作为实现该接口的Web服务公开的代码。 许多Web服务从业者都熟悉这种模式,甚至最新一代的Web服务工具也都支持这种模式。
自下而上的开发模式包括以下开发步骤
- 标识或创建代表服务接口的输入和输出参数的数据类型的JavaBean。 这些可以是现有的也可以是新的JavaBean。 因为这些JavaBeans用于与服务之间来回传输数据,所以有时将它们称为数据传输对象(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包名称生成的。 因此,如果更改了程序包名称,则名称空间也将更改,这意味着类型不再兼容。 大多数工具都允许包到名称空间的映射,但这必须在工具执行期间明确设置。
翻译自: https://www.javacodegeeks.com/2015/08/web-services-bottom-up-development.html