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.
