Agile Development и ESBs

Question

Я работаю над переходом нашей корпоративной технологической парадигмы на Agile Development. Это был сложный процесс, но мы почти у цели! :)

У нас есть устаревшие системы для управления базами данных (раньше это Access, теперь он портирован на .NET и MS SQL), и мы разрабатываем основу для нашего будущего видения. Мы хотим перенести как можно больше в Интернет. Но мы хотим интегрировать нынешнюю систему с «будущей». Мы не будем дублировать задачи и функции.

Мое видение состоит в том, чтобы переместить всю контактную информацию о наших пользователях в другую базу данных, связав эти «профили» обратно с MS SQL для их истории и бухгалтерской информации. Мы сохраним все учетные системы в настольном приложении, но мы собираемся добавить гораздо больше функциональных возможностей, которые будут сильно зависеть от Интернета, особенно Ruby on Rails.

Наверное, вопрос в том, почему ESB? Есть ли способ создать SOA без суеты со сложными системами ESB. Вся идея заключается в том, чтобы К.И.С.С. тем не мение. Может ли SOA быть создан таким образом, чтобы позволить настольному / веб / мобильному устройству быть интерфейсами, сохраняя функциональные возможности бизнес-логики (конечно, некоторые функциональные возможности должны были бы быть реализованы в интерфейсе, но сохраняя это до минимума). И соответствуют ли ESB философии Agile? Чем больше я их читаю и изучаю, тем меньше я так думаю! : /

Спасибо за ваши комментарии! Если вам нужно, чтобы я уточнил, просто задайте несколько вопросов, и я сделаю все возможное, чтобы сделать это! :)

Answer 1

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

базовая SOA просто определяет сервисы вместо приложений; ESB управляет услугами в каналах, чтобы скрыть конечные точки, делая обновления и замены намного более «гибкими»

Answer 2

Я научился довольно быстро уклоняться от термина «ESB», поскольку он очень перегружен и означает разные вещи для разных людей (а иногда разные вещи для одного и того же человека: -))

Главное, естественно, спросить себя, что именно вам действительно нужно.

Использование базы данных (баз данных) в качестве службы, вероятно, будет разумным выбором, особенно если у вас есть несколько клиентов для этих данных; вам придется потратить немало времени на обдумывание контрактов и определение объема работ, но Agile может сильно помочь в этом.

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

Служебная шина помогает маскировать услуги от их клиента (которые могут быть другими службами), и эта «маскировка» может передавать местоположение, протокол, форматы, коды и т. Д. некоторые формы служебной шины также поддерживают маршрут (что нужно назвать и когда), но мне обычно не нравится эта идея.

Итак - вопрос, который вы должны сначала задать себе, я думаю, это то, с чего вам нужно начать и сколько предварительных инвестиций вы хотите сделать (и можете обосновать)

Например, если изначально вас устраивает более точечный подход, ваши клиенты могут позвонить в службу напрямую; на более позднем этапе, по мере развития сервиса, вы можете представить «посредника» для посредничества в запросе и ответе (да - вы можете назвать его ESB, если хотите).

В качестве альтернативы вы можете начать с базового «посредника», чтобы клиенты никогда не вызывали сервис напрямую, а имели только те функции, которые вам нужны для начала, и расширяли его возможности по мере формирования требований; вполне может начаться как простая машина пересылки.

В идеале вы должны строить поверх продукта, который имеет много встроенных возможностей; BizTalk Server хорошо подходит, если вы в стеке MS (но у него есть кривая обучения)

так - извинитесь, если это не очень конкретный ответ - но я думаю, что моя главная мысль в том, что «ESB» не должен быть излишним, он просто сводится к тому, что вы хотите иметь в первый день, и проворный (и SOA) определенно помогает, позволяя вам постепенно развиваться, а не что-то вроде большого взрыва.

(если что-то из вышеперечисленного является полной чепухой или немного неясно, это из-за недостатка сна с новорожденным в доме! Извинения :-))

Answer 3

Вся миграция - вот что привело меня к ESB ... Но сама идея ESB кажется слишком сложной для решения проблемы, которая включает около 30 000 профилей! Мы находимся на грани некоторого экспоненциального роста (до нескольких миллионов профилей), и, возможно, было бы лучше начать с нового пути. Насколько просто связать запись, которая находится в БД MySQL, с данными, хранящимися в БД MS SQL? Я не хочу двойной записи, очевидно, но может быть более гибкий способ, чем «целый» ESB ... Я понимаю, что SOA с ESB может быть довольно гибким с точки зрения обновлений и замен, но будет ли это излишество? :)