Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Perl Books Media Programming The Internet Book Reviews IT Technology

Programming Web Services with Perl 83

Posted by timothy from the said-the-spider-to-the-fly dept.
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.
This discussion has been archived. No new comments can be posted.

Programming Web Services with Perl More

Programming Web Services with Perl

Comments Filter:

  • Perl is not a bad idea... (Score:4, Informative)

    by Zeinfeld ( 263942 ) on Friday April 04, 2003 @11:24AM (#5661467) Homepage
    The thing about Web Services is that they are pretty much designed like Perl to be the duct tape of the Internet. Perl itself is evolving in pretty much the way Basic did, more structure, more consistency but still pretty easy to suck it and see.

    The thing I don't quite get is the reference to the REST standard. That is some hype Roy Fielding put in his thesis. It was never agreed upon by the other members of the Web team and there is no real trace of its influence on the development of web standards for the simple reason that the thesis only came out long after the fact.

    • Perl? Consistant? Come ON! Even the Zealots just kinda run in the corner and try to hide when THAT one comes up.
    • IMHO - I think it is fair to say that bringing up REST is important, especially considering that technically it is a Web services protocol. I thinl to understand Web services and their role in application design and architecture, you should at least have a background of all Web services protocols...

      But I digress. One thing I liked about this book was the background is gave on XML-RPC and SOAP and how it started to differentiate the two. I would have liked to have seen a little more critical analysis of the
    • It seems your knowledge of REST is quite lacking.

      REST is not a standard - it is an architectural style - much like client-server or RPC.

      As for REST being some bit of hype, perhaps you should spend a little time reading Fielding's thesis (Oh, I forgot -this is slashdot). In fact, REST quite accurately and usefully describes the architeucture of the web. Further, REST had a large impact on the HTTP spec (or is it just coincidence that Fielding was one of the authors of RFC 2396)

      You might also want to tak
      • As for REST being some bit of hype, perhaps you should spend a little time reading Fielding's thesis

        That is my point, REST ain't a standard, it IS hype.

        Further, REST had a large impact on the HTTP spec (or is it just coincidence that Fielding was one of the authors of RFC 2396)

        He was an editor, that means he did the edits, it does not mean he did the design. I was an author and no, REST had no influence on the design, he didn't write his thesis until the spec was long finished. I never heard the ter

  • Blatant plug for a friend's book (Score:5, Informative)

    by dagnabit ( 89294 ) on Friday April 04, 2003 @11:28AM (#5661492)
    A fellow San Diego [pm.org] Perl Monger [pm.org] has written a book [globalspin.com] about Perl and the web, including a chapter [globalspin.com] about web services.

    It's a New Riders [newriders.com] book, but the entire contents are available free on the web.
  • This sort of book is really cool to see. Perhaps I just wasn't looking closely enough, but Perl seemed to be lagging far behind J2EE/.NET in terms of web services (and XML in general) and I now I have a little more ammo to sell Perl to my boss with! /plans trip to bookstore at lunch.

  • OK, (Score:4, Insightful)

    by frodo from middle ea ( 602941 ) on Friday April 04, 2003 @11:33AM (#5661534) Homepage
    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..

    • I know of at least tow. One is a interface from a credit reporting agency to banks the other is a portal for Liberians tow a major book distributor. I both instances they found Perl to be a faster and more robust system then .net or j2ee

    • Re:OK, (Score:2, Informative)

      by microTodd ( 240390 )
      Actually, yes, at my job (a certain site for a certain government organization) we use it quite heavily, although not necessarily in the whole "B2B" way. We use SOAP as an alternative to old-sk00l RPC calls. Works great, especially for the cross-platform-ism. I like being able to use Java, Perl, and .NET to communicate across the network and pass data around.
    • We use XML-RPC and love it. Servers in Java and C++, clients in Java, C++, perl, VB?, dunno who all our clients are :-)
      It's not B2B, but when your company is >100K people, it might as well be (which is to say, there is often no cooperation or foreknowledge that some group will want access, which is part one the reasons XML-RPC is great).

    • Re:OK, (Score:3, Insightful)

      by plcurechax ( 247883 )
      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 hundre

    • leverages HTTP (Score:3, Informative)

      by GunFodder ( 208805 )
      Why wouldn't anyone use web services? You get human-readable data objects. You can leverage HTTP as a transport, which makes it really easy to deploy robust servers built on proven technology. HTTP also gives you a variety of flexible security solutions, especially when it comes to firewalls.

      And since the standards are open you can hack wrappers for other communication protocols around a web service transport. It should be possible for .Net clients to talk to J2EE back ends and vice versa. The big que
    • Short Answer:

      Yes.

    • content aggregation with rss/rdf is very useful. then there are things like the google api.

      but, for general corporate computing, there are usually going to be better solutions.

  • 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

    • jeesh, I mean, that's what hyperlinks were invented for

      SOAP [w3.org]

      XML-RPC [xmlrpc.com]

      I'm getting "connection refused" so :

      cached XMLRPC [216.239.39.100]

    • okay (Score:2)

      by ggoebel ( 1760 )

      Honestly, if someone is reading this review and they don't know what XML-RPC and SOAP are... they probably don't need to be reading the book ;)

      I did say the book assumes no knowledge of XML-RPC and SOAP. But, obviously the review does... Though you are correct, I should have expanded the acronyms. I share your dislike for when you're never told what an acronym stands for... However be content that the book does explain what they are.

      • XML-RPC: eXtensible Markup Language - Remote Procedure Call
      • SOAP: Simp
  • It's 10 bucks cheaper at Amazon, compared to BN.

    Here -> Programming Web Services with Perl [amazon.com]

    You can save 10% if you "share the love" [passthelove.com]

  • Gratuitous O'Reilly books (Score:1, Insightful)

    by 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.
  • First of all, I love Perl. For years I've developed web applications with it. However, other technologies out there are better suited to developing web apps than Perl.

    For example, let us say I wanted to map a directory to a particular CGI script. If I were building CGI apps with Perl, I couldn't do that. I'd have to have a controlling script in the cgi-bin that would relegate particular requests to other CGI scripts (or "require" them). But if I still wanted to map a directory to a script, I would hav
    • 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.

      • That was just an example. Here's another one: Let us say you wanted the web application to go to a specific page or do something special on getting a 404 error, page not found (or any other server error for that matter). Your Java web application can be programmed to handle that rather than having to monkey with the server to handle it. Doing things like this with Perl and Apache rather than with a Java WebApp start to get much harder.

        The point is that the J2EE WebApp paradigm has advantages over applicat
        • Nope. Not any harder. Also a web server configuration - you can do something "special" with errors on any web server I've ever encountered both in Unix and Microsoft world.

          But I am becoming to see the pattern... You basically prefer the configuration mechanism of Tomcat better than Apache. That's fine, it's a perfectly legitimate concern if that's what matters most to you. But again, it has nothing to do with Java or Perl. What you're talking about are not J2EE things either - they are specific to

          • Nope. Not any harder. Also a web server configuration - you can do something "special" with errors on any web server I've ever encountered both in Unix and Microsoft world.

            Sure it is harder.

            You have to make two platforms work together rather than work on one platform that does it all. From an archival standpoint, its easier to CVS your one WebApp rather than your httpd.conf + your CGI scripts. Of course, you could always #Include the code for the httpd.conf and bundle it with your CGI scripts,

            • It's done plenty. In fact, it's done by default for various things on RedHat - it's just a matter of dropping a file in /etc/httpd/conf.d/ - that's how RedHat manages to RPM-ize stuff like mod_perl, php and SSL support. The same mechanism can (and is used where I work) to configure directories with whatever settings that directory needs (think of each directory as being one app). If you don't want to give developers access to /etc/httpd/conf.d (understandable) it'd be trivial to change httpd.conf to look
    • Perhaps Java is "better" at web services than Perl. But if your developers aren't skilled in Java then is it still a better tool? It's all relative.

      As someone who has programmed in both Java and Perl, I see your point. Problem however is that the "right tool for job" approach, as logical as it sounds isn't always workable. This industry is evolving so fast that it is simply impossible for anyone with a day-job to keep up with everything. So rather than everyone knowing all the best tools, what we tend to s
    • For example, let us say I wanted to map a directory to a particular CGI script. If I were building CGI apps with Perl, I couldn't do that

      What does that have to do with Perl? If you were building CGI apps with Java, you wouldn't be able to do that either. CGI != perl.

      On the other hand, this can be easily accomplished by a developer building a Web App for a Java servlet container (like Tomcat) by specifying the mapping in the WEB-INF/web.xml of the web application he's building.

      Playing along with this t
  • I am not really a Perl programmer, but I have used Perl several times in the last couple of years because SOAP:Lite was so easy to use to write 'foreign' clients to Java and Smalltalk web services that I was working on.

    I have not seen the book, but the fact that one author wrote SOAP:Lite is a good sign.

    Anyway, his work saved me a lot of effort in testing my stuff.

    -Mark

  • I did an article for Apple Developer [oreillynet.com] about using SOAP as the glue between AppleScript and Perl (and from there to an RSS feed).

    In retrospect, it was glue, using glue, talking to glue, using glue, talking to real data. Cute.

  • Where was this review last weekend! I bought it sunday.

    Seriously though, I havne't read much of it, but your review does increase my confidence that I haven't wasted my money.
  • Would be translation sites. Sure they normally end up with funny renditions of the original text, but at the very least they allow me to browse sites I otherwise wouldn't have a clue about. Nicely done with perl's robust string handlers.

    Another very fun application is rinkwork's [rinkworks.com] dialectizer [rinkworks.com]
    • I'm not entirely sure how rinkworks operates, but fact is an application like the dialectizer would be a good case for using perl.

  • A sample chapter, Programming Soap, is available in PDF format here [oreilly.com].

Slashdot Top Deals

You can not win the game, and you are not allowed to stop playing. -- The Third Law Of Thermodynamics

Close