Если вы занимаетесь разработкой WS-кода в первую очередь, тогда можно распространить интерфейс и передать его клиенту. Я считаю, что @WebService
не требуется (?) Для интерфейса (только реализация), поэтому у клиента нет зависимостей от этой аннотации.
Даже если вы работаете с веб-службами, использующими код, вы все равно можете загрузить документ WSDL, сгенерированный для вас Apache CXF, и вместо этого передать его клиенту. При таком подходе (который считается более зрелым, не говоря уже о том, что он может использоваться на разных платформах, таких как .NET), клиент должен генерировать заглушки (используя инструмент, подобный wsdl2java
). Этот процесс автоматически создаст очень похожий интерфейс клиента.
Это одна из причин, по которой так много людей предпочитают разработку на основе контракта - один и тот же WSDL используется для создания заглушек на стороне клиента и реализации WS на стороне сервера. Это ограничивает область (случайных) несовместимостей.