ĐẠI HỌC QUỐC GIA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN o0o BÁO CÁO Môn: Kiến trúc hướng dịch vụ (SOA) Đề tài: Tìm hiểu về BPEL Enginge Giảng viên: TS. Võ Đình Hiếu Nhóm thực hiện: Nguyễn Trần Ngọc Linh Nguyễn Việt Bảo Hà Thị Huyền Nguyễn Trọng Khôi Vũ Đức Tiệp Lớp: Quản lý hệ thống thông tin K1 Hà Nội, tháng 04/2011 MỤC LỤC 1 1. Kiến trúc hướng dịch vụ - Service Oriented Architecture 4 1.1 Các nguyên tắc cơ bản của hướng dịch vụ (Service orientation) 4 1.2 Áp dụng các nguyên tắc SOA 6 1.3 SOA tổng hợp (SOA Compositions) 13 1.4 Sự xếp đặt (Orchestration) 13 1.5 Nghệ thuật biên đạo (Choreography) 14 2 Ngôn ngữ thực thi tiến trình nghiệp vụ dịch vụ web (WS-BPEL) 16 2.1 Tóm tắt ngắn gọn về BPEL 16 2.2 Định nghĩa tiến trình 17 2.3 Phần tử import 18 2.4 Các định nghĩa <partnerLinkType> và <role> trong file WSDL 19 2.5 Các định nghĩa partnerLinks và partnerLink 20 2.6 Các định nghĩa variables và variable 21 2.7 Hoạt động có cấu trúc: Phần tử liên tục 22 2.8 Hoạt động dịch vụ web: Phần tử trả về 23 2.9 Hoạt động cơ bản: các phần tử assign, copy, from và to 24 2.10 Hoạt động dịch vụ web: Phần tử invoke 25 2.11 Hoạt động dịch vụ web: Phần tử reply 26 2.12 Hoạt động cơ bản: Phần tử wait 27 2.13 Hoạt động cơ bản: Phần tử throw 28 2.14 Hoạt động cơ bản: Phần tử exit 28 2.15 Hoạt động cơ bản: Phần tử empty 28 2.16 Hoạt động có cấu trúc: Phần tử while 28 2.17 Hoạt động có cấu trúc: Phần tử if 28 2.18 Hoạt động có cấu trúc: Phần tử pick 28 2.19 Hoạt động có cấu trúc: Phần tử flow 28 2.20 Hoạt động có cấu trúc: Phần tử compensationHandler 29 2.21 Hoạt động có cấu trúc: Phần tử correlationSets 29 2.22 Hoạt động có cấu trúc: Phần tử eventHandlers 29 2.23 Hoạt động có cấu trúc: Phần tử scope 29 3 Java Business Integration (JBI) – JSR 208 30 3.1 JBI Meta-Container 31 3.2 Service Engines 32 3.3 Binding Components 32 3.4 Normalized Message Router 33 3.5 JBI Normalize Message 34 3.6 Delivery Channel (kênh phân phối) 34 3.7 JBI Message Exchange Pattern 36 3.8 Service Invocation Patterns 36 3.9 In-Only Message Exchange Pattern 36 3.10 Robust In-Only Message Exchange Pattern 37 3.11 In – Out Message Exchange Pattern 38 3.12 JBI Message Exchange Routing 39 3.13 Information in the Service Units and Service Assemblies Routing 41 3.14 Service Unit Deployment for a Service Engine 41 3.15 JBI Composite Application Service Assembly 42 3.16 Connection Elements 43 3.17 Service Unit Deployments Intended for a Binding Component 43 3.18 Sample Descriptors 44 3.19 JBI Management, Monitoring, and Administration 45 3.20 Development of a JBI Component ( Service Engine or Binding Component) 46 3.21 Service Unit and Service Assembly Creation and Packaging 46 3.22 Service Assembly Deployment to the JBI Environment 48 1 1. Kiến trúc hướng dịch vụ - Service Oriented Architecture Trong khi việc sử dụng Web service cho phép bạn đạt được khả năng tương tác trên các ứng dụng được xây dựng trên nhiều nền tảng khác nhau với các ngôn ngữ khác nhau, việc áp dụng các khái niệm và nguyên tắc hướng dịch vụ khi xây dựng các ứng dụng dựa trên việc sử dụng Web service có thể giúp bạn tạo các giải pháp SOA mạnh mẽ, dựa trên chuẩn và có khả năng tương thích. [Có điều thú vị rằng Kiến trúc hướng dịch vụ trong khi cung cấp nền tảng kiến trúc cho việc xây dựng các giải pháp hướng dịch dụ, nó không trói buộc một công nghệ cụ thể hay thiết đặt công nghệ nào cả. Ngược lại, nó có thể được thực thi với nhiều loại công nghệ, ví dụ: DCOM, CORBA, hoặc Web Service. Tuy nhiên, chỉ có công nghệ Web Service hiện tại đang là hướng chính để đưa SOA vào thực tế. 1.1 Các nguyên tắc cơ bản của hướng dịch vụ (Service orientation) Như đã được đề cập, để xây dựng một giải pháp SOA dựa trên Web service, bạn cần phải tuân theo các nguyên tắc hướng dịch vụ khi sử dụng các dịch vụ cùng nhau trong cùng một ứng dụng. Dưới đây là một vài nguyên tắc quan trọng (khóa) của hướng dịch vụ mà bạn cần phải nhớ khi thiết kế các giải pháp SOA: - Kết nối lỏng lẻo (Loose coupling): biểu diễn một mối liên hệ thiếu logic của một dịch vụ để thay đổi một cách tối thiểu hoặc tác động đến các dịch vụ khác được sử dụng trong cùng SOA. Kết nối lỏng lẻo là nguyên tắc khóa của hướng dịch vụ. Các dịch vụ thực thi như các thành phần được liên kết lỏng lẻo của phần mềm cho phép bạn hiểu các nguyên tắc khóa khác của hướng dịch vụ, ví dụ như: khả năng sử dụng lại dịch vụ, dịch vụ tự chủ (service autonomy), và dịch vụ không trạng thái (service statelessness). - Hợp đồng dịch vụ (Service contract): biểu diễn các mô tả dịch vụ và các tài liệu khác. Nó mô tả cách một dịch vụ có thể được truy cập chương trình một cách tự động. Bên trong phần Binding với WSDL được mô tả trong chương trước, bạn thấy một ví dụ về tài liệu mô tả dịch vụ WSDL mô tả một dịch vụ, định nghĩa các quy định cho dịch vụ đó. - Trừu tượng hóa của thiếu logic (Abstraction of underlying logic): có nghĩa rằng một dịch vụ được đưa ra công khai chỉ khi logic được mô tả trong hợp đồng dịch vụ, dấu đi sự thi hành mô tả chi tiết từ các dịch vụ khách hàng (service consumers). Điều này có nghĩa rằng các dịch vụ tương tác với nhau chỉ thông qua các giao diện công khai của chúng. Như bạn đã học trong ví dụ trước, bộ mô tả WSDL mô tả một dịch vụ cung cấp các giao diện thực sự cho các dịch vụ khách hàng. - Tự chủ (Autonomy): có nghĩa là các dịch vụ chỉ kiểm soát về logic tính đóng gói của chúng. Việc phân chia ứng dụng về mặt logic thành tập các dịch vụ có tính tự chủ cho phép bạn xây dựng các giải pháp SOA một cách linh hoạt, đạt được tính liên kết lỏng lẻo, khả năng sử dụng lại và khả năng tổng hợp (composability). - Khả năng tái sử dụng (Reusability) trong hướng dịch vụ được thực hiện bằng cách phân tán ứng dụng về mặt logic giữa các dịch vụ để mỗi dịch vụ có thể được sử dụng bởi nhiều một service requestor. Việc xây dựng các dịch vụ có thể tái sử dụng hỗ trợ các nguyên tắc tổng thể (composability). - Có khả năng tổng hợp (composability) mô tả khả năng các dịch vụ được kết hợp thành dịch vụ hoàn chỉnh, phối hợp trao đổi dữ liệu giữa các dịch vụ đang được tổng hợp. Ví dụ, sử dụng ngôn ngữ xếp đặt (orchestration), ví dụ WS-BPEL, cho phép bạn tổng hợp các dịch vụ tinh thành các dịch vụ thô hơn. WS-BPEL được thảo luận tại phần BPEL sau của chương này. - Không trạng thái (Statelessness) có nghĩa rằng các dịch vụ không duy trì trạng thái cụ thể nào của chúng cho một hành động nào. Việc xây dựng các dịch vụ không trạng thái khuyến khích tính liên kết lỏng lẻo, khả năng tái sử dụng và khả năng tổng hợp (composability). - Khả năng tương tác (Interoperation) giữa các dịch vụ dễ dàng đạt được miễn là các dịch vụ tương tác với mỗi dịch vụ khác thông qua các giao diện, đảm bảo độc lập thực thi và độc lập nền tảng. - Có khả năng nhận biết (Discoverability) đề cập đến các cơ chế chuẩn làm cho nó có khả năng trong việc mô tả dịch vụ được nhận biết bởi các service requestor. Đặc tả Universal Description, Discovery và Integration (UDDI) cung cấp một cơ chế cho phép xuất bản các tài liệu mô tả dịch vụ trong một registry dựa trên XML, do đó làm cho chúng sẵn sàng sử dụng một cách công khai. Như bạn thấy, hầu hết các khái niệm đều có liên quan chặt chẽ với nhau. Ví dụ, nếu bạn theo nguyên tắc tự chủ khi phân chia ứng dụng logic thành các dịch vụ được sử dụng trong SOA, bạn sẽ có các được các nguyên tắc: tái sử dụng, có thể tổng hợp, và liên kết lỏng lẻo các thành phần của phần mềm để tái sử dụng trong các dự án tương lai. Mặt khác, việc bỏ qua ít nhất một nguyên tắc của hướng dịch vụ làm cho nó khó có thể giữ được các nguyên tắc khác. Ví dụ, nếu bạn bỏ qua nguyên tắc không trạng thái (statelessness) khi thiết kế các dịch vụ, bạn sẽ kết thúc với khối xây dựng mà không thể ít sử dụng và ít có thể tổng hợp cho các giải pháp SOA của bạn. 1.2 Áp dụng các nguyên tắc SOA Bây giờ các bạn đã biết các nguyên tắc khóa của hướng dịch vụ, đã đến lúc tìm hiểu xem làm thế nào để các nguyên tắc này có thể được áp dụng khi thiết kế các giải pháp SOA. Phần này thảo luận ngắn về tiến trình thiết kế một ứng dụng hướng dịch vụ, áp dụng các nguyên tắc hướng dịch vụ nêu trong phần trước. Giai đoạn phân tích hướng dịch vụ là giai đoạn đầu tiên trong tiến trình thiết kế một ứng dụng hướng dịch vụ. Bất kể việc liệu bạn sẽ xây dựng một giải pháp SOA khi ứng dụng logic có sẵn hay xây dựng nó từ đầu, bạn phải cân nhắc theo các câu hỏi sau: - Dịch vụ nào được yêu cầu để thỏa mãn các yêu cầu nghiệp vụ? - Ứng dụng logic nên được phân chia như thế nào giữa các dịch vụ? - Các dịch vụ nên được tổng hợp như thế nào để thực thi giải pháp SOA đã yêu cầu? Cách dễ nhất để hiểu được những gì phải được hoàn thành ở giai đoạn này là lên một ví dụ. Hãy tưởng tượng bạn chạy một trang tạp chí trực tuyến chuyên về xuất bản các bài báo kỹ thuật được gửi bởi những kỹ thuật viên làm việc trên cơ sở hợp đồng. Khi một tác giả tiềm năng gửi một đề xuất (proposal), bạn nhìn qua và sau đó chấp nhận hoặc từ chối nó, tùy thuộc vào nhu cầu biên tập hiện tại của bạn và một vài thứ khác. Sau đây là các bước chung bạn phải thực hiện khi chấp nhận một đề xuất: 1. Lưu đề xuất vào cơ sở dữ liệu 2. Lưu thông tin về tác giả (chỉ khi tác giả mới) 3. Thông báo cho tác giả về việc chấp nhận đề xuất. 4. Ban hành (issue) một PO 5. Gửi PO về cho tác giả. Bây giờ, giả sử bạn muốn thiết kế một giải pháp SOA tự động hóa tiến trình này. Như đã đề cập trước đó, điều đầu tiên bản phải xác định được những dịch vụ nào phải được xây dựng. Suy nghĩ những nguyên tắc hướng dịch vụ đã nêu trong phần trước, bạn có thể tạo ra các dịch vụ sau đây để sau đó được sử dụng khi xây dựng các khối trong giải pháp SOA đang được thiết kế: - Dịch vụ đề xuất - Dịch vụ tác giả - Dịch vụ thanh toán hóa đơn - Dịch vụ thông báo Như bạn đã thấy, 3 dịch vụ đầu tiên trong danh sách trên là các dịch vụ trọng tâm, đại diện các thực thể nghiệp vụ tương ứng. [Có 2 hướng tiếp cận chính để thiết kế các dịch vụ đại diện nghiệp vụ logic: thực thể trọng tâm và nhiệm vụ trọng tâm. Trong khi một dịch vụ nhiệm vụ trọng tâm bị ràng buộc chặt chẽ với một nhiệm vụ cụ thể và vì vậy khó có thể thay đổi và tái sử dụng, một dịch vụ thực thể trọng tâm đại diện cho một thực thể nghiệp vụ cụ thể, đại diện cho sự thay đổi tốt đang được sử dung lại trong các giải pháp đối với thực thể nghiệp vụ tương tự. cả hai hướng tiếp cận được thảo luận chi tiết trong chương 7, trong đó tập trung vào các vẫn đề liên quan đến mô hình nghiệp vụ hướng đối tượng.] Một dịch vụ thực thể trọng tâm thường cung cấp một tập đầy đủ các thao tác được yêu cầu để thao tác trong một cá thể của thực thể nghiệp vụ cụ thể. Ví dụ, dịch vụ Proposal (đề xuất) có thể hỗ trợ tập các thao tác sau đây để đáp ứng các yêu cầu xử lý: - saveProposal - getProposalById - getProposalByTitle - getProposalsByAuthor - getProposalsByTopic Giả sử rằng các tài liệu đề xuất được gửi lên có một cấu trúc nhất định (nói, từng đề nghị bao gồm chủ đề - Topic và phần dàn ý – Outline), danh sách các thao tác ở trên hỗ trợ bởi dịch vụ Proposal có thể cần được mở rộng thêm một vài thao tác có trách nhiệm duyệt các phần cụ thể của một đề xuất. Tuy nhiên, điều quan trọng để nhận ra rằng việc bao gồm các thao tác mới tác động vào giao diện dịch vụ, làm cho bạn phải chỉnh sửa tài liệu WSDL mô tả dịch vụ mỗi lần bạn thêm một thao tác mới. Có một cách để làm việc xung quanh vấn đề này là sử dụng các thao tác điều khiển tham số, chúng gọi phần yêu cầu thiếu logic phụ thuộc vào đối số được truyền vào. Trong trường hợp này, việc đóng gói hàm thiếu logic của thao tác điều khiển tham số ủy thác công việc cho một vài hàm khác nơi mà công việc hoàn thành thực sự. Ví dụ, bạn phải đưa ra một thao tác đơn để nhận về nội dung của một đề xuất, các tham số truyền vào các định xem liệu có tìm thấy tài liệu đề xuất thông qua ID hay tiêu đề và phần nào của đề xuất sẽ được trả lại. Trong trường hợp này, một thông điệp yêu cầu được đưa ra bởi một requestor để gọi đến thao tác getProposal như sau: Khi ban không đoán ra được bất kỳ nghi ngờ nào, tham số sử dụng trong ví dụ này nói với service provider trả lại toàn bộ tài liệu đặc tả đề xuất có tiêu đề là “Building services with PHP and Oracle XML DB”. Nếu bạn gọi lại từ ví dụ đã thảo luận trong phần Binding with WSDL, cấu trúc thông điệp mô tả nội dung trừu tượng logic của thông điệp đầu vào hoặc thông điệp đầu ra sẽ sử dụng với một thao tác RPC chứa đựng các thành phần bộ phận để xác định các tham số phụ thuộc vào thao tác. Vì vậy, cấu trúc thông điệp mô tả thông điệp đầu vào ở trên trong tài liệu WSDL có thể như sau: Khi thao tác getProposal được thực thi, các tham số đầu vào đến với thông điệp yêu cầu được truyền vào phương thức điều khiển cơ bản bên trong lời gọi trả về một phương thức cơ bản getProposal* thích hợp, phụ thuộc vào các giá trị của các tham số truyền vào. Hướng tiếp cận này cho phép bạn giảm bớt số lượng thao tác trình bày bởi một dịch vụ trong khi vẫn cung cấp các tính năng được yêu cầu. Bây giờ bạn có thể thêm một phương thức mới vào lớp cơ bản (underlying layer) của dịch vụ (thông thường, tầng này được trình bày bởi một class) và tạo cho phương thức đó sẵn có cho các service requestor mà không phải chỉnh sửa tài liệu WSDL xác định giao diện dịch vụ. Bây giờ, giả định rằng bạn áp dụng hướng tiếp cận ở trên cho tất cả các dịch vụ nghiệp vụ được đề cập trước đó trong phần này, bạn có thể cắt giảm đáng kể một số lượng các thao tác được trình bày bởi các dịch vụ này, trình bày công khai chỉ các thao tác chung như hình sau đây: Như bạn thấy, mỗi dịch vụ được mô tả trong hình, ngoại trừ dịch vụ thông báo (Notification service), đều hỗ trợ nhiều hơn một thao tác. Điều này có nghĩa rằng không [...]... trình WS -BPEL từ bất kỳ một dịch vụ web nào 2.1 Tóm tắt ngắn gọn về BPEL BPEL là một ngôn ngữ chặt chẽ để mở rộng các dịch vụ web cho việc tương tác các tiến trình Tiến trình nghiệp vụ BPEL xây dựng stateful (có khả năng lưu khôi phục trạng thái), kết hợp giao tiếp từ dịch vụ web Tiến trình BPEL được mô tả bằng XML Để thiết kế một ứng dụng thành phần sử dụng WS -BPEL, bạn phải biết ngôn ngữ BPEL Bài... Một dịch vụ điều khiển xây dựng với ngôn ngữ xếp đặt WS _BPEL, giống như bất kỳ dịch vụ khác, nên có một tài liệu WSDL tương ứng mô tả dịch vụ đến khách hàng của nó Xây dựng các định nghĩa WSDL cho các dịch vụ tổng hợp là xây dựng với WS _BPEL được thảo luận trong phần “WSDL definitions for Composite Services” được mô tả sau trong chương này] Bạn có thể tạo một sự xếp đặt được dùng như một dịch vụ trong... nghiệp vụ chung Ví dụ, có thể có một choreography cho phép một sự hợp tác diễn ra giữa một sự xếp đặt, một dịch vụ điều khiển đại diện cho một tiến trình WS -BPEL, và một dịch vụ khách tương tác với dịch vụ điều khiển này Trong hình trên, tầng choreography được dùng để đặc tả các mối quan hệ ngang hàng của hai dịch vụ Cụ thể hơn, tài liệu WS-CDL choreography mô tả các thông điệp trao đổi giữa các dịch vụ. .. các dịch vụ cần thiết cho việc tự động hóa quá trình gửi các đề xuất (submitting proposals), giờ là lúc xem xét tới việc làm thế nào đưa các dịch vụ đó hoạt động Trên thực tế, có một số phương pháp điều phối các dịch vụ để chúng có thể hợp thành một giải pháp SOA Ví dụ như bạn có thể tạo ra một dịch vụ tổng hợp như một đoạn mã PHP hoạt động như một dịch vụ Web mà, đứng trên khía cạnh lập trình, dịch vụ. .. Phần tử trả về Các hoạt động dịch vụ web được định nghĩa bởi BPEL để tao ra các thành phần dịch vụ web Phần tử định nghĩa thông tin được mong đợi bởi dịch vụ tiến trình (có vai trò như một bên cung cấp dịch vụ ) chờ để nhận một yêu cầu từ tiến trình đối tác mở rộng (có vai trò như bên sử yêu cầu dịch vụ) Các thuộc tính cần có để định nghĩa một nhiệm vụ nhận về gồm: -Thuộc tính partnerLink:... này trỏ vào tiến trình đối tác (bên yêu cầu dịch vụ) -Thuộc tính portType: giá trị của thuộc tính này chứa kiểu cổng (hay giao diện) của dịch vụ tiến trình (bên cung cấp dịch vụ) Kiểu cổng này sẽ chờ để nhận yêu cầu dịch vụ từ bên yêu cầu dịch vụ -Thuộc tính opertation: giá trị của thuộc tính này chứa thao tác của dịch vụ tiến trình mà bên yêu cầu sẽ nhận về -Thuộc tính variable: giá trị của thuộc... diện container, hành vi, các các dịch vụ chung Meta container bản than nó đã là một kiến trúc hướng dịch vụ Các thành phần của JBI mô tả những đặc tả của chúng thông qua WSDL Mục tiêu chính của JBI là để cung cấp một kiến chúng và một khung có khả năng để facilitates cho các thành phần động và các ứng dụng lỏng lẻo triển khai và các thành phần tích hợp kiến trúc hướng dịch vụ Nó cho phép bất cứ ai tạo... một quy trình nghiệp vụ thực thi được sẽ được chạy bởi một máy xếp đặt Nhìn chung, một sự xếp đặt có cấu trúc như sau: Như ta thấy, hình vẽ trên thể hiện một sự kết hợp các dịch vụ được điều phối bởi hệ thống logic thể hiện trong dịch vụ điều khiển (controller service) Dịch vụ điều khiển này có thể là một quy trình nghiệp vụ WS -BPEL mà có thể hoàn thành một tác vụ trong nghiệp vụ khi được thực thi... 2.0 tiêu chuẩn 31 BPEL Engine K2 QLHTTT 3.2 Service Engines Kiến trúc JBI được trình bày ở hình 2 bao gồm một JBI meta-container, hoặc một môi trường chạy thật, mà có thể chạy các SE, bên trong chạy các Service Unit (còn được gọi là các triển khai dịch vụ) Các SE cung cấp các dịch vụ như là logic nghiệp vụ, thực thi, chuyển đổi và định tuyến các dịch vụ Ví dụ, bạn có thể sử dụng WS -BPEL Service Engine... dịch vụ sử dụng kênh phân phối để khởi tạo yêu cầu dịch vụ, như trong hình 4 34 BPEL Engine K2 QLHTTT Hình 4: External Service Consumer Initiates Service Request Nhà cung cấp dịch vụ sử dụng kênh phân phối để nhận các yêu cầu, như hình 5 Hình 5 External Service Provider Receives Request 35 BPEL Engine K2 QLHTTT Bất kỳ một thành phần JBI nào cũng hoạt động như một tiêu dung dịch vụ và nhà cung cấp dịch . ĐẠI HỌC QUỐC GIA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN o0o BÁO CÁO Môn: Kiến trúc hướng dịch vụ (SOA) Đề tài: Tìm hiểu về BPEL Enginge Giảng viên: TS. Võ Đình Hiếu Nhóm thực hiện: Nguyễn Trần. đang được thiết kế: - Dịch vụ đề xuất - Dịch vụ tác giả - Dịch vụ thanh toán hóa đơn - Dịch vụ thông báo Như bạn đã thấy, 3 dịch vụ đầu tiên trong danh sách trên là các dịch vụ trọng tâm, đại diện. dụng hướng dịch vụ, áp dụng các nguyên tắc hướng dịch vụ nêu trong phần trước. Giai đoạn phân tích hướng dịch vụ là giai đoạn đầu tiên trong tiến trình thiết kế một ứng dụng hướng dịch vụ. Bất kể