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ê

Chia sẻ: Nhung Nhung | Ngày: | Loại File: PDF | Số trang:11

Thêm vào BST

Báo xấu

63
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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à...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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ác hàng đợi trong các trình quản lý hàng đợi cụ thể của bên thuê được cách ly với mỗi bên thuê khác, do đó khi cách ly các thông báo chuyển vào hàng đợi. Các trình quản lý hàng đợi có thể được quản lý riêng sao cho các vấn đề ảnh hưởng đến cơ sở hạ tầng hàng đợi của một bên thuê không ảnh hưởng đến các bên thuê khác. Mỗi bên thuê trong hệ thống nhiều bên thuê có thể có một bộ các quy tắc người môi giới khác nhau. Để cho phép mỗi bên thuê có các quy tắc người môi giới riêng của mình, các trình quản lý
hàng đợi cụ thể của bên thuê có thể được kết hợp với các quy tắc người môi giới cụ thể của bên thuê. Điều này cho phép cách ly quy tắc người môi giới giữa các bên thuê. Hình 4 tóm tắt toàn bộ ý tưởng cho thấy hai bên thuê riêng biệt chạy trong cùng một cá thể ESB. Hình 4. Các mẫu Bus dịch vụ doanh nghiệp nhiều bên thuê Các báo cáo cụ thể của bên thuê Tạo báo cáo là một yêu cầu chung với tất cả các giải pháp. IBM Cognos Business Intelligence (BI) cung cấp các khả năng truy vấn và tạo báo cáo toàn diện cho phép người dùng tạo ra các báo cáo và phân tích dữ liệu để đưa ra các quyết định kinh doanh tốt hơn. Ngoài ra, Cognos BI là một nền tảng đã được chứng tỏ có thể hoạt động trong một môi trường nhiều bên thuê, nơi tài nguyên có thể được chia sẻ giữa nhiều khách hàng. Cognos BI tạo nhóm các báo cáo và siêu dữ liệu báo cáo với các cấu trúc thư mục. Một báo cáo có thể truy cập dữ liệu cần thiết của mình bằng cách sử dụng một đối tượng kết nối nguồn dữ liệu xác định các tham số vị trí và truy cập cho các dữ liệu được hiển thị trong báo cáo. Trong một môi trường nhiều bên thuê trong đó tất cả các bên thuê chia sẻ chỉ một cá thể của Cognos BI, sự cách ly giữa các bên thuê có thể đạt được bằng cách tạo các kết nối nguồn dữ liệu và các thư mục cụ thể của bên thuê. Những người dùng của bên thuê chỉ có thể truy cập các kết nối nguồn dữ liệu và các thư mục được tạo ra cho bên thuê đó. Điều này bảo đảm sự cách ly giữa các bên thuê để họ không thể xem dữ liệu hay các báo cáo của nhau. IBM Cognos Software Development Kit (Bộ công cụ phát triển phần mềm Cognos của IBM) cho phép một nhà phát triển dễ dàng kích hoạt nhiều bên thuê và tích hợp các chức năng Cognos vào các ứng dụng nhiều bên thuê riêng của mình. Ví dụ, khi một bên thuê mới đăng ký, một trình xử lý kích hoạt có thể truy cập Cognos BI một cách trong suốt bằng cách thực hiện một cuộc gọi dịch vụ web để tạo ra một thư mục và một kết nối nguồn dữ liệu mới có thể nhìn thấy được chỉ với bên thuê này. Các tệp bản ghi nhật ký cụ thể của bên thuê
Do bây giờ các bên thuê đang chia sẻ cùng một phần mềm trung gian, nên điều quan trọng là xem xét cách tách các tệp bản ghi nhật ký cho mỗi bên thuê để cho một bên thuê chỉ có thể xem những thông báo ghi nhật ký do các việc thực hiện riêng của mình tạo ra. Việc tách rời các tệp dò vết và các tệp bản nhật ký của bên thuê sẽ giúp các quản trị viên SaaS khắc phục các vấn đề cụ thể cho một tài khoản cu thể. Các tệp bản ghi nhật ký cụ thể của bên thuê có thể được tạo ra bằng các khung công tác ghi nhật ký WebSphere mở rộng dễ dàng. Ngoài ra, mỗi sản phẩm sẽ có cấu trúc thư mục khác nhau, do đó, các vị trí của tệp bản ghi nhật ký có thể khác nhau giữa các sản phẩm. Đối với mỗi sản phẩm phần mềm, một tiện ích của trình tập hợp bản ghi nhật ký có thể gộp các tệp bản ghi nhật ký lại với nhau vào trong một kho lưu trữ riêng của một bên thuê. Giao diện người dùng thống nhất qua WebSphere Portal WebSphere Portal có thể cung cấp một cách trình bày thống nhất cho các thành phần, các ứng dụng, các qui trình và nội dung khác nhau cần được tích hợp trong một giải pháp SOA. Ví dụ, như trong Hình 2, có thể thực hiện một trải nghiệm đăng nhập một lần thống nhất thông qua WebSphere Portal để cho sau khi người dùng đăng nhập vào cổng thông tin, tất cả các ứng dụng cơ bản có thể được truy cập mà không cần phải nhập lại ID và mật khẩu người dùng. Ngoài ra, chúng tôi đã thấy các khả năng sau từ WebSphere Portal đặc biệt có ích để tạo ra các ứng dụng SaaS nhiều bên thuê:  Các portlet của mô hình thành phần của cổng thông tin cho phép bạn tạo ra các thành phần sử dụng lại có thể được sử dụng trong nhiều ứng dụng SaaS. Nó cung cấp một mô hình lập trình tiêu chuẩn để cho dễ dàng mở rộng một giải pháp SaaS bằng cách cung cấp các portlet tùy chỉnh riêng của mình đối với một bên thuê.  Với tuỳ chỉnh cổng thông tin, một bên thuê có thể tùy chỉnh giao diện người dùng với các lớp bên ngoài cụ thể của nó bằng cách thay đổi các bản định kiểu.  Truy cập tới các portlets dựa trên các vai trò. Khi thêm những người dùng cho một bên thuê, bạn có thể tự động cho phép nhưng người dùng truy cập vào các portlet thích hợp bằng cách thiết lập các vai trò tương ứng của chúng trong LDAP chia sẻ; ví dụ, các quản trị viên công ty so với doanh thu bán hàng của công ty.  Hỗ trợ thiết bị di động và nhiều thiết bị. Hầu hết các ứng dụng SaaS có thể được truy cập thông qua thiết bị di động. IBM Mobile Portal Accelerator (Bộ gia tốc Công thông tin di động của IBM) cho phép bạn hỗ trợ nhiều thiết bị nhanh chóng mà không đòi hỏi có bản quyền phụ thuộc vào thiết bị.  Hỗ trợ cho các trang trại cổng thông tin trong Phiên bản 7.0 của WebSphere Portal làm cho nó đặc biệt thích hợp để chạy trong một môi trường đám mây. Các trang trại cổng thông tin là hàng loạt các cá thể độc lập của các máy chủ cổng thông tin vận hành giống như một cụm truyền thống, nhưng dễ quản lý và mở rộng hơn. Bạn có thể tự động tăng lên và thu nhỏ quy mô của trang trại dựa trên nhu cầu về dung lượng.