Как уменьшить объем памяти объектов-заглушек клиента Apache CXF? - PullRequest
Новая
       53

Как уменьшить объем памяти объектов-заглушек клиента Apache CXF?

21 голосов
/ 23 декабря 2009

Мое клиентское приложение веб-службы использует Apache CXF для создания клиентских заглушек для связи с несколькими веб-службами. Сгенерированные объекты-заглушки веб-службы CXF имеют довольно большой объем памяти (10-15 объектов веб-службы занимают более 64 МБ памяти). Есть ли способ уменьшить занимаемую площадь объекта CXF?

Ответы [ 3 ]

1 голос
/ 24 мая 2011

У нас были похожие проблемы с Axis. Проблема, с которой мы столкнулись, заключалась в том, что мы хотели сделать много одновременных вызовов веб-службы, и клиенты Axis, созданные с использованием WSDL, заставляли каждого клиента использовать много памяти. Клиенты не являются поточно-ориентированными, поэтому нам пришлось создавать одного клиента для каждого запроса.

У нас было два варианта. Сначала мы могли бы сгенерировать сгенерированный код - но это было нехорошо по причинам обслуживания.

Во-вторых, мы просто сократили WSDL, чтобы удалить части, которые нам не подходили, и восстановили сокращенных клиентов. Таким образом, если бы мы вызвали один метод сервиса, его клиент не содержал бы объем для несвязанных методов, которые этот поток не использовал бы.

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

0 голосов
/ 23 сентября 2011

Если ваши потребности в SOAP очень простые, вы можете посмотреть на kSOAP2, который действительно эффективно использует память. Он отлично работает в приложении телефона J2ME.

0 голосов
/ 11 июня 2011

Мы использовали другой подход к клиенту CXF. Я не изучал его объем памяти, что не является проблемой в нашем контексте, но это, безусловно, более простой метод разработки, чем создание заглушек. Это выглядит примерно так: 

JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();

factory.setAddress(endpoint);
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
factory.setServiceClass(myInterface.class);
Object client = factory.create();
((BindingProvider) client).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);

myInterface stub = (myInterface)client;

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

...