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. 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. Without
a formal schema, we're really limited in what we can do.
Now
take this out of the RSS context, and think of it in terms of general purpose
publish and subscribe. Right now, if I subscribe to a topic on a JMS
server, I have nothing that tells me what the payload is going to be.
Using the same approach, I want to have a programmatic way of obtaining the XML
schema and have that integrated into my development environment so I can write
that integration code quickly.
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.
-tb
-----Original Message-----
From: Mark Baker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 21, 2005 8:15 AM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: Re: [service-orientated-architecture] Bridging EDA and SOA
Todd,
On 12/20/05, Biske, Todd <[EMAIL PROTECTED]> wrote:A colleague of mine was showing me an RSS feed that the USGS is now publishing. Within each item, in addition to the normal title, description, and link elements, it also contains latitude and longitude values, among other things. This spun its way into a conversation around subscribing to events, and whether we need an EDL (Event Description Language) that would be analagous to WSDL. Essentially, at the time a subscription is established, the EDL could be pulled in, allowing the subscriber to integrate the data from those events in a much simpler fashion.
I'm wondering, simpler than what? AFAICT, HTTP & RSS seem to have things under control there, from both the functionality and simplicity POVs.
Mark
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
-------------------------------------------------------------------------------------
A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
archived and subject to review and/or disclosure to someone other
than the recipient.
-------------------------------------------------------------------------------------
SPONSORED LINKS
Service-oriented architecture Computer monitoring software Computer and internet software Free computer monitoring software
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.
