David Janes' Code Weblog

November 29, 2010

Good-bye XML, SOAP & SOA

ideas,javascript,xml · David Janes · 7:17 am ·

In my callow youth, I remember being so excited about XML. Ah, how wrong I was. Two articles of interest:

The End Of The Road For Web Services

Web services as a strategy was fundamentally flawed in my view because it was so un-web. It took an idea that hardly worked on an Intranet – remote manipulation of tightly-specified objects – and tried to make it work on the Internet. It led to software applications that by default were complex, brittle and heavy. Although I know many brilliant software engineers who worked unexpected miracles with Web Services, implementation by the common corporate programmer was stodgy in every case I heard about. In the end Web Services became an intranet tool for most uses, rendering the “W” incorrect even if WS* will be with enterprise developers for years to come as a kind of architectural COBOL.


XML vs the Web

It’s “Yay”, because for important use cases JSON is dramatically better than XML. In particular, JSON shines as a programming language-independent representation of typical programming language data structures. This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this. The fundamental problem is the mismatch between programming language data structures and the XML element/attribute data model of elements. This leaves the developer with three choices, all unappetising


So what’s the way forward? I think the Web community has spoken, and it’s clear that what it wants is HTML5, JavaScript and JSON. XML isn’t going away but I see it being less and less a Web technology; it won’t be something that you send over the wire on the public Web, but just one of many technologies that are used on the server to manage and generate what you do send over the wire.

In the short-term, I think the challenge is how to make HTML5 play more nicely with XML. In the longer term, I think the challenge is how to use our collective experience from building the XML stack to create technologies that work natively with HTML, JSON and JavaScript, and that bring to the broader Web developer community some of the good aspects of the modern XML development experience

Having in recent memory been involved in a SOA deathmarch project (still in the process of tumbling down to inevitable failure), and dealing daily with the issues of transferring data using XML, I can firmly say: good riddance.

What do we do now? We do JSON. Why do we do JSON? Because the JSON object model (and the implicit RESTful JSON API model) is almost an exact match for how programmers – especially those of languages such as Python, Ruby & JavaScript – think about data .

November 7, 2010

Twitter4J – working with the source in Android

android,java · David Janes · 8:58 am ·

Twitter4J is a is highly spoken of¬†Java library for working with the Twitter API. We needed to implement a simple List Widget that would display Twitter statuses based on a Twitter List, but unfortunately at this time Twitter4J doesn’t supply a method to easily do this (and the one that does do it requires authentication).

Here’s how we did it. First, to the Android project, we:

  • removed the Twitter4J JAR file from libs
  • added twitter4j directory (and subdirectories) to src – this is the directory with the .java files in it
  • added the following libraries to the project (in libs):
    • commons-logging-1.1.1.jar (from here)
    • log4j-1.2.16.jar (from here)
    • slf4j-api-1.6.1.jar
    • slf4j-simple-1.6.1.jar (from here)

I’m a little scared by the number of libraries we had to add just to handle logging (on a limited mobile phone!), but what can you do?

Then we added one new method (sigh) to the code:

public ResponseList getUserListStatuses(String listOwnerScreenName, String id, Paging paging)
  throws TwitterException
  return StatusJSONImpl.createStatusList(
    conf.getRestBaseURL() + listOwnerScreenName +"/lists/" + id + "/statuses.json",
    paging.asPostParameterArray(Paging.SMCP, Paging.PER_PAGE), auth));

The only issue is we’re getting a lot of weird warnings, but it seems to work well. We’ll probably take this out if the Twitter4J folks add the method to the regular releases.

Powered by WordPress