Накопленные предприятиями ИТ практически никогда не выходят из обращения, а становятся участниками бесконечной игры под названием «Вырезать-вставить», в которую играют разработчики. В рамках непрерывного процесса интеграции, будь то добавление новых приложений или комплексное преобразование унаследованных приложений в сервис-ориентированные, предприятия постоянно вынуждены преодолевать различного рода препятствия.

В поисках путей решения интеграционных проблем предприятия могут попасть в ловушки заманчивых проприетарных решений, касающихся SOA, ESB или интеграции в целом. Тактика большинства вендоров такова, что в результате их клиенты оказываются заложниками закрытых стандартов, излишнего функционала, а так же вынуждены тратить астрономические суммы на лицензирование и услуги.

1. Ловушка для разработчиков

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

2. Ловушка для бюджета

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

3. Ловушка для времени

Услуги специалистов по проприетарным EAI, ESB, SOA и продуктам для интеграции стоят очень дорого. 50% общего дохода некоторых компаний составляет прибыль от предоставляемых услуг по продуктам, что даже заставляет усомниться в качестве ПО. По мере возникновения проблем, пользователи должны предоставить производителю их описание. Поскольку пользователь не видит кода, для понимания источника проблемы ему придется изучить очень большой объем информации, поэтому единственное, что остается – это сообщить о проблеме и ждать ответа. Но, когда проблемы касаются функциональности ПО предприятия, ждать совсем некогда.

4. Ловушка для доступа

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

5. Ловушка для интеграции

Недостатком эволюции SOA/ESB/WS является то, что для осуществления интеграции, где применение всех этих технологий были бы максимально полезным, придется заплатить вендору приличную сумму. Бывает так, что клиенту необходимы лишь средства для базовой интеграции, и ему не нежны ни BPEL, ни оркестровка, однако вендор может предложить ему полный комплект для реализации SOA. В результате клиент переплачивает за то, чем он, возможно, никогда не будет пользоваться. Но вендоры хотят, чтобы клиент подстроил свою инфраструктуру под их программные средства, а не наоборот.

Open source альтернативы

Open Source предлагает пользователям альтернативные подходы к интеграции.

Камнем преткновения многих предприятий в процессе интеграции оказывается отсутствие у вендоров каких-либо общих архитектурных подходов. Однако open source инструменты, такие как, например, Mule, позволяют архитекторам использовать типичную ESB-топологию. Некоторые используют ESB без шины и объединяют сервисы предприятия посредством Web-сервисов, HTTP или путем передачи сообщений. Разумное проектирование заключается в применении только тех технологий, которые удовлетворяют всем интеграционным потребностям клиента, а не в навязывании своих стандартов, которые в последствии станут преградой для развития архитектуры.

Open source обеспечивает прозрачность, что позволяет не только видеть код и обнаруживать “баги”, но и устранять их без посредников.

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

Проще говоря, интеграционные open source платформы позволяют повторно использовать имеющиеся у предприятия ИТ и предоставляют клиенту свободу выбора инструментов и дополнительных методик.

По материалам Dr.Dobb’s Portal

Комментарии