SOA/ESB Dilemma

Question

Извините за очень сложный вопрос, но это то, что я изучал какое-то время, и это действительно расстраивает меня. Я чувствую, что в сегодняшнем возрасте у нас есть миллион и один способ реализовать сервисы, которые являются кросс-платформенными (SOAP) и просты в построении (благодаря .NET, java и другим фреймворкам). Тем не менее, эти технологии были в обществе в течение 5-10 лет, но мы (или, по крайней мере, я) постоянно сталкиваются с теми же проблемами:

1. идентификации (услуги слежения) - UDDI; например, должен был напомнить сотруднику 3 раза в этом месяце, где работает служба, несмотря на то, что существует вики, в которой обсуждается сервис и версия PDF той же документации, которая хранится в репозитории, где мы храним наши сервисные документы ,
2. Масштабируемость - из кластера; Как организации, мы тратим много денег на то, чтобы заплатить нашим администраторам только за то, чтобы следить за использованием наших услуг и принимать такие решения, как эта служба нуждается в большей ОЗУ, больше ЦП, больше интерфейсов? Как загрузить баланс?
3. Мониторинг - регистрация ошибок и т. Д .; Я не могу подсчитать, сколько раз мне приходится настраивать трассировку на сервисах, чтобы понять, почему происходит ошибка, которая, по-видимому, влияет только на одного клиента, или должна закодировать логику в сервисе для сериализации исключений, исключений журналов в dbs, сбой изящно и т. д.
4. Развертывание - легко развертывается; ни одна из этих развертываемых библиотек DLL на 5 балансированных серверах

Для каждой из этих проблем требуется определенное типовое решение, реализуемое организацией. Документация и UDDI для # 1. Оборудование и программное обеспечение для виртуализации и балансировки нагрузки для # 2. Трассировка, запись исключений из баз данных/журналов и т. Д. Для # 3. Специальное программное обеспечение для развертывания для # 4. Я работаю в организации среднего размера. Я даже не могу представить, как компания размером с Sun, Google или Microsoft справится с этими дилеммами.

Возможно, мое видение нереально, но я мечтаю о создании Framework, который живет поверх кластера серверов, который управляет всем вышеперечисленным. Я был в восторге от того, что читал о AppFabric от Microsoft, поскольку действительно кажется, что некоторые функциональные возможности BizTalk для разработчиков WCF-сервисов: кэширование, хостинг, мониторинг и т. Д. Однако, из того, что я видел, я до сих пор не чувствую, что он живет вплоть до моей мечты о решении «все-в-одном», которое помогает разработчику и организации писать службы, которые легко масштабируются по кластерам, легко развертываются в кластере и могут быть идентифицированы, возможно, даже с возможностью версии.

Итак, я не имею в виду этот пост, чтобы быть о моей мечте. У меня действительно есть вопрос. Для начала, моя мечта/хочу совершенно нереалистично? Кроме того, какие существуют решения, которые пытаются решить эти проблемы, не ограничивая нас новым и более проприетарным способом (BizTalk) для разработки сервисов? Наконец, в отношении полного решения SOA/ESB, где мы видим наибольший потенциал на рынке прямо сейчас или в будущем?

Answer 1

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

1). Разработчики, которые не читают документацию. Это эндемическая проблема, не ограничиваясь SOA - просто посмотрите на некоторые вопросы по StackOverflow. По крайней мере, разработчик спрашивает вас, есть ли служба, а не просто дублирование логики в их собственном коде. Я не вижу никакого технического решения этих проблем, вы уже предоставили хорошие реестры и документацию, но некоторые разработчики предпочитают разговаривать с людьми. Может быть, даже это на самом деле хорошо - человеческое взаимодействие имеет ценность выше технического содержания взаимодействия. Или, может быть, ты слишком хорош: «Нет, я не буду отвечать на этот вопрос, посмотри».

2). Scaling. Существуют технологии для решения этой проблемы. (Отказ от ответственности я работаю для IBM, которые продают некоторые, поэтому я буду ссылаться на них - я не намерен предполагать, что IBM является единственным поставщиком решений в этом пространстве.) Есть такие продукты, как this, которые могут предоставить новую машину , установите стек программного обеспечения и добавьте его в кластер для изменения рабочих нагрузок. Затем на более тонком уровне управления в мире Java EE Сервер приложений может динамически формировать трафик и настраивать кластеры. См. WebSphere Virtual Enterprise

3). Мониторинг. Я не «получаю» то, что вы ожидаете отсюда. Вполне вероятно, что для таких сложных ошибок потребуется трассировка уровня приложения. Для некоторых проблем, таких как обнаружение утечек памяти и узких мест производительности, есть очень хорошие инструменты, по крайней мере, в мире Java EE.

4). Я не могу говорить с миром .Net, но я бы сказал, что серверы приложений Java EE делают разумную работу по развертыванию приложений в кластерах плавно, а в тех случаях, когда мы используем JNI и требуем развертывания DLL, мы можем использовать продукты таких как стек Tivoli, о котором я упоминаю, чтобы справиться с этим.

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

Answer 2

Вот мои два цента.

Я был разработчиком в компании, которая неправильно использовала SOA. Наихудшее решение, которое они внедрили, - это проверка уровня элементов формы на настольном приложении с использованием SOA. Для их приемлемого использования требуется очень низкая латентность. 2-4 секунды ожидания перехода на новое поле быстро стареет. Служба работала по сети на сервере biztalk. Все это ненавидели.

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

Не увлекайтесь и думайте, что SOA является решением каждой проблемы. Используется на высоком уровне, это здорово, используется на низком уровне, что делает ваши приложения хрупкими, медленными и невозможными для отладки.

Answer 3

Если вы разговариваете с IBM или одним из крупных поставщиков SOA, у них есть продукты, которые охватывают каждый сценарий.

Identification (Tracking services) - UDDI; e.g., had to remind a co-worker the 3 times this month where a service is at, despite the fact there is a wiki that discusses the service and a PDF version of the same documentation that lives in a repository where we keep our service docs. 

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

Scalability - Out of the box clustering; As organizations, we spend a lot of money on paying our admins just to watch the utilization of our services and make decisions like, does this service need more RAM, more CPU, more interfaces? How do I load balance this? 

Программное обеспечение для мониторинга транзакций, такое как IBM Tivoli Composite Application Manager для SOA. В основном, он отслеживает вещи с горизонтальной точки зрения и видит, есть ли сбой в обслуживании с точки зрения конечного пользователя/конечного приложения.

Что касается вашей кластеризации ... вам нужно выбрать хорошее промежуточное ПО и архитектуру. Лично говоря, получите материал, который «облако» готов. Серверы приложений с NoSQL, подключенные MOM.

Monitoring - error logging, etc; I can't count how many times I have to set up tracing on services in order to see why a bug is happening that only seems to affect one customer, or have to code logic into the service to serialize exceptions, log exceptions to dbs, fail gracefully, etc. 

Стандарты предприятия для ваших разработчиков и для ваших поставщиков. Интеграция всех бизнес-событий и системных событий в единую панель. (Большинство компаний разливали их). Это делается уже в большинстве корпоративных магазинов.

Deployment - easy to deploy; none of this deploying DLLs to 5 load balanced servers 

Ahh .. Microsoft IIS Web Deployment Tool 2.0. Вы можете синхронизировать 100 серверов MS, просто обновив мастер. Это очень легко.