SOA / ESB Дилемма

Question

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

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

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

Может быть, мое видение нереально, но я мечтаю о том, чтобы сама по себе Framework работала надкластер серверов, который управляет всем вышеперечисленным.Я был в восторге, читая о Microsoft AppFabric, поскольку она действительно расширяет некоторые функции 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

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