Agile Development и ESB

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

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

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

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

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