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

ничего себе-Ок-получит пост по этому поводу, но будет большой.

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

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

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

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

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

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

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

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

Приборостроение и диагностика в SOA и Intergation Porjects трудно достичь! - Не позволяйте ни одному продавцу shiney пытаться сказать вам по-другому! Да MOM с мамой ЛОР может сделать это UniCenter может сделать бла.

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

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

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

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

Есть много способов снять кожу с этой задачи!

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

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

Лучшее для последнего!

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

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

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

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

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

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

По моему опыту, трудно победить BizTalk 2006 R2 для bang for the buck, но это подразумевает использование стека технологий Microsoft.

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

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

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

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

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

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

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

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

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

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

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

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

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