Chương 5 XÂY DỰNG VÀ THỬ NGHIỆM CÔNG CỤ BPELFX
5.1 Đặc tả hệ thống BPELfx Designer
5.1.3 Ý nghĩa thực tiễn của hệ thống
Hệ thống BPELfx Designer được xây dựng với mục đính hỗ trợ người dùng thực hiện thiết kế và triển khai các quy trình BPEL lên Apache ODE server. Ngoài ra nó còn hỗ trợ việc tìm kiếm và publish các dịch vụ web lên UDDI server. Với việc hỗ trợ chuẩn BPEL 2.0 và đƣợc xây dựng trên nền web chúng tôi hy vọng sẽ mang lại cho người dùng sự thuận lợi và tiện dụng hơn trong việc thiết kế và tổng hợp các quy trình nghiệp vụ của mình. Được xây dựng theo hướng mã nguồn mở với mục tiêu sẽ đƣợc cộng đồng sử dụng và góp phần phát triển hệ thống lớn mạnh hơn trong tương lai nhằm đem lại cho người dùng nhiều sự lựa chọn hơn trong việc tìm kiếm các BPEL designer của mình. Một ý nghĩa khác mà hệ thống mang lại đó là góp phần làm cho ngôn ngữ BPEL đƣợc sử dụng phổ biến hơn.
5.2 ác định yêu cầu của hệ thống BPELfx Designer
Vì hệ thống được xây dựng trên môi trường web nên đòi hỏi phải quản lý người sử dụng hệ thống và quản lý các dự án của người dùng. Trong khuôn khổ thời gian thực hiện khóa luận cũng như hạn chế về nguồn lực hiện tại phân hệ quản lý người dùng chúng tôi chỉ thực hiện ở mức cơ bản nhất nhƣ đăng ký sử dụng, quản lý các quy trình mẫu...vv. Phần lớn các chức năng chính chúng tôi tập trung vào phân hệ Designer với các chức năng chính nhƣ tạo quy trình, chỉnh sửa, thiết kế một quy
87
trình, tổng hợp tìm kiếm các dịch vụ web, publish các thông tin của web-servirce lên UDDI server….vv.
BPEL Fx Designer có thể hỗ trợ tốt việc thiết lập và triển khai các quy trình nghiệp ở mức cơ bản nhất mà một BPEL Designer có thể có, ngoài ra nó còn có thể làm việc với một số quy trình nghiệp vụ phức tạp và đòi hỏi phải tổng hợp nhiều dịch vụ khác nhau. Các chức năng chính của hệ thống đƣợc mô tả ở lƣợt đồ Use Case.
Qua việc phân tích cũng nhƣ tham khảo một số BPEL Desiner Engine hiện tại trên thị trường đồng thời phân tích mục tiêu cũng như tính chất của đề tài chúng tôi đã thiết kế ra lƣợt đồ Use Case cho hệ thống với các chức năng đƣợc mô tả nhƣ sau:
Hình 5.2-Lƣợt đồ Usecase của hệ thống BPELfx Designer
Guest Delete User View Project Lists of Users
Administrator
Deploy Update Private Information
New Project
Remove Project
Save As Delete BPEL File
Rename BPEL File
View Project List
<<extend>>
Export
New BPEL File Save
<<extend>>
Edit BPEL File
<<extend>>
Import Open Project <<extend>>
Compile
<<include>>
closeproject User
Login Register
<<extend>>
88
Sau đây là các mô tả chi tiết cho t ng Usecase:
Đặc tả các Actor
Administrator: đóng vai trò là người quản lý hệ thống, actor này có vai trò quản lý người dùng cũng như các cấu hình của hệ thống.
User: đóng vai trò là người dùng chính trong hệ thống, Actor này có thể thực hiện các chức năng: Đăng nhập, tạo Project, Edit (chỉnh sửa, thiết kế các process), Export, Deploy các tiến trình và một số chức năng khác.
Guest: là người dùng ngoài hệ thống có thể thực hiện đăng ký để trở thành người dùng trong hệ thống.
Đặc tả Usecase
Regiter
Tóm tắt: Usercase này cho phép người dùng có thể đăng ký thành viên để trở thành người dùng trong hệ thống.
Dòng sự kiện:
Dòng sự kiện chính: Usercase này bắt đầu khi người dùng ngoài hệ thống muốn đăng ký để trở thành người dùng trong hệ thống.
1. Khi khởi động hệ thống người dùng chọn Register.
2. Hệ thống yêu cầu người dùng cung cấp các thông tin cá nhân.
3. Người dùng xác nhận các thông tin và hệ thống tiến hành kiểm tra tính hợp lệ của thông tin người dùng.
4. Nếu thông tin người dùng không hợp lệ dòng sự kiện chính được thực hiện lại.
5. Nếu thông tin người dùng hợp lệ dòng sự kiện kết thúc.
Dòng sự kiện khác:Trong quá trình đăng ký người dùng có thể chọn hủy đăng ký thành viên và dòng sự kiện kết thúc.
Các yêu cầu đặt biệt:không có
Điều kiện tiên quyết:Không có
Pre-condition:trạng thái hệ thống không thay đổi
Post-Condition:một người dùng mới sẽ được thêm vào hệ thống
Điểm mở rộng:không có
89
Login
Tóm tắt:User case này cho phép người dùng đăng nhập vào hệ thống.
Dòng sự kiện chính: User case này bắt đầu khi người dùng khởi động hệ thống và thực hiện chức năng đăng nhập vào hệ thống.
1. Người dùng khởi động hệ thống và màn hình đăng nhập xuất hiện 2. Hệ thống yêu cầu người dùng điền thông tin đăng nhập
3. Người dùng điền các thông tin đăng nhập và chọn đăng nhập
Dòng sự kiện khác:Khi thông tin đăng nhập không hợp lệ thì dòng hệ thống sẽ thông báo ngoại lệ và dòng sự kiện chính đƣợc thực hiện lại.
Điều kiện tiên quyết: không có
Post-condition: trạng thái hệ thống không thay đổi.
Pre-Condition: Nếu đăngnhập thành công thì người dùng sẽ được đăng nhập vào hệ thống.
Điểm mở rộng:Đăng ký làm thành viên của hệ thống (Resigter)
NewProject
Tóm tắt:UseCase này cho phép người dùng có thể tạo mới một project trong hệ thống
Dòng sự kiện chính: Usecase này xảy ra khi người dùng chọn chức năng tạo mới một Project .
1. Hệ thống yêu cầu người dùng nhập vào tên Project
2. Sau khi người dùng nhập tên Project thì chọn tạo mới hoặc kết thúc
3. Nếu người dùng chọn tạo mới project thì hệ thống sẽ ghi nhận và lưu trữ tên project
4. Một thƣ mục project đƣợc tao ra trong hệ thống
Dòng sự kiện khác:không có
Điều kiện tiên quyết:không có
Post-Condition:trang thái hệ thống không thay đổi
Pre-Condition:Một thư mục project được tao ra trong thư mục người dùng và hệ thống sẽ lưu trữ thông tin project xuống cơ sở dữ liệu.
90
Điểm mở rộng:không có
View Project List
Tóm tắt: Usecase này cho phép người dùng xem danh sách các project mà mình đã tạo trong hệ thống
Dòng sự kiện chính:Usecase này xảy ra khi người dùng đăng nhập thành công vào hệ thống
1. Người dùng đăng nhập thành công vào hệ thống
2. Hệ thống kết nối cơ sở dữ liệu và lấy lên thông tin các project của người dùng 3. Hệ thống load danh sách project của người dung
Dòng sự kiện khác:không có
Điều kiện tiên quyết:Usecase “Login” phải đƣợc thực thi
Post-condition:Người dùng chưa đăng nhập vào hệ thống
Pre-condition:Danh sách các project và màn hình làm việc đã đƣợc load
Điểm mởi rộng:không có
Remove Project
Tóm tắt:Usecase này cho phép người dùng xóa các project của mình ra khỏi hệ thống.
Dòng sự kiện chính:Usecase bắt đầu khi người dùng chọn chức năng xóa project.
1. Người dùng chọn project cần xóa khỏi hệ thống 2. Người dùng chọn chức năng xóa project
3. Hệ thống yêu cầu người dùng xác nhận xóa project
4. Nếu người dùng xác nhận xóa project thì hệ thống gọi Usecase “Delete BPEL ile” để thực hiện xóa các file BPEL của project.
5. Hệ thống thực hiện xóa thƣ mục project các thông tin của project trong cơ sở dữ liệu
Dòng sƣ kiện khác: không có.
Điều kiện tiên quyết:không có.
Pre-Condition:hệ thống không thay đổi.
91
Post-condition:một project bi xóa khỏi hệ thống.
Điểm mở rộng: không có
New BPEL File
Tóm tắt:Usecase này giúp người dùng có thể tạo mới một file BPEL trong project của mình
Dòng sự kiện chính: Usecase này bắt đầu khi người dùng chọn chức năng tạo mới file BPEL
1. Người dùng chọn chức năng tạo file BPEL
2. Hệ thống yêu cầu người dùng nhập vào tên file và chọn project 3. Hệ thống lưu trữ tên tên file vào cơ sở dữ liệu bên dưới
4. Hệ thống tạo file BPEL vào thƣ mục project đã đƣợc chọn
Dòng sự kiện khác:khi chưa có project nào của người dùng trong hệ thống thì hệ thống yêu cầu người dùng tạo mới Project và Usecase “New Project” được gọi.
Điều kiện tiên quyết: project đã đƣợc tạo trong hệ thống
Pre-condition:hệ thống không thay đổi
Post-condition:một file BPEL mới đƣợc tạo ra trong hệ thống
Điểm mở rộng:tạo mới project
Edit BPEL File
Tóm tắt:Usecase cho phép người dùng có thể thiết kế và chỉnh sửa nội dung file BPEL.
Dòng sự kiện chính:Usecase bắt đầu khi người dùng mở file BPEL và thực hiện thiết kế và chỉnh sửa các active.Các Use case sau có thể đƣợc gọi trong “ dit BPEL File”:
Add Activity,Edit Activity,Delete,ImportWSDL:
1. Người dùng chọn Activity t palate và kéo thả vào tiến trình BPEL.
2. Hệ thống ghi nhận sự kiện và ghi Activity vào file BPEL.
3. Usecase lặp lại khi người dùng thêm một Activity mới.
Edit Activity:
92
1. Người dùng chọn Activity cần chỉnh sửa 2. Người dùng chọn chức năng Edit Properties
3. Hệ thống cho phép người dùng nhập thông tin của Activity.
4. Người dùng lưu lại thay đổi.
5. Hệ thống cập nhật các thông tin vào dữ liệu Delete Activity:
1. Người dùng chọn Activity muốn xóa 2. Người dùng chọn chức năng “Delete”
3. Hệ thống cập nhật lại tiến trình BPEL
Dòng sự kiện khác:không có
Điều kiện tiên quyết:các Usecase “Login”,”Create Project”,”Create BPEL File” đã đƣợc thực hiện.
Precondition:người dùng đã đăng nhập vào hệ thống
Post-codition:tiến trình BPEL của người dùng trong hậ thống thay đổi
Điểm mở rộng:không có 5.3 Thiết kế hệ thống 5.3.1 Thiết kế các xử lý
Tố chức các activity
Các activity đƣợc thiết kế có tính kế th a lẫn nhau để có thể sử dụng lại các thuộc tính chung. Cấu trúc của các Activity đƣợc thể hiện ở sơ đồ sau:
93
Hình 5.3-Sơ đồ tổ chức các activity
ShapeNode là node cơ sở và đƣợc kế th a bới BasicNode và structurenode. Các BasicNode là các node cơ bản của BPEL và không thể chứa các node khác bên trong nó. Các structureNode là các node có cấu trúc và có thể chứa các BasicNode bên trong. Trong cấu trúc tiến trình BPEL thì BasicNode luôn luôn đƣợc chứa trong một node cấu trúc, và đƣợc coi nhƣ là các node xử lý của tiến trình.
Xử lý chỉnh sửa các thuộc tính của activity
Các Activity đều có những thuộc tính chung nhƣng một số lại có những thuộc tính riêng. Để xử lý cho việc chỉnh sửa thuộc tính các activity này chúng tôi thiết kế riêng cho mỗi lớp thuộc tính của activity một phương thức Update và được kế th a t lớp basic properties. Sơ đồ sau mô tả cho cấu trúc của các activity properties:
94
Hình 5.4-Sơ đồ tổ chức các activity properties
Các basic properties đƣợc kế th a t ShapeNode, t ShapeNode ta có thể biết đƣợc nó là properties của activity nào. Mỗi activity properties sẽ có những phương thức riêng của mình. Việc cập nhật các properties đƣợc gọi thông qua basicproperties.
Mỗi activity properties đƣợc thiết kế một cửa số riêng để chỉnh sửa các thuộc tính của nó. Hình 5.11 là một ví dụ cho invoke properties:
Hình 5.5-Màn hình invoke properties
Xử lý kéo thả các activity
Thao tác kéo thả là một thao tác cơ bản trong một BPEL Designer. Việc kéo thả các activity giúp người dùng thuận tiện hơn trong việc thiết kế các process của mình.
95
Hình 5.12 là một mẫu process đƣợc thiết kế t BPELfx Designer với thao tác kéo và thả các activity:
Hình 5.6-Process đƣợc thiết kế t BPELfx Designer
Để xử lý cho vấn đề cập nhật kích thức của process sau mỗi thao tác kéo thả chúng tôi thiết kế các thuộc tính của activity theo dạng động (dynamic). Sau mỗi lần thay đổi activity thì một phương thức cập nhật kích thước được gọi để cập nhật lại kích thước thể hiện của process. Chi tiết cho xử lý này mời các các tham khảo trong source code đính kèm.
Xử lý phát sinh code
Phát sinh code là một yêu cầu quan trọng trong các BPEL Designer, t mô hình thiết kế hệ thống sẽ phát sinh ra BPEL code ở dạng xml và ngƣợc lại. Code phát sinh ra được lưu trữ trong tập tin có phần mở rộng là ‟‟.bpel „‟. Có hai vấn đề chính cần giải quyết trong xử lý phát sinh code :
Khi người dùng kéo thả một activity vào process thì yêu cầu hệ thống phải phát sinh ra code cho activity đó trong trong process bên dưới. Activity được phát
96
sinh ra phải đƣợc đặt đúng vị trí và đúng cấu trúc trong process đƣợc thể hiện trong designer.
Khi một process đƣợc mở t bpel file thì yêu cầu hệ thống phải đọc ra đƣợc cấu trúc của process bao gần các activity, các variable…. và thể hiện lại trên designer bằng mô hình.
Để giải quyết cho vấn đề trên chúng tôi đã thiết kế ra thƣ viện Model để phát sinh code trong quá trình kéo thảo các activity và ngƣợc lại. Thƣ viện này có nhiệm vụ đồng bộ giữa hai đối tƣợng đồ họa và code trong quá trình thiết kế. Ngoài ra các model này còn làm việc với các file wsdl. Hình 5.7 mô tả cho mẫu thiết kế này :
Hình 5.7-mẫu thiết kế xử lý phát sinh code
Xử lý biên dịch chương trình
97
Để xử lý biên dịch chúng em đã kế th a t thƣ viện biện dịch command line BpelC của ODE Apache để thiết kế ra một trình biên dịch riêng cho mình. Kết quả biên dịch sẽ đƣợc ghi vào file log, khi đã có đƣợc tập tin kết quả biên dịch chúng em sử dụng kết quả này để làm thông báo kiểm tra lỗi cú pháp cho hệ thống BPELfx Designer . Nếu không có lỗi cú pháp, sẽ có kết quả là biên dịch thành công.
Còn nếu có lỗi cú pháp, kết quả chi tiết về lỗi (tại dòng) sẽ đƣợc thông báo.
5.3.2 Thiết kế dữ liệu lưu trữ
Dữ liệu lưu trữ của hệ thống được thiết kế ở hai dạng khác nhau. Dạng cơ sở dữ liệu quan hệ được dùng để lưu trữ các thông tin của người dùng và project. Dạng dữ liệu xml được dùng để lưu trữ các tiến trình bpel.
Dữ liệu lưu trữ thông tin project
Được thiết kế ở dạng cơ sở dữ liệu quan hệ dùng để lưu trữ thông tin về người dùng trong hệ thống và các thông tin về project của người dùng đó. Lượt đồ cơ sở dữ liệu đƣợc thiết kết nhƣ sau:
Hình 5.8-lượt đồ cơ sở dữ liệu lưu trữ thông tin project
98
Thông tin các bảng đƣợc mô tả nhƣ sau:
Bảng Account:
Thuộc tính Kiểu dữ liệu Khóa
AccountID Số nguyên Khóa chính
Name Chuỗi
Sex Số nguyên
Email Chuỗi
Username Chuỗi
Password Chuỗi
Bảng 5.1-Bảng Account.
Mô tả: Bảng này dùng để lưu trữ thông tin tài khoản của người dùng trong hệ thống bao gồm cả thành viên và admin của hệ thống. Bảng này chứa các thông tin cơ bản của người dùng như: Tên, Giới tính, Email, Tên Đăng Nhập, Mật Khẩu…..Mỗi người dùng có một AccountID dùng để phân biệt với người dùng khác
Bảng User:
Thuộc tính Kiểu dữ liệu Khóa
UserID Số nguyên Khóa chính
Active Số nguyên
Bảng 5.2-Bảng Account
Mô tả: là bảng dùng để lưu trữ thông tin của user được phân biệt với admin của hệ thống. Thông tin chi tiết của mỗi user được lưu trữ ở bảng account và được truy xuất thông qua khóa ngoại UserID. Thuộc tính active cho biết người dùng trong hệ thống có bị khóa hay không.
Bảng Admin:
Thuộc tính Kiểu dữ liệu Khóa
AccountID Số nguyên Khóa chính
Bảng 5.3-Bảng Admin
99
Mô tả: bảng này dùng để lưu trữ người dùng là quản lý của hệ thống, được dùng để phân biệt với người dùng là thành viên của hệ thống. Mỗi Admin có AccountID dùng để phân biệt. Thông tin chi tiết của admin đƣợc truy xuất qua bảng Account.
Bảng Project:
Thuộc tính Kiểu dữ liệu Khóa
ProjectID Số nguyên Khóa chính
ProjectName Chuỗi
UserID Số nguyên Khóa ngoại tham chiếu
bảng User
ProjectPath Chuỗi
Description Chuỗi
Package Chuỗi
Published Số nguyên
Bảng 5.4-Bảng Project
Mô tả: bảng này dùng để lưu trữ thông tin của project, mỗi project đều có một thuộc tính ProjectID dùng để phân biệt, mỗi project thuộc về một người dùng duy nhất (UserID) và có một mô tả riêng (Description). Mỗi người dùng có thể có một hoặc nhiều project khác nhau. Mỗi project được lưu trữ vào một thư mục riêng trong hệ thống và đƣợc truy xuất thông qua ProjectPath. Thuộc tính Published cho biết trạng thái của project là đang sẵn sàng hay đã bị khóa.
Bảng File
Thuộc tính Kiểu dữ liệu Khóa
FileID Số nguyên Khóa chính
ProjectID Số nguyên Khóa ngoại tham chiếu
bảng project
FileName Chuỗi
Bảng 5.5-Bảng File
100
Mỗi project thì có thể có nhiều file khác nhau và đƣợc phân biệt thông qua thuộc tính FileID và có tên đại diện (FileName). Một File thuộc về duy nhất một project và một project thì có thể chứa nhiều file.
Bảng Url:
Thuộc tính Kiểu dữ liệu Khóa
Id Số nguyên Khóa chính
Pid Số nguyên Khóa ngoại tham chiếu bảng project
url Chuỗi
Uid Số nguyên Khóa ngoại tham chiếu bảng user Bảng 5.6-Bảng Url
Mỗi tiến trình BPEL sau khi deploy sẽ có một url để truy xuất. Thông tin này đƣợc lưu trữ vào bảng url. Mỗi tiến trình BPEL có một url duy nhất và thuộc về một project nào đó. Các url đƣợc phân biệt với nhau bằng thuộc tính ID.
Dữ liệu lưu trữ các tiến trình BPEL
Mỗi tiến trình BPEL được lưu trữ trong một tài liệu xml duy nhất và có phần mở rộng là „.bpel‟.
Cấu trúc của file BPEL nhƣ sau:
1 2 3 4 5 6 7 8 9 10
<process...>
<partnerLinks>
</partnerLinks>
<variables>
</variables>
<faultHandlers>
</faultHanders>
<sequence>
</sequence>
</process>
Bảng 5.7-Cấu trúc lưu trữ file BPEL
Tiến trình BPEL đƣợc định nghĩa theo dạng XML. Nội dung của tập tin XML này là một mô tả về logic của tiến trình cũng nhƣ các thông tin cần thiết khác (chẳng