Дилемма SOA/ESB

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

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

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

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

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

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

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

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

Если вы собираетесь это сделать, вам действительно нужно потратить много времени на решение проблем с задержкой в ​​сети, сбоем службы, синхронизацией и тайм-аутом.

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

Если вы поговорите с 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 2.0. Вы можете синхронизировать сотни серверов MS, просто обновив мастер. Это действительно легко.