Posts tagged 'webservices'



Friday Atom and REST links

A bunch of Atom and REST related links that I came across while catching up with my blog reading today:

Atom and LDAP sitting in a tree. Trey Drake has released his OpenDS based Atom store as an open source project on Java.net at http://atom.dev.java.net. It's a directory server distributed as a Java web application that supports both Atom Publishing Protocol (APP) and Lightweight Directory Access Protocol (LDAP).

Signing, encrypting and decrypting Atom. On IBM developerWorks, Nicolas Chase explains how "digital signatures and encryption can easily mesh with Atom data using the Apache Abdera API."

Google GData: A Uniform Web API for All Google Services. Dare Obasanjo praises Google for creating a single uniform and RESTful web services API for eight of its key services, the APP based GData API. He writes "not only is it now possible to create a single library that knows how to talk to all of Google's existing and future Web services since they all use GData. It is also a lot easier to provide 'tooling' for these services than it would be for Yahoo's family of Web services given that they use a simple and uniform interface."

RESTful web services support in Netbeans. Geertjan links to blog entries and a screen-cast that explain Netbeans 6.0 support for RESTful web services, including the early access JSR-311 REST API.

Generate code from your WADL REST API. Eduardo at The Aquarium links to Thomas Steiner who is making progress on a WADL editor and a generator, bringing WSDL-like code generation to RESTful web services.


The Apache Lucene GData server project

German Viscuso: Generally spoken GData provides a general interface to make information available even beyond a browser context by providing a single API that could be used to query, update, and index structured data anywhere on the web. Could GData become a simple and open replacement for all the proprietary communications protocols currently in use by database vendors?
Interesting thoughts. I've heard about the Atom Publishing Protocol (APP) based Lucene Web Services API, but I hadn't heard about the Apache Lucene GData server project. Atom protocol is moving fast, especially considering the fact that it's not finished.

RESTful Web Services, by Richardson and Ruby

Book's cover Leonard Richardson and Sam Ruby's new book RESTful Web Services is now available. It was one of the best sellers in the JavaOne bookstore this year, so congrats to Leonard and Sam. It sold out before I was able to get a copy; Rajiv bought the last one in the store.



APP and OpenID at JavaOne

Trey Drake: How do you demo a directory server? Build cool apps around it. To that end, we've built an Atom/APP server, a lightweight OpenID server, a blogging and "twitter" like app - all powered by OpenDS. Drop by our booth (Glassfish alley at CommunityONE and .org section of the pavilion during JavaONE). Ludo and I will introduce OpenDS and show off the demos in two talks; today at CommunityONE at 5PM and Wednesday at 1:30 in the CommunityCorner.

Very cool. I'm not going to be the only one talking about Atom protocol at JavaOne. I'll have to stop by the CommunityCorner, that sounds too good to miss.


Propono 0.5 released

ROME Propono 0.5 is a minor bug fix release of Propono. You can get the release files and updated Javadocs from the Propono 0.5 release page.

WSO2 Web Services Mashup Server

I was wondering what web services vendor WSO2 was doing at the APP interop event. Turns out, they've got a "Web Services Mashup Server" in the works.

APP interop event day #2

The Atom Publishing Protocol interop event is over and now I'm catching up on blogs and email in my hotel room in Mountain View, CA. In the end, I was able to run ROME Propono successfully against Blogger/GData, AOL Journals and Wordpress. I also found a dozen small problems in Propono and in the Roller APP server.

For more information on the event, check O'Reilly's Keith Fahlgren's summary of the event titled Atom Publishing Protocol a Success. Keith mentions that "big industry players like AOL, Google, IBM, Microsoft, Oracle, and Sun are working on APP clients and servers and sent people to the interop event with interesting code" and I agree that's definitely a good sign for the protocol.

I thought it was particularly interesting that database vendors IBM and Oracle showed up with DB2 and Oracle-backed Atom stores. If Google's half-dozen or so Atom protocol based services aren't enough make you stand up and take notice, surely that should get your attention.

APP interop event day #1

Day one of the Atom Publishing Protocol (APP) interop event was a success, at least from my point-of-view. I was able to test the Propono client against Blogger.com/GData, AOL Journals and an implementation from Oracle. I found and fixed problems in Roller's APP implementation. Plus, it was great to meet all of the good folks implementing Atom and to get a close look at the Google campus. I'm getting ready to drive back to Google now so... gotta go.

Check out Tim Bray's blog for some photos of the event.


Atom protocol interop event

I just got approval to attend the Atom protocol interop event at Google April 16 and 17. I'll be bringing at least three Atom protocol implementations: Roller's Atom server, Propono's simple file-based Atom server and Propono's Atom client.

Atom protocol as the substrate for reliable messaging

I've heard the argument before that the REST approach to web services doesn't give you reliable messaging and that's the reason you need to stick with WS-*. Today Bill de hÓra disputes that notion with an interesting and somewhat provocative post that mentions a couple of specs for messaging via HTTP (HTTPLR and BTF) and argues that Atom protocol can serve as the basis for web-scale reliable messaging.

Bill de hÓra: There are a number of reasons to choose Atom Protocol as the substrate for web-scale reliable messaging. First, a ton of software will be written to target APP in the next few years, and there is plenty of scope for extending the protocol; this suggests openly available and flexible software stacks. Second, since all document collections in Atom Protocol are served as Atom Feeds, it has inherent support for systems management and end to end reconciliation. Third, Atom entries have identity and are natural envelopes, unlike SOAP, where identity and true enveloping requires further specification (essentially raw Atom presents a better basis for interoperation than raw SOAP). Fourth, Atom Protocol can support binary content transmission not just XML, and thus can transmit arbitrary payloads. Finally, because Atom Protocol respects media types and deployed HTTP infrastructure, independent proxy inspection and security check-pointing can be installed cleanly, also eliminating the need to rewrite 2 stack layers and buy XML appliances to support and secure SOAP backed web services. It seems to be a question of when, rather than if, this will get built out.

I would have blogged about this earlier today, but Bill's blog looked foobar and I didn't realize that today is CSS Naked Day. My blog doesn't look half bad naked.


Latest links: March 21, 2007


javax.ws.rest

That's big news. A standard Java API is coming for building REST based web services. If you're an expert in REST, you can participate in it's development by signing up for the expert group. Apache, BEA, Google and Jerome Louvel (the RESTlet guy) are on-board. Here's the intro from the JSR:

JSR 311: Java (TM) API for RESTful Web Services: This API will enable developers to rapidly build Web applications in Java that are characteristic of the best designed parts of the Web. This JSR will develop an API for providing REST(Representational State Transfer - See reference to Roy Fielding's dissertation in section 3.1) support in the Java Platform. Lightweight, RESTful approaches are emerging as a popular alternative to SOAP-based technologies for deployment of services on the internet. Currently, building RESTful Web services using the Java Platform is significantly more complex than building SOAP-based services and requires using low-level APIs like Servlets or the dynamic JAX-WS APIs. Correct implementation requires a high level of HTTP knowledge on the developer's part.

This JSR will aim to provide a high level easy-to use API for developers to write RESTful web services independent of the underlying technology and will allow these services to run on top of the Java EE or the Java SE platforms. The expert group will investigate whether a subset of the API can be made used with Java ME. The goal of this JSR is to provide an easy to use, declarative style of programming using annotations for developers to write REST ful Web Services and also enable low level access in cases where needed by the application.

RESTful Web Services is a relatively new area in the industry and there are still a lot of unknowns in this space. For example, a key aspect of RESTful Web Services is for the service to be stateless. However, this often requires the developer to produce boiler-plate state restoration code that could be avoided with state-aware API help. We expect the expert group to be an active and engaged group of people participating to prioritize and help drive issues to achieve the end goal of a developer friendly API.

Here are a couple more links about the new JSR:

  • Elliote Rusty Harold is not exactly positive, saying "this is like asking Karl Rove and Dick Cheney to write the Democratic Party platform" but concludes with a call for participation: "are there any JSR members here who might join the working group and bring some sanity and actual REST experience to the development of the eventual specification?"
  • Jerome Louvel explains the idea of REST annotations and explains that implementations will be possible with JAX-WS, Servlet API or Restlet API.
  • Dan Diephouse says "This is excellent news - I’m glad to see people are thinking more seriously about RESTful services on Java" and "Expert group members may be interested in checking out the previous work I’ve done on Java REST annotations"
  • Brian McAllister: says the JSR sounds like another case where "reasonably good developers trying to design software for presumed-incompetent developers which will in fact be used unhappily by basically competent developers."
  • Mark Hadley addresses some of the concerns raised above and provides an interesting code example showing the REST annotations in action.
  • Pete Lacey: "Initial thoughts: 1) Cool! 2) The servlet API is not ideal, this is needed. 3) I hope they don’t screw it up (see JAX-WS)."
  • Steve Loughran: "I don't have the faintest clue what a REST API should look like, except that it must not look like JAX-RPC/JAX-WS"
  • InfoQ thread: summary of news and three comments as of Thursday
  • Paul Sandoz: "I have been wanting to work on such an API and implementation for about 5 years! [...] Now the Web zeitgeist is back and so are we :-)"

New Atom protocol spec draft and Queen City planets

Joe Gregorio announces a new Atom Publishing Protocol Spec (draft #12) and he says it might end up being the final. I guess it's time for a new Blogapps release with APP draft #12 and ROME 0.9 support.

Plus, Joe has put together a set of new planet sites for towns in the Charlotte, NC area; all based on feeds from Google Base, Google Blogs, Google News, Craigs List, Flickr and the Weather Service. The sites look useful, but the ads combined with the minimalist design make them look a little spammy on first glance. Perhaps a short "about this site" paragraph is in order.


Ruby MetaWeblog API example

Marcus Crafter has written-up his experience moving his blog content from MovableType to Typo and all the code he used to do the job -- an excellent example of using the XML-RPC based MetaWeblog API from Ruby

Atom Publishing Protocol, draft #10

APP draft #10 is available. I'm still reading it over, but the major changes appear to be:
  • Categories can be specified at the workspace and collection level. Multiple category schemes are allowed and both fixed and free-form categories (e.g. tags) are allowed.
  • Collection titles are now specified by an <atom:title> instead of an attribute on the <collection> element.
  • A new "slug" header has been added for media posts so that clients can specify the file-name to be used for the uploaded file.
I'm especially happy about the category support -- now Atom protocol can do everything that MetaWeblog API can do, and much more. I'll be updating my client and server implementations during the next week.

Destructive GET

Beware the Google Web Accelerator. It will wreak havoc on the web applications that you use (Roller included). Problem is, in most webapps HTTP GET changes things (even though it shouldn't). Read all about it on O'Reilly Radar. I don't understand this. Google employs a hell of a lot of very smart people. How did they let this one slip by?

Update: I just reviewed the Roller UI and found that, at least for deletes, we do the right thing. The pattern we follow is to use a delete link (which causes a GET), but that sends you to an "Are You Sure" page which uses a POST to do the actual delete -- so Roller is probably safe from the Google Web Accelerator.


WellformedWeb(TM) Services

Most folks out there in corporate IT land believe that webServices == wsdl + soap. Joe is fighting that notion. BTW, I don't think Joe means to imply that SOAP and WDSL are not well-formed.

Joe Gregorio: Barring any rename, which in all honesty I know won't happen, I'll just have to start referring to non-SOAP based services as Well-Formed Web Services.