Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 9: Tích hợp các quy tắc với SOA

Bài viết này xem xét lại cách làm thế nào để tích hợp các quy tắc nghiệp vụ với Service-Oriented Architecture (SOA- Kiến trúc hướng dịch vụ) của IBM như là một kiểu thành phần nhằm mang lại các lợi thế về sự nhanh nhẹn kinh doanh và các mô hình thực thi thay thế để bổ sung các đặc tính của các kiểu thành phần khác. Bạn sẽ tìm hiểu về ba loại quy tắc chung -- các quy tắc tuần tự, các quy tắc tương quan sự kiện và các quy tắc suy diễn.

Mark Linehan, Kỹ thuật viên cao cấp, IBM

Mark Linehan là thành viên ban lãnh đạo kỹ thuật cao cấp trong ban các công nghệ mới nổi của Tập đoàn phần mềm IBM. Trong thời gian vài năm qua, ông đã nghiên cứu về công nghệ các quy tắc nghiệp vụ. Trước đó, Mark đã phát triển các giao thức truyền thông dựa trên mật mã và đã thiết kế và phát triển nhiều phần mềm truyền thông. Mark có bằng Thạc sỹ khoa học về Khoa học Máy tính của Trường Đại học Columbia và là cử nhân của trường Đại học Case Western Reserve



10 07 2009

Giới thiệu

SOA cung cấp một loạt các kiểu thực hiện thành phần, ví dụ như các đối tượng thuần Java™ (POJOs), các quá trình của Business Process Execution Language (BPEL-Ngôn ngữ thi hành quy trình nghiệp vụ), các máy trạng thái nghiệp vụ và nhiều thứ khác nữa. Phần 1 của loạt bài viết này giới thiệu các khái niệm về SOA, và Phần 6 mô tả các thành phần như là các khía cạnh then chốt của SOA.

Các nhà phát triển triển khai thực hiện các thành phần dịch vụ bằng cách sử dụng bất kỳ một trong số các công nghệ phần mềm hoặc các kiểu thành phần khác nhau. Một số dịch vụ được lợi trong việc triển khai thực hiện bằng cách sử dụng kiểu thành phần các quy tắc nghiệp vụ, vì các quy tắc mang lại những đặc trưng giải pháp hữu ích. Một mục đích của bài viết này là tóm tắt các thể loại quy tắc nghiệp vụ khác nhau và cho thấy một cách tiếp cận duy nhất để tích hợp với SOA của IBM sao cho phù hợp với các loại quy tắc khác nhau như thế nào.

Tất cả các kiểu thành phần, bao gồm các quy tắc, phù hợp với một mô hình cấu thành giải pháp, đó là SOA. Một lợi ích quan trọng của SOA chính là khả năng dành cho các nhà tích hợp (integrators) nghiệp vụ có thể thay thế một triển khai thực hiện thành phần bằng một triển khai thực hiện thành phần khác mà không ảnh hưởng tới phần còn lại của giải pháp nghiệp vụ. Mục tiêu thứ hai của bài viết này là xem xét lại cách các quy tắc nghiệp vụ, khi được triển khai thực hiện theo SOA, đạt được lợi ích này như thế nào.

Trong SOA, các dịch vụ có thể tương tác với nhau một cách đồng bộ hoặc không đồng bộ với chỉ các thông báo yêu cầu hoặc cả các thông báo yêu cầu lẫn các thông báo đáp ứng. Bài viết này cũng nhằm mô tả các cách mà các thể loại quy tắc khác nhau tương tác với các phong cách tương tác dịch vụ khác nhau.

Các quy tắc nghiệp vụ

Các quy tắc nghiệp vụ được chia thành ba loại chung:

  1. Các quy tắc tuần tự (Sequential rules) cung cấp các quy tắc khai báo được thi hành tuần tự. Thể loại quy tắc này hỗ trợ tính nhanh nhẹn kinh doanh bằng cách cho phép các lập trình viên không chuyên duy trì các quy tắc.

    Thể loại này bao gồm các câu lệnh nếu-thì (if-then) và các bảng quyết định.

    Hình 1. Quy tắc If-then
    Quy tắc If-then

    Như tên đã gợi ý, mỗi quy tắc if-then (nếu-thì) bao gồm một biểu thức Boolean, xác định có hay không thi hành một hoặc nhiều hành động đã chỉ rõ trong mệnh đề then. Các hành động này có thể tính toán các kết quả của quy tắc, gán các giá trị hoặc gọi các dịch vụ khác. Trong Hình 1, một quy tắc if-then gán một chi phí vận chuyển và xử lý là $5 đối với gói hàng có trọng lượng từ một đến 5 pao (pound) và có thể tích nhỏ hơn chín phít khối (cubic feet).

    Hình 2. Bảng quyết định
    Bảng quyết định

    Các bảng quyết định cung cấp một biểu diễn trực quan cô đọng về các điều kiện trực giao (orthogonal conditions). Chúng tương đương với nhiều quy tắc if-then, kiểm tra các điều khoản của cùng một điều kiện với các giá trị khác nhau. Hình 2 cho thấy một bảng quyết định gán các mức chi phí vận chuyển và xử lý theo nhiều cách kết hợp trọng lượng và thể tích của các gói hàng. Chi phí vận chuyển và xử lý là $7 cho tất cả các gói hàng có thể tích lớn hơn 9 và cho các gói có trọng lượng lớn hơn 5. Đối với các gói có thể tích nhỏ hơn 9, chi phí là $2 khi trọng lượng thấp hơn 1 và $5 khi trọng lượng thấp hơn 5.

    Lợi ích chính của các quy tắc tuần tự là tiềm năng cho phép các nhà phân tích nghiệp vụ hoặc các lập trình viên không chuyên khác quản trị các quy tắc ấy. Điều này là do các khuôn dạng rất dễ hiểu của các quy tắc tuần tự, lại được bổ sung bằng các công cụ làm đơn giản hóa việc duy trì các quy tắc.

    Một lợi ích thứ hai đến từ việc triển khai thực hiện các quy tắc như là các thành phần dịch vụ riêng biệt trong SOA. Sự tách biệt các quy tắc khỏi các dịch vụ khác cho phép các quy tắc được cập nhật mà không ảnh hưởng đến các dịch vụ khác. Hầu hết các triển khai quy tắc cho phép cập nhật động các quy tắc, cho phép thay đổi mà không cần một chu kỳ phát triển và triển khai thông thường đòi hỏi phải có cho các kiểu thành phần khác. Sự kết hợp của các lợi ích này mang lại sự nhanh nhẹn đáng kể cho các việc triển khai thực hiện các quy tắc nghiệp vụ, cho phép các quy tắc tiến triển mà ít bị ràng buộc vào CNTT.

    IBM WebSphere® Process Server (Máy chủ quá trình WebSphere của IBM) và IBM WebSphere Integration Developer (Nhà phát triển tích hợp WebSphere của IBM) hỗ trợ các quy tắc if-then và các bảng quyết định, vì vậy mang lại các lợi ích này cho các khách hàng của họ trong bối cảnh của SOA.

  2. Các quy tắc tương quan sự kiện (Event correlation rules) nhận biết các mối quan hệ xuyên qua nhiều sự kiện xảy ra theo thời gian. Các quy tắc này thông thường lọc các thông báo tùy theo kiểu và điều kiện trong một số cửa sổ thời gian và sau đó dò tìm ra các tình huống theo các mẫu đã định trước. Các quy tắc tương quan sự kiện được sử dụng để nhận biết các tình huống sự kiện nghiệp vụ hay công nghệ thông tin trong các chuỗi thông báo hoặc chuỗi sự kiện. Ví dụ, sinh ra một cảnh báo nếu dịch vụ "kiểm tra mức xếp hạng khách hàng" tạo ra nhiều hơn 10 lỗi SOAP trong vòng 1 phút.

    IBM Tivoli® Enterprise Console (Bàn điều khiển của Doanh nghiệp Tivoli của IBM) sử dụng các quy tắc tương quan sự kiện để nhận biết các mẫu trong các sự kiện được tạo ra từ nhiều nguồn trong một khoảng thời gian đã định trước. Các quy tắc này giúp bạn dễ dàng nhận dạng các tình huống có tầm quan trọng trong việc giám sát nghiệp vụ và CNTT, mà nếu khác đi sẽ đòi hỏi nhiều nỗ lực thủ công hoặc lập trình để tạo ra các câu lệnh quy tắc khá đơn giản.

  3. Các quy tắc suy diễn (Inference rules) triển khai thực hiện suy diễn tiến, suy diễn lùi, phép hợp nhất theo phong cách Prolog hay các quy tắc theo phong cách trí tuệ nhân tạo (AI) khác. Các ca sử dụng được hưởng lợi từ việc suy diễn là những ca sử dụng liên kết nhiều quy tắc phụ thuộc lẫn nhau, trong đó thứ tự thực hiện các quy tắc phải tùy thuộc vào dữ liệu chứ không phải đã được định trước. Các bài toán lựa chọn tài nguyên, tối ưu hóa, dự đoán vấn đề và lập kế hoạch thường cần một số dạng suy diễn. Các bài toán này liên quan tới việc tìm kiếm trong số rất nhiều giải pháp tiềm năng để tìm ra những giải pháp thỏa mãn các quy tắc.

Các bộ quy tắc

Hầu hết các hệ thống quy tắc nhóm các quy tắc thành các bộ quy tắc được định nghĩa trước trong các công cụ hoặc được kết hợp động ở thời gian chạy. Các bộ quy tắc có chứa các danh sách các quy tắc kết hợp cùng với nhau để đánh giá một tập hợp đầu vào nào đó và đưa ra một hoặc nhiều kết quả. Các cây quyết định cung cấp một cách biểu diễn khác của các bộ quy tắc if-then tuần tự.

Hình 3. Bộ quy tắc
Bộ quy tắc

Hình 3 cho thấy một bộ quy tắc với hai quy tắc if-then. Phần giao diện chú thích các đầu vào và đầu ra của bộ quy tắc. Quy tắc đầu tiên tính phí $2 cho các gói hàng có trọng lượng thấp hơn 1 pao và nhỏ hơn 9 phít khối. Quy tắc thứ hai, tính phí $5 cho các gói hàng từ 1 đến 5 pao có thể tích nhỏ hơn 9 phít khối.

Mỗi bộ quy tắc triển khai chỉ một hoạt động của một giao diện, thực hiện mục tiêu của hoạt động (ứng với mỗi tên phương thức hoặc tên hoạt động) và chữ ký (các tham số và kết quả) của hoạt động. Vì vậy, mỗi bộ quy tắc thực hiện vai trò của một hoạt động đơn lẻ trong SOA.

Có rất nhiều ưu điểm trong cách tiếp cận này:

  • Các dịch vụ khách không biết được cách dịch vụ được triển khai thực hiện như thế nào -- dùng các quy tắc hay là một công nghệ triển khai thực hiện khác nào đó -- và không biết thể loại quy tắc nào được sử dụng, khi có nhiều lựa chọn. Điều này có nghĩa là dịch vụ khách có thể được nối với các thành phần dịch vụ thay thế khác trong các bản cài đặt khác nhau hoặc ở thời gian khác nhau, như vậy cung cấp cho bạn một mức linh hoạt trong cấu hình.
  • Các lợi ích thông thường về an toàn kiểu như các hợp đồng dịch vụ cho phép.
  • Tính đơn giản của mô hình lập trình -- không có API đặc biệt nào chỉ để gọi các quy tắc.
  • Các máy dàn dựng quá trình có thể gọi các quy tắc giống như các dịch vụ khác. Một máy không cần biết rằng các hoạt động cụ thể được triển khai thực hiện bằng cách sử dụng các quy tắc.
  • Tái sử dụng các đặc tính thùng chứa (container) hiện có, ví dụ như kiểm soát truy cập và quản lý giao dịch. Ví dụ, trong việc thiết kế giải pháp, điều quan trọng là ở chỗ một phép tính getDiscount tham gia vào một giao dịch cơ sở dữ liệu như phần còn lại của ứng dụng khách. Việc gọi các quy tắc giống như bất kỳ kiểu dịch vụ khác nào làm cho các đặc tính thùng chứa có thể áp dụng được với các quy tắc.

Các nhóm quy tắc nghiệp vụ

Hình 4. Nhóm quy tắc nghiệp vụ gồm (các) bộ quy tắc và các quy tắc
Nhóm quy tắc nghiệp vụ

Như đã mô tả trong Hình 4, các dịch vụ có thể cung cấp nhiều hoạt động, trong khi một bộ quy tắc thực hiện chỉ một hoạt động đơn lẻ. Các nhóm quy tắc nghiệp vụ đóng gói lại nhiều bộ quy tắc, cùng với nhau triển khai thực hiện tất cả các hoạt động của một dịch vụ. Từ quan điểm buộc nối dịch vụ, nhóm quy tắc nghiệp vụ là thành phần "được nối" vào một ứng dụng. Vì vậy, một nhóm quy tắc nghiệp vụ đóng gói lại nhiều bộ quy tắc thành một dịch vụ để xuất khẩu một giao diện được đưa ra để các dịch vụ khác có thể tham chiếu.

Ví dụ, một nhóm quy tắc nghiệp vụ có thể thực hiện một giao diện Quản lý quan hệ khách hàng (Customer Relationship Management - CRM) bao gồm các hoạt động tính toán giảm giá (calculate discount) và tính toán chi phí vận chuyển (calculate shipping) bằng cách đưa vào một bộ quy tắc cho mỗi hoạt động. Nếu một trình khách dịch vụ được buộc nối đến một nhóm quy tắc nghiệp vụ sử dụng bộ quy tắc trong Hình 5, thì các quy tắc sẽ thi hành khi trình khách gọi hoạt động calculate shipping.

Hình 5. Trình shell của nhóm quy tắc nghiệp vụ nối dịch vụ SOA tới máy các quy tắc
Trình shell của nhóm quy tắc nghiệp vụ

Mỗi nhóm quy tắc nghiệp vụ hỗ trợ các chữ ký (signatures) của hoạt động được định nghĩa trong một giao diện đã đưa ra, do đó cho phép đảm bảo an toàn kiểu. Thông thường, các công cụ tạo ra một nhóm các quy tắc nghiệp vụ dưới dạng mã shell; mã này triển khai thực hiện các chữ ký của hoạt động, bắt giữ các tham số vào và chuyển chúng đến một máy quy tắc theo cách thức đặc thù cho mỗi máy. Mã shell giải quyết sự không khớp giữa các chữ ký của hoạt động đặc thù theo ứng dụng và các giao diện độc lập với ứng dụng của nhiều máy quy tắc. Hình 5 minh họa rằng mã shell cung cấp một cầu nối giữa trình khách và máy quy tắc, cho phép trình khách gọi các quy tắc như là một dịch vụ và tạo điều kiện cho máy quy tắc tham gia vào SOA.

Gọi các dịch vụ khác từ các quy tắc

Các quy tắc nghiệp vụ thường cần gọi các dịch vụ khác, hoặc như là một phần của các điều kiện kiểm tra (ví dụ như "'if moon.getStatus() == "Full" …') hoặc để gọi các hành động, ví dụ như gửi e-mail. Chúng ta mô hình hóa điều này thành hai phần:

  1. Mỗi nhóm quy tắc nghiệp vụ định nghĩa không hoặc nhiều tham chiếu dịch vụ, tùy theo SOA. Các tham chiếu dịch vụ chỉ rõ các đặc tả kỹ thuật của dịch vụ cần thiết.
  2. Trong Hình 4, các quy tắc thuộc về các bộ quy tắc nằm trong các nhóm quy tắc. Các quy tắc có thể gọi bất kỳ các dịch vụ nào được tham chiếu từ nhóm quy tắc nghiệp vụ mà "sở hữu" gián tiếp các quy tắc này.

Cách tiếp cận này cho phép một vòng đời phát triển ở đó mối quan hệ giữa các nhóm quy tắc và các dịch vụ khác được định nghĩa sớm hơn các bộ quy tắc và các quy tắc mà thực tế các dịch vụ đó sẽ sử dụng. Một ứng dụng có thể được định nghĩa và được buộc nối khi thực hiện hoặc triển khai, trong khi các quy tắc có thể được quản lý trong các hệ thống đang chạy thực.

Ví dụ, một nhóm quy tắc nghiệp vụ nào đó có thể tham chiếu đến các dịch vụ A, B và C. Tại một số thời điểm, các quy tắc trong nhóm quy tắc này có thể thực sự gọi một dịch vụ A, trong khi tại một thời điểm khác, các quy tắc cũng có thể gọi dịch vụ B. Các quy tắc không thể gọi dịch vụ Z do dịch vụ đó không được nhóm quy tắc nghiệp vụ tham chiếu.

Các phong cách gọi

Các dịch vụ tương tác theo hai cách chính; cả hai cách này cũng áp dụng cho các quy tắc:

  1. Phong cách yêu cầu-đáp ứng -- gọi đồng bộ bởi các dịch vụ khách. Một trình khách gọi một dịch vụ, dịch vụ này có thể sinh ra một kết quả đồng bộ.
  2. Phong cách sự kiện-xử lý -- xử lý thông báo không đồng bộ, như thấy trong Kênh dịch vụ doanh nghiệp WebSphere của IBM (IBM WebSphere Enterprise Service Bus). Một trình khách gửi một thông báo đến một dịch vụ theo phong cách kích hoạt-và-quên (fire-and-forget). Dịch vụ sẽ chuyển một đáp ứng -- nếu có -- quay trở lại tới trình khách qua một thông báo không đồng bộ khác.

Phong cách yêu cầu-đáp ứng được trình bày trước tiên, bởi vì phong cách sự kiện-xử lý được xây dựng trên cơ sở phong cách yêu cầu-đáp ứng.

Phong cách yêu cầu-đáp ứng

Theo phong cách gọi yêu cầu-đáp ứng, một dịch vụ khách gọi một hoạt động đã được triển khai thực hiện qua các quy tắc. Bối cảnh cho các quy tắc là các đối số mà dịch vụ khách chuyển đến, cộng thêm bất kỳ dữ liệu tĩnh hoặc dịch vụ khác mà các quy tắc có thể truy cập, cộng với bất kỳ trạng thái nào đó được duy trì trong các quy tắc. Như với bất kỳ hoạt động nào, các quy tắc thực hiện một số tính toán và có thể trả về một kết quả cho phía khách. Các quy tắc cũng có thể gây ra một số hành động hay các hậu quả phụ khác bằng cách gọi các dịch vụ khác.

Với SOA, tất cả các chữ ký của hoạt động là đặc thù tùy theo cách sử dụng. Do đó, các đầu vào, kết quả và tên của một hoạt động tính toán giảm giá sẽ là hoàn toàn khác với một hoạt động xác nhận hiệu lực hợp đồng bảo hiểm của một người lái xe. Nhà thiết kế của mỗi ứng dụng chỉ rõ các đầu vào được chuyển tới các quy tắc và mọi kết quả đầu ra mong đợi từ các quy tắc; không có API đặc biệt nào được sử dụng để gọi các quy tắc.

Phong cách sự kiện-xử lý

Theo phong cách sự kiện-xử lý, một bộ quy tắc sẽ xử lý không đồng bộ một luồng các thông điệp, như được hiển thị trong Hình 6. Bộ quy tắc kiểm tra lần lượt từng thông điệp một và có thể tiến hành một hành động nào đó (bằng cách gọi dịch vụ khác) hoặc có thể tạo ra một thông điệp gửi đi. Các ứng dụng tiêu biểu gồm: đáp ứng các tình huống nghiệp vụ, kiểm định các sự kiện nghiệp vụ đối với các điều kiện bất thường và theo dõi các sự kiện CNTT để phát hiện các vấn đề. Công nghệ các quy tắc làm đơn giản hoá các ứng dụng như vậy bằng cách làm cho người dùng dễ dàng hơn khi định nghĩa xử lý thông điệp mà không đòi hỏi phải thành thạo lập trình.

Hình 6. Các quy tắc nghiệp vụ và phong cách sự kiện-xử lý
phong cách sự kiện-xử lý

Phong cách sự kiện-xử lý được xây dựng dựa trên phong cách yêu cầu-đáp ứng đã mô tả ở trên. Nhóm quy tắc nghiệp vụ nhận được từng thông báo đến và gọi một bộ quy tắc. Thông thường, bộ quy tắc nhận thông báo đến như là một đối số và không trả về bất kỳ kết quả nào (do môi trường xử lý không đồng bộ). Bộ quy tắc sinh ra kết quả đầu ra -- nếu có -- bằng cách gọi dịch vụ khác, mà chúng có thể được kết hợp với hoặc không kết hợp với bất kỳ nguồn thông điệp nào. Như vậy, từ quan điểm của công nghệ các quy tắc, các sự khác biệt giữa phong cách sự kiện-xử lý và yêu cầu-đáp ứng là ở môi trường chứ không phải ở bản chất. Mô hình thi hành các quy tắc không thay đổi đối với cả hai phong cách; sự phân biệt chỉ xuất hiện trong chữ ký của giao diện được sử dụng để gọi bộ quy tắc và các tương tác giữa bộ quy tắc và các ứng dụng khách.

Các quy tắc có trạng thái so với các quy tắc không trạng thái

Giống như với các kiểu triển khai thực hiện dịch vụ khác, các quy tắc nghiệp vụ có thể hoặc không trạng thái hoặc có trạng thái, có nghĩa là chúng có thể lựa chọn để duy trì các bản ghi dữ liệu nội tại xuyên qua nhiều lần gọi. Các quy tắc duy trì trạng thái để mở rộng bối cảnh của chúng xuyên qua lược sử các lần được gọi, cho phép có các quyết định hoặc các tính toán mà cần xem xét nhiều hơn, không chỉ có đối số được chuyển đến trong lần gọi hiện tại. Các ví dụ về các quy tắc có trạng thái bao gồm hầu hết các quy tắc tương quan sự kiện và một số quy tắc sử dụng các luật suy diễn.

Mối quan hệ giữa dữ liệu trạng thái được duy trì trong các quy tắc nghiệp vụ và dịch vụ khách là đặc thù theo ứng dụng và không được đề cập đến trong kiến trúc. Thông thường, các quy tắc sử dụng một hoặc nhiều đối số gọi để đề cập đến trạng thái bên trong thích hợp.

Bất kỳ trạng thái nào được duy trì trong các quy tắc phải tiếp tục tồn tại để hỗ trợ các cấu hình bó cụm (clustered) và hỗ trợ các yêu cầu tính sẵn sàng cao tiêu biểu cho hầu hết các cấu hình nghiệp vụ kinh doanh. Việc cho phép tính linh hoạt do các quy tắc mang lại cùng với khả năng co giãn và khả năng khôi phục lại được có thể là một thách thức quan trọng đối với nhiều hệ thống các quy tắc.

Các mẫu sử dụng tiêu biểu

Các thảo luận ở trên phác thảo hai phong cách gọi quy tắc cơ bản (phong cách yêu cầu-đáp ứng đồng bộ và phong cách sự kiện-xử lý không đồng bộ) và phân biệt việc xử lý có trạng thái so với không trạng thái. Bất kỳ kiểu quy tắc nào (như đã thảo luận ở trên) có thể được sử dụng với bất kỳ một trong bốn cách tổ hợp khác nhau của phong cách gọi với việc thi hành có trạng thái hay không trạng thái. Bảng sau đây nhận biết các mẫu sử dụng tiêu biểu nhất:

Bảng 1: Các mẫu sử dụng tiêu biển dành cho các quy tắc nghiệp vụ
Phong cách yêu cầu-đáp ứngPhong cách sự kiện-xử lý
StatelessCác quy tắc tuần tự hay các quy tắc suy diễnCác quy tắc tương quan sự kiện (các mẫu đơn giản)
StatefulCác quy tắc suy diễnCác quy tắc tương quan sự kiện (các mẫu phức tạp)

Bảng này nhận biết các tổ hợp có ý nghĩa quan trọng nhất theo các đặc tính của mỗi kiểu quy tắc. Tất nhiên cũng có thể có những cách dùng khác. Ví dụ, việc dùng các quy tắc tuần tự hoặc các quy tắc suy diễn thay thế cho việc xử lý sự kiện không trạng thái sẽ cung cấp chức năng tương đương với kiểu đơn giản nhất của các quy tắc tương quan sự kiện nhưng bị mất khả năng mở rộng các quy tắc một cách trôi chảy khi thiết lập tương quan nhiều sự kiện đích thực. Một ví dụ khác, bạn có thể áp dụng các quy tắc suy diễn cho việc xử lý sự kiện có trạng thái để thực hiện các suy diễn về các chuỗi thông báo. Các yêu cầu của ứng dụng và khả năng của các công cụ xác định cách lựa chọn tốt nhất trong mỗi tình huống.

Tóm tắt

Bài viết này tóm tắt ba thể loại quy tắc chung và mô tả cách chúng tích hợp với SOA như thế nào -- bất kể:

  • Các quy tắc là không trạng thái hay có trạng thái.
  • Phong cách gọi là yêu cầu-đáp ứng đồng bộ hay dựa trên thông báo không đồng bộ.

Cách tiếp cận tích hợp được mô tả ở đây xử lý các quy tắc như là một kiểu thành phần dịch vụ hạng nhất, kết hợp các lựa chọn công nghệ cùng với các lựa chọn khác, ví dụ như mã thuần Java, các qui trình nghiệp vụ và các máy trạng thái. Với các nhà phát triển của các trình khách dịch vụ, điều này có nghĩa là các quy tắc được gọi giống như các dịch vụ khác, mà không quan tâm đến API đặc biệt. Với các nhà phát triển giải pháp tổng thể, điều này tạo ra khả năng trộn lẫn và phối hợp các quy tắc với các kiểu triển khai thực hiện khác, áp dụng các công nghệ thích hợp nhất cho mỗi thành phần trong một giải pháp tổng thể.

Tài nguyên

Học tập

Thảo luận

  • • Hãy dành tâm trí cho cộng đồng developerWorks bằng cách tham gia vào developerWorks blogs.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=SOA và dịch vụ Web
ArticleID=407174
ArticleTitle=Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 9: Tích hợp các quy tắc với SOA
publish-date=07102009