SOAP defines common ways to serialize the data, in such a way that it can be implemented in many languages. Also, SOAP can be proxied using other technologies (SOAP over email for example). I wrote an article for apple.com about using SOAP to bridge between Perl and AppleScript, passing structured data (a hash in Perl became a record in AppleScript... transparently). That was cool, and effortless.

SOAP is just glue. But a good glue, and multi-vendor supported. It's great that Perl has good support as well.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

You don't *have* to be excited by web services, but it seems cool because it's a useful standard that abstracts away a lot of messy details that it would be easier not knowing. You can easily create an application with functions, that people running different platforms and programming in different languages can call over the web. As long as their environment supports SOAP, you can communicate, never mind all the details of encoding the data, standardizing data types, error handling, etc.

If I understand your question, SOAP isn't meant to replace using a webserver and LWP. LWP is basically a programmatic web browser. SOAP is a way of creating a web service, i.e. application that is available through the web.

Personally I haven't written a web service yet, but I've used a couple and it was very easy to do.

I think that similar question asks the majority of IT industry. For some people the answer is obvious, for some not. It's the same with every new technology ....

But the question you ask looks weird to me: "Why is SOAP better than using a webserver and LWP or some other alternative?" Web services (SOAP is just one building block of these) are in its essence something very different from web server. Web server's purpose to live is to serve HTTP objects (mostly HTML pages). On the other hand, web services are communication means between two computer systems. For example, SOAP messages can be transported by SMTP or plain TCP, not just HTTP.

You should look at web services as an alternative to RPC, CORBA or Messaging Oriented Middleware, not as an alternative to Web Server. It is like to consider SMTP e-mail to be alternative to TCP/IP.

These technologies are on different IT architecture layers.

Think of SOAP (and webservices) as a method for doing RPC over exisiting protocols such as HTTP using platform independent data (i.e. embed everything as XML)

This changes the question to be "why would I want RPC?" -- Which is all down to the problems you're trying to solve. To pick a problem at 'random'; Let's say you want to find events near a UK postcode -- you may not want to try and collect this data locally, and might want to pull data off an existing website like local.angle - they offer a webservice that allows you to get a list of events based on your postcode with their permission -- you could just pull the data off their website, but you do have some morals, right?

For the data providers (in the case of web services that merely retrieve data) it's a lot more efficient to give the raw data, instead of the data dispersed through the virtually manditory 30kb of navigational fluff that is merely presentational.

Now, expand this to the cases where you want them to do something with your request (like order some books) and it becomes even more of a saving, as you're not having to "fake" form filling, etc.

Other examples I've seen (and used) are the ability to query the Amazon catalogue, find out about DSL and cable modem availability in the UK and getting exchange rate data.

At then end of the day, it's up to you to decide whether web services will solve your problems, and whether you'd like to reuse the services out there.

--
RatArsed

"the Perl Webservices book?"

Pretty much. "Programming Web Services with Perl" is, to my knowledge, the only dedicated web services and Perl book. There are others where Perl is covered with other languages, and there's also a couple of .NET ones, but PWSwP (details here) is THE book =)

This is, of course, assuming the fellow's talking about that book.

Just checking that we weren't referring to O'Reilly's "Web Services Essentials" or "Programming Web Services with SOAP"; Both which cover Web services in Perl to a greater or lesser extent...

--
RatArsed

From the article which is very good advice indeed:

If both sides of the wire use the same binary 
mechanism, an XML interface doesn’t buy you much other 
than a jazzier set of acronyms. If you have two systems 
built with the same platform, you’re better off using the 
remote call mechanism built into that platform. Web 
services become handy when you want different platforms to 
talk to each other. My attitude is to use XML Web services 
only when a more direct approach isn’t possible. 

BTW, are you reading the Randy Ray book? How is it?

See also (OT) Webservices – really progress?

Makeshifts last the longest.

lucylane:
"BTW, are you reading the Randy Ray book? How is it?"

Yes, I got Programming Web Services with Perl By Randy J. Ray, Pavel Kulchenko. I usually really enjoy ORA books, but I think this book has alot of fluff and they didn't really get me excited about the possibilities.