As an example of this lets look at REST (as implemented by HTTP) and SIP, now REST lays down a bunch of constraints and has its HTTP implementation as the way to do everything. HTTP is of course limited in what it can achieve and certain tasks it just doesn't seem to be the right way to go, VOIP being one example, now SIP provides some similar elements in terms of philosophy of simplification (which is nice) but enables multiple protocol interaction and can (in theory) support application to application communication.
Now I've been looking at it and I'm not sure why you couldn't use SIP as a boot strap before electing to use HTTP, VOIP, Video or something else for communication between applications and from applications to people. After all wouldn't it be nice for the application to send you an SMS when something changes rather than polling a web server? These people talk about using SIP to kick off VoiceXML as a reasonable approach today, and VoiceXML is an HTTP based standard.
This would of course mean that HTTP, and potentially REST, would be relegated to specific application problems with an increased requirement for sophistication around the actual mode of interaction between systems and between systems and users.
The real point here is that no one technology will ever remain for ever as the pinnacle of achievement. It is either replaced (e.g. CORBA to Web Services) or commoditised (e.g. TCP to HTTP) and in both cases it ceases to be the cutting edge of IT delivery.
Will SIP relegate HTTP to "one" of the options? Who knows. But what I do know is that backing HTTP to be the cutting edge of IT delivery for the next 20 years is on a hiding to nothing.
Technorati Tags: SOA, Service Architecture
3 comments:
Interesting post. However in my opinion your making some weird assumptions.
First off your comparing REST vs. SIP where you should be comparing SIP vs. HTTP. And while REST is an architectural style that uses HTTP, it is not the HTTP technology in it self.
HTTP dates back to what, 1989? It can hardly be refereed to as "the cutting edge of IT delivery" it is merely the accepted standard as of now.
Also please note that the protocols have different targets for their implementation. HTTP is designed to be a stateless client-to-server protocol where many users read from a single server. SIP is a peer-to-peer protocol, and while Peer-to-peer technology is seeing wide spread use over the Web (or the global IP network depending on your definition of the Web). Not many Peer-to-peer solutions are implemented using HTTP.
It is true that the REST architecture is being increasingly used. However this does not mean that it is "the cutting edge" of technology. It merely means that it has reached the "early majority" of adopters.
I actually was comparing HTTP (as in the implementation for REST) with SIP. HTTP, now constrained by REST, isn't the same as the 1989 version.
Whether REST/HTTP is cutting edge or "early majority" isn't important. The important bit is that the technology will not remain static and there will be something else that either builds on HTTP as a base or replaces it. If you look at SIP and HTTP they clearly do different things... which means...
NEITHER are the final answer.
This is an interesting post. I was having a kind of a similar thought.
as REST is relying on the HTTP/HTTPS protocol implementation as the messages conveyance mechanisms which has the effect of generalizing HTTP as a communication medium for attaining SOA.
Provided the similarity of protocol structure between SIP and HTTP and the added functionality of peer to peer and session awareness to SIP, then we could also think of the possibility of employing SIP as being the communication protocol for service-oriented implementation of services.
One day may be we could see that comes on a real basis, I do actually anticipate a lot of added benefits of highlighting the generic nature of SIP as an SOA backbone, especially in the imminent coupling between IT and Telecomm realms.
Post a Comment