Luận án Khung cộng tác đa dụng trong môi trường tính toán lưới

MỤC LỤC
LỜI CAM ĐOAN
LỜI CẢM ƠN
DANH MỤC CHỮ VIẾT TẮT
DANH MỤC BẢNG
DANH MỤC HÌNH VẼ
MỞ ĐẦU
DANH MỤC CÁC CÔNG TRÌNH ĐÃ CÔNG BỐ
TÀI LIỆU THAM KHẢO
PHỤ LỤC
DANH MỤC HÌNH VẼ
Hình 11: Sơ đồ một hoạt động.	18
Hình 12: Sự chuyển đổi giữa các mức của hoạt động.	19
Hình 13: Hai loại hoạt động tập thể.	20
Hình 14: Các mức cộng tác trong các hoạt động tập thể.	21
Hình 15: Kiến trúc lưới.	24
Hình 16: Kiến trúc Dịch Vụ lưới Mở (OGSA).	26
Hình 17: Cấu trúc của tổ chức ảo (Virtual Organization).	26
Hình 18: Quan hệ giữa OGSA và Globus Toolkit 4.	28
Hình 21: Cấu trúc của một hoạt động đơn	40
Hình 22: Góc nhìn chức năng của một hoạt động đơn A(S,T,O)	41
Hình 23: Biểu diễn một hoạt động đơn.	41
Hình 24: Các tình huống cho common-in(A1, A2).	43
Hình 25: Các tình huống cho in-out (A1, A2).	43
Hình 26: Ví dụ về biểu diễn đường dẫn path(A1, A2).	44
Hình 27: Các thành phần của hoạt động “Học một chủ đề”.	44
Hình 28: Các thành phần của hoạt động “Dạy học cho nhóm”.	45
Hình 29: Hoạt động tập thể "Học một chủ đề".	46
Hình 210: Hoạt động tập thể chỉnh.	46
Hình 211: Hoạt động Xử lý yêu cầu làm thẻ tín dụng.	47
Hình 212: Các cặp hoạt động tương đương.	49
Hình 213: Biểu diễn cho một kế hoạch.	54
Hình 214: Biểu diễn kế hoạch khả thi bằng đồ thị VÀ/HOẶC.	55
Hình 215: Biểu diễn kế hoạch không khả thi.	55
Hình 216: Biểu diễn kế hoạch không khả thi bằng đồ thị VÀ/HOẶC.	56
Hình 217: Kế hoạch cho việc xây dựng giải thuật sắp xếp.	57
Hình 218: Kế hoạch cho việc xây dựng Dịch vụ lưới của giải thuật sắp xếp.	58
Hình 219: Đường dẫn khả thi (biểu diễn bằng nét đứt).	59
Hình 220: Đường dẫn không khả thi (biểu diễn bằng nét đứt).	59
Hình 221: Đường dẫn khả thi thứ nhất cho Kế hoạch sắp xếp.	60
Hình 222: Đường dẫn khả thi thứ hai cho Kế hoạch sắp xếp.	60
Hình 223: Tổng quan về khung cộng tác đa dụng	65
Hình 224: Mô hình hóa dựa trên BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn trực quan).	71
Hình 225: Mô hình hóa dựa trên BPMN cho hoạt động “Xử lý yêu cầu làm thẻ” (phần biểu diễn bằng XML).	71
Hình 31: Phân cấp khối cấu trúc của một tiến trình	80
Hình 32: Ánh xạ của một số mẫu	81
Hình 33: Một sơ đồ tiến trình nghiệp vụ với các khối cấu trúc CAB	82
Hình 34: Mẫu Sequence	83
Hình 35: Mẫu Flow	83
Hình 36: Mẫu Switch	83
Hình 37: Mẫu Pick	84
Hình 38: Mẫu While	84
Hình 39: Rút gọn của hai “AND fork gateways” nối với nhau.	84
Hình 310: Rút gọn của hai “AND join gateways” nối với nhau	85
Hình 311: Rút gọn của hai AND gateways khác nhau nối với nhau (AND fork nối với AND join).	85
Hình 312 : Tiến trình BPMN.	92
Hình 313: Đồ thị biểu diễn tiến trình BPMN và kết quả của phép duyệt theo chiều sâu (DFS). Ở bước 1, DFS được sử dụng để phát hiện các vùng chu trình và vùng bất chu trình.	93
Hình 314: Các vùng đã phát hiện được sau bước 1. Ở đây phát hiện được ba vùng: R2 là vùng chu trình, còn R1 và R3 là hai vùng bất chu trình.	93
Hình 315: Các vùng đã phát hiện được sau bước 2 (một số nhãn cho các nút từ các hình trước đã cố tình được bỏ bớt từ hình này trở đi nhằm làm cho các hình vẽ đỡ rắc rối hơn)	94
Hình 316: Vùng cuối cùng được trả về R sau các bước cuối 3, 4 và 5	94
Hình 41: Kiến trúc khung lưới cộng tác.	99
Hình 42: Cấu trúc các modul của khung.	103
Hình 43: Sơ đồ của tiến trình BPEL Test-Factory GS-V2	105
Hình 44: Lược đồ tuần tự của hai handler.	111
Hình 45: Tiến trình BPEL thử nghiệm.	113
Hình 46: Kết quả chạy tiến trình BPEL.	113
Hình 47: Luồng công việc cho tiến trình xử lý việc nộp bài cho hội nghị.	121
Hình 48: Thiết kế chi tiết mô hình CABAC.	122
Hình 49: Chức năng chính của công cụ	127
Hình 410: Các bước thực hiện của công cụ	128
Hình 411: Cấu trúc của tệp deploy.xml	128
Hình 412: Cấu trúc của các tệp ví dụ.	130
Hình 413: Workflow của tiến trình trong ví dụ.	130
Hình 414: Tệp deploy.xml đã được tạo ra sau khi công cụ được chạy	131
Hình 415: Kết quả chạy ví dụ bằng công cụ soapUI.	131
DANH MỤC BẢNG
Bảng 21: Bảng giá trị cho hàm AND	50
Bảng 22: Một số kiểu dữ liệu và hàm phụ cho giải thuật 2-1.	63
Bảng 23: Cấu trúc của một đặc tả hoạt động	66
Bảng 24: Đặc tả hoạt động cho hoạt động Học một chủ đề	67
Bảng 25: Ánh xạ từ các thành phần của hoạt động sang luồng công việc.	69
Bảng 26: Mô hình hóa cho hoạt động “Xử lý yêu cầu làm thẻ” (phần đầu).	70
Bảng 41: Ánh xạ các khối chức năng vào các modul hệ thống.	102
Bảng 42: Các hàm tiện ích được sử dụng trong CABAC	120
Bảng 43: Biểu diễn các quy tắc trong Ví dụ 4-3	120
Bảng 44: Một số quy tắc truy nhập cho Ví dụ 4-4	122
Bảng 45: Ý nghĩa của các luồng dữ liệu trong Hình 4-8.	123
Bảng 46: So sánh các tính năng của mô hình CABAC và các mô hình khác.	126
LỜI CAM ĐOAN
Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi. Các kết quả trong luận án là trung thực và chưa từng được công bố trong bất kỳ công trình nào khác.
Giáo viên hướng dẫn
TS. Nguyễn Hữu Đức
Hà nội, ngày tháng năm 2015
Tác giả
Nguyễn Thanh Bình
GS. TS. Nguyễn Thanh Thủy
DANH MỤC CHỮ VIẾT TẮT 
Tên viết tắt
Tên đầy đủ
Ý nghĩa
ABAC
Attribute-Based Access Control
Mô hình điều khiển truy nhập dựa trên thuộc tính.
AT
Activity Theory
Lý thuyết Hoạt động: là một lý thuyết đã có một lịch sử khá dài (ra đời từ những năm 1920-1930.) với khởi đầu là các nghiên cứu của ba nhà nghiên cứu theo trường phái lịch sử văn hóa (cultural-historical school) của ngành tâm lý học Nga là L. S. Vygotsky, A. N. Leont'ev và A. R. Luria. Lý thuyết này được đưa ra nhằm giải thích các trạng thái tâm lý của con người thông qua các hoạt động có chủ đích của họ. 
Axis
Apache eXtensible Interaction System
SOAP engine và công cụ phần sụn của dịch vụ Web (Web Service middleware tool). Phiên bản 2 của nó có tên gọi Axis2 [4] có nhiều cải tiến quan trọng so với phiên bản trước.
BPEL
Business Process Execution Language
Ngôn ngữ luồng công việc cho phép biểu diễn các tiến trình nghiệp vụ ở nhiều mức, nhất là ở mức thấp mà có thể được thực thi tự động.
BPMN
Business Process Modeling Notation (Version 1)
Business Process Model & Notation (Version 2)
Ngôn ngữ luồng công việc cho phép mô hình hóa các tiến trình nghiệp vụ ở mức cao (mức phân tích và thiết kế nghiệp vụ). Nó bao gồm sơ đồ (biểu diễn hướng người dùng), và văn bản (để lưu trữ và xử lý tự động, sử dụng ngôn ngữ XML).
CDG
Collaborative Design Grid
Là một khung (phân hệ) nhằm giải quyết hai vấn đề trong thiết kế cộng tác: chia sẻ tài nguyên và cộng tác phân tán về mặt địa lý. Kiến trúc này chủ yếu dựa trên OGSA, và được cài đặt bằng các dịch vụ lưới trong Globus Tookit 3, với ba công nghệ chính: Thiết kế Cộng tác có trợ giúp của Máy tính (CSCD - Computer Supported Collaborative Design), tính toán lưới và cổng thông tin Web (Web portal).
CSCW
Computer Supported Collaborative Work
Công việc cộng tác có trợ giúp của máy tính.
ĐKTN
Điều khiển truy nhập
Cụm từ viết tắt này được sử dụng ở phần 4.2.2 khi nói về các mô hình điều khiển truy nhập.
EPR
EndPoint Reference
Tham chiếu Điểm cuối: là sự kết hợp giữa địa chỉ dịch vụ lưới và tài nguyên tương ứng. 
GC
Grid Computing
Tính toán lưới.
GCF-MD
Grid-based Collaborative Framework for Mobile Devices
Khung lưới cộng tác cho các thiết bị di động: là nền tảng cho phép các thiết bị di động có thể cộng tác với nhau để giải quyết các bài toán có khối lượng tính toán lớn
G-ODE
Grid Orchestration Director Engine
BPEL engine được luận án phát triển dựa trên ODE engine của Apache nhằm cung cấp thêm khả năng gọi dịch vụ lưới.
GS
Grid Services
Dịch vụ lưới.
MAC
Mandatory Access Control
Điều khiển truy nhập bắt buộc. Bắt buộc (mandatory) với nghĩa là các quyền truy nhập đã bị quy định cứng bởi hệ thống, và nó không thể bị thay đổi bởi người dùng hoặc bởi chương trình của người dùng.
ODE
Orchestration Director Engine
Một BPEL engine (module phần mềm giúp thực thi các tệp BPEL) mã nguồn mở của Apache [75].
OCGSA
Open Collaborative Grid Service Architecture
Kiến trúc dịch vụ lưới cộng tác mở.
OGSA
Open Grid Services Architecture
Kiến trúc dịch vụ lưới mở.
PTKT
Phụ Thuộc Khả Thi
Phụ thuộc giữa các hoạt động, được định nghĩa trong phần 2.1.3.
RBAC
Role-Based Access Control
Mô hình điều khiển truy nhập dựa trên vai trò.
SOA
Service Oriented Architecture
Kiến trúc Hướng Dịch vụ.
SOAP
Simple Object Access Protocol
Giao thức truy nhập đối tượng đơn giản.
SPM
Standard Process Models
Mô hình tiến trình chuẩn: là các sơ đồ khái quát của các Ngôn ngữ tiến trình nghiệp vụ (Business Process Languages) như BPMN và UML (Unified Modeling Language). 
VO
Virtual Organization
Tổ chức ảo.
XACML
eXtensible Access Control Markup Language
Ngôn ngữ đánh dấu điều khiển truy nhâp mở rộng, được sử dụng để định nghĩa các quy tắc truy nhập trong những hệ thống điều khiển truy nhập dựa trên vai trò (RBAC), hay dựa trên thuộc tính (ABAC).
WF
Workflow
Luồng công việc
WS
Web Service
Dịch vụ Web.
WSRF
Web Service Resource Framework
Khung tài nguyên dịch vụ Web: một chuẩn mở rộng cho dịch vụ Web (Web services) nhằm quản lý các dịch vụ Web có trạng thái.
LỜI CẢM ƠN
Luận án này là kết quả của một quá trình lao động khá lâu dài và vất vả, ngoài những nỗ lực của bản thân tác giả, còn có sự giúp đỡ nhiệt tình của rất nhiều người. Qua đây, tác giả xin trân trọng gửi những lời cảm ơn chân thành và sâu sắc nhất đến tất cả mọi người. 
Đặt biệt, tác giả xin được bày tỏ lòng biết ơn sâu sắc đến những người Thầy hướng dẫn của mình, trực tiếp hay gián tiếp, kể cả trong và ngoài nước, gồm các Thầy:
Giáo sư Nguyễn Thanh Thủy, trường Đại học Công nghệ, Đại học Quốc gia Hà Nội,
Tiến sĩ Nguyễn Hữu Đức, trường Đại học Bách khoa Hà Nội,
Giáo sư Hoàng Bằng Đoàn, trường Đại học Công nghệ Sydney (UTS), Úc,
Giáo sư Tharam Dillon, trường Đại học Công nghệ Sydney (UTS), Úc,
Tiến sĩ George Feuerlicht, trường Đại học Công nghệ Sydney (UTS), Úc.
Tác giả cũng xin được bày tỏ sự cảm kích vô hạn đối với tất cả các Thầy, Cô giáo, nơi tác giả được may mắn học tập và nghiên cứu tại Trường Đại Học Bách Khoa Hà Nội và Trường Đại Học Công Nghệ Sydney (Úc). 
Trong quá trình nghiên cứu, tác giả cũng may mắn được làm việc tại Trung Tâm Tính Toán Hiệu Năng Cao, thuộc Viện Nghiên Cứu Quốc Tế về Khoa Học Tính Toán (ICSE), Trường ĐHBK Hà Nội. Tại đây, tác giả đã nhận được sự giúp đỡ to lớn và nhiệt tình của rất nhiều người trong Trung tâm, từ Thầy Nguyễn Hữu Đức Giám đốc Trung tâm, cho đến các nhân viên và các sinh viên thực tập, trong đó đặc biệt là hai sinh viên Nguyễn Văn Cường và Nguyễn Trường Minh, lớp KSTN K52, đã hỗ trợ tác giả trong một phần cài đặt công cụ G-ODE. 
Nhân đây, tác giả cũng xin được bày tỏ lời cảm ơn sâu sắc đến ban lãnh đạo và những đồng nghiệp nơi tác giả đang công tác là Bộ môn Điện tử - Kỹ thuật máy tính, Viện Điện Tử - Viễn Thông, Trường Đại Học Bách Khoa Hà Nội.
Và cuối cùng, tác giả xin bày tỏ lòng biết ơn sâu sắc đến toàn thể gia đình, bạn bè, những người thân về sự giúp đỡ, động viên không ngừng, trong mọi hoàn cảnh dù khó khăn đến đâu.
MỞ ĐẦU
	Các hoạt động của con người, theo một cách đơn giản, có thể được chia thành hai loại: hoạt động cá nhân và hoạt động tập thể. Trong hoạt động tập thể, có sự tham gia của nhiều người để hoàn thành một mục tiêu nào đó, cần có các biện pháp thích hợp để phối hợp công việc của các thành viên, sao cho cuối cùng tập thể đó có thể hoàn thành được mục tiêu đề ra. Tùy theo lĩnh vực hoạt động, cách thức tổ chức và mục tiêu của hoạt động, có thể tồn tại các biện pháp phối hợp khác nhau với các tên gọi khác nhau như: cơ chế điều phối, công cụ cộng tác, bộ lập lịch, v.v. Trước đây, đối với các hệ thống thông tin nhằm quản lý các hoạt động nghiệp vụ tập thể, các cơ chế cộng tác thường được thiết kế và cài đặt như là một bộ phận không thể tách rời của qui trình nghiệp vụ. Thậm chí, hoạt động cộng tác thường chỉ được xem như một bước tất yếu trong toàn bộ qui trình nghiệp vụ, chứ chưa được xem như một đối tượng độc lập để có thể được tái sử dụng nhiều lần. Nói cách khác, vấn đề hỗ trợ cộng tác chưa được giải quyết trực tiếp và có hệ thống. Đối với các hệ thống quy mô nhỏ với số lượng người dùng tương đối ít và số lượng thông tin phụ thuộc cần trao đổi không nhiều, vấn đề này có thể dễ dàng được giải quyết. Tuy nhiên, với những hệ thống lớn từ hàng chục đến hàng trăm người sử dụng trở lên, số lượng dữ liệu phụ thuộc, cũng như tính chất các mối quan hệ giữa những người dùng cũng nhiều và phức tạp, vấn đề cộng tác trở nên không đơn giản. Điều này đặt ra nhiệm vụ phải giải quyết vấn đề cộng tác một cách bài bản, để từ đó có thể xây dựng những công cụ cộng tác đa dụng, mềm dẻo và hiệu quả.
	Cho đến nay, trong lĩnh vực nghiên cứu về vấn đề cộng tác, có một số nền tảng lý thuyết đã được phát triển như: Coordination Mechanisms [24] (Cơ chế Điều phối) và Common Artifacts [66] (Các công cụ thông dụng) và Activity Theory [58] [20] (Lý thuyết Hoạt động). Trong số này, Lý thuyết Hoạt động, mặc dù ra đời sớm nhất và trọng tâm nghiên cứu không phải là sự cộng tác, nhưng trong thời gian gần đây, lý thuyết này đã thu hút được nhiều sự chú ý từ một số lĩnh vực nghiên cứu liên quan đến khả năng cộng tác như: Tương tác Người-Máy (human-computer interaction) [51], Công việc cộng tác có trợ giúp của máy tính (Computer Supported Collaborative Work) [20]. Có thể đưa ra một số lý giải cho vấn đề này. Đầu tiên, lý thuyết này cho một cài nhìn toàn diện về hoạt động, nhất là các hoạt động tập thể cần có sự cộng tác. Thứ hai, nó đã giải thích một cách rõ ràng bản chất của cộng tác trong các hoạt động có tính cộng tác và từ đó, các cơ chế cộng tác và điều phối cần thiết có thể được mô hình hóa, thiết kế và cài đặt. Tuy nhiên, cho đến nay, dường như lý thuyết này vẫn thiếu sự mô tả hình thức cho các khái niệm đưa ra. Điều này dẫn đến một số vấn đề: (1) không rõ ràng trong các khái niệm trừu tượng (như hoạt động (activity), hành động (action), kế hoạch (plan),v.v); (2) một số vấn đề còn mở liên quan đến cách biểu diễn hoạt động, quan hệ giữa hoạt động và kế hoạch hành động, v.v chưa có câu trả lời thỏa đáng. Điều này làm hạn chế khả năng phát triển và ứng dụng của lý thuyết hoạt động trong thực tế. 
	Theo nghĩa thông thường, sự cộng tác được hiểu là khi có hai hay nhiều chủ thể (có thể là con người hoặc máy tính) phối hợp với nhau để thực hiện một mục tiêu chung nào đó. Nguồn gốc của mọi sự cộng tác là ở sự phân chia công việc, thường được mô tả dưới dạng một kế hoạch (trong thực tiễn, kế hoạch có thể tường minh dưới dạng một bản hợp đồng có chữ ký của các bên tham gia, nhưng cũng có thể chỉ là ngầm định như phân công bằng miệng rồi mọi người tự giác thực hiện). Kế hoạch đó sẽ quyết định cách thức và các công cụ cộng tác cần thiết cho các thành viên. Khi kế hoạch có sự thay đổi sẽ dẫn đến sự thay đổi trong việc cộng tác. Do đó, việc quản lý tốt kế hoạch sẽ giúp phát hiện và quản lý sự cộng tác tốt hơn. Tìm hiểu bản chất kế hoạch hành động, ta thấy có nhiều điểm tiếp cận tương đồng như trong lý thuyết hoạt động. Lý thuyết này tỏ ra rất thích hợp cho việc giải thích quá trình lập kế  ... n hóa và linh hoạt [68]. 
Mô hình cho các tương tác nghiệp vụ thường đòi hỏi dãy các trao đổi thông báo ngang hàng, theo kiểu hỏi-đáp hoặc một chiều có thông tin trạng thái và tương tác trong một thời gian lâu dài giữa hai hay nhiều đối tác tham gia. Do vậy, một mô tả hình thức cho các giao thức trao đổi thông báo như vậy là cần thiết để định nghĩa các tương tác nghiệp vụ được sử dụng trong các tiến trình nghiệp vụ. WS-BPEL (Web Services - Business Process Execution Language) được ra đời chính là nhằm mục đích này. Nó là một ngôn ngữ tiêu chuẩn cho phép định nghĩa các tiến trình nghiệp vụ mới thông qua việc kết hợp và tương tác của các tiến trình nghiệp vụ (hay các dịch vụ) hiện có. 
Khởi đầu nó có cái tên là BPEL for Web services, BPEL4WS, rồi sau đó chuyển thành WS-BPEL. Gần đây, BPEL đang trở thành một trong các ngôn ngữ chuẩn hóa thông dụng để cấu thành các Web service.
BPEL có thể được dùng để định nghĩa hai loại tiến trình: trừu tượng và khả thi. Một tiến trình trừu tượng chủ yếu hướng tới khía cạnh nghiệp vụ không quan tâm làm cho nó có thể thực thi được, và nó sẽ được khai báo tường minh là “abstract”. Trong khi đó, tiến trình khả thi sẽ được đặc tả chi tiết và đầy đủ để nó có thể thực thi được. 
WS-BPEL định nghĩa một mô hình và một cú pháp nhằm mô tả hành vi của một tiến trình nghiệp vụ dựa trên sự tương tác giữa nó và các đối tác. Những tương tác này xuất hiện thông qua các giao diện dịch vụ Web và cấu trúc của quan hệ này tại mức giao diện được đóng gói trong một đối tượng được gọi là liên kết đối tác. Tiến trình BPEL sẽ xác định những tương tác với các đối tác này sẽ được phối hợp như thế nào để đạt được mục tiêu về nghiệp vụ, cũng như các trạng thái và lôgic cần thiết cho sự phối hợp này. 
Ngoài ra, WS-BPEL cũng đưa vào những cơ chế để giải quyết các trường hợp ngoại lệ và xử lý lỗi, cũng như cơ chế bồi thường cho các hoạt động nghiệp vụ trong trường hợp xuất hiện ngoại lệ hay khi có yêu cầu từ đối tác.
Các mục tiêu thiết kế của BPEL
Ban đầu khi thiết kế BPEL (lúc đó còn được gọi là BPEL4WS (BPEL For Web Services)), các nhà thiết kế đã đề ra mười mục tiêu cho nó [33]:
Mục tiêu 1: BPEL4WS định nghĩa các tiến trình nghiệp vụ mà tương tác với các thực thể bên ngoài thông qua các thao tác của dịch vụ WEB được định nghĩa bởi chuẩn WSDL 1.1 và bản thân chúng cũng được biểu diễn như là các dịch vụ WEB được định nghĩa bởi WSDL 1.1. Những tương tác này là “trừu tượng” theo nghĩa là các phụ thuộc là ở định nghĩa ở portType, chứ không phải là ở định nghĩa ở port.
Mục tiêu 2: BPEL4WS định nghĩa các tiến trình nghiệp vụ sử dụng ngôn ngữ dạng XML (XML based language). BPEL4WS không quan tâm đến những biểu diễn đồ thị của các tiến trình, cũng như không xác định phương pháp luận cụ thể nào cho các tiến trình.
Mục tiêu 3: BPEL4WS nên định nghĩa một tập các khái niệm về sự phối hợp các dịch vụ WEB như là một phương tiện sẽ được sử dụng bởi cả hai loại khung nhìn bên ngoài (trừu tượng) và bên trong (khả thi) của tiến trình nghiệp vụ.
Mục tiêu 4: BPEL4WS nên cung cấp cả hai chế độ điều khiển là theo kiểu phân cấp và theo kiểu đồ thị và cho phép sử dụng trộn lẫn cả hai cách này một cách liền mạch nhất. Điều này sẽ giúp giảm được sự phân mảnh của không gian mô hình hóa tiến trình. 
Mục tiêu 5: BPEL4WS cung cấp các một cách giới hạn các hàm thao tác dữ liệu sao cho chúng đủ để thực hiện các thao tác dữ liệu đơn giản cho việc định nghĩa các dữ liệu liên quan đến tiến trình và các luồng điều khiển. 
Mục tiêu 6: BPEL4WS nên hỗ trợ một cơ chế định danh cho các thể hiện của tiến trình mà cho phép xác định định danh của thể hiện tiến trình tại mức thông báo ứng dụng. Định danh của thể hiện nên do đối tác định nghĩa và có thể thay đổi theo thời gian.
Mục tiêu 7: BPEL4WS nên hỗ trợ việc sinh ra và kết thúc ngầm định các thể hiện của tiến trình như một cơ chế quản lý vòng đời cơ bản. Các thao tác quản lý vòng đời nâng cao như tạm dừng, hồi phục có thể được bổ sung trong các phiên bản sau.
Mục tiêu 8: BPEL4WS nên định nghĩa một mô hình giao tác thực thi trong thời gian dài mà dựa trên các kỹ thuật đã được kiểm chứng qua thực tiễn như hành động bù đắp và phân phạm vi nhằm hỗ trợ việc khắc phục sự cố cho các phần của các tiến trình nghiệp vụ thực thi trong thời gian dài. 
Mục tiêu 9: BPEL4WS nên sử dụng dịch vụ WEB như là mô hình để tách và ghép các tiến trình. Kết hợp cách tiếp cận này với chuẩn WS-Policy sẽ làm mô hình này mạnh mẽ hơn.
Mục tiêu 10: BPEL4WS nên được xây dựng dựa trên các chuẩn dịch vụ WEB tương thích và các đề xuất tiêu chuẩn một cách tối đa theo cách modul và có thể kết hợp được. Chỉ trong trường hợp chưa có chuẩn hoặc đề xuất phù hợp, một đặc tả tương ứng mới cần được phát triển như một đặc tả của BPEL4WS hoặc một đề xuất tiêu chuẩn Dịch vụ WEB riêng biệt. 
Các khái niệm cơ bản
Có hai cách tiếp cận trong việc cấu thành các dịch vụ Web: orchestration và choreography. Theo cách orchestration, chỉ một dịch vụ đóng vai trò là dịch vụ chính sẽ gọi các dịch vụ khác. Thế nên, chỉ dịch vụ chính này biết về trình tự các activity, trạng thái của các yêu cầu và trả lời của các dịch vụ được gọi. Ngược lại, trong cách choreography không có dịch vụ chính. Sự phản ứng giữa các dịch vụ do cơ chế điều phối hỗ trợ. BPEL hiện nay chỉ hỗ trợ cách orchestration.
Trong BPEL, dịch vụ chính này được gọi là tiến trình nghiệp vụ (Business Process, BP) và các dịch vụ khác được gọi là đối tác. Có hai loại đối tác trong BPEL: đối tác được gọi là đối tác được gọi bởi dịch vụ chính và đối tác client là đối tác sẽ gọi dịch vụ chính. Mối liên kết tiềm tàng giữa một đối tác và một BP được gọi là liên kết đối tác (Partner Link, PL). Giao diện giữa một tiến trình và một đối tác là thông qua một portType mà đề xuất các thao tác. BPEL hỗ trợ hai lớp thao tác: input-only và input-output. 
Cấu tạo của một tiến trình BPEL
Các thành phần chính của một tiến trình nghiệp vụ được mô tả trong Hình B-3
	Hình B-3. Các thành phần chính của một tiến trình nghiệp vụ
Trong Hình B-4 đưa ra một tiến trình nghiệp vụ cụ thể thực hiện việc giải một phương trình bậc 2.
Hình B-4. Tiến trình BPEL giải phương trình bậc 2.
Các BPEL engine
BPEL engine là một phân hệ phần mềm có nhiệm vụ thực thi các tiến trình nghiệp vụ được biểu diễn bằng BPEL. Phân hệ này thường được tích hợp trong những hệ thống phần mềm có hỗ trợ BPEL.
Phần này sẽ giới thiệu tóm tắt về ba loại BPEL engine đang được sử dụng rộng rãi hiện nay là ActiveBPEL engine, BPEL engine trong JBI và ODE engine của Apache. 
ActiveBPEL engine Phiên bản 5.0 mới nhất của engine này là cài đặt mã nguồn mở cho BPEL engine, được viết bằng JAVA. Nó hỗ trợ cả hai chuẩn BPEL4WS 1.1 và WS-BPEL 2.0. Một trong những nhược điểm của engine này là quá trình khai thác các tiến trình BPEL không được tự động và rất phức tạp trong việc tạo tệp khai thác. 
BPEL engine trong JBI Engine này chỉ được tích hợp trong môi trường phát triển ứng dụng Netbeans. Một trong những hạn chế lớn nhất của engine này hiện nay là nó chỉ hỗ trợ chuẩn BPEL4WS 1.1 mà không có hỗ trợ cho chuẩn WS-BPEL 2.0.
ODE engine ODE Engine (Orchestration Director Engine) là một BPEL engine mã nguồn mở của Apache. Phiên bản mới nhất hiện nay là 1.3 có nhiều đặc tính quan trọng như:
Hỗ trợ cả hai chuẩn BPEL4WS 1.1 và WS-BPEL 2.0.
Hỗ trợ 2 lớp truyền thông: Web service http transport của Axis2 và ServiceMix của JBI. 
Nó có thể được tích hợp dễ dàng với gần như tất cả các lớp truyền thông nhờ giao diện API với engine.
Cho phép việc khai thác nhanh các tiến trình BPEL. Điều này có nghĩa là chỉ cần sao chép các tệp cần thiết vào thư mục khai thác (do engine quy định trước), sau đó engine đang chạy sẽ tự động phát hiện ra các tệp này, rồi dịch và làm chúng sẵn sàng cho việc sử dụng.
Bản ODE hiện nay không nhận ra tất cả các thông tin cần thiết được gửi đến từ các tiến trình BPEL và cũng không hỗ trợ việc gọi các dịch vụ lưới. Chương 4 sẽ khảo sát vấn đề này một cách chi tiết hơn và đưa ra giải pháp của luận án.
BPMN
Giới thiệu
BPMN (đầu tiên được gọi là “Business Process Modeling Notation” trong phiên bản 1 [69]. Sang phiên bản 2, nó được đổi thành “Business Process Model & Notation” [70]) là một hệ thống ký hiệu sử dụng đồ họa, dùng để mô hình hóa các tiến trình nghiệp vụ. Nó được phát triển bởi BPMI (Business Process Management Initiative) và OMG (Object Management Group) với mục đích chính là tạo ra một hệ thống ký hiệu thống nhất và dễ hiểu cho tất cả những người sử dụng các tiến trình nghiệp vụ, từ những người phân tích nghiệp vụ bắt đầu tạo ra bản phác thảo cho tiến trình nghiệp vụ, cho đến những người phát triển các công nghệ để cài đặt việc thực thi các tiến trình nghiệp vụ đó. BPMN cũng hướng đến mục tiêu có thể tạo ra các tiến trình tự động mà có thể được thực thi trên máy tính, qua việc hỗ trợ tối đa khả năng chuyển đổi thành các tiến trình nghiệp vụ được biểu diễn bằng BPEL [99]. Hiện nay, BPMN đã được chuẩn hóa và được hỗ trợ của hơn 70 công ty trên thế giới, trong đó có nhiều công ty lớn. 
Trong hệ thống được xác định trong luận án, BPMN được lựa chọn làm công cụ để xây dựng các kế hoạch (plan), vì vai trò của các kế hoạch chính là các tiến trình nghiệp vụ ở dạng khởi đầu. 
Các loại mô hình trong BPMN
Từ phiên bản 2, BPMN hỗ trợ ba loại mô hình:
Tiến trình (hay Orchestration): loại mô hình này lại có thể bao gồm ba loại:
Tiến trình nghiệp vụ riêng tư không thực thi được. 
Tiến trình nghiệp vụ riêng tư thực thi được. 
Tiến trình nghiệp vụ công. 
Choreographies
Tiến trình nghiệp vụ cộng tác
Ví dụ về các loại mô hình trên được cho trong các Hình B-5 – B-8 [70].
Hình B-5. Tiến trình nghiệp vụ riêng tư.
Hình B-6. Tiến trình nghiệp vụ công.
Hình B-7. Choreography.
Hình B-8. Tiến trình nghiệp vụ cộng tác
Các thành phần cơ bản của BPMN
Thành phần cơ bản nhất của BPMN là các “biểu đồ tiến trình nghiệp vụ” (Business Process Diagram - BPD). Nó là một loại lưu đồ được điều chỉnh để mô hình hóa các tiến trình nghiệp vụ. Một BPD được cấu thành từ nhiều phần tử đồ họa. Có khá nhiều phần tử đồ họa trong BPMN và được chia làm năm nhóm:
Các đối tượng luồng 
Dữ liệu 
Các đối tượng kết nối 
Các làn (Swimlanes)
Các ký hiệu gia công (Artifacts) 
Các đối tượng luồng 
Gồm có ba đối tượng cơ bản nhất của BPD là Event, Activity và Gateway (xem Hình B-9).
Hình B-9. Các loại đối tượng luồng cơ bản
Sự kiện: được biểu diễn bởi hình tròn, biểu thị cho điều gì đó xảy ra trong quá trình hoạt động của tiến trình nghiệp vụ, và gây ảnh hưởng đến luồng hoạt động này. Có ba loại sự kiện: Bắt đầu, Trung gian và Kết thúc.
Hoạt động: là thuật ngữ chung để biểu thị cho công việc cần được thực hiện. Nó được biểu diễn bởi hình chữ nhật có góc tròn. Có hai loại Hoạt động là Nhiệm vụ là loại hoạt động nguyên tố và Tiến trình con là loại hoạt động phức mà bên trong có chức các hoạt động khác.
Rẽ nhánh: được dùng để biểu diễn việc hợp hay tách các luồng hoạt động. Nó được biễu diễn bởi một hình thoi. Có khá nhiều loại gateway được cung cấp trong BPMN nhằm biểu diễn nhiều cách điều khiển các luồng khác nhau (xem Hình B-10).
Hình B-10. Các loại gateway trong BPMN
Dữ liệu
Có bốn phần tử dữ liệu trong BPMN (xem B-11 cho cách ký hiệu các phần tử):
Đối tượng dữ liệu: biểu diễn thông tin được các hoạt động sử dụng để thực thi được hoặc kết quả chúng tạo ra
Dữ liệu vào: biểu diễn dữ liệu đầu vào cho các tiến trình
Dữ liệu ra: biểu diễn dữ liệu đầu ra cho các tiến trình
Kho dữ liệu: biểu diễn dữ liệu cần được lưu trữ.
Hình B-11. Các loại phần tử dữ liệu
Các đối tượng kết nối
Khi các đối tượng luồng cần kết nối với nhau, chúng sẽ sử dụng các đối tượng kết nối. Có ba loại đối tượng kết nối là: Luồng tuần tự, luồng thông báo và liên kết (xem hình B-12).
Hình B-12. Các loại đối tượng kết nối cơ bản
Các làn 
Các làn là công cụ cho phép tổ chức hay chia các hoạt động trong tiến trình thành các nhóm. Có hai loại làn trong BPMN là Pool và Lane (xem Hình B-13):
Pool: là công cụ cho phép chia các tiến trình theo nhóm các thành viên. Mỗi Pool sẽ đại diện cho một thành viên trong tiến trình.
Lane: là công cụ phân chia bên trong Pool. Tức là mỗi Pool có thể bao gồm một hoặc nhiều Lane.
Hình B-13. Các loại Làn 
Các ký hiệu gia công (Artifacts) 
Ngoài các kí hiệu cơ bản ở trên, BPMN còn cho phép người mô hình và các công cụ phát triển mở rộng thêm các thành phần ký hiệu mới và chúng được gọi là các ký hiệu gia công. Có hai loại ký hiệu gia công đã được định nghĩa trước trong BPMN là Nhóm và Chú thích (xem Hình B-14).
Hình B-14. Các ký hiệu gia công đã được định nghĩa sẵn.
Một số công cụ hỗ trợ BPMN
Bonita Open Solution: Bonita Open Solution phiên bản 5 một môi trường hỗ trợ BPMN2, mã nguồn mở, là sản phẩm của hãng BonitaSoft [23].
jBPM: jBPM [46] là sản phẩm mã nguồn mở của Jboss.
Activity BPM
PHỤ LỤC C: AXIS 2
Axis2 [4] là phiên bản mới của Axis (Apache eXtensible Interaction System), là một SOAP engine và một công cụ phần sụn của dịch vụ Web. Nó là một hệ thống quản lý thông báo SOAP với thiết kế kiến trúc kiểu modul. Khung Axis2 (Axis2 Framework) được xây dựng dựa trên bẩy modul cốt lõi. Các module khác không phải cốt lõi được phân lớp trên đỉnh của các modul cốt lõi này [4]. Trong số bẩy modul cốt lõi, có hai modul Xử lý XML và Xử lý SOAP là có quan hệ đến nghiên cứu của luận án.
Modul xử lý XML: xử lý các thông báo SOAP là nhiệm vụ quan trọng nhất và phức tạp nhất trong Axis2 và hiệu quả của nó là nhân tố quan trọng nhất quyết định hiệu năng. Axis2 sử dụng mô hình AXIOM (AXis Object Model) để cung cấp một giao diện lập trình ứng dụng (API) đơn giản nhằm tăng cường hiệu năng xử lý SOAP và XML của Axis2 so với Axis.
Modul xử lý SOAP: modul này kiểm soát thứ tự thực thi các xử lý. Bên cạnh việc định nghĩa sẵn các pha thực thi khác nhau, modul này cũng hỗ trợ khả năng có thể mở rộng bằng cách cho phép người sử dụng mở rộng Mô hình Xử lý tại các vị trí plug-in đặc biệt. Mô hình Xử lý SOAP được minh họa trong Hình C-1.
Hình C-1. Mô hình Xử lý SOAP của Axis2
Hai hoạt động cơ bản của một bộ xử lý SOAP là gửi và nhận các thông báo SOAP. Để hỗ trợ các hoạt động này, kiến trúc trên cung cấp hai pipe (hay luồng xử lý thông báo) được gọi là In Pipe (pine nhập) và Out Pipe (pipe xuất). Cài đặt cho hai pipe này là do định nghĩa của hai phương thức (methods) send() và receive() trong Axis2 engine.
Khả năng có thể mở rộng của mô hình xử lý SOAP được cung cấp bởi các handler. Khi xử lý một thông báo SOAP, chỉ có các handler mà đã được đăng ký mới được thực thi. Axis2 hỗ trợ ba phạm vi mà các handler có thể đăng ký vào là toàn cục, dịch vụ hoặc thao tác. Chuỗi handler cuối cùng sẽ được tính toán bằng việc tổng hợp các handler từ tất cả các phạm vi.
Hoạt động như các bộ chặn, các handler xử lý các bộ phận của thông báo SOAP và cung cấp các dịch vụ bổ sung. Các giai đoạn khác nhau của pipe được gọi là pha (phase), mà cung cấp một cơ chế nhằm xác định trật tự của các handler. Một handler luôn chạy trong một pha chuyên biệt. Cả hai pipe đều có các pha được xây dựng sẵn, cũng như các chỗ dành cho “các pha của người dùng”, đến người dùng có thể định nghĩa.