4 ms·

It's one button away... as long as you have the same technology on both sides (and then, why are you incurring all this overhead anyway?) Maybe this has changed

It's one button away... as long as you have the same technology on both sides (and then, why are you incurring all this overhead anyway?) Maybe this has changed in the last 3 or 4 years, but the last time I tried to get .Net and Java stacks talking via SOAP was a royal pain.

RyanMcGreal 16y ago
I'm experiencing this particular brand of hell right now.
masklinn 16y ago
We're talking about The Enterprise here, this kind of stuff is not even on the radar.
- darklajid 16y ago
  I'm part of a 7 figure project right now. We're a .Net shop, they have a Java infrastructure (and are as "enterprise" and process-laden as you can imagine and then some). We need to integrate -> See, we're right there. SOAP it is for us and I do have to say that I'm rather relaxed. For us it's just one way (Java services, Java generated WSDL, we just consume/use the stuff), but it works rather well. Unless you don't know about 3.5/WCF/Service References and try to do it the old-fashioned "Web Reference" ASP.Net way: That's a royal pain and just plain doesn't work at all for some (valid) SOAP things (some sequences of alternating complex types a la [Key, Value, Key, Value,...] for example cannot be mapped). Guess how I found out..
Roboprog 16y ago
Boy, you said it. I tried to upvote, but I guess commenting kills my upvote. Fing "Enterprise". Beam me up Scotty, there's no intelligent life here. IBM and Microsoft drop the SOAP, and we get stuck picking it up. I hate* implementing SOAP clients for random SOAP server implementation of the day.. I'm sorry, Rob will be back shortly. We apologize for the outburst :-) ... Boy, you NAILED it exactly, though. REST sure seems simpler: define the document/content types, or schema, and just use links to GET things. Save POST for the few things that actually change state, then document carefully how the content is to be sent back up. It turns out a good deal of services really are READ-ONLY anyway. Making the simple things simple: give me my damn document! Let's keep it encrypted, and I'll prove I'm authorized to see it: https:/acme.com/service?acct=xxx&pass=yyy&item_key=123 ... Content: binary/what-you-wanted blah blah blah... Painfully easy vs just freaking painful tweaking of SOAP nonsense. Die, SOAP, die!
derefr 16y ago
> It's one button away... as long as you have the same technology on both sides (and then, why are you incurring all this overhead anyway?) If you want to make it look like you have an open API, while only having to do enough work to expose the way your two predefined systems already communicate, SOAP is the answer.

RyanMcGreal 16y ago

I'm experiencing this particular brand of hell right now.

masklinn 16y ago

We're talking about The Enterprise here, this kind of stuff is not even on the radar.

darklajid 16y ago
I'm part of a 7 figure project right now. We're a .Net shop, they have a Java infrastructure (and are as "enterprise" and process-laden as you can imagine and then some). We need to integrate -> See, we're right there. SOAP it is for us and I do have to say that I'm rather relaxed. For us it's just one way (Java services, Java generated WSDL, we just consume/use the stuff), but it works rather well. Unless you don't know about 3.5/WCF/Service References and try to do it the old-fashioned "Web Reference" ASP.Net way: That's a royal pain and just plain doesn't work at all for some (valid) SOAP things (some sequences of alternating complex types a la [Key, Value, Key, Value,...] for example cannot be mapped). Guess how I found out..

Roboprog 16y ago

Boy, you said it. I tried to upvote, but I guess commenting kills my upvote. Fing "Enterprise". Beam me up Scotty, there's no intelligent life here. IBM and Microsoft drop the SOAP, and we get stuck picking it up. I hate* implementing SOAP clients for random SOAP server implementation of the day.. I'm sorry, Rob will be back shortly. We apologize for the outburst :-) ... Boy, you NAILED it exactly, though. REST sure seems simpler: define the document/content types, or schema, and just use links to GET things. Save POST for the few things that actually change state, then document carefully how the content is to be sent back up. It turns out a good deal of services really are READ-ONLY anyway. Making the simple things simple: give me my damn document! Let's keep it encrypted, and I'll prove I'm authorized to see it: https:/acme.com/service?acct=xxx&pass=yyy&item_key=123 ... Content: binary/what-you-wanted blah blah blah... Painfully easy vs just freaking painful tweaking of SOAP nonsense. Die, SOAP, die!

derefr 16y ago

> It's one button away... as long as you have the same technology on both sides (and then, why are you incurring all this overhead anyway?) If you want to make it look like you have an open API, while only having to do enough work to expose the way your two predefined systems already communicate, SOAP is the answer.