công nghệ Sping Web service

luận văn về công nghệ Sping Web service

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

LỜI CÁM ƠN

Chúng em xin bày t ỏ lòng biết ơn chân thành nhất ñến thầy ðặng Thanh Dũng,

ng ười thầy ñã tận tâm giúp ñỡ, hướng dẫn chúng em thực hiện luận văn này

Chúng con xin g ửi lòng biết ơn và kính trọng sâu sắc ñến gia ñình, những người ñã

nuôi d ạy chúng con trưởng thành

Chúng em chân thành c ảm ơn quý thầy cô trong khoa Công nghệ thông tin trường ðại học Sư Phạm Kỹ Thuật Thành Phố Hồ Chí Minh ñã tận tình giảng dạy, hướng

d ẫn, giúp ñỡ chúng em trong suốt quá trình học cũng như hoàn thành luận văn này

M ặc dù ñã cố gắng hết sức nhưng chắc chắn luận văn còn nhiều thiếu sót, chúng

em mong nh ận ñược sự thông cảm, chỉ bảo của quý thầy cô cùng các bạn

Tp.HCM ngày 31/12/2007

Lương Nguyễn Hải ðăng-ðoàn Huỳnh Cẩm Duyên

MỤC LỤC

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN i

LỜI CÁM ƠN ii

MỤC LỤC iii

DANH MỤC CÁC HÌNH VẼ v

DANH MỤC CÁC BẢNG vii

1 CHƯƠNG 1 – MỞ ðẦU 1

1.1 Tính cấp thiết của ñề tài 1

1.2 Mục tiêu của ñề tài 1

2 CHƯƠNG 2 – CƠ SỞ LÝ THUYẾT 4

2.1 Web Services 4

2.1.1 Tổng quan về Web Service 4

2.1.2 Các thành phần chính của Web Service 7

2.1.3 Tính bảo mật Web Service 12

2.2 Spring Web Service 13

2.2.1 Giới thiệu về Spring Framework và Spring Web Service 13

2.2.2 Contract-first 15

2.2.3 Tạo một web service trong Spring 44

2.2.4 Bảo mật web service trong Spring Web Service 70

2.3 Acegi Security 91

2.3.1 Giới thiệu 91

2.3.2 Authentication 92

2.3.3 Authorization 104

2.4 Kết luận 125

3 CHƯƠNG 3 – THIẾT KẾ VÀ CÀI ðẶT 127

3.1 Thực tế 127

3.2 Sơ ñồ chuyển trang 127

3.3 Cài ñặt giao diện 128

4 CHƯƠNG 4 – KẾT LUẬN 132

4.1 Tóm tắt các kết quả ñạt ñược 132

4.2 Hướng phát triển 132

TÀI LIỆU THAM KHẢO 133

DANH MỤC CÁC HÌNH VẼ

2.2 Cấu trúc của một message theo dạng SOAP 12

2.3 Cấu trúc các module trong Spring Web Service 16

2.4 Quá trình xử lý luồng ñi của MessageDispatcher 47

2.5 Những lớp liên quan ñến quá trình Pre-Invocation Handling 110

3.8 Xóa khách hàng 131

DANH MỤC CÁC BẢNG

1 CHƯƠNG 1 – MỞ ðẦU

1.1 Tính c
p thit ca ñ tài

Cách ñây vài năm, khi nói tới thế kỷ 21, người ta khẳng ñịnh ñó sẽ là thời ñại của

“nền kinh tế số” với “thương mại ñiện tử” là then chốt Thông tin và các giao dịch ñược số hóa sẽ làm ñảo lộn nền kinh tế thế giới Làm sao ñể có thể tận dụng Internet mở rộng thị trường, tìm thêm cơ hội cho sản phẩm, dịch vụ của mình ñã trở thành ñiều mà các doanh nhân, doanh nghiệp Việt Nam không thể không quan tâm

Có thể trước mắt, khi phần lớn các Website thương mại ñiện tử ở Việt Nam chưa thực hiện giao dịch trực tuyến thì bảo mật chưa thật sự quan trọng, nhưng về lâu dài, khi các giao dịch thương mại ñiện tử trở thành xu thế tất yếu thì nếu ít quan tâm ñến bảo mật sẽ rất khó ñể tự bảo vệ mình

Web service ra ñời ñã mở ra một hướng mới trong việc phát triển các ứng dụng trên Internet Chính vì thế sự an toàn của web service trên mạng cũng không thể nằm ngoài vấn ñề này, có thể nói ngày nay ngoài việc nghiên cứu làm sao ñể tạo ra một web services tốt mang lại nhiều lợi ích thì việc nghiên cứu ñể làm sao mang lại sự

an toàn cho web services cũng là một trong những vấn ñề quan trọng nhất

Chính vì thế, cần thiết phải có nhiều ñề tài nghiên cứu về bảo mật mạng và những công cụ thực hiện bảo mật ñể có thể áp dụng chúng cho thực tế nước ta hiện nay

1.2 Mc tiêu ca ñ tài

Mục tiêu chính của ñề tài gồm:

• Nghiên cứu về web service và công nghệ Spring Web service

• Nghiên cứu về các ứng dụng Acegi Security ñể bảo mật web service trong Spring

• Viết một ứng dụng web nhỏ bán hàng trên mạng bằng web service mô phỏng việc dùng Acegi Security ñể bảo mật

Các tính năng của chương trình mà chúng tôi ñang xây dựng có thể ñược biểu diễn

trong use case diagram sau (Xem hình 1.1):

Xoa User

Xem don dat hang

Disable User

Enable User Admin

Xem san pham

Dat hang

Xem thong tin lien he

Dang nhap vao he thong

User

Dang ky thanh vien

Hình 1.1 – Use case diagram của chương trình

Nội dung chi tiết của các use case ñược cho trong bảng 1.1

Bảng 1.1: Mô tả các use case

Actor Admin

Xoa User Xóa một User trong danh sách

User

Disable User Loại bỏ các quyền của User

Enable User Khôi phục các quyền cho

User

Xem don dat hang Xem ñơn ñặt hàng của khách

Dang nhap vao he thong Dang nhap vao he thong

Actor user

Xem san pham Xem sản phẩm áo cưới hiện

có ở cửa hàng

Xem thong tin lien he Xem thông tin liên hệ của cửa

hàng

Dang ky thanh vien Dang ky thanh vien

Dang nhap vao he thong Dang nhap vao he thong

2 CHƯƠNG 2 – CƠ SỞ LÝ THUYẾT

Sau một thời gian nghiên cứu, nhóm ñã có một số kiến thức nhất ñịnh về Web Service, Spring Web service và Acegi Security ðây là cơ sở lý thuyết nền tảng cho ứng dụng

• Cho phép sự kết hợp lỏng lẻo, có nghĩa là mối tương tác giữa các ứng dụng dịch vụ sẽ không bị ngắt khi có sự thay ñổi ở một hay nhiều dịch

• ðem lại những chức năng quản trị và quản lý như là: ñộ tin cậy (reliability), trách nhiệm giải trình (accountability), bảo mật (security),… ñộc lập với những chức năng chính, ñiều này làm cường tính linh hoạt và hữu dụng trong môi trường tin học của doanh nghiệp

2.1.1.2 Cách thức làm việc của Web Service

• Client không chứa bất cứ thông tin về các dịch vụ web hiện thời, vì vậy trước hết nó phải ñi tìm dịch vụ web nào phù hợp với yêu cầu Client sẽ liên hệ với UDDI registry ñể hỏi về ñiều này

• UDDI registry sẽ trả lời cho chúng ta biết server nào cung cấp dịch vụ mà client cần

• Sau khi biết ñược nơi cung cấp dịch vụ, client cần phải biết cách thức gọi dịch vụ Vì thế nó phải hỏi server ñể có ñược mô tả chi tiết cách gọi dịch

vụ

• Server sẽ trả lời thông qua một ngôn ngữ chung là WSDL

• Tại bước này client sẽ gửi một SOAP message tới server, yêu cầu nó thực

• Sau khi thực hiện xong phương thức, server sẽ gửi kết qủa tới client bằng một thông ñiệp SOAP response chứa thông tin ñược yêu cầu hoặc thông báo lỗi trong trường hợp sự cố hoặc yêu cầu sai

2.1.1.3 Kiến trúc của công nghệ Web Service

Hình 2.1 mô tả kiến trúc của công nghệ Web Service Trong ñó bao gồm các tầng:

• Tầng vận chuyển với những giao thức chuẩn là HTTP, SMTP và JMS

• Tầng giao thức tương tác dịch vụ ( Service Communication Protocol) với giao thức chuẩn SOAP ( Simple Object Access Protocol) SOAP là giao thức nằm giữa tầng vận chuyển và tầng mô tả thông tin về dịch vụ, SOAP cho phép người dùng triệu gọi một service từ xa thông qua một message XML Có thể nói, SOAP là một giao thức giao tiếp có cấu trúc như XML

và mã hóa thành ñịnh dạng chung cho các ứng dụng trao ñổi với nhau

• Tầng mô tả dịch vụ (Service Description) với công nghệ chuẩn là WSDL

và XML WSDL(Web Services Description Language) là một ngôn ngữ dựa trên cú pháp XML dùng ñể mô tả một web service WSDL như một file ứng dụng trung gian ñứng giữa web service và web service client

• Tầng dịch vụ ( Service): cung cấp các chức năng của service

• Tầng ñăng ký dịch vụ (Service Registry) với công nghệ chuẩn là UDDI (Universal Description, Discovery and Integration) ðể có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách

sử dụng dịch vụ và biết ñược ñối tượng cung cấp dịch vụ UDDI ñịnh nghĩa những thông tin này ñể cho phép các doanh nghiệp (là các client) tìm kiếm và ñăng ký web service

• Bên cạnh ñó ñể cho các service có tính an toàn, toàn vẹn và bảo mật thông tin trong kiến trúc web service chúng ta có thêm các tầng Policy, Security, Transaction, Management giúp tăng cường tính bảo mật, an toàn và toàn vẹn thông tin khi sử dụng service

Hình 2.1 - Kiến trúc của Web Service

2.1.2 Các thành phần chính của Web Service

2.1.2.1.2 Cấu trúc tài liệu WSDL

Hình 2.2 - Cấu trúc WSDL

Trong một file WSDL phần tử gốc ñược ñặt tên “definitions” Phần tử này chứa năm phần tử con chính ñể ñịnh nghĩa web service:

• Phần tử “types”: ñịnh nghĩa các kiểu dữ liệu dùng ñể trao ñổi giữa client

và server (chỉ ñịnh nghĩa các kiểu dữ liệu phức tạp như structure, class…)

</definitions>

• Phần tử”portType”: ñịnh nghĩa một tập các chức năng web service hỗ trợ

và thông ñiệp tương ứng ñối với mỗi chức năng ñó

• WSDL ñịnh nghĩa bốn kiểu thao tác mà một cổng có thể hỗ trợ:

o One-way: cổng nhận một message, message ñó là message nhập

o Request-response: cổng nhận một message và gửi một message phản hồi

o Solicit-response: cổng gửi một message và nhận về một message

o Notification: cổng gửi một message, message ñó là message xuất Mỗi kiểu thao tác có cú pháp biến ñổi tùy theo: thứ tự của các message nhập, xuất và lỗi

<wsdl:definitions >

<wsdl:portType name="nmtoken">

<wsdl:operation name="nmtoken" /> * </wsdl:portType>

2.1.2.2.2 Cấu trúc của một message theo dạng SOAP

SOAP message là một văn bản XML bình thường bao gồm các phần tử sau:

• Phần tử gốc - envelop: phần tử bao trùm nội dung message, expressing

what is in a message; who should deal with it, and whether it is optional

Hình 2.2 - Cấu trúc của một message theo dạng SOAP

2.1.2.3 UDDI

2.1.2.3.1 Giới thiệu

ðể có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin

về cách sử dụng dịch vụ và biết ñược ñối tượng cung cấp dịch vụ UDDI ñịnh nghĩa một số thành phần cho biết trước các thông tin này ñể cho phép các client truyz tìm

và nhận lại những thông tin yêu cầu sử dụng web services

2.1.2.3.2 Cấu trúc của UDDI

Cấu trúc UDDI gồm các thành phần:

• Trang trắng - White pages: chứa thông tin liên hệ và các ñịnh dạng chính yếu của web services, chẳng hạn tên giao dịch, ñịa chỉ,… Những thông tin này cho phép các ñối tượng khác xác ñịnh ñược service

• Trang vàng - Yellow pages: chứa thông tin mô tả web services theo những chủng loại khác nhau Những thông tin này cho phép các ñối tượng thấy web services theo từng chủng loại của nó

• Trang xanh - Green pages: chứa thông tin kỹ thuật mô tả các hành vi và các chức năng của web services Các ñối tượng dựa vào ñặc ñiểm của web services ñể tìm kiếm

2.1.3 Tính bảo mật Web Service

2.1.3.1 Giới thiệu

WS - Security là một chuẩn an toàn bao trùm cho SOAP và cả những phần mở rộng của SOAP, nó ñược dùng khi muốn xây dựng những web service toàn vẹn và tin cậy WS - Security cung cấp nhiều hỗ trợ cho nhiều cơ chế an toàn khác nhau, nhiều khuôn dạng chữ ký, và nhiều công nghệ mã hóa Nó ñảm bảo cho tính an toàn, sự toàn vẹn thông ñiệp, và tính tin cậy của thông ñiệp

2.1.3.2 Những bước cần thiết ñể tạo sự an toàn thông tin trong một ứng dụng

ðể một ứng dụng an toàn và tin cậy, client và server phải có tính toàn vẹn thông tin Cấu hình tính toàn vẹn trong một ứng dụng ñược thực hiện qua các bước sau:

• Chỉ rõ những giải thuật sẽ ñược sử dụng bởi khóa ñể ký lên message

• Nếu một client chờ ñợi một sự phản hồi từ server với thông tin cũng yêu cầu phải toàn vẹn, thì client phải ñược cấu hình ñể làm cho có hiệu lực tính toàn vẹn của message phản hồi

2 Phía server:

• Cấu hình server ñể an toàn thông tin cần

• Chỉ rõ những thành phần của message cần ñược ký Nếu message ñến không có một chữ ký hợp lệ, thì yêu cầu sẽ thất bại

• Chỉ rõ một khóa ñể duyệt chữ ký của message ñến xem có hợp lệ hay không

• Chỉ rõ giải thuật mà khóa sử dụng làm cho có hiệu lực tínhr toàn vẹn của message gửi ñến

• Nếu có message phản hồi lại thì message ñó cũng phải ñược ký, và cung cấp thông tin chữ ký trong message phản hồi

2.2 Spring Web Service

2.2.1 Giới thiệu về Spring Framework và Spring Web Service 2.2.1.1 Giới thiệu Spring Framework

Spring là một application framework mã nguồn mở, ñược giới thiệu vào năm 2002 Rod Johnson ñã ñưa ra ý tưởng này từ kinh nghiệm làm việc với kiến trúc J2EE Ông ta ñã viết cuốn sách với tiêu ñề: “J2EE Develoment without using EJB” ñể giới thiệu khái niệm trình chứa hạng nhẹ (lightweight container) Với lý luận: EJB thì có giá trị của nó, nhưng không phải lúc nào cũng cần thiết và phù hợp cho tất cả các

ứng dụng Thay vì EJB, Spring sử dụng Java bean, với một vài sự thay ñổi ñể thu ñược tất cả các thuận lợi mà môi trường EJB ñưa ra Do ñó Spring là một sự lựa chọn khác so với EJB

2.2.1.2 Giới thiệu Spring Web Service

Spring web services là một sản phẩm của Spring community tập trung vào việc tạo những sản phẩm Web Service Spring web service nhắm vào việc làm nhẹ nhàng sự phát triển contract-first SOAP services Cho phép tạo ra những web service linh ñộng sử dụng những cách khác nhau ñể ñiều khiển XML payload

2.2.1.3 Môi trường runtime

Spring Web Services chạy với Java 1.3 Nó cũng hỗ trợ Java 5.0, mặc dù loại Java ñược ñặc tả cho phiên bản này ñược ñóng gói thành module với gói jar có ñuôi là

“tiger” Module bảo mật cũng yêu cầu Java 5 Spring web service bao gồm một số module sau:

• XML module (spring-xml.jar) chứa những class hỗ trợ XML cho Web service Module này có mục ñích chính cho Spring Web Service Framwork, và không phải là Web service developer

• Gói Core (spring-Web Service-core.jar và spring-Web tiger.jar) là phần trung tâm của của chức năng Spring web service Nó cung cấp những interfaces chính như WebserviceMessage và SoapMessage, framwork server-side, với sự phân phối thông ñiệp rất mạnh, và những class hỗ trợ việc ñịnh nghĩa endpoint của Web service; cuối cùng là client-side WebServiceTemplate

Service-core-• Gói Security (spring-Web Service-security.jar) cung cấp ñịnh nghĩa của Web Service-Security mà hợp nhất với gói Core Nó cho phép bạn thêm

những token cơ bản, chữ ký, mã hóa và giải mã thông ñiệp SOAP Thêm vào ñó, nó cho phép bạn ñẩy ñịnh nghĩa Acegi security cho authentication

Hình 2.3-Cấu trúc các module trong Spring Web Service

2.2.2.2 Vấn ñề không tương xứng Object/XML

Chúng ta gặp vấn ñề không tương xứng khi chuyển ñổi từ ñối tượng Java sang XML ðầu tiên, vấn ñề là tạo một XML element cho mỗi Java Object, chuyển ñổi toàn bộ các property và field của Java thành sub-element hoặc là attribute Tuy nhiên, có một số vấn ñề không ñơn giản xảy ra: có sự khác biệt về nền giữa hai ngôn ngữ như XML (và ñặc biệt là XSD) và mô hình ñồ họa của Java

2.2.2.2.1 Phần mở rộng XSD

Trong Java, có một cách ñể thay ñổi hành vi của một lớp là tạo lớp con của nó, và thêm hành vi mới trong lớp con ñó Trong XSD, bạn có thể mở rộng một dạng dữ liệu bằng cách hạn chế nó: ép giá trị ñúng cho các element và thuộc tính Cụ thể như ví dụ sau:

Kiểu như trên hạn chế một string XSD bằng một biểu thức phù hợp, chỉ cho phép 3

ký tự hoa Nếu kiểu này ñược chuyển sang Java, chúng ta sẽ chỉ sử dụng ñơn giản là java.lang.String; biểu thức trên sẽ mất trong quá trình chuyển ñổi, bởi vì Java không cho phép những kiểu lọc như vậy

2.2.2.2.2 Những loại không di chuyển ñược

Một trong những mục tiêu quan trọng của Web Service là trở nên tương thích: hỗ trợ ña nền như Java, Net, Python, v.v… Bởi vì hầu hết những ngôn ngữ trên có những lớp thư viện khác nhau, bạn phải sử dụng một loại ñịnh dạng công cộng ñể

giao tiếp giữa chúng Loại ñịnh dạng ñó là XML ñược hỗ trợ bởi tất cả các ngôn ngữ này

Bởi vì sự biến ñổi này, nên bạn phải chắc chắn rằng bạn phải sử dụng kiểu có thể chuyển ñổi ñược trong service của bạn Ví dụ như một service trả về java.util.Treemap như:

public Map getFlights() {

// use a tree map, to make sure it's sorted

TreeMap map = new TreeMap();

Vấn ñề này cũng ñược giới thiệu khi làm việc trên Client side Hãy xét một XSD snippet sau, mô tả một service contract:

<element name="from" type="string"/>

<element name="to" type="string"/>

</all>

</complexType>

</element>

Contract này ñịnh nghĩa một yêu cầu lấy một ngày (date), mà trong mô tả trong kiểu

dữ liệu của XSD là một năm (year), một tháng (month), một ngày (day) Nếu chúng

ta gọi service này trong Java, chúng ta sẽ phải sử dụng cả java.util.Date hoặc là java.util.Calendar Tuy vậy, cả hai kiểu trên ñều mô tả thêm thời gian (time) Nên chúng ta sẽ gửi dữ liệu mô tả ngày 4 tháng 4 năm 2007 vào nửa ñêm (2007-04-04T00:00:00), không giống với 2007-04-04

2.2.2.2.3 Cấu trúc vòng

Tưởng tượng chúng ta có một cấu trúc lớp ñơn giản như sau:

public class Flight {

private String number;

private List<Passenger> passengers;

// getters and setters omitted

}

public class Passenger {

private String name;

private Flight flight;

// getters and setters omitted

}

ðây là một mô hình vòng: Flight tham chiếu ñến Passenger, và ngược lại

Passenger tham chiếu ñến Flight một lần nữa Mô hình vòng khá phổ biến trong

Java Nếu chúng ta có cách tiếp cận ñơn giản ñể chuyển ñổi sang XML, chúng ta sẽ làm như sau:

<flight number="KL1117">

<passengers>

<passenger>

<name>Arjen Poutsma</name>

Cách này giải quyết vấn ựề ựệ quy, nhưng lại làm xảy ra một vấn ựề mới Bạn

không thể sử dụng một XML valitator ựể kiểm tra tắnh phù hợp của cấu trúc

Chỉ có một vài vấn ựề khi nói về Oject/XML mapping, nhưng những vấn ựề ựó rất quan trọng khi viết web service Cách tốt nhất ựể giải quyết chúng là hoàn toàn chú

ý vào XML mặc dù chúng ta sử dụng Java là một ngôn ngữ ựể cài ựặt đó là toàn bộ

ý nghĩa của contract-first

2.2.2.3 Ưu thế của contract-first so với contract-last

Bên cạnh việc giải quyết các vấn ựề về Object/XML mapping ựược nói ựến trong phần trước, có những lý do khác mà dạng contract-first ựược ưa thắch hơn

2.2.2.3.1 Tắnh chắc chắn

Như phần ựầu ựã ựề cập ựến, kết quả của dạng contract-last trên web service contract (WSDL và XSD) của bạn sẽ ựược sinh từ những Java contract (thường là interface) Nếu bạn ựang dùng cách tiếp cận này, bạn sẽ không chắc chắn rằng contract sẽ không ựổi qua thời gian Tại mỗi thời ựiểm bạn thay ựổi Java contract của bạn và deploy lại nó, có thể có những thay ựổi cho web service contract của bạn

Thêm vào ựó, không phải tất cả các stack SOAP ựều sinh ra những web service contract giống nhau từ một Java contract điều này có nghĩa là thay ựổi stack SOAP khác nhau có thể làm thay ựổi web service contract của bạn

ðể một contract hữu dụng, nó phải cố ñịnh Nếu một contract thay ñổi, bạn sẽ phải liên hệ với toàn bộ người sử dụng service của bạn, và hướng dẫn họ lấy contract phiên bản mới

2.2.2.3.2 Chất lượng

Trong khi Java tự ñộng chuyển ñổi sang XML, không có cách nào ñể biết chắc chắn cái gì ñã ñược gửi ñi Một ñối tượng có thể tham chiếu ñến một ñối tượng khác mà hướng theo một cái khác nữa, v.v… Cuối cùng, một nửa của ñối tượng trong heap của máy ảo có thể ñược chuyển thành XML mà sẽ trả về kết quả trong những lần trả lời sau

2.2.2.3.3 Khả năng tái sử dụng

ðịnh nghĩa Schema của bạn trong một tập tin riêng biệt cho phép bạn sử dụng lại

tập tin ñó trong những bước diễn tiến khác nhau Nếu bạn ñịnh nghĩa AiportCode trong một tập tin ñược ñặt tên là airline.xsd như sau:

Nếu sử dụng contract-first, chúng ta có thể có một sự kết hợp chặt chẽ giữa contract

và sự cài dặt Ví dụ như sự kết hợp chặt chẽ cho phép chúng ta cài ñặt cả những phiên bản của contract trong một class Chúng ta có thể sử dụng một XSLT stylesheet ñể chuyển ñổi một số thông ñiệp “old-style” thành thông ñiệp “new-style”

2.2.2.4 Cách viết một Contract-first web service

2.2.2.4.1 Giới thiệu

Sau ñây là cách viết một contract-first Web Service, có nghĩa là phát triển web service bắt ñầu với XML Shema/WSDL tiếp theo là mã Java Trong phần này, chúng tôi xin giới thiệu một web service, client có thể gửi yêu cầu kỳ nghỉ lên server ñể ñặt trước

element ñể chắc chắn rằng những element của chúng ta có thể ñược sử dụng tốt ở những tài liệu XML khác

Chúng ta ñã sử dụng cùng một namespace như khi ñịnh nghĩa một holiay

Nếu element <Employee/> có thể ñược sử dụng trong trường hợp khác, nó

có thể ñược tạo ra trong namespace khác ví dụ như: http://mycompany.com/employees/schemas

c) HolidayRequest

Cả hai element holiday và employee ñều có thể ñược ñể trong

<HolidayRequest/>:

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

<StartDate>2006-07-03</StartDate>

<EndDate>2006-07-07</EndDate>

</Holiday>

<Employee>

Bây giờ chúng ta ñã xem xong một số ví dụ của dữ liệu XML mà chúng ta sẽ dùng,

nó ñược ñịnh dạng thành một schema Contract dữ liệu có ñịnh nghĩa cách ñịnh dạng một thông ñiệp mà chúng ta chấp nhận Có bốn cách các nhau ñể ñịnh nghĩa một contract cho XML:

Hơn nữa, cách ñơn giản nhất ñể tạo một XSD là suy nó ra từ một tài liệu ví dụ Bất

kỳ bộ soạn thảo XML hoặc một IDE Java nào cũng cung cấp chức năng này Một cách cơ bản, những công cụ này sử dụng một số tài liệu XML làm ví dụ, và sinh ra một schema từ nó và kiểm chứng toàn bộ chúng Kết quả cuối cùng tất nhiên là cần ñược ñánh bóng lại, tuy nhiên ñó là một ñiểm xuất phát tuyệt vời

Sử dụng ví dụ mô tả ở trên, chúng ta sẽ có ñược một schema sinh ra như sau:

<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:element name="Number" type="xs:integer"/>

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

</xs:schema>

Schema ñược sinh ra này có thể ñược phát triển lên ðiều ñầu tiên cần nhớ là loại nào cũng có một element ñược khai báo cấp root Như vậy có nghĩa là Web service nên chấp nhận toàn bộ những element này như là dữ liệu Nếu mong muốn: chúng

ta chỉ muốn chấp nhận một <HolidayRequest/> thì bằng cách xóa bỏ những tag

element xuống dòng tự ñộng, và những kết quả nằm trong dòng, chúng ta có thể hoàn thành ñiều này

<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:schema>

Schema vẫn còn một vấn ñề: với một schema như vậy, bạn có thể mong muốn một thông ñiệp như sau ñể hợp thức hóa:

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

<StartDate>this is not a date</StartDate>

thể thay ñổi sequence trong <HolidayRequest/> thành all XSD cuối cùng của

chúng ta như sau:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:hr="http://mycompany.com/hr/schemas"

Chúng ta sử dụng loại xsd:date bao gồm cả năm, tháng và ngày cho

<StartDate/> và <EndDate/>

xsd:string ñược dùng cho họ và tên

Chúng ta lưu trữ tập tin thành hr.xsd

2.2.2.4.4 Service Contract

Một contract dịch vụ nói chung ñược biểu diễn thành một tập tin WSDL Phần này

sẽ giới thiệu cách tạo ra một WSDL bằng tay

Mặc dù dựa trên XSD và một số dạng chuẩn, Spring-Web Service có thể tạo ra WSDL tự ñộng, ñiều này chúng tôi sẽ giải thích sau trong mục “Cài ñặt endpoint”

Chúng ta bắt ñầu WSDL của chúng ta với phần mở ñầu chuẩn, và bằng cách import vào tập tin XSD ñã có của chúng ta ðể tách riêng schema ra khỏi ñịnh nghĩa, chúng

ta sẽ sử dụng một namespace riêng cho ñịnh nghĩa WSDL: http://mycompany.com/hr/definitions

<Web Servicedl:definitions xmlns:Web

<xsd:schema

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

Tiếp theo, chúng ta thêm vào thông ñiệp của chúng ta loại schema ñược viết Chúng

ta chỉ có duy nhất một thông ñiệp với <HolidayRequest/> ñược ñặt trong schema:

<Web Servicedl:message name="HolidayRequest">

<Web Servicedl:part

element="schema:HolidayRequest" name="HolidayRequest"/>

</Web Servicedl:message>

Chúng ta thêm thông ñiệp vào port type như một phép toán:

<Web Servicedl:portType name="HumanResource">

<Web Servicedl:operation name="Holiday">

message="tns:HolidayRequest" name="HolidayRequest"/> </Web Servicedl:operation>

</Web Servicedl:portType>

Vậy là xong phần abstract của WSDL, và còn lại phần concrete Phần này bao gồm một binding, mà cho client biết bằng cách nào ñể ñưa ra thao tác mà bạn vừa mới ñịnh nghĩa; và một service cho client biết chỗ nào ñể dẫn ra chúng

Cách thêm phần concrete chuẩn như sau: chỉ cần chỉ ra phần abstract bạn ñã ñịnh nghĩa trước ñó, chắc chắn rằng bạn sử dụng document/literal cho element soap: binding, chọn soapAction cho thao tác (trong trường hợp này là http://mycompany.com/RequestHoliday, nhưng URI nào cũng làm ñiều này ), và

làm rõ location URL nơi mà bạn muốn gửi yêu cầu ñến (trong trường hợp này là

<Web Servicedl:operation name="Holiday">