Chuyển đổi các ứng dụng một bên thuê thành các ứng dụng nhiều bên thuê

Chuyển đổi các ứng dụng một bên thuê thành các ứng dụng nhiều bên thuê Là các chuyên gia công nghệ, một trong những mục tiêu của chúng tôi là chia sẻ các kinh nghiệm của mình và những bài học mà chúng tôi học được, trong trường hợp này là kiến thức mà chúng tôi đã thu được từ việc xây dựng các ứng dụng nhiều bên thuê chạy trên IBM® SmartCloud Enterprise (Doanh nghiệp SmartCloud của IBM). Cụ thể là, chúng tôi sẽ mô tả các kỹ thuật mà chúng tôi đã sử dụng để chuyển đổi các ứng dụng SOA một bên thuê hiện có thành các ứng dụng Phần mềm là một Dịch vụ (SaaS) nhiều bên thuê. Cuối cùng, mặc dù, chúng tôi hy vọng các công cụ sẽ được phát triển để giúp các nhà phát triển bằng cách tự động hóa các phép chuyển đổi các ứng dụng một bên thuê thành các ứng dụng nhiều bên thuê phức tạp hơn. Trước tiên, hãy xem xét một số các giải pháp truyền thống từ một quan điểm của IBM (do chúng tôi quen với điều đó). Các giải pháp công nghiệp của IBM IBM cung cấp một danh mục phần mềm sâu và rộng với một bộ các khả năng phong phú. Ngoài ra, dựa trên rất nhiều các cam kết khách hàng của chúng tôi, chúng tôi có thể nói rằng IBM đang ở một vị trí duy nhất để kết hợp các khả năng này để tạo ra các giải pháp công nghiệp "ngoài hộp" (out of the box) giúp các khách hàng giải quyết các vấn đề kinh doanh cụ thể. Cách tiếp cận này cho phép các khách hàng tốn ít thời gian và nỗ lực tích hợp các sản phẩm phần mềm của IBM để giải quyết các nhu cầu kinh doanh cụ thể của họ. Kiến trúc tham khảo SOA của IBM Kiến trúc tham khảo SOA của IBM là một trình cho phép (enabler) chủ yếu để đạt được các mệnh đề giá trị của một kiến trúc hướng dịch vụ, tạo điều kiện thuận lợi cho việc tạo ra các tài sản có thể sử dụng lại, linh hoạt để thực hiện các giải pháp kinh doanh từ đầu đến cuối. Tiêu chuẩn SOA RA (Open Group SOA Reference Architecture - Kiến trúc tham khảo SOA của Tập đoàn Open) cung cấp các hướng dẫn và các tùy chọn để đưa ra các quyết định về kiến trúc, thiết kế và thực hiện trong kiến trúc của các giải pháp hướng dịch vụ, gồm cả kiến trúc của các giải pháp đám mây. Mục tiêu của tiêu chuẩn SOA RA là cung cấp một kế hoạch chi tiết để tạo và đánh giá kiến trúc. Hơn nữa, nó cung cấp những hiểu biết, các mẫu và các khối xây dựng để tích hợp các phần tử cơ bản của một SOA vào một giải pháp hoặc kiến trúc doanh nghiệp. Kiến trúc tham khảo SOA của IBM giúp tạo ra các giải pháp hướng tới các qui trình kinh doanh, các công cụ kinh doanh, trao đổi tin nhắn, tích hợp dịch vụ, truy cập dữ liệu và đóng gói phần mềm và các thành phần di sản. Để biết thêm thông tin, hãy xem Ưu điểm đối với các tiêu chuẩn kiến trúc tham khảo SOA của IBM. Nhiều giải pháp trong đó được phát triển theo Kiến trúc tham khảo SOA của IBM. Ví dụ,  Một cổng thông tin được sử dụng để tập hợp các thành phần của các ứng dụng vào một khung nhìn riêng và cho phép mọi người cộng tác và tương tác với các doanh nghiệp của họ hoặc các dịch vụ Công nghệ thông tin dựa trên vai trò của họ.  Một bus dịch vụ doanh nghiệp được sử dụng để cung cấp tính linh hoạt khi tích hợp và kết nối dịch vụ.  Các nguyên tắc bảo mật như nhận dạng, xác thực, uỷ quyền, kiểm toán và tuân thủ được áp dụng cho toàn bộ vòng đời hướng dịch vụ.  Các đồng hồ hiệu năng chính được theo dõi trong thời gian thực để cho giải pháp đó có thể nhận được thông tin mà chúng cần để phòng tránh, cách ly, chẩn đoán và sửa chữa các vấn đề.  Các phân tích kinh doanh được áp dụng để khám phá các liên kết nhạy cảm và hỗ trợ một giải pháp đưa ra các quyết định đúng.  Các báo cáo được thiết kế, tùy chỉnh và tiêu dùng thông qua cổng thông tin tích hợp. Như bạn có thể hình dung, các khả năng của một danh mục phần mềm bao gồm WebSphere® Portal (Cổng thông tin WebSphere), Lotus® Sametime, Cognos Business Intelligence (Kinh doanh thông minh Cognos), WebSphere MQ, WebSphere Message Broker (Người môi giới thông báo WebSphere), Business Process Management (Quản lý qui trình kinh doanh), Tivoli® Access Manager (Trình quản lý truy cập Tivoli), DB2®, Rational® Asset Manager (Trình quản lý tài sản Rational của DB2), v.v.. có thể được kết hợp để tạo các giải pháp ngoài hộp mới. Vậy thì thách thức đó trở thành ... ...Làm thế nào để bạn tạo ứng dụng SaaS nhiều bên thuê sử dụng các sản phẩm doanh nghiệp có sẵn mà không có khái niệm nguyên gốc riêng của chúng về một bên thuê, nhất là khi bạn cần mở rộng thêm để hỗ trợ càng ngày càng nhiều bên thuê trong giải pháp đó? Gần đây chúng tôi đã thực hiện một nỗ lực phát triển với các nhóm Giải pháp công nghiệp của mình để chuyển đổi các giải pháp SOA một bên thuê thành các giải pháp SOA nhiều bên thuê, sẵn sàng để triển khai trong IBM SmartCloud Enterprise như là các giải pháp SaaS. Mặc dù một giải pháp SOA có thể sử dụng nhiều sản phẩm phần mềm trung gian của IBM và việc chuyển đổi nó sang nhiều bên thuê có vẻ khó khăn, khả năng mở rộng của các sản phẩm phần mềm trung gian của IBM thực sự làm cho phép chuyển đổi này khá đơn giản. Bài này mô tả các kỹ thuật và những hiểu biết có thể có ích nếu bạn muốn chuyển đổi các giải pháp một bên thuê hiện có của bạn thành các giải pháp SaaS nhiều bên thuê. Trước tiên hãy xem xét khái niệm về nhiều bên thuê. Về đầu trang Khái niệm về nhiều bên thuê Các công ty lớn và nhỏ, cũng như các ISV, ngày càng tìm hiểu các giải pháp dựa trên đám mây và SaaS là mô hình phân phối mới của họ. Trong danh mục phần mềm của IBM, có nhiều cách tiếp cận để tạo ra các dịch vụ SaaS mới. Một cách tiếp cận là tạo ra một dịch vụ mới từ đầu để được cung cấp như là một giải pháp SaaS; ví dụ, IBM Blueworks Live. Cách tiếp cận khác là lấy một sản phẩm đã bắt đầu như một dịch vụ doanh nghiệp, tại doanh nghiệp và "tiến hóa" nó thành một giải pháp SaaS; ví dụ, Thương mại- là-một-Dịch vụ, Cognos và IBM SmartCloud cho Doanh nghiệp xã hội (trước đây là LotusLive™). Trong cách tiếp cận đầu tiên, nhiều bên thuê có xu hướng xây dựng từ nền lên. Đối với cách tiếp cận thứ hai, dịch vụ tại doanh nghiệp có thể không có khái niệm về một bên thuê, nhưng bạn có thể đạt được nhiều bên thuê bằng cách sử dụng các cấu hình tùy chỉnh. Hãy xem xét một số kịch bản nhiều bên thuê phổ biến để làm nổi bật định nghĩa vạch chuẩn của bên thuê. Về đầu trang Các kịch bản nhiều bên thuê phổ biến Khái niệm chung về nhiều bên thuê đã được thảo luận trong các bài viết trước (xem Tài nguyên). Một khái niệm quan trọng cần hiểu là có một phạm vi các khả năng để chia sẻ tài nguyên. Hình 1 định nghĩa các ngăn xếp công nghệ nơi nhiều bên thuê có liên quan đến một môi trường đám mây. Hình 1. Phạm vi nhiều bên thuê khi được mức tài nguyên chia sẻ xác định Như bạn có thể thấy, các kịch bản nhiều bên thuê gồm có: 1. Không chia sẻ tài nguyên nào. 2. Tài nguyên phần cứng chia sẻ. 3. Hệ điều hành chia sẻ. 4. Phần mềm trung gian chia sẻ. 5. Các ứng dụng chia sẻ. Hãy xem xét từng kịch bản chi tiết hơn. Kịch bản 1: Không chia sẻ. Mỗi bên thuê có ngăn xếp hoàn chỉnh riêng của mình về các ứng dụng, các phần mềm trung gian, các hệ điều hành và cơ sở hạ tầng (phần cứng). Mỗi bên thuê hoàn toàn được tách rời nhau ngoại trừ nó có thể sẽ chạy trong cùng một trung tâm dữ liệu vật lý. Kịch bản 2: Phần cứng chia sẻ. Bên thuê sẽ bắt đầu chia sẻ cơ sở hạ tầng trong một trung tâm dữ liệu. Ví dụ, bên thuê có thể chia sẻ các máy chủ (ví dụ, Intel®, Power), lưu trữ (SONAS®, NetApp®) và các mạng (Juniper, Cisco) trong các trung tâm dữ liệu. Kịch bản 3: Hệ điều hành chia sẻ. Bây giờ bên thuê sẽ chia sẻ cơ sở hạ tầng và các hệ điều hành. Các trình siêu giám sát như KVM và VMware® thường được sử dụng để ảo hóa phần cứng để cho phép nhiều hệ điều hành chạy trên phần cứng đó. Bên thuê vẫn còn được tách rời với các bên thuê khác vì mỗi bên có thể có các phiên bản riêng của mình về các máy chủ ứng dụng, các máy chủ cơ sở dữ liệu và các ứng dụng. Mức chia sẻ này cũng được gọi là Cơ sở hạ tầng là một Dịch vụ (IaaS). Kịch bản 4: Phần mềm trung gian chia sẻ. Bây giờ bên thuê đang bắt đầu chia sẻ một bộ các dịch vụ phần mềm trung gian chạy trên đỉnh của các hệ điều hành và cơ sở hạ tầng chia sẻ; ví dụ, dịch vụ bảo mật, cổng thông tin, các dịch vụ cơ sở dữ liệu, các dịch vụ giám sát, v.v.. Các ứng dụng khác nhau có thể được xây dựng trên các thành phần phần mềm trung gian chia sẻ này. Mức chia sẻ này cũng được gọi là Nền tảng là một Dịch vụ (PaaS). Kịch bản 5: Các ứng dụng chia sẻ. Bây giờ bên thuê sẽ chia sẻ cùng một ứng dụng với các bên thuê khác. Bằng chính bản chất của việc chia sẻ này, các bên thuê cũng sẽ chia sẻ cùng một phần mềm trung gian, gồm cả các phiên bản được sử dụng để thực hiện các ứng dụng. Mặc dù các bên thuê đang chia sẻ tài nguyên cơ bản giống nhau, chúng vẫn còn được tách rời logic với mỗi bên thuê khác. Một bên thuê không có khả năng nhìn thấy các tài sản của bên thuê khác (ví dụ như dữ liệu có thể được lưu trữ trong các máy chủ cơ sở dữ liệu hoặc hệ thống tệp). Mức chia sẻ này cũng được gọi là Phần mềm là một Dịch vụ (SaaS). Nói chung, càng có số điểm nhiều bên thuê cao hơn (có nghĩa là trong kịch bản 5, các ứng dụng chia sẻ), càng cần ít nỗ lực hơn để thiết lập một bên thuê mới vì càng có nhiều ngăn xếp cơ bản được chia sẻ. Đối với bất kỳ doanh nghiệp nào, các kế hoạch nhằm mang lại càng ngày càng nhiều bên thuê hơn về sau, có khả năng mở rộng mà không cần đến một sự gia tăng to lớn về cả hai tài nguyên kỹ thuật và tài nguyên kinh doanh sẽ là điều quan trọng cần xem xét trước. Có một cơ sở mã được chia sẻ có thể làm tăng các tiêu chuẩn thời gian tới giá trị cho cả nhà cung cấp lẫn các khách hàng và cho phép các sáng kiến mới được triển khai trong vài tuần thay vì vài tháng hoặc vài năm. Ở trên, chúng tôi đã đề cập đến một số các giải pháp phần mềm một-bên thuê đã không có một khái niệm về một bên thuê nguyên gốc trong thiết kế của chúng; chúng ta hãy thảo luận cách có thể giải quyết điều đó trước khi chúng tôi công bố 7 kỹ thuật giúp bạn chuyển đổi phần mềm một-bên thuê thành các giải pháp nhiều bên thuê. Về đầu trang Cách ly tạo ra một bên thuê trá hình Mặc dù chẳng có phần mềm nào trong các sản phẩm phần mềm mà chúng tôi đã đề cập mang theo mình khái niệm rõ ràng về một bên thuê (hoặc với thực tế đó, khái niệm về những người dùng trong một bên thuê), mỗi sản phẩm có chứa một khái niệm dựng sẵn về sự cách ly có thể được sử dụng để thực hiện một giải pháp nhiều bên thuê. Ví dụ, bài viết về các hướng dẫn thực hành tốt nhất để đạt được nhiều bên thuê hợp tác bằng cách sử dụng Rational Asset Manager ("Các hướng dẫn thực hành tốt nhất cho sự hợp tác trung tâm tài sản dựa trên đám mây", xem Tài nguyên) mô tả cách sử dụng khái niệm các cộng đồng tài sản trong Rational Asset Manager để đạt được sự cách ly và chia sẻ tài sản giữa các bên thuê. Một cộng đồng tài sản có thể được tạo ra cho một bên thuê và những người dùng của bên thuê đó có thể xuất bản tài sản cho cộng đồng; Tuy nhiên, những người dùng của bên thuê khác sẽ không nhìn thấy hoặc truy cập vào cộng đồng tài sản này theo mặc định. Một phương thức tương tự có thể được áp dụng cho phần còn lại của các dịch vụ của IBM đã đề cập ở trên. Do phần mềm của IBM có thể mở rộng được, nhiều khi đó là vấn đề sử dụng các API trong các sản phẩm để thực hiện tuỳ chỉnh. Khi sử dụng khái niệm này, chúng ta hãy xem xét bảy kỹ thuật sẽ giúp bạn chuyển đổi sang nhiều bên thuê. Về đầu trang Bảy kỹ thuật để chuyển đổi sang nhiều bên thuê Trong những nỗ lực của chúng tôi để chuyển đổi các giải pháp SOA công nghiệp, chúng tôi xác định bảy kỹ thuật có thể có ích khi bạn chuyển đổi các ứng dụng một bên thuê của bạn thành các ứng dụng SaaS nhiều bên thuê đầy đủ được xây dựng trên các sản phẩm phần mềm trung gian của IBM. Những kỹ thuật đó là  LDAP chia sẻ.  Đăng nhập một lần.  Cơ sở dữ liệu máy chủ chia sẻ.  Bus dịch vụ doanh nghiệp (Enterprise Service Bus) chia sẻ.  Các báo cáo cụ thể của bên thuê.  Các tệp bản ghi nhật ký cụ thể của bên thuê.  Giao diện người dùng thống nhất qua Cổng thông tin WebSphere. Chúng ta hãy xem xét chi tiết từng kỹ thuật. LDAP chia sẻ Để tạo ra một môi trường nhiều bên thuê, một trong những điều đầu tiên cần triển khai là một LDAP chia sẻ để cho bạn có thể có một vị trí trung tâm để quản lý thống nhất thông tin của người dùng và của tổ chức. IBM Tivoli Directory Server (Máy chủ thư mục Tivoli của IBM) là một công cụ LDAP phổ biến mà chúng tôi sử dụng. Tất cả các sản phẩm phần mềm IBM của chúng tôi đã cung cấp tích hợp ngoài hộp với Tivoli Directory Server, vì thế rất nhiều tài sản cài đặt hiện tại có thể được sử dụng. Có một vài lĩnh vực cần chú ý. Mỗi sản phẩm thường đi kèm với các thuộc tính được tối ưu hóa để xây dựng các bộ lọc tìm kiếm cụ thể với sản phẩm đó và cấu trúc thư mục LDAP mặc định riêng của nó. Bạn sẽ cần thực hiện một số việc tiêu chuẩn hóa và điều chỉnh các thiết lập mặc định này khi chia sẻ LDAP giữa nhiều sản phẩm. Ví dụ, chú ý đến sự phân biệt dạng chữ: Một số sản phẩm có thể bỏ qua trường hợp này trong khi các sản phẩm khác có thể không, như ví dụ điển hình sau đây: cn=users, o=ibm, c=us so với: cn=Users, o=IBM, c=US Đăng nhập một lần Đăng nhập một lần (SSO) cho phép một người dùng đăng nhập một lần và sau đó truy cập vào tất cả các hệ thống mà không bị nhắc đăng nhập lại cho mỗi lần truy cập vào một hệ thống trong chúng. Do nhiều sản phẩm phần mềm trung gian được xây dựng trên WebSphere Application Server (WAS – Máy chủ ứng dụng WebSphere), công nghệ LTPA (Lightweight Third-Party Authentication – Xác thực trọng số nhẹ của bên thứ ba) của IBM có thể được sử dụng và nó hoạt động hiệu quả trong một môi trường dựa trên trình duyệt. Hình 2 cho thấy một ví dụ về toàn bộ luồng. Hình 2. Đăng nhập một lần giữa nhiều máy chủ bằng cách sử dụng thẻ xác thực LTPA Khi một yêu cầu HTTP đến, WebSEAL làm việc với Tivoli Access Manager Policy Server (Máy chủ chính sách của Trình quản lý truy cập Tivoli) để xác định xem tài nguyên cần thiết có được bảo vệ không. Nếu được bảo vệ, WebSEAL đảm bảo rằng người dùng được xác thực trước khi cho phép yêu cầu này đạt tới các ứng dụng; ví dụ, một portlet chạy trên WebSphere Portal. Nếu portlet cần truy cập vào máy chủ khác, ví dụ như Sametime Community Server, thẻ xác thực LTPA chia sẻ xác định người dùng đã được WebSEAL xác thực; người dùng đó sẽ không bị kiểm tra xác thực lại. Mặc dù thẻ xác thực LTPA là một kỹ thuật tiêu chuẩn để thực hiện SSO giữa các máy chủ ứng dụng WebSphere, trong thực tế bạn vẫn phải cẩn thận khi triển khai một hệ thống như vậy trong đám mây. Dưới đây là một số thách thức mà chúng tôi gặp phải khi triển khai các giải pháp.  Một tệp LTPA quan trọng thường được xuất khẩu từ một hệ thống (ví dụ, WebSEAL) và sau đó được nhập khẩu vào hệ thống khác (ví dụ, WebSphere Portal, máy chủ Domino). Điều quan trọng là tệp quan trọng này sử dụng một cách thích hợp để mô tả LDAP chia sẻ, ví dụ bằng cách sử dụng một tên miền đầy đủ như sau: com.ibm.websphere.ltpa.Realm=vhost1111.site1.compute.ihost.com\:389   Nếu một máy chủ đang sử dụng một bí danh và đã xuất khẩu một tệp LTPA quan trọng với tên bí danh đó, nhưng một máy chủ khác không hỗ trợ sử dụng bí danh, thì SSO sẽ không làm việc đúng.   Bạn có thể thấy một lỗi trong các tệp bản ghi nhật ký cho biết thẻ xác thực LTPA của bạn đã hết hạn. Điều này có thể xảy ra nếu thời gian của hệ điều hành thiết lập trên mỗi máy ảo không giống nhau. Ví dụ, nếu thời gian thiết lập trên máy ảo WebSEAL là 10:00 và thời gian thiết lập trên máy ảo Portal là 1:00, thì khi máy chủ Portal mở thẻ xác thực và so sánh nó với thời gian cục bộ của nó, nó sẽ nghĩ rằng thẻ xác thực này đã hết hạn. Vấn đề này là khá nổi bật trong môi trường IBM SmartCloud do đồng hồ trên các máy ảo được cung cấp không đảm bảo giống nhau. Chúng tôi phải thực hiện các bước bổ sung để thiết lập lại hoặc đồng bộ lại đồng hồ trên mỗi máy ảo tới cùng một thời gian và múi giờ để cho SSO làm việc đúng. Chúng tôi cũng khuyên bạn trước tiên nên tiến hành kiểm tra SSO theo từng cặp trước khi bạn kiểm tra toàn bộ luồng. Ví dụ, đảm bảo SSO làm việc giữa:  WebSEAL và Portal  WebSEAL và Sametime  Portal và Sametime Khi các cặp này sắp làm việc, hãy kiểm tra toàn bộ đường dẫn từ WebSEAL > Portal > Sametime. Có rất nhiều máy chủ liên quan đến một giải pháp SOA, do đó, có một cách hệ thống để kiểm tra, rồi lặp lại bước kiểm tra đó là một nhân tố thành công quan trọng để quản lý các loại lỗi khác nhau có thể gặp phải trong một môi trường đám mây. Cơ sở dữ liệu máy chủ chia sẻ Điều thứ ba mà bạn muốn xem xét trong môi trường nhiều bên thuê của bạn là làm thế nào để cách ly dữ liệu của bên thuê của bạn với từng bên thuê khác. Giả sử ứng dụng một bên thuê của bạn đang sử dụng một cơ sở dữ liệu quan hệ như DB2, nhiệm vụ này tương đối đơn giản. Có một vài mô hình phổ biến như minh họa trong Hình 3. Hình 3. Các mô hình cơ sở dữ liệu nhiều bên thuê 1. Mỗi bên thuê có cơ sở dữ liệu riêng của mình. 2. Mỗi bên thuê có lược đồ riêng của mình trong một cơ sở dữ liệu riêng. 3. Tất cả các bên thuê chia sẻ cùng một cơ sở dữ liệu. Kịch bản đầu tiên đòi hỏi số lượng thay đổi trong ứng dụng ít nhất để nhận ra khái niệm về bên thuê. Thông thường tất cả thay đổi mà nó đòi hỏi dùng cho ứng dụng để kết nối với cơ sở dữ liệu cụ thể của bên thuê phải dựa vào mã định danh (ID) bên thuê. Kịch bản 1 cũng cung cấp sự cách ly nhiều nhất giữa các bên thuê. Ví dụ, các cơ sở dữ liệu của bên thuê 1 và bên thuê 2 có thể được lưu trữ theo một lịch biểu khác nhau. Kịch bản thứ hai là điển hình nếu ứng dụng hiện tại có khái niệm về siêu dữ liệu riêng của mình và dữ liệu của người dùng cần lưu trú trong cùng một cơ sở dữ liệu do cách đã thiết kế các kết nối cơ sở dữ liệu hiện có. Trong trường hợp đó, bạn có thể xem xét tách rời dữ liệu của bên thuê bằng lược đồ trong cùng một cơ sở dữ liệu và cần giảm thiểu việc thiết kế lại cần thiết. Kịch bản thứ ba yêu cầu nhiều thay đổi nhất trong ứng dụng và thiết kế các bảng. Khái niệm về ID bên thuê phải được đưa vào trong thiết kế các bảng để ứng dụng có thể kiểm tra dữ liệu đang cập nhật hoặc lấy ra cho một bên thuê cụ thể dựa vào ID bên thuê đó. Kịch bản này được sử dụng điển hình hơn bởi các ứng dụng được thiết kế từ nền lên để được cung cấp như SaaS. Bus dịch vụ doanh nghiệp chia sẻ Một ESB (Enterprise Service Bus – Bus dịch vụ doanh nghiệp) hỗ trợ các khái niệm về thực hiện SOA bằng cách tách khung nhìn của một dịch vụ của khách hàng với việc thực hiện một dịch vụ. Việc tách khung nhìn của một dịch vụ của khách hàng với việc thực hiện thực tế làm tăng tính linh hoạt của kiến trúc. Nó cho phép thay thế một nhà cung cấp dịch vụ bằng nhà cung cấp khác mà không để khách hàng nhận ra sự thay đổi này hoặc sự thay đổi luân phiên của kiến trúc. Có nhiều mẫu ESB khác nhau và các ánh xạ sản phẩm tương ứng (xem Sách Đỏ trong Tài nguyên). Dự án đang hoạt động hiện tại của chúng tôi tập trung vào một cấu trúc liên kết điển hình bằng cách sử dụng WebSphere MQ và WebSphere Message Broker. WebSphere MQ tạo điều kiện thuận lợi cho truyền thông giữa các ứng dụng. Một hàng đợi WebSphere MQ dùng làm thùng chứa (container) cho các thông báo được trao đổi giữa các ứng dụng. Một trình quản lý hàng đợi quản lý các hàng đợi và dùng làm một thùng chứa cho các hàng đợi. WebSphere Message Broker mở rộng WebSphere MQ và có thể được sử dụng để xử lý các thông báo trong hàng đợi bằng cách sử dụng các quy tắc của người môi giới. Trong một hệ thống nhiều bên thuê, tất cả các bên thuê chia sẻ một cá thể riêng của WebSphere MQ và WebSphere Message Broker. Trong một thiết lập như vậy, thông tin được một bên thuê gửi đi phải được cách ly với bên thuê khác. Một cách để đạt được sự cách ly này là cung cấp một trình quản lý hàng đợi duy nhất cho mỗi bên thuê. Cá