Programming Web Services with Perl

ggoebel writes "Programming Web Services with Perl is principally a book on implementing solutions using XML-RPC and SOAP in Perl. It also covers complementary and alternative standards such as WSDL, UDDI, and REST in some detail. And on the periphery, it finishes with a whirlwind tour of developing message routing, alternative data encoding within XML, security, transactions, workflow, internationalization, service discovery, extension, and management techniques and specifications." Read on for ggoebel's full review. Programming Web Services with Perl author Randy J. Ray, Pavel Kulchenko pages 496 publisher O'Reilly (December 2002) rating 9 of 10 reviewer ggoebel ISBN 0596002068 summary practical balanced guide to XML::RPC and SOAP::Lite

The book assumes the reader will have the knowledge of an intermediate level Perl programmer. I.e., the reader is assumed to have a working knowledge of references, data structures, and object-oriented Perl. On the other hand no previous knowledge of XML, XML-RPC, SOAP or XML related technologies is required.

It should also be mentioned that both of the authors Randy J. Ray and Pavel Kulchenko are also the principle developers of the most popular XML-RPC and SOAP Perl modules: XML::RPC and SOAP::Lite respectively. That said, the book is not a soap box for the authors to tout the merits of their tools.

Rather, it is a practical book which starts with grounding fundamentals. Readers should walk away with a core understanding of XML-RPC and SOAP and not just a particular tool set for working with them. The authors examine the alternative XML-RPC and SOAP tools, illustrate how they are used, and give practical and even handed reasons why their modules should be preferred. Which comes down to issues of features, active development, support, and the amount of work required to code to a particular interface. They then settle down to a comfortable and thorough guide to XML::RPC and SOAP::Lite.

The topics and issues are illustrated throughout using real world web services. For example creating an XML-RPC client for O'Reilly's Meerkat news wire, or a SOAP client to covert use.perl.org's journal stream to RSS. Code is presented to the reader filtered down to highlight each particular issue as it is discussed. This is nice in that it avoids listing slight variations of the same code multiple times, but on the down side it can also leave the reader flipping back and forth to reassemble an example in their head. Full code for each example is provided in the appendices. And all of the example code may be downloaded from O'Reilly.

All-in-all, the book is a thorough practical introduction to working with XML-RPC, SOAP and related technologies. When I started reading the book, I was a bit disappointed to see that it only covered XML-RPC and SOAP related services. When I finished, I was impressed with how very much information they'd managed to pack into so few pages.

And yet, I was left wishing there'd been a more through coverage of interoperability issues between other SOAP implementations and things like custom de-serializers. To be honest interoperability and de-serialization are mentioned, and the authors do an excellent job of referring the reader on to sources for continued reading on most other topics.

The book does an admirable job balancing content, length, and information density. Not to mention an excellent job delivering the information that will still be relevant years and not just weeks from the date published. Most of the topics I'd wished to see covered in more depth are those that are still developing and consequently most likely to become quickly dated. In short a well balanced practical guide to applying XML-RPC and SOAP to solve problems.

You can purchase Programming Web Services with Perl from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

OK,

[frodo from middle ea]

this may be a bit offtopic but seriously "IS there anyone who is developing web-services for critical applications ?
There could be a lot of pilot projects but do they really count ?
Isn't the very word "web-service" a marketing gimmic like B2B, B2C, Enterprize, Portal etc ?
One thing web-service promised was a homogenous set of APIs, but do you really see that happening ?
I mean every month i see some company dropping from the web-services consortium and some other joining. How then are they going to agree on standards ?

And if they do agree on standards won't that make their business model vulnerable ?

/me thinks this whole concept of web-service is going down the same path of J2EE and RDBMS, a lot of promise of standards, ease of migration from one vendor to another, BUT we will end up with lock-n proprietory solutions and getting far less than we were promised..

Re:OK,

[plcurechax]

Isn't the very word "web-service" a marketing gimmic

Sure, it is used by marketing, but it is also a actual trend or methodology, like client/server, or thin computing. And like those methods, they work some of the time, and don't work so well in other cases.

I work in an environment providing near-time data nationally, and internationally to partners, stakeholders, and customers. Trying to make all of the global systems work the same way, and whenever one of those thousands of systems maintained by hundreds of groups (and organizations) changes, not everyone wants to have to change their systems at the exact same time. Web services help in that sort of environment. It doesn't mean web services is always a good thing (i.e. high speed or real-time data flow), but in some applications it is useful.

Web services also will hopefully let companies move beyond data dumps and screen scraping for data gathering / exchange. I hate currently having to use FTP to exchange data with partners, but our current environment that is the best way for outlying nodes push data back to the upstream centres for archiving and redistribution globally.

What web services means to me, is hopefully a better way to manage large networks of data exchange / management between a large number of stakeholders. IT/IS still sucks at day to day and long term management of information and data, perhaps this will be an evolutionary improvement.

Review Critique

[Acidic_Diarrhea]

You know, the reviewer mentions that the book assumes no knowledge of XML-RPC or SOAP but still uses the acronyms. I think that if you're going to write a review of a book to help people out who don't know what either of those terms mean, you should define the terms. For those of us who already have a working understanding of those terms - we've got our books. Sure, a quick google search would, no doubt, reveal the information but some hand-holding is a bit helpful.

For instance, when I am teaching a student who is new to a particular field and I am assuming that they don't have any previous knowledge of the material - my first lesson doesn't throw around acronyms without any explanation of them. It's just good practice to define your terms, if you're assuming the reader has no knowledge of them beforehand.

And there you have my input! Have a Great Day!

Re:Programming Web Services with Perl...

[bballad]

It actualy works out great. Example the place I work we have something like 20 VB programers for our web service and its buggy and slow. A perl shop I'm familer with has 5, their code is more complex and runs faster with fewer bugs.

Gratuitous O'Reilly books

[Anonymous Coward]

I'm losing respect for this publisher. Their web services books have been the type of flimsy, generated-from-the-standards-docs crap I would expect to see from Sam's and Queue. O'Reilly can't survive on the sales of their essential books, so they have proliferated this crap to keep their sales going. Addison Wesley in my opinion is the only serious quality technical publisher left.

Re:Web Services and Perl vs. Web Apps

[avdp]

That's right, you'd have to add the mapping to the apache web server configuration. I don't see what the big deal with doing that. Is it easier to edit web.xml than httpd.conf? As someone who deals with both, I don't think so.

But regardless, I'd like to point out that you are essentially comparing configurations between Apache (a web server) with Tomcat (an application server, which can, but shouldn't be used as a web server). I am not sure how these reflect negatively on perl.

Re:how it performs?

[byrnereese]

I would hate to see SOAP::Lite benchmarks personally. It performs really well for small payloads, but quickly begins to fall over when payloads exceed a "reasonably" large size... but then again, developers and architects should have all the facts when thinking about how they will architect their Web services.

My personal take is that SOAP::Lite is probably one of the best toolkits for quick WS prototyping and simple projects, but I would tend to steer towards Axis, WebLogic, WASP, and yes, even .NET (eeeh-gads!) (please let Mono support wsdl.exe soon!) when it comes to putting software into a production environment.