(Отказ от ответственности: мой опыт в основном получен с платформ, отличных от Java, хотя у меня есть некоторый ограниченный опыт работы с Java - но в основном Я не a веер )
Это точно - но только для приложений, использующих эту архитектуру - что делает это утверждение несколько тавтологическим.
Я разобью это:
Перспектива потребителя услуг
- "Потребитель услуг" также более широко известен как клиент .
- «Файлы интерфейса службы» не необходимы для построения клиента.
- Я предполагаю, что под «файлами интерфейса» это подразумевается как SOAP WSDL документ или файл Swagger для служб REST. Эти файлы обычно не используются клиентами во время выполнения, но используются для автоматического создания клиентских библиотек классов во время разработки, но вы всегда можете создать клиент без генерации кода или повторного использования типов Java
interface. - Если это относится к повторному использованию типов Java
interface сервера / приложения, тогда диаграмма является точной только для клиент-серверных приложений, которые все - Java и оба спроектированы / созданы одинаково время (что является старой практикой со времен SOAP). В эти дни все, что сделано за последние 5-10 лет, является RESTful и возвращает данные JSON, но типов Java interface недостаточно для моделирования неструктурированных данных, таких как JSON (, учитывая, что вы не можете моделировать дискриминационные объединения без конкретных классов ... в обработчиках исключений egods и дискриминационные объединения являются важным инструментом для моделирования JSON на OOP языках).
Перспектива поставщика услуг
Я не согласен с использованием термина «Фронт-контроллер», который используется для обозначения так называемого веб-сервиса back-end . Контроллер, сервлет или Spring Controller в качестве «внешнего интерфейса» обычно относится к пользовательскому интерфейсу UX / UX, такому как визуализированный HTML + JS, внешний интерфейс SPA или расширенный клиент / толстый клиент (предоставляется, это будет «потребитель сервиса»).
Вам не нужны «метаданные сервиса», чтобы иметь веб-приложение или веб-сервис - хотя, если вы отправляете веб-сервис предназначен для использования разрозненными или нет Тогда n-сторонним клиентам будет хорошей идеей создать WSDL, Swagger или любую другую систему метаданных или описания сервисов, которую использует ваша платформа, чтобы ваши потребители могли создавать своих собственных строго типизированных клиентов.
«Перспектива реализации сервиса»
- Итак, это мое самое большое возражение: на этой диаграмме предполагается, что веб-сервис будет трехуровневым и код контроллера / сервлета является лишь тонким слоем перед типами «приложений», расположенных в других местах системы. Хотя это часто встречается в крупных и сложных приложениях, где у вас будет host-agnosti c код приложения, который предназначен для запуска, например, в интеграционном тесте или модульном тесте. Тестовый хост - или как настольное приложение, по моему опыту, большинство проектов объединяют все логики приложений c внутри кода хоста, специфицированного c (т.е. Spring, Servlets, et c), потому что это значительно упрощает вещи (и потому что эти хосты часто так или иначе поддерживают тестируемость - и идея повторного использования библиотек кода приложения как есть для настольных или мобильных приложений просто не работает в реальности, учитывая огромные различия между автономной и не имеющей состояния моделью запросы веб-сервисов по сравнению с потребностями клиентских приложений, находящихся в состоянии обработки).
В итоге: это не неправильно , но я не Полагаю, это точно описывает большинство (Java) веб-приложений, с которыми я лично имел дело ... но это мое субъективное мнение, и я знаю, что Java фреймворки веб-приложений и веб-сервисов, такие как Spring и Java EE, предназначены для 3-уровневой архитектуры и поощряют ее, я бы не стал их описывать в качестве примера из ямы успеха - я чувствую, что это отчасти связано с недостатками языкового дизайна Java (и тот факт, что эти структуры были разработаны за 20 лет до go до того, как были добавлены дженерики на язык).