Các thành phần chính của kiến trúc ODE bao gồm các ODE BPEL compiler, ODE BPEL Engine Runtime, ODE đối tƣợng truy cập dữ liệu (DAO), ODE Layer tích hợp (ILS), và công cụ hỗ trợ ngƣời dùng... Một mô tả cấp cao của các mối quan hệ giữa các thành phần này đƣợc thể hiện trong FIGREF. Nó có thể đƣợc tóm tắt nhƣ sau: "Trình biên dịch chuyển đổi BPEL tài liệu thành một dạng thực thi. Các runtime –Engine có nhiệm vụ thực thi tiến trình đã đƣợc biên dịch này một cách chính xác dựa vào các store đƣợc liên tục truy cập đến các đối tƣợng DAO; các runtime-engine này đƣợc thực thi trong khuôn khỗ của một lớp tích hợp (Integration Layer) kết nối nó với các môi trƣờng khác rộng lớn hơn”[ 12 ]. Hình sau mô tả cụ thể cấu trúc của Apache ODE:
55
ODE Compiler: Trình biên dịch BPEL có trách nhiệm chuyển đổi mã nguồn của các thành phần mã nguồn BPEL (bao gồm các tài liệu BPEL, WSDL, các lƣợt đồ) thành một dạng biểu diễn của ngôn ngữ máy để thực thi. Đầu ra của trình biên dịch là danh sách các lỗi trong thành phần mã nguồn BPEL hoặc kết quá biên dịch thành công.
Dạng biểu diễn của BPEL đƣợc biên dịch t ODE compiler là một mô hình đối tƣợng tƣơng tự nhƣ trong cấu trúc BPEL gốc, và đƣợc lƣu trữ dƣới dạng file có phần mở rộng là cbp, là file duy nhất đƣợc gọi trong quá trình thực thi (run time).
ODE BPEL Engine Runtime: đƣợc thiết lập trong module BPEL-runtime và hỗ trợ cho việc biên dịch các quy trình BPEL. Nó chịu trách nhiệm kiểm soát lỗi cũng nhƣ đảm bảo tính đúng đắng của một tiến trình. Engine Runtime cũng đảm bảo tích logic trong việc gửi và nhận các thông điệp trong tiến trình, nó cho biết khi nào một thông điệp cần đƣợc tạo ra và khi nào một thông điệp cần đƣợc gửi đi. Tóm lại Engine Runtime thực hiện các API quản lý tiến trình đƣợc sử dụng bởi các công cụ hỗ trợ ngƣời dùng để tƣơng tác với ODE.
ODE Data Acess Object (DAO): là phƣơng tiện để tƣơng tác giữa các tiến trình BPEL và dữ liệu đƣợc lƣu trữ ở bên dƣới. Thông thƣờng cơ sở dữ liệu đƣợc lƣu trữ bên dƣới là dạng cơ sở dữ liệu quan hệ JDBC, trong trƣờng hợp này các DAO đƣợc gọi thông qua các thƣ viện dùng để truy cập dữ liệu OpenJPA. Các thƣ viện này cho phép ngƣời dùng có thể tạo ra một DAO riêng trong quá trình triển khai hoặc có thể sử dụng các DAO mà các nhà phát triển cơ sở dữ liệu cung cấp. BPEL Engine Runtime yêu cầu một DAO phải giải quyết đƣợc yêu cầu sau:
Active instances: phải giữ đƣợc phiên bản của các activity mới đƣợc tạo ra. Message routing: phải gửi đến đúng activity cần nhận
Variables: biến của BPEL cho mỗi activity.
PartnerLinks-phải giữ đƣợc giá trị của các PartnerLink. Trạng thái của tiến trình: trình tự thực hiện của tiến trình
Đối với OpenJPA/JDBC cấu trúc quan hệ đƣợc dùng để đáp ứng các yêu cầu trên đƣợc thể hiện trong FIGREF.
56
3.1.3 Cách cài đặt Apache ODE
Apache ODE đƣợc cung cấp miễn phí tại http: tomcat.apache.org . Chúng tôi xin giới thiệu tới các bạn cách cài đặt Tomcat version 5.5. Để cài đặt ODE và cấu hình ODE vào Tomcat Server ver 5.5 chúng ta cần thực hiện các bƣớc sau:
Bƣớc 1.Download ApacheTomcat Server version 5.5 tại: http://tomcat.apache.org
Bƣớc 2.Cài đặt Tomcat vào thƣ mục mà bạn lựu chọn.Giả sử thƣ mục đƣợc chọn để cài đặt ở đây là C:\apache\tomcat-5.5.26 .Thƣ mục này sẽ chứa toàn bộ các tập tin và thƣ mục mà Tomcat Server sẽ tham chiếu đến trong quá trình chạy.
Bƣớc 3.Download file deploy ODE có định dạng .war tại http://ode.apache.org/getting-ode.gtml, down loại tập tin apache-ode-war- 1.2.zip tại website nêu trên, giải nén tập tin trên ra một thƣ mục tạm, sau khi giải nén chúng ta có một tập tin có tên là ode.war trong thƣ mục tạm này.Copy tập tin ode.war vào thƣ mục mà chúng ta đã cài đặt Apache Tomcat : C:\apache\tomcat-5.5.26\ webapps.
Bƣớc 4.Chạy chƣơng trình comandline của window đƣa con trỏ về đƣờng dẫn C:\apache\tomcat-5.5.26\bin và gõ vào dòng lệnh sau:” catalina run” để khởi động và config Tomcat server:
57
Bƣớc 5.Sau khi khởi động Tomcat server thì ODE đã đƣợc cài đặt thành công, để kiểm tra bạn vào thƣ mục cài đặt Tocat Server và kiểm tra nếu có thƣ mục ode tồn tại thì ODE đã đƣợc cài đặt:
Hình 3.3-Cài đặt Apache ODE
3.1.4 Triển khai một quy trình P L lên Apche O
Để triển khai một quy trình BPEL lên ODE server thì có hai bƣớc cơ bản mà bạn cần phải thực hiện:
Tạo tập tin mô tả cho tiến trình và đặt tên deploy.xml.
Chép toàn bộ tập tin và thƣ mục của tiến trình vào thƣ mục webapps/ode/WEB- INF/processes của Apache Tomcat Server.
Để triển khai các tiến trình BPEL lên ODE thì bạn có thể thực hiện thủ công hoặc t sự hỗ trợ của các BPEL Designer. Hƣớng dẫn sau đây đƣợc chúng tôi thực hiện bằng ứng dụng do chúng tôi đang xây dựng và thử nghiệm cho đề tài của khóa luận. Để thực hiện hai công việc cơ bản trên thì chúng ta cần thực hiện các bƣớc sau:
Bƣớc 1.Tạo file deploy.xml: T cửa sổ của chƣơng trình chọn newfile, chọn loại file là deploy, sau đó click vào file deloy.xml bạn sẽ làm việc với màn hình sau :
58
Hình 3.4-Tạo file deploy.xml
Chọn port và process cần deloysau đó hệ thống sẽ tƣ động phát sinh ra nội dung tập tin deloy cho bạn.
Bƣớc 2. Chép toàn bộ các tệp tin của quy trình vào thƣ mục webapps/ode/WEB- INF/processes của Apache Tomcat Server. Bƣớc này đƣợc chúng tôi xử lý tự động với BPELfx Designer nhƣ hình sau :
59
Sau khi tạo xong thì file deploy có nội dung nhƣ sau:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
<?xml version="1.0" encoding="ASCII"?>
<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
xmlns:helloworld="http://helloworld" xmlns:sample="http://eclipse.org/bpel/sample"> <process name="sample:HelloWorld">
<active>true</active> <retired>false</retired>
<process-events generate="all"/> <provide partnerLink="client">
<service name="helloworld:HelloWorld" port="HelloWorldPort"/> </provide>
</process> </deploy>
Bƣớc 3. Test lại tiến trình đã deploy nhƣ hình 3.6 :
Hình 3.6-Test webservice
Để thực thi các tiến trình nghiệp vụ thì chúng ta cần phải có một engine hỗ trợ cho việc triển khai biên dịch cũng nhƣ thực thi. Một trong những engine hỗ trợ mạnh mẽ cho việc này là Apache ODE. Vì vậy chúng em quyến định sử dụng Apache ODE làm engine hổ trợ cho việc thực thi các tiến trình trong BPELfx Designer.
60
3.3 Tìm hiểu về U I và cách thức tổ chức lưu trữ dữ liệu 3.3.1 Khái niệm và ý tưởng về UDDI
UDDI(Universal Description, Discovery, and Integration) là một dự án nhằm hỗ trợ các doanh nghiệp trong việc trong việc publish và tìm kiếm các webservice. UDDI cung cấp các phƣơng thức chuẩn cho việc publish và tìm kiếm các webservice. Mục tiêu của UDDI là tạo ra một framework mã nguồn mở chạy trên một nền độc lập nhằm mô tả các dịch vụ, tìm kiếm các quy trình nghiệp vụ và tích hợp các dịch vụ kinh doanh. UDDI tập trung vào việc khai thác tầng business của kiến trúc SOA. Để sử dụng UDDI bản thân nó cung cấp các API dƣới dạng SOAP. Các API này có hai phƣơng thức chính đó là Inquiry dùng để truy vấn và Publisher dùng để đăng ký. Ngƣời phát triển phần mềm dùng các API này này publish các service của mình hay tìm kiếm các dịch vụ liên quan. Phần mềm sẽ đƣợc hƣớng đến việc tự tìm kiếm dịch vụ và tự động sử dụng nó thay vì cần phải có sự tác động của con ngƣời. Cả hai phía doanh nghiệp lẫn nhà phát triển phần mềm đều có thể publish các thực thể kinh doanh(business entities) và các dịch vụ mới thông qua cổng thông tin của UDDI, hình sau mô tả mối quan hệ giữa doanh nghiệp và các nhà phát triển:
Hinh 3.7-Mối quan hệ giữa doanh nghiệp và nhà phát triển
Hình 3.8 mô tả nguyên lý của UDDI project. UDDI Business Registry(UBR) nhƣ những đám mây công cộng (Public Cloud) , là một khái niệm về một hệ thống duy nhất đƣợc xây dựng t nhiều nodes khác nhau có dữ liệu đồng bộ thông qua việc
61
nhân bản. Một dãy các node điều hành đƣợc tạo ra có cấu trúc giống nhau để quản lý các thông tin về service mà các doanh nghiệp đẩy lên. Mỗi service đƣợc đẩy lên sẽ đƣợc quản lý bởi một node điều hành duy nhất. Các phƣơng thức để truy cập và lấy thông tin webservice t các node này là giống nhau, việc truy cập webservice xảy ra tại node đều hành quản lý nó. Các node đều hành này có trách nhiệm quản lý việc cập nhật nội dung chứa trong nó[ 15 ].
Hình 3.8-Ý tƣởng về UDDI
Tuy nhiên khái niệm về UDDI rộng hơn nhiều so với UBR; một doanh nghiệp có thể cung cấp một node điều hành riêng của họ, không phải là node đƣợc nhân bản ra bởi UBR. Các node điều hành mà doanh nghiệp cung cấp có dữ liệu không đồng bộ với UBR nhƣng cấu trúc bên trong thì giống nhau. Một nhóm các nhà doanh nghiệp có thể cung cấp một nhóm các node điều hành tạo thành một đám mây khép kín “private cloud”, các node đều hành này không có bất kỳ mối liên hệ nào với các node điều hành của UBR.
3.3.2 Cấu trúc dữ liệu của UDDI
UDDI định nghĩa một tập các lƣợt đồ XML để mô tả các kiểu dữ liệu.Các kiểu dữ liệu đƣợc UDDI tổ chức và mối liên hệ giữa chúng đƣợc thể hiện trong sơ đồ sau:
62
Hình 3.9-Sơ đồ các cấu trúc dữ liệu trong UDDI BusinessEntity
Là một cấu trúc mô tả các thông tin cơ bản về doanh nghiệp. Các thông tin này bao gồm: thông tin liên lạc, thông tin phân loại (category), định danh,mô tả, và các mối liên hệ với các thực thể kinh doanh khác. Mỗi thể hiện của cấu trúc businessEntity biểu diễn thông tin về một tổ chức hay công ty publish các webservice. businessEntity chứa các businessService thể hiện các service mà tổ chức đó cung cấp. Sơ đồ cấu trúc businessEntity nhƣ sau:
63
Mô tả :
uddi:DiscoveryURLs: Là danh sách các URL. Thƣờng các URL này dùng để tìm kiếm các thông tin thêm về tổ chức, công ty đƣợc diễn tả.
uddi:name: description, uddi:contacts là các thông tin về tổ chức, công ty. uddi:businessServices: danh sách các business service đƣợc cung cấp bởi
businessEntity.
uddi:identifierBag: để xác định duy nhất business entity bên cạnh businessKey.
uddi:categoryBag: là danh sách các category, mỗi category diễn tả một lĩnh vực kinh doanh của businessEntity.
dsig:Signature: chữ ký điện tử của business entity.
uddi:bindingTemplate: là danh sách các diễn tả kĩ thuật mà webservice cung cấp.
businessEntity còn chứa một thuộc tính là businesKey để xác định duy nhất businessEntity trong UDDI.
Publisher Assertion
Là một cơ cấu dùng để thiết lập mối quan hệ giữa hai cấu trúc BusinessEntity. Mối quan hệ này không thể đƣợc nhìn thấy công khai tr khi có sự chứng thực giữa hai doanh nghiệp với hai tài liệu Publisher Assertion riêng biệt. Một doanh nghiệp chỉ có thể thiết lập với một doanh nghiệp khác khi có sự chứng thực t phía đối tác, mối quan hệ này chỉ có thể đƣợc public khi phía doanh nghiệp đối tác cũng có mối quan hệ ngƣợc lại và có một tài liệu Publisher Assertion riêng biệt. Ví dụ Doanh nghiệp A thiết lập mối quan hệ với doanh nghiệp B (fromKey=A toKey=B) và mối quan hệ này sẽ đƣợc public khi doanh nghiệp B cũng thiết lập mối quan hệ với doanh nghiệp A(fromKey = B, toKey = A).
BusinessService
Một BusinessEntity có thể chứa một hoặc nhiều cấu trúc businessService.Cấu trúc businessService tƣợng trƣng cho một service, diễn tả các thông tin về mặt business của service. Mỗi businessService là con về mặt logic của một businessEntity. Các
64
thông tin về mặt kĩ thuật của service đƣợc diễn tả trong các bindingTemplate. Sơ đồ cấu trúc businessService nhƣ sau:
Hình 3.11-Sơ đồ cấu trúc ServirceBus [ 30 ] Mô tả:
uddi:name, uddi:description: tên và các chú thích cho businessService. uddi:categoryBag: một danh sách các category cho service. Mỗi category
diễn tả một lĩnh vực kinh doanh mà service có thể thuộc về.
bindingTemplate: là danh sách các diễn tả kĩ thuật mà web service cung cấp. businessService còn có 2 thuộc tính là businessKey xác định businessEntity mà service thuộc về và serviceKey xác định duy nhất service.
Về mặt kĩ thuật, mỗi element wsdl:service trong tài liệu WSDL sẽ đƣợc thể hiện là một businessService trong UDDI.
Cấu trúc bindingTemplate
BindingTemplate là cấu trúc biểu diễn các thông tin kĩ thuật về service. Mỗi bindingTemplate diễn tả một thể hiện của service với một địa chỉ URL để truy cập đến service nó diễn tả. bindingTemplate cũng diễn tả loại service mà nó diễn tả bằng cách tham chiếu đến một tModel. Sơ đồ cấu trúc bindingTemplate nhƣ sau:
65
Hình 3.12- Sơ đồ cấu trúc bindingTemplate [ 30 ]. Mô tả :
uddi:description:thông tin mô tả các Template
uddi:accessPoint: là địa chỉ URL thích hợp để invoke service đƣợc diễn tả. uddi:tModelInstanceDetails: danh sách các cấu trúc tModelInstanceInfo.
Mỗi tModelInstanceInfo chứa một tModelKey tƣơng ứng với tModel mà bindingTemplate tham chiếu tới.
uddi:categoryBag: gồm một danh sách các category. Mỗi category diễn tả môt lĩnh vực mà bindingTemplate có thể thuộc về.
Cấu trúc tModel:
Mục tiêu của cấu trúc tModel là biểu diễn các thông tin dùng cho ngƣời và máy tính biết đƣợc làm cách nào để giao tiếp với service khi họ không biết nhiều về service đó. Các thông tin đó bao gồm: cách thức hoạt động, cách thức giao tiếp hay các chuẩn mà service tuân theo. Có hai mục đích sử dụng tModel là:
Xác định sự thích hợp của webservice với nhu cầu ngƣời dùng
Cung cấp hệ thống các tham chiếu. hệ thống này có thể đƣợc sử dụng để lƣu các thông tin liên quan hay thông tin mở rộng về webservice.
66
Về mặt kĩ thuật, tModel có thể đƣợc sử dụng để mô tả interface (PortType), operation hay binding. Hay có thể đƣợc dùng để định nghĩa hệ thống category cho các tModel khác tham chiếu đến.Sơ đồ cấu trúc của tModel nhƣ sau:
Hình 3.13- Sơ đồ cấu trúc tModel Mô tả:
uddi:name, uddi:description: tên và chú thích của một tModel uddi:overviewDoc: diễn tả các thông tin tổng quan về một tModel. uddi:identifierBag: danh sách các identifier xác định tModel.
categoryBag: bao gồm danh sách các category để tham chiếu bởi tModel.
3.3.3 Giải pháp lưu trữ dữ liệu cho UDDI
Nhƣ đã nhận xét ở phần trƣớc, cấu trúc tModel trong UDDI là một cấu trúc khá linh động và ta có thể lƣu các dữ liệu ngữ nghĩa cho service ở đây. Trong hình 3.14 bênh dƣới, mỗi thành phần: portType, operation, binding trong tài liệu WSDL đƣợc biểu diễn trong UDDI là một entry kiểu tModel. Mỗi Operation thuộc về một PortType, vì thế trong categoryBag có một keyedReference tham chiếu đến tModel biểu diễn PortType, keyedReference đó có name = “PortType” và value=‟ID của
67
tModel PortType”. Mỗi binding tham chiếu đến portType để chỉ mối quan hệ: binding tƣơng ứng với PortType trong tài liệu WSDL.
Hình 3.14- Sơ đồ ánh xạ các thành phần WSDL vào tModel
Các concept đƣợc chú thích cho Operation và Input, Output của nó đƣợc lƣu trong categoryBag của tModel tƣơng ứng với Operation đó bởi keyedReference có keyName là: Func. Concept, Input, Output. Các concept chú thích cho PortType đƣợc lƣu trong categoryBag của tModel tƣơng ứng với PortType đó bởi keyedReference có keyName là “PortType Category”.
3.4 Kết luận
Nội dung của chƣơng này đã đƣa ra các giải pháp cho việc thực thi, lƣu trữ và tìm kiếm các web servirce. Với các kiến thức đã tìm hiểu đƣợc về Apache ODE và UDDI là nền tản và cơ sở lý thuyết cho việc xây dựng và thử nghiệm ứng dụng BPELFX Designer.
68
Chư ng 4 TÌM HIỂU VỀ CÔNG NGHỆ JAVAFX
Nội dung: ở chương này chúng tôi c ng sẽ giới thiệu sơ lư t về công nghệ Javafx, một giải pháp mà chúng tôi đã chọn đ xây dựng ng dụng của mình.
4.1 Khái niệm về JavaFx
Javafx đƣợc coi là sự kế tục của Java Applet cho phép xây dựng các ứng dụng RIA