Web Service Method retunrs list of DOM elements, is it holding it in memory

I used wsimport to create proxy classes to be used by the web services client. One of the methods in the classes returns a List<Element> where Element is org.w3c.dom.Element, if I reference a pointer to the List<Element> , will it be holding all the elements in the list in memory, or will bring the data to the client side only when I access the data in each element and be garbage collected when the reference to each element is out of scope ?.

This is because the List potentially has a very large number of elements and we would prefer to stream in each result to control the jvm memory use.

I think it'll on client side. Server cannot reference with all clients' request, just push data to the client side. Simply check the task manager on both side.

Yes, I checked the TCP traffic and it looks like the whole thing is on the client side. How to optimize this so that the payload is brought it little by litle, is it better to swtich to XML streaming and deal with the raw SOAP messages rather than use the proxy classses ?

Yes, using XML streams more reliable, it's fastest it's secure. Most importantly is you've a large collection of data, download them to the client side periodically. I don't know your design exactly, there should be provision for those kind of changes.

This might be a basic question, if I do not use proxy classes generated from the WSDL, how can I set up the web services client to use XML streaming, are there are tools available like the wsimport tool , or would i have to be parsing each SOAP message ? that seems like a painful prospect!

Returning the XML is in string format?

There are many other ways too. As you said passing each SOAP message is a hard work.

The Java(TM) Web Services Tutorial

Quote:

---

Originally Posted by Eranga

Yes, using XML streams more reliable, it's fastest it's secure.

---

More reliable? Doubt it.
Faster? Possibly.
More secure? No. Just as secure.

Quote:

---

Originally Posted by Tolls

More reliable? Doubt it.

---

Web services are inherently unreliable and not well-suited for long run process. BUT, depends on the messaging it could achieve for these kind of non-critical communication. Framework such as BizTalk, ebXMl and so on does the same.

Quote:

---

Originally Posted by Tolls

Faster? Possibly.

---

Yes, this is comparable. However requesting a streamed data set is not faster than passing XML stream over a WS.

Quote:

---

Originally Posted by Tolls

More secure? No. Just as secure.

---

Again I think this is based on how we design the protocol. How we authenticate the communication, how the acknowledgments and re-sending data works are some of we have to consider.

Quote:

---

Originally Posted by Eranga

Web services are inherently unreliable and not well-suited for long run process. BUT, depends on the messaging it could achieve for these kind of non-critical communication. Framework such as BizTalk, ebXMl and so on does the same.

---

But it is a web service. They just want to read the SOAP stream directly...so no gain between reading the xml stream or not. The data travelling between the server and the client would be identical.

Quote:

---

Originally Posted by Eranga

Yes, this is comparable. However requesting a streamed data set is not faster than passing XML stream over a WS.

---

Again, the data travelling is the same. The only difference (and this is the only place where a gain might be had) is removing the client translation into objects...and this is only a gain if what you;re doing instead is faster.

Quote:

---

Originally Posted by Eranga

Again I think this is based on how we design the protocol. How we authenticate the communication, how the acknowledgments and re-sending data works are some of we have to consider.

---

Again, they are talking about reading the SOAP directly...so the protocol is a SOAP based web service. That's what I'm talking about.