После долгого и продолжительного изучения существующих возможностей
(TODO список)
остановился на AutoPano Pro
воскресенье, 23 ноября 2008 г.
вторник, 28 октября 2008 г.
Вопрос-ответ по системам мониторинга ИТ инфраструктуры
В настоящем списке упомянуты только вопросы, ответы на которые нельзя найти в руководствах или интернете. Из множества запросов, поступавших на протяжении нескольких лет, были выделены самые волнующие и на них даны краткие ответы.
1. Как быстро может окупиться система мониторинга?
Система мониторинга направлена на автоматизацию и не имеет своей прямой целью увеличение оборота бизнеса. Автоматизация помогает повысить эффективность и сократить расходы. Бывают сценарии, когда системы мониторинга внедряются для повышения капитализации компании или для следования требованиям регулирующих органов. Но в таких случаях подобные вопросы задаются редко.
Усредненные цифры по отрасли от крупнейших аналитических агентств никак не помогут в подсчете вашей прибыли (экономии). Можно автоматизировать рабочие места пользователей вплоть до постоянного следования новым веяниям, но это может совершенно не сказаться на реальной производительности пользователей с точки зрения бизнеса. Просто у сотрудников куда больше времени будет на перекуры и общение друг с другом. С другой стороны, повышение рентабельности на 7% в среднем с возможным отклонением от -10% до +24% (что, конечно же, умалчивается) не оставляют ни единого шанса для точной оценки возможных последствий проекта именно в Вашем случае.
Для правильной оценки ROI необходимо обратиться по каждой статье расхода (дохода) к существующей у Вас статистики (если таковая имеется, а это отдельный вопрос). В зависимости от типа автоматизации необходимо пройтись по всей таблице статей и оценить, будет ли влиять предлагаемая автоматизация на характеристики статьи. Может у Вас в компании именно такая ситуация, что предлагаемый продукт никак не поможет. Например, регламенты есть, но их никто не соблюдает.
Теория про положительный эффект от повышения производительности и сокращения персонала, так часто фигурирующая в западных методиках вычисления ROI, совершенно неприменима к российским реалиям. У нас не то чтобы переизбыток грамотных специалистов, но и повсеместный «кадровый голод».
Чтобы правильно автоматизировать, необходимо иметь информацию по степени доступности каждого элемента и обращать внимание именно на самые слабые звенья. Что толку предлагать ставить CRM (с технико-экономической позиции) и показывать топ-менеджерам презентации с фантастическими данными по ROI, если администратор БД является безответственным типом и у него постоянно все ломается?
2. А почему так дорого стоит?
Пример типичного заблуждения в стоимости объектов нематериального мира. Несмотря на то, что программный продукт является специфической совокупностью «0» и «1», он позволяет решать конкретные задачи, для которых и был создан. Стоимость продукта имеет 2 аспекта: стоимость с точки зрения производителя и стоимость с точки зрения покупателя. С точки зрения производителя, чем качественнее программный продукт, тем большее количество людей и материальных ресурсов было вовлечено в процесс создания и тем дороже он будет. Архитекторы, программисты, технические писатели, инженеры по качеству, руководители проектов, аналитики, дизайнеры, маркетологи и многие другие специалисты участвовали в создании продукта. Продукт — это не просто код, это код, окруженный большим количеством атрибутов: требования, тесты, руководства, скрипты миграции, библиотеки устройств, шаблоны отчетов. Дополнительно, код воплощает весь накопленный опыт за время существования продукта.
С точки зрения пользователя стоимость продукта определяется теми возможностями, которые становятся доступными при внедрении этого продукта. В одних случаях ПО может повысить эффективность уже существующих процессов, в других же, позволяет сделать качественный скачок и перейти на новый уровень, недоступный ранее. В разных случаях стоимость тех плюсов, которые приносит ПО, может существенно различаться. А как оценить интеллектуальную составляющую ПО? Как оценить стоимость знаний об ошибочных путях и правильных решениях, стоимость опыта, накопленных в продукте во время его эволюционирования и использования другими компаниями? Знание об ошибках конкурентов часто позволяет вовремя скорректировать стратегию и миновать определенные опасности. И чем больше пользователей у продукта, тем меньше удельная стоимость всех нововведений и исправленных ошибок. Таким образом, ПО не является дорогим или дешевым априори, реальная ценность продукта для каждого пользователя будет сильно различаться.
3. А чем решение X лучше решения Y?
Вопрос слишком общий, чтобы на него можно было дать ответ. В целом, можно ответить: «Ничем, все одинаково (полезно или бесполезно)». Правильный ответ можно дать только преломляя возможности систем через призму потребностей Заказчика. А это означает, что четкое и однозначное формулирование требований к системе мониторинга является основой правильного выбора. Однако, при формулировании требований очень важно не совершить иную ошибку, часто совершаемую техническими специалистами: формирование огромного списка сложных технических требований, которые достаточно дороги в реализации, требуют привлечения высококвалифицированных специалистов, но которые, к сожалению, не приносят основному бизнесу ничего кроме расходов. Очень важно найти разумный компромисс между желанием технического перфекционизма и реальными требованиями бизнеса.
4. Необходимо, чтобы решение осуществляло мониторинг приложения X. Ваше умеет?
Когда речь идет о мониторинге приложений, сразу возникает несколько десятков альтернатив. Что значит, осуществлять мониторинг? Следить за лог-файлами? Следить за состоянием процессов? Получать сообщения? Осуществлять проактивный мониторинг с помощью тестовых функций? Проверять выполнение бизнес-логики? Отслеживать утечки памяти? А что понимать под мониторингом распределенных и\или многозвенных приложений? У Microsoft Exchange, например, существуют более 1500 метрик (KPI); какие из этих метрик являются важными именно в Вашей конфигурации Exchange? Или может важным являются агрегатные метрики (KQI)? При этом немаловажно учесть особенности работы человеческого мозга, а именно, возможность одновременного удержания в сфере сознательного 7±2 объектов. С учетом этой особенности, 0 метрик и 100 метрик имеют равнозначно информативную составляющую, а именно, нулевую. Правильным ответом на поставленный вопрос будет анализ бизнес-процессов, выделение функций, выполняемых бизнес-критичными приложениями и формирование рекомендаций по агрегатным метрикам. Только после этого можно переходить к вопросам технической реализации мониторинга этих метрик. Для большинства приложений можно предложить несколько альтернативных технических решений по мониторингу, выбор упирается в соотношение цена\качество, аспекты безопасности, возможность изменения кода в случае ПО самостоятельной разработки и многое другое.
5. Нам необходима гибкая система отчетности. Насколько гибкую систему Вы предлагаете?
Требование о гибкости системы выглядит логичным и правильным. Вдруг по истечении некоторого времени потребуется разработать какой-либо нестандартный отчет? Однако, чем гибче система, тем она сложнее и дороже. Предельным случаем гибкой системы может служить среда разработки, например, Microsoft Visual Studio, Вряд ли этот предельный случай устроит кого-либо. А обслуживание технически сложной системы требует наличия квалифицированных специалистов, что удорожает эксплуатационные расходы. А вдруг при этом потребность в нестандартном отчете так и не возникнет? Окажется, что было выбрано дорогое, технически сложное решение, затратное в обслуживании, но выгоды от этого выбора получить не удалось. Так что, очень важно найти компромисс между гибкостью и реальными потребностями. Перейти от требований «в целом» к конкретным отчетам: проанализировать возможность создания отчетов, уже используемых в организации, какие отчеты потребуются от этой системы, какие есть нормативы на форматы отчетов, в частности от регламентирующих органов, что входит в пакет готовых отчетов, поставляемых вместе с системой, действительно ли необходимы дополнительные отчеты. Дополнительным вариантом может быть выгрузка данных и последующее использование уже существующей в компании системы генерации отчетов для решения задач генерации сложных, кроссдоменных отчетов в устоявшемся формате.
6. Система должна интегрироваться с продуктами X, Y и Z. Перечислите существующие средства интеграции.
Если рисовать высокоуровневую картину «5 прямоугольников и потоки данных», то кажется, что это все очень просто. Конечно же, требование интеграции выглядит очень правильным. Построение единой информационной системы, в которой все модули интегрированы, создана единая система отчетности в разрезах, необходимых каждому подразделению, крайне привлекательно для бизнеса. При этом, на уровне «прямоугольников» опускаются многочисленные технические аспекты, которые впоследствии не позволят эту картину воплотить в жизнь.
Средства интеграции достаточно стандартны: ODBC, CLI, Web-services, SNMP, SMTP. Но их перечисление опять же не даст никакого ответа на реальную возможность интегрировать указанные продукты. Ситуация достаточно проста: если оба продукта, которые необходимо интегрировать, не изменяются с течением времени, то интегрировать можно любым, даже самым трудоемким и неэффективным способом. Главное оттестировать эту интеграцию и устранить ошибки. И будет потом эта интеграция служить верой и правдой долгие годы. К сожалению, в реальном мире все по-другому. Каждый из интегрируемых продуктов живет своей жизнью, меняется код, меняется логика, меняются интерфейсы, меняются технологии. Поэтому, после каждого изменения продукта, входящего в интегрированный комплекс, необходимо проверять корректность работы существующего механизма интеграции. В случае сложных систем и неудачных методов интеграции эта задача может оказаться неподъемной. Таким образом, главным требованием должен быть выбор таких средств интеграции, которые позволят обеспечить максимальную инвариантность механизма интеграции по отношению к изменениям, происходящим в интегрируемых компонентах.
7. Можно систему посмотреть?
Как правило, это требование подразумевает два сценария развития. Посмотреть продукт на демо-стенде или провести триал в своей инфраструктуре. С первым случаем все просто — сценарий удаленной демонстрации отработан, его длительность составляет примерно 2-3 часа, после демонстрации пользователь получает представление обо всех основных возможностях продукта, особенностях работы и интерфейсе. Этого, как правило, вполне достаточно, чтобы позволить провести оценку для применимости системы в своем окружении и принять управленческое решение.
Второй вариант, проведение триала, требует очень тщательной подготовки со стороны пользователей, проработки методики испытаний. При ее отсутствии сложно рассчитывать на объективность оценки результатов триала.
8. Система может хранить все аварийные сообщения в течение года? А двух?
Каждая информация стоит ресурсов, которые, так или иначе, могут быть выражены в денежном эквиваленте. Изначально система регистрации неисправностей, являющаяся основой системы мониторинга, рассчитана на оперативную работу и на быструю реакцию на действия оператора. Любое увеличение данных, которые должны храниться в оперативном доступе, требует соответствующего увеличения аппаратных мощностей. Но действительно ли существуют такие объективные требования к хранениям «сырых» (raw) данных? Чем может помочь отдельное аварийное сообщение 6-ти месячной давности? А годовой? Ресурсов для изучения и анализа этого непрерывно увеличивающегося количества информации, как правило, нет и не предвидится. Ляжет это все мертвым грузом, ежедневно потребляя ресурсы на свое обслуживание. При таких сроках давности имеет смысл анализировать тенденции, периодические колебания, средние значения и статистику по сбоям. Архитектурно, это уже прерогатива систем аналитической отчетности, а не систем мониторинга. Поэтому оптимальным вариантом является разделение задач между различными системами, а не обрушение всего потока требований на одну систему.
9. Почему так мало вопросов?
В силу того, что CA Spectrum является успешным коммерческим продуктом с 15-ти летней историей, за кадром остались вопросы такие, как управление правами пользователей, самодиагностика, масштабирование, надежность, список заказчиков, и многие другие. Они не упоминаются вследствие того, что на каждый этот вопрос идет прямая цитата из документации.
1. Как быстро может окупиться система мониторинга?
Система мониторинга направлена на автоматизацию и не имеет своей прямой целью увеличение оборота бизнеса. Автоматизация помогает повысить эффективность и сократить расходы. Бывают сценарии, когда системы мониторинга внедряются для повышения капитализации компании или для следования требованиям регулирующих органов. Но в таких случаях подобные вопросы задаются редко.
Усредненные цифры по отрасли от крупнейших аналитических агентств никак не помогут в подсчете вашей прибыли (экономии). Можно автоматизировать рабочие места пользователей вплоть до постоянного следования новым веяниям, но это может совершенно не сказаться на реальной производительности пользователей с точки зрения бизнеса. Просто у сотрудников куда больше времени будет на перекуры и общение друг с другом. С другой стороны, повышение рентабельности на 7% в среднем с возможным отклонением от -10% до +24% (что, конечно же, умалчивается) не оставляют ни единого шанса для точной оценки возможных последствий проекта именно в Вашем случае.
Для правильной оценки ROI необходимо обратиться по каждой статье расхода (дохода) к существующей у Вас статистики (если таковая имеется, а это отдельный вопрос). В зависимости от типа автоматизации необходимо пройтись по всей таблице статей и оценить, будет ли влиять предлагаемая автоматизация на характеристики статьи. Может у Вас в компании именно такая ситуация, что предлагаемый продукт никак не поможет. Например, регламенты есть, но их никто не соблюдает.
Теория про положительный эффект от повышения производительности и сокращения персонала, так часто фигурирующая в западных методиках вычисления ROI, совершенно неприменима к российским реалиям. У нас не то чтобы переизбыток грамотных специалистов, но и повсеместный «кадровый голод».
Чтобы правильно автоматизировать, необходимо иметь информацию по степени доступности каждого элемента и обращать внимание именно на самые слабые звенья. Что толку предлагать ставить CRM (с технико-экономической позиции) и показывать топ-менеджерам презентации с фантастическими данными по ROI, если администратор БД является безответственным типом и у него постоянно все ломается?
2. А почему так дорого стоит?
Пример типичного заблуждения в стоимости объектов нематериального мира. Несмотря на то, что программный продукт является специфической совокупностью «0» и «1», он позволяет решать конкретные задачи, для которых и был создан. Стоимость продукта имеет 2 аспекта: стоимость с точки зрения производителя и стоимость с точки зрения покупателя. С точки зрения производителя, чем качественнее программный продукт, тем большее количество людей и материальных ресурсов было вовлечено в процесс создания и тем дороже он будет. Архитекторы, программисты, технические писатели, инженеры по качеству, руководители проектов, аналитики, дизайнеры, маркетологи и многие другие специалисты участвовали в создании продукта. Продукт — это не просто код, это код, окруженный большим количеством атрибутов: требования, тесты, руководства, скрипты миграции, библиотеки устройств, шаблоны отчетов. Дополнительно, код воплощает весь накопленный опыт за время существования продукта.
С точки зрения пользователя стоимость продукта определяется теми возможностями, которые становятся доступными при внедрении этого продукта. В одних случаях ПО может повысить эффективность уже существующих процессов, в других же, позволяет сделать качественный скачок и перейти на новый уровень, недоступный ранее. В разных случаях стоимость тех плюсов, которые приносит ПО, может существенно различаться. А как оценить интеллектуальную составляющую ПО? Как оценить стоимость знаний об ошибочных путях и правильных решениях, стоимость опыта, накопленных в продукте во время его эволюционирования и использования другими компаниями? Знание об ошибках конкурентов часто позволяет вовремя скорректировать стратегию и миновать определенные опасности. И чем больше пользователей у продукта, тем меньше удельная стоимость всех нововведений и исправленных ошибок. Таким образом, ПО не является дорогим или дешевым априори, реальная ценность продукта для каждого пользователя будет сильно различаться.
3. А чем решение X лучше решения Y?
Вопрос слишком общий, чтобы на него можно было дать ответ. В целом, можно ответить: «Ничем, все одинаково (полезно или бесполезно)». Правильный ответ можно дать только преломляя возможности систем через призму потребностей Заказчика. А это означает, что четкое и однозначное формулирование требований к системе мониторинга является основой правильного выбора. Однако, при формулировании требований очень важно не совершить иную ошибку, часто совершаемую техническими специалистами: формирование огромного списка сложных технических требований, которые достаточно дороги в реализации, требуют привлечения высококвалифицированных специалистов, но которые, к сожалению, не приносят основному бизнесу ничего кроме расходов. Очень важно найти разумный компромисс между желанием технического перфекционизма и реальными требованиями бизнеса.
4. Необходимо, чтобы решение осуществляло мониторинг приложения X. Ваше умеет?
Когда речь идет о мониторинге приложений, сразу возникает несколько десятков альтернатив. Что значит, осуществлять мониторинг? Следить за лог-файлами? Следить за состоянием процессов? Получать сообщения? Осуществлять проактивный мониторинг с помощью тестовых функций? Проверять выполнение бизнес-логики? Отслеживать утечки памяти? А что понимать под мониторингом распределенных и\или многозвенных приложений? У Microsoft Exchange, например, существуют более 1500 метрик (KPI); какие из этих метрик являются важными именно в Вашей конфигурации Exchange? Или может важным являются агрегатные метрики (KQI)? При этом немаловажно учесть особенности работы человеческого мозга, а именно, возможность одновременного удержания в сфере сознательного 7±2 объектов. С учетом этой особенности, 0 метрик и 100 метрик имеют равнозначно информативную составляющую, а именно, нулевую. Правильным ответом на поставленный вопрос будет анализ бизнес-процессов, выделение функций, выполняемых бизнес-критичными приложениями и формирование рекомендаций по агрегатным метрикам. Только после этого можно переходить к вопросам технической реализации мониторинга этих метрик. Для большинства приложений можно предложить несколько альтернативных технических решений по мониторингу, выбор упирается в соотношение цена\качество, аспекты безопасности, возможность изменения кода в случае ПО самостоятельной разработки и многое другое.
5. Нам необходима гибкая система отчетности. Насколько гибкую систему Вы предлагаете?
Требование о гибкости системы выглядит логичным и правильным. Вдруг по истечении некоторого времени потребуется разработать какой-либо нестандартный отчет? Однако, чем гибче система, тем она сложнее и дороже. Предельным случаем гибкой системы может служить среда разработки, например, Microsoft Visual Studio, Вряд ли этот предельный случай устроит кого-либо. А обслуживание технически сложной системы требует наличия квалифицированных специалистов, что удорожает эксплуатационные расходы. А вдруг при этом потребность в нестандартном отчете так и не возникнет? Окажется, что было выбрано дорогое, технически сложное решение, затратное в обслуживании, но выгоды от этого выбора получить не удалось. Так что, очень важно найти компромисс между гибкостью и реальными потребностями. Перейти от требований «в целом» к конкретным отчетам: проанализировать возможность создания отчетов, уже используемых в организации, какие отчеты потребуются от этой системы, какие есть нормативы на форматы отчетов, в частности от регламентирующих органов, что входит в пакет готовых отчетов, поставляемых вместе с системой, действительно ли необходимы дополнительные отчеты. Дополнительным вариантом может быть выгрузка данных и последующее использование уже существующей в компании системы генерации отчетов для решения задач генерации сложных, кроссдоменных отчетов в устоявшемся формате.
6. Система должна интегрироваться с продуктами X, Y и Z. Перечислите существующие средства интеграции.
Если рисовать высокоуровневую картину «5 прямоугольников и потоки данных», то кажется, что это все очень просто. Конечно же, требование интеграции выглядит очень правильным. Построение единой информационной системы, в которой все модули интегрированы, создана единая система отчетности в разрезах, необходимых каждому подразделению, крайне привлекательно для бизнеса. При этом, на уровне «прямоугольников» опускаются многочисленные технические аспекты, которые впоследствии не позволят эту картину воплотить в жизнь.
Средства интеграции достаточно стандартны: ODBC, CLI, Web-services, SNMP, SMTP. Но их перечисление опять же не даст никакого ответа на реальную возможность интегрировать указанные продукты. Ситуация достаточно проста: если оба продукта, которые необходимо интегрировать, не изменяются с течением времени, то интегрировать можно любым, даже самым трудоемким и неэффективным способом. Главное оттестировать эту интеграцию и устранить ошибки. И будет потом эта интеграция служить верой и правдой долгие годы. К сожалению, в реальном мире все по-другому. Каждый из интегрируемых продуктов живет своей жизнью, меняется код, меняется логика, меняются интерфейсы, меняются технологии. Поэтому, после каждого изменения продукта, входящего в интегрированный комплекс, необходимо проверять корректность работы существующего механизма интеграции. В случае сложных систем и неудачных методов интеграции эта задача может оказаться неподъемной. Таким образом, главным требованием должен быть выбор таких средств интеграции, которые позволят обеспечить максимальную инвариантность механизма интеграции по отношению к изменениям, происходящим в интегрируемых компонентах.
7. Можно систему посмотреть?
Как правило, это требование подразумевает два сценария развития. Посмотреть продукт на демо-стенде или провести триал в своей инфраструктуре. С первым случаем все просто — сценарий удаленной демонстрации отработан, его длительность составляет примерно 2-3 часа, после демонстрации пользователь получает представление обо всех основных возможностях продукта, особенностях работы и интерфейсе. Этого, как правило, вполне достаточно, чтобы позволить провести оценку для применимости системы в своем окружении и принять управленческое решение.
Второй вариант, проведение триала, требует очень тщательной подготовки со стороны пользователей, проработки методики испытаний. При ее отсутствии сложно рассчитывать на объективность оценки результатов триала.
8. Система может хранить все аварийные сообщения в течение года? А двух?
Каждая информация стоит ресурсов, которые, так или иначе, могут быть выражены в денежном эквиваленте. Изначально система регистрации неисправностей, являющаяся основой системы мониторинга, рассчитана на оперативную работу и на быструю реакцию на действия оператора. Любое увеличение данных, которые должны храниться в оперативном доступе, требует соответствующего увеличения аппаратных мощностей. Но действительно ли существуют такие объективные требования к хранениям «сырых» (raw) данных? Чем может помочь отдельное аварийное сообщение 6-ти месячной давности? А годовой? Ресурсов для изучения и анализа этого непрерывно увеличивающегося количества информации, как правило, нет и не предвидится. Ляжет это все мертвым грузом, ежедневно потребляя ресурсы на свое обслуживание. При таких сроках давности имеет смысл анализировать тенденции, периодические колебания, средние значения и статистику по сбоям. Архитектурно, это уже прерогатива систем аналитической отчетности, а не систем мониторинга. Поэтому оптимальным вариантом является разделение задач между различными системами, а не обрушение всего потока требований на одну систему.
9. Почему так мало вопросов?
В силу того, что CA Spectrum является успешным коммерческим продуктом с 15-ти летней историей, за кадром остались вопросы такие, как управление правами пользователей, самодиагностика, масштабирование, надежность, список заказчиков, и многие другие. Они не упоминаются вследствие того, что на каждый этот вопрос идет прямая цитата из документации.
понедельник, 6 октября 2008 г.
Сайты для строительства
- АртБетон Основной производимой продукцией компании АртБетон является искусственный камень (декоративный камень), применяемый для облицовки стен зданий. Наряду с этим отделочным материалом компания производит: тонкостенный облицовочный кирпич, тротуарную плитку, брусчатку, бордюрные камни, разнообразные архитектурные элементы фасадов.
- Парфенон Сотрудники компании "ПАРФЕНОН" и предложат помощь - качественный, детально проработанный проект дома. В нашем Интернет-магазине можно приобрести готовые проекты домов, созданные лучшими архитекторами России и Европы. Это намного выгоднее, чем делать архитектурный проект под заказ.
- DYI (Сделай Сам) Ремонт и строительство своими руками
- Еврострой «Еврострой-Инжиниринг» осуществляет проектирование отопления, продажу, поставку и монтаж систем отопления и котельного оборудования: газовые котлы, водонагреватели, отопительные котлы Viessmann, Vaillant, радиаторы отопления Kermi, Sira, Global, Arbonia, полотенцесушители.
четверг, 25 сентября 2008 г.
Тестирование MiKTeX 2.7
Попробовал перейти на версию 2.7 с 2.4. В целом, нормально, даже pscyr заработал в полном объеме, но не удалось найти ответы на несколько критичных вопросов. Поэтому откатился обратно на 2.4 :(
Проблемы:
- Не удалось состыковать hyperref с caption2 (он уже устарел), даже с использованием hypcap. Патологически ругался на некорректное использование \caption.
- Файл miktex.ini уничножен. Как настроить систему на открытие в указанном редакторе файла .tex в случае ошибки (по клавише 'E') --- ответа нет нигде.
- Надо перепроверять классы, поскольку по умолчанию все компилируется в pdf.
- Почему-то, при компиляции в DVI, latex не может найти файлы .bb для форматов jpg, png. А это огромный минус. В 2.4 работает все корректно.
Возможно, что часть проблем связана с тем, что тестировал на глубоко кастомизированном классе.
P.S. Очень не понравилась теория уничтожения localtexmf и разбрасывания локальных файлов по различным путям в 'Documents and Settings'. Портабельность настроек резко снизилась.
P.P.S.
Есть версия (но не проверял пока), что не подхватывается графика именно из-за отстутствующих в '%texmf%\tex\latex\00miktex\graphics.cfg' строчек:
\DeclareGraphicsRule{.png}{eps}{.bb}{}%
\DeclareGraphicsRule{.jpg}{eps}{.bb}{}%
\DeclareGraphicsRule{.jpeg}{eps}{.bb}{}%
\DeclareGraphicsRule{.pnm}{eps}{.bb}{}%
\DeclareGraphicsRule{.ppm}{eps}{.bb}{}%
\DeclareGraphicsRule{.pgm}{eps}{.bb}{}%
\DeclareGraphicsRule{.pbm}{eps}{.bb}{}%
\DeclareGraphicsRule{.tif}{eps}{.bb}{}%
\DeclareGraphicsRule{.tiff}{eps}{.bb}{}%
\DeclareGraphicsRule{.bmp}{bmp}{.bb}{}%
среда, 17 сентября 2008 г.
Аутентификация и авторизация: основные понятия
Полезная вещь, хорошие определения.
Процесс регистрации пользователя в системе состоит из трех взаимосвязанных, выполняемых последовательно процедур: идентификации, аутентификации и авторизации.
Идентификация — это процедура распознавания субъекта по его идентификатору. В процессе регистрации субъект предъявляет системе свой идентификатор и она проверяет его наличие в своей базе данных. Субъекты с известными системе идентификаторами считаются легальными (законными), остальные субъекты относятся к нелегальным.
Аутентификация — процедура проверки подлинности субъекта, позволяющая достоверно убедиться в том, что субъект, предъявивший свой идентификатор, на самом деле является именно тем субъектом, идентификатор которого он использует. Для этого он должен подтвердить факт обладания некоторой информацией, которая может быть доступна только ему одному (пароль, ключ и т.п.).
Авторизация — процедура предоставления субъекту определенных прав доступа к ресурсам системы после прохождения им процедуры аутентификации. Для каждого субъекта в системе определяется набор прав, которые он может использовать при обращении к ее ресурсам.
Для того чтобы обеспечить управление и контроль над данными процедурами, дополнительно используются процессы администрирования и аудита.
Администрирование — процесс управления доступом субъектов к ресурсам системы.
Данный процесс включает в себя:
— создание идентификатора субъекта (создание учетной записи пользователя) в системе;
— управление данными субъекта, используемыми для его аутентификации (смена пароля, издание сертификата и т.п.);
— управление правами доступа субъекта к ресурсам системы.
Аудит — процесс контроля (мониторинга) доступа субъектов к ресурсам системы, включающий протоколирование действий субъектов при их доступе к ресурсам системы в целях обеспечения возможности обнаружения несанкционированных действий.
Процесс регистрации пользователя в системе состоит из трех взаимосвязанных, выполняемых последовательно процедур: идентификации, аутентификации и авторизации.
Идентификация — это процедура распознавания субъекта по его идентификатору. В процессе регистрации субъект предъявляет системе свой идентификатор и она проверяет его наличие в своей базе данных. Субъекты с известными системе идентификаторами считаются легальными (законными), остальные субъекты относятся к нелегальным.
Аутентификация — процедура проверки подлинности субъекта, позволяющая достоверно убедиться в том, что субъект, предъявивший свой идентификатор, на самом деле является именно тем субъектом, идентификатор которого он использует. Для этого он должен подтвердить факт обладания некоторой информацией, которая может быть доступна только ему одному (пароль, ключ и т.п.).
Авторизация — процедура предоставления субъекту определенных прав доступа к ресурсам системы после прохождения им процедуры аутентификации. Для каждого субъекта в системе определяется набор прав, которые он может использовать при обращении к ее ресурсам.
Для того чтобы обеспечить управление и контроль над данными процедурами, дополнительно используются процессы администрирования и аудита.
Администрирование — процесс управления доступом субъектов к ресурсам системы.
Данный процесс включает в себя:
— создание идентификатора субъекта (создание учетной записи пользователя) в системе;
— управление данными субъекта, используемыми для его аутентификации (смена пароля, издание сертификата и т.п.);
— управление правами доступа субъекта к ресурсам системы.
Аудит — процесс контроля (мониторинга) доступа субъектов к ресурсам системы, включающий протоколирование действий субъектов при их доступе к ресурсам системы в целях обеспечения возможности обнаружения несанкционированных действий.
пятница, 29 августа 2008 г.
Популяризация в PC Week
В 14-м номере сего года опубликовал статью Стандартизация -- путь к сокращению издержек. Интересно, какой процент читателей газеты доберется до статьи?
пятница, 23 мая 2008 г.
Нужен ли мониторинг ИТ инфраструктуры?
Надоело каждый раз рассказывать. Оформил в виде файла + добавил изыскания на предмет мониторинга различных приложений с использованием стандартного инструментария. Готово для запуска в оборот.
среда, 14 мая 2008 г.
Мониторинг ИТ-инфраструктуры
Листовки под формат A3 (для складывания в 4-х страничную шпаргалку). Верстка немного хромает, поскольку листовки разыменованные (убран текст) из соображений корректности. Интересны по содержательной части и как портфолио.
Понятно, что надо делать дальше. Но, увы, в сутках 24 часа.
- Обзорная концептуальная листовка
- Мониторинг сетевой и серверной компонент
- Сервис Деск
- Мониторинг распределенных приложений
Понятно, что надо делать дальше. Но, увы, в сутках 24 часа.
четверг, 24 апреля 2008 г.
Применение концепции SOA в OSS решениях
Из неопубликованного. Материал был написан в конце 2006-го года.
pdf версия
Не секрет, что для разворачивания в компании более или менее полноценного OSS решения, состоящего из нескольких модулей, необходимы четкое видение задач и целей менеджментом компании на несколько лет вперед и немалые финансовые и человеческие ресурсы для осуществления этих задач. Представители компании ТехноСерв АС, опираясь на значительный опыт внедрений OSS модулей, выделили бы в качестве базового набора модулей следующую связку: Inventory, Fault Management, Performance Management, Service Provisioning. На сегодняшний день, указанными качествами обладают, в основном, компании, развивающие бизнес в области телекоммуникаций. К моменту внедрения OSS, традиционный программно-аппаратный комплекс оператора, как правило, уже включает биллинговую систему (возможно, не одну, а несколько), ERP-систему, систему документооборота, а также децентрализованную кусочную систему управления оборудованием, поставляемую непосредственно самим производителем. Все эти системы должны быть так или иначе интегрированы между собой, а изменения в них, при необходимости, должны вноситься «на лету». OSS модули, по своему назначению, обязаны взаимодействовать с указанным программно-аппаратным комплексом. Более того, каждый модуль комплексного OSS решения может быть от разных производителей, тем самым еще более усложняя интеграционную задачу. И в таком непростом IT-ландшафте переход к концепции SOA позволяет понизить сложность поставленной задачи, поскольку архитектура SOA является слабосвязанной. Но для того, чтобы воспользоваться преимуществами сервис-ориентированной архитектуры, необходимо четко понимать, что она из себя представляет, какие дополнительные требования за собой влечет, какие имеет ограничения.
Построение технологических систем на основе предоставления сервисов (услуг), конечно же, не является революционно новым архитектурным решением; в обыденной жизни мы все так или иначе пользуемся услугами различных компаний, будь то такси или же мобильный оператор. Однако, поскольку все эти веяния идут из сферы информационных технологий, то под сервисами и архитектурой, как правило, понимаются особенности построения приложений и протоколов обмена между различными модулями. Тогда возникает вполне резонный вопрос со стороны опытных разработчиков и архитекторов: «Что такого нового вы представляете, чего мы еще не видели?» И они, действительно, правы. Если ограничиваться только узкими рамками разработки программного обеспечения, то за последние 20-25 лет было сменено несколько парадигм построения приложений и способов модульных кросскоммуникаций. Аббревиатур много: OVL, RPC, COM\DCOM, CORBA, RMI, … и что дальше? Чем SOA (а в IT-домене это, как правило, трансформируется в понятие web-services) отличается от всего вышеуказанного? Чего ради делать такие огромные вложения в новую архитектурную концепцию? Для ответа на все эти вопросы, и еще некоторые другие, будет посвящена оставшаяся часть статьи.
Здесь не предполагается каких-либо частных откровений о SOA, все в рамках стандартов. В качестве базового документа воспользуемся [Reference Model for Service Oriented Architecture 1.0. OASIS Standard, 12.10.2006].
Определение: Сервис-ориентированная архитектура (SOA) является парадигмой для организации и использования распределенных мощностей по реализации различных задач. Причем эти мощности могут находиться в ведении различных функциональных подразделений.
Заметим, что в этом определении ничего не сказано, что это архитектура построения приложений или порталов. Определение носит общий характер и может описывать процессы даже не связанные с IT, например, доставка почты или же производство обуви. В общем случае субъекты (люди или организации) создают возможности для решения задач или же поддержки процессов, возникающих в ходе существования бизнеса. И вполне естественным является возможность использования этих возможностей как другими людьми из этой же компании, так и другими компаниями.
Парадигма SOA имеет 3 ключевых понятия: видимость (visibility), взаимодействие (interaction) и эффект (effect).
Первое понятие, «visibility», описывает принцип доступности информации о существующих возможностях и возникающих потребностях. Т.е. каждая компания\подразделение\человек etc. предоставляют информацию о том, какую задачу они могут выполнить, как быстро они смогут ее сделать, сколько это может стоить и другие параметры. Одовременно с этим доступна информация о потенциальных пользователях и их потребностях.
Второе понятие, «interaction», описывает механизмы, которые предоставляет архитектура, для сопоставления возникающих потребностей с возможностями и наоборот.
Третье понятие, «effect», означает, что в результате взаимодействия пользователя с поставщиком той или иной услуги должно произойти изменение в окружающей среде. Парадигма SOA не занимается описанием изменений в закрытой области (например, в рамках компании-поставщика услуги). Важным фактом является то, что эффект происходит в разделяемой или пограничной среде, доступ к которой, потенциально, могут получить и другие пользователи. Ключевой аспект во всех взаимодействиях – использование возможностей без знания о внутреннем устройстве компании, предоставляющих эту возможность.
Последний пункт, который требует детализации — понятие «сервис». Согласно словарному определению «Сервис — работа по удовлетворению чьих н. бытовых, текущих или постоянных нужд». В общепринятом же понимании, термин «сервис» является комбинацией следующих положений:
• Возможность выполнения работы для 3-го лица.
• Спецификация работы предлагаемой для выполнения 3-му лицу.
• Предложение выполнения работы для 3-го лица.
Такая концепция позволяет достаточно четко провести разделение между потенциальными возможностями и способностью воплотить эти возможности в нечто реальное. Потребности и возможности существуют независимо от парадигмы SOA, и их значение неизменно. А вот определение понятия «сервис» в рамках SOA незначительно трансформируется, формализуется и принимает вид: «Сервис — это механизм посредством которого происходит связка потребностей в выполнении тех или иных функций и возможностей эти функции выполнить».
Каковы же основные отличия концепции SOA от ранее предложенных парадигм? Наиболее показательным примером будет сравнение в тематике проектирования программных комплексов\программирования, как наиболее передовой сферы, воплощающей лучшие архитектурные подходы в числе первых. К настоящему моменту лидирующее положение во многих предметных областях заняла объектно-ориентированная парадигма программирования (OO). Очевидно, что наиболее показательным и ярким будет сравнении SOA и OO.
В отличие от парадигмы OO, фокусирующейся на инкапсуляции данных и методов для манипуляции этими данными в единый объект, выступающей в качестве законченной конструктивной единицы, в SOA фокусируется на решении конкретной бизнес-задачи или предоставлении бизнес-функции, т.е. осуществляется переход от предмета к действию, имеющему реальный эффект. Различие проявляется следующими способами:
• В парадигме OO методы намеренно объединяются с данными. В таком контексте методы манипулирования могут представляться как некие свойства объекта. В рамках концепции SOA методы (сервисы) могут рассматриваться как способах доступа к данным, но фактически, жесткая связь между данными и методами может отсутствовать. Более того, для конечного потребителя сервисов, информация о связи между различными данными и методами доступа вообще может быть недоступна.
• В рамках OO использование объектов (т.е. вызов методов) возможно только после создания конкретного экземпляра на основе предопределенного шаблона. В SOA возможно использование сервисов\служб как только они становятся доступны. При этом для конечного пользователя сервисов отпадает необходимость в заботе о создании, проверки, размещении и пр. соответствующих структур данных.
• Объект в концепции OO представляет собой изнутри простую структуру данных без какой-либо семантической информации. В концепции SOA четкое описание семантики является одним из фундаментальных требований.
Как OO так и SOA есть способ отображения объектов и методов реального мира в рамки создаваемой модели. Важнейшим моментом является правильное понимание и корректное использование парадигмы. Таким образом вопросы «Что есть сервис?» и «Что есть объект?» лишены смысла без координатной привязки. Все может быть представлено как сервисом так и объектом. Основное значение выбора парадигмы — создание более ясной и простой картины. SOA обеспечивает более надежный фундамент для построения крупномасштабных систем потому как предоставляет модели, наиболее приближенные к способу организации человеческой деятельности.
Каким же образом парадигма SOA отличается от других подходов к организации и структурированию IT средств? По существу, есть две области, в которых подход SOA отличается от существующих концепций и фреймворков, лежащих в основе распределенных систем.
Во-первых, SOA отражает реальность границ собственности, являющуюся одним из базовых принципов архитектуры и дизайна систем. Этот факт непреложным образом вытекает из основных концепций SOA: видимости (visibility), взаимодействия (interaction) и влияния (effect). Для того чтобы в полной мере нести ответственность за такие концепции как доверие (trust), бизнес транзакции (business transactions), полномочия (authority), делегирование (delegation) и т.д. — требуются дополнительные платформы (framework) и элементы архитектуры. В контексте SOA, они, вероятно, будут представлены в рамках описаний и интерфейсов сервисов (служб). Существующие механизмы описаний и интерфейсов сервисов содержат в себе возможности для включения таких ссылок, и тем самым облегчают повторное использование внешних платформ (framework) и возможности взаимодействия систем, включенных в повторное использование.
Во-вторых, в парадигме SOA учтен печальный опыт по состыковке возможностей различных сервисных IT компаний и потребностей бизнеса. Так, два или более лица объединяются в контексте единого взаимодействия, подразумевающего обмен некими данными. Этот же принцип является основным при совершении торговых сделок в реальном мире. Таким образом, есть все предпосылки для предположения, что SOA будет успешно развиваться вне зависимости от существующих на рынке в данный момент услуг; технологии и концепции, заложенные в SOA, могут масштабироваться, следуя потребностям рынка.
Переход к сервис-ориентированной архитектуре следует воспринимать как неизбежную тенденцию. Многие крупнейшие производители программного обеспечения начали свое движение в этом направлении. В частности, компании Alcatel-Lucent, BEA, IBM и другие провозглашают переход к SOA как одно из приоритетнейших направлений. И это совершенно неудивительно, поскольку только за последние несколько лет рынке произошло значительное количество слияний. В частности, были объединены активы компании Cramer и Amdocs, Micromuse и IBM, MetaSolv и Oracle и пр… А объединение различных OSS-модулей под крылом одной компании воспринимается конечным заказчиком исключительно в одном ключе: «модули одного производителя обязаны иметь ‘out-of-the-box’ интеграцию». Но, поскольку, эти модули первоначально разрабатывались в различных коллективах, в различные моменты времени и с использованием различных архитектурных подходов, это высказывание не соответствует действительности. И в задачу производителя теперь входит создание механизмов интеграции приобретенных модулей, что, зачастую, является совсем нетривиальной задачей. И в этот момент, звезда «SOA» начинает сиять особенно ярко. Именно благодаря слабосвязанности архитектуры SOA, производители OSS продуктов получают возможность путем незначительных вложений (относительно стандартных методов разработки ПО) создать интегрированный комплекс.
Для корректности следует отметить, что при переходе к приземленным вопросам, например, к вопросам интеграции, терминология меняется. SOA является более философским термином, а для решения конкретных интеграционных задач используется инструментарий, именуемый Enterprise Service Bus (ESB). Enterprise Service Bus является брокером, поддерживающим вызов сервисов\служб в синхронном и асинхронном режимах. Она разрешает передачу данных и уведомлений о событиях между отдельными модулями или приложениями. ESB помогает потребителям найти провайдеров сервисов\служб и управляет деталями взаимодействия между ними, все в полном соответствии с концепцией SOA.
Как правило, потребители сервисов\служб сталкиваются с искусственным выбором между двумя стилями взаимодействия: синхронным или асинхронным. Синхронная ESB является шлюзом служб, который выступает как центральный координатор множества служб. Асинхронная ESB является шиной сообщений, чьи службы поддерживают также способности Web-служб к самоописанию и обнаруживаемости. Для разрешения этой дилеммы, ведущие производители ESB, такие как IBM (WebSphere), BEA (WebLogic), Oracle (Oracle ESB), включают в свои продукты поддержку обоих режимов и, фактически, могут предложить две модели вызова для одной и той же службы. В этом случае потребитель при запросе адреса службы сможет получить два варианта: один для синхронного режима, второй для асинхронного, что, несомненно, повышает гибкость ESB как интеграционного инструмента. Исходя из потребностей, потребитель сможет выбрать модель вызова, которая ему больше всего подходит. Важно отметить, что независимо от выбранной модели вызова, выполняться будет одна и та же служба, хотя конкретный экземпляр провайдера службы может при этом и отличаться.
Как обычно, каждое архитектурное решение имеет свои минусы. В случае с SOA уверенно можно сказать, что плюсов от перехода к SOA будет существенно больше, чем минусов. Поэтому только заострим внимание на ключевых технических моментах, которые должны быть детально проработаны до перехода на SOA. Если эти моменты оставить в тени, то переход к SOA может стать неоправданной тратой средств.
• Для реализации SOA в обязательном порядке потребуется модель сообщений для обмена информацией между модулями.
• Для получения выгоды использования SOA необходимо согласование стандартов сообщений большого числа разнородных систем, участвующих в интеграционном процессе.
• Отсутствие четкого долгосрочного планирования при интеграции может превратить механизм версионности сообщений, как раз и предназначенный для ослабления межмодульной связи, превратить в жесткую сцепку.
• Реализации могут зависеть от специфики используемой ESB.
• Требуется дополнительное программно-аппаратное обеспечение.
• Вводится очередной абстрактный уровень обработки и трансляции сообщений, со всеми вытекающими последствиями.
• ROI архитектурных решений с использованием SOA, как правило, начинает проявляться только при их тиражируемости.
• Для эффективного осуществления требуется наличие в компании четкой стратегии развития и определенной зрелости модели управления ИТ.
В заключение еще раз отметим, что в свете означенных тенденций, демистификации концепций, четкое и понятное формулирование целей, стандартизация подходов, существенно сокращают издержки перехода к системам, построенным с использованием парадигмы сервис-ориентированной архитектуры, и уменьшают риски возможных провалов.
pdf версия
Не секрет, что для разворачивания в компании более или менее полноценного OSS решения, состоящего из нескольких модулей, необходимы четкое видение задач и целей менеджментом компании на несколько лет вперед и немалые финансовые и человеческие ресурсы для осуществления этих задач. Представители компании ТехноСерв АС, опираясь на значительный опыт внедрений OSS модулей, выделили бы в качестве базового набора модулей следующую связку: Inventory, Fault Management, Performance Management, Service Provisioning. На сегодняшний день, указанными качествами обладают, в основном, компании, развивающие бизнес в области телекоммуникаций. К моменту внедрения OSS, традиционный программно-аппаратный комплекс оператора, как правило, уже включает биллинговую систему (возможно, не одну, а несколько), ERP-систему, систему документооборота, а также децентрализованную кусочную систему управления оборудованием, поставляемую непосредственно самим производителем. Все эти системы должны быть так или иначе интегрированы между собой, а изменения в них, при необходимости, должны вноситься «на лету». OSS модули, по своему назначению, обязаны взаимодействовать с указанным программно-аппаратным комплексом. Более того, каждый модуль комплексного OSS решения может быть от разных производителей, тем самым еще более усложняя интеграционную задачу. И в таком непростом IT-ландшафте переход к концепции SOA позволяет понизить сложность поставленной задачи, поскольку архитектура SOA является слабосвязанной. Но для того, чтобы воспользоваться преимуществами сервис-ориентированной архитектуры, необходимо четко понимать, что она из себя представляет, какие дополнительные требования за собой влечет, какие имеет ограничения.
Построение технологических систем на основе предоставления сервисов (услуг), конечно же, не является революционно новым архитектурным решением; в обыденной жизни мы все так или иначе пользуемся услугами различных компаний, будь то такси или же мобильный оператор. Однако, поскольку все эти веяния идут из сферы информационных технологий, то под сервисами и архитектурой, как правило, понимаются особенности построения приложений и протоколов обмена между различными модулями. Тогда возникает вполне резонный вопрос со стороны опытных разработчиков и архитекторов: «Что такого нового вы представляете, чего мы еще не видели?» И они, действительно, правы. Если ограничиваться только узкими рамками разработки программного обеспечения, то за последние 20-25 лет было сменено несколько парадигм построения приложений и способов модульных кросскоммуникаций. Аббревиатур много: OVL, RPC, COM\DCOM, CORBA, RMI, … и что дальше? Чем SOA (а в IT-домене это, как правило, трансформируется в понятие web-services) отличается от всего вышеуказанного? Чего ради делать такие огромные вложения в новую архитектурную концепцию? Для ответа на все эти вопросы, и еще некоторые другие, будет посвящена оставшаяся часть статьи.
Здесь не предполагается каких-либо частных откровений о SOA, все в рамках стандартов. В качестве базового документа воспользуемся [Reference Model for Service Oriented Architecture 1.0. OASIS Standard, 12.10.2006].
Определение: Сервис-ориентированная архитектура (SOA) является парадигмой для организации и использования распределенных мощностей по реализации различных задач. Причем эти мощности могут находиться в ведении различных функциональных подразделений.
Заметим, что в этом определении ничего не сказано, что это архитектура построения приложений или порталов. Определение носит общий характер и может описывать процессы даже не связанные с IT, например, доставка почты или же производство обуви. В общем случае субъекты (люди или организации) создают возможности для решения задач или же поддержки процессов, возникающих в ходе существования бизнеса. И вполне естественным является возможность использования этих возможностей как другими людьми из этой же компании, так и другими компаниями.
Парадигма SOA имеет 3 ключевых понятия: видимость (visibility), взаимодействие (interaction) и эффект (effect).
Первое понятие, «visibility», описывает принцип доступности информации о существующих возможностях и возникающих потребностях. Т.е. каждая компания\подразделение\человек etc. предоставляют информацию о том, какую задачу они могут выполнить, как быстро они смогут ее сделать, сколько это может стоить и другие параметры. Одовременно с этим доступна информация о потенциальных пользователях и их потребностях.
Второе понятие, «interaction», описывает механизмы, которые предоставляет архитектура, для сопоставления возникающих потребностей с возможностями и наоборот.
Третье понятие, «effect», означает, что в результате взаимодействия пользователя с поставщиком той или иной услуги должно произойти изменение в окружающей среде. Парадигма SOA не занимается описанием изменений в закрытой области (например, в рамках компании-поставщика услуги). Важным фактом является то, что эффект происходит в разделяемой или пограничной среде, доступ к которой, потенциально, могут получить и другие пользователи. Ключевой аспект во всех взаимодействиях – использование возможностей без знания о внутреннем устройстве компании, предоставляющих эту возможность.
Последний пункт, который требует детализации — понятие «сервис». Согласно словарному определению «Сервис — работа по удовлетворению чьих н. бытовых, текущих или постоянных нужд». В общепринятом же понимании, термин «сервис» является комбинацией следующих положений:
• Возможность выполнения работы для 3-го лица.
• Спецификация работы предлагаемой для выполнения 3-му лицу.
• Предложение выполнения работы для 3-го лица.
Такая концепция позволяет достаточно четко провести разделение между потенциальными возможностями и способностью воплотить эти возможности в нечто реальное. Потребности и возможности существуют независимо от парадигмы SOA, и их значение неизменно. А вот определение понятия «сервис» в рамках SOA незначительно трансформируется, формализуется и принимает вид: «Сервис — это механизм посредством которого происходит связка потребностей в выполнении тех или иных функций и возможностей эти функции выполнить».
Каковы же основные отличия концепции SOA от ранее предложенных парадигм? Наиболее показательным примером будет сравнение в тематике проектирования программных комплексов\программирования, как наиболее передовой сферы, воплощающей лучшие архитектурные подходы в числе первых. К настоящему моменту лидирующее положение во многих предметных областях заняла объектно-ориентированная парадигма программирования (OO). Очевидно, что наиболее показательным и ярким будет сравнении SOA и OO.
В отличие от парадигмы OO, фокусирующейся на инкапсуляции данных и методов для манипуляции этими данными в единый объект, выступающей в качестве законченной конструктивной единицы, в SOA фокусируется на решении конкретной бизнес-задачи или предоставлении бизнес-функции, т.е. осуществляется переход от предмета к действию, имеющему реальный эффект. Различие проявляется следующими способами:
• В парадигме OO методы намеренно объединяются с данными. В таком контексте методы манипулирования могут представляться как некие свойства объекта. В рамках концепции SOA методы (сервисы) могут рассматриваться как способах доступа к данным, но фактически, жесткая связь между данными и методами может отсутствовать. Более того, для конечного потребителя сервисов, информация о связи между различными данными и методами доступа вообще может быть недоступна.
• В рамках OO использование объектов (т.е. вызов методов) возможно только после создания конкретного экземпляра на основе предопределенного шаблона. В SOA возможно использование сервисов\служб как только они становятся доступны. При этом для конечного пользователя сервисов отпадает необходимость в заботе о создании, проверки, размещении и пр. соответствующих структур данных.
• Объект в концепции OO представляет собой изнутри простую структуру данных без какой-либо семантической информации. В концепции SOA четкое описание семантики является одним из фундаментальных требований.
Как OO так и SOA есть способ отображения объектов и методов реального мира в рамки создаваемой модели. Важнейшим моментом является правильное понимание и корректное использование парадигмы. Таким образом вопросы «Что есть сервис?» и «Что есть объект?» лишены смысла без координатной привязки. Все может быть представлено как сервисом так и объектом. Основное значение выбора парадигмы — создание более ясной и простой картины. SOA обеспечивает более надежный фундамент для построения крупномасштабных систем потому как предоставляет модели, наиболее приближенные к способу организации человеческой деятельности.
Каким же образом парадигма SOA отличается от других подходов к организации и структурированию IT средств? По существу, есть две области, в которых подход SOA отличается от существующих концепций и фреймворков, лежащих в основе распределенных систем.
Во-первых, SOA отражает реальность границ собственности, являющуюся одним из базовых принципов архитектуры и дизайна систем. Этот факт непреложным образом вытекает из основных концепций SOA: видимости (visibility), взаимодействия (interaction) и влияния (effect). Для того чтобы в полной мере нести ответственность за такие концепции как доверие (trust), бизнес транзакции (business transactions), полномочия (authority), делегирование (delegation) и т.д. — требуются дополнительные платформы (framework) и элементы архитектуры. В контексте SOA, они, вероятно, будут представлены в рамках описаний и интерфейсов сервисов (служб). Существующие механизмы описаний и интерфейсов сервисов содержат в себе возможности для включения таких ссылок, и тем самым облегчают повторное использование внешних платформ (framework) и возможности взаимодействия систем, включенных в повторное использование.
Во-вторых, в парадигме SOA учтен печальный опыт по состыковке возможностей различных сервисных IT компаний и потребностей бизнеса. Так, два или более лица объединяются в контексте единого взаимодействия, подразумевающего обмен некими данными. Этот же принцип является основным при совершении торговых сделок в реальном мире. Таким образом, есть все предпосылки для предположения, что SOA будет успешно развиваться вне зависимости от существующих на рынке в данный момент услуг; технологии и концепции, заложенные в SOA, могут масштабироваться, следуя потребностям рынка.
Переход к сервис-ориентированной архитектуре следует воспринимать как неизбежную тенденцию. Многие крупнейшие производители программного обеспечения начали свое движение в этом направлении. В частности, компании Alcatel-Lucent, BEA, IBM и другие провозглашают переход к SOA как одно из приоритетнейших направлений. И это совершенно неудивительно, поскольку только за последние несколько лет рынке произошло значительное количество слияний. В частности, были объединены активы компании Cramer и Amdocs, Micromuse и IBM, MetaSolv и Oracle и пр… А объединение различных OSS-модулей под крылом одной компании воспринимается конечным заказчиком исключительно в одном ключе: «модули одного производителя обязаны иметь ‘out-of-the-box’ интеграцию». Но, поскольку, эти модули первоначально разрабатывались в различных коллективах, в различные моменты времени и с использованием различных архитектурных подходов, это высказывание не соответствует действительности. И в задачу производителя теперь входит создание механизмов интеграции приобретенных модулей, что, зачастую, является совсем нетривиальной задачей. И в этот момент, звезда «SOA» начинает сиять особенно ярко. Именно благодаря слабосвязанности архитектуры SOA, производители OSS продуктов получают возможность путем незначительных вложений (относительно стандартных методов разработки ПО) создать интегрированный комплекс.
Для корректности следует отметить, что при переходе к приземленным вопросам, например, к вопросам интеграции, терминология меняется. SOA является более философским термином, а для решения конкретных интеграционных задач используется инструментарий, именуемый Enterprise Service Bus (ESB). Enterprise Service Bus является брокером, поддерживающим вызов сервисов\служб в синхронном и асинхронном режимах. Она разрешает передачу данных и уведомлений о событиях между отдельными модулями или приложениями. ESB помогает потребителям найти провайдеров сервисов\служб и управляет деталями взаимодействия между ними, все в полном соответствии с концепцией SOA.
Как правило, потребители сервисов\служб сталкиваются с искусственным выбором между двумя стилями взаимодействия: синхронным или асинхронным. Синхронная ESB является шлюзом служб, который выступает как центральный координатор множества служб. Асинхронная ESB является шиной сообщений, чьи службы поддерживают также способности Web-служб к самоописанию и обнаруживаемости. Для разрешения этой дилеммы, ведущие производители ESB, такие как IBM (WebSphere), BEA (WebLogic), Oracle (Oracle ESB), включают в свои продукты поддержку обоих режимов и, фактически, могут предложить две модели вызова для одной и той же службы. В этом случае потребитель при запросе адреса службы сможет получить два варианта: один для синхронного режима, второй для асинхронного, что, несомненно, повышает гибкость ESB как интеграционного инструмента. Исходя из потребностей, потребитель сможет выбрать модель вызова, которая ему больше всего подходит. Важно отметить, что независимо от выбранной модели вызова, выполняться будет одна и та же служба, хотя конкретный экземпляр провайдера службы может при этом и отличаться.
Как обычно, каждое архитектурное решение имеет свои минусы. В случае с SOA уверенно можно сказать, что плюсов от перехода к SOA будет существенно больше, чем минусов. Поэтому только заострим внимание на ключевых технических моментах, которые должны быть детально проработаны до перехода на SOA. Если эти моменты оставить в тени, то переход к SOA может стать неоправданной тратой средств.
• Для реализации SOA в обязательном порядке потребуется модель сообщений для обмена информацией между модулями.
• Для получения выгоды использования SOA необходимо согласование стандартов сообщений большого числа разнородных систем, участвующих в интеграционном процессе.
• Отсутствие четкого долгосрочного планирования при интеграции может превратить механизм версионности сообщений, как раз и предназначенный для ослабления межмодульной связи, превратить в жесткую сцепку.
• Реализации могут зависеть от специфики используемой ESB.
• Требуется дополнительное программно-аппаратное обеспечение.
• Вводится очередной абстрактный уровень обработки и трансляции сообщений, со всеми вытекающими последствиями.
• ROI архитектурных решений с использованием SOA, как правило, начинает проявляться только при их тиражируемости.
• Для эффективного осуществления требуется наличие в компании четкой стратегии развития и определенной зрелости модели управления ИТ.
В заключение еще раз отметим, что в свете означенных тенденций, демистификации концепций, четкое и понятное формулирование целей, стандартизация подходов, существенно сокращают издержки перехода к системам, построенным с использованием парадигмы сервис-ориентированной архитектуры, и уменьшают риски возможных провалов.
среда, 23 апреля 2008 г.
Полезные пакеты LaTeX
- dirtree -- классное оформление директори в виде дерева
- multicap -- для заголовков в многоколоночном режиме
- niceframe -- красивые рамочки
- parallel -- двуязычные двухколоночные документы
- polytable -- расширенный tabular
- progress -- рисование progress bar
- pinlabel -- расстановка символов поверх любого рисунка
- typogrid -- grid включить на страницу
- wordlike -- стилевик а-ля ворд
- glossary -- создание глоссария. весьма продвинуто
- crop -- значки для обрезки страницы
- pdfpages -- вставка в документ страниц из других pdf файлов
- setspace -- изменение межстрочного интервала для фрагментов текста
- biblatex -- Bibliographies in LaTeX using BibTeX for sorting only
- etoolbox -- package is a toolbox of programming facilities geared primarily towards LaTeX class and package authors. Используется biblatex-ом
- pdfcrop.pl -- обрезка pdf файлов
- path
- url
- multicol
- regcount
- refcheck
- bophook
- boites
- breqn
- draftcopy
- drafthead
- см sttols.html
- sublabel
- showkeys
- showlabels
- smartref
- textpos
- textfit
- textcase
- truncate
- vruler
- btxbst (общий для бибилографических стилей)
Книги по методологии разработки ПО
Было прочитано и что я бы рекомедовал иметь под рукой:
Карл И. Вигерс. «Разработка требований к программному обеспечению»
Эдвард Йордон. «Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте»
Фредерик Брукс. «Мифический человеко - месяц или Как создаются программные системы»
Алан Купер. «Психбольница в руках пациентов»
Ларри Константин. «Человеческий фактор в программировании»
Том Демарко, Тимоти Листер. «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения»
Том Демарко, Тимоти Листер. «Человеческий фактор: успешные проекты и команды»
Том ДеМарко. Deadline. «Роман об управлении проектами»
Фергус О`Коннэл. «Как успешно руководить проектами. Серебряная пуля. 3-е издание»
Дж. Ханк Рейнвотер. «Как пасти котов. Наставление для программистов, руководящих другими программистами»
Николас Дж. Карр. «Блеск и нищета информационных технологий. Почему ИТ не являются конкурентным преимуществом»
Э. Хант, Д. Томас. «Программист-прагматик. Путь от подмастерья к мастеру»
Джоэл Спольски. «Лучшие примеры разработки ПО»
Джоэл Спольски. «Джоэл о программировании»
Стив Макконнелл. «Профессиональная разработка программного обеспечения»
Стив Макконнелл. «Сколько стоит программный проект»
Стив Макконнелл. «Остаться в живых! Руководство для менеджера программных проектов»
Джим и Мишель Мак-Карти. «Программируем командный дух»
Дж. Фридл «Регулярные выражения»
Г. Буч, А. Якобсон, Дж. Рамбо. «UML. Классика CS. Издание второе»
воскресенье, 6 апреля 2008 г.
Передача презентаций
Если презентация рисовалась в PowerPoint, да еще и с анимацией, то публиковать ее в pdf выглядит немного кощунственно. Что делать, если исходник передавать тоже не хочется?
Все достаточно просто:
Все достаточно просто:
- Используем программу FlashSpring (русскоязычный сайт или англоязычный) для преобразования .ppt->.swf
- Защищаем ресурсы SWF файла обфускатором, например SWF Encrypt
- Для компании достаточно одного экземпляра той и другой программы. Все ставится на машине соответствующего дизайнера, например.
- Стоимость первой программы 2000р, второй $125 USD. Итого, ~$210. Разве это цена вопроса?
Подписаться на:
Сообщения (Atom)