D-Bus: Автобус за Linux
Вече е време да се мисли за зимни гуми или счупвания и изкълчвания? Върнете се към виртуалния свят - Андрю Borovsky има предвид автобуса за обмен на данни между десктоп приложения!
Какво е D-Bus? Простият отговор - друг вътрешнопроцесна комуникационна система (комуникация между процесите или IPC). Ключовите думи тук са "още една." IPC системи по-високо ниво за Unix / Linux, има много. В допълнение към системите за високо ниво Unix IPC е разработил средства за ниско ниво (контакти, канали), което се използва успешно в много приложения директно. Защо, тогава, може да се наложи да се D-Bus? Тази система е замислена като средство FreeDesktop.org група IPC, а не в зависимост от вида на работния плот, предназначена да замени както DCOP в KDE и CORBA / Bonobo в GNOME. Разместете родния означава IPC KDE и GNOME новата система все още не е [истината, KDE 4 D-Bus ще продължи да се използва вместо DCOP, - ок. Ед. ] Но в развитието на D-Bus е намерил някои уникални и полезни функции. Важна особеност на D-Bus сигнали са асинхронни система и извикване на метод, както и прилагането на система за контрол на приложения. По този начин, отговорът на въпроса, защо може да се наложи програмиране D-Bus, се състои от две части. На първо място, много важни приложения и компоненти на системата (например Linux HAL и NetworkManager) с помощта на D-Bus като средство за комуникация с външния свят. На второ място, D-Bus - е платформено независима система IPC, която присъства в почти всяка Linux дистрибуция и е инсталиран по подразбиране в много от тях. Ето защо, ако пишете приложение, което трябва да осигури IPC услуги, които не са част от всеки настолен и сигурно ще има смисъл да се обърне внимание на D-Bus. Тя трябва да се вземат предвид недостатъците на D-Bus. Системата все още не се реализира връзката между различни машини, въпреки че работата в тази посока е в ход. D-Bus може лесно да се пренесе към други платформи, за Unix, но версията си за Windows все още е далеч от приключване.
Сред конкурентните технологии (в смисъл, че те често могат да бъдат използвани вместо D-Bus), следва да се отбележи CORBA, SOAP, XML-RPC, DCOM, DCOP, Bonobo. D-Bus е различен от тях? CORBA, както и D-Bus, използва висока двоичен протокол. В контраст, D-Bus, CORBA разтвори, предназначени за изключително широк спектър на приложение и може да се използва като локален и разпределена система. В CORBA няма такива елементи D-Bus, системата за контрол използвате приложения и сигнализация. SOAP и XML-RPC е протокол, в който на ниско ниво се използва широко XML. Тези технологии комуникация между процесите, подходящ за интернет, но обменът на данни между приложения, работещи на същата машина, използването на XML механизми води до загуба на ресурси (в този случай следва да се отбележи, разбира се, че приложенията, които използват тези протоколи, той е изключително лесно да мащабирате). Технология DCOM, DCOP и Bonobo имат подобен недостатък - всеки, предназначени за конкретен платформа (Windows, KDE и GNOME съответно), както и за организиране на взаимодействието между приложения в множество платформи с тяхна помощ ще бъде много трудно.
D-Bus интерфейс на клиент Skype на
Може би сте забелязали, че по заявление по образец, която предоставя услуги D-Bus, ние се позоваваме на клиента Skype. Интерфейсът изнесени от клиент Skype е много прост и в същото време показва всички от основните характеристики на D-Bus. Обект / COM / Skype поддържа само един метод - Invoke. позволява на външни приложения да изпращат команди към клиента Skype. Единственият аргумент, да се позове на команден ред, а стойността на връщане - низ, който съдържа отговора на програма за предава команда. Въпреки това, Skype клиент може не само да изпълнява команди приложения на трети страни, но и да ги предават на разнообразна информация, като например как да се свържете на новия потребител. За да получавате съобщения от клиент Skype на. заявлението трябва да се регистрирате клас / COM / Skype / Client. Когато клиентът Skype иска да информира заявлението за нещо, го нарича Уведоми метод клас / COM / Skype / Client. преминаване в един параметър на този метод е съобщение низ. Уведоми метод не връща стойност.
Малко по-малко за архитектура
база структурата на D-Bus е понятие шина (автобус). Автобусът е механизмът, чрез който процесите на комуникация. Въпреки че по принцип всеки две процеси могат да се организират "частни" автобусни D-Bus средства и обмен на данни помежду си, гума обществен интерес, който поддържа демон D-Bus. Daemon изпълним файл има име на DBUS-демон. Обикновено, ако демонът D-Bus трябва да се управлява ръчно, с помощта на DBUS старта команда.
Demon D-Bus ни дава два автобуса: системна шина (системна шина) и потребител на автобус (сесия автобус). Системната шина може да се използва за прехвърляне на данни в системата, докато потребителското автобус може да прехвърля данни между процеси, принадлежащи на един потребител. Трябва да се отбележи, че D-Bus гарантира правата на потребителите в системата и не позволява да се прекъсне политиката за сигурност на Linux с помощта на автобуса система.
Всички процеси, използващи D-Bus за комуникация, действат като клиенти, които се свързват с демон D-Bus и по този начин да получат достъп до една от гумите. Това трябва да се помни, наред с други неща, за да се избегне объркване в терминологията. Свързани с автобус, всеки процес прави връзка (демон D-Bus). Всяка връзка има име (който е посочен от условията на името на оригиналния литература връзка и името на автобус). Имената на съединенията, са сходни с имената на уеб сайтове, които са обърнати наопаки. Например, HAL мениджър създава връзка с името org.freedesktop.Hal. клиент Skype - най com.Skype.API име. Тъй като всички приложения, които използват системата или потребител автобус D-Bus, са свързани с демона D-Bus, но не един с друг, че е възможно да се използва едно съединение D-Bus за комуникация между различни приложения.
Ако се изкачи с едно ниво на абстракция, ще видим какво е сходството между обектите D-Bus и обектно-ориентирани обекти. Съобщения модел "-отговор" може да се разглежда като предизвикателство за метод на обекта, в който съобщението за заявка се подава на параметрите на метода и съобщение за отговор - стойностите връщане. Той призова семантика методи, използвани за образуване съобщения за искане и получаване на отговори D-Bus.
От базата на обект призовава методи D-Bus се съобщения, има възможност на асинхронни повикване. Като се позовава на метод обект D-Bus, програмата може да извършва действие, без да чака отговор. Един дори може да доведе до друг метод обект преди е била получена в резултат на друг разговор. Публикации сигнали най-лесно да се сравнят с Qt сигнали.
Въпреки че не може да работи с D-Bus обекти директно, системата предоставя програмисти obektopodobny интерфейс, който се осъществява с помощта на така наречените пълномощници (прокси обекти). Пълномощникът може да се счита за обект представител на D-Bus в програмата си. Как прокси обект е подобен на "истинския" - е зависимо от конкретната реализация. В Java и Python работи с прокси извършва по същия начин, както и с "истински" обекти на езика. При използване на GLib интерфейс библиотека за работа с прокси използва специален набор от функции.
Позовавайки се на D-Bus обекти на всяко приложение, което очаквате, че най-малко един вариант на приложението работи на системата. И какво, ако не е? Беше отбелязано по-горе, че системата за D-Bus може да контролира изпълнението на заявката. Demon D-Bus може да започне прилагането на вашата заявка (за това, разбира се, заявлението трябва да бъдат регистрирани по специален начин в системата). Този механизъм е известен под името D-Bus активиране.
Включете се!
В основата на ниско ниво D-Bus API за да представлява два обекта - DBusConnection и DBusMessage. Първият обект капсулира всичко, което е свързано с контрол автобус D-Bus, което позволява на втория съобщенията контрол. Още веднъж ви напомня, че когато говорим за D-Bus API обекти, не става дума за обектите в смисъл на обектно-ориентиран, но за обектите в стила на GTK + API (D-Bus интерфейс за програмиране като цяло е много подобен на Приложен програмен интерфейс GTK +).
Следният код е минималната програма, като се използва възможността за D-BUS.
След установяване на връзка с автобус, което наричаме обект на друго приложение. Извикването на метода се състои от четири стъпки: създаване на съобщение поискване, да създадете списък с аргументи на метода се нарича, съобщения и се обадете на обработване на резултатите.
метод поискване след обаждане създава dbus_message_new_method_call (функция). четири Нейните аргументи са имената на дистанционното за кандидатстване връзки, обекта, интерфейс и да се обаждат на метода, съответно. Функцията връща указател към създадения обект го DBusMessage. който съдържа информация за нов разговор. Тъй като генерира съобщение е предназначено за извикване на метод, ние трябва да се създаде списък на своите аргументи. Това се извършва чрез dbus_message_append_args (функция). Първият аргумент на тази функция - указател към DBusMessage на обекта. Това е последвано от променлив брой параметри, които преминават на аргументите на нареченият метод. Всеки аргумент съответства на две функции на dbus_message_append_args на параметрите (). Първият параметър предава постоянно за вида на спора във втория - показалеца място в паметта, която съхранява стойността. Усъвършенстването на списъка с аргументи постоянна DBUS_TYPE_INVALID. Тъй като нашият метод, наречен Invoke един параметър, минаваме dbus_message_append_args () списък на три аргумента. DBUS_TYPE_STRING аргумент определя типа на параметър Invoke. последвано от указател към стойността (в нашия случай - указател към променлива от тип Чар *), наричан по-нататък - списъкът на крайния маркер DBUS_TYPE_INVALID. Имайте предвид, че dbus_message_append_args функцията () - не е единственото средство за създаване на списък с аргументи. Ниско ниво на D-Bus интерфейс ни дава и останалите функции, които могат да генерират списък с елементи динамично, по време на изпълнение.
В тази работа на нашата програма е приключила. С dbus_message_unref на функциите () и dbus_connection_unref () казва системата, която сме създали обекти интерфейс D-Bus ние вече не са необходими, както и избрани от паметта им може да бъде освободен.
Мисля, че вече е знаел, че работи с D-Bus от API на ниско ниво не е много удобно. Не е изненадващо, програмистите са създали множество обвързващи D-Bus API за различни програмни езици и библиотеки. В момента D-Bus се поддържа в GTK + / GLib (трябва да се отбележи, че това е - най-проектирана котва), Qt 3 / Qt 4, Python, Java, Perl. Аз съм на работа автомати D-Bus за wxWidgets.
D-Bus автомати решаване три проблеми. На първо място, работи интеграцията на съобщение линия на D-Bus и целева платформа. На второ място, обектен модел D-Bus API ще се вижда в модела на обекта, приета на целевата платформа. На трето място, методите са за използване с D-Bus прокси като "местни" обекти. Но всичко това е съвсем друга история. LXF
Свързани статии