Здравствуйте, Allaire, Вы писали:

A>Будет тяжело составить конкуренцию Biztalk

Зачем конкуренцию? Этот инструмент использовать можно было бы, а не переписывать.

A>Но это как бы и не требуется, т.к. уже есть работающее решение — на сервисах. Вопрос только в том, насколько гибким его можно сделать, т.е. если возникает необходимость подключения нового источника или получения данных, не переписывать (или дописывать сервис), а сделать это через плагины к примеру (здесь возникают сомнения по поводутого, какой функционал включать в плагин и насколько они вообще вписываются в общую картину).

Если данные подпадают под определение "массив сущностей", то есть толкаемый MS протокол OData и, соответственно, WCF Data Services как средство создания веб-сервисов, работающих по этому протоколу. Идея в следующем.

Раньше было так: если у тебя есть куча таблиц с данными в разных SQL Server-ных базах тебе нужно как-то эти данные сагрегировать, преобразовать, заджойнить и т.д. — ты пишешь вьюхи, хранимки, user-defined functions etc. 100500 твоих коллег делают то же самое, в результате в компании образуется слоеный пирог из всех этих сотен тысяч объектов.

Теперь выяснилось, что иметь доступ ко всем этим источникам данных хотелось бы по протоколу HTTP, из разных мест земного шара. А также джойнить их с другими источниками, не на MS-овской платформе.
Поэтому придумали протокол OData.
Преимущество по сравнению с обычным SOAP-ом — в том, что OData-сервисы не типизированы (вернее, скажем так, динамически типизированы) и сами по себе поддерживают язык запросов (через query string). Ну и в том, что добавление нового источника данных — это просто развертывание еще одного HTTP-ендпойнта.
Клиенты таких сервисов также стараются быть не привязанными к конкретной схеме данных и конкретному URLу. Грубо говоря, типичный клиент такого сервиса — это веб-браузер: в поле адреса ввел запрос — внизу получил некий рекордсет.
И еще в том, что код пишется не на T-SQL, а на C# (как правило)

Слоеный пирог при этом, правда, тоже образуется

A>п.с. а что за недостатки у ESB — по-моему этот подход следует вполне оправданной логике (т.е. мухи отдельно, котлеты отдельно), где фактически пользовательское приложение получает уже готовые данные?

Сервисная шина (Biztalk, Oracle ESB etc.) — это фактически продвинутый прокси-сервер. Транслирует через себя запросы к сервисам и ответы от них. Как правило, самое умное преобразование, какое шина может сделать — это слегка поменять схему данных. Ну, еще часто есть рутинг и тупая балансировка нагрузки. И еще иногда можно спросить у шины, а какие она вообще сервисы знает.
А недостатки известны:
1. Шина — single point of failure. Тут речь даже не столько про ломающееся железо, сколько про коннективити и кривые руки обслуживающего персонала. Руки могут быть и не кривыми, но просто у этих рук очень мало способов проверить правильность своих действий, и из-за этого настройки, права доступа и WSDL постоянно разъезжаются в разные стороны — и нужный тебе сервис лежит 30% времени.
2. При серьезных нагрузках материальные затраты на обеспечение работоспособности шины легко могут превысить затраты на сами сервисы.