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 các giao 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ậpmộtSLA, người dùng vànhà cung cấpcó thểtiến hành thỏa thuậnđể xác địnhnhằmđịnh rõvà đo lường các tham số trong QoS của người dùngvà những phần thưởnghay hình phạttương ứng. Thời hạn thể hiện trong negotiation strategyđược sử dụngbởi một đối tácđể quyết địnhnhà cung cấphoặc người tiêu dùngnào đáp ứngnhu cầu của mìnhtốt nhất. Negotiation protocolđại diện choviệc trao đổicác thông điệptrong quá trìnhthỏa thuận.Gần đây, nhiềunhà nghiên cứu đãđề xuấtnhiều cách thức và chiến lượckhác nhauđể thỏa thuậnSLAtrongGrid.Tuy nhiên, những điều này khôngnhữngcho rằngcácbên liên quantrongquá trình thỏa thuậnhiểumộtcách thứcthỏa thuận chung mà còncũng giả định rằnghọ chia sẻnhận thức chungvềhàng hoá,dịch vụ theothỏa thuận.Nhưngtrongthực tế, một người tham giacó thể thỏa thuậnvà thích sử dụng giao thứcnào đó hơn những người khác(mà nó có chiến lượcphát triểntốt hơn).
Nhưthể hiện trong hình8, mỗimeta-negotiationđược xác địnhbằng các tài liệumeta- negotiation mà các bêntham gia có thểthể hiện là: điều kiện tiên quyếtđểthỏa mãnchomột thỏa thuận, chẳng hạn nhưmộtphương pháp xác thựccụ thểđược yêu cầu hoặcđiều kiệnhọ 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ứcthỏa thuận vàcác ngôn ngữvề tài liệuchocácđặc điểm kỹ thuậtcủa SLA(ví dụ Web Service Level Agreement (WSLA) hay WS-Agreement) (xemdòng11-15); vàđiều kiệnchoviệc thành lập mộtthỏa thuận, chẳng hạn nhưmộttrọng tài của bên thứ bađược yêu cầu(xem dòng 16-18).
Hình 8: tài liệu Meta-negotiation
Trước khivào meta-negotiation,một nhà cung cấpdịch vụphổ biến cácmô tả vàcác điều kiệnđược hổ trợ củagiao thứcthỏa thuậntrong bản đăng ký.Sau đó, người dùng dịch vụthực hiệntra cứutrêncơ sở dữ liệuđăng kýbằng cách gửitài liệuriêngcủa họmô tảcác thỏa thuận màhọ đang tìm kiếm. Registryphát hiện racác nhà cung cấpdịch vụ cóhỗ trợcác quá trìnhthỏa thuậnngười dùngđangquan tâm vàtrả vềcác tài liệuđược công bố bởicác nhà cung cấpdịch vụ. Cuối cùng,sau khimột nhà cung cấpdịch vụ thích hợpvàmột giao thứcthỏa thuậnđược lựa chọnbởi người dùngqua sử dụngchiến lược lựa chọnriêng của mình, quá trình thỏa thuậngiữa họ có thểbắt đầutheo các điều kiệnquy địnhtrongvăn bảncủa nhà cung cấp.
Trongkiến trúcmeta-negotiation(như trong hình. 9), vai trò cung cấp dịch vụđược thực hiện bởiAnekalà mộthệ thốngquản lý tài nguyênhướng dịch vụdựa trên công nghệ .NET. GridbusBrokerhoạt động nhưdịch vụngười dùng và bản đồcông việcvớinguồn tài nguyênthích hợpbằng cách xem xétnhững hạn chếkhác nhautheo quy địnhvềyêu cầu chức năng(functional) vàphi chức năng (non-functional).Yêu cầu chức năngbao gồmgiới hạncông việcvàphụ thuộc dữ liệu, chẳng hạn nhưmột chuỗi cáccông việc cần thiếtđể thực thi mộtứng dụng cụ thể. Yêu cầu phichức năngbao gồmcác tham số QoS, chẳng hạn nhưhạn chếngân sáchvàthời hạnthực thi.Các nhà môi giớicó thể đảm bảoyêu cầuthời hạncho người sử dụngcuối chỉ khi nócó khả nănglưu giữcác núttrênnguồn tài nguyêncó trước. Vì vậy, về mặt nàycác chức năngmôi giớinhưmộtngười dùngyê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ếmcho các tài liệumeta- negotiationđược tạo ra bởinhững người tham gia. Hiện nay, nó được thực hiện như mộtcơ sở dữ liệuPostgreSQLvớimột dịch vụ webkế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 đượclưu trữ trênmột nhà cung cấpdịch vụnhư AmazonS3hoặcGoogle App Engine. Khi một tài liệumeta-negotiationđược phổ biến,registrygán cho nó mộtđịnh danh duy nhất(ID) sau đó tài liệu này có thểđược sử dụngcho các hoạt độngtiếp theo.Cáctruy vấnsẽ thử tìm tất cảcác tài liệutrongkho lưu trữphù hợpvới cáctài liệuđược cung cấpnhưcáctham số.Nó trả về mộtmảngcác IDcủacác tài liệu nàycho người yêu cầuđể họ chọn lựa.
MNMtạo điều kiện choviệc phổ biếncác tài liệumeta-negotiation vào bản đăng ký vàviệc tích hợp nền tảngmetanegotiationvàocácclient hiện cóhoặccơ sở hạ tầngdịch vụ, chẳng hạn nhưthỏa thuậnhoặc bảo mật của khách hàng.Ngoài việc là mộtkhách hàngcho phổ biếnvà truy vấntài liệumeta-negotiation(bước 1 và 2 trong hình9),MNMcòn cung cấpthông tin cần thiếtcho khách hàng hiện đang thỏa thuận, ví dụ nhưthông tinvề việc thành lậpcácphiên thỏa thuận(Bước 4) và các thông tincần thiết đểbắt đầuquá trình thỏa thuận(Bước 5). Nhưthể hiện trong hình9, mỗingười dùngdịch vụ có thểthỏa thuận đồng thời vớinhiều nhà cung cấpdịch vụ hay ngược lại các nhà cung cấpsẽ đàm phánvới nhiềungười dùng.
Sau khitruy vấnregistryvà áp dụngmột chiến lượcdựa trên khách hàngchoviệc lựa chọn cácdịch vụ phù hợp, các thông tin từtài liệumeta-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àocácphần mềmkhách hàng hiện cósử dụngmột nền tảngliên kết phụ thuộc (dependency injection)như Spring. Liên kết phụ thuộc theo phương pháp Inversion of Controltrong đó cácphần mềmđược cấu hìnhtrong thời gian chạyđể gọidịch vụđược phát hiệntự động, chứ không phải làđược biết đếnvàtham khảotrước. Điều nàylàphù hợptrong bối cảnhmeta-negotiation, trong đó người tham giaphát hiện ranhững người kháctrong thời gian chạythông qua bản đăng kývàcóđể tự độngđiều chỉnhdựatrêncác giao diệnđược cung cấp bởiđối táccủa mình (thường là thông qua một tài liệu WSDL).
10. Tạo ra các dịch vụ đám mây của bên thứ 3: Nội dung chuyển giao trên cácdịch vụ lưu trữ đám mây