Как представить EJB как веб-сервис, который позже позволит мне поддерживать совместимость клиента при изменении ejb?

Question

Множество фреймворков позволяют мне выставлять ejb как веб-сервис.

Но через 2 месяца после публикации первоначального сервиса мне нужно изменить ejb или любую часть его интерфейса. У меня все еще есть клиенты, которым нужен доступ к старому интерфейсу, поэтому мне, очевидно, нужно иметь 2 веб-сервиса с разными сигнатурами.

У любого есть какие-либо предложения о том, как я могу это сделать, желательно, чтобы инфраструктура выполняла основную работу по созданию оберток и копированию логики (если нет еще более умного способа).

Я могу выбрать основу веб-сервиса на основе этого, поэтому предложения приветствуются.

Редактировать: я знаю, что мои изменения могут нарушить совместимость, и я полностью осознаю, что мне понадобятся две службы с разными пространствами имен одновременно. Но как я могу сделать это простым способом?

Answer 1

Не думаю, что для этого нужны какие-то дополнительные фреймворки. Java EE позволяет напрямую представлять EJB как веб-сервис (начиная с EJB 2.1 ; см. Пример для J2EE 1.4 ), но с EE 5 это еще проще:

@WebService
@SOAPBinding(style = Style.RPC)
public interface ILegacyService extends IOtherLegacyService {
    // the interface methods
    ...
}

@Stateless
@Local(ILegacyService.class)
@WebService(endpointInterface = "...ILegacyService", ...)
public class LegacyServiceImpl implements ILegacyService {
    // implementation of ILegacyService
}

В зависимости от сервера приложений вы можете предоставить ILegacyService в любом подходящем месте. Как сказал Джезелл, вы должны попытаться внести изменения, которые не изменяют контракт, непосредственно в этот интерфейс. Если у вас есть дополнительные изменения, вы можете просто предоставить другую реализацию с другим интерфейсом. Общую логику можно превратить в суперкласс LegacyServiceImpl.

Answer 2

Хорошо, здесь идет;

похоже, что dozer.sourceforge.net является приемлемой отправной точкой для выполнения тяжелой работы по копированию данных между двумя параллельными структурами. Я полагаю, что многие веб-фреймворки могут генерировать клиентские прокси, которые можно повторно использовать в контексте сервера для обеспечения совместимости.

Answer 3

Я не парень из EBJ, но я могу рассказать вам, как это обычно делается в мире веб-сервисов. Если у вас есть не нарушающее контракт изменение (например, добавление необязательного свойства), вы можете просто обновить договор, и с потребителями все будет в порядке.

Если у вас есть серьезное изменение в контракте, то способ справиться с ним - создать новый сервис с новым пространством имен для его типов. Например, если ваш первый сервис имел пространство имен:

http://myservice.com/2006

Ваш новый может иметь:

http://myservice.com/2009

Разоблачить этот контракт для новых потребителей.

Как вы справляетесь со старым контрактом, зависит от вас. Вы можете направить все запросы на старый сервер и позволить клиентам выбирать, когда обновляться до новых серверов. Если вы можете использовать некоторую логику для обновления запросов до формата, ожидаемого новой службой, то вы можете извлечь логику старой службы и заменить ее вызовами новой. Или вы можете просто отказаться от всего этого вместе и завершить все вызовы старой службы.

PS: с этим гораздо проще справиться, если вы создаете объекты класса сообщений, а не повторно используете сущности домена.