Note that there are some explanatory texts on larger screens.

plurals
  1. POJava: Fast and generic gateway Data to Soap
    text
    copied!<p>I do want to build a generic gateway from a nested map (generated from binary data stream) to SOAP- clients.</p> <p>Background: a non-java-application which needs to call SOAP-Services can't generate json or SOAP/XML, but easily generate a custom protocol (which is under our control).</p> <p>So a proxy is needed. That proxy should not be rewritten on every change of the WSDL or rollout of the next Webservice.</p> <p>My plan is:</p> <ul> <li><p>to have url, port and service-name (url:port/service-name) as "strict" defined parameters of that proxy, </p></li> <li><p>to have the SOAP Action as a "strict" defined parameter</p></li> <li><p>to request (possibly cached) the wsdl of url:port/service-name?wsdl and initiate the stub-call dynamically (cached),</p></li> <li><p>to fill the values, which are present in the nested map, to that stub</p></li> <li><p>call the SOAP-Service</p></li> <li><p>convert the answer back to that binary protocol.</p></li> </ul> <p>If some necessary values are missing it should send the equivalent of a SOAP-Error.</p> <p>All that of course with small (affordable) latency, high stability, absolute minimal deployment downtime (for updates) and quite some load.</p> <p>I see several possibilities:</p> <p>a) Using a ESB like WSO2ESB. There I would implement the stream format as a special input format adapter, convert it to internal XMLStream (at least the json-adapters seem to work that way) and send it to mediator. That mediator would try something like in <a href="http://today.java.net/pub/a/today/2006/12/13/invoking-web-services-using-apache-axis2.html" rel="nofollow">http://today.java.net/pub/a/today/2006/12/13/invoking-web-services-using-apache-axis2.html</a> "Creating a Dynamic Client" and call the SOAP-Service directly.</p> <p>b) using a MOM-Middleware like ApacheMQ with Camel,</p> <p>c) reduce it to something like Apache Karaf and CXF</p> <p>I'm a bit lost between all those possibilities, and those are just more or less arbitrary samples of each kind.</p> <p>Thoughts to a):</p> <ul> <li><p>minus: It feels a bit odd to have no ESB-Target, since the mediator would directly call the given SOAP-Requests</p></li> <li><p>minus: I wonder if internally converting into XML-Stream would not cost extra time and resources</p></li> <li><p>minus: changing the code needs restart of the WSO2ESB as far as I got it</p></li> <li><p>plus: instead of url, port, service-name I could define symbolic names which are resolved using the ESB -- iff that doesn't take extra milliseconds.</p></li> </ul> <p>For b) I have not yet checked how easily those format conversions are in Camel and if SOAP-Service-Requests fit into Message Sending and Queueing.</p> <p>I did already some searches to that topic but it's really confusing because of the overlapping scopes of quite different products. I thought it to be a standard problem but apparently there are no obvious solutions - at least I didn't find them.</p> <p>I do hope to get a clue which of those solutions could lead into trouble or much work (and which into easy success), and I hope that there is some reason in my approach.</p> <p>Thanks for any qualified comments!</p> <p>Marco</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload