Nghiên cứu và phát triển BPEL DESIGNER sử dụng công nghệ JAVAFX

Nghiên cứu và phát triển BPEL DESIGNER sử dụng công nghệ JAVAFX Các vấn đề nghiên cứu trong luận văn bao gồm: Tìm hiểu về kiến trúc hƣớng dịch vụ:SOA Tìm hiểu về ngôn ngữ mô hình hóa BPEL Nghiên cứu về ODE cho việc thực thi các tiến trình nghiệp vụ Tìm hiểu về công nghệ Java FX để xây dựng Bpel Designer Tìm hiểu về UDDI cho việc tìm kiếm và tổng hợp các WebService Xây dựng BPEL Designer trên môi trƣờng web cho phép ngƣời dùng xây dựng tìm kiếm , quản lý, lƣu trữ cũng nhƣ thực thi các tiến trình nghiệp vụ

KHOA CÔNG NGHỆ THÔNG TIN

NGUYỄN MẠNH LUÂN-MAI NGỌC SƯƠNG

NGHIÊN CỨU V PH T TRIỂN P L SIGN R

S NG CÔNG NGHỆ JAVA

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

TP HCM, 2011

KHOA CÔNG NGHỆ THÔNG TIN

NGUYỄN MẠNH LUÂN - 0842083 MAI NGỌC SƯƠNG - 0842126

NGHIÊN CỨU V PH T TRIỂN P L SIGN R

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

……… Khóa luận đáp ứng yêu cầu của LV cử nhân tin học

TpHCM, ngày …… tháng …… năm 2011

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

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

……… Khóa luận đáp ứng yêu cầu của LV cử nhân tin học

TpHCM, ngày …… tháng …… năm 2011

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

LỜI CẢM ƠN

Chúng em 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, Đại học Quốc gia Tp Hồ Chí Minh đã tạo điều kiện thuận lợi cho chúng em trong quá trình học tập và thực hiện đề tài tốt nghiệp

Chúng em xin nói lên lòng biết ơn sâu sắc đối với thầy Nguyễn Hoành Anh, thầy đã luôn quan tâm, tận tình hướng dẫn chúng em trong quá trình học tập, nghiên cứu và thực hiện đề tài

Chúng em xin chân thành cám ơn quý Thầy Cô trong Khoa Công Nghệ Thông Tin

đã tận tình giảng dạy, trang bị cho chúng em những kiến thức quý báu trong suốt quá trình học tập và thực hiện đề tài Chúng em cũng xin gửi lòng biết ơn đến thầy

cô và bạn bè trong lớp đã giúp đỡ, động viên tinh thần chúng em rất nhiều trong suốt quá trình thực hiện luận văn này

Chúng em nhớ mãi công ơn gia đình đã chăm sóc, động viên và tạo mọi điều kiện thuận lợi cho chúng em hoàn thành tốt luận văn này

Mặc dù đã 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 nhận được sự góp ý và tận tình chỉ bảo của quý Thầy Cô và các bạn

Một lần nữa, xin chân thành cám ơn và mong luôn nhận được những tình cảm chân thành của tất cả mọi người

TP Hồ Chí Minh, tháng 11 năm 2010 Nguyễn Mạnh Luân-Mai Ngọc Sương

Khoa Công Nghệ Thông Tin Lớp Hoàn Chỉnh Đại Học

ĐỀ CƯƠNG CHI TIẾT

Tên Đề Tài : NGHIÊN CỨU V PH T TRIỂN P L SIGN R S NG CÔNG NGHỆ JAVA

Giáo viên hướng dẫn: Nguyễn Hoàng Anh

Thời gian thực hiện: T 25 6 2010 đến 21/2/2011

Sinh viên thực hiện: 0842083 – Nguyễn Mạnh Luân, 0842126 – Mai Ngọc Sương Loại đề tài: Nghiên cứu lý thuyết, tìm hiểu công nghệ và phát triển ứng dụng

Nội ung Đề Tài: Đây là đề tài về hướng nghiên cứu lý thuyết, tìm hiểu công nghệ và

phát triển ứng dụng Nội dung đề tài bao gồm các phần sau:

 Tìm hiểu về kiến trúc hướng dịch vụ: SOA

 Tìm hiểu về ngôn ngữ mô hình hóa BPEL

 Nghiên cứu về ODE cho việc thực thi các tiến trình nghiệp vụ

 Tìm hiểu về công nghệ Java FX để xây dựng Bpel Designer

 Tìm hiểu về UDDI cho việc tìm kiếm và tổng hợp các WebService

 Xây dựng BPEL Designer trên môi trường web cho phép người dùng xây dựng tìm kiếm, quản lý, lưu trữ cũng như thực thi các tiến trình nghiệp vụ

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

-Ngày 25 6 2010 nhận đề tài

-T 25/6/2010 -5/8 2010 tìm hiểu các mô hình và các công nghệ liên quan: RIA, SOA, BPEL 1.1, JavaFX, UDDI và thu thập các tài liệu có liên quan

-T 6/8/2010-15/8 2010 xác định và phân tích yêu cầu

-T 16/8/2010-31/8 2010 mô hình hóa yêu cầu, phân chia công việc

-T 1/9 2010-31 12 2010 bắt đầu triển khai ứng dụng

-T 1 1 2011 -25 1 2011 chạy bản Beta thực hiện các thay đổi và kiểm thử cần thiết -T 26 1 2011-10 2 2011 tổng hợp xây dựng các tài liệu, báo cáo của dự án

M C L C

LỜI CẢM ƠN i

ĐỀ CƯƠNG CHI TIẾT ii

DANH MỤC HÌNH viii

DANH MỤC CÁC BẢNG xi

TÓM TẮT KHÓA LUẬN xiii

Chương 1.TỔNG QUAN 1

1.1 Tổng quan về nền công nghiệp phần mềm hiện nay 1

1.2 Giới thiệu về kiến trúc hướng dịch vụ(SOA) 3

1.2.1 Khái niệm 3

1.2.2 Sự khác nhau giữa dịch vụ web và kiến trúc hướng dịch vụ 5

1.2.3 Bốn nguyên tắc chính trong kiến trúc hướng dịch vụ 6

1.2.4 Các tích chất của một hệ thống được thiết kế theo kiến trúc hướng dịch vụ 7

1.2.5 Lợi ích mà kiến trúc hướng dịch vụ mang lại 10

1.2.6 Ưu điểm và khuyết điểm của hệ thống SOA 11

1.2.7 Xu hướng ứng dụng SOA hiện nay 13

1.3 Giới thiệu đề tài nghiên cứu và phát triển BPEL Designer với công nghệ JAVAFX 16

1.3.1 Lý do thực hiện đề tài nghiên cứu và phát triển BPEL Designer 16

1.3.2 Mục tiêu của đề tài 17

1.3.3 Các nghiên cứu liên quan đến BPEL-Designer và SOA trong khoa công nghệ thông tin đại học Khoa Học Tư Nhiên 17

Chương 2 PHÁT TRIỂN VÀ THỰC THI CÁC QUY TRÌNH NGHIỆP VỤ VỚI

WS-BPEL 2.0 VÀ APACHE ODE 19

2.1 Tổng quan về ngôn ngữ BPEL 19

2.1.1 Giới thiệu 19

2.1.2 Nguyên tắt hoạt động của một tiến trình BPEL 20

2.1.3 Cấu trúc của một tiến trình BPEL 22

2.1.4 Các thành phần và ký hiệu trong BPEL 23

2.1.5 Các bước xây dựng một tiến trình nghiệp vụ 42

2.2 Quản lý các ngoại lệ 44

2.3 Xử lý lỗi (Fault Handling) 44

2.4 Một số BPEL Designer hổ trợ WS-BPEL 2.0 trên thị trường hiện nay 45 2.4.1 Oracle BPEL Process Manager 45

2.4.2 Eclipse BPEL Designer 46

2.5 Đánh giá và kết luận 51

Chương 3 CÁC GIẢI PHÁP CHO VIỆC THỰC THI CÁC QUY TRÌNH NGHIỆP VỤ LƯU TRỮ VÀ TÌM KIẾM WEB SERVICE 53

3.1 Đặt vấn đề 53

3.2 Giới thiệu về Apche ODE 54

3.1.1 Giới thiệu 54

3.1.2 Cấu trúc của Apache ODE 54

3.1.3 Cách cài đặt Apche ODE 56

3.1.4 Triển khai một quy trình BPEL lên Apche ODE 57

3.3 Tìm hiểu về UDDI và cách thức tổ chức lưu trữ dữ liệu 60

3.3.1 Khái niệm và ý tưởng về UDDI 60

3.3.2 Cấu trúc dữ liệu của UDDI 61

3.3.3 Giải pháp lưu trữ dữ liệu cho UDDI 66

3.4 Kết luận 67

Chương 4 TÌM HIỂU VỀ CÔNG NGHỆ JAVAFX 68

4.1 Khái niệm về JavaFx 68

4.2 JavaFX platform 68

4.3 Javafx script 70

4.4 JavaFX runtime 71

4.5 JavaFx API 72

4.6 Công cụ phát triển 73

4.7 Cách triển khai một dự án javaFx 75

4.8 Một số User Interface trong JavaFx 76

4.9 Synchronize Data Models-Binding và Trigger 81

4.10 Kết luận 83

Chương 5 XÂY DỰNG VÀ THỬ NGHIỆM CÔNG CỤ BPELFX DESIGNER 84

5.1 Đặc tả hệ thống BPELfx Designer 84

5.1.1 Giới thiệu tổng quan về hệ thống 84

5.1.2 Nguyên lý tổ chức và vận hành hệ thống 84

5.1.3 Ý nghĩa thực tiễn của hệ thống 86

5.2 Xác định yêu cầu của hệ thống BPELfx Designer 86

5.3 Thiết kế hệ thống 92

5.3.1 Thiết kế các xử lý 92

5.3.2 Thiết kế dữ liệu lưu trữ 97

5.3.3 Thiết kế giao diện 101

5.4 Đánh giá kết luận 114

Chương 6 KẾT LUẬN 115

6.1 Các kết quả đạt được 115

6.2 Hướng phát triển của đề tài trong tương lai 116

DANH MỤC CÁC TÀI LIỆU THAM KHẢO 117

DANH M C HÌNH

Hình 1.1-Mô hình cộng tác SOA 3

Hình 1.2-Kiến trúc sản phẩm của IBM 14

Hình 2.1- Ví dụ về một tiến trình BPEL 20

Hình 2.2- Quan hệ giữa partnerLink và partnerLinkType 21

Hình 2.3-Ví dụ về trường hợp sử dụng invoke 26

Hình 2.4-Trường hợp sử dụng của Reply 28

Hình 2.5-Trường hợp sử dụng của Validate 29

Hình 2.6-Trường hợp sử dụng của Throw 30

Hình 2.7-Trường hợp sử dụng của Rethrow 31

Hình 2.8-Trường hợp sử dụng của Exit 32

Hình 2.9-Trường hợp sử dụng của Wait 33

Hình 2.10-Trường hợp sử dụng của Empty 33

Hình 2.11-Trường hợp sử dụng của Compensate Scope 34

Hình 2.12-Trường hợp sử dụng của Compensate 35

Hình 2.13-Trường hợp sử dụng của Flow 36

Hình 2.14-Trường hợp sử dụng của Pick 37

Hình 2.15-Trường hợp sử dụng của Foreach 39

Hình 2.16-Trường hợp sử dụng của Scope 40

Hình 2.18-Cấu trúc Oracle BPEL Process Manager 45

Hình 2.19-Môi trường làm việc của Oracle BPEL Process Manager 46

Hình 2.20-Tạo một quy trình BPEL với Eclipse BPEL Designer 47

Hình 2.21-Thay đổi thông tin tập tin WSDL 48

Hình 2.22-Tạo ràng buộc cho tập tin WSDL trong Eclipse BPEL Designer 48

Hình 2.23-Thay đổi các thuộc tính của tập tin WSDL trong BPEL Designer 49

Hình 2.24-Ràng buộc trong tập tin WSDL 49

Hình 2.25-Triển khai quy trình BPEL lên ODE Server trong Eclipse 51

Hình 3.1-Cấu trúc Apache ODE[ 12 ] 54

Hình 3.2-Cài đặt Apache ODE 56

Hình 3.3-Cài đặt Apache ODE 57

Hình 3.4-Tạo file deploy.xml 58

Hình 3.5-Deploy tiến trình lên ODE server 58

Hình 3.6-Test webservice 59

Hinh 3.7-Mối quan hệ giữa doanh nghiệp và nhà phát triển 60

Hình 3.8-Ý tưởng về UDDI 61

Hình 3.9-Sơ đồ các cấu trúc dữ liệu trong UDDI 62

Hình 3.10- Sơ đồ cấu trúc businessEntity 62

Hình 3.11-Sơ đồ cấu trúc ServirceBus 64

Hình 3.12- Sơ đồ cấu trúc bindingTemplate 65

Hình 3.13- Sơ đồ cấu trúc tModel 66

Hình 3.14- Sơ đồ ánh xạ các thành phần WSDL vào tModel 67

Hình 4.1-Nền tảng của JavaFx 69

Hình 4.2-Các phiên bản runtime của JavaFx 71

Hình 4.3-Một số gói công cụ phát triển JavaFx 74

Hình 4.4-Ví dụ về Stage 78

Hình 5.1-Cấu trúc hệ thống BPELfx Designer 85

Hình 5.2-Lượt đồ Usecase của hệ thống BPELfx Designer 87

Hình 5.3-Sơ đồ tổ chức các activity 93

Hình 5.4-Sơ đồ tổ chức các activity properties 94

Hình 5.5-Màn hình invoke properties 94

Hình 5.6-Process được thiết kế t BPELfx Designer 95

Hình 5.7-mẫu thiết kế xử lý phát sinh code 96

Hình 5.8-lượt đồ cơ sở dữ liệu lưu trữ thông tin project 97

Hình 5.9-Giao diện chính của chương trình 101

Hình 5.10-Màn hình tạo mới một file trong project 102

Hình 5.11-Màn hình tổ chức các activity 103

Hình 5.12-Màn hình tổ chức các activity 103

Hình 5.13-Màn hình tổ chức các process 104

Hình 5.14-Màn hình thêm mới PartnerLink 104

Hình 5.15-Màn hình chỉnh sửa một invoke activity 106

Hình 5.16-Màn hình chỉnh sửa một assign activity 107

Hình 5.17-Màn hình chỉnh sửa một reply activity 108

Hình 5.18-Màn hình chỉnh sửa một receive activity 108

Hình 5.19-Màn hình chỉnh sửa một if activity 109

Hình 5.20-Màn hình chỉnh sửa một repeat until activity 109

Hình 5.21-Màn hình chỉnh sửa một while activity 110

Hình 5.22-Màn hình chỉnh sửa một foreach activity 110

Hình 5.23-Màn hình chỉnh sửa một wait activity 111

Hình 5.24-Màn hình chỉnh sửa một throw activity 112

Hình 5.25-Màn hình import wsdl 112

Hình 5.26-Màn hình tạo file deploy.xml 113

Hình 5.27-Màn hình deploy một tiến trình 113

Hình 5.28-Màn hình kiểm tra dịch vụ sau khi deploy 114

DANH M C C C ẢNG

Bảng 2.1-Ví dụ về PartnerLink 22

Bảng 2.2-Cấu trúc file BPEL 22

Bảng 2.3-Các Activity trong BPEL 2.0 25

Bảng 2.4-cấu trúc XML của receive 26

Bảng 2.5-Cấu trúc Xml của invoke 27

Bảng 2.6-Cấu trúc Xml của Reply 28

Bảng 2.7-Cấu trúc Xml của Validate 29

Bảng 2.8-Cấu trúc Xml của Assign 30

Bảng 2.9-Cấu trúc Xml của Throw 31

Bảng 2.10-Cấu trúc Xml của Rethrow 32

Bảng 2.11-Cấu trúc Xml của Exit 32

Bảng 2.12-Cấu trúc Xml của wait 33

Bảng 2.13-Cấu trúc Xml của Empty 34

Bảng 2.14-Cấu trúc Xml của Compensate Scope 35

Bảng 2.15-Cấu trúc Xml của Compensate 35

Bảng 2.16-Cấu trúc Xml của Flow 36

Bảng 2.17-Cấu trúc Xml của RepeatUntil 36

Bảng 2.18-Cấu trúc Xml của Pick 37

Bảng 2.19-Cấu trúc Xml của If 38

Bảng 2.20-Cấu trúc Xml của Foreach 39

Bảng 2.21-Cấu trúc Xml của While 40

Bảng 2.22-Cấu trúc Xml của Scope 41

Bảng 2.23-Nội dung tập tin deploy 50

Bảng 4.1-Ví dụ về JavaFx script 70

Bảng 4.2-Các API trong javaFx 73

Bảng 4.3-Ví dụ về Stage 77

Bảng 4.4-Ví dụ về Scene 78

Bảng 4.5-Ví dụ về Style sheet 79

Bảng 4.6-Ví dụ về Scene 80

Bảng 5.1-Bảng Account 98

Bảng 5.2-Bảng Account 98

Bảng 5.3-Bảng Admin 98

Bảng 5.4-Bảng Project 99

Bảng 5.5-Bảng File 99

Bảng 5.6-Bảng Url 100

Bảng 5.7-Cấu trúc lưu trữ file BPEL 100

Bảng 5.8-Cấu trúc lưu trữ file deploy.xml 101

TÓM TẮT KHÓA LUẬN

 Các vấn đề nghiên cứu trong luận văn bao gồm:

 Tìm hiểu về kiến trúc hướng dịch vụ:SOA

 Tìm hiểu về ngôn ngữ mô hình hóa BPEL

 Nghiên cứu về ODE cho việc thực thi các tiến trình nghiệp vụ

 Tìm hiểu về công nghệ Java FX để xây dựng Bpel Designer

 Tìm hiểu về UDDI cho việc tìm kiếm và tổng hợp các WebService

 Xây dựng BPEL Designer trên môi trường web cho phép người dùng xây dựng tìm kiếm , quản lý, lưu trữ cũng như thực thi các tiến trình nghiệp vụ

 Kết quả đạt được:

 Lý thuyết về kiến trúc hướng dịch vụ, các ưu điểm của kiến trúc hướng dịch

vụ, xu hướng của kiến trúc hướng dịch vụ trong tương lai được trình bày ở chương 1 của luận văn

 Một số khái niệm về BPEL 2.0 bao gồm: định nghĩa về quy trình nghiệp vụ, các mô tả cho BPEL activity cùng một số khái niệm khác về BPEL được trình bày ở chương 2

 Hệ thống lý thuyết về UDDI bao gồm : khái niệm, cấu trúc, cách thức tổ chức dữ liệu , các lý thuyết về Java Fx được trình bày ở Chương 5

 Xây dựng và thử nghiệm ứng dụng BPEL Designer với công nghệ Java Fx vận hành trên môi trường Web, hỗ trợ người dùng thiết kế và thực thi các quy trình nghiệm vụ với ngơn ngữ mô hình hóa BPEL 2.0 Tích hợp công cụ tìm kiếm Web service

 Nội dung khóa luận gồm có 6 chương:

Chư ng 1: Tổng Quan

Chương 1 trình bày về thực trạng và xu hướng của ngành công nghệ phần mềm hiện nay T những thực trạng và xu hướng này sẽ giới thiệu tới các

bạn một trong những giải pháp cho xu hướng này đó là kiến trúc hướng dịch

vụ SOA đồng thời tóm tắt mục tiêu và nội dung của khóa luận

Chư ng 2: Phát triển và thực thi các quy trình nghiệp vụ với BPEL 2.0 và Apache ODE

Chương 2 giới thiệu về ngôn ngữ mô hình hóa tiến trình dịch vụ và được dùng để phát triển các ứng dụng lớn và phức tạp hiện nay BPEL, chúng tôi giới thiệu chi tiết về các thành phần cũng như các khái niệm trong BPEL, cách xây dựng một tiến trình BPEL đơn giản Qua chương này chúng tôi cũng đã giới thiệu một số khái niệm về Apache ODE bao gồm: cấu trúc, cách cài đặt, cách triển khai một quy trình nghiệp vụ lên Apache ODE

Chư ng 3: Các giải pháp cho việc thực thi các quy trình nghiệp vụ lưu trữ và tiềm kiế Webservice

Chương 3 giới thiệu về các giải pháp hổ trợ cho việc lưu trữ và thực thi và tìm kiếm các service

Chư ng 4: Tìm hiểu về công nghệ JavaFx

Chương 4 giới thiệu sơ lượt về công nghệ Javafx, một giải pháp mà chúng tôi đã chọn để xây dựng ứng dụng của mình

Chư ng 5: ây dựng và thử nghiệm công cụ BPELfx Designer

Chương 5 trình bày chi tiết về chương trình thử nghiệp BPEL Designer mà chúng tôi đã xây dựng dựa trên các cơ sở lý thuyết về BPEL 2.0 và ODE đã

nêu ở các phần trước đó

Chư ng 6: Kết luận

Chương 6 trình bày các kết quả đạt được và hướng phát triển của đề tài

1.1 Tổng quan về nền công nghiệp phần mềm hiện nay

Thế kỷ 21 là một thế kỷ với sự bùng nổ của cuộc cách mạng công nghệ thông tin đặt biệt là nền công nghiệp phần mềm Xu hướng “Toàn cầu hóa” diễn ra một cách mạnh mẽ đến mọi mặt hoạt động kinh tế xã hội của hầu khắp các quốc gia trên thế giới Công nghệ thông tin đang được ứng dụng mạnh mẽ vào đời sống kinh tế xã hội, nó ngày càng đóng một vai trò ngày càng quan trọng Nó thổi vào nền kinh tế thế giới một luồng sinh khí mới, nhanh chóng lan toả, mang đến những cơ hội đồng thời cũng là những thử thách to lớn không chỉ đối với những nước có nền kinh tế công nghiệp phát triển mà còn đối với những nước đang phát triển đang trên con đường công nghiệp hóa và hiện đại hóa như Việt Nam

Tuy nhiên đi đôi với sự phát triển thì phần mềm cũng đem lại không ít những khó khăn cần được giải quyết Phần mềm ngày càng trở nên phức tạp quá mức và dường như đang vượt khỏi tầm kiểm soát của các mô hình hiện có (chẳng hạn như OPP,COM DCOM ) Yêu cầu đặt ra trước mắt là chúng ta phải tổ chức phần mềm theo một cách đơn giản đến mức có thể Một thực trạng đáng buồn là có 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ì cao chót vót, đặ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ư vấn đề này đã vượt quá khả năng xử lý của các kiến trúc truyền thống Điều này một phần 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 Những yêu cầu truyền thống đặt ra đối với tổ chức CNTT vẫn còn đó, cùng lúc phải đáp ứng nhanh chóng các yêu cầu mới, đòi hỏi phải liên tụ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

Hầu như mọi tổ chức mọi công ty đều phải đối mặt với vấn đề tích hợp vì nhiều lý

do, đặt biệt là trong thị trường ngày nay, sự thay đổi luôn diễn ra với tốc độ cao và thường xuyên, các nghiệp vụ các chính sách luôn bị thay đổi và điều chỉnh liên tục

để phù hợp với xu hướng thị trường Sự thay đổi liên tục này đòi hỏi phần mềm phải có một cấu trúc mềm dẻo đễ tách rời cũng như dễ tích hợp

Hầu hết các doanh nghiệp các tổ chức ngày nay đều sở hữu những ứng dụng với những kiến trúc và công nghệ khác nhau Ở thập kỷ trước thì hầu hết các doanh nghiệp chọn giải pháp mua trọn gói một vài phần mềm lớn với các 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ì vào lúc này thì kết hợp các module t nhiều nhà cung cấp khác nhau là một việc làm bất khả thi Ngày nay các doanh nghiệp thường không chọn giải pháp mua trọn gói như vậy vì thường không linh hoạt và chi phí rất cao Các doanh nghiệp đang cố gắng tìm cách kết hợp những ứng dụng cũ sao cho thỏa mãn yêu cầu nghiệp vụ, đó chỉ là việc tổng hợp những thông tin được trả về, giải pháp này sẽ vấp phải một số khó khăn như:

 Không đáp ứng đủ các yêu cầu nghiệp vụ

 Phải làm việc với nhiều nhà cung cấp khác nhau đó là chưa kể các đối thủ

cạnh tranh và các quy trình phức tạp

 Phải làm việc với nhiều dạng dữ liệu khác nhau

 Các yêu cầu nghiệp vụ thay đổi liên tục đòi hỏi phải tốn chi phí cho việc

cập nhật và tích hợp liên tục

 Việc cải tiến và thay đổi phải phụ thuộc vào các thành phần liên quan

 Vấn đề bảo mật cũng là một ảnh hưởng lớn khi đòi hỏi phải tích hợp t

nhiều hệ thống khác nhau với chế độ bảo mật khác nhau

 Khó khăn trong việc quản lý các quy trình nghiệp vụ vì chúng được tích

hợp t nhiều module với nhiều kiến trúc khác nhau

Đa phần những khó khăn trên xuất phát t các nguyên nhân: sự phức tạp trong cấu trúc phần mềm, thiếu tính linh hoạt trong việc thiết kế hệ thống, và không có tính liên kết giữa các ứng dụng cùng loại

Chúng ta đã có các kiến trúc như OOP (Object Oriented Programming), COM/DCOM (Distributed Common Object Model), CORBA (Common Object Request Broker Architecture) và nhiều phương thức tích hợp ứng dụng nhanh và tốt hơn Thế nhưng vẫn chưa có giải pháp nào hoàn chỉnh Giờ đây, SOA đang được xem là 'ứng cử viên sáng giá' có thể đảm nhận trọng trách này và được kỳ vọng tạo

nên cuộc cách mạng trong kiến trúc phần mềm

1.2 Giới thiệu về kiến trúc hướng dịch vụ(SOA)

Hình 1.1-Mô hình cộng tác SOA

Nhà cung cấp (Service provider) dịch vụ 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 Service (Service registry) Người sử dụng

(Service 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ải 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ó

Dịch vụ là yếu tố then chốt trong SOA 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 qui trình nghiệp vụ nào đó Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối 'mềm dẻo' với nhau (nghĩa là một ứng dụng có thể 'nói chuyện' 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 SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui 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

Thiết kế SOA 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ụ Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tă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ụ

Ưu điểm quan trọng nhất của SOA là khả năng kết nối 'mềm dẻo' (nhờ sự chuẩn hóa

giao tiếp) hay còn gọi là “Loose Coupling”[ 31 ] và tái sử dụng Các dịch vụ có thể

được sử dụng với trình client chạy trên nền tảng bất kỳ và được viết với ngôn ngữ bất kỳ (Ví dụ, ứng dụng Java có thể liên kết với dịch vụ web NET và ngược lại) SOA dựa trên hai nguyên tắc thiết kế quan trọng:

 Mô-đun: Tách vấn đề lớn thành nhiều vấn đề nhỏ

 Đóng gói: Che đi dữ liệu và lô-gic trong t ng mô-dun (hay 'hộp đen') đối với truy cập t ngoài

1.2.2 Sự khác nhau giữa dịch vụ web và kiến trúc hướng dịch vụ

Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ Điều này có thể làm bạn liên tưởng đến một công nghệ được đề cập nhiều gần đây: Dịch vụ web Dịch vụ web cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp SOA và dịch vụ web trông có vẻ giống nhau nhưng chúng không phải là

một[ 8 ]

Về cơ bản, SOA là kiến trúc phần mềm phát xuất t định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực giao tiếp và phương thức gọi giao tiếp Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi 'kiến trúc định hướng giao tiếp' thích hợp hơn cho SOA Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách thức yêu cầu - đáp trả Ngay cả với yêu cầu dịch vụ 1 chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích t một phần mềm này đến một phần mềm khác Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ

Định nghĩa cơ bản của dịch vụ web dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Webservices Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery ang Integration), cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn (Hiện tại thì các công nghệ này làm việc tốt và hiệu quả)

Rõ ràng, theo định nghĩa thì dịch vụ web là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm Dịch vụ web đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải dịch vụ web (và không phải tất cả dịch vụ web đều có kiến trúc SOA) Tuy vậy, SOA và dịch vụ web có mối quan hệ tương hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công

1.2.3 Bốn nguyên tắc chính trong kiến trúc hướng dịch vụ

 Sự rõ ràng về ranh giới giữa các dịch vụ

Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao tiếp Thành phần giao tiếp này sẽ qui định về những định dạng thông điệp sử dụng trong quá trình trao đổi : thông điệp nào sẽ được chấp nhận và thông điệp nào sẽ không

được xử lý[ 6 ] Và đây chính là cách duy nhất để các đối tượng bên ngoài có thể

truy cập thông tin và chức năng của dịch vụ Ta chỉ cần gửi các thông điệp theo các định dạng đã được định nghĩa trước mà không cần phải quan tâm đến cách xử lý của dịch vụ như thế nào (môi trường thực thi, ngôn ngữ lập trình ) Điều này đạt được do sự tách biệt giữa thành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ

 Các dịch vụ tự hoạt động

Các dịch vụ cần phải được triển khai và hoạt động như những thực thể độc lập mà không lệ thuộc vào một dịch vụ khác Dịch vụ phải có tính bền vững cao, nghĩa là

nó sẽ không bị sụp đổ khi có sự cố Để thực hiện điều này, dịch vụ cần duy trì đầy

đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động trong trường hợp một dịch vụ cộng tác bị hỏng; và để tránh các cuộc tấn công t bên ngoài (như gửi thông điệp lỗi, hay gửi thông điệp ồ ạt) bằng cách sử dụng các

kỹ thuật về an toàn, bảo mật [ 6 ]

Đây chính là ý nghĩa của khái niệm „loose coupling service‟ mà ta đã đề cập trong

định nghĩa SOA

 Các dịch vụ chia sẽ lược đồ

Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoài, và

hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.) Như thế hệ thống của ta sẽ

có tính liên kết và khả năng dễ mở rộng

 Tính tư ng thích giữa các dịch vụ

Điều này nghĩa là, một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các chính sách (policiy) và yêu cầu (requirements) của dịch vụ đó như là

mã hóa, bảo mật Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai

thay đổi công nghệ theo thời gian của phần mềm

hơn mà không làm thay đổi yêu cầu

 Mức độ coupling tăng dần khi 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ệ giữa hai bên càng chặt

 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ả kết quả về thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp

được xử lý xong Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch

vụ chuyển 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 xử 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 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 này 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, các nhân viên phát triển phần mềm, nhóm điều hành và nhóm 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

 Coarse granularily

Khái niệm granularity trong dịch vụ có thể hiểu theo hai cách Đầu tiên, nó được hiểu trong phạm vi toàn bộ kiến trúc cài đặt của dịch vụ Thứ hai, nó được hiểu trong phạm vi t ng phương thức của t ng interface triển khai Mức độ granularity cũng được hiểu ở mức tương đối Ví dụ, nếu một dịch vụ cài đặt tất cả chức năng của một hệ thống ngân hàng, chúng ta xem nó là coarse-grained Nếu nó hỗ trợ chỉ chức năng kiểm tra thể tính dụng, chúng ta lại xem nó là fine-grained

Trước khi có kiến trúc thành tố và dịch vụ, các hệ thống phân tán chủ yếu dựa trên ý tưởng phân tán đối tượng Những hệ thống phân tán đối tượng chứa bên trong nó nhiều đối tượng fine-grained trao đổi thông tin với nhau qua mạng Mỗi đối tượng

có những ràng buộc với nhiều đối tượng khác bên trong hệ thống Do truy cập đến một đối tượng phải qua nhiều trung gian mà hiệu quả đạt được không cao nên

khuynh hướng thiết kế hệ thống phân tán đối tượng đang dần chuyển sang thiết kế các coarser-grained interface

 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 (Interoperability), 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 interface 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 Interoperability is achieved 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 sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống Ví dụ Webservice là một đặc tả trung gian cho giao tiếp giữa các hệ thống,

JAX-RPC và JAXM chuyển đối tượng dạng Java thành SOAP.[ 6 ]

 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ề dịch vụ nào thoả yêu cầu tìm kiếm Ví

dụ, một hệ thống chuyển khoảng (consumer) yêu cầu một registry tìm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng Registry trả về một tập các entry 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 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

 Tự phục hồi

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ế nao 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 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ụ 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 đó ứ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 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 interface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một interface 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 chỉ tương tác với 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ụ

1.2.5 Lợi ích mà kiến trúc hướng dịch vụ mang lại

Đầu tiên hãy đặt lợi ích của SOA trong triển vọng SOA là một lưỡi hái mà nó thái mỏng sự phức tạp và sự dư th a Nếu công ty của bạn không lớn hay phức tạp, ví

dụ hơn 2 hệ thống cơ bản đòi hỏi vài cấp tích hợp – không có vẻ như SOA sẽ mang lại nhiều lợi ích Thất bại trong tất cả các quảng cáo thổi phồng sự thật về SOA hiện nay là thực tế mà phương pháp luận phát triển này bản thân nó không đem lại lợi

ích thực – đó là những tác động mà nó có được trên một cơ sở hạ tầng dư th a và phức tạp, cái cơ sở mà đem lại phần thưởng Các kiến trúc sư nói có nhiều công việc có liên quan đến việc tạo một ứng dụng hướng dịch vụ tốt hơn là có một sự tích hợp phần mềm ứng dụng truyền thống hiện có (Các cuộc điều tra cho thấy SOA đang được sử dụng cho việc tích hợp ứng dụng truyền thống ở hầu hết các công ty)

Vì vậy thực tế có một chi phí bổ sung sinh ra do việc phát triển SOA trả trước Vì

có một lợi ích t công việc đó nên nó phải loại bỏ công việc ở nơi nào khác bởi vì

phương pháp luận này trong nội tại bản thân nó không hề tạo lợi ích kinh doanh[ 8

] Trước khi xem xét xem liệu SOA có lợi ích hay không, đầu tiên bạn phải quyết định xem liệu có sự dư th a nào không, thật tồi tệ nếu các ứng dịng được tích hợp

mà có thể được cố kết hay bị loại bỏ là kết quả của việc chấp nhận SOA Trong trường hợp này thì có vài lợi ích tiềm năng

Để nhận được bức tranh toàn cảnh những lợi ích được bán kèm với SOA, bạn phải quan sát nó ở 2 mức: đầu tiên, là những ưu điểm (lợi ích) sách lược của sự phát triển hướng dịch vụ và thứ hau đó là những ưu điểm của SOA như là một chiến dịch kiến trúc tổng thể

1.2.6 Ưu điểm và khuyết điểm của hệ thống SOA

Đối với nhà phát triển dịch vụ[ 8 ]:

 Tái sử dụng phần mềm Nếu gói mã mà tạo thành một dịch vụ có quy mô và kích thức phù hợp sau đó nó có thể được tái sử dụng cho lần kế tiếp, một đội phát triển cần chức năng cụ thể đó cho một ứng dụng phần mềm mới mà nó mong muốn xây dựng Họ không cần biết bất cứ thứ gì về việc mã được gói chặt như thế nào hay nó có nguồn gốc t đâu Tất cả những thứ mà họ cần làm đó là xây dựng một sự kết nối đến mã đó

 Trong một công ty mà thường xuyên xây dựng những hệ thống mới dựa trên những chức năng tương tự - ví dụ một công ty bảo hiểm với nhiều bộ phận, mỗi một bộ phận đảm nhận cho các sản phẩm khác nhau hay một công ty thường xuyên thu được những công ty mới – thời gian được tiết kiệm thông qua việc phát triển, kiểm thử và tích hợp đó với chức năng phần mềm nhỏ bé tương tự đó

có thể thêm vào Năng suất gia tăng Nếu các lập trình viên tái sử dụng các dịch

vụ điều đó có nghĩa là các dự án phần mềm có thể tiến xa hơn và đội phát triển tương tự có thể tiếp tục nhiều dự án hơn Sự tích hợp trở nên rẻ hơn nhiều( theo ước tính của Gartner thì ít nhất sẽ rẻ hơn 30%) và cũng nhanh hơn, chu trình phát triển các dự án mới sẽ giảm bớt thời gian đi vài tháng

 Linh hoạt: Thậm chí nếu các dịch vụ sẽ không được tái sử dụng, thì họ có thể đưa

ra nhiều giá trị nếu họ làm cho hệ thống CNTT chỉnh sửa dễ dàng hơn Ví dụ tại website ProFlowers.com có nhiều ứng dụng dư th a hoặc tình trạng kêu la của nhiều đơn vị doanh nghiệp Tuy nhiên theo ông Kevin Hall giám đốc CNTT của ProFlowers thì việc phân chia quá trình đặt hoa thành các dịch vụ riêng rẽ có nghĩa là mỗi một cấu phần có thể được tách biệt và được thay đổi như mong muốn để xử lý các cụm hoa theo yêu cầu nảy sinh xung quanh các ngày nghỉ Khi ProFlowers đã có một ứng dụng nguyên khối, đơn lẻ xử lý quá trình đó thì một

sự thay đổi đơn lẻ trong quy trình đó hay một sự gia tăng số lượng giao dịch (nói vào ngày Lễ tình nhân) đồng nghĩa với việc xé nhỏ toàn bộ hệ thống và xây dựng lại hệ thống đó

Đối với các doanh nghiệp và các tổ chức sử dụng dịch vụ[ 8 ]:

 Định hướng kinh doanh: SOA là một bức tranh lớn của tất cả các quy trình kinh doanh và dòng dịch chuyển trong một công ty Điều đó có nghĩa là người làm kinh doanh lần đầu tiên có thể mường tượng toàn bộ các quy trình kinh doanh được xây dựng theo quan điểm của công nghệ Khi các dự án CNTT được đặt theo quan điểm của các hoạt động và các quy trình kinh doanh hơn là các ứng dụng phần mềm phức tạp, những người làm kinh doanh có thể đánh giá và ủng

hộ các dự án CNTT tốt hơn Tầm nhìn vĩ đại đối với SOA là khi dịch vụ CNTT toàn diện kích hoạt được các quy trình lớn của một doanh nghiệp, người làm kinh doanh một ngày nào đó sẽ có thể nắm quyền chỉnh sửa, pha trộn và kết hợp nhịp nhàng, ăn khớp các dịch vụ khác nhau đó với nhau thành những sự kết hợp quy trình mới trên chính doanh nghiệp của họ Tuy vậy tầm nhìn này còn là viễn cảnh trong nhiều năm

 Một cách thức tốt hơn để nâng cao vị thế CNTT: Kiến trúc doanh nghiệp là khái niệm mà đã khá lâu người ta không dám nói đến tên của nó Kiến trúc doanh nghiệp luôn luôn là một công việc lớn, khó khăn và đắt đỏ còn chỉ số đầu tư hiệu của (ROI) của nó thường không rõ ràng đối với doanh nghiệp đó Việc tiêu chuẩn hóa, ánh xạ và kiểm soát các tài sản CNTT không làm cho doanh nghiệp đó linh động hơn, có năng lực hơn và nhiều lợi nhuận hơn Kết quả là, những nỗ lực kiến trúc CNTT thường thất bại hoặc trở nên hoàn toàn hướng về CNTT SOA cung cấp giá trị cho doanh nghiệp đó mà với kiến trúc doanh nghiệp cũ thì chỉ là những lời “hứa hươu, hứa vượn” Tái sử dụng, năng suất và sự nhanh nhạy trong CNTT thông tin được nâng cao và một cơ sở hạ tầng phần mềm ăn khớp với các quy trình kinh doanh cụ thể là sự hấp dẫn để bán một nỗ lực kiến trúc doanh nghiệp cho doanh nghiệp đó Nhưng phải nhớ rằng kiến trúc ấy không giành cho tất cả mọi người Các công ty nhỏ hoặc các công ty phân tán lớn có thể không thể điều chỉnh được một đội ngũ nhân sự tập chung gồm các giám đốc dự án, các kiến trúc sư và các lập trình viên

1.2.7 u hướng ứng dụng SOA hiện nay

Hiện nay thì IBM là một trong những nhà cung cấp dịch vụ lớn trên thế giới Các sản phẩm của IBM triển khai thực hiện SOA và mô hình lập trình SOA ngày càng nhiều hơn Các lập trình viên xây dựng các dịch vụ, sử dụng các dịch vụ và phát

triển các giải pháp để kết hợp các dịch vụ[ 14 ]

Hầu hết các tài liệu về các dịch vụ web tập trung chủ yếu vào các giao diện dịch vụ

và việc sử dụng chúng Để bổ sung đầy đủ các tiêu chuẩn giao diện và các cách làm thực tế tốt nhất, IBM giới thiệu một mô hình lập trình để triển khai thực hiện các dịch vụ và lắp ráp chúng thành các giải pháp Bằng việc mở rộng khả năng tiếp cận các nền tảng phần mềm của IBM đến cộng đồng những người sử dụng rộng lớn hơn, bao gồm cả các nhà lập trình không truyền thống Mô hình này cung cấp các kiểu thành phần mới phù hợp với vai trò, các mục tiêu, các kỹ năng và khung thiết

kế của người sử dụng Các kiểu thành phần này cho phép áp dụng các công cụ phát

triển trực quan hơn Một chủ đề chính khác nữa là tăng khả năng tiêu thụ thông qua

bộc lộ dần t ng bước các đặc tính và các khả năng của mô hình lập trình này[ 14 ]

Hình 1.2-Kiến trúc sản phẩm của IBM

Các sản phẩm hỗ trợ khung nhìn IBM về một SOA được chia thành hai thể loại lớn: các điểm cuối (endpoints) dịch vụ và kết cấu truyền dẫn thông báo liên kết chúng với nhau Kiến trúc chung này được nhiều sản phẩm góp phần vào, không một sản phẩm riêng biệt nào trong số này có thể là phương tiện chuyển tải duy nhất cho SOA của IBM được minh họa trong Hình 1.2

Ở vị trí trung tâm là một ESB cung cấp kết nối giữa các dịch vụ ESB này là dịch vụ

đa giao thức, hỗ trợ kiểu truyền thông “điểm-đến-điểm” và “đăng ký-xuất bản” (publish-subscribe) và trung gian hòa giải để xử lý các thông báo ngay trên đường

đi IBM WebSphere MQ, IBM WebSphere MQ Integrator Broker và hỗ trợ WebSphere cho các dịch vụ web và các dịch vụ Thông báo của Java (JMS), tất cả đều thuộc thể loại đầu tiên

Ngoài IBM thì hãn Motorola cũng đang tích cực triển khai các hệ thống của mình,tại diễn đàn của InfoWorld, đại diện hãng Motorola cho biết sau ba năm xây dựng

SOA họ đã triển khai được 180 dịch vụ và năm sau con số này sẽ tăng lên 1.000 Lợi ích mà SOA mang lại là sự tích hợp dữ liệu đơn giản thông qua XML, chi phí

thấp, tốc độ cao, đáp ứng nhanh những yêu cầu của doanh nghiệp[ 7 ] Theo chuyên

gia Graham của hãng BEA Systems, trong phạm vi một doanh nghiệp, cơ hội rộng

mở mà SOA tạo ra sẽ cho phép "các công ty phát minh ra được những điều thú vị, khách hàng có cơ hội làm được nhiều điều mà ta không thể tưởng tượng nổi Với dịch vụ web, bạn có thể công khai các quy trình hoạt động Đó là một "nguồn mở" của ứng dụng này".Tuy nhiên, việc triển khai SOA vẫn còn gặp nhiều rào cản Toby Redshaw, Phó chủ tịch Motorola, cho biết việc triển khai SOA cần những yếu tố quan trọng như UDDI nói trên (Universal Description Discovery and Integration),

sự giám sát, quản lý và an ninh cho các dịch vụ web Ngoài ra, đó là sự không đồng nhất của nền xử lý, vấn đề lưu dữ liệu Mark Carges, chuyên gia của BEA Systems, nhận định rằng thức đo thật sự của SOA phải là khả năng tái sử dụng dịch vụ vì không ai muốn viết lại mã lệnh chương trình đến lần thứ hai

Một cuộc nghiên cứu gần đây của Forrester cho thấy việc ứng dụng SOA ở khu vực châu Á-Thái Bình Dương đã tăng 44% Theo số liệu của Oracle, ở Việt Nam nhu cầu về nền tảng công nghệ SOA của Oracle (Oracle SOA Technologies) rất lớn Để giúp khách hàng của Oracle ở Việt Nam đưa ra được các quyết định quan trọng về CNTT, Oracle đã và đang chia sẻ thành công việc triển khai các ứng dụng sử dụng nền tảng công nghệ Oracle SOA trên toàn thế giới để họ hiểu được những lợi ích

mà họ có thể đạt được Các doanh nghiệp trong nước thường muốn biết SOA mang lại những gì cho các doanh nghiệp tương tự trên thế giới

Việt Nam và các nước khác trong khu vực Đông Nam Á rất quan tâm đến việc tìm hiểu kỹ càng về SOA và đã thực hiện những dự án SOA đầu tiên Rõ ràng là những thành công của các dự án SOA ban đầu này đã cho thấy SOA không chỉ là công nghệ Có rất nhiều khách hàng bàn về việc thay đổi phương pháp thực hiện dự án để đạt được những lợi ích lớn hơn t SOA vì họ đã nhìn thấy sự liên hệ giữa phương pháp và kết quả sẽ đạt được

Ngành viễn thông, một ngành có những hệ thống thông tin phức tạp nhất trên thế giới, đã thể hiện mình là một trong những ngành triển khai SOA thành công nhất Ngành dịch vụ tài chính hiểu rất rõ về các dịch vụ và quy trình nghiệp vụ đang ngày càng tiếp cận với SOA cho phép họ phát triển các dịch vụ mới nhanh hơn Chúng ta cũng đã đƣợc thấy những lợi ích to lớn trong những ngành dịch vụ công, bán lẻ cũng nhƣ lĩnh vực sản xuất

Tóm lại SOA sẽ giúp cho công việc phát triển phần mềm trở nên dễ dàng và nhanh chóng hơn „Đ ng tốn công chế tạo lại bánh xe', hãy kết hợp những linh kiện (dịch vụ) có sẵn và bổ sung những gì cần thiết để 'lắp ráp' nhanh chóng 'chiếc xe' đƣa bạn đến đích Đó là triết lý của SOA! Ngay t bây giờ bạn có thể áp dụng triết lý này cho các hệ thống phần mềm của mình để sẵn sàng cho những nhu cầu của ngày mai.‟

1.3 Giới thiệu đề tài nghiên cứu và phát triển BPEL Designer với công nghệ JAVAFX

1.3.1 Lý do thực hiện đề tài nghiên cứu và phát triển BPEL Designer

Với sự phát triển và ứng dụng mạnh mẽ của công nghệ SOA vào các quy trình nghiệp vụ và đang mang lại một lợi ích lớn cho các tổ chức và doanh nghiệp.Đi đôi với kiến trúc SOA là sự phát triển của các ngôn ngữ mô hình hóa các quy trình nghiệp vụ nhƣ:XPDL, BPML,BPEL… Nó giúp cho các lập trình viên và các nhà

sử dụng dịch vụ đơn giản hóa việc tổng hợp cũng nhƣ xây dựng các dịch vụ riêng cho mình Chúng không phải là một ngôn ngữ đƣợc sử dụng cho việc phân tích thiết

kế và đƣợc thể hiện bằng một bộ cú pháp xml và có các giao thức riêng của mình, chúng không có một ngôn ngữ riêng cụ thể nào cả mà chỉ đƣợc thể hiện qua các giao diện đồ họa, cũng không có một chuẩn ký hiệu chung cho các ngôn ngữ này.Trong các ngôn ngữ trên thì BPEL là ngôn ngữ đƣợc sử dụng rộng rãi nhất.T năm 2003 tổ chức OASIS đã mua bản quyền và chịu trách nhiệm cho sự phát triển của ngôn ngữ BPEL Để hỗ trợ cho việc thể hiện các ngôn ngữ này thì các công cụ desingner đƣợc phát triển ra nhƣ là một tất yếu Có rất nhiều Design Engine đƣợc

phát triển bởi nhiều tổ chức khác nhau như Oracle SOA Suite, PPEL Eclipse Plugin… hỗ trợ mạnh mẽ cho việc tổng hợp và xây dựng các dịch vụ

Tuy nhiên với sự phát triển mạnh mẽ của của internet và các công nghệ web đã là cho nhu cầu sử dụng và chia sẽ các ứng dụng thông qua môi trường web như là một nhu cầu tất yếu Vì vậy nhu cầu xây dụng các công cụ hỗ trợ cho việc tổng hợp và thiết kế các dịch vụ trên môi trường web là một nhu cầu có thật và hiển nhiên Vấn

đề đặt ra là làm sao các nhà sử dụng cũng như cung cấp dịch vụ có thể tạo ra một quy trình dịch vụ cũng như tiếp cận các dự án của mình một cách nhanh nhất vào mọi thời điểm và mọi nơi có kết nối internet mà không cần phải cài đặt sẵn các chương trình desingner

Xuất phát t vấn đề đó chúng em thực hiện nghiên cứu đề tài :” NGHI N C U VÀ PHÁT TRIỂN BPEL DESIGNER SỬ DỤNG CÔNG NGHỆ JAVAFX”.Chương trình được phát triển trên môi trường web với công nghệ Javafx một trong những công nghệ mới hiện nay

1.3.2 Mục tiêu của đề tài

Với nội dung có liên quan đến dịch vụ web và các kiến trúc cũng như công cụ của

nó thì chúng em đã đặt ra các vấn đề sau đây cần phải nghiên cứu:

 Tìm hiểu về kiến trúc hướng dịch vụ: SOA

 Tìm hiểu về ngôn ngữ mô hình hóa BPEL

 Nghiên cứu về ODE cho việc thực thi các tiến trình nghiệp vụ

 Tìm hiểu về công nghệ Java FX để xây dựng Bpel Designer

 Tìm hiểu về UDDI cho việc tìm kiếm và tổng hợp các WebService

 Xây dựng BPEL Designer trên môi trường web cho phép người dùng xây dựng tìm kiếm , quản lý, lưu trữ cũng như thực thi các tiến trình nghiệp vụ

1.3.3 Các nghiên cứu liên quan đến BPEL-Designer và SOA trong khoa công nghệ thông tin đại học Khoa Học Tư Nhiên

Trong khoa công nghệ thông tin, đại học Khoa Học Tự Nhiên đã có một số đề tài nghiên cứu về SOA như:

 Đề tài “nghiên cứu kiến trúc hướng dịch vụ (SOA) và ứng dụng” [ 2 ] của hai sinh viên: Hồ Bảo Thanh và Nguyễn Hoàng Long thực hiện năm 2005 là đề tài luận văn đầu tiên nghiên cứu về SOA tại khoa Mục tiêu của đề tài là nghiên cứu các vấn đề có liên quan đến SOA và ứng dụng SOA để xây dựng một tiến trình nghiệp vụ

 Đề tài “Nghiên cứu kiến trúc hướng dịch vụ IBM và phát triển ứng dụng” của hai sinh viên: Nguyễn Hoàng Anh và Hoàng Vũ Tuấn thực hiện năm 2007 là đề tài nghiên cứu về kiến trúc hướng dịch vụ của hãng IBM và sử dụng các công cụ của IBM để phát triển ứng dụng

 Đề tài “Xây dựng môi trường thiết kế và vận hành SOA trên Web” của hai sinh viên: Trần Quang Duy và Nguyễn Trần Kha đã xây dựng một công cụ thiết kế SOA thực thi trên môi trường web

 Đề tài :” Nghiên cứu và xây dựng hệ thống thiết kế và vận hành quy trình tổng hợp dịch vụ Web ngữ nghĩa” cùa hai sinh viên Phan Lê Sang và Trần Ngọc Tịnh năm 2009,

Đề tài này được kế th a và phát triển các kiến thức về SOA và BPEL t các đền tài nêu trên

Chư ng 2 PH T TRIỂN V THỰC THI C C QUY TRÌNH NGHIỆP V VỚI WS-BPEL 2.0 V APACH O

 ội dung: Trong chương này chúng tôi xin giới thiệu tới các bạn ngôn ngữ mô hình hóa tiến trình dịch vụ và đư c d ng đ phát tri n các ng dụng lớn và ph c tạp hiện nay chúng tôi sẽ giới thiệu chi tiết về các thành phần c ng như các khái niệm trong cách xây dựng một tiến trình đơn giản.Qua chương này chúng tôi c ng xin giới thiệu tới các bạn một số khái niệm về Apache ODE bao gồm: cấu trúc cách cài đặt cách tri n khai một quy trình nghiệp vụ lên Apache ODE

2.1 Tổng quan về ngôn ngữ P L

2.1.1 Giới thiệu

BPEL (Business Process Execution Language) là một ngôn ngữ dùng để hổ trợ phát triển các ứng dụng phức tạp, lớn đòi hỏi phải tổng hợp nhiều dịch vụ web khác nhau Phiên bản BPEL đầu tiên (BPEL 1.0) ra đời vào tháng 07 2002 Vào tháng

05 2003 BPEL 1.1 ra đời dựa trên việc kết hợp BPEL 1.0 với một số ngôn ngữ khác

và được đệ trình lên tổ chức OASIS (một tổ chức chuyên đưa ra các chuẩn thông tin) Tháng 04 2007 OASIS chuẩn hóa BPEL và đổi tên thành WS-BPEL 2.0 được

dùng cho đến nay[ 3 ]

BPEL không chỉ cho phép bạn mô tả và xử lý luồng công việc bằng cách sử dụng trình soạn thảo đồ họa thân thiện với người dùng Ngoài ra BPEL còn định nghĩa các cách quản lý các sự kiện và ngoại lệ, cơ chế bảo toàn dữ liệu khi có ngoại lệ xảy

ra BPEL hoạt động dựa trên nguyên tắc gửi các thông điệp dạng XML đến một dịch vụ khác, thao tác trên cấu trúc XML, nhận các thông điệp XML (đồng bộ hay không đồng bộ) t các service bên ngoài Nó phụ thuộc vào bốn chuẩn XML cơ bản được xem như là các đặt tả để thực thi một tiến trình BPEL: WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing Hình 2.1 thể hiện một tiến trình BPEL trong thực

tế

Hình 2.1- Ví dụ về một tiến trình BPEL 2.1.2 Nguyên tắt hoạt động của một tiến trình P L

Trong số các đặc tả: WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing trên thì WSDL đóng vai trò cốt lõi trong một tiến trình của BPEL Cốt lõi của BPEL là khái niệm peer-to-peer là sự tương tác giữa các dịch vụ web được mô tả trong WSDL Một tiến trình BPEL đặt tả làm thế nào để phối hợp giữa các dịch vụ khác nhau và kết hợp các dịch vụ đó lại thành một tiến trình hoàn chỉnh Điều này có nghĩa một tiến trình BPEL được định nghĩa hoặc cung cấp t một hoặc nhiều đặc tả WSDL khác nhau, và cung cấp một đặc tả của riêng nó về quá trình tổng hợp các

dịch vụ này[ 3 ]

Tuy nhiên có một vấn đề đặt ra là: làm thế nào để tiến trình BPEL có thể phân biệt được t ng service mà nó tổng hợp trên đó để mà tương tác trên những service đó Cũng như mỗi service được sử dụng trong tiến trình BPEL có vai trò như thế nào trong toàn bộ tiến trình… Để giải quyết vấn đề này BPEL đã đưa ra hai khái niệm

mới là partnerLinkType và partnerLink[ 28 ]

Hình 2.2- Quan hệ giữa partnerLink và partnerLinkType

 PartnerLinkType:

Một partnerLinkType mô tả quan hệ “đối thoại” giữa hai service bằng cách định nghĩa các role (đóng vai trò của mỗi service) và chỉ định portType để nhận thông điệp

 PartnerLink:

Các service trong tương tác của tiến trình nghiệp vụ được mô tả là các PartnerLinkType trong BPEL Mỗi một PartnerLink được mô tả bằng một PartnerLinkType, được đặt tên để đại diện cho tất cả các tương tác thông qua PartnerLink đó Nếu PartnerLinkType tương ứng chỉ có một role thì role này sẽ mặc định được gán cho thuộc tính myRole của PartnerLink, nhưng nếu có nhiều role thì phải chỉ ra để cho biết PartnerLink này hoạt động với PortType nào Ví dụ về PartnerLink:

< partnerLink name ="ncname" partnerLinkType ="qname"

myRole ="ncname"? partnerRole ="ncname"?

Kỹ thuật dùng partnerLink chẳng những giải quyết được vấn đề trên mà còn giúp các BPEL service có thể dễ dàng tích hợp với các bộ phận khác trong kiến trúc tổng thể của SOA Cụ thể: khi ta định nghĩa một partnerLink, chúng ta sử dụng thuộc tính myRole để chỉ vai trò của chính BPEL Webservice Ngược lại, thuộc tính partnerRole được dùng để chỉ vai trò của một service bên ngoài

2.1.3 Cấu trúc của một tiến trình P L

Cấu trúc của một tiến trình BPEL được mô tả trong tập tin BPEL như sau:

< bpel:process name ="helllo"

< bpel:import location ="aloArtifacts.wsdl"

Bảng 2.2-Cấu trúc file BPEL

Một tiến trình BPEL là một mô tả dưới dạng tài liệu XML Quy trình được mô tả trong BPEL giao tiếp với trang web và các dịch vụ trao đổi tài liệu XML(SOAP)