L'applicazione client del servizio Web utilizza Apache CXF per generare stub client per la comunicazione con diversi servizi Web. Gli oggetti stub del servizio Web CXF generati hanno un ingombro di memoria piuttosto ampio (10 - 15 oggetti di servizio Web occupano più di 64 MB di memoria). C'è un modo per ridurre l'impatto sull'oggetto CXF?Come ridurre la dimensione della memoria degli oggetti stub del client Apache CXF?
abbiamo avuto problemi simili con Axis. Il problema era che volevamo fare molte chiamate simultanee al servizio web e che i client Axis generati usando il WSDL facevano sì che ogni client usasse molta memoria. I client non sono thread-safe, quindi abbiamo dovuto creare un client per richiesta.
Avevamo due scelte. Per prima cosa abbiamo potuto sfoltire il codice generato, ma non era bello per motivi di manutenzione.
In secondo luogo, abbiamo semplicemente potati il WSDL per rimuovere le parti che non erano rilevanti per noi, e rigenerata snellita clienti. In questo modo, se chiamassimo un metodo di servizio, il client non conterrebbe la massa per i metodi non correlati che non verrebbero utilizzati da quel thread.
Ha funzionato abbastanza bene, ma è ancora un incubo di manutenzione, perché ogni volta che il WSDL viene aggiornato (ad esempio, il nostro partner rilascia una nuova versione del proprio servizio Web), è necessario dedicare tempo alla creazione di wsdls ridotti. La soluzione ideale, suppongo, sarebbe quella di convincere il nostro partner a riconoscere i nostri problemi e assumere la proprietà dei WSDL tagliati.
Abbiamo preso un approccio diverso al cliente CXF. Non ho esaminato la sua impronta di memoria, che non è un problema nel nostro contesto, ma è certamente un metodo di sviluppo più semplice rispetto alla creazione di stub. Sembra qualcosa di simile:
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;
Abbiamo appena facciamo (ovviamente abbiamo costruito alcune classi di utilità per semplificare ulteriormente le cose) per qualsiasi WS vogliamo collegare a in fase di esecuzione (a condizione, naturalmente, abbiamo avere la sua interfaccia Java). Il nostro obiettivo era quello di rendere l'intera WS come trasparente ai programmatori il più possibile. Non abbiamo alcun interesse per WSDL e XSD di per sé. Sospettiamo che non siamo soli.
Nel mio caso il servizio Web stesso è un servizio Web .NET quindi nessuna interfaccia Java. –
Se le vostre esigenze SOAP sono molto semplici, si potrebbe guardare in kSOAP2 che è veramente efficiente della memoria. È progettato per funzionare correttamente in un'applicazione telefonica J2ME.
perché pensi che quegli oggetti esattamente che stanno prendendo la memoria? – Bozho
Ho eseguito alcuni profili grezzi (osservando le dimensioni della memoria del processo nel Task Manager di Windows). Creata un'app di prova, che in un ciclo crea istanze degli stub del servizio Web e si collega al servizio web. Ogni volta che si verifica un binding vengono utilizzati altri 5-10k di memoria. Lo stesso servizio web ha circa 360 metodi web. –
Apache CXF è costruito sulla parte superiore di JAX-WS, quindi credo che sia un problema JAX-WS. Ho la stessa domanda; chiesto qui: http://weblogs.java.net/blog/jitu/archive/2008/08/control_of_jaxb.html#comment-813979 –