This week's book giveaway is in the Java in General forum.
We're giving away four copies of Think Java: How to Think Like a Computer Scientist and have Allen B. Downey & Chris Mayfield on-line!
See this thread for details.
Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Building REST wrapper over an existing SOAP web service

 
Rana Dey
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13061
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic