Application Platform Strategies Blog

A Contrarian Perspective on WS-* vs REST

Blogger: Anne Thomas Manes

Most blog posts you see regarding WS-* vs REST tend to trash SOAP and espouse the virtues of REST. This post by Ganesh Prasad takes a contrarian perspective, defending the elegance of what Ganesh calls the "SOAP-messaging-using-Smart-Endpoints" style. Ganesh entitles his post, "Paying the RESTafarians Back in Their Own Coin," although he really doesn't trash REST in his post. He simply espouses the virtues of the SOAP-messaging-using-Smart-Endpoints" model.

The post starts off as very educational -- the first part describes the virtues of the Internet and its reliance on a dumb network that only knows how to deliver packets (which it does remarkably well) and smart endpoints.

His argument gets less convincing, though, when he attempts to correlate the Internet's elegant model with that of WS-*. He implies that the WS-* model doesn't require intelligent middleware to be responsible for routing SOAP messages -- it only requires "endpointware". But then he goes on to talk about intermediaries and proxies, which in truth are intelligent mediation processors. I believe his point, though, is that you don't need a big fat ESB in the middle to direct traffic. ESBs should do most of their mediation processing at the endpoint -- think of an ESB as a service platform rather than a mediation system-- it is the endpoint.

All-in-all, I like the post, and I agree with his assertion that ESBs should operate at the endpoint rather than in the middle (at least most of the time). And I agree that there is a great deal of elegance in the SOAP-messaging-using-Smart-Endpoints model. (I don't think it's quite as simply elegant as REST, nonetheless, it is elegant.)

Read his thesis with a grain of salt. His argument has quite a few holes in it, as pointed out in Stu Charlton's comment (the 11th comment by "Stu").

Measurement, and a gift for the quantitative types

Blogger: Joe Niski

A big theme for my 2008 coverage of "all things SDLC" is what we measure, why we measure it, and how we measure. We all have hunches about where our development process does well, and what we could do better. Can we back up our hunches with hard data? Can we do it without a lot of manual data-capture overhead, i.e., without interfering with the process itself? To a large extent (the Heisenberg uncertainty principle aside), i'm convinced we can.

i won't go so far to repeat the old saw, "You can't manage what you can't measure." Rather, i prefer to rephrase it as "You can't improve what you don't measure." How do you measure project performance? Software quality? Developer productivity? What exactly do you mean by the things you measure?

Meanwhile, the fine folks at OpenLogic had a nice holiday gift for us quantitative wonks - the Open Source Census, a voluntary effort to catalog the use of open source "in the wild." If enough people behind the enterprise firewall participate, the whole industry could benefit from a reasonably valid snapshot of  open source utilization. Please consider participating - consider it a gift to the broad development community.

New RESTful Open Source Registry/Repository from WSO2

Blogger: Anne Thomas Manes

Open source SOA infrastructure vendor, WSO2, released a 0.1 version of a new open source RESTful SOA registry and repository. Paul Fremantle, WSO2's VP of Technical Sales, described the impetus and rational of this registry in a recent blog post.

Unlike UDDI-based registries, the WSO2 Registry treats each piece of information captured in the registry as an identified resource--i.e., a resource with a URI--which can be accessed and manipulated using the traditional HTTP verbs. The registry also supports remote access and notifications using the Atom Syndication Format (Atom) and the Atom Publishing Protocol (AtomPub).

The basic idea behind a REST registry and repository is a good one. It's simple, lightweight, easily accessible, and searchable. The major concern I have is that runtime systems typically need a bit more structure to enable information exchange among heterogeneous SOA infrastructure components. At the very least, we need a standard (but extensible) data model that specifies what type of information can be obtained from the registry, what the format of each type is, and the required or optional relationships that exist among registry entities. Without a standard data model, this registry will be just another vendor-specific proprietary registry.

The OASIS UDDI-spec technical committee has been talking about closing its doors, so no additional standardization effort is likely come from that quarter. If anyone is going to develop a RESTful registry/repository standard, it will be a brand new effort, and that's likely to take 5+ years to produce a standard.

The Difference between SOA and ROA

Blogger: Anne Thomas Manes

In the continuing debate over REST vs WS-* and SOA, Mike Champion recently posted the following text to the OASIS xml-dev discussion list, and I thought it deserved a little more airtime:

SOA has no constraints on operators,  but in practice operators are late bound via service definitions and operands are fairly stongly typed by schemas/data contracts. 

 

ROA tightly constrains operators, but has no constraints on operands (i.e. "resource representations" other than MIME types I suppose).

There is beauty in both views of life. What we need in my opinion is a deeper and more empirical understanding of which set of architecural constraints and non-constraints is most associated with the various, somewhat conflicting values of "scalability, evolvability, visibility, simplicity, etc."  Likewise, what are the real bottlenecks that create problems in real world implementations of the abstract designs?  I'm not at all sure there are simple and obvious results here. For example, a lot of WS-* projects founder because of the HTTP-level performance and quality of service issues compared to proprietary message services, and because of XML parsing performance bottlenecks compared to that of the previous generation of more tightly coupled data exchange mechanisms.  A failed "SOA" project isn't necessarily an opportunity for REST, it's often a victory for the old proprietary stuff that shouldn't give comfort to either side in the SOA/ROA debate. Likewise, a REST project that founders due to performance or security concerns is not necessarily an opportunity for a SOA vendor, especially if the designers don't want to install a bunch of stuff (beyond the browser) on each potential client.

      

Are PDAs dead? Not at all and here's why...

Blogger: Richard Monson-Haefel

It's easy to think of Personal Digital Assistants (PDAs) as a dead technology. After all, don't most smartphones, and even basic feature phones, include address books, contact lists, calendars, and such? Why buy a PDA which has no phone when you get a phone that has a PDA built right in?  That was my thinking until this last week when I had a fascinating conversation with Socket Mobile, a company that has been manufacturing peripherals for PDAs for about a decade.

It turns out there is a market for PDAs that do not offer phone capabilities - especially ones that are hardier than consumer devices but not as bulky as industrials devices.  Nurses use these types of devices while working with patients, retailers use them while taking inventory of stock, wait staff in restaurants use them to take orders, researchers use them to enter measurements and field data, and the hospitality industry uses them in their house keeping efforts. That's only a few really obvious examples - there are lots more. And in these types of situations you want the device to be portable and locally networked, but you don't want it be a mobile phone.  Can you imagine your waitress answering personal calls while taking your order? That's an extreme example, but the point is there are some jobs where having access to a mobile phone is not necessary or even desired but having a mobile device is. That's the PDA market that still exists today. (read more ...)

Why Microsoft Loves Google Android, Take 2

Blogger: Richard Monson-Haefel

Ed Burnette wrote a rebuttal to my blog post, "Why Microsoft Loves Google Android", which was high-spirited. Reputation bashing aside, I like high-spirited debates. My favorite quote these-days is, "Argue as if you were right, listen as if you were wrong" by Karl Weick. It's a good ground rule for any debate. It allows you to be passionate while also giving serious consideration to your opponent's arguments.

I want to apologize for my imprecise language in my original post. Ed’s misunderstanding of my thesis makes it clear to me that I didn’t explain myself very well, and I must admit that I used terminology inconsistently. I’d like to take another try at it, and this time I’ll make sure that I clearly explain the subtleties of forks, platform compatibility, and platform fragmentation. I also want to make it clear that I’m not trying to bash Android. I like Android. I’m just saying that Android is a threat to Java standards.

Is Android a fork?
First let me differentiate the Java Programming Language from the Java Platform. The Java Programming Language is a programming language syntax. The Java Platform includes the Java Language, but it’s much more than that. The Java Platform is a three-legged stool consisting of the core Java APIs (packages, frameworks, and libraries), the Java bytecode (the compiled, executable format), and the Java Virtual Machine (the runtime system that executes bytecode). Note that the language syntax is actually the least important aspect of the Java Platform. Other language syntaxes (e.g., Groovy, JRuby, JPython) can be used to write Java bytecode applications that execute in the JVM.

In order to qualify as a Java-compatible platform, a platform must implement all three of these legs as required by the Java SE or Java ME specifications. (I'm leaving Java EE out of this because it’s not germane to this discussion.) If a software distribution does not depend on or implement all three legs of the stool (APIs, bytecode, and virtual machine) then it’s not a Java Platform – it’s a fork. 

Android uses the Java programming language and some of the Java ME and SE APIs, but it uses a different executable format (i.e., not bytecode) and a different virtual machine (i.e., not a JVM). You cannot take Java bytecode generated using a Java ME or Java SE environment and execute it on Android. Therefore it is a fork. That is not a value statement; it’s a fact. Perhaps "fork" is an overloaded term these days. If there is a better word for implementing some, but not all, of the required parts of a software platform – any platform - then please tell me.            

Compatibility vs. Fragmentation
Java compatibility is very different from Java fragmentation, but the differences are subtle enough to confuse anybody.  The primary value proposition of Java is “write once, run anywhere.” Sun Microsystems and the JCP attempt to fulfill this value proposition through compatibility testing. When a vendor (commercial or open source) implements a Java standard, they have to submit their implementation to compatibility testing if they want to use the brand and say that the product is compatible. This is the role of the TCK, which is a required part of any JCP Java standard.  Android, which uses only a subset of the Java ME and SE APIs, and is compiled into something other than Java bytecode and does not run on a JVM, is incompatible with both Java ME and Java SE. 

Fragmentation is different. Fragmentation refers to what specific set of APIs a developer can realistically expect to find in any compatible implementation of a platform. Java ME, for example, is fragmented and the reason for that is the plethora of optional APIs defined by the JCP. A Java ME-compatible platform is required to implement the core Java ME APIs, but optional APIs are – well, optional. Vendors (device manufacturers and mobile network operators) are free to implement whatever optional APIs they wish and still be Java ME compliant. (They are also free to implement proprietary APIs unique to a specific device or provider.) The result is that applications that depend on optional APIs only work on devices that support those APIs. Sadly, so much of Java ME is optional that it makes it difficult to write an application that can run on any mobile device. But that is a different problem from compatibility. For example, RIM provides a compatible Java ME implementation for BlackBerry. The BlackBerry implementation passes the compatibility tests – no problem. But, Blackberry supports a subset of the optional APIs, plus it provides a bunch of proprietary APIs. A Java ME application that uses an optional API not supported by BlackBerry devices won’t run on a BlackBerry. Also an application written that uses a proprietary BlackBerry API won’t run on any other device. 

It turns out that the API fragmentation exemplified by the Java ME platform is just as bad for the Java platform as incompatibility. Microsoft is not only happy about Android’s incompatibility with Java ME and Java SE, it’s been extremely thrilled about the API fragmentation already found in Java ME. There is another major difference between compatibility and fragmentation: Fragmentation can be fixed within the Java Community Process (JCP) by defining umbrella specifications.  For example, the new Mobile System Architecture (MSA) is a Java ME umbrella specification that requires implementation of specific optional APIs in order to be compatible. That helps but it’s not silver bullet. Intentional incompatibility, on the other hand, cannot be addressed by the JCP. If a vendor, such as Google, wants to create a product that is non-compatible it can do so— it just can’t use the platform name (i.e. Java ME or Java SE) to describe the product.  Google doesn’t use the brands Java ME or Java SE; it calls its platform Android. It’s a non-compatible implementation of Java.

Is Android detrimental to Java ME and SE, and does that make Android evil?
I'm not saying that Java is some kind of holy ground and that competition with the Java platform is bad. Android is not bad like world hunger is bad. It's just not good for the Java ME and Java SE standards. The reason is simple: Android establishes a precedent that's at odds with the Java platform’s fundamental value proposition: Write once, run everywhere.  Android, because it’s neither Java ME nor Java SE, establishes a precedent for implementing platforms that use the Java programming language any way you please rather than according to the standards set by the Java Community Process. This has implications that go far beyond Java ME.

My main thesis is this: If Android succeeds as it is currently defined then the entire Java platform, including Java SE, is in trouble. Android's success sends a clear message: Standardization of Java is not important; Write once, run anywhere is not important. That's the antithesis of what the Java platform is all about. Android is not bad like world hunger is bad, it’s just not good for existing Java standards.

While Android may not be good for the Java ME and Java SE standards its impact over all could be very positive for the Java industry. Android will force Sun and the JCP to reconsider the Java ME and Java SE standards. It may even force the development of a new platform that is slimmer  than Java SE but not fractured like Java ME. That could be a big win for the Java industry in general. However, until that time, Android adds more meat to the confusing pot that is Java on mobile devices. This can only benefit competing mobile platforms such as Microsoft Windows Mobile.

Android also sets a precedent that is seriously detrimental to the Java Community Process. It asserts that creating non-compatible implementations, forks if you will, is a viable business model. If other vendors pursue this same strategy, the JCP’s ability to enforce compatibility and standards will diminish. Over time the JCP could be rendered completely irrelevant.  This too is a benefit to Microsoft and other vendors and platforms that compete with Java. Today, one of the Java industry’s most important competitive weapon against Microsoft .NET is the use of a standardization process (i.e. JCP) which enforces compatibility.  Without that, the Java industry is unified around nothing and becomes a mob of proprietary implementations rather than industry founded on a set of standards. Microsoft can compete much more effectively against a mob of proprietary products than it can against a unified group of vendors.

Update: Ed Burnett has posted another rebuttal to this post. You can read it here - he makes a lot of good points and its worth reading. Thanks, Ed!