Как вы осуществляете системную интеграцию?

Question

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

Мне интересно, решаете ли вы эту проблему, разрабатывая свои собственные небольшие сервисы, которые затем подключаются, или вы используете какой-то продукт (WebSphere, BizTalk, Мул и т. д).Я также думаю, что было бы интересно узнать, как такие решения управляются и обслуживаются (как вы решаете проблемы безопасности, инструментирования и т. д. и т. д.), какие проблемы вы столкнулись с вашим решением и так далее.

Answer 1

вау - Хорошо - об этом будет опубликовано сообщение, но оно будет большим.

Интеграция должна быть подкреплена глубоким пониманием бизнесом преимуществ - разберитесь с операционной моделью - поскольку бизнесу может действительно потребоваться стандартизация вместо интеграции, поскольку это может быть дорогостоящим - именно поэтому большинство SOA терпят неудачу! Архитектура предприятия:Ведущий бизнес из бизнеса от ИТ -автор:Жанна В.Росс

Если интеграция необходима, вам нужно выбрать тип интеграции.

Каковы показатели скорости и производительности?

У нас есть .NET SOA с составным приложением, использующим BizTalk 2006, и веб-сервисы с бизнес-приложениями.Производительность приложения на составном конце (потреблении) — ограничена скоростью веб-сервисов (и их реализации) в бизнес-приложении!Нам нужна рентабельность результатов менее 3 секунд — список случаев.Не удалось добиться этого в веб-сервисах, поэтому нам нужно напрямую обратиться к базе данных для первоначального поиска.Затем через веб-сервисы для создания дел.Здесь проблемой становятся затраты и техническое обслуживание.

Суть здесь в том, чтобы взглянуть на критерии производительности в спецификациях и бизнес-требованиях. Это поможет определить тип интеграции, которую вам необходимо выполнить — веб-службы (HTTP), удаление файлов/EDI и т. д.

Функционально для интеграции нужно потом посмотреть точки сбоя в предлагаемой архитектуре - так как это приведет к цепочке ответственности в SLA/OLA.Возможно, вам придется обернуть точки интеграции/сбоя в вещи, которые вы контролируете.

По аналогии с интеграцией с направлением бизнеса, сколько вам нужно знать о другом продукте, прежде чем вы сможете интегрироваться?Да, веб-сервисы должны разрабатываться по контракту, но реализация часто ненадежна, и вам нужно многое понимать о том, что происходит - и если это продукт, вы не можете контролировать абстракцию, даже если веб-сервисы просачиваются в вашу технологию взаимодействия, известную как BizTalk.

Соедините эти два пункта вместе, и лучший совет — это получить тип центра интеграции, такой как BizTalk — обернуть линейку бизнес-приложений в создаваемые вами веб-сервисы — так что сторона BizTalk может быть свободна от дырявых абстракций, тогда вы также можете уменьшить количество точек сбоя. поскольку вы отделили линию бизнес-приложений от центра интеграции и точку отказа к единому источнику, а не внутри оркестрации.

Инструментирование и диагностика в SOA и проектах взаимодействия трудно достижимы!- Не позволяйте никому из блестящих продавцов пытаться сказать вам другое!Да, MOM с MOM Ent могут сделать это, UniCenter может сделать бла.

Основная проблема - понять, что означают ошибки, называемые отрыжками при интергации, и как от них избавиться...В конечном итоге сообщения застревают, и вам нужно понять, что это значит для бизнес-процесса.Вы можете получить предупреждение о том, что процессоры на 100% работают, 100% оркестровка не удалась, но это не имеет реального значения.Вы должны с самого начала внедрить все это в решение — и, будем надеяться, в точки отказа.

Также необходимо учитывать типы шаблонов интеграции и способы их реализации.

Вышеупомянутое представляет собой реальный взгляд на .NET SOA с BizTalk в реализации LIVE.Но это также связано с архитектурными ограничениями: BizTalk в основном представляет собой шаблон HUB и SPOKE.

Проверить Шаблоны корпоративных приложений Мартина Фаулера

Есть много способов облегчить задачу!

Другие соображения...Языки платформы/разработчика и т. д.

Одним из важных факторов для нас были навыки, необходимые для начала этого дела.У нас были объектно-ориентированные разработчики с пониманием Java и C#, но в основном C#.Итак, мы выбрали стек MS.Но когда вы выберете тип интеграции и продукт для управления ею, им потребуется больше навыков для понимания этой технологии.Но эй, это нормально для нас, разработчиков, верно?Неправильно, что многие разработчики, независимо от их опыта, могут не справиться с такими программами, как BizTalk!Большой сдвиг в парадигме, который отчасти обусловлен сдвигом в обмене сообщениями, а не в коде.

Лучшее напоследок!

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

Вам нужно выбрать лучший по ожидаемым объемам правильный.Что-то, что можно масштабировать и масштабировать!Мы выбрали BizTalk, поскольку он может масштабироваться правильно и с лучшим пониманием, чем некоторые другие.

Если у вас нет томов, подумайте о том, чтобы не получить что-то для управления ими, и выберите стиль типа веб-сервиса для веб-сервиса без управления - в них необходимо будет закодировать понимание производительности и сбоев.

Если вы используете платформу Windows с .net 3, обратите внимание на WWF/WCF, поскольку это может помочь в переходе от веб-сервиса к веб-сервису - теперь на актуальной платформе гораздо больше возможностей для решения всех этих проблем без накладных расходов на BizTalk и других.

Надеюсь это поможет.

Answer 2

По моему опыту, это зависит от того, какую проблему вы решаете.

По моему опыту, BizTalk 2006 R2 сложно превзойти по цене, но он предполагает использование стека технологий Microsoft.

Кажется, что Websphere MQ легче продать крупным корпорациям, и он, вероятно, нашел более широкое применение на уровне предприятия.

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

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

Answer 3

Вы упомянули WebSphere, BizTalk, Mule.Каждый из которых имеет очень разные характеристики со своими хорошими и плохими сторонами.Если вам нужна только интеграция, я порекомендую Mule.У меня был очень хороший опыт работы с ним, и, что более важно, архитектор не навязчив, поэтому вы всегда можете перейти на другой ESB или другое решение для жалоб на модные слова.Одним из преимуществ Mule является то, что его можно встроить в ваше приложение, а конечный продукт можно развернуть на Webshpere, WLS, Glassfish и т. д.даже не показав, что вы встроили ESB.Затем этот ESB может выполнять всю интеграцию (управление типами соединений и протоколами).Принимая во внимание, что некоторые из конечных точек могут быть другими интеграционными решениями, о которых вы упомянули.

Answer 4

Некоторое время мы используем Mule (сейчас исследуем миграцию с версии 1.4 на версию 2.1.x).

Что ж, это один из лучших ESB с живым сообществом и быстрой реакцией со стороны поставщика, но версия IMO 2.1.x все еще немного сырая (или мы - только компания, которая использует ее для вызова веб-сайта CXF :) Подробности см. Также в моем сообщении http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320)

Answer 5

у нас есть контракт Oracle.Итак, мы используем стек Oracle.SOA Suite 10.1.3.4.В основном это решения BPEL, а для простых преобразований мы стараемся использовать ESB.

ESB имеет плохой механизм обработки ошибок.В BPEL существует множество способов обработки ошибок.Мы пытаемся разрабатывать веб-сервисы Java для подключения к SOA Suite, и нашими основными системами являются системы Oracle EBS.Они взаимодействуют с устаревшими системами или другими средами EBS через адаптеры EBS по умолчанию, поставляемые с SOA Suite.

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

Защита наших веб-сервисов не является большой проблемой.В состав стека Oracle входит Oracle Web Service Manager.Благодаря этому мы можем защитить, зарегистрировать и т. д.все веб-сервисы.

Самая большая проблема, с которой мы сталкиваемся, — это отсутствие собственных стандартов.Дать бизнесу почувствовать, что они также могут создавать решения SOA.Мы не можем объяснить преимущества, которые они получают от SOA-решения.Быстрее?нет !Более дешевый?Конечно нет!Более простые решения?Ну, может быть, когда у нас появятся хорошие многоразовые сервисы...ну, в этой более простой части есть проблема:как мы узнаем, какие приложения используют повторно используемые веб-сервисы?

Нам нужен регистр, который может отображать такую ​​информацию.Поскольку мы не можем найти хорошее решение с открытым исходным кодом, мы пытаемся создать собственный реестр.Простое решение APEX, опять же из стека Oracle.;)

Итак, кто-нибудь знает хороший продукт для регистрации такого рода информации?