Информационная структура современного бизнеса необыкновенно сложна и масштабна. Вычислительные сети, без которых невозможно не то что эффективная работа, а просто само существование компаний, становятся все больше - как по числу рабочих станций, так и по покрываемым географическим расстояниям; структура сетей постоянно усложняется - как с чисто топологической точки зрения, так и по числу используемых сетевых устройств и протоколов обмена информацией, часто весьма разнородных и не особенно совместимых между собой.
Глобальные сети не могут обойтись без дистанционного мониторинга
Появление корпоративных информационных сетей глобального масштаба ознаменовало собой новый этап в развитии сетевой инфраструктуры. Отличия сетей глобального масштаба от локальных сетей, на первый взгляд чисто количественное, на самом деле влечет к существенным качественным изменениям в самом подходе к проектированию и планированию структуры таких сетей. О каких отличиях тут идет речь?
Во-первых, в сетях глобального масштаба неизмеримо возрастает стоимость линий связи между отдельными локальными сетями, входящими в состав единой информационной системы компании. Стоимость линий связи напрямую (и очень сильно) зависит от их пропускной способности. Это, в частности, приводит к тому, что практически любые аппаратные или программные средства, приводящие к сокращению объема передаваемой по сети информации окупаются очень быстро.
Вторая важная отличительная черта сетей глобального масштаба - чрезвычайно широкое разнообразие используемого оборудования - как различных сетевых устройств, так и просто линий связи. В сетях глобального масштаба выбор конкретного оборудования часто определяется его доступностью на местном рынке, поэтому такие сети часто представляют собой настоящий конгломерат разнородных устройств. Что же касается линий связи, то тут часто и выбирать особенно не приходится - остается довольствоваться тем, что предлагает местная компания-провайдер.
Следующий момент - огромная протяженность информационных сетей. На это накладывается еще и тот факт, что небольшие филиалы компаний, подключенные к корпоративной сети глобального масштаба, могут насчитывать в своем штате совсем небольшое число сотрудников, и не иметь возможности нанять специальный персонал для обслуживания вычислительной сети. Оборудование же, установленное в таком маленьком филиале, вполне может быть весьма сложным. Если не принять специальные меры, то любая неполадка, любой сбой в работе оборудования будет вынуждать отдел информационных технологий компании отправлять технического специалиста на "точку" для выяснения ситуации и устранения неполадок. Если принять во внимание огромную протяженность сетей глобального масштаба, то станет понятно, что такие поездки (а причиной командировки вполне может быть какой-нибудь сущий пустяк) могут "съесть" весьма значительную часть времени сотрудников и технического отдела и денег, отпущенных на поддержание сети в работоспособном состоянии.
Наконец, последнее. Управление локальными сетями обычно осуществляется с какого-либо одного управляющего компьютера. Протяженность глобальных сетей и дороговизна средств связи часто заставляет компании распределять функции управления сетью между несколькими серверами, расположенными в различных точках земного шара. Такая конфигурация может быть предпочтительнее, во-первых, с точки зрения рационального использования имеющихся линий связи (вряд ли разумно передавать служебную информацию, скажем, из Новой Зеландии на Восточное побережье США и обратно), а во-вторых, с точки зрения обеспечения устойчивой работы сети.
Все это заставляет администратора международной сети задуматься о средствах управления и контроля работы сети, которые бы, во-первых, позволили следить за трафиком в сети и определять источники максимального трафика и характер пересылаемой ими информации, не "засоряя" при этом сеть большим количеством служебной информации; во-вторых, могли бы самостоятельно определять состояние сетевых устройств и если и не ремонтировать их, то хотя бы диагностировать неисправности - это позволит сотрудникам технического отдела компании принять обоснованное решение о необходимости поездки на "точку" и, в случае необходимости такой поездки, тщательно подготовиться к прведению необходимых работ. В третьих, было бы очень желательно иметь в своем распоряжении такое средство контроля работы сети, которое бы самостоятельно предупреждало о появляющихся проблемах до возникновения полного отказа оборудования.
Наконец, учитывая распределенный характер управления работой сети, было бы логично отказаться от жесткой двухуровневой системы управления сетью, принятой в SNMP, и перейти на какой-то более "распределенный" вариант рассылки собранной информации - скажем, разные участки сети могли бы отсылать свою информацию на разные управляющие машины, в ходе информационного обмена между которыми возникала бы уже полная картина работы сети. Забегая вперед, скажем, что обрисованная проблема пока далека от своего решения, и задача интеграции собранной информации о работе сети стоит по-прежнему остро.
Решить все эти задачи в рамках старого доброго SNMP невозможно. К счастью, некоторое время назад у SNMP появился наследник, благодаря которому оказывается возможным осуществлять управлкение сетью с учетом потребностей сегодняшнего дня. Имя ему - RMON (remote monitoring, или, по-русски, дистанционный мониторинг сетей).
Что такое RMON?
Стандарт на RMON появился в ноябре 1991 года, когда Internet Engineering Task Force выпустил документ RFC 1271 под названием "Remote Network Monitoring Management Information Base" ("Информационная база дистанционного мониторинга сетей"). Данный документ содержал описание RMON для сетей Ethernet. В сентябре 1993 года к нему добавился документ RFC 1513, определяюющий RMON для сетей Token Ring. Наконец, в феврале 1995 года был выпущен документ RFC 1757, представляющий собой новую версию RFC 1271.
RMON - это расширение SNMP, в основе которого, как и в основе SNMP, лежит сбор и анализ информации о характере информации, передаваемой по сети. Как и в SNMP, сбор информации осуществляется аппаратно-программными агентами, данные от которых поступают на компьютер, где установлено приложение управления сетью. Отличие RMON от своего предшественника состоит, в первую очередь, в характере собираемой информации - если в SNMP эта информация характеризует только события, проитсходящие на том устройстве, где установлен агент, то RMON требует, чтобы получаемые данные характеризовали трафик между сетевыми устройствами, а ведь именно это, как правило, и интересует администратора сети более всего.
Передача информации от агентов SNMP приложению управления осуществляется по следующей схеме: приложение управления опрашивает агентов, а они в ответ высылают необходимые данные. Предусмотрено и нечто вроде механизма прерываний - агент может послать приложению запрос на обслуживание (например, при возникновении какого-либо отказа), однако этот механизм в SNMP несовершенен и применяется редко. Сами агенты анализом данных о работе сети не занимаются - это целиком и полностью оставлено в компетенции приложений управления. Ясно, что такая схема обмена информацией сильно перегружает сеть, и потому является неприемлемой для сетей глобального масштаба, где стоимость трафика чрезвычайно высока. В отличие от агентов SNMP, агенты RMON самостоятельно выполняют анализ данных, и посылают на приложение управления уже частично обработанные данные. Помимо этого, сами агенты RMON могут выполнять простейшие функции по управлению сетью, в частности, осуществлять фильтрацию пакетов.
Интеллект агентов RMON позволяет им выполнять также простые действия по диагностике неисправностей и предупреждению о возможных отказах - например, в рамках технологии RMON можно собрать данные о нормальном функционировании сети (т. е. выполнить так называемый baselining), а потом выставлять предупреждающие сигналы, когда режим работы сети отклонится от baseline - это может свидетельсствовать, в частности, о неполной исправности оборудования. Собрав воедино информацию, получаемую от агентов RMON, приложение управления может помочь администратору сети (находящемуся, например, за тысячи километров от анализируемого сегмента сети) локализовать неисправность и выработать оптимальный план действий для ее устранения.
Информационная база управления RMON
В соответствии с документом RFC 1271, информационная база управления RMON состоит из десяти групп данных.
Первая группа носит название группы статистики (statistics). В ней собирается общая информация о трафике в данном сегменте и степени использования пропускной способности сети - количестве переданных байтов и сетевых пакетов, числе ошибок и коллизий и так далее.
Группа предыстории (history) "отвечает" за сбор информации, определенной в группе статистики, в течение определенного времени (от одной секунды до одного часа). В результате оказывается возможным проанализировать текущие тенденции в работе сети и сравнить текущее состояние с базовым - это позволит выявить нежелательные явления в работе сети раньше, чем они превратятся в серьезную проблему (например, пока сбои в работе оборудования не привели к его полному отказу).
Группа аварийных сигналов (alarms) позволяет пользователю определить ряд пороговых уровней (эти пороги могут отнситься к самым разным вещам - любому параметру из группы статистики, амплитуде или скорости его изменения и многому другому), по превышении которых генерируется аварийный сигнал. Пользователь может также определить, при каких условиях превышение порогового значения должно сопровождаться аварийным сигналом - это позволит избежать генерации сигнала "по пустякам", что плохо, во-первых, потому, что на постоянно горящую красную лампочку никто не обращает внимания, а во-вторых, потому, что передача ненужных аварийных сигналов по сети приводит к излишней загрузке линий связи. Аварийный сигнал, как правило, передается в группу событий, где и определяется, что с ним делать дальше.
Четвертая группа информационной базы управления RMON - группа хостов (hosts). В ней регистрируются все хост-машины и прочие сетевые устройства, работающие в данном сегменте сети, и осуществляется сбор основной статистики для этих устройств.
Таблица N главных хостов (HostTopN) содержит список N первых хостов, характеризующихся максимальным значением заданного статистического параметра для заданного интервала. Например, можно затребовать список 10 хостов, для которых наблюдалось максимальное количество ошибок в течение последних 24 часов. Список этот будет составлен самим агентом, а приложение управления получит только адреса этих хостов и значения соответствующих статистических параметров. Отчетливо видно, до какой степени такой подход экономит сетевые ресурсы.
Шестая группа даных информационной базы - матрица трафика (traffic matrix). Строки этой матрицы пронумерованы в соответствии с MAC-адресами станций - источников сообщений, а столбцы - в соответствии с адресами станций-получателей. Матричные элементы характеризуют интенсивность трафика между соответствующими станциями и количество ошибок. Проанализировав такую матрицу, пользователь легко может выяснить, какие пары станций генерируют наиболее интенсивный трафик. Эта матрица, опять-таки, формируется самим агентом, поэтому отпадает необходимость в передаче больших объемов данных на центральный компьютер, отвечающий за управление сетью.
Группа фильтров (filters), как можно понять из самого ее названия, используется для фильтрации пакетов. Признаки, по которым фильтруются пакеты, могут быть самыми разнообразными - например, можно потребовать отфильтровывать как ошибочные все пакеты, длина которых оказывается меньше некоторого заданного значения. Можно сказать, что установка фильтра соответствует как бы организации канала для передачи пакета. Куда ведет этот канал - определяет пользователь. Например, все ошибочные пакеты могут перехватываться и направляться в соответсвующий буфер. Кроме того, появление пакета, соответствующего установленному фильтру, может рассматриваться как событие (event), на которое система должна реагировать заранее оговоренным образом.
В состав группы перехвата пакетов (packet capture) входят буфера для захвата, куда направляются пакеты, чьи признаки удовлетворяют условиям, сформулированным в группе фильтров. При этом захватываться может не пакет целиком, а, скажем, только первые несколько десятков байт пакета. Содержимое буферов перехвата можно впоследствии анализировать при помощи различных программных средств, выясняя целый ряд весьма полезных характеристик работы сети. Перестраивая фильтры на те или иные признаки, можно характеризовать разные параметры работы сети.
В группе событий (events) определяется, когда следует отправлять аварийный сигнал приложению управления, когда - перхватывать пакеты, и вообще - как реагировать на те или иные события, происходящие в сети, например, на превышение заданных в группе alarms пороговых значений: следует ли ставить в известность приложение управления, или надо просто запротоколировать данное событие и продолжать работать. События могут и не быть связаны с предачей аварийных сигналов - например, направление пакета в буфер перехвата тоже представляет собой событие.
Десятая группа данных важна только для сетей Token Ring, поэтому мы на ней подробно останавливаться не станем. Здесь, в частности, определяется порядок следования станций в кольце.
Как видно, все группы данных информационной базы управления RMON описывают обмен данными в пределах одного сегмента локальной сети. Приложения управления могут собрать из этих фрагментов картину обмена данными в масштабах всей сети. Задача эта очень сложна и, соответственно, программы для ее решения немногочисленны и весьма дороги. Естественным образом возникает вопорос, нельзя ли часть "сборки" переложить на плечи распределенных по сети агентов - так же, как в свое время был совершен переход от SNMP к RMON. Именно эту задачу и призван решить новый стандарт - RMON 2, который сначала вроде бы должен был появиться в ноябре 1995 года, потом это событие было перенесено на конец лета 1996 года, но до сих пор о нем что-то ничего не слышно.
В RMON 2 будет описан сбор данных, описывающих работу сети на сетевом уровне и уровне приложений. О своей готовности реализовать RMON 2 объявили уже многие производители сетевого оборудования, работающего под RMON.
Как это делается?
Сбор информации RMON осуществляется аппаратно-программными зондами, подключаемыми непосредственно к сети. Чтобы выполнить задачу сбора и первичного анализа данных, зонд должен обладать достаточными вычислительными ресурсами и объемом оперативной памяти. В настоящее время на рынке имеются зонды трех типов: встроенные, зонды на базе компьютера, и автономные. Продукт считается поддерживающим RMON, если в нем реализована хотя бы одна группа RMON. Разумеется, чем больше групп данных RMON реализовано в данном продукте, тем он, с одной стороны, дороже, а с другой - тем более полную информацию о работе сети он предоставляет.
Встроенные зонды представляют собой модули расширения для сетевых устройств. Такие модули выпускаются многими производителями, в частности, такими крупными компаниями, как 3Com, Cabletron, Bay Networks и Cisco. (Кстати, 3Com и Bay Networks недавно приобрели компании Axon и ARMON, признанных лидеров в области разработки и производства средств управления RMON. Такой интерес к этой технологии со стороны крупнейших производителей сетевого оборудования лишний раз показывает, насколько нужным для пользователей является дистанционный мониторинг.) Наиболее естественным выглядит решение встраивать модули RMON в концентраторы, ведь именно из наблюдения за этими устройствами можно составить себе представление о работе сегмента. Достоинство таких зондов очевидно: они позволяют получать информацию по всем основным группам данных RMON при относительно невысокой цене. Недостатком в первую очередь является не слишком высокая производительность, что проявляется, в частности, в том, что встроенные зонды часто поддерживают далеко не все группы данных RMON. Не так давно 3Com объявила о намерении выпустить поддерживающие RMON драйверы для сетевых адаптеров Etherlink III и Fast Ethernet. В результате окажется возможным собирать и анализировать данные RMON непосредственно на рабочих станциях в сети.
Зонды на базе компьютера - это просто подключенные к сети компьютеры с установленным на них программным агентом RMON. Такие зонды (к числу которых относится, например, продукт Cornerstone Agent 2.5 компании Network General) обладают более высокой производительностью, чем встроенные зонды, и поддерживают, как правило, все группы данных RMON. Они более дороги, чем встроенные зонды, но гораздо дешевле автономных зондов. Помимо этого, зонды на базе компьютера имеют довольно большой размер, что может иногда ограничивать возможности их применения.
Автономные зонды обладают наивысшей производительностью; как легко понять, это одновременно и наиболее дорогие продукты из всех описанных. Как правило, автономный зонд - это процессор (класса i486 или RISC-процессор), оснащенный достаточным объемом оперативной памяти и сетевым адаптером. Лидерами в этом секторе рынка являются компании Frontier и Hewlett-Packard. Зонды этого типа невелики по размеру и весьма мобильны - их очень легко подключать к сети и отключать от нее. При решении задачи управления сетью глобального масштаба это, конечно, не слишком важное свойство, однако если средства RMON применяются для анализа работы корпоративной сети средних размеров, то (учитывая высокую стоимость устройств) мобильность зондов может сыграть весьма положительную роль. Существуют компании, предоставляющие зонды в аренду, а также оказывающие комплексные услуги по диагностике сети - приходят, подключают зонды, наблюдают за работой сети, а потом выдают рекомендации администраторам.
Информацию, собираемую агентами, надо обощать и представлять в удобном для пользователя виде. Этим занимаются приложения управления, представляющие собой весьма сложные программы, обеспечивающие просмотр статистики в целом по сети, выявление наиболее загруженных участков, обнаружение основных источников перегрузок (при этом удается выявить наиболее активные приложения), а также позволяющие выполнять анализ протоколов. Среди производителей наиболее продвинутого программного обеспечения надо упомянуть ARMON (ту самую, которую недавно приобрела Bay Networks), Frontier Software, Hewlett-Packard и Novell.
Вперед, к коммутируемым сетям
Использование коммутационных технологий - одно из наиболее распространенных средств повышения производительности сети. Это проявляется и на уровне сети в целом, и на уровне отдельных сегментов. Резкое снижение цен на коммутаторы привело к тому, что в настоящее время их используют буквально повсюду. Между тем, реализовать технологию RMON на коммутаторе не так просто, поскольку здесь соединения между отдельными портами и, соответственно, подключенными к ним элементами сети устанавливаются в динамическом режиме, что существенно усложняет задачу слежения за информационным обменом. Ожидается, что новый стандарт RMON 2 упростит решение задачи управления коммутируемыми сетями. Пока же, не дожидаясь почвления RMON 2, многие производители уже начали выпускать коммутаторы со встроенными зондами RMON. Правда, часть из них обеспечивает слежение лишь за частью портов, что, разумеется, снижает ценность такого продукта.
В настоящее время ведется активная разработка стандартов RMON для скоростных сетей (таких, как Fast Ethernet или ATM), где коммутация играет особенно важную роль. Скоро должны появиться первые продукты, осуществляющие дистанционный мониторинг этих сетей. Скоростные технологии находят все более широкое применение в сетях глобального масштаба, поэтому такие новинки будут очень полезны для решения задач, о которых говорилось в самом начале этой статьи.
Александр Крейнес - научный сотрудник Института кристаллографии РАН. С ним можно связаться при помощи электронной почты по адресу kreines@cti.ru.
Распределенное управление - цель, которая ускользает
Платформы начинают появляться, но где приложения? И что же из себяпредставляет Web? Кажется в компьютерной индустрии уже установился своего рода modus operandi (образ действия): программное обеспечение, способное воспользоваться преимуществами новых более скоростных процессоров, всегда выходит на месяц позже их появления.
Похожая история повторяется и с сетевым управлением. Теперь, когда платформы распределенного управления начали заполнять рынок, приложения для них так трудно найти.
Но отсутствие приложений распределенного управления не единственная проблема. Производители платформ распределенного управления еще должны тщательно разобраться в том, какое влияние на их деятельность окажет World Wide Web. Все больше и больше Web-технологии рассматриваются пользователями как новая возможность интеграции приложений управления, роль, которая изначально предназначалась платформам, но осталась за пределами их компетенции.
|
управления по классам продуктов управления достигнет 1,5 млрд. долл. к концу столетия, далеко опередив объем рынка монолитных и клиент-серверных платформ, число продаж которых будет сходить на нет.  |
Таким образом поход к распределенному управлению все еще продолжается.
Компания Hewlett-Packard, лидер рынка в создании платформ управления, в апреле начала выпуск распределенной версии своей системы OpenView - Network Node Manager (NMM) 4.0. Но основных приложений для нее пока нет.
Seagate Enterprise Management Software в начале июля представила на рынке версию своего механизма корреляции событий для NNM 4.1, NerveCentre. В свою очередь Bay Networks не намерена реализовывать версию своего Optivity, приложения сетевого управления для NNM 4.1, до октября. Примерно в то же время появится CiscoWorks для NNM 4.1 компании Cisco Systems.
Платформа Spectrum компании Cabletron Systems последовательно добивается высоких похвал своей многофункциональности и распределенным возможностям. Но поскольку Cabletron Systems пробует себя в роли производителя приложения системного управления лишь чуть больше года, она не продвинулась столь же успешно, как HP или IBM, которые уже долгое время занимаются этими проблемами.
Некоторые потребители сетуют, что наличие распределенных платформ мало помогает, поскольку имеющиеся приложения их еще не поддерживают.
Но разработчики программного обеспечения могут принизить ценность проекта создания приложений для этих платформ. По словам Рави Гулати, президента компании StonyBrook Software, поставщика комплексного оборудования для поддержки программного обеспечения управления маршрутизаторов, разработчики рассматривают платформы, как нечто большее, чем основу для работы украшающих ее приложений. Бизнес, связанный с созданием платформ - это убыточная деятельность для всех. Интеграции нет и вряд ли в течение следующих нескольких лет она появится.
Параллельно с борьбой за привнесение приложений на свои новые распределенные управляющие системы, разработчики платформ учитывают приближение господства Web-технологии. Пользователи с энтузиазмом относятся к ней, рассматривая ее как основу для сетевого управления, поскольку она обеспечивает переносимый, недорогой интерфейс, в рамках которого сообщения используются для распределения отчетов управления.
Производители относятся к Web-технологии с неприязнью, поскольку из-за нее пользователи в скором времени перестанут тратить десятки тысяч долларов на приобретение платформы управления для хранения этих отчетов. Но они чувствуют ее неизбежность, поэтому объединяются с целью стандартизации ее для сетевого управления. В процессе формирования своей инициативы Web-Based Enterprise Management (WBEM), производители приложений пришли к выводу, что платформы и другие средства управления по-прежнему требуют внимания, поскольку предлагают немногое из обещанной интеграции приложений. Производители понимают неизбежность появления устройств с серверами Web и некоторыми типами приложений управления Java и считают, что WBEM может изменить основы их бизнеса. Она может предложить производителям устройств возможность создания приложений управления, которые не будут строится на двух или трех различных платформах сетевого управления. Но протоколы WBEM не позволяют распределять большие объемы данных по многочисленным конечным станциям.
Энди Ванагунас, менеджер по программе OpenView компании Hewlett-Packard, не согласен с такой точкой зрения, заявляя, что WBEM позволит действительно усовершенствовать OpenView, обеспечивая компании возможность сосредоточиться на разработке "value-added services" для платформ. Это даст возможность усилить взаимосвязь информации, обрабатывать события, усовершенствовать топологию, составлять диаграммы связей между управляемыми объектами, добавить интерфейсные механизмы и разрабатывать хранилища управляющей информации.
|
различного типа во всем мире существенно превзойдет объем выпуска серверов предприятий и систем Windows, причем первые станут преобладающей реализацией систем управления сетями масштаба предприятия.  |
Одна из частей уравнения распределенного управления - и, возможно, наиболее важная - технология интеллектуального агента, как раз то, чего организации, ведающие стандартами, отказались касаться. Отсутствие стандарта на архитектуру интеллектуального агента может негативно сказаться на перспективах стандартизованного распределенного управления. По мнению Френка Хендерсона, директора по технологиям компании Netplex Group, ограниченияприсутствуют не столько в самой технологии интеллектуального агента, сколько в стандартизации технологии и вообще в проблемах интеграции интеллектуальности в SNMP-архитектуру.
Разные мнения о Web-технологиях и
управлении гетерогенными сетями
Пять лидирущих поставщиков програмного и аппаратного обеспечения предложили новый стандарт для управления сетями - c помощью Web-браузера....
Производители - Cisco, Compaq, Intel и BMC Software - полагают, что усилия по созданию стандарта управления сетями приведут к образованию к нового типа Web- ориентированных инструментов. Они позволят снизить сложность и стоимость управления сетями масштаба предприятия. WBEM (Web-Based Enterprise Management) группу поддерживает еще около 70 других компаний.
Ожидается, что WBEM решит проблему интеграции и даст простор для создания новых приложений и целых концепций управления.
Но история не любит таких амбициозных инициатив как создание стандартов упраления. Многие знакомы с OSF (Open Software Foundation) и ее проектом управления Distributed Management Environment или консорциумом Management Integration Consortium. Усилия предпринятые по разработке нового стандарта привели к огромным проблемам, в том числе и неожиданным. Компания Sun Microsystems, разработавшая язык программирования Java - наиболее популярное средство для создания управляющих Web приложений в Internet, достаточно холодно отнеслась к этому проекту. Часть сторонников WBEM технологий отказались публично поддержать проект. Спецификации, которые еще предстоит определить, и все принимаемые решения необходимо согласовывать с более чем 70 поставщиками и с двумя, как минимум, комитетами по стандартам.
Концепция WBEM
Концепция WBEM подразумевает три уровня стандартизации. Первый - Hyper-Media Management Schema (HMMS) - определяет гибкую модель данных для представления управляемых объектов. Другой - Hyper-Media Management Protocol (HMMP) - основан на HTTP протоколе и предназначен для поддержания связи между службами, приложениями и агентами. И третий - Hyper-Media Object Manager (HMOM) - объектный C++ диспетчер, который организует обмен данными между приложениями, которые их обрабатывают.
В основу HMOM положена технология OLE фирмы Microsoft. HMMS будет разрабатываться, поддерживаться и обновляться группой Desktop Management Task Force (DMTF). Концепцию HMMP предлагается обсуждать в Internet Engineering Task Forse, а информация о HMOM будет предоставлена широкой публике.
Поставщики ожидают появление на рынке продуктов WBEM в следующем году. Хотя разработчики WBEM утверждают, что в их планы входит работа с существующими стандартами обмена информацией (такими как SNMP и Desktop Management Interface), корректное взаимодействие с устройствами поддерживающими их гарантировать довольно сложно. Это одна из причин, почему пользователи скептически относятся к WBEM. Потенциальные потребители, вероятно, будут воздерживаться от поспешных решений, ожидая появления устойчивого стандарта. Никто не сможет упрекнуть Sun, если WBEM не будет работать, или ему не будут доверять. Sun будет держать дистанцию, пока не увидит эффекта от влияния WBEM на Java. Между WBEM и Java существуют различия как в пользовательском интерфейсе, так и в исполнении. Пользовательский интефейс WBEM-браузера основан на HTML, а Java - нет. Если различия в объектных моделях между WBEM и Java будут значительны, выполнение приложений может привести к неопределенным последствиям. Тем не менее Microsoft надееется, что Sun изменит свое отношение к WBEM. Некоторые производители, поддерживающие WBEM, ведут себя очень осторожно. Например, Tivoli Systems дочерняя компания IBM, будет поддерживать связь с HMMS с помощью других, более привычных протоколов. И только, если HMMS будет признан как фактическим стандартом, будут работать с ним. Пока до конца не понятно, как будут изменяться протоколы взаимодействия, но и этим проблемы не исчерпываются. Хотя WBEM имеет много технических проблем, политические проблемы, которые сопутствуют введению нового стандарта, могут быть еще более устрашаюшими. Некторые компании, поддерживающие этот стандарт, недолюбливают друг друга.
