Почему это плохо программирует для использования веб-сервиса с сохранением информации и почему это было бы позволено?
Почему бы не передать местоположение файла свойств в качестве аргумента командной строки (после флага)? если его нет, используйте файл по умолчанию в jar-файле.
2 ответа
Вся цель веб-службы - предоставить часть функциональности в одной транзакции с высокой степенью масштабируемости. Это означает, что все должно быть простым и атомарным.
Когда вам нужно сделать несколько вызовов для выполнения операции, у вас есть большой потенциал оставить транзакции зависшими. Клиент возвращается? Они сделали? Как долго сделка должна оставаться открытой? Они разбились? Как следует обрабатывать откаты?
Ответы на эти вопросы могут радикально повлиять на ресурсы, необходимые для работы вашей службы. Вот почему все рекомендуют делать все сразу.
Вот несколько причин, о которых я могу подумать:
Стоимость поддержания состояния придется нести только на стороне сервера - потребители услуг редко являются веб-браузерами, поэтому файлы cookie не используются. Это снижает производительность вашего сервера и увеличивает сложность вашего дизайна.
Потребитель сервиса - это умная программа, а не тупой браузер. Таким образом, программа (почти всегда) сохраняет свое состояние. Другими словами, когда вы предоставляете услугу, ваш потребитель будет запрашивать именно те данные, которые ему нужны. Поддержание состояния на сервере становится устаревшим и ненужным.
Транзакции - служба - это ненадежная точка в вашей системе, потому что ее клиенты в основном интеллектуальны и они решают, когда сообщать вам об изменениях в своем состоянии. Это означает, что если вы поддерживаете состояние, вам, возможно, придется подождать между вызовами службы, чтобы завершить транзакционную операцию. И нет абсолютно никакой гарантии, что клиент когда-либо позвонит в следующий сервис.
Есть много причин, но это те, которые я могу придумать в своей голове:)