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: (adsbygoogle = window.adsbygoogle || []).push({});
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 (adsbygoogle = window.adsbygoogle || []).push({});
Đ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ó.
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”: (adsbygoogle = window.adsbygoogle || []).push({});
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.
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.1Thiết kế các xử lý 5.3.1Thiế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 (adsbygoogle = window.adsbygoogle || []).push({});
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.2Thiế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:
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
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: (adsbygoogle = window.adsbygoogle || []).push({});
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