I’m pleased to announce the release of the first draft of
RDF Forms. This is the first usable
specification to emerge from some ideas that have been floating around in my
head for a couple of years (in
It looks brain-dead simple now, so I think (hope?!) that means that I
probably got it right.
As an example of an RDF Form, here’s a query (aka GET) based one for the
“Top downloads” service of
Mark’s RESTful MS Web services front end;
<rf:indexedBy rdf:resource="http://diveintomark.org/msweb/?WSDL#topType" rf:shortName="topType"/>
<rf:indexedBy rdf:resource="http://diveintomark.org/msweb/?WSDL#topN" rf:shortName="topN"/>
<rf:indexedBy rdf:resource="http://diveintomark.org/msweb/?WSDL#cultureID" rf:shortName="cultureID"/>
Thanks to Jan Algermissen and
Aaron Swartz for their help (though
Aaron didn’t know he was helping on this when he answered a question for me 8-).
for comments on the using a feed URI scheme to identify a subscription action for the
feed, e.g. “feed://http://example.org/rss.xml”.
I think we can do better. Here’s two big reasons why I don’t like this proposal;
- “Clicking” on a URI should always be safe, and provide information
about the identified resource, not take an action upon it. This enables
humans and automata to be able to trust that they’re
not entering into an obligation
by dereferencing a URI (any URI, not just http URIs).
- The resource really is “http://example.org/rss.xml”, and putting
“feed://” on the front obfuscates that from parties who don’t know
what “feed://” means.
So what’s the better proposal? For one, get folks to start using an
RSS-specific media type
so that the client knows it’s RSS. Then you just need to register
your aggregator as the application that handles that media type. Within
the aggregator, I would expect to see that feed after clicking on
the URI, but with a BIG “SUBSCRIBE” button in plain site when it realizes
that I’m not already subscribed to that feed. As a bonus, there’s no need
for a different “subscription URI”.
Kudos to Mark for putting a
Web front end
on the SOA based Microsoft Web Services API. Very nice!
I saw a BEA press release the other day, and was feeling a bit cheeky
tonight, so I threw this together. April is just too far away. 8-)
BEA embraces the Web for integration
Friday April 1, 2005 6:00 am ET
Regrets role in Web services. Vows to get down to business to solving
customer integration problems.
SAN JOSE, Calif. -- BEA Systems, Inc., the world's leading application
infrastructure software company, today announced that it was
discontinuing any further support of "Web services", and was announcing
sweeping organizational changes that will better position it to produce
high quality products that enable the creation of services built on the
architectural principles that have made the Web such a success,
including the constraints of the REST architectural style.
"It boggles the mind to realize what a huge mistake had been made with
Web services, and how this awesome integration platform - the Web - was
right under our noses the whole time.", said CTO Scott Dietzen. "In
retrospect, it's all so obvious, but that's small consolation when you
consider how much time and money we've wasted these past few years".
CEO Alfred Chuang added, "BEA is proud to be the first major application
infrastructure software company to close the book on this dark chapter
of IT history. We apologize to our existing customers for our role in
this debacle, and look forward to working with them to help put their
services where they belong, on the Web".
The company also announced that David Orchard had accepted the role of
Chief Architect of the newly formed Semantic Web group, whose mission
will be to integrate the W3C's Resource Description Framework into BEA's
products, enabling customers to further simplify data integration tasks.
"That's still XML, right?", Dave was heard to say shortly after learning
of his new assignment.
BEA Systems, Inc. is the world's leading application infrastructure
software company, providing the enterprise software foundation for more
than 15,000 customers around the world, including the majority of the
Fortune Global 500. BEA and its WebLogic(R) brand are among the most
trusted names in business.
Headquartered in San Jose, Calif., BEA has 77 offices in 31 countries
and is on the Web at www.bea.com.
to an old (June) post by Bill on
Foundations for component and service models.
I’m not sure why I missed this one, but it’s more or less bang on from my POV.
One quick comment …
“Calls should return documents not objects”; if the calls returned
the serialized state of objects,
would that be ok? Oh, right, documents are serialized object state P-)
Broken record, me?
Radovan Janacek writes;
However, in large scale scenarios, or in complex integration scenarios (many services, complex processes, evolution, independent participants) I definitely vote for REST-based approach.
Awesome. Conventional Web services wisdom has always been – until now – that
this kind of scenario is exactly where you need Web services. I look forward to
seeing how WASP
ends up incorporating his ideas.