Công nghệ Web Service và ứng dụng để xây dựng kiến trúc hướng dịch vụ

Thông thường khi triển khai phần mềm, doanh nghiệp đều gặp phải vấn đề khó khăn là làm sao để dữ liệu từ các phần mềm khác nhau về mặt kiến trúc và định nghĩa dữ liệu, phục vụ cho các mụ

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

M ỤC LỤC

LỜI CẢM ƠN Error! Bookmark not defined

MỤC LỤC 3

BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT 5

DANH MỤC CÁC BẢNG 6

DANH MỤC CÁC HÌNH 7

MỞ ĐẦU 8

CHƯƠNG 1 TỔNG QUAN VỀ WEB SERVICE 11

1.1 Các công nghệ hỗ trợ trước web service 11

1.2 Web service là gì 12

1.3 Lợi ích của việc sử dụng web service 14

1.4 Kiến trúc tổng quan của web service 14

CHƯƠNG 2 CÁC CÔNG NGHỆ NỀN TẢNG CỦA WEB SERVICE 16

2.1 XML 16

2.1.1 Khái niệm về XML 16

2.1.2 Các quy tắc cú pháp của XML 16

2.1.3 XML có định dạng tốt (Well-formed XML) 18

2.1.4 XML đúng đắn (Valid XML) 18

2.1.5 Không gian tên (Namespaces) 22

2.1.6 Tên viết tắt (Qualified Names - QNames) 24

2.1.7 CDATA 25

2.1.8 Trình diễn dữ liệu XML trên web 25

2.2 SOAP 26

2.2.1 Đặc trưng của SOAP 26

2.2.2 Cấu trúc một thông điệp (Message) theo dạng SOAP 27

2.2.3 SOAP trong HTTP 38

2.3 WSDL 40

2.4 UDDI 42

2.5 Hoạt động chung của một web service 43

CHƯƠNG 3 ỨNG DỤNG WEB SERVICE ĐỂ XÂY DỰNG KIẾN TRÚC HƯỚNG DỊCH VỤ 48

3.1 Tổng quan về kiến trúc hướng dịch vụ 48

3.1.1 SOA là gì? 48

3.1.2 Các lợi ích của SOA: 49

3.1.3 Khi nào sử dụng SOA ? 49

3.1.4 Mối quan hệ giữa web service và kiến trúc hướng dịch vụ (SOA) 50

3.2 Bài toán ứng dụng công nghệ Web Service trong xây dựng kiến trúc hướng dịch vụ 51

3.2.1 Mô tả hoạt động của web service 51

3.2.2 Đặc tả về các hệ thống giao tiếp 52

3.2.3 Đặc tả về giao diện kết nối 55

CHƯƠNG 4 THỰC NGHIỆM 57

4.1 Thực nghiệm 57

4.1.1 Giao dịch vấn tin tài khoản (Account Inquiry) 57

4.1.1 Giao dịch cập nhật số dư tài khoản (Balance Update) 59

4.2 Đánh giá kết quả thực nghiệm 61

KẾT LUẬN 67

TÀI LIỆU THAM KHẢO 68

BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT

Integration

DANH MỤC CÁC BẢNG

Bảng 2.1: Các thành phần logic của web service 43 Bảng 4 1: Bảng mô tả chi tiết các trường trong phần header của thông điệp 57 Bảng 4.2: Bảng mô tả chi tiết các trường trong phần dữ liệu của thông điệp gửi đi 58 Bảng 4.3: Bảng mô tả chi tiết các trường trong phần dữ liệu của thông điệp trả về 58 Bảng 4 4: Bảng mô tả chi tiết các trường trong phần dữ liệu của thông điệp gửi đi 59

DANH MỤC CÁC HÌNH

Hình 1.1: Kiến trúc của Web Service 15

Hình 2.1: Mô hình trình diễn dữ liệu XML trên Web 26

Hình 2.2: SOAP với các giao thức HTTP, SMTP, và Raw TCP/IP 27

Hình 2.3: Cấu trúc của thông điệp SOAP 28

Hình 2.4: SOAP message path 31

Hình 2.5: Message path của thông điệp SOAP purchase-Order 32

Hình 2 6: Mô hình hoạt động của SOAP 38

Hình 2.7: Thông điệp yêu cầu của SOAP 39

Hình 2.8: Thông điệp hồi đáp của SOAP 40

Hình 2.9: Cấu trúc của WSDL 40

Hình 2.10: Các thành phần logic của web service 45

Hình 2.11: Biểu đồ ca sử dụng của web service 46

Hình 2.12: Biểu đồ tuần tự 46

Hình 3.1: Mô hình SOA phát triển lên từ mô hình đối tượng 510

Hình 3.2: Mô hình kết nối giữa 2 hệ thống 52

Hình 3.3:Mô hình kiến trúc SOA cho ngân hàng của IBM 53

Hình 3.4:Hệ thống theo kiến trúc SOA sử dụng công nghệ WS 55

Hình 3.5: Thông điệp theo định dạng ABCS 55

Hình 3.6: File đặc tả các trường trong header 56

Hình 4.1: Thông điệp gửi đến 58

Hình 4.2: Thông điệp sau khi được thêm header và chuyển sang định dạng của hệ thống core 58

Hình 4.3: Thông điệp gửi đến 60

Hình 4.4: Giao diện luông xử lý thông điệp 61

Hình 4.5:Thao tác với file đặc tả WSDL 61

Hình 4.6: Luồng xử lý tại nút Inquiry 62

Hình 4.7: Giao diện làm việc với môi trường coding 62

Hình 4.8: Đoạn lập trình các thao tác làm việc với core 63

Hình 4.9: Giao diện web service 64

Hình 4.10: Giao diện đăng ký web service với UDDIRegistry 64

Hình 4.11:Thử nghiệm với thông điệp đầu vào của giao dịch Vấn tin TK 64

Hình 4.12:Kết quả trả về 65

MỞ ĐẦU

Tích hợp dữ liệu (Data Integration) là qui trình trao đổi dữ liệu giữa các hệ thống quản lý thông tin kinh doanh để đưa ra được thông tin đầy đủ nhằm phục vụ mục đích quản trị Khi hai ứng dụng (Applications) trao đổi dữ liệu dựa trên thông tin của các qui trình định sẵn, chúng ta gọi là tích hợp ứng dụng (Enterprise Application Integration hay là EAI) Thông thường khi triển khai phần mềm, doanh nghiệp đều gặp phải vấn đề khó khăn là làm sao để dữ liệu từ các phần mềm khác nhau (về mặt kiến trúc và định nghĩa dữ liệu), phục vụ cho các mục đích của các bộ phận nghiệp vụ khác nhau được tập trung về hệ thống quản lý tài chính trung tâm, nhằm đáp ứng những nhu cầu thông tin quản lý để ban lãnh đạo kịp thời ra quyết định Trong bối cảnh cạnh tranh ngày càng khốc liệt hiện nay, các doanh nghiệp đang phải đối mặt những đối thủ khổng lồ, với hệ thống thông tin tích hợp hiện đại và chính xác thì nhu cầu tích hợp càng bức thiết cho bất cứ doanh nghiệp nào muốn đứng vững trên thị trường[4]

Trong quá trình hình thành doanh nghiệp, các doanh nghiệp quản lý phần mềm thường theo nhu cầu tự phát, thiếu tính chiến lược – Các phần mềm chủ yếu là do doanh nghiệp mua hoặc tự phát triển để đáp ứng được nhanh nhất các yêu cầu về quản

lý và nghiệp vụ Khi có nhu cầu cao hơn, doanh nghiệp lại tiếp tục phát triển các phần mềm mới hoặc nâng cấp các phần mềm hiện có để nhằm thỏa mãn những nhu cầu khác nhau Dần dà, doanh nghiệp nhận ra mình đang sở hữu rất nhiều phần mềm, mỗi phần mềm chỉ thỏa mãn được một nhu cầu nào đó, nhưng các phần mềm này lại không chia sẻ dữ liệu với nhau, hoặc phối hợp với nhau một cách thiếu đồng bộ Đến thời điểm hiện nay những hệ thống như vậy bộc lộ quá nhiều khuyết điểm do nhiều nguyên nhân khách quan cũng như chủ quan như sau [3]:

- Các phần mềm thiếu một kiến trúc và chuẩn dữ liệu đồng nhất

- Các phần mềm thiếu cơ sở đồng nhất về hạ tầng

- Do doanh nghiệp phát triển nhanh chóng, số lượng giao dịch tăng làm ảnh hưởng đến hoạt động của phần mềm mà mục đích chỉ sử dụng cho các giao dịch đơn lẻ

- Có quá nhiều phần mềm nhỏ lẻ, khó quản lý, chi phí cho đội ngũ quản lý và bảo trì phần mềm rất lớn

- Việc báo cáo định kỳ đòi hỏi sự phối hợp và trao đổi dữ liệu giữa các phòng ban, do đó Ban điều hành chậm nhận được báo cáo về tình hình hoạt động của doanh nghiệp, gây chậm trễ trong việc ra quyết định

- Việc quản lý sẽ trở nên khó kiểm soát nếu doanh nghiệp có nhiều chi nhánh hoặc bộ phận trong nước và nước ngoài, hay công ty muốn chuyển đổi thành tập đoàn hay công ty đa quốc gia

Để khắc phục các điểm yếu trên, doanh nghiệp thường chọn một trong hai giải pháp:

1 Chọn mua một phần mềm hoàn toàn mới, có tất cả chức năng cần thiết cho việc quản lý tổng thể với chi phí phần mềm và chi phí triển khai, bảo trì cao với sự chuyển đổi dữ liệu phức tạp

2 Xác định một phần mềm tích hợp trung tâm (Central Integration Hub), liên kết đồng bộ dữ liệu từ các hệ thống đơn lẻ về hệ thống tích hợp này, sau đó gửi dữ liệu

đã được cập nhật trực tuyến đến các hệ thống khác

Gần đây, một số doanh nghiệp lớn trong nước bắt đầu chuyển sang mua và triển khai các phần mềm ERP đã được sử dụng nhiều trên thế giới như của Oracle, SAP, Sun System , các phần mềm chuyên biệt cho hệ thống khách sạn, bảo hiểm, ngân hàng, bệnh viện với chi phí đầu tư lên đến vài trăm nghìn hoặc vài triệu USD Không phải tất cả những doanh nghiệp này đều đã nghĩ đến bài toán Tích hợp hệ thống Họ đã chọn nhiều phần mềm khác nhau để triển khai Có công ty đã chọn Oracle cho kế toán tài chính; SAP cho phân hệ CRM; Solomon cho kho bãi và phân phối[4] Triển khai như thế có lợi là sẽ sử dụng được tất cả thế mạnh của mỗi phần mềm, nhưng việc tích hợp các hệ thống này trong tương lai sẽ là một bài toán khó cho bất kỳ một đội ngũ IT mạnh mẽ nào

Trước thực trạng trên ta thấy được bài toán tích hợp ứng dụng trong các hệ thống là bài toán mà bất kỳ doanh nghiệp nào cũng có thể gặp phải, tuy nhiên, việc sử dụng công nghệ nào để có thể tích hợp giữa các hệ thống lại là một bài toán khác Nếu trước đây, người ta thường đề cập đến nhiều công nghệ khác nhau như COM (Common Object Manifest), CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation), RPC (Remote Procedure Call) được dùng để gọi đối tượng từ xa thì những năm gần đây, thuật ngữ ―Web service‖ được rất nhiều người nhắc đến như là một giải pháp lý tưởng cho bài toán tích hợp doanh nghiệp Và khi nhắc đến Web Service, người ta thường coi đó là một trong những cách thức hiệu quả

để xây dựng kiến trúc hướng dịch vụ SOA (Service Oriented Architecture) – một trong những kiểu kiến trúc được đánh giá là có khả năng đem lại cho doanh nghiệp một kiến trúc linh hoạt và khả chuyển

Bài luận văn tập trung vào hai nội dung chính là: tìm hiểu những khái niệm cơ bản về web service, và vai trò của web service trong việc tích hợp ứng dụng và khả năng ứng dụng của Web service trong việc xây dựng kiến trúc hướng dịch vụ như thế nào

Các phần còn lại của luận văn được cấu trúc như sau:

Chương 1 trình bày về những khái niệm tổng quan về khái niệm Web service, các lợi ích mà web service đem lại cũng như đưa ra một cái nhìn chung về kiến trúc của web service

Chương 2 trình bày về các công nghệ nền tảng của web service, bao gồm các công nghệ như XML, SOAP, WSDL và UDDI

Chương 3 giới thiệu tổng quan về kiến trúc hướng dịch vụ, lợi ích của kiến trúc này đem lại cũng như khả năng sử dụng web service để xây dựng kiến trúc này Trong chương 3 cũng mô tả về một bài toán ứng dụng cụ thể xây dựng một web service thực hiện việc giao tiếp giữa hai hệ thống sử dụng các định dạng thông điệp khác nhau

Chương 4 đưa ra một số kết quả thực nghiệm thu được khi xây dựng web service trong bài toán đã được mô tả trong chương 3

CHƯƠNG 1 TỔNG QUAN VỀ WEB SERVICE

1.1 Các công nghệ hỗ trợ trước web service

Sự ra đời của phương pháp lập trình hướng đối tượng đã đem lại nhiều hứa hẹn

về khả năng tái sử dụng mã nguồn trên nhiều hệ thống và kiến trúc Để giúp giảm thiểu thời gian và công sức cho các lập trình viên, các kho mã nguồn ra đời nhằm cung cấp các thư viện thực hiện các chức năng cơ bản cho lập trình viên (Ví dụ như các thư viện thương mại C++ chứa các phương thức tao tác chuẩn trên ngày và giờ, ) Tuy nhiên, các thư viện thương mại này chỉ có thể cung cấp các chức năng cơ bản và các lớp tổng quát cần thiết, còn đối với một số nghiệp vụ đặc biệt, như nghiệp vụ của ngân hàng, đòi hỏi phải xây dựng các gói thư viện riêng phù hợp với từng nghiệp vụ của mỗi công ty Ban đầu, các công ty xây dựng các gói thư viện nghiệp vụ dưới dạng các thư viện liên kết động DLL (Dynamic Link Library) Các thư viện này chứa thông tin cho các ứng dụng khác dùng để tạo các đối tượng và chỉ có thể lập trình để chạy trên cùng một máy (như các tập tin DLL) Tuy nhiên, nếu trong một tập đoàn lớn, với yêu cầu phải bảo trì hàng trăm ngàn máy trạm và các ứng dụng trên mỗi hệ thống, việc có những thư viện này trên mỗi hệ thống sẽ gây ra rất nhiều khó khăn khi phải tiến hành bảo trì.Do đó, việc dùng các đối tượng từ xa là một cách tối ưu để sử dụng lại mã nguồn ở mức ứng dụng trên một máy cục bộ Các đối tượng từ xa là các đối tượng được tạo ra ở trên một máy chủ trung tâm và có thể được truy cập từ máy trạm thông qua mạng, kể cả Internet.Trước khi web service ra đời, người ta thường sử dụng ba công nghệ dùng để gọi các đối tượng từ xa là RMI, DCOM (COM) và CORBA

 RMI (Remote Method Invocation): Là phương thức do công ty JavaSoft đưa

ra và được xây dựng trên ngôn ngữ Java RMI là các hàm thư viện hỗ trợ các lời gọi phương thức từ xa và trả về giá trị cho các ứng dụng tính toán phân tán Chúng ta giả

sử rằng ngôn ngữ Java được sử dụng ở cả phía gọi và phía bên phương thức được gọi.RMI là một tập các hàm thư viện đơn giản vì cả 2 bên đều sử dụng cùng môt ngôn ngữ lập trình và kiến trúc máy Điều này sẽ làm cho vấn để triệu gọi phương thức từ xa

dễ giải quyết hơn.Tuy nhiên sử dụng RMI đòi hỏi các ứng dụng của client-server phải được viết trong ngôn ngữ Java.Các đối tượng trong RMI không thể giao tiếp với các đối tượng không phải là đối tượng Java.Chính vì vậy, RMI chỉ thích hợp cho các ứng dụng được viết trên ngôn ngữ Java[19]

 DCOM (Distributed Component Object Model - Mô hình Đối tượng Thành phần phân tán): Đây là một sự mở rộng của COM (Component Object Model) DCOM được phát triển bởi Microsoft cho những hệ điều hành Windows.Nó hỗ trợ những đối tượng được phân tán qua một mạng gần giống như giao thức DSCOM của IBM (là một thực thi của CORBA)[17] Tuy nhiên DCOM chỉ dùng tốt cho hệ thống phân bố dành cho destop khó mở rộng trong cấp độ enterprise,và các ứng dụng của DCOM chỉ tốt trên các ứng dụng của Microsoft

 CORBA (Common Object Request Broker Architecture): Là kiến trúc do tổ chức OMG (Object Management Group) đưa ra.CORBA là một trong những giao thức được sử dụng khá phổ biến để phát triển các ứng dụng phân tán (distributed) hướng đối tượng (object-oriented) CORBA là một chuẩn công nghiệp cho phép gọi các phương thức từ xa và nhận kết quả trả về, nhưng không giống như RMI, nó có thể được sử dụng khi bên phía gọi và bên phía phương thức được gọi có thể sử dụng các ngôn ngữ lập trình khác nhau, bao gồm cả trường hợp là cả 2 bên đều không sử dụng ngôn ngữ Java CORBA sử dụng ORB (Object Request Broker) đóng vai trò như một middleware cho việc gọi một chương trình từ xa.ORB sử dụng một ngôn ngữ CORBA IDL để định nghĩa giao diện (interface) và cái này tách biệt với sự hiện thực của một đối tượng[18].Tuy nhiên các hệ thống của CORBA cũng chỉ giao tiếp được với các hệ thống khác cùng sử dụng chuẩn CORBA

Một đặc điểm chung của các giao thức trên đó là nó chỉ hoạt động được trên cùngcác hệ thống sử dụng công nghệ hoặc ngôn ngữ giống nhau, chính vì vậy vấn đề đặt ra là: Làm sao để các hệ thống phân tán được phát triển trên các công nghệ khác nhau, được xây dựng bằng các ngôn ngữ khác nhau có thể giao tiếp với nhau?Microsoft đã tạo ra một giao thức chuẩn dựa trên XML gọi là SOAP (Simple Object Access Protocol – Giao thức truy cập đối tượng đơn giản) Giao thức này là sự kết hợp việc lưu trữ dữ liệu dưới định dạng XML và một giao thức chuẩn cho phép truyền tải dữ liệu qua Internet.Những giao thức mà SOAP thường sử dụng để truyền tải bao gồm SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) và HTTP (Hypertext Transfer Protocol).Các nhà phát triển thường xem những giao thức này như là chồng các giao thức của Web Service.Sự ra đời của web service cung cấp khả năng chia sẻ dữ liệu giữa các ứng dụng và cơ chế giao tiếp giữa các đối tượng một cách linh hoạt và dễ dàng, độc lập với ngôn ngữ phát triển, hệ điều hành và các công nghệ mà đối tượng đó sử dụng[13]

1.2 Web service là gì

Ta hãy xem một số tổ chức định nghĩa như thế nào về web service

Theo Tổ chức W3C [13]:

o Web service là một hệ thống phần mềm được thiết kế để hỗ trợ các tương tác từ máy này tới máy khác (machine to machine) thông qua mạng internet.Web service là các web API có thể truy cập được thông qua mạng Internet, và được thực hiện tại hệ thống từ xa có chứa các dịch vụ được yêu cầu Các hệ thống khác tương tác với web service thông qua việc sử dụng các thông điệp XML tuân theo chuẩn SOAP …

Như vậy ta có thể hiểu khái niệm Service ở đây là chỉ những ứng dụng mà mình muốn cho bên ngoài sử dụng Ví dụ: Chương trình của bạn chỉ có 1 lớp Java đơn giản như sau:

Class HelloWorld {

public HelloWorld() {

super();

} public String sayHello(String str) {

1.3 Lợi ích của việc sử dụng web service

Việc sử dụng Web Service có những lợi ích sau[10,14]:

 Chia sẻ dữ liệu: Web Service cho phép các ứng dụng chia sẻ dữ liệu, cung cấp khả năng gọi đến các ứng dụng khác mà không cần quan tâm đến các ứng dụng đó được phát triển bằng ngôn ngữ nào, chạy trên hệ điều hành hoặc môi trường nào, v.v… Mặc dù các ứng dụng Web Service là độc lập với nhau, nhưng chúng có thể liên kết với nhau để thực hiện một công việc cụ thể Do đó, người dùng có thể sử dụng bất kỳ chương trình phía khách nào để gọi đến các phương thức của các Web Service, tương tác và lấy kết quả vềtheoyêu cầu để xử lý

 Chi phí thấp: Web Service được xây dựng trên công nghệ XML Như vậy dữ liệu có thể được truyền qua các môi trường và hệ điều hành khác nhau mà không bị phụ thuộc vào các ngôn ngữ lập trình được sử dụng Do đó, giảm được chi phí và thời gian để xây dựng một môi trường giao tiếp dữ liệu linh hoạt giữa các hệ thống khác nhau

 Thông tin được cập nhật thường xuyên và linh hoạt: Web Service không chỉ cho phép các hệ thống kết nối với nhau mà còn cho phép kết nối thông tin giữa người sử dụng thông tin và các thông tin mà họ cần khai thác Sau đó thông tin có thể được sử dụng theo bất cứ một khuôn dạng nào mà người sử dụng thông tin mong muốn Người sử dụng thông tin có thể yêu cầu bất cứ thông tin nào, tại một thời điểm bất kỳ từ địa điểm cung cấp các dịch vụ Web mà không phải đợi thông tin được chuyển lên theo định kỳ [8]

 Lượng thông tin phong phú: Tăng khả năng thu thập và trao đổi thông tin

từ nhiều nguồn khác nhau thông qua việc liên kết thông tin giữa các Web Service Do

đó, giảm được gánh nặng lưu trữ dữ liệu tại trung tâm lưu trữ (khả năng lưu trữ phân tán)

 Khả năng bảo mật cao: Các phương thức của Web Service có thể yêu cầu một số thông tin từ phía người dùng trong các yêu cầu được gửi đến cho chúng Các thông tin trao đổi (mô tả bằng XML) có thể được mã hóa theo chuẩn mã hóa XML Nếu các Web Service sử dụng các phương thức trao đổi dữ liệu dưới dạng nhị phân (thông qua cơ chế gọi thủ tục từ xa – Remote Procedure Call), chúng sẽ được tăng cường bảo mật bởi chính các công nghệ RPC của từng nhà cung cấp dịch vụ

1.4 Kiến trúc tổng quan của web service [20]

Web Service bao gồm nhiều tầng Về cơ bản, đó là một cơ chế chuẩn liên quan đến việc nhận biết, mô tả, và tìm kiếm các chức năng được cung cấp bởi một ứng dụng

Web Service.Kiến trúc của web service được mô tả trong hình dưới đây:

Hình 1.1:Kiến trúc của Web Service

Trong đó bao gồm các tầng [9]:

 Tầng vận chuyển với những công nghệ chuẩn là HTTP , SMTP và JMS

 Tầng giao thức tương tác dịch vụ (Service Communication Protocol) với công nghệ chuẩn là SOAP 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

 Tầng mô tả dịch vụ (Service Description) với công nghệ chuẩn là WSDL và XML.WSDL là mô ̣t ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML Web service sử du ̣ng ngôn ngữ WSDL để truyền các tham số và các lo ại dữ liệu cho các thao tác, các chức năng mà web service cung cấp

 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.UDDI dùng cho cả người dùng và ̣ SOAP server , nó cho phép đăng ký d ịch vụ để người dùng có thể gọi thực hiện service từ xa qua mạng, hay nói cách khác một service cần phải được đăng ký để cho phép các client có thể gọi thực hiện 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[15]

CHƯƠNG 2 CÁC CÔNG NGHỆ NỀN TẢNG CỦA WEB SERVICE

2.1 XML

2.1.1 Khái niệm về XML

XML, viết tắt của chữ eXtensible Markup Language, là ngôn ngữ được tổ chức mạng toàn cầu (W3C)định nghĩa Trong HTML, các thẻ được định nghĩa và quy định trước, còn trong XML người dùng được phép tự do đặt tên các cặp thẻ để dùng khi cần.Với khả năng này, XML không những cho phép mô tả cấu trúc dữ liệu văn bản mà còn cho cả các kiểu dữ liệu khác, như hình ảnh, âm thanh

Điểm khác biệt chính giữa HTML và XML là trong khi các cặp thẻ của HTML chứa ý nghĩa về cách trình bày (formatting) các dữ liệu, thì các cặp thẻ của XML còn bao hàm nội dung cả về cấu trúc vàtrình diễn của dữ liệu Khi muốn trình bày các dữ kiện của một trang XML theo một kiểu nào đó, phục vụ hiển thị trên các thiết bị khác nhau, ta dùng một bảng định kiểu (Style Sheet) tương ứng cho nó Ví dụ, muốn trình bày cùng một nội dung tài liệu XML nhưng hiển thị trên hai thiết bị khách nhau, một trên PC và một trên Mobile Phone (điện thoại di động), ta sẽ dùng hai Style Sheet khác nhau, một cho PC, cái kia cho Mobile Phone

2.1.2 Các quy tắc cú pháp của XML [2]

Các quy tắc cú pháp của XML được định nghĩa rất đơn giản nhưng chặt chẽ giúp cho XML dễ học và dễ sử dụng Các tài liệu XML sử dụng các cú pháp tự mô tả chính nó Xét ví dụ về một tài liệu XML sau:

Dòng đầu tiên của tài liệu là dòng khai báo XML, định nghĩa phiên bản XML

và bảng mã ký tự được sử dụng trong tài liệu.Trong ví dụ này, tài liệu sử dụng đặc tả XML phiên bản 1.0 và bảng mã ký tự IS0-8859-1 (Latin 1/Western European).Dòng thứ hai mô tả phần tử gốc (root element) Bốn dòng tiếp theo là bốn phần tử con (child element) của phần tử gốc và dòng cuối cùng là định nghĩa kết thúc phần tử gốc Ta có thể dễ dàng nhận thấy rằng, tài liệu XML này mô tả một nhắc nhở (note) từ ―Jani‖ gửi tới ―Tove‖ do cú pháp của XML mô tả chính nó

Tất cả các phần tử XML đều phải nằm trong một cặp thẻ Ví dụ:

Khai báo nhƣ trên là không hợp lệ do thẻ <address> nằm trong cặp thẻ <name> và

</name>, còn thẻ </address> lại nằm ngoài

Tất cả các tài liệu XML đều phải có một cặp thẻ định nghĩa một phần tử gốc của tài liệu Tất cả các phần tử con của nó phải nằm trong phần tử gốc này Tất cả các phần

tử trong XML đều có thể có một hoặc nhiều các phần tử con Những phần tử con này phải nằm giữa cặp thẻ định nghĩa phần tử cha Ví dụ:

Không giống như HTML, trong XML, tất cả các ký tự trắng sẽ được giữ nguyên

và không bị loại bỏ khi sử dụng hay hiển thị

Cú pháp để viết dòng chú thích trong XML cũng giống như trong HTML:

<!—- Nội dung chú thích >

2.1.3 XML có định dạng tốt (Well-formed XML)

Mặc dù số lượng cặp thẻ trong một tài liệu XML là không hạn chế, nhưng mỗi tài liệu cần phải tuân theo một số qui luật để được xem là đúng chuẩn (Well-Formed) Nếu một trang XML không theo mẫu chuẩn thì coi như không dùng đuợc, không có chương trình xử lý nào có thể làm việc với dữ liệu bên trong nó Do đó, khi xây dựng một trang XML cần phải tuân theo đúng các qui luật sau:

1 Tất cả các tài liệu XML đều phải có một phần tử gốc

2 Tất cả các phần tử phải nằm trong một cặp thẻ

3 Tất cả các thẻ trong XML đều phân biệt chữ hoa, chữ thường

4 Các cặp thẻ không được xen kẽ nhau

5 Các giá trị của các thuộc tính phải nằm trong dấu ngoặc kép

Trang tài liệu XML tuân theo các quy luật trên (hay nói cách khác là đúng cú pháp) sẽ được coi là Well-Formed

2.1.4 XML đúng đắn (Valid XML)[2]

XML chứa các dữ liệu bằng cách dùng những cặp thẻ, nhưng tự nó không đòi hỏi các dữ liệu nào cần phải có hay chúng phải liên hệ với nhau như thế nào Một cách để thực hiện việc này là thêm vào phần đầu của một trang XML những qui luật mà các dữ liệu phải tuân theo để trang XML đuợc xem là có ý nghĩa Tập hợp các qui luật đó được gọi là Document Type Definition (DTD) DTD phải nằm trong một định nghĩaDOCTYPE, có cấu trúc cú pháp như sau:

<!DOCTYPE root-element [element-declarations]>

DOCTYPE được sử dụng để khai báo phần tử gốc của XML Trong DTD, một phần tử của XML được khai báo bằng một định nghĩa có cú pháp:

<!ELEMENT element-name category>

hoặc

<!ELEMENT element-name (element-content)>

Ví dụ định nghĩa kiểu dữ liệu DTD đƣợc thêm vào đầu file XML:

<!ELEMENT title (#PCDATA)>

<!ELEMENT publisher_list (publisher*)>

<! publisher children >

<!ELEMENT publisher (name, email?, homepage?,

address?, voice?, fax?)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT email (#PCDATA)>

<!ELEMENT homepage (#PCDATA)>

<!ELEMENT address (#PCDATA)>

<!ELEMENT voice (#PCDATA)>

<!ELEMENT fax (#PCDATA)>

Tuy nhiên, DTD còn có nhiều giới hạn, thí dụ như không định nghĩa chính xác được các kiểu dữ liệu (data type) Do đó, Microsoft đề xướng sơ đồ XML (XML Schemas) với những ưu điểm sau:

- Dễ học và dùng hơn DTD, chính sơ đồ cũng là một trang thuộc loại XML

- Nó cho phép định nghĩa chính xác các kiểu dữ liệu (data type)

- Dùng lại được các phần tửbằng cách thừa kế (inheritance)

- Linh động, dễ thêm bớt các phần tử của sơ đồ

Mọi sơ đồ XML đều có phần tử gốc là <Schema>, phần tử này có thể bao gồm một số thuộc tính và được khai báo như sau:

<xs:element name="xxx" type="yyy"/>

trong đó ―yyy‖ là kiểu dữ liệu của phần tử Sơ đồ XML có một số kiểu dữ liệu xây dựng sẵn bao gồm: xs:string, xs:decimal, xs:integer, xs:boolean, xs:date, xs:time Phần tử phức tạp là phần tử chứa các phần tử khác hay các thuộc tính Phần tử phức tạp có thể là phần tử rỗng:

<element type="publisher_list" minOccurs="1"

Tài liệu ở dạng sơ đồ này được lưu dưới dạng file XML,và được đính kèm vào trang XML của tài liệu bằng cặp thẻ:

Thuộc tính của không gian tên XML (xmlns) được đặt tại thẻ đầu tiên của mỗi phần tử và có cấu trúc như sau:

xmlns:namespace-prefix="namespaceURI"

trong đó ―namespaceURI‖ là một chuỗi ký tự dùng để xác định một tài nguyên trên Internet Dạng thường thấy nhất của URI là URL (Uniform Resource Locator) dùng để xác định một địa chỉ tên miền Internet

Ví dụ: Có một tài liệu XML như sau:

Để tránh sự nhầm lẫn này, ta có thể dùng không gian tên để nói rõ tên phần tử con nào nằm trong phần tử cha nào Ví dụ trên được viết lại như sau:

</BookOrder>

2.1.6 Tên viết tắt (Qualified Names - QNames)

Trong tài liệu XML ta đã sử dụng khái niệm không gian tên để phân biệt giữa các phần tử giống nhau trong cùng một tài liệu Tuy nhiên, vấn đề đặt ra là nếu như trong tài liệu có nhiều các phần tử cần phân biệt, nếu vậy sẽ phải bổ sung không gian tên cho tất cả các phần tử đó trong tài liệu Một cách giải quyết là khai báo chữ viết tắt cho các không gian tên ngay ở đầu tài liệu, trong phần tử gốc (tức là Document Element) Sau

đó bên trong tài liệu ta chỉ cần bổ sung tiền tố (prefix) cho các phần tử cần xác nhận không gian tên bằng chữ viết tắt của không gian tên đó Thành phần đó được gọi là

―Tên viết tắt‖ (QName)

Một QName bao gồm một tiếp đầu ngữ mà trước đó đã được gán giá trị bằng một URI, tiếptheo là dấu ‗:‘ và tên cục bộ

Giả sử, nếu một QName có tiếp đầu ngữ là ‗foo‘được gán cho một URI là

―http://example.org/somewhere/‖ thì QName có dạng foo:barlà cách viết tắt của địa chỉ URI: http://example.org/somewhere/bar

Trong đoạn mã ở trên, trình phân tích sẽ bỏ qua nội dung nằm trong

―<![CDATA[― và ― ]]>‖ Do đó, nội dung đó không cần phải tuân thủ theo các quy định của một tài liệu XML chuẩn Nó cho phép ta có thể chèn các đoạn mã lệnh vào trong tài liệu XML

2.1.8 Trình diễn dữ liệu XML trên web

Ban đầu người ta dùng CSS (Cascading Style Sheet), một định dạng rất thông dụng cho các trang Web, để làm phương tiện mô tả cách trình bày một trang XML Nhưng sau đó ngôn ngữ bảng kiểu mở rộng(XSL -eXtensible Stylesheet Language) đã được sử dụng.Nó chứng tỏ là một ngôn ngữ trình bày rất mạnh mẽ và uyển chuyển.XSL được viết dưới dạng một trang XML Nó cũng là một ngôn ngữ lập trình nên chẳng những cho phép biến đổi định dạng (Style) hiển thị của dữ liệu trang XML

mà còn có thể quyết định dữ liệu nào được hiển thị và hiển thị theo thứ tự nào

Phát triển ứng dụng Web với kỹ thuật tiêu bản XSL (template XSL) giúp tách biệt nội dung trang Web và hình thức thể hiện.Nhờ đó việc thiết kế Web trở nên dễ

dàng, linh động hơn, hiệu suất ứng dụng Web cũng được nâng cao hơn

Trong hình 2.1, ta có thể thấy mô hình sử dụng và biểu diễn dữ liệu XML diễn

ra như sau: Khi người dùng kích hoạt một chức năng trên ứng dụng Web, phần xử lý tương ứng với chức năng này sẽ trả lại kết quả dưới dạng XML cho ứng dụng Web, kết quả này cùng với mẫu XSL tương ứng sẽ được biên dịch để trở thành giao diện hiển thị cuối cùng và gửi trả lại máy người dùng

Người

dùng

Trả lại Kết quả

hiển thị

Tương tác

Ứng dụng Web

Chuyển yêu cầu đến

Bộ điều khiển

Tạo ra

Dữ liệu dạng XML

Bao gồm

Áp dụng

dữ liệu XML cho

SOAP ban đầu được Microsoft cài đặt bằng cách gọi thủ tục từ xa (RPC – Remote Procedure Call) qua giao thức HTTP.Nó cho phép các ứng dụng client có thể

dễ dàng kết nối tới các dịch vụ từ xa và gọi đến phương thức tương ứng Các giao thức khác như CORBA, DCOM, và Java RMI đều cung cấp các tính năng tương tự như SOAP, tuy nhiên do các thông điệp SOAP được viết hoàn toàn bằng XML nên nó độc lập với mọi nền và mọi ngôn ngữ Ví dụ một ứng dụng SOAP Java client chạy trên

Linux hay Perl client chạy trên Solaris đều có thể kết nối tới một Microsoft SOAP server chạy trên Windows 2000 Sau đó, các công ty khác, trong đó có IBM đã xây dựng chuẩn SOAP 1.1 và gửi lên tổ chức W3C để phê chuẩn Các đóng góp của các công ty này đã cho SOAP khả năng truyền nhận thông tin bằng các giao thức khác không chỉ là HTTP, và các kiểu truyền gửi thông điệp khác không chỉ là RPC Đơn vị trao đổi thông tin cơ bản của SOAP là một thông điệp SOAP đƣợc viết theo định dạng tài liệu XML Các thông điệp SOAP ngoài HTTP còn có thể truyền nhận qua email sử dụng giao thức SMTP (Simple Mail Transfer Protocol) và các giao thức mạng khác nhƣ FTP (File Transfer Protocol) và raw TCP/IP (Transmission Control Protocol/Internet Protocol) [5]

Hình 2.2: SOAP với các giao thức HTTP, SMTP, và Raw TCP/IP

SOAP không đƣợc thiết kế chuyên biệt cho bất kỳ một ngôn ngữ lập trình, một sản phẩm hay là một hạ tầng phần cứng nào Vì vậy, SOAP có thể đƣợc sử dụng trong các ứng dụng phát triển trên nhiều nền tảng khác nhau (C++, Java, NET, …) SOAP đƣợc thiết kế đặc biệt để chứa và chuyển những tài liệu XML trên mạng Internet (Intranet)

2.2.2 Cấu trúc một thông điệp (Message) theo dạng SOAP [11]

Thông điệp dạng SOAP là một văn bản XML bao gồm các phần tử sau:

- Phần bao gói (Envelope): bao trùm nội dung thông điệp, khai báo văn bản

XML nhƣ là một thông điệp SOAP

- Phần tử đầu trang (Header): chứa các thông tin tiêu đề cho trang Phần tử này

không bắt buộc khai báo trong văn bản Đầu mục còn có thể mang những dữ

liê ̣u xác thực, chữ ký số hóa, và thông tin mã hóa, hoă ̣c những cài đặt cho giao thức

- Phần tử khai báo nội dung chính trong thông điệp (Body): chứa các thông tin

yêu cầu (từ máy khách) hay phản hồi (từ máy dịch vụ)

- Phần tử lỗi phát sinh (Fault): cung cấp thông tin về các lỗi xảy ra trong quá

trình xử lý thông điệp

Hình 2.3: Cấu trúc của thông điệp SOAP

2.2.2.1 Phần bao gói (Envelope)

Mỗi thông điệp SOAP có một phần tử gốc Envelope Không giống như các đặc

tả khác như HTTP và XML, SOAP không có phần định nghĩa vềcác phiên bản (vd: HTTP 1.0 hay HTTP 1.1), thay vào đó thì SOAP sử dụng không gian tên XML (XML namespace) để phân biệt các phiên bản (version) khác nhau

Không gian tên XML đóng vai trò quan trọng trong các thông điệp SOAP Một thông điệp SOAP có thể gồm nhiều phần tử XML trong các phần tử Header và Body,

vì vậy để tránh xung đột, các phần tử này cần phải được phân biệt bằng một không gian tên duy nhất Ví dụ trong thông điệp SOAP dưới đây chứa phần tử purchaseOrder, message-id và vì vậy trong khối header sẽ bao gồm ít nhất là 4 không gian tên được tô đậm trong hình dưới đây

Trong cáckhông gian tên đƣợc mô tả ở trên, không gian tên đầu tiên, đƣợc mô

tả trong phần tử Envelope định nghĩa không gian tên của các phần tử SOAP – Envelope, Header và Body

Ở ví dụ trên trong phần tử Body lại định nghĩa 2 không gian tên khác, đặc tả không gian tên đầu tiên thuộc về Purchase Order Markup Language đƣợc định nghĩa trong Monson-Haefel Books

Đặc tả SOAP định nghĩa các qui tắc xử lý các khối header trong một message path Message path có chức năng định tuyến cách mà một thông điệp SOAP đƣợc

chuyển từ bên gửi tới bên nhận Giao thức SOAP định nghĩa một message path là một danh sách các nút dịch vụ SOAP Mỗi phần tử trong message path thực hiện một tiến

trình xử lý và sau đó chuyển thông điệp tới nút tiếp theo để xử lý

Đặc tả SOAP và web service sử dụng nhiều thuật ngữ đặc biệt, bởi không nhƣ các giao thức khác, SOAP có thể sử dụng cho rất nhiều hệ thống truyền thông điệp các nhau (đồng bộ, không đồng bộ, RPC, one-way, ) Để có thể mô tả tất cả các đối tƣợng tham gia vào quá trình truyền thông điệp SOAP, ta dùng các thuật ngữ đặc biệt để tránh nhầm với các thuật ngữ khác, ví dụ nhƣ là ―client‖, ―server‖

SOAP là một giao thức sử dụng để trao đổi các thông điệp giữa các ứng dụng SOAP trên mạng intranet hoặc internet Một ứng dụng SOAP đơn giản chỉ là một phần mềm có thể tạo hoặc xử lý các thông điệp SOAP Ứng dụng gửi thông điệp SOAP đƣợc gọi là bên gửi, ứng dụng nhận gọi là bên nhận Tất cả các thông điệp SOAP đƣợc khởi tạo bởi bên gửi (initial sender), và đƣợc nhận bởi bên nhận (ultimate receiver) Vì vậy ta có thể coi bên gửi (initial sender) là phía client và bên nhận (ultimate receiver)

là web service

Hình 2.4: SOAP message path

Khi thông điệp SOAP đƣợc truyền qua message path, các khối header sẽ đƣợc biên dịch (intercept) và đƣợc xử lý bởi một số SOAP intermediaries (SOAP trung gian) Một SOAP Intermediary vừa là bên gửi vừa là bên nhận Nó sẽ nhận thông điệp SOAP, xử lý một hay nhiều khối Header, sau đó gửi nó đến các ứng dụng SOAP khác Các ứng dụng trong một message path còn đƣợc gọi là các SOAP node

Chúng ta hãy xem xét ví dụ sau đây để hiểu rõ cách thức các node trong một message path xử lý các khối Header Trong ví dụ sau chúng ta sử dụng 2 khối Header: message_id và processed_by Thông điệp SOAP trong ví dụ này sẽ được chuyển qua một số intermediary để xử lý trước khi đến được bên nhận Hình dưới đây minh họa message path của thông điệp SOAP được tạo bởi một khách hàng và sau đó được xử lý bởi nhân viên bán hàng, nhân viên kế toán, inventory và hệ thống phân phối

Hình 2.5: Message path của thông điệp SOAP purchase-Order

Các intermediary sẽ không chỉnh sửa nội dung trong phần SOAP body mà sẽ thao tác với các SOAP header Dưới đây là đoạn thông điệp có chứa khối header processed_by

thuộc tính là actor để nhận biết các khối header mà các SOAP node cần xử lý, ngoài ra

nó còn sử dụng thuộc tính mustUnderstand để chỉ ra liệu một node có bắt buộc/không

bắt buộc phải xử lý đoạn thông điệp đến hay không

nhiều vai trò (role) khác nhau Ví dụ, với node Sale (hình dưới) có thể bao gồm các module: module ghi log, module thực hiện việc xác thực bảo mật, module transaction

Thuộc tính actor được sử dụng kết hợp với XML namespace để xác định code module nào sẽ xử lý khối header nào Đầu tiên, node tiếp nhận thông điệp sẽ xác định vai trò (role) của nó được gán trong thuộc tính actor, sau đó nó sẽ chọn code module phù hợp để xử lý khối header, dựa trên XML namespace của khối header đó Ví dụ, thuộc tính actor chỉ ra vai trò ghi log với URL là "http://www.Monson-Haefel.com/logger" Một node thực hiện vai trò ghi log sẽ tìm kiếm các khối header nào mà có thuộc tính actor chứ URL trên Trong ví dụ dưới đây ta thấy khối header message-id trong thông điệp SOAP purchase-order chưa thuộc tính actor kể trên

Ngoài vai trò ghi log (role log), SOAP còn định nghĩa 2 vai trò khác là next và ultimate receiver Vai trò next chỉ ra node tiếp theo trong message path cần phải xử lý

khối header Vai trò next đƣợc gán với một URI đƣợc đặt là