Кстати, в конфигурации нет кода, публикующего сервисы. Более того, и в примерах кода вы не найдете строк публикации сервисов. Это делается внутри используемых сторонних библиотек. То есть сравнивать ваш код и конфигурационные файлы просто не корректно.
Это разные конфигурации, править ни чего не нужно. Можно конечно слить оба примера и конфигурации в одно приложение, если очень хочется.
А что если я усложню задачу! Условный заказчик очень хочет RMI протокол использовать, ну или его "брата" CORBA. И в придачу на почтовые запросы отвечать.
Хорошо, говорил. Но если Вы привели мои слова, то вспомните к чему они относились? Они относились к корректировке файла конфигурации. В этих то примерах что править? Тут нет ни одного "переменного" параметра. Править нечего, следовательно внести ошибку невозможно. Если только намерено испортить конфигурационный файл.
У меня хоть есть весь исходный успешно выполняемый код на GitHub. У Вас вообще ни чего нет. Обрывки непонятно чего, непонятно откуда. Я же верю Вам на слово.
Я опять что то пропустил? И мы уже перешли на обсуждение альтернатив публикаций SOAP и REST сервисов? И какое отношение ваши фрагменты кода имеют к распределенным средам?
Вы уже второй день постоянно задаете один и тот же не относящийся к "делу" (статье) вопрос. Все время сваливаетесь на какие частности. Хватит. Не судьба так не судьба.
СУБД само по себе имеет какую то ценность? Нет и управлять ей нечем, если БД предметной области не будет.
Первоначально, большинство программ разрабатывается на заказ. Затем результат и требования от разных заказчиков анализируется и предметная область отделяется от программного кода. Результат предлагается другим заказчикам. Так появились ОС (Билл Гейтс первую свою ОС по заказу IBM сделал), СУБД, брокеры сообщений и много чего другого.
СУБД в "коробке" программный код? Да. Привязан к предметной области? Нет.
Установили, сконфигурировали, создали таблицы предметной области — создали конфигурацию в среде выполнения. Если это все (весь сервер с установленной СУБД и БД) выдернуть и поставить, условно, из Газпрома Роскосмосу. Будет это работать? Нет. Сервер конечно включиться и СУБД запуститься. Но даже подключиться к нему будет нельзя, как минимум надо сетевой интерфейс переконфигурировать.
Но если сервер и СУБД переконфигурировать, базу снести и создать другую — создать новую конфигурацию, то будет.
Программный код, в общем случае, не привязан к предметной области и среде выполнения. В разных средах выполнения один и тот же программный код может использовать разные конфигурации. Программный код в "чистом виде" переносим из одной среды выполнения в другую.
Конфигурация одной среды выполнения может быть не приемлема для этого же программного кода в другой среде выполнения. Конфигурация не переносима из среды в среду.
Поэтому программный код должен быть отделен от конфигурации приложения. Если программный код смешан с конфигурацией он теряет переносимость.
Да
Кстати, в конфигурации нет кода, публикующего сервисы. Более того, и в примерах кода вы не найдете строк публикации сервисов. Это делается внутри используемых сторонних библиотек. То есть сравнивать ваш код и конфигурационные файлы просто не корректно.
Это разные конфигурации, править ни чего не нужно. Можно конечно слить оба примера и конфигурации в одно приложение, если очень хочется.
А что если я усложню задачу! Условный заказчик очень хочет RMI протокол использовать, ну или его "брата" CORBA. И в придачу на почтовые запросы отвечать.
Подробную пошаговую инструкцию опубликуете вашего примера.
Хорошо, говорил. Но если Вы привели мои слова, то вспомните к чему они относились? Они относились к корректировке файла конфигурации. В этих то примерах что править? Тут нет ни одного "переменного" параметра. Править нечего, следовательно внести ошибку невозможно. Если только намерено испортить конфигурационный файл.
У меня хоть есть весь исходный успешно выполняемый код на GitHub. У Вас вообще ни чего нет. Обрывки непонятно чего, непонятно откуда. Я же верю Вам на слово.
При готовой конфигурации, риск отсутствует.
Я опять что то пропустил? И мы уже перешли на обсуждение альтернатив публикаций SOAP и REST сервисов? И какое отношение ваши фрагменты кода имеют к распределенным средам?
О каких рисках идет речь?
И что за код тут опубликован?
Статью в студию, я не телепат, чтобы по обрывкам кода догадываться, что под ним подразумевается.
Подали эту конфигурацию и получили SOAP-сервис
Подали эту и уже REST-сервис имеем
Вам нужно почитать статьи о загрузчиках Java.
Динамическое связывание классов во время выполнения — да на этом построена вся идеология среды выполнения JVM.
Я что то пропустил? Мы уже ведем речь о загрузчике кода?
Останется код, которому можно "подать" при запуске совершенно другую конфигурацию и таким образом получить совершенно другую информационную систему.
Вы уже второй день постоянно задаете один и тот же не относящийся к "делу" (статье) вопрос. Все время сваливаетесь на какие частности. Хватит. Не судьба так не судьба.
Ну не хватает мне смайликов ...
Я высказал свою точку зрения, ваши реплики к ней это уже частности.
СУБД само по себе имеет какую то ценность? Нет и управлять ей нечем, если БД предметной области не будет.
Первоначально, большинство программ разрабатывается на заказ. Затем результат и требования от разных заказчиков анализируется и предметная область отделяется от программного кода. Результат предлагается другим заказчикам. Так появились ОС (Билл Гейтс первую свою ОС по заказу IBM сделал), СУБД, брокеры сообщений и много чего другого.
Я описал в общем виде.
СУБД в "коробке" программный код? Да. Привязан к предметной области? Нет.
Установили, сконфигурировали, создали таблицы предметной области — создали конфигурацию в среде выполнения. Если это все (весь сервер с установленной СУБД и БД) выдернуть и поставить, условно, из Газпрома Роскосмосу. Будет это работать? Нет. Сервер конечно включиться и СУБД запуститься. Но даже подключиться к нему будет нельзя, как минимум надо сетевой интерфейс переконфигурировать.
Но если сервер и СУБД переконфигурировать, базу снести и создать другую — создать новую конфигурацию, то будет.
Программный код, в общем случае, не привязан к предметной области и среде выполнения. В разных средах выполнения один и тот же программный код может использовать разные конфигурации. Программный код в "чистом виде" переносим из одной среды выполнения в другую.
Конфигурация одной среды выполнения может быть не приемлема для этого же программного кода в другой среде выполнения. Конфигурация не переносима из среды в среду.
Поэтому программный код должен быть отделен от конфигурации приложения. Если программный код смешан с конфигурацией он теряет переносимость.
в статье все расписано, читайте и найдете ответы на ваши вопросы.
Хорош, дискуссия уже давно потеряла какой либо конструктивный характер.
Уже десть раз попросил, статью в студию
Вы задаете вопрос, образно, что в черном ящике.
Мое видение описано в статье, где ваше?
Очень не хватает тут смайликов.
Статью в студию.