Nghiên cứu về kiến trúc hướng dịch vụ và webservice

Hình 1.2 - Mô hình tương tác của các đối tượng DCOM Các kiến trúc trên đều hướng đến việc xây dựng một hệ thống “hướng dịch vụ” tuy nhiên chúng vẫn còn gặp phải một số vấn đề: • Đầu tiên

MỤC LỤC

LỜI MỞ ĐẦU 3

Chương 1 TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ 4

1.1 Thực trạng hiện tại 4

1.2 Phân tích, đánh giá một số mô hình kiến trúc phân tán hiện tại 5

1.2 Các vấn đề phát sinh, nguyên nhân và biện pháp khắc phục 9

Chương 2 KIẾN TRÚC HƯỚNG DỊCH VỤ (SOA) VÀ WEBSERVICE 11

2.1 Kiến trúc hướng dịch vụ (SOA) 11

2.1.1 Khái niệm về kiến trúc hướng dịch vụ 11

2.1.2 Các tính chất của một hệ thống SOA 12

2.1.3 Lợi ích của SOA 17

2.1.4 Quy trình xây dựng hệ thống SOA 20

2.2 Dịch vụ web (web service) 25

2.2.1 Khái niệm về dịch vụ web 25

2.2.2 Đặc điểm của dịch vụ web 27

2.2.3 Ưu và nhược điểm 28

2.2.4 Kiến trúc web service 29

2.2.5 Các thành phần trong web service 30

2.2.6 An toàn cho dịch vụ Web 39

2.3 Xây dựng Web Services 40

2.3.1 Các giai đoạn xây dựng Web services 40

3.1.2 Các thành phần của GIS 48

3.1.3 Thành phần dữ liệu GIS 49

3.2 Các chuẩn mở OpenGIS 53

3.2.1 Web Map Service 54

3.2.2 Web Feature Service 55

3.3 Bài toán ứng dụng 58

3.3.1 Phân tích 60

3.3.2 Xây dựng hệ thống thông tin trên Web với mã nguồn mở 60

3.3.3 Các vấn đề liên quan đến bài toán và phương hướng giải quyết 62

3.3.4 Sơ đồ kiến trúc chi tiết áp dụng 65

3.3.5 Thiết kế 65

KẾT LUẬN 82

TÀI LIỆU THAM KHẢO 84

PHỤ LỤC 86

LỜI MỞ ĐẦU

Ngày nay, nhu cầu phát triển và mở rộng phần mềm ngày càng đòi hỏi cao hơn, nhanh hơn và chuyên nghiệp hơn Người sử dụng phần mềm không chỉ là những người dùng bình thường mà còn là những nhà xây dựng, phát triển phần mềm khác Người phát triển phần mềm không còn xây dựng phần mềm của mình từ chỗ không

có gì, họ sẽ sử dụng lại các phần mềm của những nhà phát triển khác Từ đó, nhu cầu đóng gói, trao đổi và mua bán các gói phần mềm ngày càng tăng cao Vào thời đại ngày nay, với sự phát triển của Interrnet cùng với công nghệ khác kèm theo, việc trao đổi, mua bán các gói phần mềm và thực thi chúng ngày càng thuận lợi và nhanh chóng hơn Từ đó, dẫn đến sự ra đời của nhiều giải pháp phát triển phần mềm khác nhau, chẳng hạn như DCOM, CORRBA, RMI, … Nhưng trong đó, nổi bật và có nhiều ưu điểm là giải pháp phát triển phần mềm dự trên kiến trúc hướng dịch vụ

(SOA – Service Oriented Architecture) và triển khai trên cơ chế Web Service

Việc áp dụng giải pháp dịch vụ Web cho ứng dụng GIS (Geographical

Information Systems) đang được triển khai ngày càng rộng rãi Do đó hoàn toàn giải

quyết được các yêu cầu đặt ra bởi các ứng dụng cho GIS

Chính vì vậy, việc tiến hành nghiên cứu kỹ thuật lập trình Web Service để triển khai cho hệ thống hướng dịch vụ là một hướng nghiên cứu mang tính chiến lược cho

sự phát triển các ứng dụng tương lai Nên em tìm hiểu đề tài “Nghiên cứu về kiến

trúc hướng dịch vụ và webservice” cho đồ án tốt nghiệp, bao gồm 3 chương Chương 1 Tổng quan về kiến trúc hướng dịch vụ

Chương 1 TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ 1.1 Thực trạng hiện tại

Ngày nay, phần mềm đang ngày càng trở nên phức tạp quá mức và dường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển hiện có Đây cũng chính là vấn đề đặt ra hiện nay trong lĩnh vực phát triển phần mềm Một thực trạng đáng buồn là có rất nhiều hệ thống phần mềm được xây dựng với kiến trúc quá phức tạp, chi phí phát triển và bảo trì cao, đặc biệt là với hệ thống phần mềm cao cấp Hàng chục năm qua, các kiến trúc phần mềm đã cố gắng giải quyết vấn đề này Thế nhưng độ phức tạp vẫn tiếp tục tăng và dường như vấn đề này đã vượt qua khả năng

xử lý của các kiến trúc thông thường Nguyên nhân khiến cho hệ thống có độ phức tạp tăng cao là do sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất, trong khi nhu cầu trao đổi, chia sẻ, tương tác giữa các hệ thống không thể đáp ứng được trong môi trường như vậy Và làm sao có thể dung hòa được những sự khác biệt giữa các hệ thống mới và hệ thống cũ Các hệ thống cũ cần được sử dụng lại thay vì phải gỡ bỏ và thay mới bởi vì chi phí thực hiện lại từ đầu chắc chắn sẽ cao hơn việc chi phí chuyển đổi cái cũ rất nhiều lần Vấn đề này liên quan đến một

khái niệm và cũng là một thách thức mà các tổ chức phải đối mặt, đó là vấn đề “tích hợp hệ thống” (Enterprise Architecture Integration - EAI) Hiện nay vấn đề này

đang được rất nhiều tổ chức, doanh nghiệp quan tâm đến, với mức chi phí đầu tư lớn như IBM, Microsoft, …

Một nguyên nhân khác cũng dẫn đến tình trạng khó khăn như thế là vấn đề lập trình dư thừa và không thể tái sử dụng Chẳng hạn nếu một ngân hàng có nhiều chi nhánh khác nhau, mỗi chi nhánh có một hệ thống tách biệt và cần kết nối với các hệ thống khác của ngân hàng để phục vụ khách hàng được hiệu quả hơn Giả sử các hệ thống này được thiết kế rất tốt Thế nhưng các hệ thống này được xây dựng trong những thời gian khác nhau, trong những dự án độc lập và khác nhau Vấn đề lấy dữ

hệ thống lưu trữ tài khoản, và ngay cả khi người dùng truy cập vào cùng một tài khoản trong một cơ sở dữ liệu Bây giờ ngân hàng đó cần phát triển một hệ thống cung cấp dịch vụ gửi tiền hay cho vay tiền để năng cao chất lượng phục vụ khách hàng Thì hệ thống mới này được xây dựng như thế nào? Nếu giải pháp là xây dựng

hệ thống mới, thì gặp phải vấn đề lớn: dư thừa, không đồng nhất, tốn kém, … Còn nếu chọn giải pháp là sử dụng lại các chức năng sẵn có, thì phải đối mặt với những chuyện thiết lập các mối liên kết với toàn bộ các hệ thống trước

Hầu như mọi tổ chức, doanh nghiệp phải đối mặt với vấn đề tích hợp với nhiều

lý do, đặc biệt là trong thị trường ngày nay, sự thay đổi luôn diễn ra với tốc độ chóng mặt Có thể là mở rộng thêm chi nhánh, một hệ thống bán hàng mới, hoặc chỉ đơn giản là kết nối các hệ thống sẵn có Những vấn đề trước chưa giải quyết mà nay phải đối mặt với những thách thức mới: đáp ứng nhanh chóng các sự thay đổi, giảm chi phí phát triển, tăng khả năng tương thích, và tái sử dụng, … Tất cả đã tạo nên một áp lực nặng nề đối với các nhà phát triển phần mềm

1.2 Phân tích, đánh giá một số mô hình kiến trúc phân tán hiện tại

Một số kiến trúc phân tán phổ biến nhất hiện này là CORBA, RMI, DCOM Các kiến trúc này là sự mở rộng của các hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng

► RMI (Remote Method Invocation):

RMI là một phần của bộ J2SDK (Java 2 Platform Standard Development Kit )

là các hàm thư viện hỗ trợ cho các lời triệu 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 RMI cho phép chạy các đối tượng trên môi

trường JVM (Java Virtual Machine) triệu gọi với đối trượng chạy trên nền JVM

truyền tham số từ đối tượng gọi đến phương thức được gọi, ngoài ra nó cũng trả về các giá trị cho đối tượng thực thi phương thức

Trong một ứng dụng phân tán, mặc dù đoạn mã lập trình phương thức trông có

vẻ giống như trong trường hợp ứng dụng không phân tán, nhưng là một cơ chế hoàn toàn khác nhau được dùng để móc nối những đối tượng này Khi một đối tượng muốn triệu gọi một phương thức, nó sẽ gọi một đối tượng bè bạn bên phía máy khách, đối tượng này sẽ đại diện cho đối tượng gọi phương thức bên ngoài phía máy

chủ Đối tượng này được gọi là stub

Stub sẽ gọi kiến trúc RMI bên phía máy khách và di chuyển dữ liệu qua mạng đến kiến trúc RMI trên máy chủ, đến lượt nó sẽ gọi thực thi một đối tượng bè bạn

phía máy chủ gọi là skeleton

Hình 1.1 - Mô hình RMI Đối tượng skelenton sẽ gọi phương thức của đối tượng thật sự bên phía máy chủ Đến khi trả lại kết quả thì một cơ chế giống hệt như trên sẽ triệu gọi thực thi theo chiều ngược lại, khi đó kết quả trả về sẽ được truyền cho đối tượng skelenton trên phía máy chủ, và đối tượng này truyền theo kiểu đường mạng sử dụng kiến trúc RMI, tiếp đến nó sẽ triệu gọi đối tượng stub bên phía máy khách, và trả về giá trị cho đối tượng gọi phương thức

Vậy, ưu điểm của kiến trúc đối tượng phân tán RMI là người lập trình chỉ cần lập trình các lời gọi phương thức vì đối tượng được gọi đã hiện diện trong máy ảo của nó Nhưng nhược điểm là RMI chỉ thích hợp cho các ứng dụng viết trên ngôn ngữ Java

CORBA Là một chuẩn công nghiệp được đưa ra bởi OMG (Object Management Group), nó 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 ngôn ngữ lập trình khác nhau

CORBA được định nghĩa từ 2 phần:

 Thực thể mà cho phép liên lạc giữa 2 tiến trình được gọi là 1 mô giới yêu cầu

đối tượng (Object Request Broker - ORB)

 Một giao thức được ORB dùng để liên lạc giữa nhiều tiến trình, được gọi là

IIOP (Internet Interoperability Protocol)

Nền của Java chứa một CORBA ORB CORBA dung kỹ thuật stub/skelenton như RMI, nhưng không giống như RMI, CORBA phát sinh stub và skelenton từ nột

mô tả giao diện độc lập với ngôn ngữ được gọi là ngôn ngữ mô tả giao diện

(Interface Definition Language - IDL) thay vì mã nguồn của ngôn ngữ IDL xác định

tên phương thức, cũng như tham số gọi và trả về theo kiểu ngôn ngữ trung lập

Ưu điểm của CORBA là các lập trình viên có thể chọn bất kỳ ngôn ngữ, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn thoả các tính chất của CORBA Tuy nhiên CORBA có một số nhược điểm là nó là ngôn ngữ lập trình cấp thấp, rất phức tạp, khó học và cần một đội ngũ phát triển có kinh nghiệm Ngoài ra các đối tượng CORBA cũng khó có thể tái sử dụng

► DCOM – Distributed Component Object Model:

DCOM là một mô hình phân tán dễ triển khai với chi phí thấp, hỗ trợ tigh coupling giữa các ứng dụng và hệ điều hành Mô hình Component Object Model (COM) định nghĩa cách thức các các thành phần và client liên lạc trao đổi với nhau

DCOM mang đến nhiều ưu điểm như tính ổn định, không phụ thuộc vị trí địa

lý, quản lý kết nối hiệu quả và dễ dàng mở rộng, là một lựa chọn tốt cho các doanh nghiệp sử dụng công nghệ của Windows để chạy các ứng dụng có yêu cầu cao về sự chính xác và ổn định Tuy nhiên, các công nghệ của Microsoft có một nhược điểm lớn là chúng bị giới hạn trên nền tảng Windows

Hình 1.2 - Mô hình tương tác của các đối tượng DCOM Các kiến trúc trên đều hướng đến việc xây dựng một hệ thống “hướng dịch vụ” tuy nhiên chúng vẫn còn gặp phải một số vấn đề:

• Đầu tiên là kiến trúc triển khai cài đặt bên phía nhà cung cấp dịch vụ và phía sử dụng dịch vụ phải giống nhau Điều này đồng nghĩa với khó khăn mỗi khi có sự thay đổi từ một trong 2 phía bởi vì mỗi thay đổi cần được đánh giá, lên kế hoạch

và sửa chữa ở cả 2 phía

• Tiếp đến những chuẩn trên đa phần là chuẩn đóng, chúng hầu như không thể kết

hợp, hoạt động với chuẩn khác Ví dụ như bắt đối tượng Java trao đổi dữ liệu trực tiếp với một đối tượng DCOM là không thể Lượng thông tin giữa trong mỗi lần

thực hiện giao dịch là ít, và được thực hiện nhiều lần dẫn đến chiếm dụng băng thông sử dụng và tăng thời lượng đáp trả dữ liệu

1.2 Các vấn đề phát sinh, nguyên nhân và biện pháp khắc phục

Ngày nay áp lực đặt lên các doanh nghiệp ngày càng lớn: giảm chi phí đầu tư

cơ sở hạ tầng, khai thác có hiệu quả các công nghệ có sẵn, phải cố gắng phục vụ yêu

cầu của khách hàng ngày càng tốt hơn, đáp ứng tốt các thay đổi nghiệp vụ, khả năng

tích hợp cao với các hệ thống bên ngoài… Nguyên nhân chính của mọi khó khăn

trên đó là: sự không đồng nhất và sự thay đổi

Hầu hết các doanh nghiệp ngày nay đều sở hữu nhiều hệ thống, ứng dụng, với

những kiến trúc khác nhau, xây dựng vào những khoảng thời gian khác nhau và dựa

trên những công nghệ khác nhau Vào những năm 1990, các doanh nghiệp chọn giải

pháp trọn gói, mua hẳn một vài gói phần mềm lớn với những module được tích hợp

sẵn thay vì cố gắng “sửa và kết hợp” chúng với nhau, bởi vì lúc bấy giờ kết hợp các

sản phẩm từ nhiều nhà cung cấp khác nhau thực sự là một cơn ác mộng Ngày nay,

các doanh nghiệp không thể chi trả như vậy, vì một giải pháp trọn gói thường không

linh hoạt và có giá thành cao Các doanh nghiệp quay lại tìm kiếm những giải pháp

kết hợp những ứng dụng cũ sao cho thoả mãn nhu cầu, Trong quá trình kết hợp chắc

 Quá nhiều định dạng dữ liệu

 Yêu cầu khách hàng thường xuyên thay đổi

nhiều lĩnh vực khác nhau để phát triển, triển khai và quản lý các ứng dụng và hệ thống mà bản thân chúng không thống nhất với nhau Thêm vào đó là việc nâng cấp phức tạp, tích hợp cùng với nhu cầu về bảo mật ngày một tăng

 Không linh hoạt: Cùng với sự phức tạp là tính cứng nhắc trong chính sách,

chiến lược phát triển, cũng như là cơ sở hạ tầng của các công ty Hầu như công ty nào cũng có những ứng dụng có sẵn mà khó nâng cấp, khó kết hợp hoạt động hoặc

tệ hơn, không thể thay thế Vấn đề tích hợp vì thế trở nên tốn kém và khó khăn hơn

 Không bền vững: trái ngược với sự cứng nhắc nói trên là sự không bền

vững đi cùng với khả năng thất bại và những vấn đề khác đi kèm Các phương pháp tiếp cận truyền thống trong việc xây dựng các hệ thống phần mềm thường dẫn đến một “mớ hỗn độn” các giải pháp lắp ghép, tích hợp Kết quả là mỗi khi có thay đổi

về quy trình nghiệp vụ hoặc yêu cầu thì các công ty phải chấp nhận phát triển những

dự án nâng cấp tốn kém hoặc là hủy và thay thế hẳn công nghệ không phù hợp Rủi

ro cùng lúc cũng tăng lên với sự phụ thuộc chồng chéo giữa các thành phần, hệ thống có sẵn

Chính vì vậy các doanh nghiệp cần một cách tiếp cận mới để giải quyết vấn đề môi trường không đồng nhất và tốc độ chóng mặt của sự thay đổi trong khi phải xoay sở với nguồn ngân sách hạn hẹp và nền kinh tế khó khăn Cách tiếp cận đó gọi

là “kiến trúc hướng dịch vụ” Service oriented Architecture (SOA)

Chương 2 KIẾN TRÚC HƯỚNG DỊCH VỤ (SOA) VÀ

WEBSERVICE 2.1 Kiến trúc hướng dịch vụ (SOA)

2.1.1 Khái niệm về kiến trúc hướng dịch vụ

Kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA) là một hướng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng

module, trong đó mỗi module đóng vai trò là một “dịch vụ” (service) tự hoạt động

và liên kết lỏng lẻo, và có khả năng truy cập thông qua môi trường mạng Hiểu một cách đơn giản thì một hệ thống SOA là một tập hợp các dịch vụ được chuẩn hóa trên mạng trao đổi với nhau trong một ngữ cảnh tiến trình nghiệp vụ Một giải pháp SOA bao gồm một tập các dịch vụ nghiệp vụ mà thực hiện một quy trình nghiệp vụ

SOA là một kiểu kiến trúc có khả năng mở rộng, bao gồm các service có khả năng tương tác, khả năng khám phá, tự trị, có thể phục vụ cho nhiều khách hàng khác nhau, và có khả năng sử dụng lại

 Một Architecture: Là một mô tả có tính hình thức của hệ thống, xác định

mục đích, chức năng, thuộc tính, giao diện, … của hệ thống Nó cũng bao gồm việc

mô tả những thành phần bên trong hệ thống và mối quan hệ giữa chúng, cùng với nguyên tắc thiết kế, hoạt động, và sự phát triển của hệ thống

 Một Service: Là một thành phần phần mềm mà nó có thể được truy nhập qua

mạng để cung cấp chức năng tới người có yêu cầu dịch vụ

 Thuật ngữ “Service Oriented Architecture” ám chỉ kiểu kiến trúc xây dựng

những hệ thống phân tán (distributed systems) mà các chức năng như là các dịch vụ,

Trong SOA có 3 đối tượng chính:

Hình 2.1 - Kiến trúc hướng dịch vụ - SOA

Nhà cung cấp dịch vụ (service provider) cần cung cấp thông tin về dịch vụ của mình cho một dịch vụ lưu trữ thông tin dịch vụ (service registry) Người yêu cầu dịch vụ hay khách hàng (service requestor / consumer) thông qua service registry

để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp

SOA cung cấp giải pháp để giả quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định Một hệ thống triển khai theo

mô hình SOA có khả năng dễ mở rộng, liên kết tốt Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có

2.1.2 Các tính chất của một hệ thống SOA

 Loose coupling:

Vấn đề kết nối (coupling) ám chỉ một số ràng buộc giữa các module lại với nhau Có 2 loại coupling là rời (loose) và chặt (tight) Các module có tính chất loose coupling có một số ràng buộc được mô tả rõ ràng trong khi các module có tính tight coupling lại có nhiều ràng buộc không thể biết trước Hầu như mọi kiến trúc phần mềm đều hướng đến tính loose coupling giữa các module Mức độ kết dính của hệ

thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống Kết dính càng chặt bao nhiêu thì có nhiều thay đổi chỉnh sửa khi có sự thay đổi nào đó xảy ra Mức độ coupling tăng dần khi bên sử dụng dịch vụ càng cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ càng chặt Ngược lại, nếu bên sử dụng dịch vụ không cần biết mọi thông tin

chi tiết của dịch vụ trước khi triệu gọi nó thì quan hệ giữa 2 bên càng có tính loose coupling

Loose coupling làm cho sự phụ thuộc là nhỏ nhất Khi sụ phụ thuộc là nhỏ nhất thì sự thay đổi là có ảnh hưởng nhỏ nhất và hệ thống vẫn có thể chạy khi có thành phần nào đó bị hỏng Sự phụ thuộc là nhỏ nhất nó làm cho hệ thống linh hoạt, và lỗi xảy ra là ít

SOA hỗ trợ tính loose coupling thông qua việc sử dụng hợp đồng và ràng buộc (contract and binding) Một người sử dụng truy vấn đến nơi lưu trữ và cung cấp thông tin dịch vụ (service registry) để lấy thông tin về loại dịch vu cần sử dụng

Registry sẽ trả về tất cả các dịch vụ tìm kiếm Cho nên người dùng chỉ việc chọn dịch vụ mà mình cần tìm, và thực thi phương thức trên đó theo mô tả dịch vụ nhận được từ registry Bên sử dụng không cần phụ thuộc trực tiếp vào cài đặt của dịch vụ

đi Loose coupling đem đến sự độc lập giữa bên cung cấp và bên sử dụng nhưng nó đòi hỏi các giao diện phải theo chuần và cần một thành phần trung gian quản lý, trung chuyển yêu cầu giữa các hệ thống đầu cuối

 Sử dụng lại dịch vụ

Bởi vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơi nhất định nên chúng dễ ràng được tìm và tái sử dụng Nếu một dịch vụ không có khả năng tái sử dụng, nó cũng không cần đến interface mô tả Các dịch vụ có thể được tái sử dụng lại bằng cách kết hợp lại với nhau theo nhiều muc đích khác nhau Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần trùng lặp và tăng tốc độ vững chắc trong cài đặt, nó còn giúp đơn giản hóa việc quản trị Thực ra tái sử dụng dịch vụ lại dễ dàng hơn tái sử dụng thành tố hay lớp Những dịch vụ được dùng

chung bởi tất cả các ứng dụng của một hệ thống SOA gọi là những shared infrastructure service

 Sử dụng dịch vụ bất đồng bộ

Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận Bên nhận xử lý thông tin và trả về kết quả thông tin qua một kênh thông điệp, các yêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lý với tốc độ tối ưu Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về nên không bị ảnh hưởng bởi việc sử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ

 Quản lý các chính sách (policy)

Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các policy Các policy cần được quản lý các áp dụng cho mỗi dịch vụ cả khi thiết kế lẫn khi trong thời gian thực thi

Việc tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng, Bởi vì các policy được thiết kế tách biệt, và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm Nếu không sử dụng các policy, thì các nhân viên phát triển phần mềm, nhóm điều hành và nhóm hỗ trợ phải làm việc với nhau trong suốt thời gian phát triển để cài đặt và kiểm tra những policy Ngược lại, nếu sử dụng policy, những nhân viên phát triển phần mềm giờ chỉ cần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗ trợ tập trung vào các luật kết hợp

 Khả năng cộng tác

Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác, khả năng mà các

hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau Mỗi dịch vụ cung cấp một giao diện có thể được triệu gọi thông qua một dạng kết nối Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định dạng

dữ liệu mà mỗi client kết nối đến nó đều hiểu Khả năng cộng tác đạt được bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client Kỹ thuật này đạt được bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung gian Đặc tả trung gian này sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu

khả kết (interopersble) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống

 Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm truy tìm dịch vụ (service discovery) Một người sử dụng

cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần Người sử dụng chỉ cần hỏi một registry về một dịch vụ nào thỏa yêu cầu tím kiếm Ví dụ, một hệ thống chuyển khoản (consumer) yêu cầu một registry tìm tất cả

số cần thiết dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô tả cung cấp và gửi đi Nhà cung cấp dịch vụ sẽ thực thi kiểm tra thẻ tín dụng và trả về một thông điếp có định dạng đúng như trong phần mô tả dịch vụ Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry trung gian Mối ràng buộc này là ràng buộc trong thời gian chạy chứ không phải ràng buộc trong lúc biên dịch Tất cả thông tin cần thiết về dịch

vụ được lấy về và sử dụng trong khi chạy Vậy với SOA, bên sử dụng dịch vụ không cần biết định dạng của thông điệp yêu cầu và thông điệp trả về, cũng như địa chỉ dịch vụ cho đến khi cần

 Tự hồi phục

Với kích cỡ và độ phức tạp của những hệ thống phân tán ngày nay, khả năng phục hồi của một hệ thống phân sau khi bị lỗi trở thành một yếu tố quan trọng Một

hệ thống tự hồi phục (self-healing) là hệ thống có khả năng tự hồi phục sau khi lỗi

mà không cần sự can thiệp của con người

Độ tin cập (reliability) là mức độ đo khả năng của một hệ thống xử lý tốt hư

thế nào trong tình trạng hỗn loạn Trong SOA, các dịch vụ luôn có thể hay ngừng bất

cứ lúc nào, nhất là đối với những áp dụng tổng hợp từ những từ nhiều dịch vụ của nhiều tổ chức khác nhau Độ tin cậy phụ thuộc vào khả năng phục hồi của phần cứng sau khi bị lỗi Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy Một khía cạnh khác ảnh hưởng đến độ tin cậy

là kiến trúc mà dựa trên đó những ứng dụng được xây dựng Một kiến trúc hỗ trợ kết nối và thực thi động sẽ có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên

Ngoài ra, những hệ thống dựa trên dịch vụ yêu cầu tách biệt giữa giao diện và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một giao diện Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì Khả năng này chỉ có được khi

client tương tác với giao diện của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ Đây là một trong những tính chất cơ bản của hệ thống hướng dịch vụ (SOA)

2.1.3 Lợi ích của SOA

► Sử dụng lại những thành phần có sẵn

Như một công ty bán lẻ có thể có một nhóm phần mềm cho hệ thống phân phối, một nhóm phần mềm cho hệ thống lưu kho và một nhóm phần mềm cho những chức năng liên kết Thông thường những nhóm phần mềm này đựơc phát triển trên nhiều nền tảng khác nhau, sử dụng nhiều ngôn ngữ lập trình khác nhau và thường có nhiều tính năng lặp lại giữa chúng Một hệ thống SOA cho phép các công ty tránh tình trạng lặp dư thừa, tạo ra những đơn thể dịch vụ chia sẻ giữa các ứng dụng Thay

vì phải “thay đổi” , với SOA ta chỉ cần tạo ra các “cầu nối” liên hệ giữa những hệ

thống và ứng dụng khác nhau, thay vì chỉnh sửa hoặc xây dựng lại từ đầu Bởi vì có

đa phần các dịch vụ mới sử dụng lại những dịch vụ sẵn có nên chi phí phát triển các

thành phần mới được giảm đến mức tối thiểu Nghĩa là :

 Nhằm giảm tính dư thừa

 Các công ty có thể triển khai những tiến trình xử lý mới nhanh hơn rất nhiều

 Chi phí dành cho phát triển và kiểm thử giảm đáng kể

 Giảm rủi ro khi dịch vụ tạm ngưng hoạt động

 Rủi ro về lỗi phần mềm giảm đi và tăng chất lượng dịch vụ

 Tránh công việc trùng lặp là một trong những lợi ích mà SOA mang lại

thông tin (portal) giúp cho người dùng cuối chỉ cần truy cập một lần mà vẫn có thông tin về hàng loạt sản phẩm của doanh nghiệp Loại kết hợp này có thể khó khăn nếu không sử dụng SOA vì nó đòi hỏi việc tích hợp phức tạp, nỗ lực lập trình và kiểm thử Nhưng với SOA, một ứng dụng tổng hợp có thể được tổng hợp dễ dàng, bất kể sự khác nhau về địa lý hoặc công nghệ phát triển các dịch vụ đó Điều này cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí đến mức tối thiểu và tăng sức mạnh thoả mãn yêu cầu của người dùng cuối hiệu quả hơn

► Giúp khả năng linh hoạt và triển khai cài đặt

Lợi ích của SOA, trong đó phía triệu gọi dịch vụ không cần quan tâm đến địa chỉ hoặc công nghệ nền tảng của service Nó mang đến khả năng linh hoạt cao và nhiều lợi ích khác Trong một hệ thống SOA ta triệu gọi dịch vụ thông qua các interface theo một dạng thức chuẩn nên giúp lập trình viên tránh được việc phải lặp lại công việc tạo mới các service có khả năng hiểu tất cả những công nghệ được sử dụng bởi từng dịch vụ trong hệ thống

Với một hệ thống SOA, thật dễ dàng khi cung cấp một loạt những dịch vụ ra bên ngoài cho một đối tác nào đó sử dụng Nhờ tính độc lập địa chỉ và công nghệ của SOA, đối tác kia không cần quan tâm đến dịch vụ được cài đặt như thế nào, và nhờ các dịch vụ đã theo chuẩn giao tiếp nên đối tác đó chỉ cần một lượng thông tin nhỏ vừa đủ để sử dụng dịch vụ Tương tự cho điều ngược lại, nếu đối tác đã xây dựng một hệ thống SOA thì việc đem sử dụng chức năng một số dịch vụ của họ vào

sử dụng bên trong hệ thống của mình cũng trở nên dễ dàng và nhanh chóng Đặc tính này của SOA hứa hẹn tăng hiệu suất và tự động hoá Cuối cùng một lợi ích là tăng khả năng triển khai

► Thích ứng với những thay đổi trong tương lai

Các phương pháp tiếp cận truyền thống trong quy trình phát triển phần mềm có thể mô tả ngắn gọn là người dùng mô tả họ cần gì – công ty phát triển phần mềm –

tình huống thay đổi không định trước Với SOA, công ty phát triển phần mềm có thể

tạo nên những quy trình nghiệp vụ uyển chuyển, phức tạp biến đổi tùy “theo yêu cầu” và theo “thời gian thực“

► Hỗ trợ đa thiết bị và đa nền tảng

SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới Điều này cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau bao gồm cả những trình duyệt và thiết bị di động như pager, điện thoại di động, PDA và các thiết bị chuyên dụng khác sử dụng cùng một chức năng mà vẫn có thông tin trả về tùy theo dạng thiết bị Tính độc lập công nghệ này giúp cho các công ty tiết kiệm chi phí rất nhiều nhất là khi phải xử lý với vô số công nghệ hiện đang được sử dụng

► Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp

Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộng bằng cách thêm nhiều thể hiện (instance) của một service Công nghệ chia tải (load-balancing)

sẽ tự động tìm và định tuyến yêu cầu đến thể hiện service thích hợp Tương tự, SOA

có thể chuyển tiếp nội dung yêu cầu đến một thể hiện khác khi cần,nhờ đó tăng khả năng sẵn sàng phục vụ

Cần nhấn mạnh là lợi ích mà SOA mang lại không phải là ít mà là rất ấn tượng Thực tế giá trị kinh tế mà SOA mang lại lớn đến nỗi các tạp đoàn trên thế giới đang suy xét xem làm thế nào để chuyển toàn bộ các kiến trúc phần mềm có sẵn của họ thành SOA

2.1.4 Quy trình xây dựng hệ thống SOA

2.1.4.1 Các pha cơ bản trong chu trình vòng đời của hệ thống SOA

Chu trình vòng đời của hệ thống SOA:

Hình 2.2 – Các pha cơ bản trong chu trình vòng đời của SOA

● Pha phân tích hướng dịch vụ (Service-oriented analysis): Đây là giai đoạn

đầu để quyết định phạm vi của hệ thống SOA Tầng dịch vụ là được lược đồ hóa ra

(mapped out), và chia dịch vụ ra thành các mô hình, bao gồm hệ thống SOA sơ bộ

● Pha thiết kế hướng dịch vụ (service-oriented design): Là pha có sự kết hợp

chặt chẽ về sự thỏa hiệp của doanh nghiệp và nguyên lý hướng dịch vụ thành quy trình thiết kế dịch vụ Trong pha này, làm cho người thiết kế dịch vụ phải đương đầu với giải quyết vấn đề then chốt đó là thiết lập nên những ranh giới thông qua các dịch vụ Các tầng dịch vụ là được thiết kế trong giai đoạn này có thể bao gồm tầng orchestrantion, các kết quả của nó là trong sự xác định quy trình nghiệp vụ hình thức

● Pha phát triển dịch vụ (Service development): Trong pha này, là pha xây

dựng thực tế Ở đây vấn đề về nền tảng phát triển đi vào hoạt động, không quan tâm tới nó là loại dịch vụ nào Một cách cụ thể, là sự lựa chọn ngôn ngữ lập trình và môi

trường phát triển sẽ quyết định những mẫu dịch vụ và quy trình nghiệp vụ orchestrantion nào phù hợp với thiết kế

● Pha kiểm thử dịch vụ (Service testing): Để đưa ra những tiềm năng cho

việc dùng lại và bao gồm cả những trạng thái không biết trước được, các dịch vụ là được yêu cầu trải qua được sự nghiêm ngặt của việc kiểm thử trước khi được triển khai thành các sản phẩm

● Pha triển khai dịch vụ (Service deployment): Giai đoạn thực thi này đưa

đến việc cài đặt và cấu hình cho các thành phần phân tán, các giao diện dịch vụ, và

nhiều sản phẩm trung gian (middleware products) kết hợp với nhau thành những

server

● Pha quản trị dịch vụ (Service administration): Sau khi các dịch vụ được

triển khai, vấn đề quản lý các ứng dụng trở thàn hàng đầu, mối quan tâm cho hệ

thống phân tán, và các ứng dụng dựa trên các thành phần (component-based applications), ngoại trừ chúng là áp dụng cho các dịch vụ như một tổng thể

 Phương pháp top-down (The top-down strategy)

Trong xây dựng một hệ thống SOA, thì phương pháp top-down là phương pháp mà điểm xuất phát của nó sẽ là từ các yêu cầu ngiệp vụ để xác định các yêu

cầu chức năng, các tiến trình và tiến trình con, các trường hợp sử dụng (use cases)

để tới xác định các thành phần hệ thống (components), các dịch vụ, …

Trong phương pháp top-down hỗ trợ tạo ra các bước để hình thành tầng dịch

vụ (service layers) Phương pháp này phổ biến để đưa ra những kiến trúc dịch vụ có

chất lượng cao, trong quá trình tạo ra nhiều những nghiệp vụ được sử dụng lại và các dịch vụ ứng dụng

Hình 2.3 – Quy trình các bước của phương pháp top-down

 Bước 1: Define relevant ontology: Bước này là để xác định, phân loại các

tập thông tin được xử lý bởi các cơ cấu tổ chức của hệ thống Các kết quả này là các

từ vựng phổ biến, như sự định nghĩa mối quan hệ giữa các tập thông tin này với tập thông tin khác là như thế nào Các tổ chức có phạm vi rộng lớn hơn cùng với nhiều phạm vi nghiệp vụ có thể có vài ontology, với mỗi sự cai quản thì các nghiệp vụ chia ra một cách rõ ràng Nếu có nhiều từ vựng nghiệp vụ không tồn tại cho bất cứ các tập thông tin nào mà một giải pháp được yêu cầu thực hiện, thì bước này nó sẽ được định nghĩa Một số lượng đáng kể của tập các thông tin trước và kết quả phân

tích nghiệp vụ ở mức cao có thể là được yêu cầu

 Bước 2: Align relevant business models (including entity models): Sau khi

ontology là được thiết lập, sự tồn tại các mô hình nghiệp có thể cần để thay đổi (hay tạo ra) để thể hiện các từ vựng bằng cách cung cấp ontology trong các thuật ngữ mô hình nghiệp vụ Mô hình thực thể chi tiết là quan trọng

 Bước 3: Perform service-oriented analysis: Xác định các dịch vụ và hướng

tiếp cận cho các dịch vụ, đưa ra mô hình hóa dịch vụ

 Bước 4: Perform service-oriented design: Thực hiện thiết kế hướng dịch

vụ

 Bước 5: Develop services: Phát triển các dịch vụ theo yêu cầu Các dịch vụ

được phát triển theo những bản thiết kế kỹ thuật tương ứng và các đặc tả dịch vụ được tạo ra ở bước 4

 Bước 6: Test service operations: Giai đoạn kiểm thử được yêu cầu cho tất

cả các quá trình hoạt động của dịch vụ phải trải qua cần thiết đảm bảo chất lượng của quá trình kiểm tra Khi đó làm vượt qua số lượng kiểm thử yêu cầu cho logic tự động hóa thực thi vì các dịch vụ sử dụng lại sẽ cần thiết để được kiểm thử vượt ra ngoài phạm vi giải pháp

 Bước 7: Deploy service: Giải pháp cuối cùng là được triển khai Quan tâm

tới vấn đề thực thi, xác định tiềm năng tương lai sử dụng lại của dịch vụ Để thuận tiện cho nhiều người yêu cầu dịch vụ, thì các dịch vụ sử dụng lại có thể yêu cầu mở rộng sức mạnh xử lý và có thể có sự bảo mật và các khả năng yêu cầu truy cập là sẽ cần được cung cấp

 Phương pháp bottom-up (The bottom-up strategy)

Phương pháp này sẽ dựa trên việc phân tích tình trạng, các tài nguyên của hệ thống hiện có và sẽ tái sử dụng lại những thành phần này trong việc xây dựng các dịch vụ mới

Trong hướng tiếp cận này, thì đã thừa nhận là các yêu cầu nghiệp vụ đã tồn tại

Hình 2.4 – Quy trình các bước của phương pháp bottom-up

 Bước 1: Model application services: Trong bước này kết quả là sự định

nghĩa của các yêu cầu ứng dụng được thỏa mãn thông qua việc sử dụng Web service Các yêu cầu này bao gồm những thiết lập lên các kênh tích hợp point-to-

point giữa hệ thống cũ (legacy system) hoặc giải pháp B2B (Business-to-Business)

Các yêu cầu phổ biến khác sẽ hiện ra để thay công nghệ truyền thông truyền thống bằng những framework truyền thông điệp SOAP

Các dịch vụ ứng dụng cũng sẽ được mô hình hóa bao gồm các logic và quy tắc cho nghiệp vụ cụ thể Trong trường hợp này, nó là giống như hai tầng dịch vụ ứng dụng là sẽ hiện ra, gồm có các dịch vụ tiện ích và nhân bản

 Bước 2: Design applicaion services: Một vài các dịch vụ ứng dụng được mô

hình hóa trong bước 1 có thể được trình bày bằng thành bản thiết kế Các dich vụ có thể cung cấp thêm vào cho thiết kế Các dịch vụ ứng dụng tùy ý sẽ cần được trải qua quá trình thiết kế, ở một khía cạnh nào đó thì tồn tại những chuẩn thiết kế được áp dụng để đảm bảo mức độ vững chắc

 Bước 3: Deploy application service: Các dịch vụ ứng dụng được phát triển

theo sự mô tả dịch vụ và bản thiết kế chi tiết ứng dụng

 Bước 4: Test service: Các dịch vụ, môi trường kết hợp của chúng, và logic

của những hệ thống cũ là được kiểm thử để đảm bảo chắc chắn rằng xử lý các yêu cầu là phù hợp Sự thực thi và tiêu chuẩn kiểm thử được nhấn mạnh thường là được thiết lập lên các tham số cho hệ thống cũ thông qua các dịch vụ Kiểm tra bảo mật cũng là phần quan trọng của giai đoạn này

 Bước 5: Deploy services: Những giải pháp và các dịch vụ ứng dụng của nó là

được triển khai thành sản phẩm Sự cân nhắc thực thi cho các dịch vụ ứng dụng thường bao gồm sự thực thi và các yêu cầu bảo mật

 Phần lớn các tổ chức hiện nay là đang xây dựng Web service áp dụng phương pháp bottom-up Lý do chính là các tổ chức đơn giản chỉ thêm Web service vào môi trường ứng dụng đã có để tăng sức mạnh của công nghệ Web service Thông qua phương pháp thiết kế bottom-up cho phép tạo hiệu quả Web service như

là được yêu cầu bởi các ứng dụng

2.2 Dịch vụ web (web service)

2.2.1 Khái niệm về dịch vụ web

Web Services là chuẩn mở của tổ chức W3C (World Wide Web Consortium)

và được định nghĩa như sau: “Web Service là ứng dụng phần mềm được định danh

bởi URI (Uniform Resource Identifier), các giao diện và sự gắn kết của nó là có khả

năng định nghĩa, mô tả, và khám phá bằng XML Một Web Service hỗ trợ trực tiếp

sự tương tác với những tác nhân phần mềm (software agents) khác bằng việc sử

dụng những thông điệp dựa trên XML được trao đổi thông qua giao thức dựa trên Internet.”

Như vậy, Web Service là hệ thống phần mềm được xây dựng để hỗ trợ cho sự tương tác hoạt động giữa các hệ thống với nhau thông qua môi trường mạng Web Service thường là các hàm Web API có thể truy cập qua môi trường mạng như Internet, và thực thi dựa vào các yêu cầu dịch vụ của các hệ thống máy tính từ xa

Hình 2.5 – Kiến trúc của Web Service

Định nghĩa Web Service bao gồm nhiều hệ thống khác nhau, nhưng thường bao gồm client và server, truyền thông giữa chúng bằng XML dựa trên giao thức

chuẩn SOAP (Simple Object Access Protocol) và đặc tả Web Service dựa trên ngôn ngữ WSDL (Web Services Description Language) Những tài liệu XML chứa các

thông tin để trao đổi giữa các thành phần Trong khi đó, SOAP cung cấp chuẩn đóng gói và định tuyến cho việc trao đổi những tài liệu XML trên một mạng, còn WSDL cho phép tổ chức đặc tả những tài liệu XML và những thông điệp mà nó phải sử

dụng để tương tác với những Web Service Cuối cùng là UDDI (Universal Description, Discovery, and Integration) cho phép những tổ chức đăng ký những

Web Service của họ với một thư mục chung, vì vậy những client có thể xác định được những Web Service của họ và biết làm thế nào để truy xuất đến chúng

Dữ liệu và các ứng dụng từ máy tính cá nhân tới các máy phục vụ của một nhà cung cấp dịch vụ web Các máy phục vụ này cũng cần trở thành nguồn cung cấp cho người dùng cả về độ an toàn, độ riêng tư và khả năng truy cập Các máy phục vụ

ứng dụng sẽ là phần quan trọng của các Web Service bởi vì thường thì các máy phục

vụ này thực hiện các hoạt động ứng dụng phức tạp dựa trên sự chuyển giao giữa người sử dụng và các chương trình kinh doanh hay các cơ sở dữ liệu của một tổ chức nào đó

Web Service là công nghệ tương đối mới mà nó nhận được sự hưởng ứng rộng lớn, một trong đó là khả năng thực thi kiến trúc hướng dịch vụ (SOA) Đây là điều tạo sao Web Service cung cấp khả năng phân tán cho những ứng dụng không đồng nhất với nhau qua mạng Interrnet Những đặc tả Web Service không lệ thuộc vào các ngôn ngữ lập trình, hê điều hành và phần cứng Công nghệ của Web Service dựa trên các công nghệ mở như:

 eXtensible Markup Language (XML)

 Simple Object Access Protocol (SOAP)

 Universal Description, Discovery and Integration (UDDI)

 Web Service Description Language (WSDL)

2.2.2 Đặc điểm của dịch vụ web

 Dịch vụ Web cho phép client và server tương tác được với nhau ngay cả trong những môi trường khác nhau

 Phần lớn kĩ thuật của dịch vụ Web được xây dựng dựa trên mã nguồn mở và được phát triển từ các chuẩn đã được công nhận như XML

 Một Dịch vụ Web bao gồm có nhiều mô-đun

 Là sự kết hợp của việc phát triển theo hướng từng thành phần với những lĩnh

 Ngày nay dịch vụ Web đang rất phát triển, những lĩnh vực trong cuộc sống

có thể áp dụng và tích hợp dịch vụ Web là khá rộng lớn như dịch vụ chọn lọc và phân loại tin tức (hệ thống thư viện có kết nối đến web portal để tìm kiếm các thông tin cần thiết); ứng dụng cho các dịch vụ du lịch (cung cấp giá vé, thông tin về địa điểm…), các đại lý bán hàng qua mạng, thông tin thương mại như giá cả, tỷ giá hối đoái, đấu giá qua mạng…hay dịch vụ giao dịch trực tuyến (cho cả B2B và B2C) như đặt vé máy bay, thông tin thuê xe…

2.2.3 Ưu và nhược điểm

 Nâng cao khả năng tái sử dụng

 Thúc đẩy đầu tư các hệ thống phần mềm đã tồn tại bằng cách cho phép các tiến trình/chức năng nghiệp vụ đóng gói trong giao diện dịch vụ Web

 Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong

hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán

 Thúc đẩy hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giá thành hoạt động, phát triển hệ thống nhanh và tương tác hiệu quả với hệ thống của các doanh nghiệp khác

► Nhược điểm:

 Những thiệt hại lớn sẽ xảy ra vào khoảng thời gian chết của dịch vụ Web, giao diện không thay đổi, có thể lỗi nếu một máy khách không được nâng cấp, thiếu các giao thức cho việc vận hành

Có quá nhiều chuẩn cho dịch vụ Web khiến người dùng khó nắm bắt

 Phải quan tâm nhiều hơn đến vấn đề an toàn và bảo mật

2.2.4 Kiến trúc web service

Hình 2.6: Kiến trúc web service

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

● 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 đă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

2.2.5 Các thành phần trong web service

● XML– Extensible Markup Language

Là một chuẩn mở do W3C đưa ra cho cách thức mô tả dữ liệu, nó được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu B2B Về hình thức, XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML nhưng HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đó chứa cái gì Với XML, các thẻ có thể được lập trình viên

tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến và hiệu quả mã nguồn mở

Do dịch vụ Web là sự kết hợp của nhiều thành phần khác nhau nên nó sử dụng các tính năng và đặc trưng của các thành phần đó để giao tiếp XML là công cụ chính để giải quyết vấn đề này và là kiến trúc nền tảng cho việc xây dựng một dịch

vụ Web, tất cả dữ liệu sẽ được chuyển sang định dạng thẻ XML Khi đó, các thông tin mã hóa sẽ hoàn toàn phù hợp với các thông tin theo chuẩn của SOAP hoặc XML-RPC và có thể tương tác với nhau trong một thể thống nhất

● SOAP - Simple Object Accesss Protocol

SOAP là một giao thức giao tiếp có cấu trúc như XML Nó được xem là cấu trúc xương sống của các ứng dụng phân tán được xây dựng từ nhiều ngôn ngữ và

các hệ điều hành khác nhau SOAP là giao thức thay đổi các thông điệp dựa trên XML qua mạng máy tính, thông thường sử dụng giao thức HTTP

Một client sẽ gửi thông điệp yêu cầu tới server và ngay lập tức server sẽ gửi những thông điệp trả lời tới client Cả SMTP và HTTP đều là những giao thức ở lớp ứng dụng của SOAP nhưng HTTP được sử dụng và chấp nhận rộng rãi hơn bởi ngày

nay nó có thể làm việc rất tốt với cơ sở hạ tầng Internet

 Cấu trúc một thông điệp theo dạng SOAP

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

Hình 2.7 - Cấu trúc thông điệp SOAP

▪ Phần tử gốc - envelop: phần tử 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

▪ Phần tử đưa ra các thông tin về lỗi -fault, cung cấp thông tin lỗi xảy ra trong qúa trình xử lý thông điệp

Một SOAP đơn giản trong body sẽ lưu các thông tin về tên thông điệp, tham chiếu tới một thể hiện của dịch vụ, một hoặc nhiều tham số Có 3 kiểu thông báo sẽ được đưa ra khi truyền thông tin: request message(tham số gọi thực thi một thông điệp), respond message (các tham số trả về, được sử dụng khi yêu cầu được đáp ứng) và cuối cùng là fault message (thông báo tình trạng lỗi)

 Kiểu truyền thông: Có 2 kiểu truyền thông

▪ Remote procedure call (RPC): cho phép gọi hàm hoặc thủ tục qua mạng Kiểu này được khai thác bởi nhiều dịch vụ Web

▪ Document: được biết đến như kiểu hướng thông điệp, nó cung cấp giao tiếp ở mức trừu tượng thấp, khó hiểu và yêu cầu lập trình viên mất công sức hơn

Hai kiểu truyền thông này cung cấp các định dạng thông điệp, tham số, lời gọi đến các API khác nhau nên việc sử dụng chúng tùy thuộc vào thời gian và sự phù hợp với dịch vụ Web cần xây dựng

 Cấu trúc dữ liệu: Cung cấp những định dạng và khái niệm cơ bản giống như trong

các ngôn ngữ lập trình khác như kiểu dữ liệu (int, string, date…) hay những kiều phức tạp hơn như struct, array, vector… Định nghĩa cấu trúc dữ liệu SOAP được đặt trong namespace SOAP-ENC

 Mã hóa: Giả sử dịch vụ yêu cầu và dịch vụ provider được phát triển trong Java,

khi đó mã hóa SOAP là làm thế nào chuyển đổi từ cấu trúc dữ liệu Java sang SOAP XML và ngược lại, bởi vì định dạng cho Web Service chính là XML Bất kỳ một môi trường thực thi SOAP nào cũng phải có một bảng chứa thông tin ánh xạ nhằm chuyển đổi từ ngôn ngữ Java sang XML và từ XML sang Java - bảng đó được gọi là SOAPMappingRegistry Nếu một kiểu dữ liệu được sử dụng dưới một dạng mã hóa thì sẽ có một ánh xạ tồn tại trong bộ đăng ký của môi trường thực thi SOAP đó

Các ứng dụng có thể xử lý và định tuyến các thông điệp dựa trên thông tin

trúc như DCOM, CORBA và RMI không có được, vì các protocol header của chúng phải được chỉ định chi tiết cho mỗi ứng dụng

● WSDL -Web Services Description Language

WSDL định nghĩa cách mô tả dịch vụ Web theo cú pháp tổng quát của XML, bao gồm các thông tin:

▪ Tên dịch vụ

▪ Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của dịch vụ Web

▪ Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao diện của dịch vụ Web cộng với tên cho giao diện này)

Một WSDL hợp lệ gồm hai phần: phần giao diện (mô tả giao diện và phương thức kết nối) và phần thi hành mô tả thông tin truy xuất CSDL Cả hai phần này sẽ được lưu trong 2 tập tin XML tương ứng là tập tin giao diện dịch vụ và tập tin thi hành dịch vụ Giao diện của một dịch vụ Web được miêu tả trong phần này đưa ra cách thức làm thế nào để giao tiếp qua dịch vụ Web Tên, giao thức liên kết và định dạng thông điệp yêu cầu để tương tác với dịch vụ Web được đưa vào thư mục của WSDL

WSDL thường được sử dụng kết hợp với XML schema và SOAP để cung cấp dịch vụ Web qua Internet Một client khi kết nối tới dịch vụ Web có thể đọc WSDL

để xác định những chức năng sẵn có trên server Sau đó, client có thể sử dụng SOAP

để lấy ra chức năng chính xác có trong WSDL

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

Tập tin giao diện - Service Interface

WSDL mô tả 5 loại thông tin chính bao gồm : import , types , message , portType , binding

▪ Types :WSDL định nghĩa các kiểu dữ liệu của thông điệp gửi

Những định nghĩa message được sử dụng bởi phần tử thi hành service Nhiều thao tác có thể tham chiếu tới cùng định nghĩa message

Thao tác và những message được mô hình riêng rẽ để hỗ trợ tính linh hoạt và đơn giản hóa việc tái sử dụng lại Chẳng hạn, hai thao tác với cùng tham số có thể chia sẻ một định nghĩa message

▪ Kiểu cổng (port type):WSDL mô tả cách gửi và nhận thông điệp

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

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

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

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

- 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 > *

- Mỗi một kết hợp tham chiếu đến một loại cổng; một kiểu cổng (portType)

có thể được sử dụng trong nhiều mối kết hợp Tất cả các thao tác định nghĩa bên trong kiểu cổng phải nằm trong phạm vi mối kết hợp

▪Tập tin thi hành - Service Implementation

WSDL mô tả 2 loại thông tin chính bao gồm : service và port

Dịch vụ (Service) : Nó sẽ thực hiện những gì đã được định nghĩa trong tập tin giao diện và cách gọi web services theo thủ tục và phương thức nào :

</wsdl:definitions>

Ở đây chúng ta thấy rằng thuộc tính kết hợp tên là qname Nó tham chiếu tới một mối kết hợp Một cổng chứa đựng chính xác một địa chỉ mạng; Bất kỳ cổng nào trong phần thi hành phải tương ứng chính xác với một tham chiếu trong phần giao diện

● UDDI - Universal Description, Discovery and Intergration

Về cơ bản Universal Description, Discovery, and Intergration (UDDI) là một nơi mà các tổ chức đăng ký và tìm kiếm các Web Service Cho phép người sử dụng dịch vụ tìm đúng nhà cung cấp dịch vụ cần tìm UDDI hỗ trợ chức năng:

• Thực hiện tìm kiếm, định vị những doanh nghiệp cung cấp dịch vụ hay sản phẩm theo phần loại theo vùng địa lý

• Thông tin về một nhà cung cấp dịch vụ bao gồm địa chỉ, thông tin liên lạc và các định danh

• Thông tin kỹ thuật (Technical information) về Web service mà doanh nghiệp cung cấp (ví dụ như cách sử dụng dịch vụ được cung cấp)

Để sử dụng đến các dịch vụ của UDDI, bản thân UDDI cung cấp một tập hàm API dưới dạng SOAP Web Service Tập API được chia làm hai phần: Inquiry API dung truy vấn và Publisher’s API dùng đăng ký Phần API dùng để truy vấn bao gồm hai phần con : một phần dùng để tạo ra các chương trình cho phép tìm kiếm và duyệt thông tin trên một UDDI registry, phần còn lại dùng để xử lý lỗi triệu gọi Thành phần xử lý chính là bộ đăng ký UDDI, đó là một file XML dùng để mô tả một thực thể kinh doanh (business entity) kèm theo các Web service đi cùng Sử

 Tóm lại để tạo một web service chúng ta cần xây dựng các tầng cần thiết trong kiến trúc web service hay nói cách khác là xây dựng và thiết lập các thành phần trong các tầng đó , cụ thể là các thành phần SOAP , WSDL , UDDI , XML , trong đó :

- 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

- WSDL là một ngôn ngữ mô tả giao tiếp và thực thi dựa trên XML Web service sử dụ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

- 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 thi các hàm , các chức năng của web service 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 đó chúng ta cũng phải quan tâm đến việc làm sao để cho các service có tính an toàn , toàn vẹn và bảo mật thông tin trong web services nhất là các service liên quan đến giao dịch thương mại và tài chính.Chúng ta sẽ tìm hiểu nội dung này trong các phần tiếp theo

Sơ đồ dưới đây cho chúng ta thấy rõ hơn về các thành phần cần thiết trong một web service và mối quan hệ giữa các thành phần

Hình 2.9 - Mối quan hệ giữa các thành phần trong Web service

2.2.6 An toàn cho dịch vụ Web

Dịch vụ Web liên kết và tương tác với các ứng dụng qua Internet, chính vì vậy bảo mật là một vấn đề được quan tâm khi các công ty tiến tới kết hợp ứng dụng với một dịch vụ Web Việc đảm bảo an toàn cho dịch vụ Web là một vấn đề quan trọng, đặc biệt đối với những dịch vụ liên quan đến trao đổi tiền tệ, thông tin từ thị trường chứng khoán hay dịch vụ bán hàng qua mạng (liên quan đến trả tiền bằng tài khoản

và có yêu cầu thông tin cá nhân của người dùng)

Trước khi có WS-Security (bảo mật cho dịch vụ Web) thì ý nghĩa thông thường của an toàn dịch vụ Web là bảo mật kênh truyền dữ liệu Hiện nay, nó được thực hiện cho những SOAP/HTTP dựa trên cơ chế truyền thông điệp bằng cách sử dụng giao thức HTTPS Không chỉ là an toàn ở mức truyền thông điệp, HTTPS còn cung cấp sự an toàn tới toàn bộ gói dữ liệu HTTP

Mặc dù HTTPS không bao gồm tất cả các khía cạnh trong chuẩn an toàn chung cho dịch vụ Web nhưng nó đã cung cấp một lớp bảo mật khá đầy đủ với định danh, chứng thực, tính toàn vẹn thông điệp hay độ tin cậy

Khái niệm về WS-Security: đây là một chuẩn an toàn bao trùm cho SOAP, nó được dùng khi muốn xây dựng những dịch vụ Web toàn vẹn và tin cậy Toàn vẹn có nghĩa là khi có một giao dịch hay khi truyền thông tin, hệ thống và thông tin sẽ không bị chặn, giao dịch sẽ không bị mất cũng như không thể có người lấy cắp được

dữ liệu trên đường truyền WS-security được thiết kế mang tính mở nhằm hướng tới những mô hình an toàn khác bao gồm PKI, Kerberos và SSL Nó cũng đưa ra nhiều

Tính toàn vẹn tạo ra một chữ ký số hóa XML dựa trên nội dung của thông điệp Nếu dữ liệu bị thay đổi bất hợp pháp, nó sẽ không còn thích hợp với chữ ký số hóa XML đó Chữ ký này được tạo ra dựa trên khóa mà người gửi thông điệp tạo ra, do

đó người nhận chỉ nhận thông điệp khi có chữ ký sử dụng và nội dung phù hợp Ngược lại sẽ có một thông báo lỗi Việc chứng thực được thực hiện giữa client và server là cách chứng thực rất cơ bản (sử dụng định danh người dùng và mật khẩu)

WS-security chỉ là một trong những lớp an toàn và bảo mật cho dịch vụ Web,

vì vậy cần một mô hình an toàn chung lớn hơn để có thể bao quát được các khía cạnh khác Các thành phần được thêm có thể là WS-Secure Conversation Describes,WS-Authentication Describes,WS-Policy Describes hay WS-Trust Describes Chúng sẽ thực hiện việc đảm bảo an toàn hơn cho hệ thống khi trao đổi

dữ liệu, mở và đóng các phiên làm việc cũng như quản lý dữ liệu cần chứng thực và chính sách chứng thực

2.3 Xây dựng Web Services

2.3.1 Các giai đoạn xây dựng Web services

Có 4 giai đoạn chính để xây dựng một web service là xây dựng, triển khai, tiến hành và quản lý :

- Giai đoạn xây dựng bao gồm phát triển và chạy thử ứng dụng web service, bao gồm các chức năng và định nghĩa service

- Giai đoạn triển khai bao gồm công bố định nghĩa service, xây dựng WSDL,

và triển khai mã thực thi của web service

- Giai đoạn tiến hành bao gồm tìm kiếm và gọi thực thi web service

- Giai đoạn quản lý bao gồm quản lý và quản trị ứng dụng web service

Chu trình xây dựng một Web service bao gồm các bước chung phải có để tạo

ra một web service mới