Web Services
I've heard a lot of people discount SOA as a bogus buzzword which people are throwing around to describe anything that they want to sell you. While I think that's mostly true, I also believe there are a lot of people building systems on top of services with great success. For a few examples, checkout Ten companies where SOA made a difference in 2006. I'm hoping that some of our clients make it on the list for 2007, 2008, and beyond as we start rolling out our software, and getting people using the services layer that we're providing.
Technorati tags:
soa,
services
I've grown increasingly interested in taking advantage of all the free web services that are popping up. LinuxWorld recently published an article about "Ten Web API's you can really use". For those, like me, interested in seeing real life web services (of the public nature) that are being made available to the world, I'd suggest checking out some of the API's they cover.
Another great source that I found a couple months ago is the ProgrammableWeb. They have over 350 API's cataloged and are growing their database daily.
Yesterday
I posted about how I'm considering using Amazon S3 as my backup solution. This evening I went searching to see what tools are available for working with
S3 and found myself at
SmugMug. When the SmugMug homepage loaded I wasn't sure how or why I ended up there. After a little bit of backtracking to the
Amazon S3 Solutions Catalog page I found a couple comments that suggested that SmugMug was using S3 as part of their infrastructure. Again after a little digging, I came to Don MacAskill's blog post entitled, "
Amazon S3: Show me the money". Done reading? If not let me wait, you really have to read his post, its amazing......ok all done?
SmugMug is saving an incredible amount of money by moving much of their storage infrastructure to Amazon S3. Rather than purchasing servers and storage as their needs increase, SmugMug is leaning on S3. As a result, they've already saved $350,000 in the last 7 months, and are expecting to save over $1,000,000 in 2007. That's $1 million more dollars that they can spend improving their business, or enjoying themselves. The more I read about the web service offerings from Amazon, the more ideas that come to mind. What kind of "muck" are you dealing with that Amazon might be able to help you with?
Technorati Tags:
smugmug,
amazon s3,
s3,
aws
Me neither, but Ryan Tomayko did. Lucky for us he captured it all in a nice blog post here:
How I explained REST to My Wifetags:
rest,
webservices
Speaking of REST,
it appears that the next version of Rails (1.2?) is going to have some
nice built in support for accessing "resources" with REST. It seems
similar to what Alex is looking for in
RESTQL.
tags:
rest,
rails,
webservices
If you've done any work designing SOAP based web services you undoubtedly know that that The S stands for Simple, right?
As someone who has been working extensively with SOAP based web services (developed using Indigo) over the last year+, I have a lot of interest in the REST approach. I've found the following "REST Dialogue" posts useful, and I'm definitely looking forward to checking out Leonard Richardson and Sam Ruby, "REST Web Services" book! Where do you stand on the REST vs SOAP debate?
The REST Dialogues
If your developing web services you should consider doing contract first development. To help, be sure to check out Christian Weyer's WSContactFirst.
If you're trying to keep up with all the WS-Specs out there check out this easy to read introduction on WS-Eventing.
And now WS-Eventing Part II: The Subscription Response!
I've just read a couple overviews of WS-Addressing and think I understand its intended purpose.
I was about to write pretty much everything I read on Steve Maine's blog so let me direct you there rather then plagiarize his entire post 
. The funny thing is that it took reading another MSDN article for me to *get* what Steve got when he posted his "I think I finally get WS-Addressing" post.
WS-Addressing helps to define how web services should be invoked, routed, and replied to in a transport neutral way. Rather then relying on HTTP to carry along the information necessary, we explicitly define it in the SOAP Header for our web service calls. This not only allows us to invoke web services using TCP, but it also allows us better control over how the response messages from our web services calls are handled. Rather then always returning to the address of the service/client that invoked the web service we can instead reply to another service or client. We also have the ability to customize how SOAP fault's are handled. What's cool is that using this approach we're able to introduce a lot into our architecture. Instead of limiting ourselves by always having our message response returned to the place that it was invoked from we can introduce all kinds flexibility regarding how the response is handled. We have the ability to chain web services together, and provide a dynamic pipeline for processing our message. WS-Addressing is cool, and as Alex Lowe reminded me extremely necessary.
Reference:
Web Service Addressing (WS-Addressing)
Expanding the Communications Capabilities of Web Services with WS-Addressing