Ну вот... нормальную тему во флуд обратили, или холевар, непонятно...

zeehond-=*ShamaN*=-Мой выбор был бы таким:
SOA-архитектура, сервер приложений на Java предоставляет объектный фасад, доступ к которому осуществляется через SOAP-протокол.
Клиентской частью может выступать как рабочая станция пользователя, так и сервер (или сервис). Для каждой конкретной ситуации интерфейс можно нарисовать на любой платформе, которая поддерживает SOAP. Это может быть сервер внутреннего сайта, SilverLight, NativeGUI и пр.
Там, где критична скорость реакции, не важна мультиплатформ. и экономия железа - GUI. Всё остальное - HTML, JavaScript, Ajax. Не исключается возможность дублирования функциональности в клиентах разных типов.
Обычно ввод информации в ИС делается на нативном ГУЕ, для вывода используются HTML и пр.

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

всё правильно, за исключением того, что полноценный SOAP - это оверкилл во многих случаях
REST/JSON - вполне себе альтернатива, тем более если клиент лёгкий, на JS

хотя с дргой стороны у ТС там киоски а не онлайновая система, которая должна тянуть в среднем пицот запросов в секунду


Если SOAP=Overkill, вижу такую схему: от SOA не отказываемся, он есть и существует (EJB или .NET-компоненты это будут в зависимости от выбранной платформы - неважно, важна модель). Есть дырки, через которые можно получить доступ к этим объектам и их функциональности: RMI или .NET(Remoting), повторюсь, в зависимости от выбранной платформы. Далее эти компоненты можно завернуть в... да во что угодно!
1. WebServices через SOAP - как одна из альтернатив, наиболее подходящая для этого, но можно точно так же выставить отдельный сервер, который обращается к тем же компонентами, но запросы принимает в формате JSON. Примерно получится так:

ОБЪЕКТ1
- МЕТОД1
- МЕТОД2

СЕРВЕР1-WS(SOAP) : принимает запросы от GUI клиентов по локальной сети по протоколу SOAP, для выполнения каких-либо операций обращается к серверу, где лежит ОБЪЕКТ1 и дёргает его методы по протоколу RMI, .NET Remoting (есть и другие способы).

СЕРВЕР2-JSON дырка : делается специально для киосков, принимает запросы от тонких клиентов по протоколу JSON, но для выполнения каких-либо операций опять же, как и в случае с SOAP, обращается к серверу, где лежит ОБЪЕКТ1 и дёргает его методы по протоколу RMI, .NET Remoting. JSON-фронт можно даже самому ручками наваять в виде сервлета на Java, где на вход просто закидывается строка с именем метода и параметрами, а дальше дело техники.
.
.
.
СЕРВЕРN-WEB морда : например, сервер отчётов, который для генерации контента обращается к серверу, где лежит ОБЪЕКТ1 или другие и дёргает его методы по протоколу RMI, .NET Remoting, получая оттуда данные.

Встаёт вопрос о технологии, которая будет использована на клиенте. Тут нужно понимать, что от конкретного клиента требуется сегодня, ну и хотя бы на завтра. Киоски и пр. должны быть лёгкими: HTML, SL, JavaFX, JS, JSON. Если требования к ним могут вырасти, есть риск замены клиентской технологии в корне. Тут просто клиент исполняется на любой выбранной технологии, делается для него фасад, который обращается опять же к SOA.

PS.. За нас уже подумали, надо правильно вкурить...
PS2.. SQL.ru правильнее назвать VKurilke.ru)))

Что касается сжатия пакетов.
Надо на эту фичу смотреть реально, а не широко раскрытыми глазами, и именно, как на опциональную фичу, а не достоинство технологии. Это как весы: на одной чаше сильный процессор-память, на другой скорость доступа к удалённому сервису. Задача транспорта и RPC всё равно останется такой же: сериализация, маршаллинг, доставка пакетов и вызов методов.
Если слабый компьютер и слабый канал, то ничего не поделаешь - тормоз, он и в Африке тормоз. Если сильный компьютер, но слабый канал, то при наличии опции сжатия, появляется возможность ослабить нагрузку на канал... НО! это достигается за счёт увеличения нагрузки на процессор. Ещё нужно учесть периодичность запросов, если они очень частые, то в первую очередь задохнётся процессор из-за процессов пакования (это уже от рук программистов и проектировщиков удалённых сервисов зависит, как часто клиент шлёт запросы и "глубина" сериализуемых объектов). Не всегда сжатие имеет положительный эффект, а в локальной сети вообще бесполезная трата ресурсов.

iscrafmSilverlight
Сервис и сообщение будут полностью соответствовать спецификации SOAP.
ты уже придумал куда в soap приткнуть что-то в формате json?


Можно, через обёртку, только зачем??

egorych-=*ShamaN*=-iscrafmSilverlight
Сервис и сообщение будут полностью соответствовать спецификации SOAP.
ты уже придумал куда в soap приткнуть что-то в формате json?


Можно, через обёртку, только зачем ??это должен был быть второй вопрос, но пока застопорились на первом

Смысл в JSON есть только в случае, когда требуется в коде JavaScript в браузере сделать асинхронный запрос к серверу... Формат очень простой и пакет вполне реально сформировать средствами скриптовых языков. Ещё JSON используют на HighLoad проектах (linkedin, twitter, vkontakte и пр.) для кэширования объектов в MemCache (это базы Key=Value, построенные по технологии DHT). Больше областей эффективного применения JSON я не вижу. Мож кто подскажет, где ещё его применять удобно.

В нашем случае есть киоск, если коиск - это вэб-приложение, построенное на AJAX, то JSON рулит. WEB-сервер тут является принимающей JSON стороной, он его парсит и далее выполняет нужные действия, обращается к распред. объектам или сам что-то делает и лезет в базу, не суть...
Заворачивать JSON в SOAP глупо, они примерно на одном уровне и выполняют роль носителей для для сетевого транспорта. На JS можно сформировать SOAP-пакет и успешно его заслать на сервер, но на JavaScript это муторно с точки зрения трудозатрат и геммороя. Вот тут его и сменяет JSON...

Может по теме, господа?)