On 12/21/05, Biske, Todd <[EMAIL PROTECTED]> wrote:
You could dereference the namespace URI (assuming its an http URI, as it should be) and find it there, perhaps via RDDL ( http://www.rddl.org).
Indeed. You might want to consider using RDF/XML, which completely embraces that philosophy.
I'd say that the lack of the data model is the problem, not the schema. The schema only tells you a very small part of the data model.
I think you'd find it a lot more illuminating to look at the problem from a Web perspective rather than a Web services perspective, as in my experience, Web services have little to offer RSS and other document-oriented systems.
It sounds like you need an asynchronous data transfer mechanism, and I've found HTTP can play that role very well for many applications. In fact, there's an HTTP based publish/subscribe router called mod-pubsub which seems to do exactly what you want. KnowNow sells a commercial quality version too (in fact, mod-pubsub was created by KnowNow). You POST to a topic URI, and other clients can GET from that same URI to retrieve the POSTed document. The mod-pubsub site is currently down, but I have the latest version of it on my machine.
Mark.
-- To understand where I'm coming from, disconnect the RSS feed from its current use in a feed aggregator/client. Imagine that I'm writing an application that wants to poll the RSS feed and integrate the data into an AJAX app that will show the earthquake location on a google map or something along those lines.The first problem is that I have no schema for the XML content within each <item>. Yes, I can manually open the XML feed and infer a schema, but this has potential to be very brittle. If we're dealing with complex types, it could be a lot of effort to integrate this into a robust application. The latitude/longitude example of the USGS may be too trivial. What I'd prefer would be to have an XML schema available via a standard query (like ?WSDL...) that the development tools could utilize to allow the developer to integrate the data in a more efficient manner.
You could dereference the namespace URI (assuming its an http URI, as it should be) and find it there, perhaps via RDDL ( http://www.rddl.org).
This also has run time benefits, since this schema dictates a functional contract. That contract can be versioned, data can be checked for compliance, etc. Guaranteed, if no one does anything the schema, the run-time benefits aren't as great. The bulk of the cost is in the development-time integration. My philosophy is that the schema will eventually change, and we're far better off planning for it and managing it effectively.
Indeed. You might want to consider using RDF/XML, which completely embraces that philosophy.
Without a formal schema, we're really limited in what we can do.
I'd say that the lack of the data model is the problem, not the schema. The schema only tells you a very small part of the data model.
Another example of this is in the fire and forget style of service invocation. A service is an explicit request to a provider to go do something. In the fire and forget style, the consumer doesn't care when or how it gets done, only that it will get done. Typically, we'd implement this by having the consumer drop a message on a queue, with a provider picking it up off the queue when it's ready. The consumer's thread is freed up at the time the message is dropped, it doesn't have to wait for processing to occur as it would in a request-response style. With Web Services today, I have a dilemma. Tools like VIsual Studio will import WSDL and generate a client proxy, but the interface exposed is a combined "create SOAP and Send" operation, named according to the operations, of course. If I want my .NET client to drop the SOAP message on a JMS queue, I have two options:1) Generate the SOAP by hand. This is the equivalent of what I'd do currently in the earlier examples, but at least I have a schema in a WSDL file.2) Use low level APIs to register a SOAP interceptor so I can grab the message and then hand it off to my JMS code. Neither of these are particularly attractive, and this is what we have to do in the other event-driven scenarios I called out.
I think you'd find it a lot more illuminating to look at the problem from a Web perspective rather than a Web services perspective, as in my experience, Web services have little to offer RSS and other document-oriented systems.
It sounds like you need an asynchronous data transfer mechanism, and I've found HTTP can play that role very well for many applications. In fact, there's an HTTP based publish/subscribe router called mod-pubsub which seems to do exactly what you want. KnowNow sells a commercial quality version too (in fact, mod-pubsub was created by KnowNow). You POST to a topic URI, and other clients can GET from that same URI to retrieve the POSTed document. The mod-pubsub site is currently down, but I have the latest version of it on my machine.
Mark.
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
