Как вы делаете системную интеграцию?
Мне интересно, как разные люди решают интеграцию систем. У меня есть ощущение, что в последние годы все больше и больше усилий вкладывается в интеграцию систем и что потребность в такой работе также возрастет.
Мне интересно, решаете ли вы это, разрабатывая свои собственные небольшие сервисы, которые затем подключаются, или используете какой-то продукт (WebSphere, BizTalk, Mule и т. Д.). Я также думаю, что было бы интересно узнать, как такие решения управляются и поддерживаются (как вы решаете вопросы безопасности, контрольно-измерительные приборы и т. Д.), Какие проблемы у вас возникли с вашим решением и так далее.
5 ответов
Вау - хорошо - получит сообщение об этом, но будет большим.
Интеграция должна быть подкреплена большим пониманием со стороны бизнеса о преимуществах - разберитесь с оперирующей моделью - поскольку бизнесу может потребоваться стандартизация, а не интеграция, поскольку это может быть дорогостоящим - вот почему большинство SOA терпят неудачу! Архитектура предприятия: стимулирование бизнес-преимуществ от ИТ Автор (ы): Жанна В. Росс
Если необходима интеграция, вам нужно выбрать тип интеграции.
Каковы показатели скорости и производительности?
У нас есть.NET SOA с составным приложением, которое использует BizTalk 2006, и веб-сервисы с линейкой бизнес-приложений. Производительность приложения на составном конце (потребление) - ограничена скоростью работы веб-сервисов (и их реализацией) в линейке бизнес-приложений! Нам нужно менее 3 секунд возврата результатов - список дел. Не удалось получить доступ к веб-сервисам, поэтому нам нужно сразу перейти к базе данных для начального поиска. Затем через веб-сервисы для создания кейса. Затраты и обслуживание становятся проблемой здесь.
Смысл здесь в том, чтобы взглянуть на критерии производительности в спецификациях и бизнес-требованиях, это поможет взглянуть на тип интеграции, который вам нужно сделать - WebServices (HTTP), File Drop/ EDI и т. Д.
Функционально для интеграции вам необходимо посмотреть на точки сбоя в предлагаемой архитектуре - так как это приведет к цепочке ответственности в SLA/OLA. Возможно, вам придется обернуть точки интеграции / сбоя в вещи, которые вы контролируете.
Что касается интеграции с Line of Business, то сколько вам нужно знать о другом продукте, прежде чем вы сможете интегрироваться? Да, предполагается, что веб-сервисы проектируются по контракту, но реализация часто протекает, и вам нужно много понимать о том, что происходит, и если это продукт, который вы не контролируете абстракцию, даже если веб-сервисы просочились в вашу технологию интеграции, известную как BizTalk.
Соедините эти две точки вместе, и вам лучше всего получить интеграционный тип, такой как BizTalk, - обернуть линию бизнес-приложений в создаваемые вами веб-сервисы - так, чтобы сторона BizTalk могла быть свободна от неплотных абстракций, тогда вы также можете уменьшить количество точек сбоя. как вы отделили бизнес-приложение от центра интеграции и точки отказа до одного источника, а не внутри оркестровки.
Инструментарий и диагностика в SOA и Intergation Porjects труднодоступны! - Не позволяйте ни одному блестящему продавцу попытаться сказать вам по-другому! Да, MOM с MOM Ent могут сделать это, UniCenter может сделать бла.
Основная проблема заключается в том, чтобы понять, что означает ошибка, также известная как "отрыжка" в процессе интеграции, и как исправить ее... В результате вы застряли в сообщениях, и вам нужно понять, что это означает для этого процесса busienss. Вы можете получить предупреждение, чтобы сказать - процессоры на 100%. Ram 100% оркестровки потерпели неудачу - но никакого реального смысла. Вы должны с самого начала внедрить этот материал в решение - и, надеюсь, в ваши точки неудачи.
Типы моделей интеграции и способы их применения также должны быть рассмотрены.
Вышесказанное представляет собой реальный взгляд на.NET SOA с BizTalk в реализации LIVE. Но это также связано с архитектурными ограничениями этого - BizTalk в основном является шаблоном HUB и SPOKE.
Проверьте шаблоны корпоративных приложений от Мартина Фаулера
Есть много способов снять задание!
Другие соображения... Языки платформы / разработчика и т. Д.
Одним из важных факторов для нас были навыки, необходимые для начала этой работы. У нас были разработчики OO с пониманием Java и C#, но в основном C#. Итак, мы пошли на стек MS. Но когда вы выбираете тип интеграции и продукт для управления им, им потребуется больше навыков в понимании этой технологии. Но эй, это нормально для нас, девы, верно? Неправильно, что многие разработчики, независимо от того, где они находятся, могут оторваться от подобных BizTalk! Большой сдвиг в парадигме - отчасти это связано со смещением сообщений, а не с кодом.
Лучший бит для последнего!
Количество транзакций, которые могут встретиться в процессе интеграции, вероятно, является самым большим фактором во всем этом. Как это будет руководить, какой шаблон, точки отказа и терпимости для таких вещей.
Вы должны выбрать лучший по ожидаемым объемам правильный. Что-то, что может увеличиваться и уменьшаться! Мы выбрали BizTalk, поскольку он может корректно масштабироваться и масштабироваться лучше и лучше, чем некоторые другие.
Если у вас нет томов, обратите внимание на то, что вы не получаете что-то для управления ими, и перейдите к веб-сервису в стиле типа веб-сервиса без управления - производительность и понимание ошибок должны быть закодированы в них.
Если вы работаете на платформе Windows с.net 3, взгляните на WWF/WCF, так как это может помочь веб-сервису веб-сервису - гораздо больше в актуальной платформе для решения всех этих проблем без дополнительных затрат на BizTalk и другие.
Надеюсь это поможет.
У нас есть контракт с 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.;)
Так кто-то знает хороший продукт для регистрации такого рода информации?
Вы упомянули WebSphere, BizTalk, Mule. Каждый из которых имеет очень разные характеристики со своими хорошими и плохими сторонами. Если вам нужна только интеграция, я рекомендую Mule. У меня был очень хороший опыт работы с ним, и что более важно, архитектор не инвазивен, поэтому вы всегда можете перейти на другой ESB или другое решение для жалоб Buzz Word. Одним из приятных моментов Mule является то, что он может быть встроен в ваше приложение, а ваш конечный артефакт может быть развернут на Webshpere, WLS, Glassfish и т. Д., Даже не показывая, что вы внедрили ESB. Затем этот ESB может выполнять всю интеграцию (управление типами соединений и протоколами). Принимая во внимание, что некоторые из конечных точек могут быть другим интеграционным решением, которое вы упомянули.
По моему опыту, это зависит от того, какую проблему вы решаете.
По моему опыту, сложно превзойти BizTalk 2006 R2 по выгодной цене, но это подразумевает использование технологического стека Microsoft.
Похоже, что Websphere MQ легче продавать крупным корпорациям, и, вероятно, он получил большее применение на уровне предприятия.
Оба предоставляют хорошие инструменты, но вы, как разработчик, можете настроить их в соответствии с требованиями вашего клиента.
В некоторых случаях я обнаружил, что индивидуальное решение является наиболее подходящим или использует технологии, такие как MSMQ, для снижения затрат.
Некоторое время мы используем 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)