2.1.1. động lực
Trong phạm vi một hệ thống máy tắnh, có một khoảng cách giữa phần mềm quản lý và các thành phần của hệ thống yêu cầu quản lý. Việc quản lý phải hiểu làm thế nào ựể thao tác với thông tin về số sản phẩm liên tục gia tăng. để các sản phẩm có thể quản lý ựược, chúng ta phải biết những rắc rối của cơ chế mã hóa phức tạp và lược ựồ ựăng ký. Sự sắp xếp này là không mong muốn từ cả hai phắa.
DMI ựược thiết kế ựể nhằm ựạt các yêu cầu sau: - độc lập của một máy tắnh hoặc hệ ựiều hành cụ thể. - độc lập của một giao thức quản lý cụ thể.
- Có khả năng tương thắch cao với các hãng cung cấp. - Có thể sử dụng cục bộ khi không có mạng.
- Có thể sử dụng qua mạng bằng các giao thức truyền thông RPC/DCE, ONC/RPC hoặc TI/RPC.
- Có thể tương tác với các giao thức quản lý mạng hiện tại (vắ dụ CMIP, SNMP).
Giao diện DMI theo thủ tục ựược thiết kế ựặc biệt ựể truy cập từ xa thông qua việc sử dụng các thủ tục ựiều khiển. Các RPCs hỗ trợ của DMI bao gồm:
DCE/RPC, ONC/RPC, TI/RPC.
2.1.2. Các yếu tố của DMI
DMI có bốn yếu tố:
1. Một ựịnh dạng ựể mô tả thông tin quản lý. 2. Một thực thể cung cấp dịch vụ.
3. Hai bộ API, một bộ cho nhà cung cấp dịch vụ và chương trình quản lắ, bộ khác cho nhà cung cấp dịch vụ và các thành phần.
4. Một tập các dịch vụ ựể phục vụ việc ựiều khiển từ xa.
Mô tả thành phần ựược ựịnh nghĩa trong một ngôn ngữ ựược gọi là ựịnh dạng thông tin quản lý (viết tắt là MIF). Mỗi thành phần có một file MIF ựể mô tả các ựặc ựiểm quản lý của nó. Khi một thành phần ựược cài ựặt ban ựầu vào hệ thống, MIF ựược thêm vào cơ sở dữ liệu MIF.
Nhà cung cấp dịch vụ DMI ựưa ra một tập hợp các ựiểm vào có thể ựược gọi bởi CISTR. đây là tập hợp tên gọi mà các API của Modul cung cấp ựưa ra cho các thành phần. Tương tự như vậy, modul mã của CISTR ựưa ra tập hợp các ựiểm truy nhập có thể ựược gọi bởi các nhà cung cấp dịch vụ DMI. đây là những tập hợp các tên gọi mà các API hợp phần cung cấp.
Giao diện thành phần CI (Component Interface), ựược sử dụng bởi các Modul cung cấp dịch vụ, mô tả cách truy cập vào thông tin quản lý. Các CI và MIF che ựi sự phức tạp của các kiểu mã hóa và thông tin ựăng ký. Người ta không cần phải tìm hiểu chi tiết các giao thức quản lý phổ biến hay mới.
Các phiên bản trước của ựặc tả kỹ thuật này ựịnh nghĩa CI là một giao diện hướng khối dữ liệu, trái ngược với một giao diện hướng thủ tục của phiên bản mới. đặc tả kỹ thuật này giới thiệu một giao diện CI thủ tục mới. Tất cả các chức năng ựược giới thiệu trong ựặc tả này là một phần của CI thủ tục mới.
Chú ý rằng các chức năng trong giao diện thành phần hướng hệ ựiều hành cụ thể. Một số hệ ựiều hành không thể thực hiện các CI nhưng cung cấp chức năng tương ựương bằng cách sử dụng cơ chế mã nguồn gốc.
Nhà cung cấp dịch vụ DMI cũng ựưa ra một tập hợp các ựiểm truy nhập có thể ựược gọi bởi ứng dụng quản lý. đây là những tập hợp tên gọi mà API của nhà cung cấp dịch vụ DMI cung cấp các ứng dụng quản lý. Tương tự như vậy, ứng dụng quản lý cũng ựưa ra một tập hợp các ựiểm truy nhập có thể ựược gọi bởi các nhà cung cấp dịch vụ DMI. đây là tập hợp tên gọi có thể gọi bởi các API của DMI.
Giao diện quản lý MI (Management Interface) ựược sử dụng bởi các ứng dụng có nhu cầu quản lý các thành phần. Thông qua MI, mặc dù các nhà cung cấp ứng dụng quản lý với các cơ chế khác nhau vẫn có thể có ựược thông tin quản lý từ các thành phần trong một hệ thống máy tắnh.
Các phiên bản trước ựây MI là giao diện hướng khối dữ liệu. đặc ựiểm kỹ thuật này giới thiệu một giao diện MI mới hướng thủ tục. Tất cả các chức năng mới ựược giới thiệu bởi ựặc tả kỹ thuật này chỉ là một phần của MI thủ tục mới.
MI hướng thủ tục mới là một giao diện truy nhập từ xa, hỗ trợ RPCs. Nhà cung cấp dịch vụ DMI, trước ựây ựược gọi là lớp dịch vụ, là một chương trình thường trú chạy trên một hệ thống máy tắnh, ựây là chương trình làm nhiện vụ trung gian giữa MI và CI và thực hiện dịch vụ ựại diện cho MI và CI.
Sơ ựồ khối chức năng ựược hiển thị trong Hình 2-1.
Phiên bản DMI 1.1 giao diện hướng khối MI và CI là giao diện cục bộ, ựược sử dụng trong một hệ thống duy nhất. MI hướng thủ tục mới là một giao diện truy nhập từ xa sử dụng các thủ tục ựiều khiển. CI hướng thủ tục mới là một giao diện cục bộ, ựược sử dụng trong một hệ thống duy nhất.
Trong Hình 2 -1, tất cả các thành phần như phần cứng và phần mềm, cơ sở dữ liệu MIF, và nhà cung cấp ựịch vụ DMI có thể tồn tại trong một hệ thống duy nhất, hoặc trực thuộc, chẳng hạn như máy in hoặc modem.
Lưu ý: Là hợp lệ cho các CISTR ựăng ký thường trú hoặc tạm thời như là một ứng dụng MI bên cạnh việc ựăng ký CI. điều này thường ựược sử dụng bởi các thành phần như là một phương tiện tự ựộng lấy ID thành phần hiện tại ở thời gian chạy từ nhà cung cấp dịch vụ DMI.
Hình 2.1. Sơ ựồ khối chức năng.
2.1.3. Mô hình dữ liệu
Các thành phần có một hoặc nhiều thuộc tắnh có tên chung xác ựịnh các thông tin có sẵn cho một ứng dụng quản lý. Các thuộc tắnh ựược thu thập vào nhóm ựược ựặt tên ựể dễ tham khảo. Các nhóm có thể vô hướng hoặc có thể là ựa thể hiện, chẳng hạn như tập hợp các thuộc tắnh cho mỗi thể hiện của một bảng giao diện mạng. Nhóm nhân khởi tạo ựược gọi là bảng, một hàng của một bảng ựược gọi bằng một tập hợp các thuộc tắnh hình thành một chìa khóa. Vì vậy trong một hệ thống có rất nhiều thành phần, với một hoặc nhiều nhóm. Mỗi nhóm có một hay nhiều thuộc tắnh và mỗi nhóm có thể ựược khởi tạo như một bảng. Các CISTR trình bày thành phần / nhóm / khóa / thuộc tắnh này cho các ứng dụng quản lý. Sơ ựồ ựược thể hiện trong Hình 2-2.
Thành phần thiết bị có thể ựáp ứng với yêu cầu của ứng dụng quản lý và có thể cung cấp thông tin không cần gửi yêu cầu.
Hình 2.2. Sơ ựồ của ựại diện thuộc tắnh Mô hình dữ liệu.
Các mối quan hệ giữa các ứng dụng quản lý, Nhà cung cấp dịch vụ DMI và CISTR có thể tồn tại như mối quan hệ một nhiều-một-nhiều. Có thể có nhiều ứng dụng quản lý phát hành các lệnh thông qua một nhà cung cấp dịch vụ DMI duy nhất ựể quản lý nhiều thành phần. Nếu ứng dụng quản lý nhiều hoạt ựộng, hỗ trợ bởi các ngôn ngữ khác nhau, ựòi hỏi CISTR hỗ trợ nhiều ngôn ngữ cùng một lúc.
Ứng dụng quản lý phải ựăng ký với nhà cung cấp dịch vụ DMI trước khi có thể tham gia vào chức năng quản lý. Khi lần ựầu tiên ựưa vào hệ thống, các CISTR phải cài ựặt vào nhà cung cấp dịch vụ DMI. Các cơ chế của "kết nối" ựể các nhà cung cấp dịch vụ DMI ựăng ký hoặc ban hành các lệnh có thể khác nhau giữa các hệ thống ựiều hành và triển khai nhà cung cấp dịch vụ DMI.
Kiểm soát luồng thông tin thường bắt ựầu từ các ứng dụng quản lý tới nhà cung cấp dịch vụ DMI và các CISTR. Luồng các chỉ dẫn, báo cáo theo hướng ngược lại.
Có ba loại lệnh truy cập chắnh: Get, Set và List. Các lệnh Get và Set cho phép ứng dụng quản lý ựọc và viết các thực thể quản lý trong một hệ thống.
Các lệnh List trả lại "siêu" thông tin, thông tin về bản thân MIF thành phần. Các lệnh List không nhận ựược giá trị thuộc tắnh thực tế trong thành
phần. Các lệnh List cho phép ứng dụng quản lý có ựược các thông tin ngữ nghĩa trong MIF. Khi nhà cung cấp dịch vụ DMI nhận ựược thông tin MIF từ cơ sở dữ liệu MIF, các lệnh List không gây ra kắch hoạt bất kỳ mã nào của CISTR.
Cùng với các lệnh truy cập tiêu chuẩn này là các lệnh ựể ựăng ký / giải ựăng ký của các thực thể quản lý, và các lệnh tạo ra các chỉ dẫn do CISTR.
Trong cấu trúc dữ liệu DMI, tất cả các chuỗi ựược lưu trữ dưới dạng <length> <data>. <length> là giá trị 32-bit không dấu cho biết số lượng octet trong một phần của chuỗi. Lưu ý rằng số lượng ký tự trong chuỗi phụ thuộc vào ựịnh dạng ISO 8859-1 (1 octet / ký tự) hoặc ựịnh dạng Unicode (2 octet / ký tự.
Các CISTR ựược tái sử dụng nối tiếp nhau, nhưng sẽ không ựược tái vào lại.
DMI không cung cấp các hàm nguyên thủy ựể sở hữu hoặc khóa các tài nguyên trên một chuỗi các lệnh. Nhiều ứng dụng quản lý có thể truy cập ựồng thời các giao diện ựược mô tả trong tài liệu này. Phân nhóm và lập lịch hoạt ựộng là trách nhiệm của ứng dụng quản lý. Tương tự như vậy, bất kỳ mong muốn loại trừ lẫn nhau ựể khóa truy cập nhất ựịnh, hoặc cung cấp bảo mật cơ sở dữ liệu DMI dưới bất kỳ hình thức nào là trách nhiệm của các ứng dụng quản lý.
2.1.4. Giao diện truy nhập từ xa
Giao diện hướng khối dữ liệu ựược giới thiệu trong tháng tư năm 1994 với DMI phiên bản 1 (DMIv1.x), sử dụng một ựiểm vào duy nhất (DmiInvoke ') và cho thông qua một tập hợp các cấu trúc dữ liệu nối tiếp nhau. Tại thời ựiểm DMIv1.x ựược tạo ra, loại hình giao diện này ựược cho là cần thiết cho cấp ựộ truy cập thấp như khi cần chuyển mức bảo vệ trong một bộ xử lý, giao diện ựiều khiển thiết bị và ựể ựóng gói dễ dàng khi truy cập từ xa. Giao diện
truy nhập từ xa là giao diện hướng thủ tục trái ngược với giao diện hướng khối của DMIv1.x. Giao diện hướng thủ tục, ngoài việc phù hợp với truy cập từ xa thông qua một trong những cơ chế RPC ựược hỗ trợ ựịnh nghĩa trước ựó, rất thân thiện với lập trình viên và ắt bị lỗi hơn nhiều.
Các vấn ựề RPC ựược giới hạn cho việc mở và ựóng kết nối của phiên làm việc từ xa. Các vấn ựề về mạng lưới trung tâm như vận chuyển, phân giải tên, vv ựược cung cấp bởi các dịch vụ RPC ngoài phạm vi của ựặc tả kỹ thuật này.
Giao diện truy cập từ xa (DMIv2.0) ựược thiết kế ựể cung cấp truy cập từ xa vào chức năng và dữ liệu DMI ẩn ựi sự phức tạp của việc thao tác với các khối dữ liệu của phiên bản DMIv1.x. DMIv1.x thường gói các chức năng liên quan với nhau thành một lệnh duy nhất. Chắnh vì vậy, kết quả trả lại mang rất nhiều thông tin liên quan và yêu cầu người gọi phải trắch chọn ra các thông tin mong muốn. Trong phiên bản DMIv2.0, các lệnh gọi tách riêng từng chức năng ựể yêu cầu các thông tin cụ thể.
RPC dựa trên một kiến trúc client / server. Phắa khách hàng tạo một tập hợp các ựoạn mã (Stub) có giao diện cùng một chữ ký khi gọi chức năng ở trên máy chủ. Stub tương tác với RPC cục bộ ựể hỗ trợ cho trao ựổi các thông số ựầu vào, các thông số ựầu ra, mã số trở lại và với các thủ tục từ xa nằm ở máy chủ. Một nút từ xa hoạt ựộng như một khách hàng khi thực hiện các cuộc gọi chức năng thủ tục MI, và như một máy chủ khi nhận các chỉ báo. Các nút thuộc quyền quản lý hoạt ựộng như một máy chủ cho các cuộc gọi chức năng thủ tục MI, và như một khách hàng khi cung cấp chỉ báo cho một nút từ xa.
Hình 2-4 cho thấy kiến trúc tổng thể cho giao diện truy nhập từ xa. Lưu ý rằng CI là một giao diện cục bộ và không phải là truy cập từ xa. Triển khai cụ thể của ựặc ựiểm kỹ thuật này có thể thay ựổi phần nào trong cấu trúc thực
tế của các chương trình phần mềm.
Hình 2.4. Kiến trúc Giao diện truy nhập từ xa
Một số yếu tố của DMIv1.x không có mặt trong DMIv2.0. Khái niệm về khối lệnh nối tiếp nhau ựã ựược gỡ bỏ trong DMIv2.0. DMIv2.0 là một giao diện hoàn toàn ựồng bộ, trong khi DMIv1.x là không ựồng bộ. Bảo mật mức liên kết dữ liệu mới ựược ựưa vào DMIv2.0, ựược cung cấp bằng cách sử dụng cơ chế bảo mật cơ bản RPC.
2.1.5. An ninh
DMIv2.0s ựịnh nghĩa một cơ chế ựể kiểm soát truy cập từ xa vào giao diện quản lý DMI và các truy cập vào giao diện DMI. Các cơ chế kiểm soát truy cập từ xa ựược xác ựịnh trên cơ chế RPC tiêu chuẩn, trong khi cơ chế kiểm soát truy cập cục bộ ựược xác ựịnh trên cơ chế hệ ựiều hành. DMIv2.0s không chỉ ựịnh một ựịnh dạng tiêu chuẩn cũng không sử dụng hệ mật mã riêng mà dựa trên cơ chế bảo mật của RPC và hệ ựiều hành. Các tắnh năng chắnh ựược giới thiệu bởi DMIv2.0s là xác thực, ủy quyền dựa trên vai trò,
chắnh sách linh hoạt, chỉ dẫn an ninh và ựăng ký truy nhập. DMIv2.0s bảo mật là một phiên bản mở rộng của ựặc tả kỹ thuật DMIv2.0.
Mở rộng an ninh DMI là ựiều kiện cần thiết. đó là, nếu một nhà cung cấp dịch vụ DMI thực hiện cung cấp một cơ chế kiểm soát truy cập, nó phải thực hiện mở rộng an ninh DMI như ựược ựịnh nghĩa trong ựặc tả này ...
Lưu ý rằng DMI2.0s bảo mật là dựa trên cơ sở hạ tầng bảo mật ựược cung cấp bởi RPC và hệ ựiều hành. Do ựó, nếu an ninh của các RPC hoặc hệ ựiều hành bị tổn thương, an ninh của DMI2.0s cũng sẽ bị tổn hại. Vắ dụ, nếu một người sử dụng ựộc hại có thể phá vỡ an ninh hệ thống tập tin và thay ựổi cơ sở dữ liệu MIF trên một hệ thống, có thể thay ựổi chắnh sách DMI2.0s trong cơ sở dữ liệu ựể có lợi cho mình.
2.2. Giao diện thành phần CI
Giao diện thành phần (CI) là một giao diện tùy chọn cho phép các thành phần cần quản lý kết nối trực tiếp ựến Modul cung cấp dịch vụ. Lưu ý rằng khả năng cung cấp bởi giao diện này thường là ựặc trưng của phần mềm nền hay hệ ựiều hành cụ thể. Vì lý do này DMIF, cơ quan quản lý chịu trách nhiệm cho DMI, coi CI như là tùy chọn và vì thế không yêu cầu các thực thi phải tuân thủ mô hình DMI.
Trong phiên bản DMIv1.x, CI cung cấp các lời gọi cần thiết ựể một thành phần bị quản lý ựược cài ựặt hay gỡ bỏ từ modul nhà cung cấp dịch vụ DMI. Trong mô hình DMI hướng thủ tục, chức năng tương ựương ựược cung