posted by ![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
sbisson at 03:08pm on 11/07/2002
sbisson at 03:08pm on 11/07/2002...here. All to the good, seeing Don add RSS to his site, and to see him get the point of its use in the blogging community.
But will he grok RSS as the missing half of the web services equation?
Perhaps I'd better explain my thinking here.
Currently web services are very much focused on the task of managing remote method calls. That's all very well when your code needs to access information with low latency - a typical call-response cycle. But there are many cases, especially when dealing with long workflow-based distributed computing models, where we use workflow orchestration to manage the transactional relationships across multiple web service requests, when we don't need to get access to near-instantaneous information.
Instead, we're just accessing pre-published sources - sources that need a catalogue. Where WSDL gives SOAP a call structure for any remote procedure, RSS gives us the tools to extract information from periodically updated information sources - which don't need to be documents, as RSS 1.0 lets us codify anything with a URI, even down to the level of a single element in an XML document. And what's ocured to me today is that RSS descriptions themselves can be dynamically generated and personalised (especially if you're accessing them over SSL...).
Lets consider a simple case. I have an application that is designed to just look for problems on my tube journey. It has a secured relationship with a remote web service. Instead of making a parser intensive SOAP call, I just request the RSS for my journey, and then extract any updated information into my UI. All my code needs is the URI of my RSS feed, and the ability to extract and parse URIs as required. It's a lot simpler than constructing a SOAP message, sending it, waiting for the response and then parsing and processing the resulting information stream.
But will he grok RSS as the missing half of the web services equation?
Perhaps I'd better explain my thinking here.
Currently web services are very much focused on the task of managing remote method calls. That's all very well when your code needs to access information with low latency - a typical call-response cycle. But there are many cases, especially when dealing with long workflow-based distributed computing models, where we use workflow orchestration to manage the transactional relationships across multiple web service requests, when we don't need to get access to near-instantaneous information.
Instead, we're just accessing pre-published sources - sources that need a catalogue. Where WSDL gives SOAP a call structure for any remote procedure, RSS gives us the tools to extract information from periodically updated information sources - which don't need to be documents, as RSS 1.0 lets us codify anything with a URI, even down to the level of a single element in an XML document. And what's ocured to me today is that RSS descriptions themselves can be dynamically generated and personalised (especially if you're accessing them over SSL...).
Lets consider a simple case. I have an application that is designed to just look for problems on my tube journey. It has a secured relationship with a remote web service. Instead of making a parser intensive SOAP call, I just request the RSS for my journey, and then extract any updated information into my UI. All my code needs is the URI of my RSS feed, and the ability to extract and parse URIs as required. It's a lot simpler than constructing a SOAP message, sending it, waiting for the response and then parsing and processing the resulting information stream.
pleased
There are no comments on this entry. (Reply.)