Rajith’s Column

Mark Baker has hung up his boots on the REST vs SOAP debate. I appreciate his effort in building awareness about the value of REST and convincing people that it provides a solid basis for designing distributed systems. In the same post, Mark also says that, “The war really has been won”. Other REST folks including Stefan Tilkov says more or less the same thing too. I don’t know. In my humble opinion, a few years from now when the systems we design/build today using a RESTful, WS-* (or whatever) approach will show us which approach yields the better result in terms of scalability, extensibility, reliability, interoperability, flexibility, versioning, reusability ..etc. Sure the REST folks would say the web has being there for a while now and it works. But usually there is a human on the other side that drives the interaction. So it remains to be seen whether it will be the same with application-to-application interactions as well.
After all the hype surrounding REST,WS-* etc.. dies out and when people have enough experience building real world applications using both approaches and realizes the advantages and disadvantages of each approach there will be less debate as to which is better, or whether we need both approaches ..etc. The answers to these questions will become more clear to the ordinary folks in time. I for one will have an open mind and is very interested to see the outcome of all of this.

The REST vs SOAP debate has been more emotional/religious and less technical as of late. Several folks burned bridges due to insidious remarks, inflammatory comments and even personal attacks. Irrespective of the technical merits one should be able to tolerate/appreciate differences of opinions and debate in a more disciplined manner than resorting to personal attacks or inflammatory comments. Even if you are the most intelligent person in the world it doesn’t matter if you can’t put forward your technical arguments without degrading your own self by making inflammatory comments or personal attacks.

To me the value of Roy Fielding’s dissertation goes beyond REST. Steve Vinoksi summarised it very well in one of his comments while answering a comment I made on his blog.

It’s(Roy’s dissertation) not really primarily about REST; rather, it’s about principled design. Much of his dissertation is about architectural elements, principles, constraints, properties, and the relationships between them all. REST is used as a very clear example in chapter 5 of what principled design is all about.

Why can’t we use a principled design approach when we do SOA or for that matter any other architecture?

When we add contraints or relax constraints we induce certain properties in our architecture. As an architect you make an educated desision as to what constraints make sense in your environment and what doesn’t. When designing systems don’t we go through decisions like “should we make these services stateless or statefull ..etc” during our design meetings ?

I think in what ever system you design as an architect you should think through and note down the constraints you want to impose on your system. This will provide a proper foundation to your system and an excellent guideline to your developers which will clearly communicate the desired goals of your system. Then later on when somebody else wants to relax any of these constraints or add more constraints they already have a guideline and can see how the “relaxing of an existing constraint” or the “addition of a new constraint” can impact the overall system.

REST is just a name coined by Roy to identify a set of constraints, and they are not the only constraints, nor the best combination of constraints in every situation. As Steve mentioned Roy spends the first few chapters providing an excellent analysis about “architectural elements, principles, constraints, properties, and the relationships between them all” and of course the value of a principled design approach.
To me the value of Roy’s thesis goes beyond REST and I hope most people would realize the same.

Axis2 1.3 release has experimental clustering support enabling you to deploy your services in a cluster for Scalability, Failover support and HA. In simple terms, we provide replication for Service Context, Service Group Context and ConfigurationContext. This enables you to deploy your services in a cluster and share state. Please give it a spin and provide feedback via the mailing lists.
Please check the Axis2 Clustering Guide for a good introduction.

In Summary, here are a few points worth remembering

• For Stateful Web Services it is recommended to deploy in pairs using the primary/secondary model. i.e Each Node will replicate to one or more backups (secondary nodes) for failover.
• There will be only one active node at any given time. This is to avoid conflicts as we don’t have a distributed locking mechanism.
• To achieve Scalability, you need to deploy several of these pairs. In other words your cluster will consist of multiple pairs with one active node in each - and your pairs are isolated sub groups with no replication between them.
• If your cluster consists of more than one pair, you need to use some sort of partitioning to avoid a user being serviced by more than one pair within a given session in order to avoid potential conflicts. You could use session affinity to achieve this.
• There is no such restriction for Stateless Web Services.
• If your Services read shared state more frequently and update very rarely, you could experiment with more than one active node. However conflicts are still possible.

Sanjiva asked me to help over a year ago and it got postponed month after month due to other commitments until I was finally able to produce a prototype. Many thanks to Afkam Azeez, Chamikara, Snajay and Sanjiva for the support they provided. Azeez and Chamikara was primarily responsible for bringing the clustering support to it’s current state after I contributed an initial implementation. If not for those two it would have been next to impossible to get it included in the release. Special thanks to Philip Hanik for answering questions on Apache Tribes even while on vacation.

In Dans blog entry, he compares SCA vs Spring with an excellent example which highlights the similarities.

I do not view them as competing technologies rather complementing as I see some synergy between these technologies.

Clearly SCA and Spring share several design principles and it is no surprise that the SCA spec group views Spring as an implementation technology for components and composites. In fact the SCA spec group has gone as far as formalizing this approach with SCA Spring Component Implementation Specification

So Ke Jin’s comment on InfoQ was right on the money when he said,

“As the matter of fact, the so-called SCA assembly model is merely a DSL (domain specific language) that can easily be realized on top of Spring or any decent POJO IoC containers, with few hundreds lines of code and half day of work”

On his InfoQ comment, Dan asks?

But why wouldn’t I just use Spring to begin with?

The simple answer is that SCA could become a standard and the ability to deploy my composites in any SCA runtime. The other SCA runtime could be using Spring or the next great thing under the covers.

Mike Edwards points out on the same InfoQ thread

What the SCA Assembly model then brings to the party is a organized and standard way of describing how the different components in your (distributed) system are linked together to build a particular application.

This will only add value if and when SCA becomes a standard through OASIS and is adopted across different languages by the masses. Spring is great and I really like it. However distributed systems are not built only using java. It would be nice if we have a standard way of expressing how different components are linked together to build your application.

Also unlike the EJB’s if SCA composites can be truly portable across different runtimes (Ex Tuscany java runtime to ABC java runtime) with zero code changes it can be a very good selling point. Vendors shouldn’t spoil the party with vendor specific addons in their runtime which can lock-in unsuspecting users.

Dan asked

Someone show me where Ke Jin is wrong and where SCA expands on Spring capabilties.

Technically the capabilities are more or less the same, albeit spring being a more simple model. The standardization and portability of SCA (if achieved) is where it can exapnd or add value on top of Spring. I am not advocating to replace Spring with SCA. You can continue to use Spring to realize SCA. They are certainly complementary. This white paper explains how SCA can be used with OSGi and Spring.

P.S I conveniently ignored the complexity issue. IMHO it is a red herring.
Distributed systems are complex in nature. Thinking we can provide simple solutions is the biggest misconception.
EJB, WS-*, REST, SCA they all prove this one after the other. That’s a good topic for my next blog entry

It is surprising that many people still think of Web Services as a Distributed Object access architecture like CORBA or COM.

This is quoted from the post by Leonard Richardson http://www.crummy.com/writing/REST-Web-Services/

“The answer is that “Web Services” aren’t the web. They’re a heavyweight architecture for distributed object access, like COM and CORBA”

This is very misleading. Web Services is *NOT* a distributed object architecture.
WS is not object centric and has no notion of an object reference or distributed garbage collection.

So it is wrong to say *LIKE* CORBA or COM

I wrote a Case Study for Synapse and it’s available here