3 ms·

It's because no one uses REST and then choose to go back to spending days making java axis web services and .net clients play well together with ugly hackish cu

by johnb 19y ago

It's because no one uses REST and then choose to go back to spending days making java axis web services and .net clients play well together with ugly hackish custom soap extensions. Or maybe I'm just venting about my shitty week at work :)

c1sc0 19y ago
Shitty week at work? Don't get me started ... that was the reason for this thread in the first place: an 'enlightened' architect imposing Axis/SOAP & then being surprised at the implementation-level problems.
- geebee 19y ago
  I used Axis for some very minor work, and it wasn't too bad. I didn't get into SOAP at all, but it seemed like a good and (by java standards) lightweight way to turn a bunch of POJOs into web services quickly. What are some of the bad implementation problems you've experienced or heard about? Btw, I'm definitely not asking this to challenge the truth of your statement (ie., I'm not looking for a response to pick apart and argue - I would genuinely like to hear about some of the pitfalls you've seen).
  - c1sc0 19y ago
    I was initially impressed with the ease of converting some classes into SOAP requests with axis, but after a while we got random service outages & bad error handling. From previous experience in the biological field I saw great plans, lovely (& expensive) plans to develop grand services in SOAP ... that never actually materialized ... & were converted to REST spitting out standard files. I think the ideas of SOAP, WSDL & Co are actually very interesting but as a WS consumer I've come to shun SOAP services. In my opinion, human discoverability & excellent documentation are core to any webservice. Maybe throw in some example implementations or lightweight libraries specific to your service.
    - geebee 19y ago
      So far, our internal clients have been the only client for the axis-driven web service, so I haven't really opened it up. In other words, we're really just using axis2 for internal rpc-style calls. We also aren't transmitting much in a soap message - really just the parameters to run. The bulk of data transfer is handled through other methods.

by johnb 19y ago

c1sc0 19y ago

Shitty week at work? Don't get me started ... that was the reason for this thread in the first place: an 'enlightened' architect imposing Axis/SOAP & then being surprised at the implementation-level problems.

geebee 19y ago
I used Axis for some very minor work, and it wasn't too bad. I didn't get into SOAP at all, but it seemed like a good and (by java standards) lightweight way to turn a bunch of POJOs into web services quickly. What are some of the bad implementation problems you've experienced or heard about? Btw, I'm definitely not asking this to challenge the truth of your statement (ie., I'm not looking for a response to pick apart and argue - I would genuinely like to hear about some of the pitfalls you've seen).
- c1sc0 19y ago
  I was initially impressed with the ease of converting some classes into SOAP requests with axis, but after a while we got random service outages & bad error handling. From previous experience in the biological field I saw great plans, lovely (& expensive) plans to develop grand services in SOAP ... that never actually materialized ... & were converted to REST spitting out standard files. I think the ideas of SOAP, WSDL & Co are actually very interesting but as a WS consumer I've come to shun SOAP services. In my opinion, human discoverability & excellent documentation are core to any webservice. Maybe throw in some example implementations or lightweight libraries specific to your service.
  - geebee 19y ago
    So far, our internal clients have been the only client for the axis-driven web service, so I haven't really opened it up. In other words, we're really just using axis2 for internal rpc-style calls. We also aren't transmitting much in a soap message - really just the parameters to run. The bulk of data transfer is handled through other methods.