TrưỜng đẠi học khoa học tự nhiên khoa công nghệ thông tin nguyễn mạnh luân-mai ngọc sưƠng nghiên cứu và phát triển bpel designer sử dụng công nghệ javafx khóa luận tốt nghiệp cử nhân cntt tp. Hcm, 2010



tải về 0.84 Mb.
trang1/7
Chuyển đổi dữ liệu21.12.2018
Kích0.84 Mb.
  1   2   3   4   5   6   7


TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

KHOA CÔNG NGHỆ THÔNG TIN

NGUYỄN MẠNH LUÂN-MAI NGỌC SƯƠNG

NGHIÊN CỨU VÀ PHÁT TRIỂN BPEL DESIGNER SỬ DỤNG CÔNG NGHỆ JAVAFX

KHÓA LUẬN TỐT NGHIỆP CỬ NHÂN CNTT

TP. HCM, 2010

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

KHOA CÔNG NGHỆ THÔNG TIN

NGUYỄN MẠNH LUÂN-0842083

MAI NGỌC SƯƠNG-0842126

NGHIÊN CỨU VÀ PHÁT TRIỂN BPEL DESIGNER SỬ DỤNG CÔNG NGHỆ JAVAFX

KHÓA LUẬN TỐT NGHIỆP CỬ NHÂN CNTT

GIÁO VIÊN HƯỚNG DẪN

NGUYỄN HOÀNG ANH




NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

Khóa luận đáp ứng yêu cầu của LV cử nhân tin học.

TpHCM, ngày …… tháng …… năm 2011

Giáo viên hướng dẫn



NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

………………………………………………………………………………

Khóa luận đáp ứng yêu cầu của LV cử nhân tin học.

TpHCM, ngày …… tháng …… năm 2011

Giáo viên phản biện



Lời cảm ơn

Chúng em chân thành cám ơn Khoa Công Nghệ Thông Tin, trường Đại Học Khoa Học Tự Nhiên, Đại học Quốc gia Tp. Hồ Chí Minh đã tạo điều kiện thuận lợi cho chúng em trong quá trình học tập và thực hiện đề tài tốt nghiệp.

Chúng em xin nói lên lòng biết ơn sâu sắc đối với thầy Nguyễn Hoành Anh, thầy đã luôn quan tâm, tận tình hướng dẫn chúng em trong quá trình học tập, nghiên cứu và thực hiện đề tài.

Chúng em xin chân thành cám ơn quý Thầy Cô trong Khoa Công Nghệ Thông Tin đã tận tình giảng dạy, trang bị cho chúng em những kiến thức quý báu trong suốt quá trình học tập và thực hiện đề tài. Chúng em cũng xin gửi lòng biết ơn đến thầy cô và bạn bè trong lớp đã giúp đỡ, động viên tinh thần chúng em rất nhiều trong suốt quá trình thực hiện luận văn này.

Chúng em nhớ mãi công ơn gia đình đã chăm sóc, động viên và tạo mọi điều kiện thuận lợi cho chúng em hoàn thành tốt luận văn này.

Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phép nhưng chắc chắn sẽ không tránh khỏi những thiếu sót, kính mong nhận được sự góp ý và tận tình chỉ bảo của quý Thầy Cô và các bạn.

Một lần nữa, xin chân thành cám ơn và mong luôn nhận được những tình cảm chân thành của tất cả mọi người

TP. Hồ Chí Minh, tháng 11 năm 2010

Nguyễn Mạnh Luân-Mai Ngọc Sương

Khoa Công Nghệ Thông Tin

Lớp Hoàn Chỉnh Đại Học

ĐỀ CƯƠNG CHI TIẾT



Tên Đề Tài : NGHIÊN CỨU VÀ PHÁT TRIỂN BPEL DESIGNER SỬ DỤNG CÔNG NGHỆ JAVAFX

Giáo viên hướng dẫn: Nguyễn Hoàng Anh

Thời gian thực hiện: Từ 25/6/2010 đến 14/2/2011

Sinh viên thực hiện: 0842083 – Nguyễn Mạnh Luân, 0842126 – Mai Ngọc Sương

Loại đề tài: Nghiên cứu lý thuyết, tìm hiểu công nghệ và phát triển ứng dụng



Nội Dung Đề Tài: Đây là đề tài về hướng nghiên cứu lý thuyết, tìm hiểu công nghệ và phát triển ứng dụng. Nội dung đề tài bao gồm các phần sau:

  • Tìm hiểu về kiến trúc hướng dịch vụ:SOA

  • Tìm hiểu về ngôn ngữ mô hình hóa BPEL

  • Nghiên cứu về ODE cho việc thực thi các tiến trình nghiệp vụ

  • Tìm hiểu về công nghệ Java FX để xây dựng Bpel Designer

  • Tìm hiểu về UDDI cho việc tìm kiếm và tổng hợp các WebService

  • Xây dựng BPEL Designer trên môi trường web cho phép người dùng xây dựng tìm kiếm , quản lý, lưu trữ cũng như thực thi các tiến trình nghiệp vụ.

Kế Hoạch Thực Hiện:

-Ngày 25/6/2010 nhận đề tài

-Từ 25/6/2010 -5/8/2010 tìm hiểu các mô hình và các công nghệ liên quan: RIA, SOA, BPEL 1.1, JavaFX,UDDI và thu thập các tài liệu có liên quan

-Từ 6/8/2010-15/8/2010 xác định và phân tích yêu cầu

-Từ 16/8/2010-31/8/2010 mô hình hóa yêu cầu , phân chia công việc

-Từ 1/9/2010-31/12/2010 bắt đầu triển khai ứng dụng

-Từ 1/1/2011 -25/1/2011 chạy bản Beta thực hiện các thay đổi và kiểm thử cần thiết

-Từ 26/1/2011-10/2/2011 tổng hợp xây dựng các tài liệu,báo cáo của dự án

-Ngày 12/2/2011 kết thúc dự án


Xác nhận của GVHD

Ngày 24 tháng 6 năm 2010


SV Thực hiện


Mai Ngọc Sương-Nguyễn Mạnh Luân

MỤC LỤC


DANH MỤC HÌNH



Hình 2.15-Mô hình của tiến trình 59

DANH MỤC CÁC BẢNG

Hình 2.15-Mô hình của tiến trình 59

TÓM TẮT KHÓA LUẬN

  • Các vấn đề ngiên cứu trong luận văn bao gồm:

  • Tìm hiểu về kiến trúc hướng dịch vụ:SOA

  • Tìm hiểu về ngôn ngữ mô hình hóa BPEL

  • Nghiên cứu về ODE cho việc thực thi các tiến trình nghiệp vụ

  • Tìm hiểu về công nghệ Java FX để xây dựng Bpel Designer

  • Tìm hiểu về UDDI cho việc tìm kiếm và tổng hợp các WebService

  • Xây dựng BPEL Designer trên môi trường web cho phép người dùng xây dựng tìm kiếm , quản lý, lưu trữ cũng như thực thi các tiến trình nghiệp vụ

  • Kết quả đạt được:

  • Lý thuyết về kiến trúc hướng dịch vụ, các ưu điểm của kiến trúc hướng dịch vụ, xu hướng của kiến trúc hướng dịch vụ trong tương lai được trình bày ở Chương 1 của luận văn.

  • Một số khái niệm về BPEL 2.0 bao gồm: định nghĩa về quy trình nghiệp vụ, các mô tả cho BPEL activity cùng một số khái niệm khác về BPEL được trình bày ở chương 2

  • Hệ thống lý thuyết về UDDI bao gồm : khái niệm, cấu trúc, cách thức tổ chức dữ liệu.., các lý thuyết về Java Fx được trình bày ở Chương 5

  • Xây dựng và thử nghiệm ứng dụng BPEL Designer với công nghệ Java Fx vận hành trên môi trường Web,hổ trợ người dùng thiết kế và thực thi các quy trình nghiệm vụ với ngơn ngữ mô hình hóa BPEL 2.0. Tích hợp công cụ tìm kiếm Web servirce

  • Nội dung khóa luận gồm có bảy chương:

Chương 1:Tông Quan

Chương 2: Phát triển và thực thi các quy trình nghiệp vụ với BPEL 2.0

Chương 3:Triển khai các quy trình nghiệp vụ với Apche ODE

Chương 4:Giới thiệu một số BPEL Designer trên thị trường hiện nay

Chương 5: Tìm hiểu về JavaFx và một số kiến thức về UDDI

Chương 6:Xây dựng và thử nghiệm công cụ BPEL-Fx-Designer

Chương 7: Kết luận.


  1. TỔNG QUAN

Nội dung: Trong chương này chúng tôi sẽ trình bày về thực trạng và xu hướng của nghành công nghệ phần mềm hiện nay.Từ những thực trạng và xu hướng này sẽ giới thiệu tới các bạn một trong những giải pháp cho xu hướng này đó là kiến trúc hướng dịch vụ SOA đồng thời tóm tắc mục tiêu và nội dung của khóa luận.

  1. Tổng quan về nền công nghiệp phần mềm hiện nay

Thế kỷ 21 là một thế kỷ với sự bùng nổ của cuộc cách mạng công nghệ thông tin đặt biệt là nền công nghiệp phần mềm.Xu hướng “Toàn cầu hóa” diễn ra một cách mạnh mẽ đến mọi mặt hoạt động kinh tế xã hội của hầu khắp các quốc gia trên thế giới. Công nghệ thông tin đang được ứng dụng mạnh mẽ vào đời sống kinh tế xã hội, nó ngày càng đóng một vai trò ngày càng quan trọng. Nó thổi vào nền kinh tế thế giới một luồng sinh khí mới. Nhanh chóng lan toả, mang đến những cơ hội đồng thời cũng là những thử thách to lớn không chỉ đối với những nước có nền kinh tế công nghiệp phát triển mà còn đối với những nước đang phát triển đang trên con đường công nghiệp hóa và hiện đại hóa như Việt Nam.

Tuy nhiên đi đôi với sự phát triển thì phần mềm cũng đem lại không ít những khó khăn cần được giải quyết.Phần mềm ngày càng trở nên phức tạp quá mức và dường như đang vượt khỏi tầm kiểm soát của các mô hình hiện có( chẳng hạng như OPP,COM/DCOM..). Yêu cầu đặt ra trước mắt là chúng ta phải tổ chức phần mềm theo một cách đơn giản đến mức có thể. Một thực trạng đáng buồn là có rất nhiều hệ thống phần mềm được thực hiện quá phức tạp, chi phí phát triển và bảo trì cao chót vót, đặc biệt với các hệ thống phần mềm cao cấp. Hàng chục năm qua, các kiến trúc phần mềm đã cố gắng giải quyết vấn đề này. Thế nhưng độ phức tạp vẫn tiếp tục tăng và dường như vấn đề này đã vượt quá khả năng xử lý của các kiến trúc truyền thống. Điều này một phần do ngày càng xuất hiện nhiều công nghệ mới tạo nên môi trường không đồng nhất, một phần do yêu cầu trao đổi tương tác giữa các hệ thống phần mềm với nhau. Những yêu cầu truyền thống đặt ra đối với tổ chức CNTT vẫn còn đó, cùng lúc phải đáp ứng nhanh chóng các yêu cầu mới, đòi hỏi phải liên tục giảm chi phí, có khả năng sử dụng và tích hợp các thành phần mới.... Hầu như mọi tổ chức mọi công ty đều phải đối mặt với vấn đề tích hợp vì nhiều lý do, đặt biệt là trong thị trường ngày nay, sự thay đổi luôn diễn ra với tốc độ cao và thường xuyên, các nghiệp vụ các chính sách luôn bị thay đổi và điều chỉnh liên tục để phù hợp với xu hướng thị trường. Sự thay đổi liên tục này đòi hỏi phần mềm phải có một cấu trúc mềm dẻo đễ tách rời cũng như dễ tích hợp.

Hầu hết các doanh nghiệp các tổ chức ngày nay đều sở hữu những ứng dụng với những kiến trúc và công nghệ khác nhau. Ở thập kỷ trước thì hầu hết các doanh nghiệp chọn giải pháp mua trọn gói một vài phần mềm lớn với các module được tích hợp sẵn thay vì cố gắng sữa và kết hợp chúng với nhau, bởi vì vào lúc này thì kết hợp các module từ nhiều nhà cung cấp khác nhau là một việc làm bất khả thi.Ngày nay các doanh nghiệp thường không chọn giải pháp mua trọn gói như vậy vì thường không linh hoạt và chi phí rất cao.Các doanh nghiệp đang cố gắng tìm cách kết hợp những ứng dụng cũ sao cho thỏa mãn yêu cầu nghiệp vụ, đó chỉ là việc tổng hợp những thông tin được trả về , giải pháp này sẽ vấp phải một số khó khăn như:


  • Không đáp ứng đủ các yêu cầu nghiệp vụ.

  • Phải làm việc với nhiều nhà cung cấp khác nhau đó là chưa kể các đối thủ .cạnh tranh và các quy trình phức tạp.

  • Phải làm việc với nhiều dạng dữ liệu khác nhau.

  • Các yêu cầu nghiệp vụ thay đổi liên tục đòi hỏi phải tốn chi phí cho việc cập nhật và tích hợp liên tục.

  • Việc cải tiến và thay đổi phải phụ thuộc vào các thành phần liên quan.

  • Vấn đề bảo mật cũng là một ảnh hưởng lớn khi đòi hỏi phải tích hợp từ nhiều hệ thống khác nhau với chế độ bảo mật khác nhau.

  • Khó khăn trong việc quản lý các quy trình nghiệp vụ, vì chúng được tích hợp từ nhiều module với nhiều kiến trúc khác nhau.

Đa phần những khó khăn trên xuất phát từ các nguyên nhân:sự phức tạp trong cấu trúc phần mềm, thiếu tính linh hoạt trong việc thiết kế hệ thống, và không có tính liên kết giữa các ứng dụng cùng loại.

Chúng ta đã có các kiến trúc như OOP (Object Oriented Programming), COM/DCOM (Distributed Common Object Model), CORBA (Common Object Request Broker Architecture)... và nhiều phương thức tích hợp ứng dụng nhanh và tốt hơn. Thế nhưng vẫn chưa có giải pháp nào hoàn chỉnh. Giờ đây, SOA đang được xem là 'ứng cử viên sáng giá' có thể đảm nhận trọng trách này và được kỳ vọng tạo nên cuộc cách mạng trong kiến trúc phần mềm.



  1. Giới thiệu về kiến trúc hướng dịch vụ(SOA)

  1. Khái niệm

SOA - Service Oriented Architecture (Kiến trúc Định hướng Dịch vụ), theo định nghĩa của DotNetGuru, là 'Khái niệm về hệ thống trong đó mỗi ứng dụng được xem như một nguồn cung cấp dịch vụ'[ ].

Nói theo một cách đơn giãn thì kiến trúc hướng dịch vụ (Service-oriented Architecture) là một hướng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng module và có khả năng truy cập thông qua môi trường mạng.Hệ thống SOA là một tập hợp các dịch vụ được chuẩn hóa trên mạng trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ.Sự cộng tác trong kiến trúc SOA được mô tả như sau:



d:\study\document\bpel_baocao\tailieuthamkhao\soa_howitwork.gif

Hình 1.1-Mô hình cộng tác SOA

Nhà cung cấp (Service provider) dịch vụ cần cung cấp thông tin về dịch vụ của mình cho một dịch vụ lưu trữ thông tin Service (Service registry). Người sử dụng (Service consumer) thông qua Service registry để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp.

SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triển khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có.

Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là hàm chức năng (mô-đun phần mềm) thực hiện qui trình nghiệp vụ nào đó. Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối 'mềm dẻo' với nhau (nghĩa là một ứng dụng có thể 'nói chuyện' với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới.

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ.

Ưu điểm quan trọng nhất của SOA là khả năng kết nối 'mềm dẻo' (nhờ sự chuẩn hóa giao tiếp) hay còn gọi là “Loose Coupling”[ ] và tái sử dụng. Các dịch vụ có thể được sử dụng với trình client chạy trên nền tảng bất kỳ và được viết với ngôn ngữ bất kỳ. (Ví dụ, ứng dụng Java có thể liên kết với dịch vụ web .NET và ngược lại).

SOA dựa trên hai nguyên tắc thiết kế quan trọng:



  • Mô-đun: Tách vấn đề lớn thành nhiều vấn đề nhỏ

  • Đóng gói: Che đi dữ liệu và lô-gic trong từng mô-dun (hay 'hộp đen') đối với truy cập từ ngoài[ ].

  1. Sự khác nhau giữa dịch vụ web và kiến trúc hướng dịch vụ

Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ. Điều này có thể làm bạn liên tưởng đến một công nghệ được đề cập nhiều gần đây: Dịch vụ web. Dịch vụ web cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau nhưng chúng không phải là một[ ].

Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực giao tiếp và phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi 'kiến trúc định hướng giao tiếp' thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ 1 chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ.

Định nghĩa cơ bản của dịch vụ web dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery ang Integration), cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp. Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn. (Hiện tại thì các công nghệ này làm việc tốt và hiệu quả).

Rõ ràng, theo định nghĩa thì dịch vụ web là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. Dịch vụ web đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải dịch vụ web (và không phải tất cả dịch vụ web đều có kiến trúc SOA). Tuy vậy, SOA và dịch vụ web có mối quan hệ tương hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công.



  1. Bốn nguyên tắc chính trong kiến trúc hướng dịch vụ

  • Sự rõ ràng về ranh giới giữa các dịch vụ

Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao tiếp. Thành phần giao tiếp này sẽ qui định về những định dạng thông điệp sử dụng trong quá trình trao đổi : thông điệp nào sẽ được chấp nhận và thông điệp nào sẽ không được xử lý[ ]. Và đây chính là cách duy nhất để các đối tượng bên ngoài có thể truy cập thông tin và chức năng của dịch vụ. Ta chỉ cần gửi các thông điệp theo các định dạng đã được định nghĩa trước mà không cần phải quan tâm đến cách xử lý của dịch vụ như thế nào (môi trường thực thi, ngôn ngữ lập trình...). Điều này đạt được do sự tách biệt giữa thành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ.

  • Các dịch vụ tự hoạt động

Các dịch vụ cần phải được triển khai và hoạt động như những thực thể độc lập mà không lệ thuộc vào một dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa là nó sẽ không bị sụp đổ khi có sự cố. Để thực hiện điều này, dịch vụ cần duy trì đầy đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động trong trường hợp một dịch vụ cộng tác bị hỏng; và để tránh các cuộc tấn công từ bên ngoài (như gửi thông điệp lỗi, hay gửi thông điệp ồ ạt) bằng cách sử dụng các kỹ thuật về an toàn, bảo mật...[ ]

Đây chính là ý nghĩa của khái niệm ‘loose coupling service’ mà ta đã đề cập trong định nghĩa SOA.



  • Các dịch vụ chia sẽ lượt đồ

Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoài, và hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.). Như thế hệ thống của ta sẽ có tính liên kết và khả năng dễ mở rộng.

  • Tính tương thích giữa các dịch vụ

Điều này nghĩa là, một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các chính sách (policiy) và yêu cầu (requirements) của dịch vụ đó như là mã hóa, bảo mật... Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai các yêu cầu, chính sách đó.

  1. Các tích chất của một hệ thống được thiết kế theo kiến trúc hướng dịch vụ

  • Tính kết nối mềm dẻo

Như đã đề cập ở trên thì một trong những tính chất quan trọng nhất của kiếm trúc SOA là khả năng kết nối mềm dẻo (Loose Coupling) có nghĩa là các đơn vị trong phần mềm có tính độc lập với nhau.Sự độc lập này có nghĩa là khi thay đổi một đơn vị nào đó thì nó sẽ gây ra ít ảnh hưởng nhất tới các đơn vị khác trong phần mềm. Điều này mang lại một sự tiết kiệm lớn về thời gian cũng như chi phí cho việc thay đổi hay bổ sung một chức năng mới cho phần mềm. Mức độ kết dính giữa các đơn vị trong phần mềm ảnh hưởng trực tiếp đến khả năng thay đổi của hệ thống. Giá trị lớn nhất của tính chất Loose Coupling mang lại đó là tính sẵn sàn cho việc thay đổi công nghệ theo thời gian của phần mềm.

  • Tái sử dụng dịch vụ

Vậy làm thế nào để tăng tính Loose Coupling giữa các đơn vị phần mềm với nhau, một trong các đặt điểm sau đây sẽ ảnh hưởng đến tính Loose Coupling giữa các đơn vị phần mềm:

  • Tính logic và ngôn ngữ của dịch vụ phải độc lập với yêu cầu của dịch vụ.Bạn có thể thay đổi thuật toán cũng như cấu trúc của dịch vụ để đạt được hiểu quả cao hơn mà không làm thay đổi yêu cầu.

  • Mức độ coupling tăng dần khi khi bên sử dụng dịch vụ càng cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp. Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ giữa hai bên càng chặt.

  • Sử dụng dịch vụ bất đồng bộ

Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận. Bên nhận xử lý thông tin và trả kết quả về thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp được xử lý xong. Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch vụ chuyển thông điệp, các yêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lý với tốc độ tối ưu. Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ. Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ.

  • Quản lý các policy

Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các policy. Các policy cần được quản lý các áp dụng cho mỗi dịch vụ cả khi thiết kế lẫn khi trong thời gian thực thi.

Việc này tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng. Bởi vì các policy được thiết kế tách biệt, và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm. Nếu không sử dụng các policy, các nhân viên phát triển phần mềm, nhóm điều hành và nhóm nhóm hỗ trợ phải làm việc với nhau trong suốt thời gian phát triển để cài đặt và kiểm tra những policy. Ngược lại , nếu sử dụng policy, những nhân viên phát triển phần mềm giờ chỉ cần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗ trợ tập trung vào các luật kết hợp.



  • Coarse granularily

Khái niệm granularity trong dịch vụ có thể hiểu theo hai cách. Đầu tiên, nó được hiểu trong phạm vi toàn bộ kiến trúc cài đặt của dịch vụ. Thứ hai, nó được hiểu trong phạm vi từng phương thức của từng interface triển khai. Mức độ granularity cũng được hiểu ở mức tương đối. Ví dụ, nếu một dịch vụ cài đặt tất cả chức năng của một hệ thống ngân hàng, chúng ta xem nó là coarse-grained. Nếu nó hỗ trợ chỉ chức năng kiểm tra thể tính dụng, chúng ta lại xem nó là fine-grained.

Trước khi có kiến trúc thành tố và dịch vụ, các hệ thống phân tán chủ yếu dựa trên ý tưởng phân tán đối tượng. Những hệ thống phân tán đối tượng chứa bên trong nó nhiều đối tượng fine-grained trao đổi thông tin với nhau qua mạng. Mỗi đối tượng có những ràng buộc với nhiều đối tượng khác bên trong hệ thống. Do truy cập đến một đối tượng phải qua nhiều trung gian mà hiệu quả đạt được không cao nên khuynh hướng thiết kế hệ thống phân tán đối tượng đang dần chuyển sang thiết kế các coarser-grained interface.



  • Khả năng cộng tác

Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác (Interoperability), khả năng mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau. Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng kết nối. Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu. Interoperability is achieved bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client. Kỹ thuật này đạt được bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung gian. Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống. Ví dụ Web Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống, JAX-RPC và JAXM chuyển đối tượng dạng Java thành SOAP.[ ]

  • Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm truy tìm dịch vụ (service discovery). Một người sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần. Người sử dụng chỉ cần hỏi một registry về dịch vụ nào thoả yêu cầu tìm kiếm. Ví dụ, một hệ thống chuyển khoảng (consumer) yêu cầu một registry tìm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng. Registry trả về một tập các entry thoả yêu cầu. Các entry chứa thông tin về dịch vụ, bao gồm cả phí giao dịch. Bên sử dụng sẽ chọn một dịch vụ có phí giao dịch thấp nhất trong danh sách các dịch vụ trả về, kết nối đến nhà cung cấp dịch vụ đó dựa trên thông tin registry entry để sử dụng dịch vụ kiểm tra thẻ tín dụng. Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cần thiết dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô tả cung cấp và gửi đi. Nhà cung cấp dịch vụ sẽ thực thi kiểm trả thẻ tín dụng và trả về một thông điệp có định dạng đúng như trong phần mô tả dịch vụ. Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry trung gian. Mối ràng buộc này là ràng buộc trong thời gian chạy chứ không phải ràng buộc trong lúc biên dịch. Tất cả thông tin cần thiết về dịch vụ được lấy về và sử dụng trong khi chạy.

  • Tự phục hồi

Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. Một hệ thống tự hồi phục (self-healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần sự can thiệp của con người.

Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nao trong tình trạng hỗn loạn. Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thể hoạt động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tổng hợp từ những từ nhiều dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy phụ thuộc vào khả năng phụ hồi của phần cứng sau khi bị lỗi. Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên đó ứng dụng được xây dựng. Một kiến trúc hỗ trợ kết nối và thực thi động khi chạy sẽ có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên.

Thêm vào đó, bởi vì những hệ thống dựa trên dịch vụ yêu cầu sự tách biệt giữa interface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một interface. Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì. Khả năng này chỉ có được khi client chỉ tương tác với interface của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ. Đây là một trong những tính chất cơ bản của các hệ thống hướng dịch vụ.


  1. Lợi ích mà kiến trúc hướng dịch vụ mang lại

Đầu tiên hãy đặt lợi ích của SOA trong triển vọng. SOA là một lưỡi hái mà nó thái mỏng sự phức tạp và sự dư thừa. Nếu công ty của bạn không lớn hay phức tạp, ví dụ hơn 2 hệ thống cơ bản đòi hỏi vài cấp tích hợp – không có vẻ như SOA sẽ mang lại nhiều lợi ích. Thất bại trong tất cả các quảng cáo thổi phổng sự thật về SOA hiện nay là thực tế mà phương pháp luận phát triển này bản thân nó không đem lại lợi ích thực – đó là những tác động mà nó có được trên một cơ sở hạ tầng dư thừa và phức tạp, cái cơ sở mà đem lại phần thưởng. Các kiến trúc sư nói có nhiều công việc có liên quan đến việc tạo một ứng dụng hướng dịch vụ tốt hơn là có một sự tích hợp phần mềm ứng dụng truyền thống hiện có. (Các cuộc điều tra cho thấy SOA đang được sử dụng cho việc tích hợp ứng dụng truyền thống ở hầu hết các công ty). Vì vậy thực tế có một chi phí bổ sung sinh ra do việc phát triển SOA trả trước. Vì có một lợi ích từ công việc đó nên nó phải loại bỏ công việc ở nơi nào khác bởi vì phương pháp luận này trong nội tại bản thân nó không hề tạo lợi ích kinh doanh[ ]. Trước khi xem xét xem liệu SOA có lợi ích hay không, đầu tiên bạn phải quyết định xem liệu có sự dư thừa nào không, thật tồi tệ nếu các ứng dịng được tích hợp mà có thể được cố kết hay bị loại bỏ là kết quả của việc chấp nhận SOA. Trong trường hợp này thì có vài lợi ích tiềm năng.

Để nhận được bức tranh toàn cảnh những lợi ích được bán kèm với SOA, bạn phải quan sát nó ở 2 mức: đầu tiên, là những ưu điểm (lợi ích) sách lược của sự phát triển hướng dịch vụ và thứ hau đó là những ưu điểm của SOA như là một chiến dịch kiến trúc tổng thể.



  1. Ưu điểm và khuyết điểm của hệ thống SOA

Đối với nhà phát triển dịch vụ[ ]:

  • Tái sử dụng phần mềm. Nếu gói mã mà tạo thành một dịch vụ có quy mô và kích thước phù hợp sau đó nó có thể được tái sử dụng cho lần kế tiếp, một đội phát triển cần chức năng cụ thể đó cho một ứng dụng phần mềm mới mà nó mong muốn xây dựng. Họ không cần biết bất cứ thứ gì về việc mã được gói chặt như thế nào hay nó có nguồn gốc từ đâu. Tất cả những thứ mà họ cần làm đó là xây dựng một sự kết nối đến mã đó.

  • Trong một công ty mà thường xuyên xây dựng những hệ thống mới dựa trên những chức năng tương tự - ví dụ một công ty bảo hiểm với nhiều bộ phận, mỗi một bộ phận đảm nhận cho các sản phẩm khác nhau hay một công ty thường xuyên thu được những công ty mới – thời gian được tiết kiệm thông qua việc phát triển, kiểm thử và tích hợp đó với chức năng phần mềm nhỏ bé tương tự đó có thể thêm vào.Năng suất gia tăng. Nếu các lập trình viên tái sử dụng các dịch vụ điều đó có nghĩa là các dự án phần mềm có thể tiến xa hơn và đội phát triển tương tự có thể tiếp tục nhiều dự án hơn. Sự tích hợp trở nên rẻ hơn nhiều( theo ước tính của Gartner thì ít nhất sẽ rẻ hơn 30%) và cũng nhanh hơn, chu trình phát triển các dự án mới sẽ giảm bớt thời gian đi vài tháng.

  • Linh hoạt Thậm chí nếu các dịch vụ sẽ không được tái sử dụng, thì họ có thể đưa ra nhiều giá trị nếu họ làm cho hệ thống CNTT chỉnh sửa dễ dàng hơn. Ví dụ tại website ProFlowers.com có nhiều ứng dụng dư thừa hoặc tình trạng kêu la của nhiều đơn vị doanh nghiệp. Tuy nhiên theo ông Kevin Hall giám đốc CNTT của ProFlowers thì việc phân chia quá trình đặt hoa thành các dịch vụ riêng rẽ có nghĩa là mỗi một cấu phần có thể được tách biệt và được thay đổi như mong muốn để xử lý các cụm hoa theo yêu cầu nảy sinh xung quanh các ngày nghỉ. Khi ProFlowers đã có một ứng dụng nguyên khối, đơn lẻ xử lý quá trình đó thì một sự thay đổi đơn lẻ trong quy trình đó hay một sự gia tăng số lượng giao dịch( nói vào ngày Lễ tình nhân) đồng nghĩa với việc xé nhỏ toàn bộ hệ thống và xây dựng lại hệ thống đó.

Đối với các doanh nghiệp và các tổ chức sử dụng dịch vụ[ ]:

  • Định hướng kinh doanh. SOA là một bức tranh lớn của tất cả các quy trình kinh doanh và dòng dịch chuyển trong một công ty. Điều đó có nghĩa là người làm kinh doanh lần đầu tiên có thể mường tượng toàn bộ các quy trình kinh doanh được xây dựng theo quan điểm của công nghệ. Khi các dự án CNTT được đặt theo quan điểm của các hoạt động và các quy trình kinh doanh hơn là các ứng dụng phần mềm phức tạp, những người làm kinh doanh có thể đánh giá và ủng hộ các dự án CNTT tốt hơn. Tầm nhìn vĩ đại đối với SOA là khi dịch vụ CNTT toàn diện kích hoạt được các quy trình lớn của một doanh nghiệp, người làm kinh doanh một ngày nào đó sẽ có thể nắm quyền chỉnh sửa, pha trộn và kết hợp nhịp nhàng, ăn khớp các dịch vụ khác nhau đó với nhau thành những sự kết hợp quy trình mới trên chính doanh nghiệp của họ. Tuy vậy tầm nhìn này còn là viễn cảnh trong nhiều năm.

  • Một cách thức tốt hơn để nâng cao vị thế CNTT. Kiến trúc doanh nghiệp là khái niệm mà đã khá lâu người ta không dám nói đến tên của nó. Một vài giám đốc CNTT tiến đến những bước đi lớn để nhằm tránh việc sử dụng thuật ngữ này với những người ngang cấp vì sợ hăm dọa, làm xa lánh hay đơn giản là việc làm cho họ buồn tê tái. Kiến trúc doanh nghiệp luôn luôn là một công việc lớn, khó khăn và đắt đỏ còn chỉ số đầu tư hiệu của (ROI) của nó thường không rõ ràng đối với doanh nghiệp đó. Việc tiêu chuẩn hóa, ánh xạ và kiểm soát các tài sản CNTT không làm cho doanh nghiệp đó linh động hơn, có năng lực hơn và nhiều lợi nhuận hơn. Kết quả là, những nỗ lực kiến trúc CNTT thường thất bại hoặc trở nên hoàn toàn hướng về CNTT. SOA cung cấp giá trị cho doanh nghiệp đó mà với kiến trúc doanh nghiệp cũ thì chỉ là những lời “hứa hươu, hứa vượn”. Tái sử dụng, năng suất và sự nhanh nhạy trong CNTT thông tin được nâng cao và một cơ sở hạ tầng phần mềm ăn khớp với các quy trình kinh doanh cụ thể là sự hấp dẫn để bán một nỗ lực kiến trúc doanh nghiệp cho doanh nghiệp đó. Nhưng phải nhớ rằng kiến trúc ấy không giành cho tất cả mọi người. Các công ty nhỏ hoặc các công ty phân tán lớn có thể không thể điều chỉnh được một đội ngũ nhân sự tập chung gồm các giám đốc dự án, các kiến trúc sư và các lập trình viên.

  1. Xu hướng ứng dụng SOA hiện nay

Hiện nay thì IBM là một trong những nhà cung cấp dịch vụ lớn trên thế giới. Các sản phẩm của IBM triển khai thực hiện SOA và mô hình lập trình SOA ngày càng nhiều hơn. Các lập trình viên xây dựng các dịch vụ, sử dụng các dịch vụ và phát triển các giải pháp để kết hợp các dịch vụ[ ].

Hầu hết các tài liệu về các dịch vụ web tập trung chủ yếu vào các giao diện dịch vụ và việc sử dụng chúng. Để bổ sung đầy đủ các tiêu chuẩn giao diện và các cách làm thực tế tốt nhất, IBM giới thiệu một mô hình lập trình để triển khai thực hiện các dịch vụ và lắp ráp chúng thành các giải pháp. Bằng việc mở rộng khả năng tiếp cận các nền tảng phần mềm của IBM đến cộng đồng những người sử dụng rộng lớn hơn -- bao gồm cả các nhà lập trình không truyền thống -- mô hình này cung cấp các kiểu thành phần mới phù hợp với vai trò, các mục tiêu, các kỹ năng và khung thiết kế của người sử dụng. Các kiểu thành phần này cho phép áp dụng các công cụ phát triển trực quan hơn. Một chủ đề chính khác nữa là tăng khả năng tiêu thụ thông qua bộc lộ dần từng bước các đặc tính và các khả năng của mô hình lập trình này[ ].



d:\study\document\bpel_baocao\tailieuthamkhao\figure1.gif

Hình 1.2-Kiến trúc sản phẩm của IBM

Các sản phẩm hỗ trợ khung nhìn IBM về một SOA được chia thành hai thể loại lớn: các điểm cuối (endpoints) dịch vụ và kết cấu truyền dẫn thông báo liên kết chúng với nhau. Kiến trúc chung này -- được nhiều sản phẩm góp phần vào, không một sản phẩm riêng biệt nào trong số này có thể là phương tiện chuyển tải duy nhất cho SOA của IBM -- được minh họa trong Hình 1.2.

Ở vị trí trung tâm là một ESB cung cấp kết nối giữa các dịch vụ. ESB này là dịch vụ đa giao thức, hỗ trợ kiểu truyền thông điểm-đến-điểm và đăng ký-công bố (publish-subscribe) và trung gian hòa giải để xử lý các thông báo ngay trên đường đi. IBM WebSphere MQ, IBM WebSphere MQ Integrator Broker và hỗ trợ WebSphere cho các dịch vụ web và các dịch vụ Thông báo của Java (JMS), tất cả đều thuộc thể loại đầu tiên.

Ngoài IBM thì hãn Motorola cũng đang tích cực triển khai các hệ thống của mình, tại diễn đàn của InfoWorld, đại diện hãng Motorola cho biết sau ba năm xây dựng SOA họ đã triển khai được 180 dịch vụ và năm sau con số này sẽ tăng lên 1.000. Lợi ích mà SOA mang lại là sự tích hợp dữ liệu đơn giản thông qua XML, chi phí thấp, tốc độ cao, đáp ứng nhanh những yêu cầu của doanh nghiệp[ ]. Theo chuyên gia Graham của hãng BEA Systems, trong phạm vi một doanh nghiệp, cơ hội rộng mở mà SOA tạo ra sẽ cho phép "các công ty phát minh ra được những điều thú vị, khách hàng có cơ hội làm được nhiều điều mà ta không thể tưởng tượng nổi. Với dịch vụ web, bạn có thể công khai các quy trình hoạt động. Đó là một "nguồn mở" của ứng dụng này".Tuy nhiên, việc triển khai SOA vẫn còn gặp nhiều rào cản. Toby Redshaw, Phó chủ tịch Motorola, cho biết việc triển khai SOA cần những yếu tố quan trọng như UDDI nói trên (Universal Description Discovery and Integration), sự giám sát, quản lý và an ninh cho các dịch vụ web. Ngoài ra, đó là sự không đồng nhất của nền xử lý, vấn đề lưu dữ liệu. Mark Carges, chuyên gia của BEA Systems, nhận định rằng thước đo thật sự của SOA phải là khả năng tái sử dụng dịch vụ vì không ai muốn viết lại mã lệnh chương trình đến lần thứ hai.

Một cuộc nghiên cứu gần đây của Forrester cho thấy việc ứng dụng SOA ở khu vực châu Á-Thái Bình Dương đã tăng 44%. Theo số liệu của Oracle, ở Việt Nam nhu cầu về nền tảng công nghệ SOA của Oracle (Oracle SOA Technologies) rất lớn. Để giúp khách hàng của Oracle ở Việt Nam đưa ra được các quyết định quan trọng về CNTT, Oracle đã và đang chia sẻ thành công việc triển khai các ứng dụng sử dụng nền tảng công nghệ Oracle SOA trên toàn thế giới để họ hiểu được những lợi ích mà họ có thể đạt được. Các doanh nghiệp trong nước thường muốn biết SOA mang lại những gì cho các doanh nghiệp tương tự trên thế giới.

Việt Nam và các nước khác trong khu vực Đông Nam Á rất quan tâm đến việc tìm hiểu kỹ càng về SOA và đã thực hiện những dự án SOA đầu tiên. Rõ ràng là những thành công của các dự án SOA ban đầu này đã cho thấy SOA không chỉ là công nghệ. Có rất nhiều khách hàng bàn về việc thay đổi phương pháp thực hiện dự án để đạt được những lợi ích lớn hơn từ SOA vì họ đã nhìn thấy sự liên hệ giữa phương pháp và kết quả sẽ đạt được.

Ngành viễn thông, một ngành có những hệ thống thông tin phức tạp nhất trên thế giới, đã thể hiện mình là một trong những ngành triển khai SOA thành công nhất. Ngành dịch vụ tài chính hiểu rất rõ về các dịch vụ và quy trình nghiệp vụ đang ngày càng tiếp cận với SOA cho phép họ phát triển các dịch vụ mới nhanh hơn. Chúng ta cũng đã được thấy những lợi ích to lớn trong những ngành dịch vụ công, bán lẻ cũng như lĩnh vực sản xuất.

Tóm lại SOA sẽ giúp cho công việc phát triển phần mềm trở nên dễ dàng và nhanh chóng hơn. 'Đừng tốn công chế tạo lại bánh xe', hãy kết hợp những linh kiện (dịch vụ) có sẵn và bổ sung những gì cần thiết để 'lắp ráp' nhanh chóng 'chiếc xe' đưa bạn đến đích. Đó là triết lý của SOA! Ngay từ bây giờ bạn có thể áp dụng triết lý này cho các hệ thống phần mềm của mình để sẵn sàng cho những nhu cầu của ngày mai.


  1. Giới thiệu đề tài nghiên cứu và phát triển BPEL-Designer với công nghệ JAVA-FX

  1. Lý do thực hiện đề tài nghiên cứu và phát triển BPEL Designer

Với sự phát triển và ứng dụng mạnh mẽ của công nghệ SOA vào các quy trình nghiệp vụ và đang mang lại một lợi ích lớn cho các tổ chức và doanh nghiệp.Đi đôi với kiến trúc SOA là sự phát triển của các ngôn ngữ mô hình hóa các quy trình nghiệp vụ như:XPDL, BPML,BPEL…. Nó giúp cho các lập trình viên và các nhà sử dụng dịch vụ đơn giãn hóa việc tổng hợp cũng như xây dựng các dịch vụ riêng cho mình.Chúng không phải là một ngôn ngữ được sử dụng cho việc phân tích thiết kế và được thể hiện bằng một bộ cú pháp xml và có các giao thức riêng của mình, chúng không có một ngôn ngữ riêng cụ thể nào cả mà chỉ được thể hiện qua các giao diện đồ họa, cũng không có một chuẩn ký hiệu chung cho các ngôn ngữ này.Trong các ngôn ngữ trên thì BPEL là ngôn ngữ được sử dụng rộng rãi nhất.Từ năm 2003 tổ chức OASIS đã mua bản quyền và chịu trách nhiệm cho sự phát triển của ngôn ngữ BPEL..Để hổ trợ cho việc thể hiện các ngôn ngữ này thì các công cụ desingner được phát triển ra như là một tất yếu. Có rất nhiều Design Engine được phát triển bởi nhiều tổ chức khác nhau như Oracle SOA Suite, PPEL Eclipse Plugin… hổ trợ mạnh mẽ cho việc tổng hợp và xây dựng các dịch vụ.

Tuy nhiên với sự phát triển mạnh mẽ của của internet và các công nghệ web đã là cho nhu cầu sử dụng và chia sẽ các ứng dụng thông qua môi trường web như là một nhu cầu tất yếu. Vì vậy nhu cầu xây dụng các công cụ hổ trợ cho việc tổng hợp và thiết kế các dịch vụ trên môi trường web là một nhu cầu có thật và hiển nhiên. Vấn đề đặt ra là làm sao các nhà sử dụng cũng như cung cấp dịch vụ có thể tạo ra một quy trình dịch vụ cũng như tiếp cận các dự án của mình một cách nhanh nhất vào mọi thời điểm và mọi nơi có kết nối internet mà không cần phải cài đặt sẵn các chương trình desingner.



Xuất phát từ vấn đề đó chúng em thực hiện nghiên cứu đề tài :” NGHIÊN CỨU VÀ PHÁT TRIỂN BPEL DESIGNER SỬ DỤNG CÔNG NGHỆ JAVAFX”.Chương trình được phát triển trên môi trường web với công nghệ Javafx một trong những công nghệ mới hiện nay.

  1. Mục tiêu của đề tài

Với nội dung có liên quan đến dịch vụ web và các kiến trúc cũng như công cụ của nó thì chúng em đã đặt ra các vấn đề sau đây cần phải nghiên cứu:

  • Tìm hiểu về kiến trúc hướng dịch vụ:SOA

  • Tìm hiểu về ngôn ngữ mô hình hóa BPEL

  • Nghiên cứu về ODE cho việc thực thi các tiến trình nghiệp vụ

  • Tìm hiểu về công nghệ Java FX để xây dựng Bpel Designer

  • Tìm hiểu về UDDI cho việc tìm kiếm và tổng hợp các WebService.

  • Xây dựng BPEL Designer trên môi trường web cho phép người dùng xây dựng tìm kiếm , quản lý, lưu trữ cũng như thực thi các tiến trình nghiệp vụ

  1. Các nghiên cứu liên quan đến BPEL-Designer và SOA trong khoa công nghệ thông tin đại học Khoa Học Tư Nhiên

Trong khoa công nghệ thông tin, đại học Khoa Học Tự Nhiên đã có một số đề tài nghiên cứu về SOA như:

  • Đề tài “nghiên cứu kiến trúc hướng dịch vụ (SOA) và ứng dụng” [ 2 ] của hai sinh viên: Hồ Bảo Thanh và Nguyễn Hoàng Long thực hiện năm 2005 là đề tài luận văn đầu tiên nghiên cứu về SOA tại khoa. Mục tiêu của đề tài là nghiên cứu các vấn đề có liên quan đến SOA và ứng dụng SOA để xây dựng một tiến trình nghiệp vụ.

  • Đề tài “Nghiên cứu kiến trúc hướng dịch vụ IBM và phát triển ứng dụng” của hai sinh viên: Nguyễn Hoàng Anh và Hoàng Vũ Tuấn thực hiện năm 2007 là đề tài nghiên cứu về kiến trúc hướng dịch vụ của hãng IBM và sử dụng các công cụ của IBM để phát triển ứng dụng.

  • Đề tài “Xây dựng môi trường thiết kế và vận hành SOA trên Web” của hai sinh viên: Trần Quang Duy và Nguyễn Trần Kha đã xây dựng một công cụ thiết kế SOA thực thi trên môi trường web.

  • Đề tài :” Nghiên cứu và xây dựng hệ thống thiết kế và vận hành quy trình tổng hợp dịch vụ Web ngữ nghĩa” cùa hai sinh viên Phan Lê Sang và Trần Ngọc Tịnh năm 2009,

Đề tài này được kế thừa và phát triển các kiến thức về SOA và BPEL từ các đền tài nêu trên.

  1. PHÁT TRIỂN VÀ THỰC THI CÁC QUY TRÌNH NGHIỆP VỤ VỚI WS-BPEL 2.0

Nội dung :Trong chương này chúng tôi xin giới thiệu tới các bạn ngôn ngữ mô hình hóa tiến trình dịch vụ và được dùng để phát triển các ứng dụng lớn và phức tập hiện nay-BPEL, chúng tôi sẽ giới thiệu chi tiết về các thành phần cũng như các khái niệm trong BPEL, cách xây dựng một tiến trình BPEL đơn giãn.

  1. Tổng quan về ngôn ngữ BPEL

  1. Giới thiệu

BPEL (Business Process Execution Language) là một ngôn ngữ dùng để hổ trợ phát triển các ứng dụng phức tạp, lớn đòi hỏi phải tổng hợp nhiều dịch vụ web khác nhau. Phiên bản BPEL đầu tiên (BPEL 1.0) ra đời vào tháng 07/2002. Vào tháng 05/2003 BPEL 1.1 ra đời dựa trên việc kết hợp BPEL 1.0 với một số ngôn ngữ khác và được đệ trình lên tổ chức OASIS (một tổ chức chuyên đưa ra các chuẩn thông tin). Tháng 04/2007 OASIS chuẩn hóa BPEL và đổi tên thành WS-BPEL 2.0 được dùng cho đến nay[ ].

BPEL cho phép bạn mô tả và xử lý luồng công việc bằng cách sử dụng trình soạn thảo đồ họa than thiện với con người.Ngoài ra BPEL còn định nghĩa các cách quản lý các sự kiện và ngoại lệ, cơ chế bảo toàn dữ liệu khi có ngoại lệ xảy ra.BPEL hoạt động dựa trên nguyên tắc gửi các thông điệp dạng XML đến một dịch vụ khác, thao tác trên cấu trúc XML, nhận các thông điệp XML (đồng bộ hay không đồng bộ) từ các service bên ngoài.Nó phụ thuộc vào bốn chuẩn XML cơ bản được xem như là các đặt tả để thực thi một tiến trình BPEL: WSDL, XML Schema 2.0,XPath 2.0 và WS-Addressing. Hình 2.1 thể hiện một tiến trình BPEL trong thực tế.



bpel.bmp

Hình 2.1- Ví dụ về một tiến trình BPEL



  1. Nguyên tắt hoạt động của một tiến trình BPEL

Trong số các đặc tả: : WSDL, XML Schema 2.0,XPath 2.0 và WS-Addressing trên thì WSDL đóng vai trò cốt lõi trong một tiến trình của BPEL.Cốt lõi của BPEL là khái niệm peer-to-peer là sự tương tác giữa các dịch vụ web được mô tả trong WSDL. Một tiến trình BPEL đặt tả làm thế nào để phối hợp giữa các dịch vụ khác nhau và kết hợp các dịch vụ đó lạ thành một tiến trình hoàn chỉnh.Điều này có nghĩa một tiến trình BPEL được định nghĩa hoặc cung cấp từ một hoặc nhiều đặt tả WSDL khác nhau, và cung cấp một đặt tả của riêng nó về quá trình tổng hợp các dịch vụ này[ ].

Tuy nhiên có một vấn đề đặt ra là: làm thế nào để tiến trình BPEL có thể phân biệt được từng service mà nó tổng hợp trên đó để mà tương tác trên những service đó. Cũng như mỗi service được sử dụng trong tiến trình BPEL có vai trò như thế nào trong toàn bộ tiến trình… Để giải quyết vấn đề này BPEL đã đưa ra hai khái niệm mới là partnerLinkType và partnerLink[ ].


  1   2   3   4   5   6   7


Cơ sở dữ liệu được bảo vệ bởi bản quyền ©tieuluan.info 2019
được sử dụng cho việc quản lý

    Quê hương