The summary of a new report by Light Reading titled Telco Web 2.0 Mashups: A New Blueprint for Service Creation makes me think of the Beatles v. Stones battle.
Obviously, in the 60's the Beatles and the Rolling Stones were foes to death, and history can tell that only one of these two bands was great. Which one?
The report apparently highlights the need for operators to rapidly embrace a web services and service mashups approach. Fine, I totally agree with this.
My problem is when IMS and SIP are presented as an alternative to this approach. In this report this is clearly the bad one, as everybody knows that you cannot implement both web services and SIP/IMS and combine the two for an optimal usage.
When will the industry stop looking for the silver bullet? The unique technical solution, the unique business model that will answer all problems?
A core thesis I am trying to develop in this blog is that SOA/web services and IMS/SIP can be combined together to form a new paradigm (User Oriented Architecture) which, like the bands cited above would be more than the sum of its parts.
Another summary of the report cites JAIN SLEE as the service creation/execution environment in the context of IMS. I like JAIN SLEE and I think it can play an interesting role in IMS and across IMS and other networks.
However, it would be more interesting if the summary mentioned Java EE (J2EE) as well, as it could show that the Web Services / SIP picture is not that black and white. J2EE platforms fit very well in a web services world and I know at least three of the main J2EE platform suppliers which include SIP servlet support at the core of their platform. This means that there exist on the market platforms that can be used to implement services that are both web services and SIP/IMS centric. Unless of course this is strictly forbidden by both IMS and Web Services purists (I already had the opportunity to write about the artificial separation between IMS and Web Services chapels).
Why should the telecom industry just follow the steps of Internet companies and not try to bring its own contribution to the future, by integrating and enriching what exists today?
Christophe
Subscribe to:
Post Comments (Atom)
Stumble It!
6 comments:
The competition between the Beatles and the Stones was a media contrived battle. They were in fact friends and associates who wisely timed the release of their records so as not to interfere with each other. "I Want to be Your Man" written by Lennon/McCartney" was a hit for the Stones. Jagger appeared on lots of recordings and videos with the Beatles. Lennon appeared in a jam with Richards in the Stones' Rock & Roll Circus.
Hi Jack,
This is why I used this comparison.
I am pretty sure that the anti-IMS stance in the summaries I linked to might be a similar media circus made to promote the report.
And I think that web services and SIP, SOA and IMS, could be the best buddies if they knew each other a little better.
Christophe
Hey Christophe, Thank for this great blog
Actually, I understand that the Telco companies hesitate to just expose their network capabilities(presence, location enablers) and to open theirs subscribers profiles for the IT or Web 2.0 companies (Google, Yahoo ...)
On the other hand, the Telco companies manage to have access to third parties and to web services via the OSA/PARLAY gateways; so it seems to be unfair to think that they don't want to cooperate with the IT world.
Another thing, The IMS is based on SIP, so it's normal to give priority to develop SIP applications.
Also, the big technical problem in my point of view is the clear definition of a SCIM or service broker which is the only entity that could help integrating IT and Telco applications together and provide blended services.
Can you give me your feedback on this thoughts.
Thanks a lot
Sofiene
Hi Sofiene,
The point I wanted to make was that I hate this approach which basically says that if you want to be part of the web services and service mashup buzz, you have to get rid of your IMS-related plans, and vice versa.
I believe that the way to go is both in the web services direction (as a supplier of web services to 3rd parties and as a consumer of 3rd party web services) and in the advanced IMS/SIP one, with applications whose implementation combines both the usage of web services and SIP.
I think that most operators are interested in using and exposing web services.
However, I see two important limitations, that are related and that IMS can help solving.
First, this is one thing to expose web services, and this is another to expose web services of interest to 3rd parties. I am sorry to say this, but in a pre-IMS world, telecom operators have very few interesting capabilities to expose to 3rd parties.
IMS can totally change this situation, as in an advanced IMS world, every new application deployed in an AS or installed in a client can lead to new service capabilities.
This leads to the second issue. If you really adopt the web services and service mashup philosophy, you rapidly understand that it is a nonsense to go through a long standardization process for each and every web service you want to expose.
If you browse through past posts, you will see some on the SCIM as well as how I see an optimal application layer.
I still have a lot to say on this and I have material for still some time. Come back.
Christophe
I also think there is a missunderstanding in what is specific to web and real-time communication. I believe most of those attacking IMS believe that the future/money is only in data/content services with (low-cost) web technologies. But if you start thinking about mixing real-time communication aspects with data/content, then an IMS approach combine with web principles makes sense. If you only intend to publish a blog, pictures and link it with a map, you don't need IMS.
On the other hand, if you see value in better connecting all the telco subscribers (IMS users) between themselves and augment the experience through "web type" of services while provide a good user experience through a good integration between web services and IMS (i.e. mashup content with real-time communication) it makes much more sense.
The question is how fast and well this can be achieved.
Hi Emanuel,
I agree that one of the great added values of IMS is its ability to combine data/content and person to person communication.
IMS is also a great means to share a data/content experience simultaneously between several users (whether communication happens between them or not, but more often than not it will take place).
My next "service pattern " post will address specifically this issue. It should come in the following weeks.
As for the time it will take, it might depend how long it takes for me to become the telecom industry illuminated dictator.
Seriously, it is hard to tell. I think that the hypothetical progression towards an innovative IMS application layer could well be governed by successive hops, as one operator (or Internet company) deploys a disruptive service, and then the whole industry aligns, until the next hop.
To some extent, a service like Videosharing (unidirectional stream of a video over IMS during a circuit-switched voice call) was such an early hop, as it showed that some IMS services could rely essentially on client-centric logic.
Also, a key aspect concerning the pace of evolution is in the understanding of the industry about how much standardization is too much. There must be a newfound balance between standardization and differentiation, which at the moment does not fit very well with the telecom culture.
Christophe
Post a Comment