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

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

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

15.08.2008 06:06:13
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 и другие.

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

10
15.08.2008 07:51:51

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

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

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

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

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

0
15.08.2008 15:44:50

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

0
4.09.2008 20:12:06

Некоторое время мы используем 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 )

0
1.11.2008 19:46:24

у нас есть контракт с 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. ;)

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

0
25.12.2008 21:44:35