Nghiên cứu ứng dụng kiến trúc SOA trong mô hình ứng dụng doanh nghiệp

Dịch vụ là yếu tố then chốt trong SOA, nó giúp cho các doanh nghiệp có thể tích hợp các thành phần hiện có vào các ứng dụng mới và các thành phần này có thể được chia sẻ hoặc tái sử dụng

LỜI CAM ĐOAN

Tôi – Phạm Đức Thọ, học viên lớp Cao học CNTT 2010 – 2012 Trường Đại học Bách khoa Hà Nội – cam kết Luận văn tốt nghiệp là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của TS Tạ Tuấn Anh, Viện Khoa học và công nghệ Việt Nam

Các kết quả trong Luận văn tốt nghiệp là trung thực, không sao chép toàn văn của bất kỳ công trình nào khác

Hà Nội, ngày 10 tháng 03 năm 2012

Học viên: Phạm Đức Thọ

Lớp: 10BCNTT-HV

LỜI CẢM ƠN

Tôi xin bày tỏ lòng biết ơn sâu sắc tới thầy giáo, TS Tạ Tuấn Anh, Viện Khoa học và công nghệ Việt Nam, đã khuyến khích và rất tận tình hướng dẫn tôi trong suốt quá trình thực hiện luận văn Nhờ sự quan tâm chỉ bảo và những ý kiến đóng góp quý báu của thầy, tôi mới có thể hoàn thành luận văn này

Tôi xin chân thành cảm ơn tập thể các thầy, cô giáo trường Đại học Bách Khoa Hà Nội nói chung và Viện Công Nghệ Thông Tin và Truyền Thông nói riêng

đã tận tình giảng dạy truyền đạt cho tôi những kiến thức, kinh nghiệm quý báu trong suốt những năm học vừa qua

Tôi cũng xin cảm ơn các giảng viên đồng nghiệp ở trường Đại học Hùng Vương đã tạo điều kiện về thời gian để tôi có thể học tập và hoàn thành luận văn

Cuối cùng tôi xin chân thành cảm ơn gia đình, người thân đã hết lòng giúp đỡ,

hỗ trợ về vật chất lẫn tinh thần giúp tôi yên tâm học tập và nghiên cứu trong suốt quá trình học tập và thực hiện luận văn

MỤC LỤC

LỜI CAM ĐOAN 1

LỜI CẢM ƠN 2

MỤC LỤC 3

DANH MỤC KÝ HIỆU, CHỮ VIẾT TẮT 6

DANH MỤC BẢNG 7

DANH MỤC HÌNH 8

MỞ ĐẦU 11

1 Lý do chọn đề tài 11

2 Mục đích, phạm vi nghiên cứu 11

3 Đối tượng nghiên cứu 12

4 Phương pháp nghiên cứu 12

5 Nhiệm vụ nghiên cứu 12

CHƯƠNG 1: HỆ THỐNG THÔNG TIN DOANH NGHIỆP THEO MÔ HÌNH KIẾN TRÚC HƯỚNG DỊCH VỤ 13

1.1 Hệ thống thông tin doanh nghiệp 13

1.1.1 Khái niệm 13

1.1.2 Phân loại các HTTT dùng trong doanh nghiệp 13

1.2 Mô hình kiến trúc hướng dịch vụ ứng dụng trong HTTT doanh nghiệp 15

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

1.2.2 Kiến trúc của SOA 16

1.2.3 Các công nghệ được áp dụng 21

1.2.4 Lợi ích khi sử dụng mô hình SOA trong thiết kế và xây dựng HTTT doanh nghiệp 30

CHƯƠNG 2: MÔ HÌNH HÓA QUY TRÌNH NGHIỆP VỤ TRONG HTTT DOANH NGHIỆP THEO KIẾN TRÚC SOA 35

2.1 Quy trình nghiệp vụ 35

2.1.1 Khái niệm quy trình nghiệp vụ 35

2.1.2 Mô hình hóa quy trình nghiệp vụ 36

2.1.3 Một số công cụ hỗ trợ việc mô hình hóa quy trình nghiệp vụ theo kiến trúc SOA 39

2.2 Giới thiệu BPMN 2.0 40

2.2.1 Khái niệm cơ bản 40

2.2.2 Các kí pháp cơ bản trong BPMN 2.0 41

2.2.3 So sánh BPMN 2.0 với biểu đồ hoạt động của UML 46

CHƯƠNG 3: MÔ HÌNH HÓA QUY TRÌNH NGHIỆP VỤ BẰNG BPMN 2.0 48

3.1 Chuyển đổi mô hình truyền thống sang BPMN 2.0 48

3.2 Một số quy trình nghiệp vụ đơn giản 48

3.2.1 Quy trình nghiệp vụ xem thông tin chi tiết hồ sơ học sinh 48

3.2.2 Quy trình nghiệp vụ tra cứu hồ sơ học sinh 51

3.2.3 Quy trình nghiệp vụ đăng nhập không nhớ mật khẩu 54

3.2.4 Quy trình nghiệp vụ học sinh nộp bài tập về nhà 56

3.2.5 Quy trình nghiệp vụ sửa thông tin hồ sơ học sinh 58

3.2.6 Quy trình nghiệp vụ phân lớp tự động 60

3.3 Quy trình nghiệp vụ có nhiều tác nhân cùng tham gia 63

3.3.1 Quy trình nghiệp vụ xin nghỉ phép cho giáo viên 63

3.3.2 Quy trình nghiệp vụ xin miễn giảm học phí 65

3.3.3 Quy trình đề nghị thanh toán Dạy trung tâm 66

CHƯƠNG 4: ÁP DỤNG CÔNG CỤ HỖ TRỢ BPMN 2.0 TỰ ĐỘNG HÓA MỘT SỐ QUY TRÌNH NGHIỆP VỤ 69

4.1 Giới thiệu Activiti 69

4.1.1 Tổng quan 69

4.1.2 Cài đặt 69

4.2 Triển khai Activiti 5.9 để mô hình hóa quy trình nghiệp vụ bằng BPMN 2.0 72 4.3 Sử dụng công cụ Activiti tự động hóa một số quy trình nghiệp vụ 76

4.3.2 Quy trình nghiệp vụ xin miễn giảm học phí 85

4.3.3 Quy trình đề nghị thanh toán Dạy trung tâm 91

4.4 Đánh giá 98

4.4.1 Ưu điểm của BPMN 2.0 98

4.4.2 Nhược điểm của BPMN 2.0 99

KẾT LUẬN 100

1 Các nội dung đã hoàn thành trong luận văn 100

2 Các đóng góp khoa học 100

3 Hạn chế của luận văn 101

4 Hướng phát triển luận văn 101

TÀI LIỆU THAM KHẢO 103

DANH MỤC KÝ HIỆU, CHỮ VIẾT TẮT

BGH Ban giám hiệu

BPM Business Process Management

BPEL Business Process Execution Language

BPMN Business Process Modeling Notation

CRM Customer Relationship Management

E- commerce Electronic commerce

EAI Enterprise application integration

ERP Enterprise Resource Planning

HTTT Hệ thống thông tin

GVCN Giáo viên chủ nhiệm

JAX-RPC Java APIs for XML-Based Remote Procedure Call JAXM Java API for XML Messaging

NSD Người sử dụng

SCM Supply Chain Management

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SRM Supplier Relationship Management

UML Unified Modeling Language

DANH MỤC BẢNG

Bảng 3-1 Mô tả quy trình nghiệp vụ xem thông tin chi tiết hồ sơ học sinh 48

Bảng 3-2 Mô tả nghiệp vụ tra cứu hồ sơ học sinh 51

Bảng 3-3 Mô tả quy trình nghiệp vụ đăng nhập không nhớ mật khẩu 54

Bảng 3-4 Mô tả quy trình nghiệp vụ học sinh nộp bài tập về nhà 56

Bảng 3-5 Mô tả quy trình nghiệp vụ sửa thông tin hồ sơ học sinh 58

Bảng 3-6 Mô tả quy trình nghiệp vụ phân lớp tự động 60

Bảng 3-7 Mô tả nghiệp vụ xin nghỉ phép cho giáo viên 64

Bảng 3-8 Mô tả nghiệp vụ xin miễn giảm học phí 65

Bảng 3-9 Mô tả nghiệp vụ Đề nghị thanh toán dạy trung tâm 67

DANH MỤC HÌNH

Hình 1.1 Mô hình cơ bản của SOA 16

Hình 1.2 Kiến trúc tổng quan của SOA 17

Hình 1.3 Kiến trúc phân tầng chi tiết của SOA 18

Hình 1.4 Mô hình triển khai SOA trong thực tế 19

Hình 1.5 Mô hình cơ bản của Web Service 20

Hình 1.6 Mô hình khung của Openwings 25

Hình 1.7 Mô hình ESB 28

Hình 2.1 Quy trình học sinh hoàn thành môn học 36

Hình 2.2 Các Event trong BPMN 42

Hình 2.3 Các kiểu Activities trong BPMN 43

Hình 2.4 Các kiểu Sub-Process 43

Hình 2.5 Các loại Gateway 44

Hình 2.6 Các đối tƣợng kết nối 45

Hình 2.7 Các loại Artifacts 46

Hình 3.1 Mô hình nghiệp vụ xem thêm thông tin chi tiết hồ sơ học sinh 50

Hình 3.2 Mô hình hóa quy trình nghiệp vụ xem thông tin chi tiết hồ sơ học sinh bằng BPMN 2.0 51

Hình 3.3 Mô hình nghiệp vụ tra cứu hồ sơ học sinh 53

Hình 3.4 Mô hình hóa quy trình nghiệp vụ tra cứu hồ sơ học sinh bằng BPMN 2.0 54

Hình 3.5 Biểu đồ hoạt động UML nghiệp vụ đăng nhập không nhớ mật khẩu 55

Hình 3.6 Mô hình hóa quy trình nghiệp vụ đăng nhập không nhớ mật khẩu bằng BPMN 2.0 56

Hình 3.7 Biểu đồ hoạt động UML nghiệp vụ nộp bài tập về nhà 57

Hình 3.8 Mô hình hóa quy trình nghiệp vụ nộp bài tập về nhà bằng BPMN 2.0 58

Hình 3.9 Biểu đồ luồng xử lý chức năng quy trình sửa thông tin hồ sơ học sinh 59

Hình 3.10 Mô hình hóa quy trình nghiệp vụ sửa thông tin hồ sơ học sinh bằng BPMN 2.0 60

Hình 3.12 Mô hình hóa quy trình phân lớp tự động bằng BPMN 2.0 63

Hình 3.13 Mô hình quy trình nghiệp vụ xin nghỉ phép cho giáo viên 65

Hình 3.14 Quy trình nghiệp vụ xin miễn giảm học phí 66

Hình 3.15 Quy trình đề nghị thanh toán tiền dạy trung tâm 68

Hình 4.1 Màn hình chính Activiti Explorer 70

Hình 4.2 Công cụ Activiti Modeler 71

Hình 4.3 Công cụ Activiti Probe 71

Hình 4.4 Công cụ Activiti Cycle 72

Hình 4.5 Mô hình hóa quy trình bằng BPMN 2.0 trên Eclipse 73

Hình 4.6 Đăng nhập bằng quyền quản trị hệ thống 74

Hình 4.7 Tải thêm quy trình vào Activiti Explorer 74

Hình 4.8 Màn hình quản lý các quy trình hiện có 75

Hình 4.9 Màn hình khởi động quy trình đã mô hình hóa bằng BPMN 2.0 76

Hình 4.10 Mô hình quy trình nghiệp vụ xin nghỉ phép cho giáo viên 76

Hình 4.11 Giáo viên đăng nhập để xin nghỉ phép 79

Hình 4.12 Màn hình chính Activiti Explorer 79

Hình 4.13 Chọn khởi động quy trình xin nghỉ phép 79

Hình 4.14 Hoàn thiện thông tin xin nghỉ 80

Hình 4.15 Người quản lý đăng nhập 81

Hình 4.16 Màn hình chính Activiti Explorer của người quản lý 81

Hình 4.17 Các công việc đang chờ xử lý 81

Hình 4.18 Nhận việc xử lý yêu cầu xin nghỉ phép 82

Hình 4.19 Xử lý yêu cầu và hoàn thành 83

Hình 4.20 Nhận lại yêu cầu thay đổi 83

Hình 4.21 Gửi lại yêu cầu 84

Hình 4.22 GV gửi lại yêu cầu đã sửa 84

Hình 4.23 Quy trình nghiệp vụ xin miễn giảm học phí 85

Hình 4.24 Học sinh đăng nhập vào hệ thống 87

Hình 4.25 Chọn quy trình Xin miễn giảm học phí 87

Hình 4.26 Điền đầy đủ thông tin vào form khởi động 88

Hình 4.27 Quy trình đã đƣợc khởi động 88

Hình 4.28 GVCN nhận phần việc của mình 89

Hình 4.29 GVCN Xử lý công việc 89

Hình 4.30 Quy trình chuyển tiếp công việc đến BGH 90

Hình 4.31 BGH Xử lý công việc 90

Hình 4.32 Quy trình đề nghị thanh toán tiền dạy trung tâm 91

Hình 4.33 GV chọn quy trình Thanh toán Dạy trung tâm 93

Hình 4.34 GV nhập các thông tin để tiến hành thanh toán 94

Hình 4.35 Công việc xuất hiện trong hàng chờ của giáo vụ 94

Hình 4.36 Giáo vụ xử lý yêu cầu 95

Hình 4.37 Giáo viên nhận lại yêu cầu 95

Hình 4.38 Tải lên tài nguyên đính kèm 96

Hình 4.39 Giáo vụ nhận lại yêu cầu 96

Hình 4.40 Quản lý đào tạo nhận việc 97

Hình 4.41 Thủ quỹ hoàn thành quy trình thanh toán 97

MỞ ĐẦU

1 Lý do chọn đề tài

Hiện nay nhiều dịch vụ trên Internet cũng như trong các công ty được thiết kế theo kiến trúc SOA (Service Oriented Architechture - kiến trúc hướng dịch vụ) Dịch vụ là yếu tố then chốt trong SOA, nó giúp cho các doanh nghiệp có thể tích hợp các thành phần hiện có vào các ứng dụng mới và các thành phần này có thể được chia sẻ hoặc tái sử dụng trong nhiều lĩnh vực khác nhau của công ty đó mà không cần phải chỉnh sửa mã nguồn hay phải tái cấu trúc lại hệ thống

Xuất phát từ lợi ích của việc xây dựng hệ thống thông tin doanh nghiệp theo hướng SOA nên ngày càng nhiều công ty áp dụng SOA trong việc thiết kế các hệ thống thông tin doanh nghiệp của mình nhằm đạt được mức độ linh hoạt cao trong kinh doanh Chính vì lẽ đó tôi chọn đề tài “Nghiên cứu ứng dụng kiến trúc SOA trong mô hình ứng dụng doanh nghiệp” là đề tài luận văn tốt nghiệp

2 Mục đích, phạm vi nghiên cứu

 Nghiên cứu tìm hiểu về SOA, hệ thống thông tin doanh nghiệp, đưa ra được các lợi ích khi sử dụng SOA trong thiết kế và xây dựng hệ thống thông tin doanh nghiệp

 Nghiên cứu tìm hiểu về mô hình hóa quy trình nghiệp vụ và nghiên cứu cách thức sử dụng kí pháp của BPMN 2.0 Từ đó mô hình hóa một số quy trình nghiệp vụ trường học

 So sánh các ưu điểm của BPMN 2.0 với biểu đồ hoạt động UML

 Chuyển đổi một số mô hình quy trình nghiệp vụ dạng truyền thống sang BPMN 2.0

 Áp dụng phần mềm Activiti 5.9 để tiến hành tự động hóa một số quy trình nghiệp vụ trường học đã được mô hình hóa bằng BPMN 2.0

3 Đối tượng nghiên cứu

- Các quy trình nghiệp vụ trong một tổ chức, doanh nghiệp

- Kiến trúc SOA

- Ngôn ngữ mô hình hóa BPMN 2.0

- Phần mềm Activiti 5.9

4 Phương pháp nghiên cứu

Các phương pháp nghiên cứu đã được áp dụng bao gồm:

- Phương pháp nghiên cứu lý thuyết, tổng hợp tài liệu

- Phương pháp ứng dụng minh họa

- Phương pháp nghiên cứu thực tiễn

5 Nhiệm vụ nghiên cứu

 Tìm hiểu khái quát về kiến trúc SOA, hệ thống thông tin doanh nghiệp, sau đó tập trung vào tìm hiểu về BPMN 2.0, quy trình nghiệp vụ, và mô hình hóa quy trình nghiệp vụ bằng BPMN 2.0

 So sánh BPMN 2.0 với biểu đồ hoạt động UML

 Nghiên cứu sử dụng công cụ Activiti 5.9 để tự động hóa các quy trình nghiệp vụ đã được mô hình hóa bằng BPMN 2.0

CHƯƠNG 1: HỆ THỐNG THÔNG TIN DOANH NGHIỆP THEO

MÔ HÌNH KIẾN TRÚC HƯỚNG DỊCH VỤ

1.1 Hệ thống thông tin doanh nghiệp

1.1.1 Khái niệm

Hệ thống thông tin doanh nghiệp là hệ thống hỗ trợ cho các quy trình nghiệp

vụ của một tổ chức với các chức năng như sản xuất, phân phối, bán hàng, kế toán, tài chính và nhân sự

Các thành phần chính trong hệ thống thông tin doanh nghiệp gồm:

 Hệ thống hoạch định nguồn lực doanh nghiệp (Enterprise Resource Planning - ERP)

 Hệ thống quản trị quan hệ khách hàng (Customer Relationship Management - CRM) và hệ thống quản trị quan hệ nhà cung cấp (Supplier Relationship Management - SRM)

 Hệ thống quản trị chuỗi cung ứng (Supply Chain Management - SCM)

1.1.2 Phân loại các HTTT dùng trong doanh nghiệp

Có nhiều cách phân loại các HTTT dùng trong doanh nghiệp Dưới đây là cách phân loại dựa trên loại hỗ trợ mà HTTT cung cấp

1.1.2.1 Các hệ thống hỗ trợ hoạt động

 Hệ thống xử lý giao dịch (xử lý giao dịch kinh doanh)

 Hệ thống điều khiển tiến trình (điều khiển các quá trình công nghiệp)

 Hệ thống cộng tác xí nghiệp (hỗ trợ giao tiếp, cộng tác trong doanh nghiệp)

Các hệ thống hỗ trợ hoạt động, hay các HTTT tác nghiệp, xử lý các dữ liệu dùng cho các hoạt động kinh doanh và sinh ra trong các hoạt động đó Các hệ thống

này sinh ra nhiều sản phẩm thông tin dùng bên trong và bên ngoài doanh nghiệp Chúng thường đảm nhận các vai trò sau đây:

 Xử lý một cách hiệu quả các giao dịch kinh doanh,

 Điều khiển các tiến trình công nghiệp (thí dụ quá trình chế tạo sản phẩm),

 Hỗ trợ việc giao tiếp và cộng tác trong toàn xí nghiệp,

 Cập nhật các CSDL cấp Công ty

Tuy nhiên các hệ thống này không chú trọng vào việc tạo ra các sản phẩm thông tin mang đặc thù quản lý Muốn có các thông tin dạng đó phải tiến hành xử lý tiếp trong các HTTT hỗ trợ quản lý

1.1.2.2 Các hệ thống hỗ trợ quản lý

 Hệ thống thông tin quản lý (các báo cáo theo mẫu định trước)

 Hệ hỗ trợ quyết định (hỗ trợ quyết định tương tác, không theo mẫu)

 Hệ thống thông tin điều hành (các thông tin cho lãnh đạo cấp cao nhất) Các hệ thống hỗ trợ quản lý, trợ giúp các nhà quản lý trong việc ra quyết định Chúng cung cấp các thông tin và các hỗ trợ để ra quyết định về quản lý, là các nhiệm vụ phức tạp do các nhà quản trị và các nhà kinh doanh chuyên nghiệp thực hiện Về mặt ý niệm, thường chia ra các loại hệ thống chính sau đây, nhằm hỗ trợ các chức trách ra quyết định khác nhau:

 Các HTTT quản lý - cung cấp thông tin dưới dạng các báo cáo theo mẫu định sẵn, và trình bày chúng cho các nhà quản lý và các chuyên gia khác của doanh nghiệp,

 Các hệ thống hỗ trợ quyết định - cung cấp trực tiếp các hỗ trợ về mặt tính toán cho các nhà quản lý trong quá trình ra quyết định (không theo mẫu định sẵn, và làm việc theo kiểu tương tác, không phải theo định

 Các HTTT điều hành - cung cấp các thông tin có tính quyết định từ các nguồn khác nhau, trong nội bộ cũng như từ bên ngoài, dưới các hình thức dễ dàng sử dụng cho các cấp quản lý và điều hành

1.2 Mô hình kiến trúc hướng dịch vụ ứng dụng trong HTTT doanh nghiệp

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

SOA (Service Oriented Architecture) – Kiến trúc Định hướng Dịch vụ là một cách tiếp cận hay một phương pháp luận để thiết kế và tích hợp các thành phần khác nhau, bao gồm các phần mềm và các chức năng riêng lẻ lại thành một hệ thống hoàn chỉnh Kiến trúc SOA rất giống như cấu trúc của các phần mềm hướng đối tượng gồm nhiều module Tuy nhiên khái niệm module trong SOA không đơn thuần

là một gói phần mềm, hay một bộ thư viện nào đó Thay vào đó, mỗi module trong một ứng dụng SOA là một dịch vụ được cung cấp rải rác ở nhiều nơi khác nhau và

có thể truy cập thông qua môi trường mạng Nói một cách ngắn gọn, một hệ thống SOA là một tập hợp nhiều dịch vụ được cung cấp trên mạng, được tích hợp lại với nhau để cùng cộng tác thực hiện các tác vụ nào đấy theo yêu cầu của người dùng

Một trong những cách hiểu sai lầm nhất về SOA là coi SOA là một công nghệ Mặc dù SOA hoạt động được là nhờ công nghệ, nhưng khách hàng cần phải chuyển đổi từ chỗ chỉ việc tích hợp công nghệ SOA sang việc phải điều chỉnh các phương pháp thực hiện dự án, chính sách bảo trì và thay đổi để đạt được các lợi ích về khả năng trưởng thành và đáp ứng

Dịch vụ là yếu tố then chốt trong SOA Có thể hiểu dịch vụ như là một loại module thực hiện một quy trình nghiệp vụ nào đó Một trong những mục đích của SOA là giúp các ứng dụng có thể 'nói chuyện' với nhau mà không cần biết các chi tiết kỹ thuật bên trong Để thực hiện điều đó SOA định ra một chuẩn 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à

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 Sự trừu tượng là cốt lõi của khái niệm dịch vụ, nó giúp cho các doanh nghiệp có thể tích hợp các thành phần hiện có vào các ứng dụng mới và các thành phần này có thể được chia sẻ hoặc tái sử dụng trong nhiều lĩnh vực khác nhau của công ty đó mà không cần phải chỉnh sửa mã nguồn hay phải tái cấu trúc lại hệ thống

Có nhiều cách khác nhau để kết nối các dịch vụ, chẳng hạn dùng các giao thức mạng có sẵn, hoặc tạo một giao thức riêng Nhưng từ năm 2001, các dịch vụ web (Web service) được xây dựng dựa trên nền tảng web toàn cầu, bất cứ nơi nào cũng

có, đã trở thành một phương pháp phổ biến cho việc kết nối các thành phần của hệ thống SOA với nhau Thoạt nhìn SOA và dịch vụ web trông có vẻ giống nhau nhưng chúng không phải là một

Hình 1.1 Mô hình cơ bản của SOA

1.2.2 Kiến trúc của SOA

1.2.2.1 Kiến trúc tổng quan của SOA

Hình 1.2 Kiến trúc tổng quan của SOA

 Service Provider: Cung cấp các dịch vụ phục vụ cho một nhu cầu nào đó User (người sử dụng hay một ứng dụng sử dụng service) không cần quan tâm đến vị trí thực sự mà service họ cần sử dụng đang hoạt động

 Serive Consumer: User sử dụng dịch vụ được cung cấp bởi Service Provider

 Service Registry: Nơi lưu trữ thông tin về các service của các Service Provider khác nhau, Service Consumer dựa trên những thông tin này để tìm kiếm và lựa chọn Service Provider phù hợp

Service Provider sẽ đăng ký thông tin về service mà mình có thể cung cấp (các chức năng có thể cung cấp, khả năng của hệ thống (tài nguyên, hiệu năng), giá cả dịch vụ, ) vào Service Registry Service Consumer khi có nhu cầu về một service nào đó sẽ tìm kiếm thông tin trên Service Registry Ngoài chức năng hỗ trợ tìm kiếm, Service Registry còn có thể xếp hạng các Service Provider dựa trên các tiêu chí về chất lượng dịch vụ, bầu chọn từ các khách hàng đã sử dụng service, Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer Khi đã xác định được Service Provider mong muốn, Service Consumer thiết lập kênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hành thương lượng thêm (về mặt giá cả, tài nguyên sử dụng, )

1.2.2.2 Kiến trúc chi tiết

Hiện nay chưa có một mô hình chính thức nào của SOA Thật sự SOA là một

phương pháp luận giúp chúng ta tận dụng sức mạnh của các nguồn lực, nguồn tài

nguyên khác nhau trong mạng máy tính để trở thành một hệ thống nhất Mỗi một

công ty, hệ thống có một mô hình SOA khác nhau Nhìn chung mô hình SOA có

các đặc điểm sau:

Hình 1.3 Kiến trúc phân tầng chi tiết của SOA

Một vài thành phần quan trọng trong kiến trúc này:

 Connectivity: đây là tầng thấp nhất của SOA, có nhiệm vụ giao tiếp trực tiếp

với các thành phần khác như cơ sở dữ liệu, giao tiếp với các ứng dụng khác,

các web service,… Vì vậy có thể coi đây là tầng vật lý của SOA

 Orchestration: là các dịch vụ xử lý các quy trình nghiệp vụ và dộc lập với

tầng vật lý phía bên dưới

 Composite Application: là các ứng dụng tổng hợp nhằm mục đích trình diễn

(presentation) và hiển thị thông tin cho người dùng cũng như cung cấp một

giao diện cho người dùng tương tác với hệ thống như là một phần mềm duy

nhất Tầng này có thể là các website, portal, các ứng dụng client mở rộng

(rich client), các thiết bị di động thông minh (smart device),…

 Các thành phần khác: gồm có quy trình phát triển (development), quản lý các dịch vụ (service management), và quản lý con người (governance) Như vậy

có thể thấy SOA không chỉ đơn thuần là về mặt công nghệ mà nó là tổng hòa của rất nhiều yếu tố: công nghệ, cơ sở hạ tầng, con người và quy trình nghiệp

vụ

Hình 1.4 Mô hình triển khai SOA trong thực tế

1.2.2.3 SOA và Web service

Chúng ta có thể thấy mô hình trên của SOA rất giống với của mô hình Web service:

Hình 1.5 Mô hình cơ bản của Web Service

SOA và Web service là hai khái niệm tách biệt nhau SOA chỉ đặc tả một mô hình phát triển các ứng dụng dựa trên dịch vụ, Còn Web service tập trung vào công nghệ để thực hiện điều đó dựa trên nền tảng Web Nói ngắn gọn, Web service là một mô hình cụ thể hóa của SOA Web service đƣợc sử dụng phần lớn trong các ứng dụng SOA Chúng ta cần chú ý là khái niệm “service” của SOA không chỉ là Web service mà nó bao hàm cả các dịch vụ khác mà chúng ta có thể tìm thấy và sử dụng chúng trong một mạng máy tính

1.2.2.4 Mô hình giao tiếp bằng thông điệp (message) trong SOA

So với kiểu thiết kế Component-Based, điểm khác biệt chính của SOA là cung cấp khả năng giao tiếp giữa các thành phần trong hệ thống (service) sử dụng thông điệp (message) dựa trên các chuẩn giao tiếp đã đƣợc chuẩn hóa (HTTP, FTP, SMTP, .) Chính nhờ đặc điểm này, hệ thống SOA trở nên độc lập với platform (platform independent) Các service hoạt động trên nền các platform khác nhau vẫn

có thể giao tiếp với nhau nhờ vào các interface giao tiếp đã đƣợc chuẩn hóa để cộng tác xử lý một tác vụ nào đó

 Thông điệp trở thành ngôn ngữ chung của các platform và các ngôn ngữ lập trình khác nhau Điều này đảm bảo các service trên các platform khác nhau hoạt động với cấu trúc dữ liệu đặc thù của platform đó

 Hoạt động gửi nhận thông điệp được thực hiện theo cơ chế chỉ gửi Phía gửi

và phía nhận không cần phải chờ thông điệp trả lời sau khi đã gửi đi một thông điệp Điều này giúp cho phía gửi và phía nhận tiếp tục xử lý công việc sau khi gửi thông điệp mà không cần dừng thực thi để chờ thông điệp trả lời

 Các thông điệp từ phía gửi có thể được gửi đến một dịch vụ trung gian có nhiệm vụ lưu trữ các thông điệp Dịch vụ trung gian sẽ gửi (forward) thông điệp cho phía nhận khi phía nhận có thể xử lý yêu cầu tiếp theo Cơ chế Store-and-Forward này đảm bảo các thông điệp sẽ không bị thất lạc trong trường hợp phía nhận bị quá tải và không thể nhận thêm yêu cầu mới

 Việc trao đổi thông điệp theo cơ chế bất đồng bộ giúp ứng dụng không cần ngừng thực thi để chờ một tác vụ kết thúc mà có thể tạo ra các luồng xử lý các công việc khác nhau

 Các thông điệp lưu trữ thông tin về các đối tượng dữ liệu dưới dạng đặc tả hình thức thay thế việc phải nối tiếp hóa và hủy nối tiếp các đối tượng dữ liệu truyền qua mạng khi ứng dụng thực hiện gọi từ xa một ứng dụng khác

 Thông điệp có thể lưu trữ thông tin về ngữ cảnh bảo mật của kênh giao tiếp Điều này cung cấp khả năng điều khiển liên quan đến bảo mật như xác thực

Dịch vụ được dựa trên các giao diện đã được viết trong ngôn ngữ lập trình Java Nó không quan tâm đến việc dịch vụ cài bằng phần cứng hay phần mềm Đối tượng dịch vụ mà người dùng tải về được cung cấp bởi các thành phần cung cấp dịch vụ Client chỉ cần biết rằng họ đang làm việc với một cài đặt của một giao diện được viết bằng ngôn ngữ lập trình Java Việc thiết kế dựa trên các giao diện dịch vụ cho phép xây dựng các hệ thống với tính sẵn dùng cao Một thành phần có thể sử dụng bất kỳ dịch vụ nào phù hợp với giao diện, thay vì được cấu hình tĩnh để giao tiếp với một thành phần nhất định nào đó

Công nghệ Jini được xây dựng phía trên công nghệ Java (xem hình dưới) Phương thức triệu gọi từ xa của Java (RMI) cung cấp cơ chế thu rác từ xa của các đối tượng từ xa và khả năng chuyển trạng thái của đối tượng cũng như mã đối tượng qua mạng

Kiến trúc Jini bao gồm:

 Dịch vụ tra cứu (Looup Services): Dịch vụ tra cứu lưu trữ các dịch vụ Jini và cung cấp các uỷ nhiệm để truyền thông với dịch vụ, bản thân nó cũng là một dịch vụ Jini

 Dịch vụ Jini(Jini services): Dịch vụ Jini được đăng ký với dịch vụ tra cứu và có khả năng được triệu gọi thông qua giao diện công khai của mình (giao diện này được định nghĩa thông qua một giao diện từ xa)

Hệ thống nền tảng truyền thông của Jini là RMI

 Thành phần sử dụng dịch vụ Jini (Jini Client): Thành phần sử dụng dịch

vụ Jini là một phần mềm yêu cầu đối tượng uỷ nhiệm từ dịch vụ tra cứu

để gọi dịch vụ Jini

Jini có một số các dịch vụ được xây dựng sẵn, bao gồm:

 Dịch vụ tìm kiếm tra cứu (Lookup Discovery Services): Dịch vụ tìm kiếm tra cứu thông báo cho các thành phần sử dụng dịch vụ về các thay

đổi trong mạng Jini Các dịch vụ có thể kết hợp hoặc tách ra khỏi mạng bất kỳ thời điểm nào

 Dịch vụ tái tạo ràng buộc(Lease Renewal Services): Khái niệm tái tạo ràng buộc hỗ trợ mạng dịch vụ Jini tính naưng tự hàn gắn và khắc phục lỗi Dịch vụ phải tái tạo ràng buộc không được tái tạo, dịch vụ sẽ là một ứng viên bị loại bỏ khỏi mạng lưới dịch vụ Trách nhiệm của những người quản trị trong lĩnh vực này được giảm tới mức tối thiểu nhờ tính năng tự hàn gắn của hệ thống

 Dịch vụ giao dịch (Transactor Services): Dịch vụ cho phép sử dụng các giao dịch trong một hệ thống phân tán Thông thường, các tổ chức sử dụng cơ sở dữ liệu để tạo các hệ thống giao dịch Dịch vụ giao dịch của Jini đưa tính năng giao dịch của cơ sở dữ liệu lên mạng Các dịch vụ có thể tham gia vào các giao dịch để đảm bảo các thuộc tính ACID (Atomicity- Consistency- Isolation- Durability) gắn liền với giao dịch

 Dịch vụ hộp thư sự kiện (Event MailBox Services): Các thay đổi trong mạng dịch vụ Jini đựơc truyền đi trogn hệ thống bằng cách sử dụng các

sự kiện phân tán dịch vụ hộp thư sự kiện hỗ trợ tính năng thông báo các sự sự kiện cho các dịch vụ ngay cả khi dịch vụ không được kích hoạt tại thời điểm hiện tại

1.2.3.2 Openwings

Openwings là một khung kiến trúc hướng dịch vụ cho việc xây dựng các hệ thống các siêu hệ thống (hệ thống của hệ thống) Mặc dù không bị ràng buộc cụ thể với Jini, nó cho phép xây dựng dựa trên các khải niệm của Java và Jini để cung cấp một giải pháp hoàn thiện hơn

Openwings có hàng loạt các dịch vụ cốt lõi hỗ trợ tính toán hướng đối tượng

Component Services (Các dịch vụ thành phần): cung cấp các kỹ thuật cho việc đƣa ra công bố một dịch vụ trong hệ thống đảm bảo cho quá trình tìm kiếm phát hiện (discover), thông qua sử dụng component cung các thƣ viện cho phép:

Tạo ra các khả năng cung cấp, định vị và sử dụng các dịch vụ nói chung trong

hệ thống mà không phụ thuộc vào bất cứ kỹ thuật định vị/ tìm kiếm (location/lookup) nào Ví dụ các kỹ thuật định vị/tìm kiếm nhƣ Jini, UDDI với mô hình Web-services, giao thức phát hiện (discovery) Bluetooth

Quá trình giao tiếp giữa các thành phần hay dịch vụ đƣợc định nghĩa với các API chuẩn cho các dịch vụ thông qua việc thiết kế thừa từ những giao diện chuẩn

Hình 1.6 Mô hình khung của Openwings

Install services (Các dịch vụ cài đặt): là một thành phần dịch vụ của framework cho phép thực hiện cài đặt các thành phần mới vào hệ thống Để cài đặt được thì các thành phần này cần phải thông qua các quy trình chuẩn mà openwings

đề xuất

Cung cấp các khả năng cài đặt thêm những dịch vụ mới để hạn chế tối đa các tương tác bằng tay cho người sử dụng Đảm bảo không gây ảnh hưởng tới các thành phần hay dịch vụ đã được cài đặt trước đó

Cung cấp các khả năng tự động dò tìm và cho phép gọi thực hiện với các thành phần được lưu trữ trong các thiết bị lưu trữ tự động

Có cơ chế thẩm định quyền và độ ưu tiên cho việc cài đặt và gọi thực hiện

Có cơ chế huỷ cài đặt an toàn cho hệ thông khi cần thiết

Context Services (Các dịch vụ ngữ cảnh): là các thành phần cho hỗ trợ việc kết hợp các dịch vụ trong môi trường hệ thống để có được một dịch vụ lớn hơn Đồng thời còn hỗ trợ việc kết hợp các dịch vụ được chia sẻ trong một mạng WAN

Management Services (các dịch vụ quản lý): cung cấp các phương thức cơ bản

hỗ trợ việc quản lý các thành phần và dịch vụ trong hệ thống Với các hỗ trợ từ dạng quản lý hệ thống qua can thiệp bầng tay hay thông qua việc cài đặt các cơ chế quản

lý tự động Các hỗ trợ này được đóng gói trong Mbean

Security Services (các dịch vụ kết bảo mật): cung cấp các phương thức cho việc mã hoá, truyền tải dữ liệu trong hệ thống, các hỗ trợ cơ bản cho việc cấp quyền, thẩm định quyền, đảm bảo an toàn khi truyền tin, tính toàn vẹn, khả năng phát hiện tấn công và đáp trả các tấn công vào hệ thống

Connector Services (các dịch vụ kết nối): cung cấp các kỹ thuật cho việc giao tiếp giữa các thành phần hay dịch vụ trong hệ thống Hỗ trợ trực tiếp cho các kỹ thuật giao tiếp thông qua một đối tượng chuyển tiếp trung gian như CORBA, RMI, giao tiếp từ một giao diện dịch vụ được định hướng trước theo các kỹ thuật chuyển tiếp trung gian chuẩn với các cơ chế động ngay tại thời điểm diễn ra giao tiếp tuỳ theo yêu cầu sử dụng Với đầy đủ các hỗ trợ cho việc giao tiếp theo phiên hay theo dạng giao tiếp không duy trì kết nối Hỗ trợ đầy đủ các hàm cơ bản cho phép làm việc với RMI, CORBA, JMS, SOAP

Container Services (các dịch vụ chứa đựng): cung cấp môi trường tương ứng cho việc thực hiện các dịch vụ trong mô hình openwings Đây là một thành phần quan trọng trong việc tạo nên khả năng vận hành động không phụ thuộc vào nền tảng hay môi trường vận hành phân tán của hệ thống

Cung cấp các khả năng gọi chạy dịch vụ trên máy hiện tại qua một nền hệ thống từ xa

Hỗ trợ việc quản lý vòng đời của các tiến trình dịch vụ, các phương thức cho phép tự động khởi động lại, tạm dừng hay huỷ dịch vụ

Cung cấp khả năng gán hay thiết lập cho một số tiến trình xây dựng bằng Java

có thể hoạt động độc lập trên các máy ảo Java mà không ảnh hưởng tới các thành phần khác

Hỗ trợ việc gọi khởi động các dịch vụ không được xây dựng trên nền Java

Cung cấp các phương thức cho ohép theo dõi tài nguyên hệ thống như theo dõi các thông tin về độ dung lượng trong bộ nhớ, khả năng hoạt động của bộ vi xử lý hay khả năng đáp ứng lưu lượng của đường truyền tải dữ liệu

1.2.3.3 Dịch vụ web

Mặc dù các khái niệm nền tảng cho kiến trúc hướng dịch vụ đã được thiết lập

từ trước khi dịch vụ mạng xuất hiện nhưng dịch vụ mạng vẫn đóng một vai trò quan trọng trong một kiến trúc hướng dịch vụ Đó là bởi vì dịch vụ mạng được xây dựng trên một tập các giao thức được biết tớí nhiều và độc lập về nền tảng Các giao thức này bao gồm HTTP, XML, UDDI, và SOAP Chính sự kết hợp của các giao thức này đã làm dịch vụ mạng đáp ứng đựơc các yêu cầu của chính kiến trúc hướng dịch vụ: SOA yêu cầu dịch vụ phải được phát hiện và triệu gọi động, yêu cầu này được thoả mãn bằng UDDI, WSDL, và SOAP; SOA yêu cầu dịch vụ có một giao ước giao diện độc lập nền tảng, yêu cầu này được thoả mãn bởi XML; SOA nhấn mạnh tới tính liên thông, yêu cầu này được thoả mãn bởi HTTP Đây là lý do tại sao các dịch vụ mạng lại có vai trò trung tâm trong kiến trúc hướng dịch vụ

1.2.3.4 Enterprise Services Bus (ESB)

Các công nghệ dựa trên nền dịch vụ mạng ngày càng được ứng dụng rộng rãi trong phát triển và tích hợp ứng dụng trong các tổ chức Một trong những vấn đề nổi lên hiện nay là việc tìm kiếm các phương pháp hiệu quả hơn trong việc thiết kế, phát triển và triển khai dịch vụ mạng dựa trên các hệ thống kinh doanh; quan trọng

hơn nữa là việc chuyển kiểu truyền thông dịch vụ mạng điểm tới điểm tới các ứng dụng lớn hơn của các công nghệ này thành các quy trình kinh doanh ở mức xí nghiệp Trong bối cảnh này, mô hình ESB đang xuất hiện như một bước tiến mới trong sự phát triển của dịch vụ mạng và kiến trúc hướng đối tượng

Hình 1.7 Mô hình ESB

Dịch vụ mạng cơ bản:

Dịch vụ mạng cơ bản (SOAP/HTTP điểm tới điểm) cung cấp một nền tảng vững trắc cho việc cài đặt một kiến trúc hướng dịch vụ, nhưng có những vấn đề ảnh hưởng tới tính mềm dẻo và khả năng bảo trì của chúng trong các kiến trúc ở quy mô

xí nghiệp

Thứ nhất, bản chất điểm tới điểm của dịch vụ mạng cơ bản có nghĩa là người dùng dịch vụ thường cần phải được sửa đổi bất kỳ khi nào giao diện người cugn cấp dịch vụ thay đổi Điều này không thành vấn đề trên quy mô nhỏ, nhưng trong các xí nghiệp lớn chúng ta sẽ phải phải thay đổi đối với các trình khách đã có

Thứ hai chúng ta có thể kết thúc bằng một kiến trúc dễ đổ vỡ và không linh hoạt khi một số dung lượng lớn người dùng dịch vụ và người cung cấp dịch vụ liên lạc với nhau sử dụng các kết nối kiểu điểm tới điểm hỗn loạn

Cuối cùng, dịch vụ mạng cơ bản đòi hỏi mỗi người dùng phải có một bộ điều hợp giao thức thích hợp với mỗi nhà cung cấp dịch vụ Việc phải triển khai nhiều bộ điều hợp giao thức trên nhiều ứng dụng khách làm tăng giá thành và chi phí bảo trì

Cách tiếp cậu ESB sẽ giải quyết được những vấn đề này

Khái niệm ESB không phải là một sản phẩm, nhưng là một thực tiễn kiến trúc tốt nhất cho việc cài đặt một kiến trúc hướng dịch vụ Như chỉ ra trong hình dưới,

nó thiết lập một đường bus thông điệp lớp xí nghiệp kết hợp hạ tầng thông điệp với

sự chuyển đổi thông điệp và đinh tuyến dựa vào nội dung trong một tâng tích hợp logic giữa những người dùng và người cung cấp dịch vụ

Mục đích của ESB là cung cấp một sự trừu tượng hoá về các nguồn tài nguyên của doanh nghiệp, cho phép các nghiệp vụ của doanh nghiệp có thể được phát triển

và quản lý độc lập với hạ tầng, mạng và có sự có mặt của các dịch vụ doanh nghiệp khác Các nguồn tài nguyên trong ESB được mô hình như những dịch vụ có một hay nhiều thao tác

Cài đặt một ESB đòi hỏi một tập hợp được tích hợp của các dịch vụ phần giữa

hỗ trợ các kiểu kiến trúc như sau:

 Các kiến trúc hướng dịch vụ: ở đây, các ứng dụng phân tán bao gồm các dịch vụ có thể sử dụng lại được với các giao diện rõ ràng, có thể được xuất bản và tương thích với các chuẩn

 Các kiến trúc hướng thông điệp: ở đây, các ứng dụng gửi thông điệp qua ESB tới các ứng dụng nhận thông điệp

 Các kiến trúc hướng sự kiện: ở đây, các ứng dụng tạo mới và sử dụng các thông điệp độc lập lẫn nhau

 Các dịch vụ phần giữa(middleware): đựơc cung cấp bởi một ESB cần chứa:

o Phần giữa truyền thông hỗ trợ nhiều mô hình truyền thông (như đồng bộ, không đồng bộ, yêu cầu/ trả lời, một chiều ), chất lượng dịch vụ (bảo mật, hiệu năng ), các API, nền tảng và các giao thức độc lập

o Một cơ chế cho việc chèn xử lý thông minh của các lần yêu cầu

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

Một trong những lợi ích rõ ràng nhất của SOA là nó giúp các công ty thu được giá trị nhiều hơn bằng cách sử dụng lại những tài nguyên sẵn có; kết quả là giảm chi phí cho phần kiến trúc và tích hợp Ngoài ra nó còn giúp giảm chi phí mua phần mềm mới Thời gian viết chương trình lấy dữ liệu từ máy chủ trước đây được tính bằng tháng thì bây giờ chỉ còn tính bằng phút Lợi ích của việc sử dụng lại có thể chia làm 2 phần :

 Lợi ích từ việc sử dụng lại những thành phần nhằm giảm tính dư thừa

 Lợi ích từ việc sử dụng lại những thành phần có sẵn khi thiết kế cung cấp một chức năng mới

Nhiều phần mềm doanh nghiệp đã phát triển thành những nhóm phần mềm tách biệt, thông thường là tương ứng với mỗi đơn vị kinh doanh Ví dụ một công ty bán lẻ có thể có một nhóm phần mềm cho hệ thống phân phối, một nhóm phần mềm cho hệ thống lưu kho và một nhóm phần mềm cho những chức năng liên kết Thông thường những nhóm phần mềm này đựơc phát triển trên nhiều nền tảng khác nhau,

sử dụng nhiều ngôn ngữ lập trình khác nhau và thường có nhiều tính năng lặp lại giữa chúng Một hệ thống SOA cho phép các công ty tránh tình trạng lặp dư thừa, tạo ra những đơn thể dịch vụ chia sẻ giữa các ứng dụng

Trong một hệ thống SOA, chỉ cần thay đổi duy nhất một phiên bản của dịch

vụ cần được thay đổi và chỉ cần kiểm thử một lần, sử dụng những kỹ năng tương ứng với những kỹ năng đã dùng để phát triển dịch vụ Lợi ích rõ ràng nhất là giảm chi phí bảo trì phần mềm Ngoài ra điều này còn giúp doanh nghiệp chịu trách nhiệm nhiều hơn với những thay đổi về về mặt nghiệp vụ và cho phép doanh nghiệp cập nh ật những tính năng của nó nhanh hơn

Bằng cách phân rã một ứng dụng thành những đơn thể dịch vụ nghiệp vụ, sau

đó cho những dịch vụ này liên kết lại với nhau, các hệ thống bây giờ có thể sử dụng lại được các thành phần có sẵn, giảm chi phí phát triển từng phần độc lập cho mỗi tính năng mới chưa có Thay vì phải “ thay đổi” , với SOA ta chỉ cần tạo ra các “ cầu nối” liên hệ giữa những hệ thống và ứng dụng khác nhau, thay vì chỉnh sửa hoặc xây dựng lại từ đầu

Bởi vì có đa phần các dịch vụ mới sử dụng lại những dịch vụ sẵn có nên chi phí phát triển các thành phần mới được giảm đến mức tối thiểu Nghĩa là :

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

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

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

Lợi ích cuối cùng của việc tái sử dụng thường khó nhận thấy, đó là khi sử dụng những thành phần có sẵn, mỗi khi có lỗi xảy ra ta đều có thể giới hạn vào khu

vực có những thành phần đang được phát triển Nhờ đó rủi ro về lỗi phần mềm giảm

đi và tăng chất lượng dịch vụ

Giảm chi phí phát triển và kiểm thử, và tránh công việc trùng lặp là một trong những lợi ích mà SOA mang lại Nhưng quan trọng vẫn là lợi ích từ việc tăng khả năng kinh doanh Nếu những nhân tố này được đánh giá đúng mức thì lợi ích mang lại là rất đáng kể

1.2.4.2 Giải pháp ứng dụng tổng hợp cho doanh nghiệp

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

1.2.4.3 Tính chất kết nối lỏng giúp tăng tính linh hoạt và khả năng triển khai cài

đặt

Lợi ích kế tiếp đến từ tính kết nối lỏng của SOA, trong đó phía triệu gọi dịch

vụ không cần quan tâm đến địa chỉ hoặc công nghệ nền tảng của service Nó mang đến khả năng linh hoạt cao và nhiều lợi ích khác

Trong một hệ thống SOA ta triệu gọi dịch vụ thông qua các interface theo một dạng thức chuẩn nên giúp lập trình viên tránh được việc phải lặp lại công việc tạo mới các service có khả năng hiểu tất cả những công nghệ được sử dụng bởi từng

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

Cuối cùng một lợi ích mà tính kết nối lỏng mang lại là tăng khả năng triển khai Như đã phân tích ở trên, những thành phần có tính kết nối lỏng có thể được triệu gọi mà không cần biết chúng được cài đặt như thế nào mà chỉ cần biết cách thức triệu gọi chúng thông qua một interface chuẩn Vì vậy chỉ cần bọc những thành phần sử dụng interface ứng dụng thành dạng dịch vụ, ta đã có một đơn thể thành phần được sử dụng trong hệ thống SOA như những dịch vụ bình thường khác

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

Các phương pháp tiếp cận truyền thống trong quy trình phát triển phần mềm

có thể mô tả ngắn gọn là người dùng mô tả họ cần gì – công ty phát triển phần mềm – triển khai hệ thống theo yêu cầu Quy trình này đôi khi gặp khó khăn khi gặp những tình huống thay đổi không định trước Với SOA, công ty phát triển phần mềm có thể tạo nên những quy trình nghiệp vụ uyển chuyển, phức tạp biến đổi tùy “ theo yêu cầu” và theo “ thời gian thực“

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

SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới Điều này cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau bao gồm cả những trình duyệt và thiết bị di động như điện thoại di động, PDA và các thiết bị chuyên dụng

khác sử dụng cùng một chức năng mà vẫn có thông tin trả về tùy theo dạng thiết bị Tính độc lập công nghệ này giúp cho các công ty tiết kiệm chi phí rất nhiều nhất là khi phải xử lý với vô số công nghệ hiện đang được sử dụng

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

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

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

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

CHƯƠNG 2: MÔ HÌNH HÓA QUY TRÌNH NGHIỆP VỤ TRONG

HTTT DOANH NGHIỆP THEO KIẾN TRÚC SOA

2.1 Quy trình nghiệp vụ

2.1.1 Khái niệm quy trình nghiệp vụ

Quy trình nghiệp vụ là một quy trình xử lý các công việc của một cơ quan hay một tổ chức nào đó Quy trình nghiệp vụ bao gồm các hoạt động, các công việc bên trong mỗi tổ chức, cơ quan cụ thể

Ví dụ : Quy trình học sinh hoàn thành một môn học trong một học kỳ như sau :

 Học sinh phải đi học đầy đủ Nếu học sinh nghỉ học quá ba buổi thì sẽ không được thi kết thúc môn học và sẽ không hoàn thành môn học đó Ngược lại nếu học sinh đi học đầy đủ thì học sinh phải thi giữa học kỳ môn học đó

 Nếu như điểm thi giữa học kỳ lớn hơn hoặc bằng 5 thì học sinh đó sẽ được thi cuối kỳ Ngược lại, nếu như điểm thi giữa kỳ của học sinh đó nhỏ hơn 5 thì học sinh đó không được thi cuối kỳ và sẽ không hoàn thành môn học đó Khi học sinh thi cuối kỳ xong, nếu điểm tổng kết của học sinh đó lớn hơn hoặc bằng 5 thì học sinh đó hoàn thành môn học Ngược lại nếu điểm tổng kết của học sinh nhỏ hơn 5 thì sẽ không hoàn thành môn học đó

Hình 2.1 Quy trình học sinh hoàn thành môn học

2.1.2 Mô hình hóa quy trình nghiệp vụ

Mô hình hóa nghiệp vụ là một kỹ thuật để mô tả quy trình nghiệp vụ của tổ

một chức, một đơn vị Mô hình nghiệp vụ xác định các quy trình nghiệp vụ nào

được hỗ trợ bởi hệ thống Song song với quá trình khảo sát tìm hiểu về vấn đề hệ

thống thì cách tiếp cận nghiệp vụ là phương pháp có hệ thống nhất để nắm bắt các

yêu cầu của các ứng dụng nghiệp vụ

Khi những hệ thống ngày càng phức tạp, việc mô hình hóa trực quan và cách

vận dụng các kỹ thuật mô hình hóa ngày càng trở nên quan trọng hơn Có nhiều

nhân tố bổ sung cho sự thành công của một dự án, nhưng việc có một tiêu chuẩn

ngôn ngữ nghiệp vụ là tạo ra các mô hình nhằm để dễ hiểu hơn và để có thể thiết kế

những chương trình máy tình bằng cách thông qua hiện tượng thế giới thực như

người, nguyên liệu làm việc và cách thức chúng thực hiện những nhiệm vụ của họ

Như vậy, việc mô hình hóa nghiệp vụ là lập mô hình những tổ chức thế giới thực

Phạm vi ảnh hưởng của việc mô hình hóa nghiệp vụ có thể biến đổi tùy theo

nhu cầu và hệ thống nghiệp vụ cụ thể Có thể đơn giản chúng ta chỉ nhằm vào việc

tăng năng suất bằng cách cải tiến những quy trình đã tồn tại, hoặc là đang tạo ra

những sự cải tiến có ảnh hưởng lớn bằng cách thay đổi đáng kể những quy trình nghiệp vụ dựa trên sựa phân tích kỹ lưỡng các mục tiêu và các khách hàng của tổ chức Cho dù là bất kỳ trường hợp nào, những hệ thống thông tin hỗ trợ cho hệ thống nghiệp vụ đều bị ảnh hưởng

Trong quá trình phát triển hệ thống phần mềm một vấn đề tồn tại rất lớn là đội ngũ phát triển hệ thống thường hiếm khi có một kiến thức hiểu biết đầy đủ về nghiệp vụ của tổ chức mà chính họ là người xây dựng hệ thống phần mềm thực hiện trong môi trường nghiệp vụ đó Trong khi đó, người sử dụng phần mềm chính là các đối tượng xử lý nghiệp vụ thường không am hiểu tường tận về các công nghệ và các

kỹ thuật của phần mềm nhằm chọn lựa và áp dụng nó một cách phù hợp và hiệu quả với nhu cầu của mình Khoảng cách này là một vấn đề rất lớn dẫn đến sự thất bại của quá trình tin học hóa hệ thống và thực tế đã có rất nhiều dự án đã thất bại và làm thiệt hại rất lớn về thời gian, công sức của những người tin học hóa Do đó, làm thế nào để các đối tượng này có thể hiểu và thống nhất được tốt nhất về cách giải quyết hệ thống trong quá trình tin học hóa Những mô hình nghiệp vụ đưa ra các cách thức diễn tả những quy trình nghiệp vụ dưới dạng những đối tượng và hành động tương tác giữa chúng Nếu không mô hình hóa nghiệp vụ thì ta có thể gặp nhiều rủi ro do những người phát triển không có thông tin đầy đủ về cách thức mà nghiệp vụ được thực hiện Họ chỉ làm những gì mà họ hiểu rõ, như là thiết kế và tạo

ra phần mềm, mà không quan tâm đến những quy trình nghiệp vụ Điều này gây ra một sự lãng phí do trước đó đã xây dựng các quy trình nghiệp vụ tốn kém Rủi ro do những hệ thống được xây dựng không hỗ trợ các nhu cầu thực sự của tổ chức cũng

có thể xảy ra rất cao

Việc hiểu rõ những quy trình nghiệp vụ là rất quan trọng để có thể xây dựng những hệ thống đúng và hài lòng khách hàng Việc mô hình hóa nghiệp vụ có thể có mục tiêu chính là sự phát triển hệ thống, trong đó công việc thực sự là xác định đúng các yêu cầu hệ thống

Cơ sở để xây dựng hệ thống là sử dụng những vai trò và trách nhiệm của con người cũng như định nghĩa những gì được xử lý bởi nghiệp vụ Điều này được thể hiện trong một mô hình đối tượng nghiệp vụ, mà qua đó có thể thấy rõ các vai trò đối tượng sẽ được làm rõ

Với sự xuất hiện của e-commerce (thương mại điện tử) mô hình hóa nghiệp

vụ cũng trở nên quan trọng hơn Các ứng dụng e-commerce được xây dựng để tự động hóa những quy trình nghiệp vụ

Một khi xác định được các mô hình nghiệp vụ, chúng ta cần phải thiết lập những mối quan hệ giữa các ca sử dụng hệ thống và những mô hình nghiệp vụ Điều này sẽ cho phép các nhà phân tích được thông báo khi có những thay đổi ở trong hệ thống

Tóm lại, mục đích của mô hình hóa nghiệp vụ là :

 Hiểu được cấu trúc và các hoạt động của tổ chức được triển khai hệ thống

 Hiểu được các vấn đề hiện tại trong tổ chức và xác định các vấn đề cần cải tiến

 Để đảm bảo rằng các khách hàng, người dùng cuối, và các nhà phát triển có sự hiểu biết chung về tổ chức đang thực hiện tin học hóa

 Thiết lập các yêu cầu hệ thống nhằm hỗ trợ tổ chức

Để đạt được những mục đích trên, luồng công việc mô hình hóa nghiệp vụ

mô tả một bức tranh tổng quát về tổ chức, từ đó xác định các quy trình (process), các vai trò (role), và các trách nhiệm của tổ chức này trong mô hình ca sử dụng nghiệp vụ (business use-case-model) và mô hình đối tượng nghiệp vụ (business object model)

2.1.3 Một số công cụ hỗ trợ việc mô hình hóa quy trình nghiệp vụ theo

kiến trúc SOA

Hiện nay, có rất nhiều các công cụ hỗ trợ cho việc mô hình hóa do tính cần thiết của quá trình mô hình hóa các quy trình nghiệp vụ trong các HTTT doanh nghiệp Tuy nhiên, chính vì có nhiều công cụ hỗ trợ việc mô hình hóa quy trình nghiệp vụ mà các công cụ này lại sử dụng những kí pháp riêng để mô tả nghiệp vụ nên người sử dụng các công cụ khác nhau đôi khi khó hiểu khi đọc các bản mô hình hóa khác nhau

vụ người ta thường sử dụng biểu đồ hoạt động (Activiti diagram) Tuy nhiên, biểu

đồ hoạt động của UML lại không hỗ trợ nhiều các trong các mô hình nghiệp vụ phức tạp và đòi hỏi tính thực tế cao, chính vì thế mà đã có nhiều công cụ hỗ trợ việc

mô hình hóa nghiệp vụ đã ra đời

2.1.3.2 BPEL

BPEL ( viết tắt của Web Services Business Process Execution Language BPEL4WS) là ngôn ngữ thực thi quy trình nghiệp vụ, hỗ trợ các dịch vụ tương tác với nhau nhằm thực hiện một nhiệm vụ nào đó

-BPEL là ngôn ngữ dựa trên XML, nó là sự kết hợp của hai ngôn ngữ WSFL - Web Services Flow Language của IBM và XLANG của Microsoft BPEL chỉ định chính xác thứ tự thực thi của các web service theo một quy trình nghiệp vụ

BPEL cung cấp một nền tảng tự động hóa cho các quá trình nghiệp vụ, cho phép triển khai thực hiện song song các hoạt động không trùng nhau thực hiện để

2.1.3.3 BPMN 2.0

Công cụ này mới được phát triển từ năm 2004 nhưng đã đáp ứng được nhiều yêu cầu của người sử dụng trong việc mô hình hóa hệ thống Đặc biệt BPMN 2.0 hỗ trợ rất mạnh các quy trình nghiệp vụ dạng thương mại, trong BPMN 2.0 không những hỗ trợ các mô hình hệ thống mà còn hỗ trợ mô hình hóa những quy trình nghiệp vụ thực tế Chính vì điều này mà BPMN 2.0 được sử dụng rộng rãi và trở thành một chuẩn mô hình hóa các quy trình nghiệp vụ hệ thống cũng như các quy trình nghiệp vụ thực tế

Tóm lại, để hỗ trợ cho việc mô hình hóa các quy trình nghiệp vụ hiện nay có rất nhiều công cụ, tuy nhiên trong khuôn khổ luận văn này sẽ chủ yếu đề cập đến

mô hình hóa quy trình nghiệp vụ bằng BPMN 2.0 Trong chương tiếp theo của luận văn sẽ tìm hiểu và tiến hành mô hình hóa một số quy trình nghiệp vụ bằng BPMN 2.0

2.2 Giới thiệu BPMN 2.0

2.2.1 Khái niệm cơ bản

BPMN là một mô tả đồ họa cho các quy trình nghiệp vụ cụ thể trong một mô hình nghiệp vụ

BPMN được phát triển bởi BPMI (Bussiness Process Management Intitinative), phiên bản 1.0 được phát hành vào tháng 5 năm 2004, và hiện đang được duy trì bởi Object Management Group kể từ khi 2 tổ chức sát nhập vào năm

2005 Tháng 1 năm 2009, phiên bản hiện hành của BPMN là 1.2, với một quá trình sửa đổi lớn cho quá trình cải tiến BPMN 2.0

BPMN là một chuẩn cho mô hình các quy trình nghiệp vụ và cung cấp các ký hiệu đồ họa cho các quy trình nghiệp vụ cụ thể cho Bussiness Process Diagram (BPD) – Sơ đồ quy trình nghiệp vụ, dựa trên một công nghệ lập biểu đồ tiến trình