đồ án tìm hiểu và xây dựng ứng dụng kiến trúc hướng dịch vụ với oracle soa suite

Câu hỏi được đặt ra là làm thế nào để vừa thỏa mãn những yêu cầu truyền thống, vừa đáp ứng nhanh chóng các yêu cầu mới, đồng thời đòi hỏi việc giảm chi phí, có khả năng sử dụng và tích h

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN KHOA CÔNG NGHỆ THÔNG TIN

THẠCH BẠCH – LÊ NGUYỄN HOÀI NAM

TÌM HIỂU VÀ XÂY DỰNG ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ VỚI

ORACLE SOA SUITE

KHÓA LUẬN TỐT NGHIỆP CỬ NHÂN CNTT

TP.HCM, 2011

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN KHOA CÔNG NGHỆ THÔNG TIN

TÌM HIỂU VÀ XÂY DỰNG ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ VỚI

ORACLE SOA SUITE

KHÓA LUẬN TỐT NGHIỆP CỬ NHÂN TIN HỌC

GIÁO VIÊN HƯỚNG DẪN ThS NGÔ BÁ NAM PHƯƠNG

NIÊN KHÓA 2007–2011

i

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

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

Khóa luận đáp ứng yêu cầu của Luận văn cử nhân tin học TpHCM, ngày …… tháng …… năm 2011

Giáo viên hướng dẫn

ii

NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

Khóa luận đáp ứng yêu cầu của Luận văn cử nhân tin học TpHCM, ngày …… tháng …… năm 2011

Giáo viên phản biện

iii

LỜI CÁM ƠN

Chúng em xin chân thành cảm ơn Khoa Công Nghệ Thông Tin, trường Đại Học Khoa Học Tự Nhiên Tp.HCM đã tạo điều kiện tốt cho chúng em thực hiện đề tài này

Chúng em xin chân thành cảm ơn Thầy Ngô Bá Nam Phương, là người đã định hướng và giúp đỡ chúng em trong suốt thời gian thực hiện đề tài Trong quá trình thực hiện đề tài Thầy đã tận tình chỉ dẫn, trao đổi giúp chúng em giải quyết các vấn

đề để hoàn thiện đề tài

Chúng em cũng xin gửi lời cảm ơn sâu sắc đến quý Thầy Cô trong Khoa đã tận tình giảng dạy và trang bị cho chúng em vốn kiến thức vô cùng quí báu trong những năm học vừa qua Cảm ơn Thầy Nguyễn Hoàng Anh và Thầy Hoàng Vũ Tuấn vì những tài liệu quý báu của các thầy

Bên cạnh đó chúng em xin gửi lòng biết ơn sâu sắc đến toàn thể gia đình Ba,

Mẹ, anh chị đã quan tâm, chăm sóc, động viên Bạn bè đã ủng hộ, giúp đỡ chúng

em trong những lúc khó khăn cũng như trong suốt thời gian học tập và nghiên cứu Mặc dù chúng em đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phép, nhưng chắc chắn sẽ không tránh khỏi những thiếu sót, kính mong sự cảm thông và chỉ bảo của quý Thầy Cô và các bạn

Nhóm thực hiện

Thạch Bạch – Lê Nguyễn Hoài Nam

Giáo viên hướng dẫn:

• Th.S Ngô Bá Nam Phương

Thời gian thực hiện:

• Nghiên cứu công nghệ và phát triển ứng dụng

• Đề tài thuộc hướng công nghệ phần mềm

Nội Dung Đề Tài:

• Tìm hiểu cơ sở nền tảng kiến trúc hướng dịch vụ

• Tìm hiểu kiến trúc hướng dịch vụ Oracle (Oracle SOA Suite)

• Tìm hiểu các phần mềm của Oracle hỗ trợ cho từng pha trong chu trình sống SOA

• Tìm hiểu kiến trúc Hibernate, Spring framework để phục vụ cho việc xây dựng ứng dụng minh họa

• Xây dựng ứng dụng dựa trên kiến trúc hướng dịch vụ theo đúng nền tảng kíến trúc hướng dịch vụ Oracle

Kết Quả Đạt Được:

• Tìm hiểu được cơ sở nền tảng kiến trúc hướng dịch vụ

• Tìm hiểu được nền tảng kiến trúc hướng dịch vụ Oracle cho việc xây dựng các quy trình ứng dụng

v

• Xây dựng ứng dụng theo đúng nền tảng kiến trúc hướng dịch vụ Oracle

Kế Hoạch Thực Hiện:

2/3/2011 17/3/2011 Tìm hiểu cơ sở nền tảng kiến trúc

Xác nhận của GVHD

ThS Ngô Bá Nam Phương

Ngày tháng năm 2011 Nhóm SV Thực hiện

Thạch Bạch – Lê Nguyễn Hoài Nam

vi

MỤC LỤC

LỜI CÁM ƠN 3

ĐỀ CƯƠNG LUẬN VĂN 4

MỤC LỤC 6

DANH MỤC CÁC HÌNH 9

DANH MỤC CÁC BẢNG 13

Chương 1 MỞ ĐẦU 1

1.1 Giới thiệu về đề tài 1

1.2 Lý do thực hiện đề tài 2

1.3 Mục tiêu đề tài 3

1.4 Nội dung luận văn 4

Chương 2 NỀN TẢNG KIẾN TRÚC HƯỚNG DỊCH VỤ ORACLE 6

2.1 Service Oriented Architecture (SOA) 7

2.2 Các lợi ích của kiến trúc hướng dịch vụ 10

2.3 Kiến trúc lớp doanh nghiệp (Layering the Enterprise Architecture) 15

2.4 Những công nghệ được sử dụng để cài đặt theo kiến trúc hướng dịch vụ (Standards in SOA) 20

2.5 Kiến trúc thành phần hướng dịch vụ 25

Chương 3 CÁC CÔNG CỤ HỖ TRỢ CÀI ĐẶT, TRIỂN KHAI VÀ QUẢN LÝ ỨNG DỤNG THEO KIẾN TRÚC HƯỚNG DỊCH VỤ 28

3.1 Các bước thực hiện trong chu kì sống SOA 29

3.2 Các phần mềm của Oracle hỗ trợ triển khai và quản lý trong chu kỳ sống SOA 29

vii

3.3 So sánh hai nền tảng IBM SOA Portfolio và Oracle SOA Suite 45

Chương 4 MÔ HÌNH HÓA ỨNG DỤNG VINABOOK 53

4.1 Giới Thiệu 53

4.2 Phát biểu bài toán 55

4.3 Chi tiết các chức năng và các phân hệ 56

4.4 Các yêu cầu chức năng cho Guest 57

4.5 Các Yêu cầu cho Member (Thành viên) 61

4.6 Các yêu cầu cho Admin (Quản trị viên) 61

4.7 Lược đồ Use-Case tổng thể 66

4.8 Các lược đồ Use-Case Chi Tiết 67

4.9 Thiết kế dữ liệu lưu trữ 71

Chương 5 TỔNG HỢP ỨNG DỤNG VINABOOK 72

5.1 Thành phần dịch vụ “Thêm Sản Phẩm” 72

5.2 Thành phần dịch vụ “Lấy Sản Phẩm Theo Loại, Giá, Tên Tác Giả Hoặc Sản Phẩm” (Tìm Kiếm Nâng Cao) 78

5.3 Thành phần dịch vụ “So Sánh Giá” (Với Amazon.com) 83

Chương 6 TRIỂN KHAI VÀ QUẢN LÝ ỨNG DỤNG VINABOOK 91

6.1 Triển khai ứng dụng 91

6.2 Khách hàng 91

6.3 Admin (Quyền quản trị) 113

6.4 Quản lý ứng dụng với WebLogic 118

Chương 7 Kết luận 123

7.1 Các kết quả đạt được 123

viii 7.2 Hướng phát triển của đề tài 125TÀI LIỆU THAM KHẢO 126

ix

DANH MỤC CÁC HÌNH

Hình 2-1: SOA, BPM, và EDA 7

Hình 2-2: Sự cộng tác trong kiến trúc hướng dịch vụ 8

Hình 2-3: Kiến trúc lớp doanh nghiệp 15

Hình 2-4: Mô tả các tầng nghiệp vụ 17

Hình 2-5: Giao diện point-to-point 17

Hình 2-6: ESB 18

Hình 2-7: Kiến trúc thành phần dịch vụ 27

Hình 3-1: Oracle JDeveloper Studio 33

Hình 3-2: BPEL Process Modeler trong JDeveloper (Nguồn: www.oracle.com) 35

Hình 3-3: Oracle BPEL Process Designer trong JDeveloper 37

Hình 3-4: Oracle BPEL Console (Nguồn: www.oracle.com) 38

Hình 3-5: Ứng dụng tổng hợp (Nguồn: www.oracle.com) 39

Hình 3-6: Oracle SQL * Plus 39

Hình 3-7: Oracle WebLogic Suite 41

Hình 3-8: Oracle Business Activity Monitoring (Nguồn www.oracle.com) 43

Hình 5-1: Thành phần tổng hợp dịch vụ “Thêm sản phẩm” 72

Hình 5-2: Quy trình nghiệp vụ “Thêm sản phẩm” 73

Hình 5-3: Thành phần tổng hợp dịch vụ “Tìm kiếm nâng cao” 78

Hình 5-4: Quy trình nghiệp vụ “Tìm kiếm nâng cao” 79

Hình 5-5: Thành phần tổng hợp dịch vụ “So sánh giá” 83

Hình 5-6: Quy trình nghiệp vụ “So sánh giá” 84

x

Hình 6-1: Đăng nhập ứng dụng 92

Hình 6-2: Giao diện đăng nhập 92

Hình 6-3: Giao diện đăng kí 93

Hình 6-4: Giao diện thông báo đăng ký thành công 94

Hình 6-5: Giao diện chỉnh sửa thông tin cá nhân 94

Hình 6-6: Giao diện thông báo chỉnh sửa thành công 95

Hình 6-7: Giao diện danh mục sản phẩm 95

Hình 6-8: Giao diện tìm kiếm sản phẩm 96

Hình 6-9: Giao diện tìm kiếm cơ bản 96

Hình 6-10: Tìm kiếm nâng cao 97

Hình 6-11: Kết quả tìm kiếm nâng cao 98

Hình 6-12: Giao diện tìm kiếm theo danh mục 99

Hình 6-13: Kết quả tìm kiếm theo danh mục 99

Hình 6-14: Đưa vào giỏ hàng 100

Hình 6-15: Giao diện giỏ hàng 101

Hình 6-16: Cập nhật giỏ hàng 101

Hình 6-17: Tiếp tục mua hàng 102

Hình 6-18: Thanh toán 103

Hình 6-19: Giao diện Sandbox PayPal 103

Hình 6-20: Màn hình tài khoản PayPal 104

Hình 6-21: Đăng nhập vào hệ thống PayPal 104

Hình 6-22: Tài khoản trước khi mua sản phẩm 105

Hình 6-23: Màn hình xác nhận thanh toán 105

xi

Hình 6-24: Màn hình thông báo thanh toán thành công 106

Hình 6-25: Lưu giỏ hàng 106

Hình 6-26: Kết quả lưu giỏ hàng 107

Hình 6-27: Xóa sản phẩm 107

Hình 6-28: Chọn sản phẩm trong giỏ hàng để xóa 108

Hình 6-29: Màn hình sau khi xóa 108

Hình 6-30: Xem chi tiết sản phẩm 109

Hình 6-31: Giao diện chính ‘Chi tiết sản phẩm’ 109

Hình 6-32: Giao diện sản phẩm bán chạy 110

Hình 6-33: Giao diện sản phẩm mới 110

Hình 6-34: So sánh giá 111

Hình 6-35: Giao diện ‘So sánh giá’ 111

Hình 6-36: Xem chi tiết so sánh giá 112

Hình 6-37: Chi tiết so sánh giá Vinabook 112

Hình 6-38: Chi tiết so sánh giá Amazon 113

Hình 6-39: Giao diện quản lý của Admin 113

Hình 6-40: Thêm tài khoản 114

Hình 6-41: Kết quả sau khi thêm tài khoản 114

Hình 6-42: Cập nhật tài khoản 115

Hình 6-43: Thông báo cập nhật tài khoản thành công 115

Hình 6-44: Xóa tài khoản 115

Hình 6-45: Thông báo xóa thành công 116

Hình 6-46: Giao diện quản lý sản phẩm 116

xii

Hình 6-47: Thêm sản phẩm 116

Hình 6-48: Thông báo thêm sản phẩm thành công 117

Hình 6-49: Xóa sản phẩm 117

Hình 6-50: Thông báo thêm sản phẩm thành công 117

Hình 6-51: Deployment – Log thông báo việc deploy đã thành công 118

Hình 6-52: WebLogic Enterprise Manager 119

Hình 6-53: Kiểm tra dịch vụ 120

Hình 6-54: Nhập thông tin để kiểm tra 120

Hình 6-55: Chọn hình thức xem 121

Hình 6-56: Test thành công 121

xiii

DANH MỤC CÁC BẢNG

Bảng 1-1: Danh sách công cụ hỗ trợ xây dựng ứng dụng Oracle SOA Suite 3

Bảng 2-1: Các xử lý cơ bản của BPEL 25

Bảng 2-2: Các xử lý có cấu trúc của BPEL 25

Bảng 3-1: Danh sách các sán phẩm hỗ trợ chu kỳ sống SOA 47

Bảng 3-2: Thời gian cài đặt của hai thành phần 49

Bảng 3-3: So sánh sự bảo mật của IBM và Oracle 50

Bảng 4-1: Bảng yêu cầu chức năng cho Khách Hàng 60

Bảng 4-2: Bảng yêu cầu chức năng cho Thành Viên 61

Bảng 4-3: Yêu cầu chức năng cho Quản Trị Viên 65

Bảng 5-1: Các hành động của dịch vụ “Thêm sản phẩm” 78

Bảng 5-2: Bảng hàng động của dịch vụ “Tìm kiếm nâng cao” 82

Bảng 5-3: Bảng hàng động của dịch vụ “So sánh giá” 89

1.1 Giới thiệu về đề tài

Trong suốt lịch sử phát triển của ngành công nghệ thông tin, có rất nhiều mô hình kiến trúc phần mềm được đưa ra phát triển, ứng dụng và đạt được nhiều thành công hết sức to lớn Tuy nhiên, phần mềm đang ngày càng trở nên quá phức tạp và vượt ra khỏi sự kiểm soát của các mô hình hiện nay, đó cũng chính là vấn đề lớn được đặt ra trong lĩnh vực phát triển phần mềm

Rất nhiều hệ thống phần mềm được thực hiện quá phức tạp, chi phí phát triển và bảo trì quá cao, đặc biệt với các 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ư nó đã vượt quá khả năng xử lý của các mô hình kiến trúc truyền thống Nguyên nhân một phần là do ngày càng xuất hiện nhiều công nghệ mới tạo nên môi trường không đồng nhất, một phần do yêu cầu trao đổi tương tác giữa các hệ thống phần mềm với nhau Câu hỏi được đặt ra là làm thế nào để vừa thỏa mãn những yêu cầu truyền thống, vừa đáp ứng nhanh chóng các yêu cầu mới, đồng thời đòi hỏi việc giảm chi phí, có khả năng sử dụng và tích hợp các thành phần mới… Kiến trúc hướng dịch vụ - Service Oriented Architecture (gọi tắt là SOA) - ra đời đánh dấu một bước phát triển mới của nghành công nghệ thông tin, đáp ứng được các nhu cầu nghiệp vụ nâng cao của doanh nghiệp

Kiến trúc hướng dịch vụ là một kiểu kiến trúc phần mềm và là sự kết hợp của nhiều phương pháp hướng tới việc đạt được khả năng giao tác giữa các ứng dụng đồng nhất hoặc không đồng nhất, các ứng dụng cục bộ hoặc từ xa bằng cách tổng

hợp các dịch vụ có khả năng tái sử dụng (Nguồn : www.oracle.com)

2

Hiểu một cách cơ bản, kiến trúc hướng dịch vụ là tập hợp các dịch vụ kết nối với nhau (nghĩa là một ứng dụng có thể liên lạc với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống và có thể tái sử dụng Kiến trúc hướng dịch vụ là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới Dịch vụ là yếu tố then chốt trong mô hình kiến trúc hướng dịch vụ Có thể hiểu dịch vụ như là hàm chức năng (mô-đun phần mềm) thực hiện quy trình nghiệp vụ nào đó Ta không những sử dụng chúng tạo ra những quy trình nghiệp vụ, mà còn

có thể sử dụng để xây dựng các ứng dụng mới

Thiết kế mô hình kiến trúc hướng dịch vụ tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ Nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ Việc tái sử dụng phần mềm tốt hơn, cũng như tăng cường sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ

1.2 Lý do thực hiện đề tài

Thông qua kết quả khảo sát các công cụ hỗ trợ xây dựng ứng dụng mô hình SOA, chúng em đã tìm hiểu việc xây dựng ứng dụng dựa trên Oracle SOA Suite Thêm vào đó, với những ưu điểm của Oracle SOA và những ưu điểm vượt trội của nó so với những mô hình kiến trúc truyền thống thì kiến trúc hướng dịch vụ nói chung và kiến trúc hướng dịch vụ của Oracle nói riêng, đã mở ra một bước phát triển mới trong lĩnh vực công nghệ thông tin

Ta có thể nhận thấy việc lập trình truyền thống chú trọng nhiều vào việc phát triển giao diện người dùng, các xử lý cơ sở dữ liệu, thực hiện các giao tác theo yêu

3

cầu Trong khi đó, kiến trúc hướng dịch vụ Oracle đã hỗ trợ một cách linh hoạt các hoạt động mở rộng như là tích hợp hướng dịch vụ và thiết kế các luồng quy trình nghiệp vụ Mặt khác, điểm nổi bật của Oracle SOA như tính kết nối lỏng, tính tái sử dụng các dịch vụ đã tồn tại sẵn,

Để có cái nhìn trực quan về những ưu điểm của mô hình kiến trúc này, thì việc xây dựng ứng dụng minh họa là rất cần thiết Muốn xây dựng các giải pháp ứng dụng thành công dựa trên mô hình kiến trúc hướng dịch vụ ta cần có kiến trúc tham chiếu, có các phần mềm hỗ trợ cho các pha trong chu kỳ sống của kiến trúc hướng dịch vụ, các kịch bản kiến trúc hướng dịch vụ, …

STT Tên sản phẩm

1 Oracle Express Edition (XE) 10.2.0.1

2 Oracle WebLogic Server + Coherence - Package Installer

- Tìm hiểu cơ sở nền tảng kiến trúc hướng dịch vụ

- Tìm hiểu nền tảng kiến trúc hướng dịch vụ Oracle

- Tìm hiểu và so sánh sự khác nhau giữa hai nền tảng kiến trúc hướng dịch vụ của Oracle và kiến trúc hướng dịch vụ của IBM

- Tìm hiểu các phần mềm của Oracle nhằm hỗ trợ cho từng pha trong chu kỳ sống của SOA

- Xây dựng ứng dụng dựa trên kiến trúc hướng dịch vụ theo đúng nền tảng kiến trúc hướng dịch vụ Oracle

4

1.4 Nội dung luận văn

Nội dung luận văn bao gồm 4 phần chính: Nghiên cứu cơ sở kiến trúc hướng dịch vụ, nghiên cứu nền tảng kiến trúc hướng dịch vụ Oracle, xây dựng ứng dụng

và tổng kết

Nội dung chi tiết của từng phần như sau:

 Phần 1: Nghiên cứu cơ sở kiến trúc hướng dịch vụ gồm 2 chương

 Chương 1: Mở đầu

 Nội dung: Giới thiệu đề tài, lý do thực hiện đề tài, mục tiêu của đề tài và nội dung trình bày của luận văn

 Chương 2: Nền tảng kiến trúc hướng dịch vụ Oracle

 Nội dung: Nêu định nghĩa các tính chất của mô hình kiến trúc hướng dịch vụ

 Phần 2: Nghiên cứu nền tảng kiến trúc huớng dịch vụ Oracle gồm 1 chương

• Chương 3: Các công cụ hỗ trợ cài đặt, triển khai và quản lý ứng dụng theo kiến trúc hướng dịch vụ

 Nội dung: Trình bày định nghĩa kiến trúc thành phần dịch vụ, các công cụ hỗ trợ chu kỳ sống SOA Oracle Suite, so sánh hai nền tảng SOA của Oracle và IBM

 Phần 3: Xây dựng ứng dụng gồm 3 chương

• Chương 4: Mô hình hóa ứng dụng Vinabook

 Nội dung: Mô hình hóa ứng dụng dựa trên kiến trúc hướng dịch vụ, ứng dụng thương mại điện tử VINABOOK Thu thập và quản lý yêu cầu, thiết kế các lược đồ Use-Case của ứng dụng, mô hình hóa quy trình nghiệp vụ của ứng dụng và thiết kế các dịch vụ

• Chương 5: Tổng hợp ứng dụng Vinabook

 Nội dung: Sử dụng phần mềm Oracle JDeveloper để tổng hợp ứng dụng ở mức tổng quát nhất có thể

5

• Chương 6: Triển khai và quản lý ứng dụng Vinabook

 Nội dung: Triển khai ứng dụng lên WebLogic, khảo sát ứng dụng dưới các vai trò: Khách hàng, Member (Thành viên), Quản trị (Admin) và quản lý ứng dụng với Enterprise Manager

 Phần 4: Tổng kết gồm 1 chương

• Chương 7: Kết luận

 Nội dung: Trình bày các kết quả đã đạt được và hướng phát triển của đề tài

6

Chương 2 NỀN TẢNG KIẾN TRÚC HƯỚNG DỊCH VỤ ORACLE

Nội dung trình bày trong chương 2 đề cập đến nền tảng kiến trúc hướng dịch

vụ của Oracle Gồm 2 phần chính:

 Giới thiệu về các khái niệm, tính chất của kiến trúc hướng dịch vụ (Service Oriented Architecture)

 Trình bày khái niệm kiến trúc thành phần hướng dịch vụ

Linh động hay thực hiện nghiệp vụ nhanh gọn là một mục tiêu quan trọng cho tổ chức hiện đại để theo kịp thị trường, thỏa mãn nhu cầu của khách hàng Sự toàn cầu hóa và internet đã có ảnh hưởng đến cơ hội tương tác giữa các đối tác và đạt được thỏa thuận với khách hàng Nhu cầu của ngành công nghệ thông tin là tính linh động để thay đổi nghiệp vụ hiện tại một cách nhanh chóng, tốn ít thời gian, chí phí thấp mà vẫn đạt được chất lượng cao

Thiết kế kiến trúc tốt sẽ giúp ích cho cả quy trình lẫn nghiệp vụ ngành công nghệ thông tin Trong chương này giới thiệu về kiến trúc hướng dịch vụ (SOA) của Oracle và tính chất đặc thù của SOA Mục tiêu của SOA là đáp ứng yêu cầu một cách nhanh chóng, cung cấp khả năng tương thích của các chức năng thông qua dịch vụ có sẵn Một phần khác của SOA là kiến trúc hướng sự kiện (Event Driven Architecture - EDA) EDA cho phép quy trình nghiệp vụ để khởi tạo thực thi dịch

vụ để đáp ứng với sự kiện mà không tạo ra sự phụ thuộc trực tiếp mà có thể tạo ra cản trở khả năng thay đổi các thành phần Như chúng ta thấy trong hình 2-1, SOA, BPM (BPEL Process Manager) và EDA có quan hệ mật thiết với nhau Quy trình nghiệp vụ trong BPM tăng khi một số sự kiện xảy ra và gọi dịch vụ để thực thi tác

vụ tự động

8

- Kiến trúc hướng dịch vụ cho phép các tài nguyên phần mềm độc lập trở thành các khối xây dựng sẵn để có thể tái sử dụng trong việc phát triển các ứng dụng khác Kiến trúc hướng

dịch vụ giúp tập trung vào việc

tổng hợp ứng dụng hơn là việc cài

đặt chi tiết bên dưới

- SOA được sử dụng để tạo ra các

2.1.2 Sự cộng tác trong kiến trúc hướng dịch vụ

Sự cộng tác trong kiến trúc hướng dịch vụ là mô hình tìm kiếm, nối kết

và gọi thực hiện dịch vụ Người dùng dịch vụ xác định vị trí dịch vụ động bằng cách truy vấn đến nơi đăng ký dịch vụ (Service Registry) tìm kiếm một dịch vụ khớp với yêu cầu của nó Nếu dịch vụ tồn tại thì nơi đăng ký dịch vụ

sẽ cung cấp cho người dùng dịch vụ hợp đồng dịch vụ và địa chỉ điểm cuối của dịch vụ cung cấp

Hình 2-2: Sự cộng tác trong kiến trúc hướng dịch vụ

9

 Các hoạt động trong kiến trúc hướng dịch vụ

- Công bố (Publish): nhà cung cấp dịch vụ công bố bản đặc tả dịch vụ

(WebService Description Language - WSDL) của mình lên nơi đăng ký dịch

vụ, khi đó người dùng dịch vụ có thể tìm kiếm và gọi thực hiện dịch vụ

thông qua bản đặc tả này

- Tìm kiếm (Find): người dùng dịch vụ định vị trí một dịch vụ bằng cách truy

vấn đến nơi đăng ký dịch vụ (Service Registry) yêu cầu cung cấp một dịch

vụ theo tiêu chuẩn của nó

- Nối kết và gọi thực hiện (Bind): sau khi có được bản đặc tả dịch vụ , người

dùng dịch vụ tiến hành gọi thực hiện dịch vụ theo thông tin trong bản đặc tả

dịch vụ

 Các vai trò trong kiến trúc hướng dịch vụ

- Người dùng dịch vụ (Service Consumer): là một ứng dụng, một module của

phần mềm hay là các dịch vụ khác có nhu cầu sử dụng dịch vụ Người dùng dịch vụ khởi tạo yêu cầu dịch vụ đến nơi đăng ký dịch vụ, nối kết với dịch vụ theo một giao thức truyền tải và chạy chức năng của dịch vụ Người dùng dịch vụ gọi thực hiện dịch vụ bằng cách gửi yêu cầu theo đúng định dạng ghi

trong bản hợp đồng dịch vụ

- Nhà cung cấp dịch vụ (Service Provider ): là một thực thể có địa chỉ mạng,

nó chấp nhận và thực hiện các yêu cầu từ các người dùng Nhà cung cấp dịch

vụ công bố các dịch vụ và hợp đồng dịch vụ của nó đến nơi đăng ký dịch vụ

để người dùng dịch vụ có thể tìm kiếm và truy cập dịch vụ

- Nơi đăng ký dịch vụ (Service Registry): là nơi được thiết lập cho việc tìm

kiếm , đăng ký và cung cấp dịch vụ, nó là một thư mục trên mạng chứa các dịch vụ Nơi đăng ký dịch vụ là một thực thể chấp nhận, lưu trữ các bản hợp đồng dịch vụ từ các nhà cung cấp dịch vụ và cung cấp các bản hợp đồng này

đến người dùng dịch vụ có nhu cầu

- Hợp đồng dịch vụ (Service Contract): là một đặc tả dịch vụ chỉ ra cách thức

mà người dùng dịch vụ tương tác với nhà cung cấp dịch vụ Nó chỉ định định

dịch vụ, bảo mật, khả năng sẵn sàng đáp ứng của dịch vụ (availability),

2.2 Các lợi ích của kiến trúc hướng dịch vụ

Đối tượng trung tâm của mô hình kiến trúc hướng dịch vụ là khái niệm dịch vụ Các dịch vụ là các thực thể độc lập thực hiện một chức năng nghiệp vụ riêng biệt Các dịch vụ được đưa ra để cung cấp các cấp độ khác nhau về chức năng trong một nghiệp vụ Sau đây là các tính chất mà dịch vụ có bên dưới kiến trúc hướng dịch vụ

- Tính chất kết nối lỏng (Loose Coupling)

- Khả năng tái sử dụng (Reuse)

- Khả năng trong suốt vị trí (Transparent Position)

- Khả năng giao tiếp (Communication)

- Khả năng tổng hợp (Composite)

- Khả năng tự phục hồi (Self-healing)

- Giao diện có địa chỉ mạng

- Khả năng tìm kiếm và ràng buộc động (Find and Binding)

- Khả năng tự chứa và đơn thể (Container and Module)

(Nguồn: Oracle SOA Suite 11g Handbook.pdf )

2.2.1 Tính chất kết nối lỏng (Loose Coupling)

SOA hỗ trợ tính kết nối lỏng thông qua việc sử dụng hợp đồng và liên kết (contract and binding) Một người sử dụng dịch vụ truy vấn đến nơi lưu trữ và cung cấp thông tin dịch vụ (Nơi đăng kí dịch vụ - Registry) để lấy thông tin về loại dịch

vụ cần sử dụng Nơi đăng kí dịch vụ sẽ trả về tất cả những dịch vụ thoả tiêu chuẩn tìm kiếm Từ bây giờ người dùng chỉ việc chọn dịch vụ mà mình cần và thực thi phương thức trên đó theo mô tả dịch vụ nhận được từ nơi đăng kí dịch vụ Bên sử

2.2.2 Khả năng tái sử dụng (Reuse)

Các dịch vụ được cung cấp trên môi trường mạng (Internet) và được đăng ký ở một nơi nhất định nên chúng dễ dàng được tìm thấy 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 giao diệ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 mục đí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

độ vững chắc trong cài đặt, nó còn giúp đơn giản hoá 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 phần 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 dịch vụ chia sẻ cơ sở hạ tầng (shared infrastructure service)

2.2.3 Khả năng trong suốt vị trí (Transparent Position)

Sự trong suốt vị trí là một trong những đặc tính của kiến trúc hướng dịch vụ Người dùng dịch vụ chỉ có thể biết vị trí dịch vụ tại nơi đăng kí dịch vụ Sự trong suốt vị trí có được là do việc sử dụng nơi đăng kí dịch vụ, bộ trung gian dịch vụ và các bộ trung gian khác nằm giữa nhà cung cấp dịch vụ và người dùng dịch vụ

2.2.4 Khả năng giao tiếp (Communication)

Các dịch vụ trong SOA có khả năng giao tiếp với nhau Nếu nhà cung cấp và người dùng dịch vụ có nền tảng khác nhau mà kết nối với nhau thì các giao thức giao tiếp dùng để hỗ trợ cho các tương tác dịch vụ cần phải tương thích với các nền

12

tảng đó Do có các yêu cầu giao tiếp, SOA sử dụng các công nghệ giao tiếp chuẩn

mở như XML và Web Service

2.2.5 Khả năng tổng hợp (Composite)

Chức năng phần mềm có thể được đóng gói như là các dịch vụ có mức độ trừu tượng khác nhau trong một nghiệp vụ Các dịch vụ có thể được tổng hợp để cài đặt các dịch có mức độ trừu tượng cao hơn Ví dụ: Việc tổng hợp một quy trình nghiệp

vụ từ các dịch vụ, sau đó quy trình được kết xuất như là một dịch vụ

Khả năng tổng hợp của dịch vụ liên quan tới cấu trúc đặc tả của dịch vụ Cấu trúc đặc tả cho phép các dịch vụ có khả năng tổng hợp, lắp ráp vào các ứng dụng mà lập trình viên tích hợp không quan tâm đến dịch vụ đó được thiết kế như thế nào Bằng việc sử dụng các dịch vụ đã được kiểm thử và xây dựng hoàn chỉnh làm gia tăng chất lượng của hệ thống phần mềm Xây dựng các hệ thống theo kiến trúc hướng dịch vụ là đầu tư cho hiện tại và cả tương lai Vì các dịch vụ dễ dàng dùng lại, dễ dàng tổng hợp vào các ứng dụng khác Với khả năng tổng hợp của dịch vụ làm cho hệ thống phần mềm có thể thích ứng nhanh chóng với các thay đổi, dễ dàng cải tiến, tái cấu trúc hệ thống phần mềm và thêm mới các chức năng cho nó một cách nhanh nhất có thể có

Một dịch vụ có thể được tổng hợp theo 3 cách: ứng dụng tổng hợp, các dịch vụ liên quan, dịch vụ tổng hợp Một ứng dụng thường là sự lắp ráp, tổng hợp từ các dịch vụ, các thành phần với nhau cho một mục đích xác định

Dịch vụ liên quan là tập các dịch vụ được quản lý trong một dịch vụ lớn hơn Ví dụ: dịch vụ kiểm tra tài khoản, dịch vụ đăng kí tài khoản, dịch vụ quản lý thông tin khách hàng Có thể được tổng hợp vào dịch vụ lớn là dịch vụ khách hàng

Dịch vụ tổng hợp là dịch vụ thực thi một nghiệp vụ, tương tác với nhiều dịch vụ

hệ thống để tạo ra bản thân nó, thường được gọi là quy trình nghiệp vụ Quy trình nghiệp vụ gồm một hay nhiều bước thực hiện, mỗi bước thực hiện là một tác vụ nghiệp vụ, mỗi tác vụ nghiệp vụ thực hiện gọi dịch vụ để hoàn thành tác vụ

13

2.2.6 Khả năng tự phục hồi (Self-healing)

Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục hồi của một hệ thống 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à một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần sự can thiệp của con người

Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nào trong tình trạng hỗn loạn Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thể hoạt động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tổng hợp

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 để xây dựng ứng dụng Một kiến trúc

hỗ trợ kết nối và thực thi động khi chạy 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

Thêm vào đó, bởi vì những hệ thống dựa trên dịch vụ yêu cầu sự tách biệt giữa giao diện (interface) 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 (interface) Nếu một thể hiện dịch vụ 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 khách hàng chỉ tương tác với giao diện (interface) 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 các hệ thống hướng dịch vụ

2.2.7 Giao diện có địa chỉ mạng

Vai trò của mạng là chính yếu trong kiến trúc hướng dịch vụ Một dịch vụ phải

có một giao diện có địa chỉ mạng Một người dùng dịch vụ trên một mạng phải có khả năng gọi dịch vụ thông qua mạng Mạng cho phép các dịch vụ được dùng lại bởi bất kì người dùng dịch vụ nào, bất kì thời điểm nào Khả năng tổng hợp ứng dụng từ các dịch vụ sẵn có trên các máy khác nhau chỉ có thể nếu dịch vụ hỗ trợ một giao diện mạng

14

Người dùng dịch vụ có thể truy cập một dịch vụ thông qua một giao diện cục bộ

mà không phải thông qua mạng nếu người dùng dịch vụ và nhà cung cấp dịch vụ nằm trên cùng một máy Mặc dù dịch vụ có thể được cấu hình cho việc truy cập từ người dùng dịch vụ trên cùng một máy nhưng dịch vụ phải đồng thời hỗ trợ cho việc truy cập dịch vụ từ bên ngoài

2.2.8 Khả năng tìm kiếm và ràng buộc động (Find and Binding)

SOA hỗ trợ khái niệm truy tìm dịch vụ (Find) 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 nhà cung cấp dịch vụ (Registry) về dịch vụ nào thoả yêu cầu tìm kiếm Ví dụ, một hệ thống chuyển khoản (Hệ thống chuyển khoảng trong trường hợp này là một người dùng dịch vụ) yêu cầu nơi cung cấp dịch vụ tìm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng Nơi cung cấp dịch vụ trả về một tập các entry (danh sách các dịch vụ) thoả yêu cầu Các entry chứa thông tin về dịch vụ, bao gồm cả phí giao dịch Bên sử dụng sẽ chọn một dịch vụ có phí giao dịch thấp nhất trong danh sách các dịch vụ trả về, kết nối đến nhà cung cấp dịch vụ đó dựa trên thông tin registry entry để sử dụng dịch vụ kiểm tra thẻ tín dụng Trong phần

mô tả dịch vụ kèm theo đã có tất cả các tham 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 trả 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 nơi cung cấp dịch vụ 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í dụ trên cho thấy cách người dùng dịch vụ tìm kiếm và sử dụng “động” một dịch vụ Đây là một thế mạnh của SOA Với SOA, phía người 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ỉ nhà cung cấp dịch vụ

15

2.2.9 Khả năng tự chứa và đơn thể (Container and Module)

Mặc dù việc sử dụng các giao diện tách biệt người dùng dịch vụ ra khỏi cài đặt dịch vụ nhưng các cài đặt của mỗi dịch vụ không nên kết nối với nhau Ví dụ, một cài đặt dịch vụ phụ thuộc vào cài đặt của dịch vụ khác bằng cách chia sẽ mã lệnh, chia sẽ truy cập dữ liệu, … Cách thiết kế này dẫn đến tình trạng khó bảo trì và kiểm lỗi dịch vụ Nếu các dịch vụ kết nối chặt, điều đó đi ngược lại mục đích của kiến trúc hướng dịch vụ đạ đề ra:

- Cực tiểu hóa độ móc nối giữa các dịch vụ

- Cài đặt dịch vụ như là người của các dịch vụ khác

- Dịch vụ thể hiện được độ kết dính giữa các phương thức

2.3 Kiến trúc lớp doanh nghiệp (Layering the Enterprise Architecture)

Khi mô tả một doanh nghiệp, kiến trúc của các lớp thường được thể hiện như trong hình 2-3 Mỗi lớp có những đặc trưng cụ thể, trách nhiệm và phụ thuộc lẫn nhau Do đó có các yêu cầu khác nhau về tiêu chuẩn và chất lượng

Hình 2-3: Kiến trúc lớp doanh nghiệp

2.3.1 Lớp ứng dụng dịch vụ (Application service layer)

Các ứng dụng (dịch vụ) bao gồm các lớp thành phần trong việc triển khai dịch

vụ Ví dụ như, nếu chúng ta có một dịch vụ làm công việc bổ nhiệm thì thành phần ứng dụng mà tạo ra việc bổ nhiệm để phục vụ nghiệp vụ thực tế

16

2.3.2 Lớp Dịch vụ và lớp sự kiện (Services and Events Layer)

Các dịch vụ và lớp sự kiện mô tả các hợp đồng và giao diện của dịch vụ Hợp đồng dịch vụ bổ nhiệm của chúng emcó thể biểu diễn, nó có sẵn trong giờ làm việc

và có thể được sử dụng bởi người có thẩm quyền Giao diện đã được định nghĩa sẵn

2.3.3 Lớp quy trình nghiệp vụ (Business Process Layer)

Lớp này chứa những quy trình nghiệp vụ Một quy trình nghiệp vụ bao gồm việc gọi đến các dịch vụ cho các hoạt động tự động và tác vụ cần có sự can thiệp của con người cho thao tác thủ công với một vài dòng công việc lôgic ở giữa Chu kỳ của quản lý quy trình nghiệp vụ bao gồm các giai đoạn sau đây: phân tích quy trình nghiệp vụ, thực thi quy trình nghiệp vụ và quản lý quy trình nghiệp vụ

Một loại quy trình mà con người làm trung tâm, nơi mà hầu hết các công việc được thực hiện bởi con người Thách thức quan trọng nhất là việc giao khối lượng công việc đồng đều và theo dõi tiến độ công việc Đây là quy trình làm việc của những kiểu quy trình truyền thống Một loại quy trình khác là lấy tài liệu làm trung tâm (ví dụ : quy trình RUP) Loại quy trình thứ ba là lấy quy trình làm trung tâm Đây là quy trình truyền thống gọi là sự phối hợp (Orchestrate)

Ngoài việc có loại quy trình khác nhau, chúng ta thường xác định mức độ khác nhau của quy trình Mary (người đã đề xuất ra quy trình nghiệp vụ trong một tổ chức) đã quyết định sử dụng các cấp độ: Cấp độ đầu tiên có chứa nhiều chuỗi quy trình nghiệp vụ Cấp độ thứ hai có chứa các quy trình end-to-end Mức thấp nhất là mức độ có liên quan cho các nhà phát triển và người dùng cuối Đây là quy trình mà thực sự sẽ được thực hiện và chạy trong thực tế Nó chứa chi tiết các hoạt động thực hiện về các loại tác vụ công việc (tự động, con người, v.v ) và mô tả chi tiết các dòng công việc với vòng lặp xác định Dưới đây là hai mẫu thiết kế mà St.Mathew (người đã đưa ra hai mẫu thiết kế về quy trình làm việc trong một tổ chức) đã quyết định áp dụng cho các quy trình nghiệp vụ :

 Quy trình không nên quá chung chung

 Sử dụng sự thực thi song song thực hiện bất cứ khi nào có thể

17

2.3.4 Lớp GUI (Graphic User Interface)

Lớp này chứa các giao diện tương tác với người dùng cuối Các thành phần trong lớp này chẳng hạn như khôi phục lại ứng dụng (backup), hoặc mash-up,…Sử dụng quy trình nghiệp vụ và các lớp dịch vụ để truy vấn dữ liệu và thực hiện các thao tác Chẳng hạn như, St.Mathew có thể tạo ra một cổng thông tin cho tất cả bệnh nhân Thông tin về bệnh viện có thể được hiển thị ở đó, truy vấn từ một dịch

vụ hệ thống quản lý nội dung Bệnh nhân cũng có thể được cung cấp một mẫu đăng

ký để yêu cầu cuộc hẹn Điều này một phần của ứng dụng có thể sử dụng dịch vụ hẹn

Hình 2-4: Mô tả các tầng nghiệp vụ

Hình 2-5: Giao diện point-to-point

18

2.3.5 Lớp Enterprise Service Bus (ESB)

Một trong những khó khăn khi xem xét tích hợp giữa hệ thống là quản lý tất cả các kết nối Nếu chúng ta có giao diện point-to-point (như hình 2-4) và vài thứ thay đổi trong dịch vụ, tất cả người tiêu dùng dịch vụ cần được sửa đổi Người tiêu dùng dịch vụ phải có kiến thức về giao thức khi gọi dịch vụ sử dụng, cũng như định dạng thông điệp và vị trí của dịch vụ Một ESB nằm giữa người tiêu dùng và các dịch vụ

mà họ gọi (xem hình 2-5) Nó thường có một số tính năng thuận lợi cho sự tương tác và giúp người tiêu dùng tách riêng từ nhà cung cấp:

 Endpoint ảo hóa (Endpoint virtualization) : khi người tiêu dùng gọi một

dịch vụ thông qua ESB thay vì gọi trực tiếp tới nhà cung cấp dịch vụ, định vị trong suốt đạt được trong kiến trúc Một nhà cung cấp dịch vụ có thể thay thế bằng một nhà cung cấp dịch vụ khác, mà không cần phải thay đổi người người tiêu dùng để phản ánh địa chỉ mới Đây được gọi là ảo hóa dịch vụ

(virtualization of servive)

 Định tuyến dịch vụ (Routing of service) : Căn cứ vào nội dung thông điệp

yêu cầu từ người dùng dịch vụ được chọn để chuyển tiếp các yêu cầu, đây

được gọi là nội dung dựa trên định tuyến

Hình 2-6: ESB

 Sự chuyển đổi(Transformation) : Nhà cung cấp và người tiêu dùng thường

không nói cùng một ngôn ngữ Họ thường xuyên không sử dụng các giao thức và thông điệp tương tự nhau ESB có thể chuyển đổi một yêu cầu để

19

định dạng và hỗ trợ giao thức bởi dịch vụ và không đảo ngược để đáp ứng trước khi trao lại cho người tiêu dùng Thông điệp trong ESB dựa trên mô hình dữ liệu kinh điển (Canonical Data Model - CDM); thông điệp được chuyển đến CDM khi vào ESB và có thể cần biến đổi để ứng dụng đặc biệt định dạng lại khi vượt ngoài sự hỗ trợ của ESB Yếu tố quan trọng nữa là

trong chuyển đổi có thể có thông điệp khác nhau

 Xác nhận(Validation): ESB có thể yêu cầu xác nhận trước khi chúng được gửi đến nhà cung cấp dịch vụ cũng như đáp ứng nhà cung cấp

 Kiểm soát(Auditing): Các ESB có thể đăng nhập và đáp ứng yêu cầu cho mục đích kiểm soát và gởi cảnh báo khi điều kiện đặc biệt được áp dụng

 Thông điệp(Messaging): Thay vì gọi một dịch vụ, một ứng dụng có thể gởi

thông điệp và giao tiếp bất đồng bộ với ứng dụng khác Các ESB có thể cung cấp đảm bảo giao phát và nhất quán thông điệp Điều này được giải thích chi

tiết hơn trong phần “Sự kiện và kiến trúc hướng sự kiện”

 Đồng bộ và bất đồng bộ bộ thích ứng (Synchronous/ asynchronous adaptation): Một ESB có thể vạch ra các dịch vụ với giao diện đồng bộ hoặc

bất đồng bộ, bất kể bản chất của nhà cung cấp dịch vụ thực tế nó cần phải gọi

Nó có thể thích ứng từ đồng bộ đến bất đồng bộ và ngược lại Điều này, cùng với việc hỗ trợ cho lưu trữ và chờ đợi các dịch vụ được cung cấp tạm thời Nhà cung cấp không cần phải sẵn sàng thời gian như nhà cung cấp dịch vụ

và người tiêu dùng không cần chờ đợi đáp ứng từ dịch vụ này gọi

 Thành phần (Composition): Một ESB có thể sử dụng để tổng hợp các kết

quả từ một số dịch vụ Lưu ý rằng các thành phần khác như: một cổ máy quy trình nghiệp vụ chạy trên quy trình BPMN (Business Process Model and Notation) hoặc BPEL (Business Process Execute Language) có thể cung cấp thành phần tương tự và chức năng tương tự như dịch vụ phối hợp Một ESB cũng có thể làm trung gian giữa giao thức bảo mật khác nhau, ví dụ như cho phép người tiêu dùng gởi một yêu cầu với một chứng thực SAML (Security

Assertion Markup Language, nguồn www.saml.xml.org) trong khi các nhà

20

cung cấp dịch vụ được chứng thực thông qua xác thực giao thức HTTP

(Hypertext Transfer Protocol) cơ bản ESB rõ ràng là tốt mang hai phần lại

với nhau thông qua các loại phân chia: giao thức giao tiếp, định vị, công nghệ, định dạng thông điệp, đồng bộ hay bất đồng bộ, sẵn sàng và giao thức bảo mật Những chức năng khác của ESB có thể cung cấp bao gồm kỹ thuật

và khía cạnh quản lý Chẳng hạn như, cải tiến hiệu suất thông qua kết quả bộ nhớ đệm, có tính sẵn sàng cao thông qua độ tin cậy, phân nhóm và quản lý giao dịch, bắt buộc chứng thực, điều tiết thông điệp và giám sát SLA (Service Level Agreement)

2.4 Những công nghệ được sử dụng để cài đặt theo kiến trúc hướng dịch

vụ (Standards in SOA)

Một trong những nguyên tắc quan trọng của SOA là tiêu chuẩn hóa Khi giao tiếp với ứng dụng khác, nếu giao thức và các định dạng thông điệp mà các ứng dụng này sử dụng khác nhau Chúng ta thấy rằng trong các cuộc thảo luận của chúng ta

về các định dạng dữ liệu kinh điển và ESB Điều này cũng đúng cho các giao thức

Hệ thống công nghệ thông tin trong một tổ chức thường sử dụng các giao thức khác nhau và các ngôn ngữ lập trình khác nhau Điều này làm cho sự kết hợp chúng với ứng dụng mới gặp khó khăn Để giải quyết điều này, nên sử dụng các giao thức chuẩn và định dạng thông điệp chuẩn Tiêu chuẩn trong SOA gồm các phần sau đây:

 Dịch vụ web (Web Service)

21

2.4.1 Dịch vụ web (Web Services)

Dịch vụ web (Web Service) là một trong những chuẩn được áp dụng phổ biến nhất trong kiến trúc hướng dịch vụ Theo tổ chức W3C mô tả các dịch vụ web như sau : “Dịch vụ web cung cấp một chuẩn tích hợp giữa các ứng dụng phần mềm khác nhau, chạy trên nhiều nền tảng hoặc các framework khác nhau Dịch vụ web đặc trưng bởi khả năng tương tác và mở rộng cũng như các đặc tả sử dụng XML Chúng

có thể được kết hợp một cách lỏng lẻo để mà đạt được các thao tác phức tạp Có hai cách để tạo ra một dịch vụ web: Sử dụng một giao thức định nghĩa hoạt động chính thức và định dạng thông điệp trước Dịch vụ web SOAP là một ví dụ làm việc theo thông số kỹ thuật chính thức được xác định trước, trong khi dịch vụ RESTful là một cách tiếp cận thứ hai

2.4.2 SOAP (Simple Object Access Protocol) và WSDL (Web Service Description Language)

Cách tiếp cận chính thức theo hợp đồng và tiếp cận theo XML được coi là rất mạnh Dịch vụ SOAP gọi một phương thức chính thức của việc giao tiếp giữa ứng dụng Thông qua SOAP và WSDL một tổ chức có thể mô tả các hoạt động có sẵn trong dịch vụ và các dữ liệu có thể được trao đổi với các dịch vụ Các đặc điểm kỹ thuật của dịch vụ này có các ưu điểm như sau :

 Tương tác mạnh mẽ

 Được hỗ trợ bởi nhiều giao thức(SOAP trên HTTP, SOAP trên JMS)

 Các tính năng khác như: WS- Addressing, WS-Security

2.4.3 Dịch vụ RESTful

Một dịch vụ web khác nhẹ hơn là RESTful REST viết tắt của Representational State Transfer Nguồn gốc được giới thiệu bởi Roy Fielding là một nguồn tài nguyên theo định hướng chứ không phải phương pháp chính thức của chương trình tương tác qua giao thức HTTP sử dụng bốn giao thức cơ bản: PUT, POST, GET và DELETE, dịch vụ RESTful đã phát triển thành giao thức HTTP dựa trên các API Dịch vụ RESTful chấp nhận yêu cầu giao thức HTTP đơn giản và gởi các đáp ứng

22

cho người dùng Ban đầu nó gần như phân bổ cho thấy sự cần thiết hoặc thậm chí cho các mô tả, trong khi ở giai đoạn sau này đã thử nghiệm với các nhóm lớn như WADL(Web Application Definition Language) Kiểu dịch vụ REST có thể trả về file XML, mặc dù các định dạng khác như CSV và JSON rất phổ biến Có rất nhiêu

sự hỗ trợ cho REST về phía khách hàng (dịch vụ REST áp dụng nhiều trong các ngôn ngữ lập trình) và một số trên máy chủ cho xuất bản các dịch vụ kiểu REST Một số ESB đã hỗ trợ cho REST mặc dù chủ yếu là XML được mô tả bởi một số hợp đồng được xác định trước RESTful rất hữu dụng cho việc tích hợp dữ liệu giữa web client và server

2.4.4 RSS Feeds

Một cách tiếp cận nhẹ nhàng để chương trình trao đổi thông tin là thông qua RSS feeds Một yêu cầu HTTP GET đơn giản đủ để lấy các thông tin, định dạng cấu trúc XML được xác định trước RSS chỉ hỗ trợ mô hình tương tác rất đơn giản

23

 Các thành phần

 Quy ước

 Các server

 Các xử lý tại điểm thực thi

Các chính sách cho phép thiết lập các quy tắc tại thời điểm thực thi, giám sát sự truyền thông, cách xử lý dịch vụ  làm nổi bật và gia tăng sức mạnh cho các hợp đồng dịch vụ Việc tạo ra các chính sách của quy trình thiết kế làm tăng tính linh hoạt và đem lại sự quản lý dễ dàng hơn nhiều

2.4.6 Thư mục UDDI (Universal Description Discovery and Integration), đăng

ký dịch vụ (Service Registry) và nơi lưu trữ dịch vụ (Service Reposity)

Bởi vì chúng ta muốn tái sử dụng các tài nguyên để xây dựng ứng dụng mới, sử dụng các thành phần tồn tại sẵn Chúng ta cần một vài kiểu đăng ký để lưu trữ và xuất bản thông tin về dịch vụ trong tổ chức Những dịch vụ này đã sẵn sàng và có thể được tìm thấy Để làm được điều này có thể sử dụng các công cụ khác nhau để tìm kiếm các dịch vụ, một tiêu chuẩn được định nghĩa để tìm kiếm dịch vụ web là : UDDI (Universal Description Discovery and Integration) UDDI định nghĩa một phương pháp chuẩn cho việc xuất bản và tìm kiếm mạng lưới các thành phần phần mềm trong SOA UDDI là một trong những chuẩn mới nhất trong dịch vụ web với WSDL và SOAP Nhiều UDDI hoặc dịch vụ đăng ký ngày nay dường như sử dụng cho lúc chạy để tìm kiếm vị trí vật lý của dịch vụ hoặc hình thức dịch vụ ảo

2.4.7 Business Process Execution Language (BPEL)

BPEL là một ngôn ngữ XML được thiết kế nhằm cho phép kết hợp các xử lý trên một môi trường phân tán theo một luồng xử lý hay quy trình nghiệp vụ có cấu trúc định trước Việc kết hợp một cách có hiệu quả các dịch vụ hỗ trợ rất nhiều trong việc tích hợp các hệ thống Điều này thật sự cần thiết trong bối cảnh phát triển ứng dụng cộng đồng công nghệ thông tin ngày nay Khi mà xuất hiện ngày càng nhiều các nền tảng và các công nghệ mới Và vấn đề mở rộng các hệ thống hiện có, tích hợp thêm các hệ thống mới để tiếp cận các lợi ích, các thành tựu của công nghệ mới đã trở nên là vấn đề cấp bách và hiện đang giành được rất nhiều sự quan tâm

24

Điều này thể hiện rõ ở sự ra đời của ngôn ngữ, với sự hỗ trợ phát triển của các công

ty lớn như là Microsoft, IBM, Siebel Systems, BEA, SAP và Oracle

BPEL được xây dựng dựa trên ngôn ngữ WSFL (Web Service Flow Language) của IBM và ngôn ngữ XLANG của Microsoft Vì thế nó kế thừa được những tính năng nổi trội của hai ngôn ngữ này (tính có cấu trúc của XLang và khả năng mô hình hóa của WSFL) BPEL hỗ trợ tạo ra hai loại tiến trình:

- Tiến trình trừu tượng: Đưa ra những qui tắc trao đổi thông điệp giữa những

dịch vụ tham gia, nhưng không chỉ rõ về cấu trúc bên trong của các thông điệp

- Tiến trình thực thi: Xác định rõ trình tự thực hiện của từng xử lý, các dịch

vụ liên quan, các thông điệp trao đổi trong khi tương tác, cơ chế bắt lỗi và xử

đối tượng bên ngoài tiến trình

bên ngoài tiến trình

khoảng thời gian

thực hiện một cách song song

kiện lặp còn được thỏa

theo các điều kiện

những xử lý tương ứng

Bảng 2-2: Các xử lý có cấu trúc của BPEL

2.5 Kiến trúc thành phần hướng dịch vụ

SCA (Service Component Architecture): là một mô hình lập trình mới cho

việc xây dựng kiến trúc hướng dịch vụ gọi là kiến trúc thành phần dịch vụ - SCA Kiến trúc thành phần dịch vụ là một mô hình được thiết kế đặc biệt cho việc xây dựng và tổng hợp các giải pháp nghiệp vụ trong kiến trúc hướng dịch vụ, hướng tới việc tích hợp và tổng hợp các dịch vụ Kiến trúc thành phần dịch vụ ra đời không có