BÀI BÁO CÁO THỰC TẬP-NGHIÊN CỨU WEB SERVICES COMPOSITION SỬ DỤNG BPEL4WS

Việc kết hợp các dịch vụ trong mô hình SOA với quản lý các tiến trình nghiệp vụ là một giải pháp cho việc xây dựng các hệ thống tích hợp.Vì thế ngôn ngữ BPEL4WS ra đời để đáp ứng cho giả

-BÁO CÁO TỐT NGHIỆP HỆ ĐẠI HỌC

Ngành : Công Nghệ Thông Tin Hệ : Chính quy

Năm 2009

Qua 4 năm học tập,được sự tận tình chỉ bảo của các thầy cô trong Học viện đã trang bị cho em những kiến thức để có hành trang vào cuộc sống.Trong 6 tháng qua em xin chân thành cảm ơn thầy Tân Hạnh đã hướng dẫn em làm đề tài này và các bạn trong lớp cũng tạo điều kiện để em hoàn thành luận văn

Do thời gian làm đồ án và kiến thức còn hạn chế nên không thể tránh khỏi những sai sót Em rất mong nhận được sự đóng góp ý kiến của Quý thầy

cô và các bạn sinh viên

Em xin gửi đến Quý thầy cô lời chúc sức khỏe và thành công

Em xin chân thành cảm ơn!

Sinh viên: Hoàng Xuân Tuấn

LỜI NÓI ĐẦU

Ngày nay, công nghệ thông tin đang là nền công nghệ mũi nhọn trong chiến lược phát triển kinh tế, xây dựng đất nước của hầu hết các quốc gia Với sự phát triển của internet và với xu thế hội nhập chung của toàn thế giới, các tổ chức, các cơ sở doanh nghiệp cần bắt tay, phối hợp hoạt động và chia sẻ tài nguyên với nhau để nâng cao hiệu quả hoạt động

Hệ thống của các tổ chức doanh nghiệp ngày càng trở nên cồng kềnh hơn với việc triển khai hàng loạt các ứng dụng phân tán dựa trên nhiều hệ nền, kỹ thuật, công nghệ khác nhau Những nghiên cứu gần đây cho thấy rằng: các khó khăn trong việc tích hợp các hệ thống có thể được khắc phục bằng cách định nghĩa thêm một tầng trừu tượng cho các hệ thống tin học hiện có và mới xây dựng Tầng này sẽ được xây dựng dựa trên các chuẩn của web service

Công nghệ web service có thể được dùng để xây dựng cầu nối giao tiếp cho các

hệ thống xây dựng trên những hệ nền, sử dụng những công nghệ hay chuẩn khác xa nhau, như là NET, J2EE, CORBA, WebSphere MQ, hay các ứng dụng đóng gói

Việc kết hợp các dịch vụ trong mô hình SOA với quản lý các tiến trình nghiệp

vụ là một giải pháp cho việc xây dựng các hệ thống tích hợp.Vì thế ngôn ngữ BPEL4WS ra đời để đáp ứng cho giải pháp trên BPEL4WS được xây dựng dựa trên ngôn ngữ WSFL (Web Service Flow Language) của IBM và ngôn ngữ XLANG của Microsoft, nó kế thừa được những tính năng nổi trội của hai ngôn ngữ này (tính có cấu trúc của XLang và khả năng mô hình hóa của WSFL )

Mục tiêu của đề tài này …

Sinh viênHoàng Xuân Tuấn

MỤC LỤC

Contents

CƠ SỞ TẠI THÀNH PHỐ HỒ CHÍ MINH 1

BÁO CÁO TỐT NGHIỆP HỆ ĐẠI HỌC 1

Hình1.1 Mô hình CORBA………9 8

CHƯƠNG I:HIỆN TRẠNG 10

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

Hình1.1 Mô hình CORBA 11

Hình 1.2 Mô hình EJB 12

Hình 1.3 Mô hình DCOM 12

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

1.3 SOA và web service giải quyết vấn đề tích hợp như thế nào: 13

Hình 1.4 Mô hình SOA sử dụng webservice 14

CHƯƠNG II: WORKFLOW 14

2.1 Khái niệm 14

2.2 Ích lợi áp dụng workflow: 14

2.3 Các dạng workflow 15

Hình 2.1 Mô hình tuần tự: 15

2.3.1.2.Song song (Parallel Split) 15

Hình 2.2 song song 16

2.3.1.3 Đồng bộ hoá 16

2.3.1.4 Phép chọn loại trừ (Exclusive Choice) 16

Hình 2.4 Mô hình chọn loại trừ 16

2.3.1.5 Trộn đơn giản (Simple Merge) 16

Hình 2.5.Mô hình trộn đơn giản 17

2.3.1.6 Chọn đa nhánh (Multi-Choice) 17

Hình 2.6.Mô hình chọn đa nhánh 17

2.3.1.7 Trộn đồng bộ hoá 17

Hình 2.7.Mô hình trộn đồng bộ hóa 18

2.3.1.8 Trộn đa nhánh 18

Hình 2.8.Mô hình trộn đa nhánh 18

2.3.1.9 Các vòng lặp tuỳ ý 18

Hình 2.9.Mô hình các vòng lặp tùy ý 19

CHƯƠNG III:TÌM HIỂU KHÁI QUÁT WEB SERVICE 19

3.1.Định nghĩa web service: là một công nghệ gọi từ xa có tính khả chuyển cao nhất hiện nay: mang tính độc lập nền, độc lập ngôn ngữ Do đó, các chương trình code bằng các ngôn ngữ lập trình khác nhau, chạy trên các nền tảng (phần cứng & OS) khác nhau đều có thể trao đổi với nhau thông qua công nghệ này 19

Hình 3.1.Mô hình webservice đơn giản 20

3.2.Đặc điểm của webservice: 20

Hình 3.2 Ứng dụng của webservice trong thực tế 20

3.3.Các thành phần chính trong Webservice: 21

3.3.1.XML: XML là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định nghĩa Về hình thức XML có ký pháp tựa như HTML nhưng không tuân theo một đặc tả quy ước như HTML Do web service là sự kết hợp của nhiều thành phần khác nhau , do đó web services sử dụng các tính năng và đặc trưng của các thành phần này để giao tiếp với nhau.Vì vậy XML là một công cụ chính yếu để giải quyết vấn đề này Từ kết qủa này , các ứng dụng tích hợp vĩ mô tăng cường sử dụng XML.Nhờ có khả năng tổng hợp này mà XML đã trở thành kiến trúc nền tảng cho việc xây dựng web service 21

3.3.2.WSDL -Web Services Description Language : 21

Hình 3.3.Mô tả wsdl 21

3.3.3.UDDI - Universal Description , Discovery and Intergration: 21

Hình 3.4.Mô hình của UDDI 22

3.3.4 SOAP - Simple Object Accesss Protocol 22

3.4.Xây dựng web service: 23

3.4.1.1.Giai đoạn xây dựng 23

Hình 4.1.Kiến trúc của bpel process 25

4.1.Nội dung cơ bản: 25

4.1.1.Cấu trúc của bpel process: 25

4.1.2.Mối quan hệ với các Bussiness Partner: 27

Hình 4.2 Các thành phần trong bpel process 27

4.1.3.Trạng thái của BPEL process: 27

4.2.Các Activie cơ bản: 28

4.2.1.Invoke: 28

4.2.2.Receive: 29

4.2.3.Reply: 29

4.2.4.Assign 30

4.2.5 Throw: 32

4.2.6.Empty: 32

4.3.Các Active có cấu trúc 32

4.3.1.Xử lý tuần tự: <sequence> 32

4.3.2.Điều kiện <if>: 33

4.3.3.Thực thi vòng lặp <while>: 34

4.3.4 Song song và xử lý các điểu khiển lệ thuộc: <flow> 34

4.3.5.Xử lý đa nhánh:<foreach> 34

4.3.6.Scope (phạm vi): 35

CHƯƠNG 5: ỨNG DỤNG CHO BPEL 36

5.1.Mô tả nghiệp vụ: 36

5.2.Phân tích bài toán: 36

Hình 5.1.Lược đồ hoạt đồng 37

5.3.Xây dựng BPEL process: 37

5.3.1.Xây dựng các webservice liên quan: 37

Hình 5.2.Interface của web service airline webservice 38

5.3.2 WSDL cho BPEL Process: 38

Hình 5.3 Interface bpel process 38

5.3.3 Định nghĩa các Partner Link Types: 38

5.3.4.Định nghĩa quy trình nghiệp vụ (Bussiness Process Definition) 39

Hình 5.4 Lược đồ tuần tự 40

5.4.Config engine và cài plug-in 40

5.4.1.Cài đặt Apache Tomcat: 41

Hình 5.5 Thiết lập biến môi trường 42

Hình 5.6 Start Tomcat 26 42

5.5.2.Cài đặt Axis2( phiên bản nâng cấp của Axis):có nhiều cách để cài đặt axis2,đơn giản nhất là chép tập tin axi2.war vào thư mục C:\apache-tomcat-5.5.27\webapps và restart lại tomcat sẽ thành công.Truy câp:http://localhost:8080/axis2 sẽ được: 43

Hình 5.7.Khởi động Axis2 43

5.4.3.Cài đặt Eclipse WTP: 43

Hình 5.8 Thiết lập Axis2 trong eclipse 44

5.4.4 Cài đặt MySQL 4.1 và JDBC connector: 44

Hình 5.9 Lược đồ cơ sở dữ liệu 45

5.4.5.Cài đặt ODE Apache 45

5.5.Thực hiện: 45

5.5.1.Chương trình chính: 45

Hình 5.10 Giao diện thiết kế 46

Hình 5.11.WSDL của web service airline 46

Hình 5.12.Thiết kế partnerlink 47

Hình 5.13 config active <invoke> 48

Hình 5.14 BPEL proccess 49

Hình 5.15 active <if> 49

Hình 5.16 config active <assign> 50

Hình 5.17 Config WSDL cho bpel proccess 51

Hình 5.18 config deploy.xml 52

5.5.2.Viết client gọi BPEL: 52

Hình 5.19.Mô hình bpel process tương tự 1 web service 53

Hình 5.20.Tạo web project client 54

MỤC LỤC HÌNH: Hình1.1 Mô hình CORBA………9

Hình 1.2 Mô hình EJB ……….10

Hình 1.3 Mô hình DCOM ……… 11

Hình 1.4 Mô hình SOA sử dụng webservice………13

Hình 2.1 Mô hình tuần tự……….14

Hình 2.3.Mô hình đồng bộ hóa ……… 15

Hình 2.2 song song ………14

Hình 2.4 Mô hình chọn loại trừ ……… 15

Hình 2.5.Mô hình trộn đơn giản ……… 15

Hình 2.6.Mô hình chọn đa nhánh ……… 16

Hình 2.7.Mô hình trộn đồng bộ hóa ……….………17

Hình 2.8.Mô hình trộn đa nhánh ……….17

Hình 2.9.Mô hình các vòng lặp tùy ý……….17

Hình 3.1.Mô hình webservice đơn giản……….18

Hình 3.2 Ứng dụng của webservice trong thực tế ………19

Hình 3.3.Mô tả wsdl ………20

Hình 3.4.Mô hình của UDDI……….20

Hình 3.5.Cấu trúc SOAP ……… 21

Hình 4.1.Kiến trúc của bpel process ……… 24

Hình 4.2 Các thành phần trong bpel process……… 26

Hình 5.1.Lược đồ hoạt dong……….36

Hình 5.2.Interface của web service airline webservice……… 37

Hình 5.3 Interface bpel process ……….38

Hình 5.4 Lược đồ tuần tự ……… 40

Hình 5.5 Thiết lập biến môi trường ……… 41

Hình 5.6 Start Tomcat 26 ………42

Hình 5.7.Khởi động Axis2……… 42

Hình 5.8 Thiết lập Axis2 trong eclipse……… 43

Hình 5.9 Lược đồ cơ sở dữ liệu ……… 44

Hình 5.10 Giao diện thiết kế ……… 45

Hình 5.11.WSDL của web service airline ……… 46

Hình 5.12.Thiết kế partnerlink ………46

Hình 5.13 config active <invoke> ……….47

Hình 5.14 BPEL process 48 ……… 48

Hình 5.15 active <if> ……… 48

Hình 5.16 config active <assign> ……… 49

Hình 5.17 Config WSDL cho bpel process ……… 50

Hình 5.18 config deploy.xml ……… 51

Hình 5.19.Mô hình bpel process tương tự 1 web service ……… 52Hình 5.20.Tạo web project client ……… 53

CHƯƠNG I:HIỆN TRẠNG

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

Ba kiến trúc phân tán phổ biến nhất hiện này là CORBA, DCOM và EJB Các kiến trúc này là sự mở rộng của các hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng Đối tượng đó có thể có không gian địa chỉ bên ngoài ứng dụng, hoăc ở một máy khác với máy chứa ứng dụng trong khi vẫn được tham chiếu sử dụng như một phần của ứng dụng

• CORBA – Common Object Request Broker Architecture:

► CORBA được định nghĩa bởi Object Management Group (OMG), là một kiến

trúc phân tán mở, độc lập nền tảng và độc lập ngôn ngữ

► CORBA Component Model (CCM) là một cải tiến đáng kể nhằm định nghĩa các mô hình thành phần so với CORBA Nó định nghĩa ra quy trình thiết kế, phát triển, đóng gói, triển khai và thực thi các thành phần phân tán CCM định nghĩa khái niệm Ports cho các thành tố Các port này được sử dụng để kết nối các thành phần có sẵn với nhau, tạo các hệ thống phân tán phức tạp hơn Mỗi thành phần CCM có một đối tượng Home chịu trách nhiệm quản lý chu kỳ sống của đối tượng và được triển khai bên trong một trình chứa (container)

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

Hình1.1 Mô hình CORBA

• EJB - Enterprise Java Bean:

► Kiến trúc EJB là một kiến trúc thành tố bên phía máy chủ dùng cho việc phát triển và triển khai các ứng dụng phân tán hướng đối tượng cỡ vừa và lớn

► Kiến trúc EJB có 3 tầng với tầng đầu tiên là tầng trình diễn, tầng thứ hai là tầng xử lý nghiệp vụ, và tầng thứ ba là các tài nguyên như cơ sở dữ liệu máy

chủ Truyền thông giữa các đối tượng EJB thông qua Remote Method Invocation (RMI) Các client không bao giờ tương tác trực tiếp với các bean Thay vì vậy chúng

sẽ sử dụng các phương thức được định nghĩa trong các interface Remote và Home Mỗi bean tồn tại bên trong trình chứa, chịu trách nhiệm việc tạo thể hiện mới, lưu trữ

dữ liệu và các quản lý khác Trình chứa sẽ triệu gọi các phương thức callback của mỗi thể hiện bean khi có sự kiện tương ứng Không giống như CCM, EJB không định nghĩa các port kết nối trực tiếp giữa các thành phần liên quan bởi vì mỗi bean bên trong trình chứa là một thực thể độc lập không có bất kỳ ràng buộc nào bên ngoài

► EJB là một kiến trúc tốt cho việc tích hợp các hệ thống vì nó độc lập nền tảng

nhưng nó cũng gặp vấn đề là nó không phải là một chuẩn mở, khả năng giao

tiếp với các chuẩn khác vẫn còn hạn chế

Hình 1.2 Mô hình EJB

• DCOM – Distributed Component Object Model:

► DCOM là một mô hình phân tán dễ triển khai với chi phí thấp, hỗ trợ tigh coupling giữa các ứng dụng và hệ điều hành Mô hình Component Object Model (COM) định nghĩa cách thức các các thành phần và client liên lạc trao đổi với nhau trên cùng một máy DCOM mở rộng COM bằng cách sử dụng các giao thức mạng chuẩn khi cần trao đối dữ liệu với máy khác trên mạng DCOM hỗ trợ kết nối giữa các đối tượng và những kết nối này có thể được thay đổi lúc đang chạy Các đối tượng DCOM được triển khai bên trong các gói nhị phân chứa các mã lệnh quản lý chu kỳ sống của đối tượng và việc đăng ký đối tượng

► DCOM mang đến nhiều ưu điểm như tính ổn định, không phụ thuộc vị trí địa lý, quản lý kết nối hiệu quả và dễ dàng mở rộng, là một lựa chọn tốt cho các

doanh nghiệp sử dụng công nghệ của Windows để chạy các ứng dụng có yêu cầu cao

về sự chính xác và ổn định Tuy nhiên, các công nghệ của Microsoft có một nhược điểm lớn là chúng bị giới hạn trên nền tảng Windows

Hình 1.3 Mô hình DCOM

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

Ngày nay áp lực đặt lên các doanh nghiệp ngày càng lớn: giảm chi phí đầu tư cơ sở hạ tầng, khai thác có hiệu quả các công nghệ có sẵn, phải cố gắng phục vụ yêu cầu của

khách hàng ngày càng tốt hơn, đáp ứng tốt các thay đổi nghiệp vụ, khả năng tích hợp cao với các hệ thống bên ngoài… Nguyên nhân chính của mọi khó khăn trên đó là: sự không đồng nhất và sự thay đổi

Hầu hết các doanh nghiệp ngày nay đều sở hữu nhiều hệ thống, ứng dụng, với những kiến trúc khác nhau, xây dựng vào những khoảng thời gian khác nhau và dựa trên những công nghệ khác nhau phần việc của mình, sau đó chỉ việc tổng hợp thông tin trả về Trong quá trình kết hợp chắc chắn sẽ gặp những khó khăn như:

• Không đủ khả năng quản lý quy trình nghiệp vụ

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

• Vấn đề bảo mật :Trong khi đó những thay đổi vẫn liên tục xảy ra

• Toàn cầu hoá dẫn đến tính cạnh tranh khốc liệt đòi hỏi phải rút ngắn quy trình sản phẩm để tăng ưu thế cạnh tranh với các đối thủ

• Nhu cầu và yêu cầu khách hàng thường xuyên thay đổi nhanh chóng nhằm cho ra các sản phẩm có tính cạnh tranh liên tục xuất hiện trên thị trường

• Cải tiến công nghệ dẫn đến thay đổi các thành phần liên quan

1.3 SOA và web service giải quyết vấn đề tích hợp như thế nào:

Công nghệ XML và web service

Những nghiên cứu gần đây cho thấy rằng: các khó khăn trong việc tích hợp các hệ thống có thể được khắc phục bằng cách định nghĩa thêm một tầng trừu tượng cho các

hệ thống tin học hiện có và mới xây dựng Tầng này sẽ được xây dựng dựa trên các chuẩn của web service Một số giải pháp chung trong việc dùng web service cho vấn

đề tích hợp:

• Tích hợp hướng dữ liệu:

► Xác định thông tin dữ liệu nào cần được chia sẻ (các bảng dữ liệu, các định dạng file và thông điệp)

► Xây dựng các lược đồ mô tả XML (Xml Schema) cho các thông tin này

► Sử dụng SOAP như là định dạng của thông điệp

• Tích hợp hướng chức năng/hàm APIs:

► Xác định các phương thức từ xa nào sẽ được thể hiện ra ngoài như các web service

► Định nghĩa kiểu dữ liệu XML cho đối số của các phương thức này

► Sử dụng SOAP như là định dạng thông điệp

• Tích hợp hướng thành phần giao tiếp:

► Định nghĩa thông tin mô tả web service (WSDL)

► Tạo ra các đối tượng bọc và thực hiện ánh xạ tương ứng giữa thành phần giao tiếp vừa định nghĩa với dữ liệu, thông điệp và các lời gọi hàm APIs

(cần được chia sẻ) của hệ thống hiện hành

Hình 1.4 Mô hình SOA sử dụng webservice

CHƯƠNG II: WORKFLOW

BPEL4WS là một ngôn ngữ chuẩn cho việc thực hiện các quy trình nghiệp vụ.Để tìm hiểu về các quy trình này chúng ta sẽ đi vào thế giới workflow

Có 2 cách hiểu về workflow

Cách 1: workflow theo nghĩa rộng, là 1 mô hình nghiệp vụ, trong đó các công việc được phân công rõ ràng, thực hiện theo thứ tự đặt sẵn Khái niệm workflow theo cách hiểu này đã có từ lâu và được ứng dụng rộng rãi trong các ngành công nghiệp Cách 2: Khái niệm workflow trong khoa học máy tính ứng dụng vào quản lý tiến trình kinh doanh (tìm hiểu dưới đây)

2.1 Khái niệm

Workflow là quá trình tự động hóa một phần hoặc toàn bộ một tiến trình kinh doanh

Ý nghĩa của workflow khi này đơn giản chỉ là các luồng công việc

Hệ thống quản trị luồng công việc: quản lý và thực thi các mô hình luồng công việc thông qua việc thực thi các phần mềm Gồm 2 thành tố:

+ Bộ phận hỗ trợ đặc tả mô hình luồng công việc

+ Bộ phận vận hành mô hình đã đặc tả

2.2 Ích lợi áp dụng workflow:

Lợi ích của việc sử dụng worflow trong quản lý tiến trình kinh doanh được liệt

kê như sau:

+ Tiến trình kinh doanh đưọc vạch ra rõ ràng, vì thế trách nhiệm và những mối

quan hệ cộng tác được định rõ

+ Dễ dàng để tối ưu hóa công việc kinh doanh vì những định nghĩa chính xác

trên

+ Tiến trình kinh doanh được chia nhỏ thành những module và những module này có thể tổ chức lại theo mô hình workflow để thích ứng với tiến trình kinh doanh chung, vì thế dễ dàng thích nghi nhanh chóng với những thay đổi không đoán trước được trong những yêu cầu và điều kiện kinh doanh

+ Workflow có thể theo dõi hằng ngày

+ Workflow tích hợp với những ứng dụng hay những hệ thống khác vào tiến

Ví dụ: hành vi gửi hóa đơn được thực hiện ngay sau hành vi gửi hàng hóa

Cài đặt: dạng tuần tự được sử dụng để mô hình các bước liên tiếp trong

cùng 1 tiến trình của luồng công việc

Mô hình:

Hình 2.1 Mô hình tuần tự:

Công việc B được thực hiện sau khi công việc A được hoàn thành

2.3.1.2.Song song (Parallel Split)

Mô tả: 1 điểm trong 1 tiến trình của luồng công việc là nơi 1 công việc được tách thành nhiều công việc con Các công việc con có thể được tiến hành đồng thời cùng lúc với nhau (song song nhau)

Ví dụ: Sau khi hành vi nhận tiền hoàn thành, hành vi gửi hàng và hành vi

xuất hóa đơn sẽ được kích hoạt và tiến hành đồng thời

Mô hình:

Công việc B Công việcA

Hình 2.2 song song

2.3.1.3 Đồng bộ hoá

Mô tả: 1 điểm trong luồng công việc là nơi các tiến trình hay các công việc con nhập lại làm 1 tiến trình hay công việc đơn Trong dạng mô hình này, tất cả các luồng đi vào phải chờ nhau tại điểm đồng bộ hóa

Ví dụ: Sau khi hành vi gửi hàng và xuất hóa đơn được thực hiện, hành vi

lưu trữ mới được kích hoạt

Mô hình:

Hình 2.3.Mô hình đồng bộ hóa

2.3.1.4 Phép chọn loại trừ (Exclusive Choice)

Mô tả: tại 1 điểm trong luồng công việc sẽ diễn ra sự lựa chọn công việc nào sẽ được kích hoạt tiếp theo trong 1 loạt các công việc kế tiếp

Ví dụ: Sau khi công việc kiểm thử phần mềm được thực hiện, dựa vào kết

quả kiểm thử sẽ quyết định công việc tiếp theo là lập trình hay đóng gói phần mềm

Mô hình:

Hình 2.4 Mô hình chọn loại trừ

2.3.1.5 Trộn đơn giản (Simple Merge)

Mô tả: 1 điểm trong luồng công việc là nơi 2 hay nhiều nhánh gặp nhau, không có sự đồng bộ hóa giữa các nhánh

Ví dụ: Công việc lưu trữ được thực hiện sau khi công việc gửi hóa đơn

hoặc công việc nhận hóa đơn được thực hiện

Công việc A

Công việc B

Công việc CChon b

hay c

Hình 2.5.Mô hình trộn đơn giản

Chú thích: chỉ cần 1 trong 2 công việc A hoặc B được hoàn thành thì công việc C sẽ được kích hoạt

+ Các dạng nâng cao:

2.3.1.6 Chọn đa nhánh (Multi-Choice)

Mô tả: Một điểm trong tiến trình là nơi mà một hoặc nhiều nhánh được chọn theo một quyết định hoặc dựa trên dữ liệu của nghiệp vụ.Mẫu này khác với mẫu 2.4.1.4 (chọn loại trừ) có thể chọn một hoặc nhiều nhánh được chọn ra và thực thi, tương tự như phép XOR

Các ví dụ:Sau khi thực hiện hành vi đánh-giá-thiệt-hại, hành vi “liên hệ phòng cứu hỏa” hoặc hành vi “liên hệ công ty bảo hiểm” được thực hiện Ít nhất một trong hai hành vi này được thực hiện Tuy nhiên, cũng có thể là cả hai cần được thực hiện

ra khỏi nút AND phân luồng (AND-Split) phải đều được thực hiện

Các ví dụ: Mở rộng ví dụ trong mẫu 6 (chọn đa nhánh), sau khi một hoặc cả hai hành

vi liên-hệ-phòng-chữa-cháy và liên-hệ-công-ty-bảo-hiểm đã hoàn tất (dựa trên việc nó

có được thực thi hay không), hành vi trình-báo-cáo phải được thực hiện (chỉ duy nhất một hành vi)

A

Hình 2.7.Mô hình trộn đồng bộ hóa

2.3.1.8 Trộn đa nhánh

Mô tả: Một điểm trong tiến trình là nơi hai hoặc nhiều nhánh hội tụ lại và không được đồng bộ hóa Nếu nhiều hơn một nhánh được kích hoạt, ngay lập tức hành vi sau điểm trộn sẽ bắt đầu đối với mỗi kích hoạt của mỗi nhánh vào Mẫu này chính là thể hiện cho cơ chế trộn phục vụ cho mục đích dùng chung cho các thành phần trong quy trình Các ví dụ: Thỉnh thoảng hai hay nhiều nhánh có cùng điểm kết thúc Thay vì lặp lại tiến trình này cho mỗi nhánh (có thể phức tạp), ta dùng mẫu trộn đa nhánh Ví dụ đơn giản của trường hợp này là 2 hành vi “kiểm tra đơn xin việc” và “xử lý đơn xin việc” cùng thực hiện song song và thực hiện trước hành vi “đóng trường hợp”

Các ví dụ:Tiến trình xem xét sản phẩm : trong tiến trình này vòng lặp các

hoạt động Make,Read, Note, Approve là một vòng lặp cấu trúc

B

A

C

Hình 2.9.Mô hình các vòng lặp tùy ý

CHƯƠNG III:TÌM HIỂU KHÁI QUÁT WEB SERVICE

3.1.Định nghĩa web service: là một công nghệ gọi từ xa có tính khả chuyển cao nhất

hiện nay: mang tính độc lập nền, độc lập ngôn ngữ Do đó, các chương trình code bằng các ngôn ngữ lập trình khác nhau, chạy trên các nền tảng (phần cứng & OS) khác nhau đều có thể trao đổi với nhau thông qua công nghệ này

Hình 3.1.Mô hình webservice đơn giản

3.2.Đặc điểm của webservice:

• Web service cho phép client và server tương tác được với nhau mặc dù trong những môi trường khác nhau

• Web service thì có dạng mở và dựa vào các tiêu chuẩn.XML và HTTP là nền tảng kỹ thuật cho web service.Phần lớn kỹ thuật của web service được xây dựng là những dự án nguồn mở Bởi vậy, chúng độc lập và vận hành được với nhau

• Web service thì rất linh động : với UDDI và WSDL, thì việc mô tả và phát triển web service có thể được tự động hóa

• Web service được xây dựng trên nền tảng những công nghệ đã được chấp nhận

• Web service có dạng mô đun

• Web service có thể công bố (publish)

Ví dụ về webservice như: Đặt vé máy bay trực tuyến,các dịch vụ thương mại,dự báo thời tiết…

Hình 3.2 Ứng dụng của webservice trong thực tế

3.3.Các thành phần chính trong Webservice:

3.3.1.XML: XML là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định

nghĩa Về hình thức XML có ký pháp tựa như HTML nhưng không tuân theo một đặc

tả quy ước như HTML Do web service là sự kết hợp của nhiều thành phần khác nhau ,

do đó web services sử dụng các tính năng và đặc trưng của các thành phần này để giao tiếp với nhau.Vì vậy XML là một công cụ chính yếu để giải quyết vấn đề này Từ kết qủa này , các ứng dụng tích hợp vĩ mô tăng cường sử dụng XML.Nhờ có khả năng tổng hợp này mà XML đã trở thành kiến trúc nền tảng cho việc xây dựng web service

3.3.2.WSDL -Web Services Description Language :

WSDL định nghĩa cách mô tả web service theo cú pháp tổng quát XML , bao gồm các thông tin

- Tên ̣service

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

- Loại thông tin: những thao tác, những tham số, và những kiểu dữ liệu gồm có giao diện của web service, cộng với tên cho giao diện này

Một WSDL hợp lệ gồm có hai phần :

1 Phần giao diện mô tả giao diện và giao thức kết nối

2 Phần thi hành mô tả thông tin để truy xuất service

Cả 2 phần trên sẽ được lưu trong 2 tập tin XML , bao gồm:

- Tập tin giao diện service (cho phần 1)

- Tập tin thi hành service (cho phần 2)

Hình 3.3.Mô tả wsdl

3.3.3.UDDI - Universal Description , Discovery and Intergration:

Để có thể sữ dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng dịch vụ và biết được đối tượng cung cấp dịch vụ UDDI định nghĩa một

số thành phần cho biết trước các thông tin này để cho phép các client truy tìm và nhận lại những thông tin yêu cầu sử dụng web services

Hình 3.4.Mô hình của UDDI

3.3.4 SOAP - Simple Object Accesss Protocol

Web services có thể truy xuất bằng một giao thức là Simple Object Access Protocol – SOAP Nói cách khác chúng ta có thể truy xuất đến UDDI registry bằng các lệnh gọi hoàn toàn theo kiểu SOAP

SOAP là một giao thức giao tiếp có cấu trúc như XML và mã hóa thành định dạng chung cho các ứng dụng trao đổi với nhau Ý tưởng bắt đầu từ Microsoft và phần mềm Userland , trải qua nhiều lần thay đổi , hiện tại là phiên bản SOAP 1.2 với nhiều ưu điểm vuợt trội hơn bản SOAP 1.1 SOAP được xem như là cấu trúc xương sống của các ứng dụng phân tán xây dựng từ nhiều ngôn ngữ , hệ điều hành khác nhau

3.3.4.1 Đặc trưng SOAP:

SOAP có những đặc trưng sau :

- SOAP được thiết kế đơn giản và dễ mở rộng

- Tất cả các message SOAP đều được mã hóa sử dụng XML

- SOAP sử dùng giao thức truyền dữ liệu riêng

- Không có garbage collection phân tán , và cũng không có cơ chế tham

chiếu.Vì thế SOAP client không giữ bất kỳ một tham chiếu đầy đủ nào về các đối tượng ở xa

- SOAP không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công nghệ nào

3.3.4.2 Cấu trúc một message theo dạng SOAP:

Cấu trúc một message theo dạng SOAP được mô tả như hình dưới đây:

Hình 3.5.Cấu trúc SOAPMessage theo dạng SOAP là một văn bản XML bình thường bao gồm các phần tử sau:

- Phần tử gốc - envelop : phần từ bao trùm nội dung message , khai báo văn bản XML như là một thông điệp SOAP

- Phần tử đầu trang – header : chứa các thông tin tiêu đề cho trang , phần tử này không bắt buộc khai báo trong văn bản Những đầu mục còn có thể mang những dữ liệu chứng thực, những chữ ký số hóa, và thông tin mã hóa, hoặc những cài đặt cho giao tác

- Phần tử khai báo nội dung chính trong thông điệp - body , chứa các thông tin yêu cầu

và phản hồi

- Phần tử phát sinh lỗi (Fault) cung cấp thông tin lỗi xảy ra trong qúa trình xử lý thông điệp

Trong trường hợp đơn giản nhất, phần thân của SOAP message gồm có:

- Tên của message

- Một tham khảo tới một thể hiện service

- Một hoặc nhiều tham số mang các giá trị và mang các tham chiếu Có 3 kiểu thông báo

Request messages : với các tham số gọi thực thi một service

Response messages với các tham số trả về, được sử dụng khi đáp ứng yêu cầu

3.4.Xây dựng web service:

3.4.1.1.Giai đoạn xây dựng

Giai đoạn đầu tiên khi chúng ta tạo ra một web service là giai đoạn xây dựng.Có hai cách khác nhau để tiến hành trong giai đọan xây dựng:

- Red path - solod : chúng ta xây dựng từ trạng thái ban đầu hoặc đã có sẵn bằng mã Java Sử dụng mã Java đó, chúng ta xây dựng định nghĩa service (WSDL) với các đối tượng , hàm , chức năng mà chúng ta mong muốn

- Blue path –dashed : một cách thực hiện khác là xây dựng 1 webservice dựa trên một webservice đã có sẵn

3.4.1.2.Giai đoạn triển khai

Giai đoạn thứ hai là giai đoạn triển khai.Trong giai đoạn này chúng ta triển khai web service tới một application server

3.4.1.3 Giai đoạn thực thi:

Giai đoạn thứ ba là giai đoạn tiến hành Trong giai đoạn này chúng ta công bố

(publish) web service để các client có thể tìm thấy Thao tác̣ công bô nàý có thể sử dụng UDDI registry.Web service được thực thi và được gọi bởi những người dùng muốn sử dụng dịch vụ

3.4.1.4 Giai đoạn quản lý:

Giai đoạn cuối cùng là giai đoạn quản lý Nó bao trùm tất cả các nhiệm vụ quản lý và quản trị ứng dụng web service

Chúng ta đã nắm được các bước cơ bản để thực hiện 1 dịch vụ web Ngoài ra còn có những phương pháp khác để tạo một dịch vụ khác mà điển hình là sử dụng ngôn ngữ BPEL4WS Đây là ngôn ngữ mạnh hiện nay,chúng ta sẽ đi vào tìm hiểu ngôn ngữ này ở chương kế tiếp.

CHƯƠNG 4: LÝ THUYẾT BPEL 2.0

Hình 4.1.Kiến trúc của bpel process

4.1.Nội dung cơ bản:

4.1.1.Cấu trúc của bpel process:

Đầu tiên BPEL process là một container,trong đó chúng ta định nghĩa các mối liên hệ bên ngoài,định nghĩa các loại dữ liệu,kiểm soát lỗi và quan trọng nhất chính là các active thực thi

Trên cùng, process chứa một số thuộc tính và các namespace.Ví dụ:

<process name="PrimerProcess"

targetNamespace="http://oasis-open.org/WSBPEL/Primer/"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" />

Namespace định nghĩa “http://docs.oasis-open.org/wsbpel/2.0/process/executable”

đó là những Execute Process

Ta có cấu trúc tổng quát theo mẫu sau:

<process name="ncname" targetNamespace="uri"

<! Note: At least one role must be specified >

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

<! Note: There must be at least one fault handler or default >

<catch faultName="qname"? faultVariable="ncname"?>*

<! Note: There must be at least one onMessage or onAlarm handler >

<onMessage partnerLink="ncname" portType="qname"

Activity

</process>

4.1.2.Mối quan hệ với các Bussiness Partner:

BPEL gọi những service tương tác với process là những partner (invoke) và client

sử dụng BPEL cũng là 1partner (receive).BPEL process thì giống như 1

Hình 4.2 Các thành phần trong bpel process

Ví dụ:các partner tương ứng là:Client,Credit Service và Inventory Service

4.1.3.Trạng thái của BPEL process:

Để việc truyền dữ liệu trong BPEL ta định nghĩa các variable.các variable này lưu giữ dữ liệu trong suốt quá trình thực hiện BPEL process Các dữ liệu này được viết

và đọc từ các kiểu biến Giá trị trong 1 biến có thể là của 2 nguồn: hoặc là những message trao đổi giữa các partner hoặc là những dữ liệu trung gian của của

process Các biến trong BPEL phải là các kiểu message trong WSDL,các kiểu cơ bản trong XML Schema Và để thay đổi trạng thái của process bằng cách thay đổi