Slashdot Mirror
Programming Web Services with Perl
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.
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
A fellow San Diego Perl Monger has written a book about Perl and the web, including a chapter about web services.
It's a New Riders 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.
jack's bicycle is music to my ears
i'm (like several slashdoters) tired of .net vs java benchmarks. . . is out there a .net vs perl vs php vs java benchmark?
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 ?
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
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!
I hate liberals. If you are a liberal, do not reply.
So is your mom?
heheh, couldn't resist.
Perl is just another way of doing things. Plus,
there are a lot of perlizens that just don't want
to bother learning PHP. Hardware is pretty cheap
compared with development time. You can bang
something out in perl that's reasonably good on
resources in a ridiculously short time.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
It's 10 bucks cheaper at Amazon, compared to BN.
Here -> Programming Web Services with Perl
You can save 10% if you "share the love"
hooray! it's a sex wiki
perl is wonderful. Its so easy to accomplish any goal.. and there is no one way to do it. you can have five people write five different things and achieve the same goal. Perl also works on damn near every platform.
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.
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.
Odd most programmers I know say that about PHP, how many enterprise leve XML projects are built in PHP...I can name a number of them in Perl
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 have to add the mapping to the Apache web server configuration.
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.
IMHO, I find Java WebApps to be much more flexible and better suited to developing web applications than Perl. And of course, if you want to still use Perl CGIs (or non-cgi perl scripts), Tomcat will still let you do that.
This is not to say Perl doesn't have its niche--it does, but Perl is not the be all and end all of web development.
I say use the right tool for each job.
http://www.cgisecurity.com/lib
http://www.cgisecurity.com/xml.shtml
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
It's 10 bucks cheaper at Amazon, compared to BN.
/me rolls eyes
Yeah... it's because that 1-click technology saves them so much money.
My journal has hot
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.
I finished reading this book a few days ago. I'll be brief. If you are remotely curious on how XML-RPC, SOAP or UDDI THIS book covers EVERYTHING. The concepts covered apply to every language, not just perl. I use my "mastering algorithm's" book a lot in other languages, because I find perl to be an easier way for me to understand the concepts, and this book fits the bill perfectly in this respect.
:-)
I've been working with XML-RPC for a while now, it's nice to finally have an all encompassing reference on my shelf...
-Ryan Dietrich
software engineer
intelligent software solutions
hampton, virginia
ps. Great job Randy !
There is a similar debate at the place where I work. What's really funny is the VB programmers defend their technology by claiming the Perl developers are just better programmers, so you can't conclude that it's the platform.
Honest!
He looked at me and said, "Kid, we don't like your kind, and we're gonna send your fingerprints off to Washington."
It \/\/r0x0rs!
In retrospect, it was glue, using glue, talking to glue, using glue, talking to real data. Cute.
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 take a gander at the W3C TAG's latest Architecture of the World Wide Web draft - Section 5.2 basically says that understanding REST is a good practice for web protocol designers.
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.
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.
.Net clients to talk to J2EE back ends and vice versa. The big question is whether all these companies are going to play nice. I think customers will demand it though, so they will have no choice.
And since the standards are open you can hack wrappers for other communication protocols around a web service transport. It should be possible for
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 dialectizer
I'm not entirely sure how rinkworks operates, but fact is an application like the dialectizer would be a good case for using perl.
First a bit about my background so my statement has some context. I love trying new operating systems (running win2k, freebsd and gentoo linux at home now) and programming languages.
I have no loyalty to any language or operating system. Whatever gets the job done most effectively and saves me time is what I choose (of course, keeping in mind the system quality tradeoffs that choice would bring).
With this background, I only recently started taking perl seriously (although I've used perl5 regular expressions in other languages for years). When I looked at perl code years ago without rtfm, I said "what an ugly language, this looks like @#$!". I also stayed away because of the cgi performance issues (before mod_perl or fastcgi started getting used in corporate settings) and because sun & microsoft touted so much to push ASP/DCOM/VBScript or Java/JSP/Servlet in the enterprise that using something else would have been less lucrative (I just didn't think I could make $200K/year in my late twenties without using MS & Sun technologies).
Having said all this, and after taking a 2nd look at perl by actually reading the first few chapters of Programming Perl and using it for a few weeks, I've become a fan. Perl is by no means perfect but man, it is so easy to just "get stuff done" especially when used to process text files/streams like xml or html.
With Perl and XML being such a great combo, it "just makes sense" that Perl and web services would also be very synergistic.
I have extensive experience with both Visual Studio and Java but choose Perl for processing xml files. And since I don't want to get stuck using a vendor-specific way to handle web services, I'm currently looking at Perl for this as well.
One note about Perl though, if you want unicode or threading, use version 5.8 instead of whining about poor support in previous versions.
Also, Perl doesn't force you to code things in a certain way--this means its your responsibility to come up with and enforce coding standards. For us, we use exception handling similar to Java by using Error.pm and we force everyone to "use strict", "use warnings" and follow our naming conventions.
So you can have the best of all worlds, if you just stop whining about how perl code looks as a first impression (rtfm for 1 hour and it will make a lot of sense) or about Perl giving coders given too much freedom (establish & enforce good coding standards). And if you don't like Perl making certain assumptions about what your code means, then add the "use strict" statement near the start of your code.
NOTE: You can see some thought-provoking benchmarks at http://www.chamas.com/bench/ if you've been brainwashed into believing perl is slow for web applications.
A sample chapter, Programming Soap, is available in PDF format here.
jeesh, I mean, that's what hyperlinks were invented for
:
SOAP
XML-RPC
I'm getting "connection refused" so
cached XMLRPC
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I have a copy of the previous edition of this book, written by Doug Tidwell, James Snell and Pavel Kulchenko. In addition to perl it covers Java and C#. Concise, well written, simple examples. A thoroughly good book. So I would tend to disagree - while I haven't been impressed with *all* of the O'Reilly books (XML in a Nutshell indeed is essentially a Javadoc of the API), buyer beware.
...you can have five people write five different things and achieve the same goal.
You make that sound like a good thing. What it actually is is Perlspeak for, "each developer will have to learn the idiosyncratic programming habits of four other developers".
It's simple: I demand prosecution for torture.
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.
Life is like an egg better scrambled than fried. -- Ken Sawatari
Programming Web Services with Perl is a first edition. If you check out the Amazon reviews, you will note that as of the time of this post, it has 5 stars from 5 reviews.
You are referring to:
Your observations of those books may very well be valid. I myself haven't read them. But the amazon reviews for them are 2 1/2 stars and 4 stars respectively.
Life is like an egg better scrambled than fried. -- Ken Sawatari
I actually submitted the review 3/26/03... It just took that long for the review to be reviewed I guess :)
Life is like an egg better scrambled than fried. -- Ken Sawatari
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying