Spring WebServices入门与合同优先设计实践

需积分: 10 189 浏览量更新于2024-07-24 收藏 366KB PDF 举报

本文档是Spring WebServices-Reference 1.5.5版本的官方文档，由Arjen Poutsma、Rick Evans和Tareq Abed Rabbo编撰，提供了对Spring框架在构建Web服务方面的深入参考。Spring WebServices是一种用于简化Java企业应用程序开发，特别是通过基于契约（Contract-First）方法实现Web服务的工具。 **1. Spring WebServices简介** Spring WebServices支持契约驱动的设计，即在服务提供者和服务消费者之间明确定义接口和数据交换格式（如XML）。它强调在设计阶段就确定接口和数据模型，这有助于解决对象/XML之间的不匹配问题，包括： - **对象/XML impedance mismatch**：通过定义XML Schema (XSD) 扩展来确保数据结构的一致性，减少转换过程中的复杂性。 - **非移植性类型**：Spring提供了解决跨平台兼容性的解决方案，比如处理不同环境下的数据类型问题。 - **循环依赖**：通过设计良好的契约，避免在序列化和反序列化过程中可能出现的数据结构问题。 **2. 为什么选择契约第一？** 采用契约第一的方法有以下优点： - **脆弱性**：通过预先定义接口，降低代码改动对服务影响的风险，维护更容易。 - **性能**：由于接口清晰，可以提前优化处理逻辑，提高性能。 - **可重用性**：服务契约作为独立于实现的文档，增强了服务的复用性和模块化。 - **版本控制**：通过版本化的契约管理服务升级，降低迁移成本。 **3. 编写契约第一的Web服务** - **消息**：文档以一个简单的例子介绍，如Holiday、Employee和HolidayRequest消息，展示如何定义服务请求和响应。 - **数据合同**：定义了数据传输的结构，如Employee对象，明确字段和数据类型。 - **服务合同**：包括操作名称、输入参数、输出结果以及可能的异常，如发送一个请求假期的接口。 - **项目创建**：指导如何使用Spring框架创建新项目，并集成Web服务组件。 - **实现端点**：解释如何处理XML消息，包括解析请求、执行业务逻辑和生成响应。 - **发布WSDL**：最后一步是将服务公开，通过发布WSDL文档使其他系统能够发现和调用服务。 Spring WebServices文档提供了一套完整的流程，帮助开发者从概念理解到实际操作，实现高效、灵活且易于维护的契约驱动Web服务开发。通过遵循契约第一的原则，开发人员能够更好地管理服务的演化和与客户端的交互，从而提升整个项目的质量和可靠性。

3.2.3. HolidayRequest

Both the holiday and employee element can be put in a <HolidayRequest/>:

</Holiday>

<FirstName>Arjen</FirstName>

<LastName>Poutsma</LastName>

</Employee>

</HolidayRequest>

The order of the two elements does not matter: <Employee/> could have been the first element just as well.

What is important is that all of the data is there. In fact, the data is the only thing that is important: we are

taking a data-driven approach.

3.3. Data Contract

Now that we have seen some examples of the XML data that we will use, it makes sense to formalize this into a

schema. This data contract defines the message format we accept. There are four different ways of defining

such a contract for XML:

• DTDs

• XML Schema (XSD)

• RELAX NG

• Schematron

DTDs have limited namespace support, so they are not suitable for Web services. Relax NG and Schematron

certainly are easier than XML Schema. Unfortunately, they are not so widely supported across platforms. We

will use XML Schema.

By far the easiest way to create an XSD is to infer it from sample documents. Any good XML editor or Java

IDE offers this functionality. Basically, these tools use some sample XML documents, and generate a schema

from it that validates them all. The end result certainly needs to be polished up, but it's a great starting point.

Using the sample described above, we end up with the following generated schema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified"

targetNamespace="http://mycompany.com/hr/schemas"

xmlns:hr="http://mycompany.com/hr/schemas">

<xs:element name="HolidayRequest">

<xs:complexType>

<xs:sequence>

<xs:element ref="hr:Holiday"/>

<xs:element ref="hr:Employee"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Holiday">

<xs:complexType>

<xs:sequence>

<xs:element ref="hr:StartDate"/>

Writing Contract-First Web Services

Spring-WS (1.5.5) 9

<xs:element ref="hr:EndDate"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="StartDate" type="xs:NMTOKEN"/>

<xs:element name="EndDate" type="xs:NMTOKEN"/>

<xs:element name="Employee">

<xs:complexType>

<xs:sequence>

<xs:element ref="hr:Number"/>

<xs:element ref="hr:FirstName"/>

<xs:element ref="hr:LastName"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Number" type="xs:integer"/>

<xs:element name="FirstName" type="xs:NCName"/>

<xs:element name="LastName" type="xs:NCName"/>

</xs:schema>

This generated schema obviously can be improved. The first thing to notice is that every type has a root-level

element declaration. This means that the Web service should be able to accept all of these elements as data.

This is not desirable: we only want to accept a <HolidayRequest/>. By removing the wrapping element tags

(thus keeping the types), and inlining the results, we can accomplish this.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:hr="http://mycompany.com/hr/schemas"

elementFormDefault="qualified"

targetNamespace="http://mycompany.com/hr/schemas">

<xs:element name="HolidayRequest">

<xs:complexType>

<xs:sequence>

<xs:element name="Holiday" type="hr:HolidayType"/>

<xs:element name="Employee" type="hr:EmployeeType"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="HolidayType">

<xs:sequence>

<xs:element name="StartDate" type="xs:NMTOKEN"/>

<xs:element name="EndDate" type="xs:NMTOKEN"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="EmployeeType">

<xs:sequence>

<xs:element name="Number" type="xs:integer"/>

<xs:element name="FirstName" type="xs:NCName"/>

<xs:element name="LastName" type="xs:NCName"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

The schema still has one problem: with a schema like this, you can expect the following messages to validate:

<EndDate>neither is this</EndDate>

</Holiday>

</HolidayRequest>

Clearly, we must make sure that the start and end date are really dates. XML Schema has an excellent built-in

date type which we can use. We also change the NCNames to strings. Finally, we change the sequence in

<HolidayRequest/> to all. This tells the XML parser that the order of <Holiday/> and <Employee/> is not

significant. Our final XSD now looks like this:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

Writing Contract-First Web Services

Spring-WS (1.5.5) 10

xmlns:hr="http://mycompany.com/hr/schemas"

elementFormDefault="qualified"

targetNamespace="http://mycompany.com/hr/schemas">

<xs:element name="HolidayRequest">

<xs:complexType>

<xs:all>

<xs:element name="Holiday" type="hr:HolidayType"/> ❶

<xs:element name="Employee" type="hr:EmployeeType"/>

</xs:all>

</xs:complexType>

</xs:element>

<xs:complexType name="HolidayType">

<xs:sequence>

<xs:element name="StartDate" type="xs:date"/>

<xs:element name="EndDate" type="xs:date"/> ❷

</xs:sequence> ❷

</xs:complexType>

<xs:complexType name="EmployeeType">

<xs:sequence>

<xs:element name="Number" type="xs:integer"/>

<xs:element name="FirstName" type="xs:string"/>

<xs:element name="LastName" type="xs:string"/> ❸

</xs:sequence> ❸

</xs:complexType>

</xs:schema>

❶ all tells the XML parser that the order of <Holiday/> and <Employee/> is not significant.

❷ We use the xsd:date data type, which consist of a year, month, and day, for <StartDate/> and

<EndDate/>.

❸ xsd:string is used for the first and last name.

We store this file as hr.xsd.

3.4. Service contract

A service contract is generally expressed as a WSDL file. Note that in Spring-WS, writing the WSDL by hand

is not required. Based on the XSD and some conventions, Spring-WS can create the WSDL for you, as

explained in the section entitled Section 3.6, “Implementing the Endpoint”. You can skip to the next section if

you want to; the remainder of this section will show you how to write your own WSDL by hand.

We start our WSDL with the standard preamble, and by importing our existing XSD. To separate the schema

from the definition, we will use a separate namespace for the WSDL definitions:

http://mycompany.com/hr/definitions.

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:schema="http://mycompany.com/hr/schemas"

xmlns:tns="http://mycompany.com/hr/definitions"

targetNamespace="http://mycompany.com/hr/definitions">

<wsdl:types>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:import namespace="http://mycompany.com/hr/schemas" schemaLocation="hr.xsd"/>

</xsd:schema>

</wsdl:types>

Next, we add our messages based on the written schema types. We only have one message: one with the

<HolidayRequest/> we put in the schema:

<wsdl:message name="HolidayRequest">

<wsdl:part element="schema:HolidayRequest" name="HolidayRequest"/>

</wsdl:message>

Writing Contract-First Web Services

Spring-WS (1.5.5) 11

We add the message to a port type as an operation:

<wsdl:portType name="HumanResource">

<wsdl:operation name="Holiday">

<wsdl:input message="tns:HolidayRequest" name="HolidayRequest"/>

</wsdl:operation>

</wsdl:portType>

That finished the abstract part of the WSDL (the interface, as it were), and leaves the concrete part. The

concrete part consists of a binding, which tells the client how to invoke the operations you've just defined; and

a service, which tells it where to invoke it.

Adding a concrete part is pretty standard: just refer to the abstract part you defined previously, make sure you

use document/literal for the soap:binding elements (rpc/encoded is deprecated), pick a soapAction for the

operation (in this case http://mycompany.com/RequestHoliday, but any URI will do), and determine the

location URL where you want request to come in (in this case http://mycompany.com/humanresources):

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:schema="http://mycompany.com/hr/schemas"

xmlns:tns="http://mycompany.com/hr/definitions"

targetNamespace="http://mycompany.com/hr/definitions">

<wsdl:types>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:import namespace="http://mycompany.com/hr/schemas" ❶

schemaLocation="hr.xsd"/>

</xsd:schema>

</wsdl:types>

<wsdl:message name="HolidayRequest"> ❷

<wsdl:part element="schema:HolidayRequest" name="HolidayRequest"/> ❸

</wsdl:message>

<wsdl:portType name="HumanResource"> ❹

<wsdl:operation name="Holiday">

<wsdl:input message="tns:HolidayRequest" name="HolidayRequest"/> ❷

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="HumanResourceBinding" type="tns:HumanResource"> ❹❺

<soap:binding style="document" ❻

transport="http://schemas.xmlsoap.org/soap/http"/> ❼

<wsdl:operation name="Holiday">

<soap:operation soapAction="http://mycompany.com/RequestHoliday"/> ❽

<wsdl:input name="HolidayRequest">

<soap:body use="literal"/> ❻

</wsdl:input>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="HumanResourceService">

<wsdl:port binding="tns:HumanResourceBinding" name="HumanResourcePort"> ❺

<soap:address location="http://localhost:8080/holidayService/"/> ❾

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

❶ We import the schema defined in Section 3.3, “Data Contract”.

❷ We define the HolidayRequest message, which gets used in the portType.

❸ The HolidayRequest type is defined in the schema.

❹ We define the HumanResource port type, which gets used in the binding.

❺ We define the HumanResourceBinding binding, which gets used in the port.

❻ We use a document/literal style.

❼ The literal http://schemas.xmlsoap.org/soap/http signifies a HTTP transport.

❽ The soapAction attribute signifies the SOAPAction HTTP header that will be sent with every request.

❾ The http://localhost:8080/holidayService/ address is the URL where the Web service can be

invoked.

Writing Contract-First Web Services

Spring-WS (1.5.5) 12

This is the final WSDL. We will describe how to implement the resulting schema and WSDL in the next

section.

3.5. Creating the project

In this section, we will be using Maven2 to create the initial project structure for us. Doing so is not required,

but greatly reduces the amount of code we have to write to setup our HolidayService.

The following command creates a Maven2 web application project for us, using the Spring-WS archetype (that

is, project template)

mvn archetype:create -DarchetypeGroupId=org.springframework.ws \

-DarchetypeArtifactId=spring-ws-archetype \

-DarchetypeVersion=1.5.5 \

-DgroupId=com.mycompany.hr \

-DartifactId=holidayService

This command will create a new directory called holidayService. In this directory, there is a

'src/main/webapp' directory, which will contain the root of the WAR file. You will find the standard web

application deployment descriptor 'WEB-INF/web.xml' here, which defines a Spring-WS

MessageDispatcherServlet and maps all incoming requests to this servlet:

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"

version="2.4">

<display-name>MyCompany HR Holiday Service</display-name>

<servlet-name>spring-ws</servlet-name>

<servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>spring-ws</servlet-name>

<url-pattern>/*</url-pattern>

</servlet-mapping>

</web-app>

In addition to the above 'WEB-INF/web.xml' file, you will also need another, Spring-WS-specific configuration

file, named 'WEB-INF/spring-ws-servlet.xml'. This file contains all of the Spring-WS-specific beans such as

EndPoints, WebServiceMessageReceivers, and suchlike, and is used to create a new Spring container. The

name of this file is derived from the name of the attendant servlet (in this case 'spring-ws') with

'-servlet.xml' appended to it. So if you defined a MessageDispatcherServlet with the name 'dynamite',

the name of the Spring-WS-specific configuration file would be 'WEB-INF/dynamite-servlet.xml'.

(You can see the contents of the 'WEB-INF/spring-ws-servlet.xml' file for this example in ???.)

3.6. Implementing the Endpoint

In Spring-WS, you will implement Endpoints to handle incoming XML messages. There are two flavors of

endpoints: message endpoints and payload endpoints. Message endpoints give access to the entire XML

message, including SOAP headers. Typically, the endpoint will only be interested in the payload of the

Writing Contract-First Web Services

Spring-WS (1.5.5) 13

剩余85页未读，继续阅读

ttyszs1

粉丝: 0
资源: 1

Spring WebServices入门与合同优先设计实践

java_webservice_JAX-RS.zip_cxf_jax_jax-rs_spring cxf

neu_wb7.1_Webservice接口_

cxf_webservice

spring webservice参考.pdf

hibernate_spring_struts框架资料

xfire+spring开发webservice的例子

在自己的项目中利用axis2+spring发布webservice与客户端调用包括session

spring-axis2-test.rar_Axis2 Spring3_axis2_axis2 spring3_axis2 s

XFire与Spring构建WebService实战

使用XFire与Spring构建WebService教程

最新资源