динамически определяемые аргументы веб-метода - PullRequest
Новая
       13

динамически определяемые аргументы веб-метода

2 голосов
/ 07 января 2011

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

Все основано на JAXB-совместимой схеме клиента.Схема скомпилирована в классы Java и упакована как jar клиента.(Большое спасибо членам stackoverflow, которые помогли мне сделать это на лету).

И вот проблема: они хотят, чтобы веб-сервис (SOAP) делал все, что они в настоящее время делают через веб-интерфейс.И, конечно же, с типами wsdl в соответствии со схемой JAXB они динамически меняются и ежедневно развертываются :( На самом деле все операции, которые они выполняют через Интернет:

  1. Запуск / остановка контейнера приложения (общийзадача, а не проблема)
  2. Вставка определенного клиентом объекта в контейнер
  3. Извлечение объектов определенного типа из контейнера

"3" не является проблемой один раз "2 "в порядке. Но" 2 "сводит меня с ума, и я нуждаюсь в вашем совете, ПРЕЖДЕ ЧЕМ я начинаю что-то делать. С точки зрения WebService мой вопрос: Как опубликовать конечную точку WS следующим методом, предполагая, что тип аргументаопределяется клиентской JAXB-схемой : 

@WebMethod
public void inject(UserDefinedObject obj) {
  getAppContainer().inject(obj); // that's all I have to implement
}

Вот подходы, о которых я думаю:

  1. Использование объекта в качестве аргумента: public void inject(Object obj); и кода ServletFilter для изменения запроса / ответа xml в соответствии со схемой клиента. Но я не уверен, что сервлет WS не будет проверять сигнатуру метода и генерировать исключения в этом случае. Другой вопрос заключается в том, получу ли я доступ кзапросите xml из этого метода для выполнения демаршаллинга JAXB.

  2. Поскольку я уже собираю клиентские jar-файлы, я также мог бы скомпилировать конечные точки веб-службы и динамически развертывать их как пакеты OSGI.Я абсолютно новичок в OSGI, здесь слишком много вопросов: возможно ли вообще, что насчет моего слуха, нужно ли мне делать все как OSGI, как общаться с EJB и т. Д., И т. Д.

  3. Больше гуглить, но, боюсь, Брин и Пейдж начнут меня заряжать.

Есть еще идеи?

1 Ответ

0 голосов
/ 18 января 2011

Окончательно решил в пользу опции OSGi, как описано в решении , о том, как правильно превратить модуль EAR в комплект OSGi .После того, как моя война с администраторами была полностью прекращена, она превратилась в пакет OSGi и, следовательно, получила доступ к BundleContext, можно динамически развертывать / отменять развертывание личной веб-службы клиента на лету: 

  Bundle clientWsBundle = bundleContext.installBundle(bundleId, bundleWarInputStream);
  registerNewBundle(clientWsBundle);

Не уверен, что это решениеприменимо к другим серверам приложений не на основе OSGi.Я предполагаю, что потребуется некоторая дополнительная конфигурация OSGI, чтобы она работала гладко во взаимодействии с оставшейся частью EAR.

...