I'm a seasoned web programmer, but I've never touched XSLT.
You should do - it's useful stuff.
How's your XML ?
It's
always been one of those acronyms I've never needed to educate myself on.
The Michael Kay book, "XSLT".
The O'Reilly "XSLT Cookbook", if you find yourself dropped into something from a great height, but be warned that it contains major ugliness ! XSLT is one of those technologies that's beautiful when it's applied to the right problem, but often mis-applied and blecherous.
Now... we're working with a web content provider who says we need to use XSLT and Web Services to pull the content from their site.
You _need_ web services. You may find XSLT useful.
You may also find XSLT to be a nightmarish hell-hole (especially with web services), but that's a separate issue. It is _not_ the solution to all the world's data integration problems, so be suspicious of vendors who tell you it is. But you should still learn it.
Can someone give me a nutshell definition on how this works???
In the beginning was Unix RPC RMI, Corba, DCOM et al. These let you "call functions" on distant machines. Then the philosophical question started to arise as to whether it was best to treat these as "functions"; placeOrder (myOrder) or to treat them as wandering objects that could manifest behaviours in the relevant places; shippingWarehouse => myOrder.fulfillYourself
HTTP and the web happened. Shortly followed by HTML and gaffer tape. It was extremely useful to "screen scrape" catalogue sites and read the human-readable HTML version, instead of doing a database import of the products catalogue. You could even pretend to be a human-filled-out <form> and submit orders from scripts. Great advances in usefulness, but oh was this code nasty and unstable!
So in '99 or so, SOAP arrived. Take XML (as a better-behaved and more flexible HTML) and use that instead, through something resembling a well-thought-out specification. XML-RPC was also invented (by He Who Shall Not Be Named), but that's best ignored.
SOAP used HTTP, because everywhere in the world was wired for HTTP and firewalls let it through unchecked. If you couldn't do this, you could run it over SMTP (rather cute for low-volume and low-cost setups) or any other protocol you could invent. I'm sure someone on Slashdot has done carrier pigeons and Napster by now.
That question of "function call vs. wandering object" cames back again. SOAP specs went through minor version changes and came back unrecognisable. Hmmm.
By this time, SOAP was getting unwieldy. Its one great benefit though was its _absolute_ non-proprietary nature, platform and coding language independence. So then along came "web services" and the rise of middleware. This "simplified" things for developers, because now they had a piece of code on their machine to take to, rather than an abstract protocol. However we were also now tied to vendors (IBM Webthing, BEA Webotherthing or briefly HP's Bluestone) and languages (Java everywhere on all servers). OTOH, imagine the tag soup nightmare if developers still in short trousers had to write their protocol state machines. At least now it works.
To let web services talk, there's something called WSDL. This is like IDL for web services, it describes function call APIs. Most service-building people now make WSDL (automatically, so it's fairly accurate) and a few client-building people even use it (also automatically).
UDDI is the next rung up the tree. This lets you advertise web services, so that clients looking for "a service that does <foo>" can find one, even if they've not encountered your business before. No one uses this yet.
M$oft did something too, but we don't talk about .that
BizTalk is evil incarnate, BTW. First M$oft product to be specifically mentioned in the Book of Revelations.
So now it works like this.
- Buy middleware, as suits your existing server platform (or switch to JBoss). All middleware talks to all other middleware - any that doesn't is a heretic and should be burned.
- Design your app, probably using some sort of CASE tool. Press a button - out pops both code that talks to your middleware, and WSDL that describes its web service nature.
- Plug. Play.
- Pay large bill for middleware.
- Pay larger bill for Java geeks who understand optimisation.
The O'Reilly on SOAP is almost useless because it's so trivial, but it is a reasonable one evening's read that will give you the basics. Then throw it away.
More advanced reading really depends on which platform you've chosen. The grey one with the zen garden on the front is decent, if you're not already anti-Java.
We use Cold Fusion MX on our web server,
Haven't touched Cold Fusion this millennium. All platforms have a middleware product though, becuase if they don't, then they're dead.
somewhat simple procedure on how one pulls data from a remote server using XSLT.
You don't.
You pull the content by other means (probably "Middleware for CF"), then you get an XML document back. You might process this by XSLT. That would rather depend on what you intended to do with it afterwards though.
If I was writing a client that used a consume-only model with some fairly detailed information service (maybe TV listings), then I offered this to humans through something like HTML or PDFs, then I would look at using XSLT (largely because the final consumers are humans who like verbose documents). If I was doing something more machine-oriented, or more bi-directional, then I would avoid XSLT.
