Web Services

Erik Sliman writes "Why are all the IT companies suddenly interested in open standards with web services? An OpenStandards.net article explores the issues surrounding the somewhat vague term."

Related recent /. story

[bigmouth_strikes]

Here's a related /. story [slashdot.org] regarding IBM and Microsoft's suggested security standard for web services.

Simply put...

[gUmbi]

Simply put, Web services is SOAP and UDDI. SOAP is like RPC, UDDI is like LDAP. There is nothing really new here.

The reason it is becoming popular is:
A) it uses XML for procedure calls and it has a big-fat standard for type-mapping so it's not tied to a specific language or language-binding.
B) It can piggy-back on HTTP so it works through firewalls.

Web Services may have some issues when network/security administrators figure out people will be using RPC through the firewall.

Jason.

SOAP != HTTP (necessarily)

[oops]

There's a common assumption that SOAP is only transported via HTTP.

From the Apache SOAP faq [apache.org]

The writers of the SOAP 1.1 protocol [http://www.w3.org/TR/SOAP/] note that: 'SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework'.

eg. you can transport SOAP via SMTP.

FYI: SOAP is not transport/port specific

[e2d2]

FYI: SOAP can be used on ports other than just 80 and used by transport protocols other than HTTP/HTTPS such as SMTP, FTP, Jabber, and BEEP:

http://www.pocketsoap.com/specs/smtpbinding/
ht tp://beepcore.org/beepcore/beep-soap.jsp
http://x ml.apache.org/axis/
http://mailman.jabber.org/pip ermail/rpc-jig/2001-O ctober/000016.html

Just a few links but you can search www.google.com and get an idea of what SOAP really entails.

stupidest argument ever

[mikemulvaney]

You don't have to run SOAP services on port 80. If you need to protect them with a firewall, then you should probably run them on some other port.

SOAP isn't any different from CGI. I'm posting this message in a web browser, and it is going to port 80. The horror! If slashdot ran a SOAP service, you could write other clients to do the same thing. Instead of posting to 'postcomment.pl?subject=stupidest+argument+ever&co ntent=...' or whatever, it would encode that stuff in XML and send it to a SOAP proxy.

That's all SOAP is. You can just relax about the use of HTTP. I don't understand why people see something like this, and immediately react with hysterics.

-Mike

Whoaa Site Buzzword Alert !!!

[Anonymous Coward]

looks like Openstandards site is all about buzzwords

Taken from the "about us" page

"dedicated to increasing the synergy of international IT collaboration"

"creating synergy"

"opportunities to foster synergistic cooperation"

"fostering proprietary standards"

"the greater the demand for innovation leveraging it"

maybe he should try plain english, even consumer TV adverts are laughing at this kind of "dotcom" speak

Congratulations

[CoreyG]

Your understanding of XML, "...XML is nothing more than formatted text -- utterly devoid of value until two or more parties agree on a shared vocabulary (in the form of a DTD or Schema" is exactly what XML is defined to be. See? [w3.org] Point #2 is probably the most appropriate here.

Re:What's wrong with HTTP?

[dwsauder]

HTTP works for simple request/response interactions only. Not every interaction fits into that pattern. For example, you may want to control a interactive voice response (IVR) unit. You ask the IVR to play a prompt, then collect digits entered by the user (on his telephone keypad). If the user is entering a card number, you may allow a couple of minutes before the IVR times out, or before the number is completely entered. Once the IVR has the number, it must get that number back to the requestor. The requestor may also want feedback, say, to get the digits as they are entered. Because of the long timeout allowed, and the need to get feedback, this just doesn't work with HTTP.

As an even more extreme case, consider the situation where you want to start a lengthy computation on a computational server. Your HTTP request starts the action and the HTTP response indicates that the computation has started successfully. However, when the computation finishes, perhaps hours later, HTTP may not work to report the completion event. Constant polling isn't a good idea, either. Sure, HTTP communication could happen the other way. But HTTP traversal through a firewall or NAT is usually asymmetric, so the reverse HTTP connection may not be a possibility.