Опасения по поводу управления артефактами JAX WS - PullRequest
Новая
       0

Опасения по поводу управления артефактами JAX WS

1 голос
/ 29 марта 2011

Я разрабатываю приложение, которое интенсивно использует веб-сервисы.Я буду разрабатывать клиентскую и серверную части этого приложения.Я хотел бы использовать JAX WS (который я новичок), потому что это, кажется, будущее для веб-сервисов для Java, но у меня есть ряд проблем, связанных с артефактами.Ни одно из этих опасений не является нарушением условий сделки, но в целом JAX WS создает много неудобств.Я новичок в JAX WS, поэтому, возможно, есть вещи, о которых я не знаю, которые могли бы облегчить мои проблемы.

Вот мои проблемы:

  1. Я ожидаю, чтодовольно большое количество POJO, которые передаются между клиентом и сервером (из-за отсутствия лучшего термина я буду называть эти транспортные объекты).Я хотел бы включить в эти объекты документацию и бизнес-логику (для начала, equals, hashcode, toString).Если у меня есть бизнес-логика в этих классах, я не могу использовать wsimport для создания аннотаций для них, и мне приходится управлять ими вручную.Кажется громоздким и подверженным ошибкам.

  2. У меня есть выбор: заставить систему сборки создавать артефакты или же разработчики создают артефакты и проверяют их в системе контроля версий.Если артефакты создаются системой сборки, то всякий раз, когда член команды обновляет API, каждый должен создавать артефакты в своих собственных средах разработки.Если артефакты создаются разработчиками и проверяются в системе контроля версий, каждый раз, когда член команды переименовывает или удаляет API, он должен не забыть удалить артефакты-оболочки.Любой подход кажется обременительным.Какова лучшая практика здесь?

  3. wsimport создает все артефакты в одном пакете.Я буду создавать несколько сервисов, и у меня будет несколько транспортных объектов, к которым предоставлен общий доступ, и поэтому мне нужно импортировать все мои сервисы в один пакет.Если у двух сервисов есть API с одинаковым именем, артефакты обертки столкнутся.

  4. Я предполагаю, что в моих сервисах будет хотя бы сто API.Это означает как минимум 200 классов-обёрток.Похоже, огромное количество беспорядка.Много-много классов, которые не представляют интереса для развития.Что еще хуже, эти классы-обертки будут находиться в том же пакете, что и транспортные объекты, которые будут одними из наиболее часто используемых классов в моей системе.Отношение сигнал / шум очень низкое для самого важного пакета в моей системе.

Буду признателен за любые указания, которые кто-либо может дать мне, чтобы упростить разработку моего приложения.

1 Ответ

2 голосов
/ 29 марта 2011

Если у вас есть контроль над клиентом и сервером, вам не нужно генерировать клиента с wsimport.В настоящее время я делаю это следующим образом: один проект определяет API для веб-службы.API состоит из интерфейса и всех классов «объектов переноса».Еще один проект реализует сервис.Теперь вы можете распространять API для клиента, который теперь может использовать службу и может использовать все ваши дополнительные бизнес-методы.

Предполагая, что ServiceInterface является вашим интерфейсом службы, клиент может выглядеть следующим образом: 

Service s = Service.create(
        new URL("http://example.com/your_service?wsdl"),
        new QName("http://example.com/your_namespace", "YourServiceName"));
ServiceInterface yourService = s.getPort(
        new QName("http://example.com/your_namespace", "YourPortName"),
        ServiceInterface.class);

И вот так у вас есть сервисный клиент.Таким образом, вы можете использовать все свои методы (1), у вас есть полный контроль над вашими пакетами (3), и у вас нет никаких классов-оболочек, поскольку все они генерируются во время выполнения (4).Я думаю, что (2) и этим решается.

Ваш вопрос довольно велик, поэтому, если мне не удается достаточно подробно остановиться на каком-либо пункте, оставьте комментарий, и я попытаюсь подробнее разобраться.

...