Meta-Negotiation Middleware (MNM) đại diện cho nguyên mẫu đầu tiên thực hiện việc thành lập trao đổi đám mây toàn cầu và cơ sở hạ tầng thị trường cho các dịch vụ thương mại. MNM làm cầu nối giữa giao các diện dịch vụ độc quyền khác nhau và chiến lược thỏa thuận khác nhau được sử dụng bởi các nhà cung cấp dịch vụ và người dùng.
Trước khi thiết lập một SLA, người dùng và nhà cung cấp có thể tiến hành thỏa thuận để xác định nhằm định rõ và đo lường các tham số trong QoS của người dùng và những phần thưởng hay hình phạt tương ứng. Thời hạn thể hiện trong negotiation strategy được sử dụng bởi một đối tác để quyết định nhà cung cấp hoặc người tiêu dùng
nào đáp ứng nhu cầu của mình tốt nhất. Negotiation protocol đại diện cho việc trao đổi
các thông điệp trong quá trình thỏa thuận. Gần đây, nhiều nhà nghiên cứu đã đề xuất nhiều cách thức và chiến lược khác nhau để thỏa thuận SLA trong Grid. Tuy nhiên, điều này không những cho rằng các bên liên quan trong quá trình thỏa thuận hiểu một cách thức thỏa thuận chung mà còn cũng giả định rằng họ chia sẻ nhận thức chung về hàng hoá, dịch vụ theo thỏa thuận. Nhưng trong thực tế, một người tham gia có thể thỏa thuận và thích sử dụng giao thức nào đó (có chiến lược phát triển tốt hơn) hơn những người khác.
Như thể hiện trong hình 8, mỗi meta-negotiation được xác định bằng các tài liệu
meta-negotiation mà các bên tham gia có thể thể hiện là: điều kiện tiên quyết để thỏa mãn cho một thỏa thuận, chẳng hạn như một phương pháp xác thực cụ thể được yêu cầu hoặc điều kiện họ muốn thỏa thuận (ví dụ: thời gian, giá cả, độ tin cậy) (xem dòng 2-9); các giao thức thỏa thuận và các ngôn ngữ về tài liệu cho các đặc điểm kỹ thuật của SLA (ví dụ Web Service Level Agreement (WSLA) hay WS-Agreement) (xem dòng 11-15); và điều kiện cho việc thành lập một thỏa thuận, chẳng hạn như cần một trọng tài của bên thứ ba (xem dòng 16-18).
Hình 8: tài liệu Meta-negotiation
Trước khi vào meta-negotiation, một nhà cung cấp dịch vụ phổ biến các mô tả và
các điều kiện được hổ trợ của giao thức thỏa thuận trong bản đăng ký. Sau đó, người dùng dịch vụ thực hiện tra cứu trên cơ sở dữ liệu đăng ký bằng cách gửi tài liệu riêng của họ mô tả các thỏa thuận mà họ đang tìm kiếm. Registry phát hiện ra các nhà cung cấp dịch vụ có hỗ trợ các quá trình thỏa thuận người dùng đang quan tâm và trả về các tài liệu được công bố bởi các nhà cung cấp dịch vụ. Cuối cùng, người dùng chọn một nhà cung cấp dịch vụ thích hợp và một giao thức thỏa thuận bằng cách sử dụng chiến lược lựa chọn riêng của mình, quá trình thỏa thuận giữa họ có thể bắt đầu theo các điều kiện quy định trong văn bản của nhà cung cấp.
Trong kiến trúc meta-negotiation (như trong hình 9), vai trò cung cấp dịch vụ được
thực hiện bởi Aneka là một hệ thống quản lý tài nguyên hướng dịch vụ dựa trên công nghệ .NET. Gridbus Broker hoạt động như dịch vụ người dùng và bản đồ công việc với nguồn tài nguyên thích hợp bằng cách xem xét những hạn chế khác nhau theo quy định về
yêu cầu chức năng (functional) và phi chức năng (non-functional). Yêu cầu chức năng
bao gồm giới hạn công việc và phụ thuộc dữ liệu, chẳng hạn như một chuỗi các công việc cần thiết để thực thi một ứng dụng cụ thể. Yêu cầu phi chức năng bao gồm các tham số QoS, chẳng hạn như hạn chế ngân sách và thời hạn thực thi. Các nhà môi giới có thể đảm bảo yêu cầu thời hạn cho người sử dụng cuối chỉ khi nó có khả năng lưu giữ các nút trên nguồn tài nguyên có trước. Vì vậy, về mặt này các chức năng môi giới như một người dùng yêu cầu đặt chổ từ nhà cung cấp.
Hình 9: Kiến trúc của meta-negotiation giữa Aneka Cloud và Client
Bản đăng ký (registry) là một kho lưu trữ tìm kiếm cho các tài liệu meta- negotiation được tạo ra bởi những người tham gia. Hiện nay, nó được thực hiện như một cơ sở dữ liệu PostgreSQL với một dịch vụ web kết thúc trước đó cung cấp giao diện để truy cập vào registry. Tuy nhiên, có thể lưu trữ các đăng ký bằng cách sử dụng cơ sở dữ liệu đám mây được lưu trữ trên một nhà cung cấp dịch vụ như Amazon S3 hoặc Google
App Engine. Khi một tài liệu meta-negotiation được phổ biến, registry gán cho nó một
định danh duy nhất (ID) sau đó tài liệu này có thể được sử dụng cho các hoạt động tiếp theo. Các truy vấn sẽ thử tìm tất cả các tài liệu trong kho lưu trữ phù hợp với các tài liệu được cung cấp như các tham số. Nó trả về một mảng các ID của các tài liệu này cho người yêu cầu để họ chọn lựa.
MNM tạo điều kiện cho việc phổ biến các tài liệu meta-negotiation vào bản đăng
ký và việc tích hợp nền tảng metanegotiation vào các client hiện có hoặc cơ sở hạ tầng dịch vụ, chẳng hạn như thỏa thuận hoặc bảo mật của khách hàng. Ngoài việc là một khách
hàng cho phổ biến và truy vấn tài liệu meta-negotiation (bước 1 và 2 trong hình 9), MNM
còn cung cấp thông tin cần thiết cho khách hàng hiện đang thỏa thuận, ví dụ như thông tin về việc thành lập các phiên thỏa thuận (Bước 4) và các thông tin cần thiết để bắt đầu quá trình thỏa thuận (Bước 5). Như thể hiện trong hình 9, mỗi người dùng dịch vụ có thể thỏa thuận đồng thời với nhiều nhà cung cấp dịch vụ hay ngược lại các nhà cung cấp sẽ đàm phán với nhiều người dùng.
Sau khi truy vấn registry và áp dụng một chiến lược dựa trên khách hàng cho việc
lựa chọn các dịch vụ phù hợp, các thông tin từ tài liệu meta-negotiation của dịch vụ được
phân tích. Sau đó, các thông tin meta-negotiation được kết hợp vào các phần mềm khách
hàng hiện có sử dụng một nền tảng liên kết phụ thuộc (dependency injection) như Spring.
Liên kết phụ thuộc theo phương pháp Inversion of Control trong đó các phần mềm được cấu hình trong thời gian chạy để gọi dịch vụ được phát hiện tự động, chứ không phải là
được biết đến và tham khảo trước. Điều này là phù hợp trong bối cảnh meta-negotiation,
trong đó người tham gia phát hiện ra những người khác trong thời gian chạy thông qua bản đăng ký và có để tự động điều chỉnh dựa trên các giao diện được cung cấp bởi đối tác của mình (thường là thông qua một tài liệu WSDL).