Пожалуйста, потерпите меня, если это звучит как банальный вопрос.
Это не тривиальный вопрос.Все тривиальные примеры и руководства по веб-сервисам "Hello World", которые вы найдете в Интернете, никогда не предлагают никаких советов о том, как управлять веб-сервисами "Real World" в дальнейшем.
Это как мы должны модифицировать существующие веб-сервисы?
Ну ... не совсем.Я постараюсь дать общее объяснение и, возможно, возможное решение для вашего конкретного случая, поэтому, пожалуйста, потерпите меня (: D), так как это будет длинный пост.
Контракт первый против контракта последний
Существует два подхода при создании веб-сервисов: сначала контракт, а потом контракт.
Контракт сначала означает создание WSDL, а затем генерирование кода Java, который реализует контракт, предусмотренный WSDL.Последний контракт означает создание вашего Java-кода, а затем генерацию WSDL на основе кода.
Оба имеют свои преимущества и недостатки, но в обоих случаях важен контракт.
Контракт
Ваш WSDL описывает контракт.После развертывания веб-службы контракт должен оставаться замороженным.Контракт является основой для связи между веб-службой и ее клиентами (даже не начинайте с совместимость веб-служб ).
Веб-служба и все клиенты реализуют этот контракт в своем коде.
Я внес изменения в WSDL ...
Это не всегда хорошая идея.
При изменении договора на веб-службу пользователи договора могут разорваться.Когда вы изменяете WSDL, вы регенерируете код веб-службы для поддержки нового контракта.Но как насчет клиентов?
Если новые модификации нарушают договор, вам нужно будет дать указание всем клиентам получить новый договор и изменить их код в соответствии с изменениями.Сколько клиентов у вас есть для этого вашего веб-сервиса?Какие изменения вы внесли в WSDL?
Изменения разрыва контракта против изменений без разрыва
Можно внести некоторые изменения в контракт, не нарушая клиентов.Например, вы можете добавить новую операцию.Клиенты не знают об этом в своем коде, и то, что они не знают, не может повредить им.Вы также можете добавить некоторые необязательные параметры к существующим сообщениям;поскольку они являются необязательными, это означает, что они могут быть опущены при общении, и клиентский код не знает об этом, а то, что они не знают, не может повредить им.Это неразрывные изменения .
Разрывные изменения ... ну ... разорвать контракт.Это включает, например, изменение имен операций, изменение типов или имен параметров сообщений, добавление обязательных параметров и т. Д. Код клиента теперь не работает.Клиенты только что узнали об этом (существующий код больше не работает), и они пострадали.В данный момент ваш веб-сервис больше не используется.
Какие изменения вы внесли в свой WSDL?
Код
В подходе с последним контрактом WSDLгенерируется на основе кода веб-службы.Это имеет тот недостаток, что связывает реализацию кода с WSDL.Если вы вносите изменения в код, вы можете инициировать изменения в WSDL, таким образом, в договоре, который вы согласовали со своими клиентами.
Но если в подходе, основанном на контракте, вы вносите изменения в WSDL, а затем восстанавливаете сетьКод службы сервиса, вы снова изменили договор.Вы не сделали ничего лучше ... и теперь у вас есть еще одна проблема.Что происходит с существующим скелетным кодом веб-службы, который вы сейчас генерируете еще раз?
Генерация кода из WSDL
Когда вы генерируете код из WSDL, вы получаете скелет веб-службы.Это стандартный код, который просто получает сообщения веб-службы по сети в формате SOAP, указанном в контракте.
Обычно вы генерируете этот код и включаете его в свой проект для использования «важным» кодом веб-службы, кодом, который фактически предоставляет «службу». Как вы используете этот код, важно. Вы должны принять во внимание случай повторной генерации кода без перезаписи существующего кода.
Обычно инструмент генерации кода может разделить ваш скелетный код на интерфейс и реализацию этого интерфейса. Вы должны отказаться от сгенерированной реализации и предоставить собственную реализацию интерфейса . Вы предоставляете свою реализацию в другом месте, чтобы она не перезаписывалась при создании кода скелета. Если интерфейс, конечно, изменится, у вас будут проблемы с компиляцией, потому что он не будет соответствовать новому контракту, но, по крайней мере, у вас все еще есть код для его изменения: D.
К сожалению, это не то, что происходит в большинстве проектов. Люди изменяют сгенерированную реализацию напрямую, и когда они снова генерируют скелет, они теряют весь добавленный код. Большинство инструментов генерации вставляют предупреждение в код «Это сгенерированный компьютером код. Все изменения будут потеряны, если этот код будет сгенерирован снова ...» или что-то подобное, но люди слушают?
Возможное решение в вашем случае
Ладно, хватит болтовни ...
Есть ли способ внести изменения в существующий код, не перезаписывая его?
Сделайте это вручную (при условии, что это не прерывается)!
Это займет некоторое время, но это не сложно сделать. Вы берете оригинальный WSDL и генерируете код для него в отдельной папке: Folder1. Возьмите новый WSDL и сгенерируйте для него код в еще одной отдельной папке: Folder2. Сделайте diff из двух каталогов, чтобы увидеть, какие файлы изменились. Загляните внутрь файлов.
Теперь вы знаете, как ваш код должен быть изменен в существующем коде проекта. Теперь вы должны выяснить, был ли изначально сгенерированный код изменен каким-либо образом после его создания. Сравните папку проекта с папкой1.
Затем внесите изменения вручную.
Если вместо этого это хрупкое изменение, возможно, вы захотите проверить, можно ли перенести клиентов. В противном случае вам, возможно, придется выставить свою веб-службу на двух конечных точках, каждая с собственным контрактом WSDL, на одну и ту же веб-службу и со временем перенести клиентов, если это вообще возможно.