Tìm hiểu về Enterprise Service Bus (ESB) môn Kiến trúc hướng dịch vụ (SOA)

ĐẠI HỌC QUỐC GIA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN BÁO CÁO Môn học: Kiến trúc hướng dịch vụ (SOA) Đề tài: Tìm hiểu về Enterprise Service Bus (ESB) Giảng viên: TS. Võ Đình Hiếu Nhóm thực hiện: Trần Mạnh Trường Cù Kim Long Trịnh Thị Mai Anh Lương Thế Hùng Vũ Xuân Nam Lớp: Quản lý Hệ thống thông tin Hà Nội, tháng 04/2011 MỤC LỤC MỤC LỤC 2 1. Giới thiệu 3 2. ESB là gì? 5 3. Các vai trò của người sử dụng SOA và các nhiệm vụ của chúng 7 4. Các mẫu ESB 9 4.1. Các mẫu tương tác 11 4.2. Các mẫu hòa giải 12 4.3. Các mẫu phức tạp 14 4.4. Các mẫu triển khai 14 5. Ví dụ về ESB 16 6. MuleESB 17 6.1. Giới thiệu Mule ESB 17 6.2. Kiến trúc của Mule ESB 18 6.2.1. Xử lý dữ liệu 19 6.2.2. Điều hướng thông điệp giữa các thành phần dịch vụ 20 6.2.3. Tách biệt logic nghiệp vụ với thông điệp 20 6.2.4. Kết hợp các dịch vụ với nhau 22 6.3. Logic của luồng dữ liệu 23 7. Kết luận 24 2 1. 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. 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. Một ESB là một kiến trúc phần mềm cho lớp giữa (middleware), cung cấp các dịch vụ cơ bản phục vụ các lớp kiến trúc phức tạp hơn. Ví dụ: một ESB tổ chức chặt chẽ tất cả các tính năng sẽ yêu cầu thực thi một kiến trúc hướng dịch vụ SOA. Nói một cách tổng quan, ESB có thể được nghĩ như một cơ chế mà tại đó nó quản lý việc truy cập vào các ứng dụng và các dịch vụ (đặc biệt là các hệ thống cũ với phiên bản khác 3 nhau), để đưa ra một giao diện, giao tiếp đơn giản và đồng nhất với người dùng cuối, có thể thông qua Web, hoặc form tới người dùng cuối. Hiểu cách khác, ESB thực hiện phân phối các dịch vụ cho các hệ thống và các ứng dụng không đồng nhất phía sau với người dùng phía trước, hay các hệ thống cần thông tin cũng không đồng nhất. Khi đó, các phần mềm lớp giữa sẵn sàng thực hiện: Ẩn các phần phức tạp, đơn giản hóa các truy nhập, cho phép các nhà phát triển sử dụng các form truy vấn chung và đồng nhất, truy nhập và tương tác, xử lý các chi tiết phức tạp phía sau. Sự hấp dẫn của ESB và có thể thành công trong tương lai, chính là khả năng hỗ trợ sự tăng lên nhanh chóng các dịch vụ và các ứng dụng tích hợp trong các hệ thống của tổ chức doanh nghiệp theo đòi hỏi của nghiệp vụ kinh doanh có thể vượt quá khả năng của công nghệ của các hệ thống đó. Một ESB được xây dựng có khả năng: - Phân phối thông tin cho toàn bộ doanh nghiệp một cách nhanh chóng và dễ dàng. - Ẩn đi các nền tảng khách nhau phía sau của kiến trúc phần mềm và các giao thức mạng. - Đảm bảo thông tin được chuyển đi cho dù thậm chí khi vài hệ thống hoặc mạng bị ngừng hoạt động gián đoạn. - Định tuyến, lưu vết, và lưu trữ thông tin không đòi hỏi các ứng dụng cần viết lại (coding). - Đáp ứng việc triển khai dần dần, doanh nghiệp không nhất thiết phải chuyển toàn bộ dịch vụ hay các ứng dụng ngay hoặc toàn bộ trong một lần. Việc định tuyến các bản tin trên ESB, mỗi một hãng công nghệ có một sản phẩm khác nhau. Nhưng có vẻ về nhìn chung, nó routing các bản tin gần như là Router trong Network vậy. Các bản tin có thể được định tuyến theo chủ đề (Subject), hay nội dụng hay ID của bản tin. Và giữa các subnets khác nhau, các bản tin cũng được quản lý giám sát để được Route qua tường lửa ESB không phải là một sản phẩm mới, nó chỉ là một cách nhìn mới về cách tích hợp các ứng dụng, sự phối hợp các tài nguyên và quản lý xử lý thông tin mà thôi. 4 2. 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 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 5 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). 6 Hình 1. 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ý. 3. 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. 7 Đố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. 8 Hình 2. 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. 4. 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. 9 Hình 3. Các phần tử của mẫu ESB cơ bản 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 10 [...]... phần dịch vụ, đưa nó vào phần cài đặt cấu hình và thể hiện như một dịch vụ, và chắc chắn rằng thông tin đúng đắn sẽ được chuyển đi dựa trên cài đặt mà ta chỉ định cho dịch vụ nào đó trong tệp cấu hình của Mule Ta có thể có nhiều thành phần dịch vụ khác nhau để thực thi các logic nghiệp vụ khác nhau, như một dịch vụ có nhiệm vụ xác thực xem mặt hàng của hóa đơn có trong kho hàng 19 hay không và dịch vụ. .. điệp, gửi nó tới dịch vụ xử lý với thông điệp đó một số logic nghiệp vụ cần thiết (như kiểm tra khách hàng và cơ sở dữ liêu kho hàng), và sau đó điều hướng nó tới ứng dụng cần thiết khác (như hệ thống hoàn tất hóa đơn) Mule chứa nhiều thành phần khác nhau để quản lý việc xử lý và điều hướng thông điệp đó Phần quan trọng của dịch vụ là thành phần dịch vụ (service component) Thành phần dịch vụ thực hiện... thể chuyển theo một luồng tới thành phần dịch vụ kế tiếp cho tới khi tất cả các yêu cầu được hoàn tất 6.2.2 Điều hướng thông điệp giữa các thành phần dịch vụ Như đề cập ở phần trên, thành phần dịch vụ chứ logic nghiệp vụ để xử lý dữ liệu trong thông điệp Nó không chứa bất kỳ thông tin nào về cách nhận và gửi bản thân thông điệp đó Để đảm bảo rằng thành phần dịch vụ nhận thông điệp đúng đắn và chuyển tiếp... 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... 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 4.4 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: 14 • 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... dịch vụ có thể đọc được trước khi router (bộ điều hướng) chuyển thông điệp đó tới thành phần dịch vụ Ví dụ, nếu hóa đơn ở dạng XML được gửi qua giao thức HTTP thì HTTP transport sẽ mang thông điệp, router sẽ định hướng thông điệp tới mỗi thành phần dịch vụ cần xử lý nó, và transformer sẽ thay đổi hóa đơn theo một cách nào đó (ví dụ từ XML thành đối tượng Java) theo yêu cầu của mỗi thành phần dịch vụ. .. 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... Lưu trữ và phục vụ các dịch vụ có thể tái sử dụng, • Mule ESB hoạt động như một bộ chứa các dịch vụ một cách nhẹ nhàng Service mediation — che dấu các dịch vụ khỏi định dạng thông điệp và các giao thức, • tách biệt logic nghiệp vụ với thông điệp và cho phép gọi dịch vụ ở các điểm độc lập Message routing — điều hướng, lọc, tập hợp và sắp thứ tự các thông điệp dựa trên nội • dung và các qui tắc Data transformation... 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... xử lý, ta phải chỉ định một inbound router và một outbound router cho dịch vụ mà chứa thành phần đó khi cấu hình Mule ESB Inbound router chỉ ra những thông điệp nào thành phần dịch vụ sẽ xử lý Chúng có thể lọc thông điệp gửi đến, tổ chức và sắp xếp chúng trước khi chuyển tiếp chúng tới thành phần dịch vụ Sauk hi một thành phần dịch vụ đã xử lý thông điệp, outbound router sẽ xác định nơi chuyển tiếp thông . ĐẠI HỌC QUỐC GIA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN BÁO CÁO Môn học: Kiến trúc hướng dịch vụ (SOA) Đề tài: Tìm hiểu về Enterprise Service Bus (ESB) Giảng viên: TS. Võ Đình Hiếu Nhóm thực hiện: Trần. như: • Service creation and hosting — Lưu trữ và phục vụ các dịch vụ có thể tái sử dụng, Mule ESB hoạt động như một bộ chứa các dịch vụ một cách nhẹ nhàng. • Service mediation — che dấu các dịch vụ. quản lý việc xử lý và điều hướng thông điệp đó. Phần quan trọng của dịch vụ là thành phần dịch vụ (service component). Thành phần dịch vụ thực hiện các logic nghiệp vụ trên thông điệp, như đọc