Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 4: Giới thiệu về Kênh Dịch vụ Doanh nghiệp của IBM

Mẫu kiến trúc của Kênh Dịch vụ Doanh nghiệp (ESB) hỗ trợ công nghệ ảo hóa và quản lý các tương tác dịch vụ trong một kiến trúc hướng dịch vụ (SOA). Nó cho phép các tương tác giữa các bên cung cấp dịch vụ và bên yêu cầu dịch vụ và có thể được triển khai thực hiện bằng cách sử dụng nhiều loại công nghệ phần mềm trung gian và các mô hình lập trình. Nó mở rộng các khái niệm mô hình lập trình SOA đã được giới thiệu trong các bài viết trước của loạt bài này.

Dr. Beth Hutchison, Kỹ thuật viên cao cấp, IBM

Tiến sĩ Beth Hutchison là một thành viên của ban lãnh đạo kỹ thuật cao cấp và Kiến trúc sư Dịch vụ Web đang làm việc về các công nghệ Kênh Dịch vụ Doanh nghiệp của IBM (Enterprise Service Bus). Bà vẫn luôn luôn làm việc về các công nghệ hàng đầu, khởi đầu là nhà phát triển hàng đầu của bản phát hành đầu tiên của WebSphere MQ trên nền tảng phân tán. Sau đó, bà đã đảm nhận vai trò của kiến trúc sư hiệu năng cho các máy ảo Java của IBM. Bây giờ bà đã quay lại gia đình MQ và đang làm việc về quản lý hệ thống trên ESB



Marc-Thomas Schmidt, Kỹ sư cao cấp, Kiến trúc sư trưởng, IBM

Marc-Thomas Schmidt là một kỹ sư xuất sắc và đang tiếp tục công việc về các công nghệ Tích hợp Nghiệp vụ IBM suốt hơn một thập kỉ qua, từ các hệ thống quản lý luồng công việc đến phần mềm trung gian hướng-thông báo cao cấp theo công nghệ quản lý qui trình nghiệp vụ. Trong vai trò hiện tại của mình, ông đã lãnh đạo công việc kiến trúc kĩ thuật của các công nghệ ESB của IBM



Dan Wolfson, Kiến trúc sư trưởng, Database Technology Institute for e-Business

Dan Wolfson, kỹ sư xuất sắc của IBM, là Giám đốc Kỹ thuật của Phần mềm Tích hợp Nghiệp vụ tại Tập đoàn phần mềm IBM. Ông chịu trách nhiệm về vai trò lãnh đạo của chiến lược kiến trúc và kỹ thuật dành cho phần mềm tích hợp của IBM (môi trường chạy và công cụ), làm việc với đội kiến trúc và phát triển SWG -- các sản phẩm tích hợp nghiệp vụ và tích hợp thông tin WebSphere IBM nói riêng. Dan đã có trên 20 năm kinh nghiệm trong lĩnh vực tính toán phân tán cả về nghiên cứu lẫn thương mại, bao gồm các hệ thống giao dịch và hướng-đối tượng, các ngôn ngữ lập trình, truyền thông báo và các hệ thống cơ sở dữ liệu



Marcia Stockton, Kỹ thuật viên cao cấp, IBM

Marcia L. Stockton là thành viên của ban lãnh đạo kỹ thuật cao cấp và là một nhà phát minh chính của Tổ hợp phần mềm IBM tại Công viên tam giác nghiên cứu (Research Triangle Park), Bắc Carolina (cư trú tại California). Bà cũng là một thành viên IEEE cấp cao. Marcia lãnh đạo Nhóm công tác về mô hình lập trình của Hội đồng Kiến trúc của Tổ hợp phần mềm, ở đây bà lãnh đạo thực hiện các sáng kiến tích hợp ngang hàng và khuyến khích làm đơn giản hóa mô hình lập trình trên các sản phẩm của Lotus, Rational, WebSphere, DB2 và Tivoli. 73 bằng sáng chế Hoa Kỳ của bà bao trùm các lĩnh vực từ mạng, Web, an ninh, bảo mật, đa phương tiện, không dây, các thiết bị lan tỏa (pervasive) cho tới mã nhận dạng tần số vô tuyến. Mới đây bà lãnh đạo việc định nghĩa kiến trúc quản lý nhân dạng (identity) và về việc lập trình phân tán phía máy chủ. Bà đến với IBM vào năm 1988 sau năm năm phát triển phần mềm mạng. Bà đã có bằng cử nhân văn chương (B.A.) của trường Cao đẳng Swarthmore vào năm 1975



10 07 2009

Giới thiệu

Các SOA cung cấp một cách tiếp cận linh hoạt, mở rộng được và cấu tạo lại được để sử dụng lại và mở rộng các ứng dụng hiện có đồng thời xây dựng các ứng dụng mới. Các dịch vụ thông báo công khai các khả năng, cả khả năng cung cấp lẫn khả năng tiêu thụ, bằng cách khai báo các giao diện mà chúng triển khai thực hiện hoặc mong chờ các dịch vụ khác sẽ triển khai thực hiện và bằng cách khai báo các chính sách đang chi phối các tương tác của đối tác có tiềm năng. Ngôn ngữ Mô tả Dịch vụ Web (WSDL) và các tiêu chuẩn dịch vụ web khác, ví dụ như Chính sách dịch vụ Web (WS – Policy), cung cấp vốn từ vựng cho các khai báo này. (Xem Tài nguyên để có một liên kết đến WSDL, Phiên bản 2.0 Phần 0: Primer).

Việc ảo hóa của các chức năng nghiệp vụ, một mục tiêu then chốt của một SOA, thực hiện được thông qua tách biệt định nghĩa dịch vụ và cách sử dụng dịch vụ khỏi việc triển khai thực hiện dịch vụ. Các dịch vụ có thể được triển khai thực hiện bằng cách sử dụng một loạt các công nghệ, bao gồm cả IBM WebSphere® MQ, IBM CICS® hoặc IBM IMS™, Java™ 2 Platform, Enterprise Edition (J2EE) Enterprise JavaBeans (EJB), các lớp Java, IBM DB2® Queries, Java Message Services (JMS) hoặc Microsoft® .NET. Bên yêu cầu dịch vụ gửi đi các yêu cầu tới bên cung cấp dịch vụ có cung cấp các khả năng mà mình mong muốn, không cần biết về việc triển khai thực hiện dịch vụ.

Một ESB là một mẫu kiến trúc để hỗ trợ công nghệ ảo hóa và quản lý các tương tác dịch vụ giữa các bên tham gia giao tiếp. Nó cung cấp kết nối giữa các bên cung cấp dịch vụ và bên yêu cầu dịch vụ, tạo điều kiện thuận lợi cho sự tương tác của chúng ngay cả khi chúng không ăn khớp chính xác. Mẫu này có thể được triển khai thực hiện bằng cách sử dụng nhiều loại công nghệ phần mềm trung gian và các mô hình lập trình.

Bài viết này định nghĩa mẫu ESB và vai trò của nó trong SOA. Các bài viết tiếp sau sẽ trình bày chi tiết các kịch bản sử dụng, triển khai thực hiện mẫu ESB với các công nghệ hiện nay và các định hướng tương lai cho các công nghệ ESB.


ESB là gì?

Trong mẫu ESB, thay vì tương tác trực tiếp, các bên tham gia vào một tương tác dịch vụ sẽ giao tiếp thông qua một kênh (bus); kênh này cung cấp các đặc tính công nghệ ảo hóa và quản lí để triển khai thực hiện và mở rộng định nghĩa cốt lõi của SOA. Mẫu ESB của IBM cung cấp công nghệ ảo hóa về:

  • Địa điểm và nhân dạng: Bên tham gia không cần biết địa điểm hoặc nhân dạng của các bên tham gia khác. Ví dụ, bên yêu cầu không cần phải biết rằng một yêu cầu có thể được phục vụ bởi bất kỳ một bên cung cấp dịch vụ nào. Bên cung cấp dịch vụ có thể được thêm vào hoặc gỡ bỏ mà không làm đổ vỡ hệ thống.
  • Giao thức tương tác: Những bên tham gia không cần phải chia sẻ cùng một giao thức giao tiếp hay dạng tương tác. Một yêu cầu được biểu diễn dưới dạng SOAP/HTTP có thể được phục vụ bởi một bên cung cấp chỉ hiểu được Java Remote Method Invocation (RMI-Cách gọi phương thức từ xa của Java).
  • Giao diện: Các bên yêu cầu và bên cung cấp dịch vụ không cần phải đồng ý về một giao diện chung. ESB hóa giải các sự khác nhau bằng cách chuyển đổi các thông báo yêu cầu thành một khuôn dạng mà nhà cung cấp trông đợi.
  • Chất lượng (Tương tác) Dịch vụ (QoS): Các bên tham gia khai báo các yêu cầu QoS của mình, bao gồm cả hiệu năng và độ tin cậy, quyền hạn của các yêu cầu, mã hóa/giải mã các nội dung thông báo, kiểm tra tự động các tương tác dịch vụ và việc định tuyến các yêu cầu ấy như thế nào (ví dụ như đi đến bản triển khai thực hiện đang sẵn sàng, dựa trên tiêu chí về phân tải công việc). Các chính sách mô tả các yêu cầu và khả năng QoS của những bên yêu cầu và bên cung cấp dịch vụ có thể được chính các dịch vụ thỏa mãn hoặc được thỏa mãn bởi ESB qua việc bù trừ các chỗ không ăn khớp.

Như vậy, mẫu ESB tránh cho bên yêu cầu không cần phải biết rõ việc thực hiện thực tế của bên cung cấp dịch vụ -- từ quan điểm của cả nhà phát triển lẫn nhà triển khai ứng dụng. ESB sẽ chịu trách nhiệm về việc phân phối các yêu cầu tới bên cung cấp dịch vụ có đưa ra các chức năng và QoS cần thiết. Các bên cung cấp dịch vụ nhận được các yêu cầu và chúng sẽ đáp ứng yêu cầu đó mà không biết nguồn gốc của thông báo. Chính ESB cũng là trong suốt đối với các bên yêu cầu và cung cấp dịch vụ đang sử dụng nó. Logic ứng dụng có thể gọi hoặc phân phối dịch vụ bằng cách sử dụng một loạt các mô hình và các kỹ thuật lập trình mà không cần phải xem xét có kết nối trực tiếp không hoặc có đi xuyên qua một ESB không. Kết nối đến một ESB là một quyết định triển khai; mã nguồn ứng dụng không thay đổi.

Một ESB hỗ trợ nhiều loại hình tương tác, bao gồm một-chiều, yêu cầu/đáp ứng, không đồng bộ, đồng bộ và công bố/đăng ký. Nó cũng hỗ trợ quá trình xử lý sự kiện phức tạp trong đó một loạt các sự kiện có thể được quan sát để sinh ra một sự kiện như là một hệ quả của các mối quan hệ trong loạt sự kiện.

Hình 1 mô tả mẫu ESB cơ bản. Các thông báo chảy qua một kênh liên kết nhiều bên tham gia giao tiếp. Một số bên tham gia gọi các dịch vụ được cung cấp bởi những bên khác; những bên tham gia khác công bố thông tin cho những bên tiêu thụ quan tâm. Nơi mà ở đó một điểm đầu cuối tương tác với ESB được gọi là một Điểm Tương tác Dịch vụ (Service Interaction Point - SIP). Một SIP có thể, ví dụ, là một điểm đầu cuối dịch vụ web, một hàng đợi MQ WebSphere hoặc một trình ủy quyền (proxy) của một đối tượng đầu xa RMI. Một sổ đăng ký dịch vụ nắm giữ siêu dữ liệu mô tả các yêu cầu và các khả năng của các SIP (ví dụ, các giao diện mà chúng cung cấp hoặc chúng yêu cầu), chúng muốn tương tác với các SIP khác như thế nào (ví dụ như, đồng bộ hoặc không đồng bộ, thông qua HTTP hoặc JMS), các yêu cầu QoS của chúng (ví dụ, các tương tác an toàn, độ tin cậy được ưu tiên) và các thông tin khác để có thể tương tác với các SIP khác (chẳng hạn như các chú thích về ngữ nghĩa).

Hình 1. Mẫu ESB cơ bản
Mẫu ESB cơ bản

Việc chèn ESB vào giữa các bên tham gia mang lại cơ hội để điều biến sự tương tác của chúng thông qua một cấu kiện logic được gọi là một thành phần hòa giải (mediation). Các thành phần hòa giải hoạt động với các thông báo đang trên đường truyền dẫn giữa những bên yêu cầu và cung cấp dịch vụ. Đối với các tương tác phức tạp, các thành phần hòa giải có thể móc nối theo tuần tự. Mục Các mẫu hòa giải (Mediation patterns) sẽ trình bày các mẫu hòa giải chung triển khai thực hiện công nghệ ảo hóa, QoS và các khái niệm quản lý này.

Mẫu ESB cung cấp một cách tiếp cận linh hoạt và dễ quản lý để triển khai thực hiện SOA. Được chèn trong suốt giữa các điểm đầu cuối, kênh này nâng cao chất lượng dịch vụ; tạo điều kiện thuận lợi cho các tương tác giữa bên yêu cầu - bên cung cấp mặc dù các giao thức, các mẫu tương tác hay các khả năng dịch vụ không hoàn toàn ăn khớp và cho phép giám sát và quản lý.


Các vai trò của người sử dụng SOA và các nhiệm vụ của chúng

Việc xem xét các vai trò và các nhiệm vụ của những người sử dụng, những người tạo ra và quản lý các giải pháp SOA làm sáng tỏ hơn nữa về mẫu ESB. Các công cụ ESB và môi trường chạy phân chia vòng đời giải pháp SOA thành bốn giai đoạn:

  • Khám phá và mô tả: Nhận biết và mô tả các SIP để có thể kết nối chúng trên ESB. Điều này bao gồm việc tạo ra dịch vụ mới, khám phá dịch vụ hiện có và mô tả về các giao diện, các yêu cầu và các khả năng của chúng.
  • Mô hình và xây dựng: kết nối giữa các SIP qua các thành phần hòa giải mới hoặc hiện có để mô tả các tương tác đầu cuối đến đầu cuối của một giải pháp.
  • Cấu hình và triển khai: Định cấu hình cho một khai báo trừu tượng của một giải pháp dành cho một hình thái (topology) môi trường chạy thực và triển khai nó, tạo ra những tạo phẩm chạy thực cần thiết.
  • Theo dõi và quản lý: Theo dõi và quản lý giải pháp thông qua các hành vi của các SIP và thành phần hòa giải. Giai đoạn này sử dụng các điểm đo và kiểm soát trong môi trường chạy ESB, cũng như các thành phần hòa giải để theo dõi và tác động đến dòng thông báo.

Đối với phần mềm trung gian ESB, các vai trò phát triển giải pháp SOA quan trọng nhất là nhà phát triển tích hợp và nhà quản trị giải pháp, nhưng cũng có liên quan đến nhà phân tích nghiệp vụ, kiến trúc sư giải pháp, người thực hiện (implementer), nhà phát triển bộ tiếp hợp và người vận hành. (Các vai trò là khái niệm lôgic, một người có thể giữ nhiều vai trò). Hình 2 cho thấy các vai trò này tương tác như thế nào.

Các nhà phân tích nghiệp vụ nhận biết các yêu cầu nghiệp vụ và xem xét lại các qui trình nghiệp vụ. Họ phác thảo các mục tiêu của một giải pháp, các qui trình nghiệp vụ được gọi, các chỉ báo then chốt để theo dõi trạng thái và sức khỏe các giải pháp và các loại hình dịch vụ nghiệp vụ mà các hệ thống CNTT cần phải cung cấp.

Các kiến trúc sư giải pháp quyết định các yêu cầu nghiệp vụ nào có thể được đáp ứng bằng cách sử dụng lại, sửa đổi hoặc kết hợp các tài sản CNTT hiện có và các yêu cầu nghiệp vụ nào đòi hỏi các tài sản CNTT mới cần được viết hoặc mua. Họ định nghĩa các tương tác giữa các tài sản CNTT, bao gồm nội dung trao đổi thông báo.

Công việc phát triển được phân chia giữa ba vai trò. Một người thực hiện viết mã ứng dụng mới, sẽ được gọi thông qua một giao diện dịch vụ. Một nhà phát triển bộ tiếp hợp xây dựng các dịch vụ để gói gọn các ứng dụng và các gói hiện có hoặc mới mua nhằm mang lại khả năng truy cập cho các dịch vụ khác. Một nhà phát triển tích hợp sử dụng các công cụ và công nghệ có liên quan đến ESB để xây dựng một logic kiểm soát cách các yêu cầu được định tuyến giữa các dịch vụ này như thế nào.

Hình 2. Các vai trò của người sử dụng
Các vai trò của người sử dụng

Một nhà quản trị giải pháp làm cho các tài sản CNTT mới sẵn sàng để sử dụng bằng cách triển khai chúng và nhập khẩu các định nghĩa dịch vụ của chúng vào sổ đăng ký dịch vụ. Khi giải pháp đã được triển khai sẵn sàng, những người vận hành theo dõi việc thi hành của nó, khởi động và cho ngừng các hệ thống CNTT theo yêu cầu và tư vấn cho nhà quản trị giải pháp, những người có thể điều chỉnh cấu hình của giải pháp.


Các mẫu ESB

Các nhà phát triển tích hợp và các nhà quản trị giải pháp sử dụng một bộ các mẫu để thiết kế và triển khai các giải pháp SOA.

Hình 3. Các phần tử của mẫu ESB cơ bản
Các vai trò của người sử dụng

Mẫu ESB cơ bản trừu tượng hóa các thành phần ứng dụng thành một tập hợp các dịch vụ để tương tác thông qua một kênh chứ không thông qua các giao tiếp điểm-đến-điểm trực tiếp. Dịch vụ đang nói đến có thể là bên cung cấp, bên yêu cầu hoặc cả hai. Bất kỳ việc thực hiện SOA nào đều cần làm cho công nghệ ảo hóa cơ bản có thể thực hiện được, cho phép thay thế một triển khai thực hiện bên cung cấp dịch vụ tương đương mà không làm ảnh hưởng đến các bên yêu cầu phụ thuộc nó. Mẫu ESB hoàn thiện khả năng SOA cơ bản này thông qua việc quản lý rõ ràng các tương tác giữa bên yêu cầu - bên cung cấp dịch vụ. Bất cứ bên cung cấp dịch vụ nào cũng có thể được thay thế bằng bên cung cấp dịch vụ khác miễn là nó có các khả năng gần giống với yêu cầu của bên yêu cầu theo cách mà ESB có thể dàn xếp.

ESB cung cấp các điểm tương tác, nơi mà các các dịch vụ gửi các thông báo lên kênh hoặc lấy chúng về. Nó áp dụng các thành phần hòa giải đến các thông báo đang trên đường truyền dẫn và đảm bảo QoS cho các tương tác được quản lý này.

Từ phối cảnh của ESB, tất cả các điểm đầu cuối tương tác dịch vụ là như nhau, theo nghĩa chúng gửi các yêu cầu/các sự kiện hoặc xử lý các yêu cầu/các sự kiện; chúng cũng yêu cầu QoS cụ thể; và chúng có thể yêu cầu các hậu thuẫn cho tương tác. Mẫu ESB cho phép các nhà phát triển tích hợp coi bên yêu cầu hay bên cung cấp mà tương tác với mọi người theo cùng một cách (hướng-dịch vụ) giống như logic nghiệp vụ mới, các thành phần dàn dựng qui trình, hoặc các dịch vụ web bên ngoài.

Các mẫu để xây dựng các giải pháp dựa trên ESB được phân loại như sau:

  • Các mẫu tương tác: Cho phép các điểm tương tác dịch vụ gửi các thông báo đi hoặc nhận thông báo từ kênh.
  • Các mẫu hòa giải: Cho phép thao tác trao đổi thông báo.
  • Các mẫu triển khai: Hỗ trợ triển khai giải pháp vào một cơ sở hạ tầng liên kết.

Các mẫu tương tác

ESB cho phép các điểm cuối tương tác trong các mô hình tương tác tự nhiên của chúng thông qua kênh. Nó hỗ trợ một loạt các giao thức điểm cuối và các dạng tương tác. Một vài ví dụ về các mẫu tương tác là:

  • Yêu cầu /đáp ứng (Request/response): Xử lý các tương tác kiểu yêu cầu/đáp ứng giữa các điểm cuối. ESB dựa trên một mô hình truyền thông điệp, vì thế một tương tác yêu cầu/đáp ứng được xử lý bằng hai dòng thông điệp một chiều có liên quan -- một dòng cho yêu cầu và một dòng cho đáp ứng.
  • Một yêu cầu/nhiều đáp ứng (Request/multi-response): Một biến thể của dạng nói trên, ở đây có nhiều hơn một đáp ứng có thể được gửi đi.
  • Lan truyền sự kiện (Event propagation): Các sự kiện có thể được phân phối ẩn danh đến một danh sách các bên quan tâm do ESB quản lý. Các dịch vụ có thể tự bổ sung thêm mình vào danh sách.
Hình 4. Các mẫu tương tác
Các mẫu tương tác

Các mẫu hòa giải

Các mẫu hòa giải xử lý các thông điệp trên đường truyền dẫn trên kênh (các yêu cầu hoặc các sự kiện). Các thông điệp do một bên yêu cầu gửi đi được biến đổi thành các thông điệp hiểu được đối với một nhà cung cấp, có thể hơi không tương thích, được chọn từ một tập hợp các điểm cuối có tiềm năng.

Các mẫu hòa giải này hoạt động theo các thông điệp một chiều hơn là theo các cặp yêu cầu-đáp ứng, bởi vì ESB đặt các mẫu tương tác phủ bên trên các mẫu hòa giải.

Hình 5. Các mẫu hòa giải
Các mẫu hòa giải

Có một số các mẫu cơ bản của các thành phần hòa giải; các mẫu phức tạp hơn có thể được xây dựng bằng cách kết hợp các mẫu đơn giản:

  • Chuyển mạch giao thức (Protocol switch): Cho phép những bên yêu cầu dịch vụ gửi đi thông điệp của chúng, sử dụng một loạt các giao thức tương tác hoặc các API, ví dụ như là SOAP/HTTP, JMS và MQ Integrator (MQI). Chuyển mã các yêu cầu theo định dạng của bên cung cấp dịch vụ nhắm tới. Có thể được áp dụng tại đầu bên yêu cầu hoặc đầu bên cung cấp của một tương tác, hoặc tại cả hai đầu, hoặc tại bất cứ nơi nào ở giữa.
  • Chuyển đổi (Transform): Dịch nội dung thông báo từ lược đồ của bên yêu cầu sang lược đồ của bên cung cấp dịch vụ. Có thể bao gồm việc bao gói, mở gói hoặc mã hóa.
  • Làm giàu thêm (Enrich): Làm tăng thêm nội dung thông báo bằng cách bổ sung thêm các thông tin từ các nguồn dữ liệu bên ngoài, chẳng hạn như các thông số tuỳ chỉnh được định nghĩa bởi thành phần hòa giải, hoặc từ các truy vấn cơ sở dữ liệu.
  • Định tuyến (Route): Thay đổi tuyến đường của một thông điệp, lựa chọn giữa các bên cung cấp dịch vụ có hỗ trợ mục đích của bên yêu cầu. Tiêu chí lựa chọn có thể bao gồm nội dung và bối cảnh thông điệp, cũng như các khả năng của các đích.
  • Phân phối (Distribute): Phân phối thông điệp đến một tập hợp các bên quan tâm và thường là dựa theo khái lược các quan tâm của người đăng ký.
  • Theo dõi (Monitor): Theo dõi các thông điệp khi chúng đi qua một thành phần hòa giải không thay đổi. Có thể được sử dụng để theo dõi các mức dịch vụ; trợ giúp trong việc xác định vấn đề hay đo đạc việc sử dụng để sau đó tính tiền thu phí đối với những người sử dụng; hay ghi lại các sự kiện mức nghiệp vụ, chẳng hạn như đặt mua hàng vượt quá một mức (giá trị đô la) nào đó. Cũng có thể được sử dụng để ghi nhật ký các thông báo, phục vụ kiểm định hoặc khai phá dữ liệu sau này.
  • Thiết lập mối tương quan (Correlate): Tạo ra các sự kiện phức tạp từ các luồng thông điệp hoặc luồng sự kiện. Bao gồm các quy tắc để nhận biết mẫu và các quy tắc phản ứng lại việc khám phá mẫu, ví dụ, bằng cách tạo ra một sự kiện phức tạp bắt nguồn từ nội dung của luồng sự kiện kích hoạt.

Các thành phần hòa giải có thể được định cấu hình rõ ràng trong một giải pháp. Ví dụ, một nhà phát triển tích hợp có thể định cấu hình một thành phần hòa giải enrich để thay đổi nội dung thông báo. Một nhà quản trị giải pháp có thể định cấu hình một thành phần hòa giải route cho phép nó chuyển mạch một nhà cung cấp dịch vụ ở chế độ ngoại tuyến.

Các thành phần hòa giải khác được ESB đặt đúng chỗ để đáp ứng các yêu cầu QoS của các bên yêu cầu dịch vụ và các bên cung cấp dịch vụ. Ví dụ, nếu một khai báo chính sách an ninh của một nhà cung cấp dịch vụ đòi hỏi các thông báo phải được mã hóa, ESB có thể định cấu hình một thành phần hòa giải mã hóa (encryption) một cách tự động.

Cũng giống như là các thuộc tính của các dịch vụ, nhà quản trị giải pháp có thể thiết lập các chính sách đối với một tương tác hoặc nhóm các tương tác. Ví dụ, để ghi nhật ký tất cả các thông báo đến một nhà cung cấp bên ngoài cụ thể hoặc với một giá trị giao dịch vượt quá 1 triệu Đôla. ESB sẽ triển khai thực hiện chính sách bằng cách định cấu hình một thành phần hòa giải, trong trường hợp này, là một thành phần hòa giải monitor.


Các mẫu phức tạp

Hình 6. Các mẫu phức tạp
Các mẫu phức tạp

Các mẫu hòa giải và các mẫu tương tác có thể được kết hợp để thực hiện các mẫu phức tạp hơn.

Ví dụ, một chuyển mạch giao thức, tiếp sau đó là một phép biến đổi có thể triển khai thực hiện một mẫu bộ tiếp hợp chuẩn tắc (canonical adapter) trong đó tập hợp các thông điệp và các đối tượng nghiệp vụ được sử dụng bởi tất cả các bên được chuẩn hóa theo một khuôn dạng chuẩn tắc. Mẫu bộ tiếp hợp chuẩn tắc chuyển đổi các giao thức nguyên thủy, gắn với kênh (bus-attachment) của các điểm cuối thành một giao thức tiêu chuẩn, chuẩn hóa nội dung (payload) và biến đổi ngược trở lại khi chuyển giao cho bên nhận.

Một thành phần hòa giải phức tạp chung khác là mẫu biến đổi, ghi nhật ký và định tuyến (transform, log and route).

Mẫu cổng kết nối (gateway) là một biến thể chuyển mạch giao thức phức tạp. Nó có thể kết hợp các thành phần hòa giải chuyển đổi và theo dõi để cung cấp khả năng mã hóa, ghi nhật ký hoặc kiểm định. Nó cũng có thể kết hợp lại và tách ra các thông điệp trong một mối quan hệ một-tới-nhiều. Các cổng web dịch vụ tiêu biểu cho mẫu này, cung cấp một điểm liên lạc đơn lẻ cho nhiều dịch vụ và ẩn giấu các chi tiết của các dịch vụ bên trong.


Các mẫu triển khai

Các nhà quản trị giải pháp có một vài sự lựa chọn dành cho các hình thái ESB. Một số ví dụ thường gặp được chỉ ra dưới đây:

  • ESB toàn cầu (Global ESB): Tất cả các dịch vụ chia sẻ chung một vùng tên và mỗi bên cung cấp dịch vụ đều được mọi bên yêu cầu dịch vụ nhìn thấy, xuyên qua một môi trường phân phối không thuần nhất, được quản lý tập trung, phân tán về địa lý. Được sử dụng bởi các bộ phận hoặc các doanh nghiệp nhỏ, nơi tất cả các dịch vụ đều có thể được áp dụng trên toàn bộ tổ chức.
  • ESB được kết nối trực tiếp (Directly connected ESB): Một sổ đăng ký dịch vụ chung làm cho tất cả các dịch vụ có trong một số bản cài đặt ESB độc lập nhau đều có thể được nhìn thấy. Được sử dụng ở nơi dịch vụ được cung cấp và được quản lý bởi một dòng nghiệp vụ nhưng đã tạo ra cho nhiều loại doanh nghiệp có sẵn.
  • ESB được môi giới (Brokered ESB): Các dịch vụ cầu nối, đưa ra giới thiệu một cách có chọn lọc các bên yêu cầu hoặc các bên cung cấp dịch vụ cho bên đối tác trong các miền khác, điều phối việc chia sẻ giữa nhiều bản triển khai thực hiện ESB mà mỗi bản quản lý một vùng tên riêng của mình. Các tương tác dịch vụ giữa các ESB được hậu thuẫn thông qua một trình môi giới chung, mà trình này triển khai thực hiện các dịch vụ cầu nối. Được sử dụng bởi các bộ phận để phát triển và quản lý các dịch vụ riêng của mình, nhưng có chia sẻ một vài dịch vụ trong số đó hoặc có truy cập các dịch vụ chọn lọc, được cung cấp trong toàn doanh nghiệp.
  • ESB liên hiệp (Federated ESB): Một ESB chính mà một vài ESB phụ thuộc khác liên hiệp với nó. Những người sử dụng dịch vụ và các nhà cung cấp dịch vụ kết nối tới ESB chính hay tới một ESB phụ thuộc để truy cập vào các dịch vụ trên toàn mạng. Được sử dụng bởi các tổ chức muốn liên kết một tập hợp các bộ phận tự trị ở mức vừa phải dưới các ô của một bộ phận giám sát.
Hình 7. Các mẫu triển khai ESB
Các mẫu triển khai ESB

Kết luận

Mẫu ESB mở rộng các khả năng của công nghệ ảo hóa của SOA. Các thành phần hòa giải có thể được hợp thành từ các đơn vị chức năng tiêu chuẩn và được triển khai để tạo điều kiện thuận lợi cho các tương tác giữa những bên yêu cầu dịch vụ và bên cung cấp dịch vụ không ăn khớp với nhau. ESB cũng cung cấp một mô hình chung để triển khai, quản lý và quản trị các dịch vụ. Các khái niệm ESB cho phép tách biệt các mối quan tâm theo vai trò của người sử dụng, làm giảm bớt gánh nặng thiết kế khái niệm đối với bất kỳ người sử dụng nào, cải thiện khả năng sử dụng kiến trúc. Các công cụ đã thành phần hóa, mô hình lập trình toàn diện của ESB và sự hỗ trợ cơ sở hạ tầng thúc đẩy đáng kể việc thực hiện các nguyên tắc của SOA.


Lời cảm ơn

Các tác giả muốn cảm ơn Birgit Schmidt-Wesche, John Whitfield, Malcolm Ayres, Mandy Chessell, Peter Lambros, Rick Robinson, và Robert Berry về những đóng góp của họ cho bài viết này.

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 các 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=407155
ArticleTitle=Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 4: Giới thiệu về Kênh Dịch vụ Doanh nghiệp của IBM
publish-date=07102009