Аналитик промежуточного программного обеспечения

Аналитики промежуточного ПО — это инженеры-программисты , специализирующиеся на продуктах, которые соединяют две разные компьютерные системы. Эти продукты могут быть с открытым исходным кодом или фирменными. Как следует из термина, программное обеспечение, инструменты и технологии, используемые аналитиками промежуточного ПО, находятся «посередине», между двумя или более системами; их цель — дать возможность двум системам общаться и обмениваться информацией.

Роли и обязанности

Аналитики промежуточного ПО [1] рассматривают систему систем . [2] Они решают технические проблемы, которые включают в себя крупномасштабные междисциплинарные задачи с множественными, гетерогенными, распределенными системами, которые встроены в сети на нескольких уровнях. [3] Аналитики промежуточного ПО обладают и поддерживают профессионализм в технологиях промежуточного ПО. Промежуточное ПО — это компьютерное программное обеспечение, которое соединяет программные компоненты или приложения. Центральной темой большинства ролей аналитиков промежуточного ПО является способность сформулировать, почему сервисно-ориентированная архитектура ( SOA ) важна для бизнеса. [4]

Лучшие практики внедрения

Лучшие практики промежуточного ПО способствуют удобству использования и обслуживания обслуживаемых систем. Здесь приведены несколько примеров лучших практик, чтобы дать некоторое представление о том, как промежуточное ПО учитывает ключевые принципы вычислений на основе стандартов .

Одной из распространенных проблем для промежуточного ПО является способ, которым пользовательские приложения настроены так, что ссылки на очередь обходят определения псевдонимов очереди, ссылающиеся непосредственно на локальное или удаленное определение очереди. Такой обход псевдонима очереди отклоняется от передовой практики и должен быть исправлен, когда администратор и/или программист смогут исправить это в пределах параметров времени и области действия. Все ссылки из пользовательских приложений должны указывать на псевдонимы очереди. Тогда псевдонимы очереди должны указывать на определенную локальную или удаленную очередь.

Псевдонимы очереди [5] обеспечивают гибкость для администраторов промежуточного программного обеспечения для быстрого решения или устранения проблем с производством. Используя псевдонимы очереди, администраторы промежуточного программного обеспечения могут перенаправлять поток сообщений в случае возникновения проблем с обслуживанием без внесения изменений в пользовательское приложение. Например, если локальная очередь переполнена, администратор промежуточного программного обеспечения может изменить псевдоним очереди, чтобы он указывал на временную локальную очередь, тем самым позволяя пользовательскому приложению продолжать свою обработку без прерывания, пока не будет устранена основная причина.

Указывая все пользовательские ссылки на приложения на псевдонимы очередей, он сохраняет гибкость, которую администраторы промежуточного ПО должны были бы иметь для решения проблем производства, которые могут возникнуть. Если бы не соблюдалась лучшая практика псевдонимов очередей, способность администратора промежуточного ПО помочь с остановкой производства была бы затруднена.

Навыки

Очередь сообщений («MQ») — это технология промежуточного программного обеспечения, которая значительно упрощает связь между узлами системы и между узлами, которые соединяют системы вместе. Консультанты по информационным системам используют очередь сообщений в качестве основы своих навыков. На этой основе консультанты по информационным системам добавляют управление рабочим процессом, брокерскую обработку сообщений и реализации J2EE с использованием виртуальных машин Java ( JVM ) и Message Driven Beans (MDB).

Вероятно, наиболее важным навыком, который использует аналитик промежуточного ПО, является не технический, а, безусловно, культурный. SOA требует от людей по-другому думать о бизнесе и технологиях. Вместо того чтобы думать в первую очередь о технологиях, аналитики промежуточного ПО должны сначала думать в терминах бизнес-функций или услуг. Ожидается, что принятие SOA изменит ИТ-отделы бизнеса, создав ИТ-организации, ориентированные на сервисы (а не на технологии). Аналитики промежуточного ПО выполняют важную евангелизацию этой концепции.

Корпоративная сервисная шина является основным элементом любой SOA . ESB обеспечивают связь «любой с любым» между сервисами внутри компании и за ее пределами для подключения к торговым партнерам компании. Поэтому аналитики промежуточного ПО должны быть в первую очередь квалифицированными в концепциях SOA и корпоративной сервисной шины . Аналитики промежуточного ПО полагаются на эталонную архитектуру SOA для разработки среды SOA , которая соответствует потребностям и приоритетам компании. ESB является частью этой эталонной архитектуры и обеспечивает основу SOA, но сама по себе не считается SOA.

Проблемы безопасности

Общие общепринятые практики

Поскольку промежуточное ПО является кроссплатформенным инструментом, ожидается, что ваши аналитики промежуточного ПО будут иметь высокую квалификацию. Люди, которые проектируют и реализуют поток сообщений промежуточного ПО, должны полностью понимать, как работает модель безопасности на каждой целевой платформе. Это может включать Windows , Unix , z/OS или IBM i .

Промежуточное ПО защищает данные при передаче с помощью технологий PKI и SSL . Сертификаты безопасности закупаются у центра сертификации и регулярно развертываются и обновляются на серверах. Это защищает данные во время передачи, когда они покидают один сервер и поступают на следующий сервер в цепочке. Это не защищает данные, пока они находятся в состоянии покоя.

Дополнительная безопасность передачи может дополнять основные меры SSL, которые существуют на вашем сервере. Это аутентификация клиента SSL, фильтрация DN, проверка CRL по LDAP и криптографическое оборудование (шифрование на уровне IPSEC). Этот тип безопасности называется «безопасностью на уровне границы», потому что он защищает данные только с момента, когда они покидают ваши границы, и до тех пор, пока они не попадут на границы вашего торгового партнера. Он не защищает данные после того, как данные пересекли границу. IPSEC — наиболее эффективный и наименее затратный метод защиты. SSL — это золотая середина, с балансом между гибкостью, потреблением ресурсов и временем передачи.

Когда данные находятся в состоянии покоя в очередях, они не защищены MQ. То есть данные находятся в виде «открытого текста». Поэтому, если данные, содержащиеся в сообщениях, являются конфиденциальными, то необходимо использовать шифрование данных на уровне приложений . Примерами данных, которые могут быть защищены с помощью этой стратегии, являются банковские данные (номера счетов, банковские транзакции и т. д.). Безопасность транзакций на уровне приложений является наиболее надежной формой защиты, но также и наиболее затратной с точки зрения потребления ресурсов ЦП и пропускной способности ввода-вывода как отправляющего, так и принимающего серверов. Она также является наименее эффективной.

Каналы данных промежуточного ПО могут быть настроены для обеспечения различных степеней защиты. Пара каналов отправителя/получателя может быть настроена для обеспечения безопасности на транспортном уровне IPSEC без использования SSL. Вторая пара каналов отправителя/получателя может быть настроена для обеспечения безопасности SSL на уровне граница-к-границе без использования IPSEC. Третья пара каналов отправителя/получателя может быть настроена для обеспечения шифрования на уровне приложений. Используя эту схему, вы предоставляете широкий выбор механизмов защиты, из которых ваши приложения могут выбирать во время выполнения. Это дает приложениям возможность достичь наилучшей безопасности при необходимости или более эффективной безопасности, когда данные не столь конфиденциальны.

Соображения, связанные с HIPAA

Если ваше предприятие обрабатывает данные HIPAA ePHI , то ваши аналитики промежуточного программного обеспечения должны знать и понимать требования, установленные законом . [6] Неспособность защитить данные в состоянии покоя может подвергнуть вашу организацию штрафам и санкциям, налагаемым федеральным правительством или другим органом. [7] Для этого требуется шифрование данных на уровне приложений перед доставкой данных в систему очередей для транспортировки. [8]

Системным администраторам, включая аналитиков промежуточного ПО, не разрешается просматривать незащищенные данные ePHI. Поэтому, когда данные ePHI присутствуют в любой информационной системе, они должны быть защищены от возможности администратора просматривать их. Не допускается хранение данных ePHI в очереди незащищенными.

Смотрите также

Ссылки

  1. ^ "Middleware Analyst, Emerging Technology". Архивировано из оригинала 20-08-2010 . Получено 04-09-2009 .
  2. ^ Агравал, М.; Граба, Л. (2005). «Требования к распределенному промежуточному программному обеспечению для разрозненного авионики и управляющего программного обеспечения». 24-я конференция по цифровым авиационным системам . Том 2. стр. 8.B.4-1-8.B.4-5. doi :10.1109/DASC.2005.1563466. ISBN 0-7803-9307-4. S2CID  23776303.
  3. ^ Тай, Стефан; Лампартер, Штеффен (2008). «Моделирование услуг – междисциплинарная перспектива». Коммуникации в области компьютерных и информационных наук . 8 : 8–11 . doi :10.1007/978-3-540-78999-4_2. ISBN 978-3-540-78998-7.
  4. ^ «Удалено».
  5. ^ "Руководство по системному администрированию". Архивировано из оригинала 2003-09-27 . Получено 2009-09-04 .
  6. ^ "Архивная копия" (PDF) . Архивировано из оригинала (PDF) 2009-04-19 . Получено 2009-05-04 .{{cite web}}: CS1 maint: архивная копия как заголовок ( ссылка )
  7. ^ "HIPAA: Закон о переносимости и подотчетности медицинского страхования". Архивировано из оригинала 2009-04-22 . Получено 2009-05-04 .
  8. ^ "Us-en_software_HP" . 9 ноября 2020 г.
Взято с "https://en.wikipedia.org/w/index.php?title=Middleware_analyst&oldid=1108442622"