Putting services to use

My test drive of Grand Central's Business Services Network seems all the more urgent now that Amazon Simple Queue Service has launched. My gut feel is that having capabilities like these available on demand from reputable providers like Grand Central and Amazon is going to put a whole lot more functionality within the reach of users that never previously had the skills or the resources to make use of them. Mike Gunderloy spelt out the potential impact in an insightful comment piece on ADTmag.com this week, Could Amazon be your next infrastructure partner?:

"By taking responsibility for all of the messaging infrastructure, and by providing a simple interface to it, Amazon threatens to lower the cost of entry for setting up a distributed application to just about zero (plus whatever they charge for the service, of course) ... Without the Amazon Simple Queue Service, setting up a distributed application with message queueing for one of my smaller customers would be daunting: install a server, get MSMQ (or some other queueing software) set up and configured, write to its API, figure out who's going to monitor and maintain the server. With this new offering, the job is simplified to just putting some Web service calls into the components."

The purpose of my test drive is to follow up my gut feel with a proof-of-concept, using the Grand Central Network as a test bed. It's all very well talking breathlessly about the wonderful potential of these on-demand capabilities, but can you actually string them together to do something useful? And is it really so accessible that even a power business user like me can cobble simple processes together using the tools and capabilities that Grand Central offers? After a weekend upgrade at the provider, my early access account is now using the production 2005 version, so I was greeted by a new sign-up page when I returned to continue the test drive yesterday. Here are the notes and thoughts I jotted down as I went:

• The new-look Business Services Network login that came into effect as of Monday is much changed from the early adopter version. It's pitched much more at the non-technical user, with strong, clear messages about the business applications of the network, and very clear, straightforward instructions. The Firefox problem I'd previously noted with the Dreamfactory plug-in is now fixed, which is good news as I was finding it a pain having to remember to load up IE before logging on.

• As well as the 'Hello World' example I ran through last week, there's now another sample process in the Process Designer application: QuoteRequest. This is a more complex process, and is a good demonstration of how the various actions connect together in the designer. But I'm not really the kind of guy that works through training or reads the manual; I'd much rather just get started, and when I run into problems, that's when I want to look things up. (This, by the way, is the main reason why I like using PHP; its online documentation is excellent, and very easy to use).

• The trouble with any new application or software environment is working out how to get started. I can remember, back in 1985, puzzling over Lotus 1-2-3 for ages until someone explained about using the slash key to bring up the menu (no, I didn't look at the manual then, either). Here I am, two decades later (goodness, has it really been all that time?) and I'm paging back and forth between a list of my 'Endpoints & Processes' and the 'Service Directory', puzzling over how I'm going to take the first step. I want to do something simple but with a practical use. I can't quite manage to map what's in front of me on the screen to a mental roadmap of how to reach that objective.

• My first idea is to use Grand Central's message scheduling capability as a way of triggering a regular process on the Loosely Coupled website, such as regularly checking RSS feeds for updates (or, since we're in the services realm now, perhaps I should save everyone a lot of bother and think more in terms of checking via the Bloglines API; but let's not get ahead of ourselves just yet). The conventional way of getting your website to do something automatically is to run what's called a 'cron job'. But I've never got around to working out how to do this, not least because I remember reading that they carry the risk of making the server fall over, which is the last thing you want to happen in the middle of an automated, unattended process. By putting this functionality into the Grand Central network, I can decouple it from my web server, and let Grand Central worry about making sure its servers don't fall over.

• Following the tutorial last week, I built a simple process to make a 'Hello World' response to an input. What I'm now aiming to do is to build a process that responds to a scheduled message with a call to an external service. It sounds very similar in principle, so I'm going to work through the same tutorial but adapt it as I go along.

• OK, into Process Designer and open a new service. I'll call it PollResponse. Then go to Process View, and start off by dragging the Reply icon into the process. I would find some extra help useful here, for example, something that explains what each of the available icons mean. The error handling icons in particular are pretty impenetrable — 'Try', 'Catch', 'Throw' — this is a ballgame I'm not familiar with. But the help does at least tell me that the Process Designer is "for different types of mediation when exchanging messages between services," whereas what I'm doing here oughtn't to need any mediation. All I really need to do is to define an endpoint, register it with Grand Central, and then get the network to fire scheduled messages at it.

• But I'd rather avoid having to write a SOAP web service to run on my web server (imagine the fun that would be, especially since my web server host, along with every other packaged managed server provider, doesn't yet support the XML-friendly PHP 5, leaving users like me stuck with 4.3.2 or worse). So instead, I'm going to use Grand Central's HTTP Gateway service to translate the SOAP request generated by the automated message into an HTTP post that will trigger an action on my server. Back in Process Designer, instead of the 'Reply' icon, I insert the 'Service' icon, which is an attractive green cog, and it's now sitting in my process flow with the name 'Unlabled'. I wonder, how do I turn that virgin cog into the HTTP Gateway service? This needs a bit more research, so I'm going to save the unfinished process, close off for now, and return later.

Will I eventually succeed in cobbling together my first real-world, SOAP web services process using the Grand Central Network? Or will it all end in shame and disappointment? To be continued ...

posted by Phil Wainewright 3:48 PM (GMT) | comments | link