Иван Шумов, Клиент - понятие относительное и в общем случае обозначает инициатора запроса, обращения, потребителя услуги и т.д. "Многослойный пирог" - содержит в себе и "слой" клиента и "слой" сервиса. Система, которую я привел в качестве примера, оперативная система управления почти реального времени (есть некоторые задержки в сборе информации). В ней есть все, автоматическое планирование, прогнозирование, ситуационное моделирование и прочие " Business representative", если угодно, позволяющие принимать оперативному персоналу управленческие решения.
Можно эту систему перенастроить на совершенно другую предметную область? Можно. Что для этого нужно сделать. В основном заменить слой XSLT.
К@inoise, Каждый узел - "многослойный пирог". В нем есть все, в том числе он может обслуживать и пользовательские запросы в автономном состоянии. Каждый узел при запуске пытается соединиться со всеми другими узлами и когда это связь устанавливается возможности узла по обслуживанию пользовательских запросов расширяются.
Иван Шумов, Работает! Именно по такому принципу построена (и по другому ее просто создать нельзя) высоконагруженная корпоративная система параллельных вычислений - распределенная, с множеством источников данных, с множеством узлов, территориально расположенная во множестве ЦОД. Подключение новых источников данных, подключение новых узлов - ни каких проблем не вызывает. Модификация системы - элементарно. Мониторинг присутствует. Авторизация и аутентификация - присутствуют. Система автоматического выхода из сбойных ситуаций присутствует. Режим разноверсионности ПО на разных узлах - присутствует (система сохраняет свою работоспособность при обновлении территориально разбросанных узлов)
Авторизация аутентификация это совершенно другая задача. Мониторинг совершенно другая задача. И прочие функции. Не надо валить разные задачи в кучу. Не разгребете!
Иван Шумов, не вижу ни каких проблем в адаптации упомянутого сервиса под ваше ключевое слово SAAS. БД позволяет Вам получить всю информацию о структуре данных. Вся информация о получаемых параметрах Вам тоже доступна. Остается только придумать правила (описание) преобразования (бизнес логику) получаемых параметров из одного "вида" в "другой". Это можно сделать несколькими способами. Выбирайте любой.
Привязка программной модели к модели данных (JPA), на мой взгляд, очень плохое решение. Как только Вы это осознаете, для Вас Spring, Hibernate и прочие подобные реализации становятся "программным мусором". Отказ от JPA дает Вам свободу модификации вашей системы при возникновении новых требований.
Кстати, отлично подходит для подобной реализации XSLT.
Можно эту систему перенастроить на совершенно другую предметную область? Можно. Что для этого нужно сделать. В основном заменить слой XSLT.