• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Building REST wrapper over an existing SOAP web service

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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

 
reply
    Bookmark Topic Watch Topic
  • New Topic