wood burning stoves*
The moose likes Web Services and the fly likes Building REST wrapper over an existing SOAP web service Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Building REST wrapper over an existing SOAP web service" Watch "Building REST wrapper over an existing SOAP web service" New topic
Author

Building REST wrapper over an existing SOAP web service

Rana Dey
Greenhorn

Joined: Jul 05, 2012
Posts: 10
My team is developing an REST service wrapper over an existing SOAP based web service. We don't exactly know the SOAP service internals, just have access to the WSDL file. Our REST service wrapper will be just one-to-one mapping.

I know in real its not adhere to REST philosophy, even though please allow me to call it REST services. This REST service will be deployed on Tomcat and many client will be accessing it concurrently.

The current implementation is that for each client we will be creating an proxy object (using SOAP WSDL proxy class). This proxy object will be used to call the SOAP APIs. The SOAP requires authentication details binding over the proxy objects, so we are saving these objects for each client in memory at runtime while making first REST call to establish a session.

The saved object is fetched at runtime using an SessionID identifier. Now the problem is these proxy object occupy large memory chunks and only few REST clients are supported. (With default 64 MB only 19 REST clients can run). This is the trouble now we want to change the approach and would require your suggestions.

Kindly let me know if any better solution exists. We don't want a DB to store the objects.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Remove the notion of a session with your REST clients and treat every request as a new one containing all the information required to perform the requested operation.
It's already a bit square as it is and creating sessions in REST is just stretching the corners even more.
Rana Dey
Greenhorn

Joined: Jul 05, 2012
Posts: 10
E Armitage wrote:Remove the notion of a session with your REST clients and treat every request as a new one containing all the information required to perform the requested operation.
It's already a bit square as it is and creating sessions in REST is just stretching the corners even more.


From REST services usability point it doesn't seems acceptable to burden client developer to pass extra parameters for every request.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Why use REST at all here then if your interaction is not stateless.
If you still want to continue hammering at this until it fits then consider using a separate token server/service.
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
The saved object is fetched at runtime using an SessionID identifier. Now the problem is these proxy object occupy large memory chunks and only few REST clients are supported. (With default 64 MB only 19 REST clients can run). This is the trouble now we want to change the approach and would require your suggestions.

Kindly let me know if any better solution exists. We don't want a DB to store the objects.


Try serializing to disk using the SessionID as a file name when client storage gets tight. Serialization is surprisingly fast in my experience.

Bill

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Building REST wrapper over an existing SOAP web service
 
Similar Threads
Sample Questions for 288 - Need answers
Incompatibility side effects of refactoring
Changing USERNAME_PROPERTY/PASSWORD_PROPERTY values in service proxy object at runtime?
web service not available
advice/question regarding server side wsdl stubs