Potential IP (Patent, not Protocol) Troubles for SOAP 1.2

sckienle writes "Infoworld has an article on possible patent problems ahead for the SOAP 1.2 recommendation. Apparently two companies are claiming they may have patents that cover parts of the specification. But, they have yet to specify the relevant patent numbers or even how they feel there would be infringement. Here is The Register's spin on this."

Comments

Why HTTP?

[mhesseltine]

I know this question has been asked before, but why do people insist on SOAP running over HTTP? HTTP isn't designed to store state information. It's a Hyper TEXT TRANSFER protocol. I know that it runs over port 80, so sysadmins don't have to open another port; but seriously, if you have an application running through your firewall, wouldn't you want to see that traffic as something other than typical web traffic?

Not trying to flame here; actually looking for a serious answer.

Re:Why HTTP?

[sckienle]

I don't really know the answer to this, but I think it is basically because:

• XML is text, after all
• The original use of SOAP wasn't for "stateful" objects, but really as a light weight RPC protocol
• The designers were more playing around initially, so they used what transport protocol was available
• The designers also were not Network people, but programmers, so the intricacies of creating a new network protocol were more than they wanted to bite off at the time (The old, we'll fix it later, but it never happens syndrome)
• Someone thought that it would be "good" for security to use an existing protocol and port
• You can use any port you want for SOAP traffic, it doesn't have to be 80 (The old "it's a user error" excuse ;-)

Hopefully someone else with more knowledge will pipe in but, from my experience on development projects, that is what I really expect to be what happened.

I also agree with your statement: in reality, you do not want SOAP traffic filtered and controlled in the same way as "standard" HTTP traffic. Maybe version 2.0 will address this. But then, given that the group didn't think that data encryption or user authentication was important enough to be in the original spec, I'm not holding my breath.

Re:Why HTTP?

[King of the World]

HTTP as it turns out is a good general purpose protocol. It has download resuming, and compression (zip), and many other features that weaker protocols like FTP don't have. It's also being extended via WebDAV (webdav is mostly a subset but there are planned extensions). Regardless of whether it's a "text transfer" protocol, everyone uses it for images, pdfs and zips, and it's quite good at it.

SOAP isn't anything to do with HTTP. SOAP can go via SMTP for all it cares. People tend to use HTTP, but then they do that for many things anyway.

Also understand that - like the web - all SOAP applications don't need to store state. A stateful protocol would be overkill, when you can implement state in SOAP. HTTP works, and is very well understood by many people.

Finally, SOAP has a specific HTTP header that firewalls can recognise (and then block if need be). Considering that SOAP can be just a wrapper for a request that returns some xml it's often similar to submitting a query to google. It could be dangerous, but so is allowing all kinds of downloads, so you have to get into HTTP filtering anyway.