The Growing of REST

Here I try to give my point of view on why REST is gaining a lot of traction against SOAP in the Webservices world.

First, I have to explain that REST is an architectural style while SOAP-based WS are just a way to implement RPC, which is the most basic inter-communication style. Even Corba one day went to the point of being very mature an stable, but how many new projects are now started with it? A technology should demonstrate itself within a reasonable time window, otherwise people get tired. My first SOAP implementation, I think it was 2000, was with Axis's ancestor Apache SOAP: I still feel the headache.

My opinion is that most self-proclaimed RESTful implementations are not really so, because REST is not just XML over HTTP (it can use JSON, plain text, Atom, binary streams, or a combination of all) but it is a way to implement an Object-Oriented architectural approach on top of Web resources (the data is the resource itself, the methods are the HTTP operations get, put, post delete, etc...). SOAP WS instead, as said, is plain, old RPC and it does not mandate to use HTTP only, but also works with other protocols such as JMS, etc.

Now I hope we agree programming languages evolved from procedural to OO, so I'd say the REST paradigm is more modern than RPC one, but we know that good OO is actually harder than procedural (and I mean good OO). So, IMHO, the traction REST is gaining is not due to the fact that it is conceptually simpler (as OO is not, if compared to procedural programming) but instead to the fact that REST is based on a simpler implementation, robust protocol (HTTP), few consistent operations (HTTP methods), a proven architecture (The World Wide Web, not a tiny one really...), a set of extremely tested technologies (Web servers, Web proxy and caches) and a long track of true interoperability and security (again, the WWW and SSL). Honestly I am very happy that I still access my on-line banking through HTTP + SSL and not any WS-Security......

Resource Oriented Architecture, implemented through REST, is actually conceptually harder than RPC style for the same reasons that proper Object Oriented modelling is conceptually harder than plain procedural programming. But a lot more rewarding, if we compare the final outcomes. And that's why, by the way, also good stuff like Spring is gaining a lot of traction: it allows to model a real domain through POJOs.

Maybe I am too old, because in this procedural world of SOAP and EJB (yes, EJB specs before version 3 forced a procedural programming style) I still persist thinking that Object Orientation should be the way to model business domains properly: I learned that many years ago and still nothing has been able to change my mind. Of course, integration often demands for a simpler paradigm than OO: probably scripting will happily rule here (IFL and Fuji anyone?).

My opinion is that the WSDL + WS-* combination, regardless of all the efforts, is still a way too complex, real interoperability is still questionable and security is largely unproven, if compared with plain, old HTTPS and its some billions of daily Web transactions. However, I agree things are improving, but while I'm at customer site I'd love not to spend days resolving WSDL and WS-* quirks and instead focus my attention to more added-value activities....

More simplicity quite usually equates to more security.

A Java CAPS Custom Security Provider Enablement

Recently I had to enable a Java custom security provider implemented by a customer. The implementation is based on a set of JAR files included into Java Collaborations, providing some special signing and hashing security features.
To have that libraries working I just had to add few lines to the server.policy file, which resides into:

logicalhost\is\domains\domain1\config

being domain1 my target domain. The JAR files were put into

logicalhost\is\domains\domain1\lib\ext

Below the additional permissions fragment:

// Basic set of required permissions granted to all remaining code
grant {
    ...
    // Java CAPS needs these permissions so that the Bouncy Castle provider can be used
    permission java.security.SecurityPermission "insertProvider.BC";
    permission java.security.SecurityPermission "removeProvider.BC";
    permission java.security.SecurityPermission "putProviderProperty.BC";
    
    //----------------------------------------------------------------------------
    //  "InnoSec" custom security provider
    //----------------------------------------------------------------------------
    permission java.security.SecurityPermission "insertProvider.InnoSec";
    permission java.security.SecurityPermission "removeProvider.InnoSec";
    permission java.security.SecurityPermission "putProviderProperty.InnoSec";
    //----------------------------------------------------------------------------
    ...