Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Programming Web Services with Perl

timothy posted more than 11 years ago | from the said-the-spider-to-the-fly dept.

Perl 83

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.

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.

cancel ×

83 comments

Sorry! There are no comments related to the filter you selected.

you linux hippies need to get some SOAP (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5661400)

You stink.

If this is not the first post... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5661401)

...I will smear honey on my genitals and roll around on a nest of fire ants.

As always, links to pictures will be posted.

Re:If this is not the first post... (-1, Offtopic)

Anonymous Slacker (607727) | more than 11 years ago | (#5661412)

sorry charlie, looks like someone beat ya to it.

Re:If this is not the first post... (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5661416)

you FAIL...AGAIN! where's the pictures...still waiting for the last damn set also

Re:If this is not the first post... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5661420)


thanks ! I'd love to see them !

HAHAHAH!!!! (-1)

cyborg_monkey (150790) | more than 11 years ago | (#5661424)

Frosty Piss is all mine!

You all are sux0rs swimming in my wake!!!

Frost Piss!!! Mine, all MINE you biatches.

Or something like that.

I noticed that I drink my own urine! (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5661429)

What's up, cockazoids? 10th post or so! I fucking rule at Excitebike!

Must see (-1)

Anonymous Coward | more than 11 years ago | (#5661432)

Offtopic but still cool Must See [rulez.org] .

Re:Must see (-1)

Anonymous Coward | more than 11 years ago | (#5661553)

Funny, but Tenacious D blows.

PERL and XML??? (-1, Flamebait)

thierno (635164) | more than 11 years ago | (#5661459)

PERL is ugly and bloated. Anyone interested in programming web services should seriously consider PHP and XML those two languages complement each other very well

Ummmmm, (0, Flamebait)

Sevn (12012) | more than 11 years ago | (#5661544)


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.

Re:PERL and XML??? (1)

Muerto (656791) | more than 11 years ago | (#5661603)

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.

Re:PERL and XML??? (1)

sfjoe (470510) | more than 11 years ago | (#5675499)

...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".

Re:PERL and XML??? (1, Informative)

bballad (663078) | more than 11 years ago | (#5661678)

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

Re:PERL and XML??? (-1)

Anonymous Coward | more than 11 years ago | (#5661718)

Oooooh! A troll got in first. By the way... it is:

Perl = when talking about the language
perl = when talking about the interpreter
PERL = is not correct

Perl is not a bad idea... (3, Informative)

Zeinfeld (263942) | more than 11 years ago | (#5661467)

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.

Re:Perl is not a bad idea... (0, Flamebait)

Tyler Eaves (344284) | more than 11 years ago | (#5662124)

Perl? Consistant? Come ON! Even the Zealots just kinda run in the corner and try to hide when THAT one comes up.

Re:Perl is not a bad idea... (1)

byrnereese (249300) | more than 11 years ago | (#5662518)

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 them all though - REST v. SOAP v. XML-RPC etc... but perhaps that should be left to the reader?

Misinformed about REST (1)

chucking (143875) | more than 11 years ago | (#5662666)

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.

Re:Misinformed about REST (1)

Zeinfeld (263942) | more than 11 years ago | (#5664762)

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 term mentioned until after the spec went to proposed so I have a hard time believing it to have been important.

I know that Roy has been busy trying to promote REST as being the great insight, that does not make it so.

Programming Web Services with Perl... (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5661481)

...Sounds a bit like Writing 3D Games in Forth.

Re:Programming Web Services with Perl... (2, Insightful)

bballad (663078) | more than 11 years ago | (#5661655)

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.

Re:Programming Web Services with Perl... (2, Funny)

happyclam (564118) | more than 11 years ago | (#5662061)

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.

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!

Blatant plug for a friend's book (4, Informative)

dagnabit (89294) | more than 11 years ago | (#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.

Re:Blatant plug for a friend's book (1)

Koschei (9613) | more than 11 years ago | (#5690023)

That chapter is less informative than the text on the back of "Programming Web Services with Perl".

It'sa (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5661509)

Hard knock mom ....

Yo G i'm makin Pee I just got kicked in the knee did I hear you say you gotta take a wee?

Cool! (1)

xmutex (191032) | more than 11 years ago | (#5661517)

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.

New book by Cmdr Tuna Taco (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5661525)


"Programming Perl Necklaces with your Cock."

$55, Amazon.

how it performs? (0)

oordaz (236205) | more than 11 years ago | (#5661526)

i'm (like several slashdoters) tired of .net vs java benchmarks. . . is out there a .net vs perl vs php vs java benchmark?

Re:how it performs? (2, Insightful)

byrnereese (249300) | more than 11 years ago | (#5662558)

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.

OK, (4, Insightful)

frodo from middle ea (602941) | more than 11 years ago | (#5661534)

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, (1)

bballad (663078) | more than 11 years ago | (#5661628)

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, (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5662129)

Wow - that was amazing. You managed to misspell two completely different words the same way: to->tow and two -> tow. Awesome. Your idiocy made my day.

Re:OK, (0)

_14k4 (5085) | more than 11 years ago | (#5661801)

I use SOAP::Lite all the time for production products, and processes.

And they're all also quering a RDBMS.. Where's the problem you speak of? You're just lagging behind a bit, it's ok.

Re:OK, (2, Informative)

microTodd (240390) | more than 11 years ago | (#5661881)

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.

Re:OK, (1)

kwerle (39371) | more than 11 years ago | (#5661924)

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, (2, Insightful)

plcurechax (247883) | more than 11 years ago | (#5662033)

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.

leverages HTTP (2, Informative)

GunFodder (208805) | more than 11 years ago | (#5662926)

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 question is whether all these companies are going to play nice. I think customers will demand it though, so they will have no choice.

Re:OK, (1)

LadyLucky (546115) | more than 11 years ago | (#5665758)

Short Answer:

Yes.

Re:OK, (0)

Anonymous Coward | more than 11 years ago | (#5666275)

I consult for a large telecommunications corp in the US. We actively use many methods of system to system interfacing. Web-based interfaces allow business logic to be seperated from the UI and support parity for external local service providers which is mandated for many of the new systems being built.
Network load balancers are very mature for web-based protocols too, unlike CORBA or other interfacing methods, unless you want proprietary solutions.

Re:OK, (1)

eversunsoft (651496) | more than 11 years ago | (#5667608)

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.

Review Critique (2, Insightful)

Acidic_Diarrhea (641390) | more than 11 years ago | (#5661537)

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!

good call - here's the links (1)

DrSkwid (118965) | more than 11 years ago | (#5668001)

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 (1)

ggoebel (1760) | more than 11 years ago | (#5678409)

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: Simple Object Access Protocol

LARRY WALL CAN GO EAT A FAG OF HELL (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5661558)



somethingsomething YELLING

Re:LARRY WALL CAN GO EAT A FAG OF HELL (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5662165)

A fag of hell??? HAHAHAHAHA!! You kill me man!

I gotta use that!

fag of hell!

BWAHAHAHAHHHHAHAHAHHAHAHAHA..

$27.97 (free shipping) at Amazon (2, Informative)

gnurb (632580) | more than 11 years ago | (#5661562)

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]

GOTO HELL, JEFF!!! (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5661611)

Re:$27.97 (free shipping) at Amazon (1)

rwsorden (244333) | more than 11 years ago | (#5661668)

It's only $24.50 at Bookpool [bookpool.com] , but there's is a shipping cost unless you spend over $40 total.

Re:$27.97 (free shipping) at Amazon (-1)

Mighty_Joe_Stalin (640589) | more than 11 years ago | (#5661796)

You fucking kikey kike! You hid an associate tag into that link! Fuck you! I found you out Ezikiel!!! You son of a bitch - jew jew jew. Fuck you jew!!

I am calling you out - get a real fucking job and stop trying to jew through life. Fuck you with a ten inch dildo, you douchebag! I hate you so much. Jesus Christ, what a dick-eater you are. That's right, I said JESUS CHRIST. Remember the guy your people killed? Yeah, asshole - fuck you people. Who besides the stupid fucking jews would kill God's son? I mean, it's God's fucking son!!! Not even the dumb negroes would kill God's son - even those monkeys know better. Fuck you you fucking moron. Get a job.

Re:Yeah... (1)

Surak (18578) | more than 11 years ago | (#5661912)

It's 10 bucks cheaper at Amazon, compared to BN.

Yeah... it's because that 1-click technology saves them so much money. /me rolls eyes

Re:$27.97 (free shipping) at Amazon (1)

Acidic_Diarrhea (641390) | more than 11 years ago | (#5662535)

Mods: this guy has hid an associate referral within the link. Please mod the parent down and mod up this link [amazon.com] . If you check out gnurb's posting history, you will see that he is using Slashdot as his own personal free advertising space. I find this highly irregular and would like to see action taken against his account. I will be contacting the chief manager of the associates program at amazon later today in order to have his account disabled.

Re:$27.97 (free shipping) at Amazon (1)

byrnereese (249300) | more than 11 years ago | (#5662661)

+1

In total agreement. This behavior is so weak... and quite transparent.

Re:$27.97 (free shipping) at Amazon (1)

gnurb (632580) | more than 11 years ago | (#5662681)

I wasn't trying to hide my affiliate link...

If it's inappropriate, then someone (from amazon or slashdot) just needs to tell me so.

Gratuitous O'Reilly books (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5661666)

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.

What about Wrox? (0)

Anonymous Coward | more than 11 years ago | (#5662478)

It \/\/r0x0rs!

O'Reilly Rules! (1)

kupci (642531) | more than 11 years ago | (#5670857)

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.

Re:O'Reilly Rules! (1)

davorg (249071) | more than 11 years ago | (#5677612)

I have a copy of the previous edition of this book, written by Doug Tidwell, James Snell and Pavel Kulchenko.

No you don't. This is the first edition of Programming Web Services with Perl [oreilly.com] . Looks like you have a copy of Programming Web Services with SOAP [oreilly.com] . Two completely separate books with a small amount of overlap.

You are mistaken (1)

ggoebel (1760) | more than 11 years ago | (#5678537)

Programming Web Services with Perl [amazon.com] 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.

Web Services and Perl vs. Web Apps (1)

PerlPunk (548551) | more than 11 years ago | (#5661822)

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.

Re:Web Services and Perl vs. Web Apps (2, Insightful)

avdp (22065) | more than 11 years ago | (#5662017)

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:Web Services and Perl vs. Web Apps (1)

PerlPunk (548551) | more than 11 years ago | (#5663244)

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 applications that are, so to speak, stitched together.

Re:Web Services and Perl vs. Web Apps (1)

avdp (22065) | more than 11 years ago | (#5663610)

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 an implementation of a J2EE application server (tomcat).

You seem to have a beef with Perl because you don't like Apache. Perl is a just a language, not a platform. You can write .Net web apps in perl if you like and then you have all the goodies that you like so much about Tomcat but in perl (using IIS).

Re:Web Services and Perl vs. Web Apps (1)

PerlPunk (548551) | more than 11 years ago | (#5664427)

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, but that's not done much.

From a coding point of view, because you write your code in one place, there is more incentive to use features that you would otherwise have to modify your server config for. Most CGI programmers (and it doesn't have to be with Perl) don't often code both the httpd.conf and their collection of scripts at the same time. And those who need to code both Perl and Apache are probably working in mod_perl.

You seem to have a beef with Perl because you don't like Apache.

Wrong. I love apache. In fact, I interface Apache and Tomcat most of the time. It just that a framework that combines many traditional server features and scripting features makes much more sense to program in.

Perl is a just a language, not a platform. You can write .Net web apps in perl if you like and then you have all the goodies that you like so much about Tomcat but in perl (using IIS).

I'll wait for Perl6 to come out, which will be opensource answer to Java. I'm not a Microsoft fan, and I'm not about to pay $$$ for IIS when Apache and Tomcat are better and free.

Re:Web Services and Perl vs. Web Apps (1)

avdp (22065) | more than 11 years ago | (#5665456)

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 in a set directory in their home directories.

I understand your argument, but unfortunately I find the "complications" of not working in a tomcat-like "framework" rather insignificant. Don't get me wrong, Tomcat IS nice - and I use it too, I am just not buying your arguments AGAINST a straight perl/apache solution.

Now if you had talked about scalability of CGIs, then I probably would not have argued with you.

Re:Web Services and Perl vs. Web Apps (0)

Anonymous Coward | more than 11 years ago | (#5668168)

One of the best solutions:

apache/mod_perl + HTML::Mason

OO(ish) and scalable, makes large site management easy.

But hey, if the world can't manage without JSP and J2EE crap shoved down their throats - that's their problem :)

Re:Web Services and Perl vs. Web Apps (1)

forgetmenot (467513) | more than 11 years ago | (#5662203)

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 see are programmers specializing in a small "set" of tools that may not be the best at some niche job but are nevertheless adequate enough to get the job done 90% of the time. I feel this is also a more efficient use of one's knowledge. Most company's aren't looking for that one person who can do everything - they want the person who does one or two things exceptionally well.

So a book like this I don't think is aimed at the people who already develop web services in Java or .NET, but rather at those who are experts in Perl. It allows them to leverage those valuable perl skills in a new area.

Re:Web Services and Perl vs. Web Apps (1)

PerlPunk (548551) | more than 11 years ago | (#5663293)

I agree with your assessment that the book helps Perl programmers build better applications for the web.

Also, on another note, in this economy people who know Perl but not Java are probably not doing too well.

Re:Web Services and Perl vs. Web Apps (2, Interesting)

Black Perl (12686) | more than 11 years ago | (#5663596)

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 terrible web-server configuration example... You can easily do the same thing with mod_perl or PHP (which uses mod_PHP). A "servlet container", mod_perl, and mod_PHP are all types of web app server. Compare apples and apples.

Re:Web Services and Perl vs. Web Apps (0)

Anonymous Coward | more than 11 years ago | (#5663961)

Holy christ do we have to say it again??
CGI Perl, thank you.

Re:Web Services and Perl vs. Web Apps (0)

Anonymous Coward | more than 11 years ago | (#5665807)

Um, as someone who used Java extensively and is a Sun certified Java Architect, I think you're statement about Java being better suited than Perl for web apps is misleading.

You're talking about directory mapping in Apache vs Tomcat for goodness sakes. If you wanted to make a case, say something about performance, scalability, memory footprint, available apis & free components, programmer productivity, lines of code required for most common tasks needed in web apps, etc.

BTW, for all of you brainwashed into believing that Java is faster than Perl for web applications (like I was), take a look at some benchmarks or better yet, perform your own benchmarks based on how YOUR web applications will run:

Several Perl and Java Benchmarks [chamas.com]


Equating Perl web apps to just cgi is like equating Java only to browser-based java applets. Both Perl and Java have much more to offer than cgi or applets. Perl has mod_perl and fastcgi for performance as well as persistance. Java has jsp, servlets and ejb.

Frankly I always like servlets better than jsp and usually like servlets bettern than ebj. Servlets are great for the bulk of web apps.

But once you try Perl using mod_perl or fastcgi, I think you'll realize that there Perl can be a much more productive environment where apps will use much less memory than Java and run more quickly as well in most cases.

I still like Java (and C) and I've coded Java for at least 3-4 years longer than Perl. But I find that for similar tasks, I can get things done with Perl in 1/2 the time than it would take me in Java. Even more quickly if the coding involves processing text files like xml or html.

Again, try learning/using competing technologies until you're considered very good or an expert in both, run your own benchmarks, then tell the world what you think is better.

Loyalty to languages, operating systems or other technologies for its own sake is very silly. Get good at several things (choose wisely) and use whatever is most appropriate for each situation.

SOAP:Lite is awesome (1)

MarkWatson (189759) | more than 11 years ago | (#5661903)

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

article text (0, Redundant)

rankey (663849) | more than 11 years ago | (#5661961)

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.

Web Services with Perl (0)

Anonymous Coward | more than 11 years ago | (#5661973)

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 ! :-)

Perl, SOAP, and AppleScript (1)

merlyn (9918) | more than 11 years ago | (#5662492)

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.

bastard! (1)

BoneFlower (107640) | more than 11 years ago | (#5662871)

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.

bastard ;) (1)

ggoebel (1760) | more than 11 years ago | (#5678870)

I actually submitted the review 3/26/03... It just took that long for the review to be reviewed I guess :)

Some my favorite web services.. (1)

splerdu (187709) | more than 11 years ago | (#5663325)

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]

disclaimer (1)

splerdu (187709) | more than 11 years ago | (#5663434)

I'm not entirely sure how rinkworks operates, but fact is an application like the dialectizer would be a good case for using perl.

This makes sense (0)

Anonymous Coward | more than 11 years ago | (#5665579)

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.

Sample Chapter (1)

darkpurpleblob (180550) | more than 11 years ago | (#5666708)

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

*BSD is dying (0)

Anonymous Coward | more than 11 years ago | (#5681718)

It is official; Netcraft now confirms: *BSD is dying

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 [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin [amazingkreskin.com] 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

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>