Sending data to a webservice

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
...you don't know how to use it?
Or you're just an ignorant fool that's just trying to keep your job secure with antiquated tools. There are vastly superior transformation formats that will blow SOAPS encoding/decoding times out of the water.
 

me_

Senior Member
Joined
Oct 11, 2013
Messages
657
Or you're just an ignorant fool that's just trying to keep your job secure with antiquated tools. There are vastly superior transformation formats that will blow SOAPS encoding/decoding times out of the water.
When you say SOAP, do you mean XML encoding or decoding? Or are you being specific about the layers of the SOAP protocol across the various transmission channels?
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
When you say SOAP, do you mean XML encoding or decoding? Or are you being specific about the layers of the SOAP protocol across the various transmission channels?
SOAP uses HTTP. I am referring to the bloat that is the SOAP definition format. That is why I said "transformation formats".
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,930
When you say SOAP, do you mean XML encoding or decoding? Or are you being specific about the layers of the SOAP protocol across the various transmission channels?
The entire specification is bloated and over complicated, and It lingers solely because of its legacy.
 

Solarion

Honorary Master
Joined
Nov 14, 2012
Messages
18,314
Or you're just an ignorant fool that's just trying to keep your job secure with antiquated tools. There are vastly superior transformation formats that will blow SOAPS encoding/decoding times out of the water.
Put it this way, SOAP is still used and it's probably something good to have in ones toolbox. I'm still learning and working through some SOAP projects and examples. After that I will move onto something newer like JSON/WCF. Whichever is more relevant in today's world. I think the fact that SOAP is so clunky and old has a silver lining to it in that as someone that is learning you get a more hands on approach to what is involved in a web service. Just from my observation.

Putting a SOAP application together so far has been fun but also a real challenge. It's far from finished though and I will get as far as I can go with it.
 

me_

Senior Member
Joined
Oct 11, 2013
Messages
657
SOAP uses HTTP. I am referring to the bloat that is the SOAP definition format. That is why I said "transformation formats".
You mean the headers and envelope around the payload? What "transformation formats" are you referring to? You mean naked JSON/XML?
SOAP can use HTTP, but it's actually transport agnostic - can run over message queues, even file systems.

SOAP definitely still has it's place in enterprise integration and B2B patterns. It was maybe misused in the past as SOAP over HTTP to provide data to web applications, but it still has a lot to offer in asynchronous, reliable and secure patterns.

WSDLs make SOAP incredibly easy to work with from most ESBs and other types of application integration middleware. At their core, they store the message much in the same way with headers and envelope, etc so they just take that natively from the SOAP message with no encoding/decoding.

REST is great for pulling data from multiple sources into a single UI because that's exactly what it was designed to do, but try executing something reliably, with cross server transactions or asynchronously...
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
You mean the headers and envelope around the payload? What "transformation formats" are you referring to? You mean naked JSON/XML?
SOAP can use HTTP, but it's actually transport agnostic - can run over message queues, even file systems.

SOAP definitely still has it's place in enterprise integration and B2B patterns. It was maybe misused in the past as SOAP over HTTP to provide data to web applications, but it still has a lot to offer in asynchronous, reliable and secure patterns.

WSDLs make SOAP incredibly easy to work with from most ESBs and other types of application integration middleware. At their core, they store the message much in the same way with headers and envelope, etc so they just take that natively from the SOAP message with no encoding/decoding.

REST is great for pulling data from multiple sources into a single UI because that's exactly what it was designed to do, but try executing something reliably, with cross server transactions or asynchronously...
Yes thanks for the history lesson I know how SOAP works and I know how its used in enterprise systems having built some myself.

The fact is there are better methods in this day and age instead of using antiquated SOAP.

But you keep on chugging ahead, nobody is stopping you.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
Put it this way, SOAP is still used and it's probably something good to have in ones toolbox. I'm still learning and working through some SOAP projects and examples. After that I will move onto something newer like JSON/WCF. Whichever is more relevant in today's world. I think the fact that SOAP is so clunky and old has a silver lining to it in that as someone that is learning you get a more hands on approach to what is involved in a web service. Just from my observation.

Putting a SOAP application together so far has been fun but also a real challenge. It's far from finished though and I will get as far as I can go with it.
Why are you wasting your time trying to build a SOAP service in C#? When the defacto standard is WCF. You're working against the grain and its pointless.
 

Solarion

Honorary Master
Joined
Nov 14, 2012
Messages
18,314
Yes thanks for the history lesson I know how SOAP works and I know how its used in enterprise systems having built some myself.

The fact is there are better methods in this day and age instead of using antiquated SOAP.

But you keep on chugging ahead, nobody is stopping you.
Why are you wasting your time trying to build a SOAP service in C#? When the defacto standard is WCF. You're working against the grain and its pointless.
Well, you know, I guess I just have a fetish for outdated over-engineered tech. A polymorphed Neo-Luddite if you will.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,930
Why are you wasting your time trying to build a SOAP service in C#? When the defacto standard is WCF. You're working against the grain and its pointless.
a defacto standard it's hardly.... maybe if you're Microsoft...
Anyway for a proper weigh in on what's better would need a reference problem; when talking around the fringes almost anything could fly even dare I say it WCF's default... SOAP.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
a defacto standard it's hardly.... maybe if you're Microsoft...
Anyway for a proper weigh in on what's better would need a reference problem; when talking around the fringes almost anything could fly even dare I say it WCF's default... SOAP.
He’s building a SOAP service. He can use WCF to achieve his goals. I’m not sure if he is hand weaving the SOAP manually. And according to you what is the standard for SOAP webservices in C#?
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,930
He’s building a SOAP service. He can use WCF to achieve his goals. I’m not sure if he is hand weaving the SOAP manually. And according to you what is the standard for SOAP webservices in C#?
I'm well aware of his SOAP endeavours and no he's certainly not hand weaving it :laugh:; it's via WSDL, so fairly easy by SOAP standards. o_O

As for WCF; the last time I checked the default is basicHttpBinding with SOAP 1.1, and whilst you can get WCF to use JSON it's a very inefficient form of JSON, largely because WCF AFAIK internally serialises the JSON streams to a XML Information Set format; which means it is typically slower than native implementations and requires about 1.5 times more bytes.

As you know there's many options aside from SOAP and WCF; and which one to choose really depends on circumstance e.g. legacy, projected peak loads, performance, resource efficiency, etc...
 
Last edited:

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
I'm well aware of his SOAP endeavours and no he's certainly not hand weaving it :laugh:; it's via WSDL, so fairly easy by SOAP standards. o_O

As for WCF; the last time I checked the default is basicHttpBinding with SOAP 1.1, and whilst you can get WCF to use JSON it's a very inefficient form of JSON, largely because WCF AFAIK internally serialises the JSON streams to a XML Information Set format; which means it is typically slower than native implementations and requires about 1.5 times more bytes.
Thanks you still haven't answered my question. According to you what is the standard if its not WCF (for SOAP)? There are far better ways to use JSON or even JSON-RPC.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,930
Thanks you still haven't answered my question. According to you what is the standard if its not WCF (for SOAP)? There are far better ways to use JSON or even JSON-RPC.
Not sure what you are asking? Do you want to me to list alternatives; surely you are aware of most of the alternatives, and no they're not all JSON.

As for WCF it can never be considered a defacto standard when its adoption is typically restricted to Microsoft circles.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
Not sure what you are asking? Do you want to me to list alternatives; surely you are aware of most of the alternatives, and no they're no at all JSON.
My question is very simple, I made the statement that for C# (read web services written in C#) it is a very common standard to build the services in WCF (If you're looking for soap support). You made the claim its not.

As for WCF it can never be considered a defacto standard when its adoption is typically restricted to Microsoft circles.
Wrong. You can call services that use WCF from other languages.

from suds.client import Client

print "Connecting to Service..."
wsdl = "http://serviceurl.com/service.svc?WSDL"
client = Client(wsdl)
result = client.service.Method(variable1, variable2)
print result
Why? Because it has a WSDL definition.

So again, if you're not using WCF to build a SOAP service in C#, what is the standard practice then?
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
5,930
My question is very simple, I made the statement that for C# (read web services written in C#) it is a very common standard to build the services in WCF (If you're looking for soap support). You made the claim its not.
My comments have been general; but even singling out C# still does not definitely make WCF a de facto standard -- granted it may very well be a de facto in certain companies, but I rarely see new projects picking it over other options. As for SOAP; sure if legacy is the measure; then yes, WCF fits that mould in the Microsoft space.

Wrong. You can call services that use WCF from other languages.
That again doesn't make it a de facto standard; I certainly have not seen much Java, Scala, Objective-C, Rust, Swift, etc... code choosing to use WCF over the alternatives.
As you likely know; Java has it's own WCF thing, called Jax-WS, Apache has Axiom, and ... and ...
...and availability in other languages alone is generally meaningless ito of measuring popularity; because even alternatives like Protocol Buffers or Flatbuffers or ... are available for most mainstream languages.
 

semaphore

Honorary Master
Joined
Nov 13, 2007
Messages
10,573
My comments have been general; but even singling out C# still does not definitely make WCF a de facto standard -- granted it may very well be a de facto in certain companies, but I rarely see new projects picking it over other options. As for SOAP; sure if legacy is the measure; then yes, WCF fits that mould in the Microsoft space.
So you finally concede that for C# and building SOAP services in WCF is the standard? If not please provide one then (I am specifically talking C# and SOAP here). Thanks. (Of course if you're only communicating with other .NET based apps you can add binary transports, but that's not what we're talking about here).


That again doesn't make it a de facto standard; I certainly have not seen much Java, Scala, Objective-C, Rust, Swift, etc... code choosing to use WCF over the alternatives.
I never once said it was the defacto standard for other languages, I merely stated you can call WCF from other languages due the exposure of the WSDL definition.
 
Top