Two weeks ago I presented at Oredev - a regional developer conference hosted in Malmo, Sweden. The great thing about small conferences like Oredev is that the organizers go out of their way to make it a great experience for everyone. Meetings were well coordinated and the hospitality was remarkable.
The talk I presented was "Voice Mail service with JSLEE, SIP and RTP". The title did not represent the main theme of the talk, but it helped gather an audience which was interested in VoIP and Java. The talk was about converged applications and new market opportunities. It was about writing and deploying scalable applications, which handle web, voice signaling and media.
It was interesting to see a big part of the audience being familiar with VoIP development. A year ago at JavaPolis, about 20% of the people at my presentation, had VoIP hands on experience. At Oredev the percentage was 50!
The questions I was asked last year were more often about the feasibility of transitioning from legacy telco systems to standard development environment. This time around the majority of questions were targeted at the details of the JSLEE programming model. Most developers were familiar with the VoIP protocols and they were interested to learn how to build scalable applications. There was also a good bit of interest in the new market opportunities.
The slides of my Oredev presentation as well as the source code for the demo are available for download.
Saturday, December 02, 2006
Wednesday, September 27, 2006
IT Vendors vs. NEPs - Round 2.0
IMS Insider raises a flag that many should have seen coming by now. Recommended read. Another variable worth considering in the equation is Open Source Service Delivery Platforms. Shouldn't a Red Hat/JBoss SDP be added to the list of IT vendor offerings?
If IT vendors can get telco platforms right, and we know from recent history that Open Source can get enterprise platforms right, one would think that Open Source will make a major appearence with a telco platform...
The top IT vendors are certainly strong enough to battle head to head with NEPs and eventually win... if NEPs accept such fight. But what if ... instead of fighting head on with IT, NEPs partner up with Open Source vendors to get up to speed with a common Open Source Open Standards platform and find ways to add value in places where they are traditionally strong - telco applications. In this hyptothetical scenario, NEPs will quickly secure viable infrastructure at a minimal cost and will have all the time and money saved to apply to strengthening their portfolio of Telco 2.0 applications. They already have a wide business moat with building custom applications and partnering with open source vendors will help them grow it further.
If IT vendors can get telco platforms right, and we know from recent history that Open Source can get enterprise platforms right, one would think that Open Source will make a major appearence with a telco platform...
The top IT vendors are certainly strong enough to battle head to head with NEPs and eventually win... if NEPs accept such fight. But what if ... instead of fighting head on with IT, NEPs partner up with Open Source vendors to get up to speed with a common Open Source Open Standards platform and find ways to add value in places where they are traditionally strong - telco applications. In this hyptothetical scenario, NEPs will quickly secure viable infrastructure at a minimal cost and will have all the time and money saved to apply to strengthening their portfolio of Telco 2.0 applications. They already have a wide business moat with building custom applications and partnering with open source vendors will help them grow it further.
Wednesday, June 07, 2006
Another good day for Open Source and IMS
HP and Atos Origin jointly released to Open Source an IMS testing tool called Seagull (http://gull.sourceforge.net/). It continues the legacy of the successful sipp, which has proven valuable for SIP compliance testing and benchmarking.
Seagull is an extensible tool with immediate support for key IMS protocols such as Diameter, XCAP, and TCAP.
This is a very exciting development, because it will accelerate interoperability between IMS component vendors. I am hopefull that a critical mass of community support will build up around it to ensure long term viability of the project and a growing library of IMS testing plug-ins.
Seagull is an extensible tool with immediate support for key IMS protocols such as Diameter, XCAP, and TCAP.
This is a very exciting development, because it will accelerate interoperability between IMS component vendors. I am hopefull that a critical mass of community support will build up around it to ensure long term viability of the project and a growing library of IMS testing plug-ins.
Tuesday, May 23, 2006
Standardization out of the box
Most people that have been involved in a standardization process via formal body will likely cringe when you ask them about the experience. Its slow, its political, its just painful...but is it worth it? In my experience - Yes, it is, because it grows the market and enables economies of scale among other good reasons. Only if it wasn't so painful...
I haven't blogged in a couple months, but I am excited about something great that happened recently. It might be a new magic formula for accelerated standardization.
Some context first.
As you know, JSLEE is one of my favorite topics. One of the biggest strengths of JSLEE is its well defined extension mechanism, fomally called JSLEE Resource Adaptor architecture. It clearly draws the line between the core JSLEE Event Driven Architecture (EDA) and higher layers of abstraction that bridge external communications protocols (such as SIP, XMPP, H.323, etc.) with JSLEE applications.
It has taken a good 5 years for the JSLEE expert group to design JSLEE 1.0 and another couple years for JSLEE 1.1. The result is a robust core specification for next generation communications services.
This is great, but JSLEE applications cannot be deployed in production unless there are Resource Adaptors available to connect them with the rest of the world. A simple application such as voice mail requires several APIs for external resources. One is call setup protocol such as SIP or Jingle. Another API is needed for client authentication. Some kind of accounting or billing interface are often needed as well. Of course a media streaming feature to enable automated voice interaction is also required.
Each one of the required APIs corresponds to a different external type of resource. The SIP API requires implementation of the SIP signaling protocol to allow the phone to locate and establish a point to point session with the service. Authentication, authorization and accounting are likely to be handled via Diameter, which is a specialized AAA IP protocol. The encoded audio stream will likely be handled via Real-Time Protocol (RTP).
Based on this information we can roughly come up with the need for 3 Resource Adaptors - SIP RA, Diameter RA and RTP RA.
If a simple Voice Mail application demands 3 RAs, what about more sophisticated ones like IPTV, video conferencing, or location aware tour guide?
Going back to the topic of standardization.
The RA architecture allows JSLEE to be very successful, but in order for this to actually happen, there needs to be a follow up process that allows quick standardization of RAs driven by market demand.
It has become apparent that going through a formal standardization process takes 3 to 5 years. This is obviously unacceptable for the case in point.
What is a solution then?...Well it turns out that the main ingredients required are vendor synergy and an independent public forum.
It also helps that the RA architecture has 2 characteristics, which make things easier.
First, it distinguishes the concepts of RA Type and RA Implementation. An RA Type specifies Java interfaces, deployment descriptors and semantic behaviour of an RA, but it leaves to the implementation a lot of freedom to deal with external and system resource management. While an RA Type gives the application developer a piece of mind that applications are portable across different vendor products, an RA Implementation can be a significant competitive differentiator between vendors. At the end of the day the user can choose best of breed implementation for the reality of their production environment without having to rewrite code.
The second feature of the RA architecture is that it natively supports versioning of RA Types. This allows RA Types to be released frequently with incremental improvements without compromising the investments made in applications written for earlier versions.
With all the stars aligned, it took just a few days for the major JSLEE vendors to discuss and agree that RA Type standardization is a necessesity and we all need a quick process with minimum overhead to deliver results. We found that a great independent public authority is no other than the java.net Communications Community.
A few days later, we had an engaged, unfiltered, raw technical discussion in full steam.
Check out the public discussion forum yourself:
JSLEE Resource Adaptor Types
Also, see the official announcement we made to the JAIN-SLEE-INTEREST list:
JSLEE Resource Adaptor Standardization Effort
Eventually Open Source RA Types developed in the community will be submitted to a proper standards body like the JCP, but in the meanwhile we will have de-facto standardization at the speed demanded by users...
Isn't this something.
I haven't blogged in a couple months, but I am excited about something great that happened recently. It might be a new magic formula for accelerated standardization.
Some context first.
As you know, JSLEE is one of my favorite topics. One of the biggest strengths of JSLEE is its well defined extension mechanism, fomally called JSLEE Resource Adaptor architecture. It clearly draws the line between the core JSLEE Event Driven Architecture (EDA) and higher layers of abstraction that bridge external communications protocols (such as SIP, XMPP, H.323, etc.) with JSLEE applications.
It has taken a good 5 years for the JSLEE expert group to design JSLEE 1.0 and another couple years for JSLEE 1.1. The result is a robust core specification for next generation communications services.
This is great, but JSLEE applications cannot be deployed in production unless there are Resource Adaptors available to connect them with the rest of the world. A simple application such as voice mail requires several APIs for external resources. One is call setup protocol such as SIP or Jingle. Another API is needed for client authentication. Some kind of accounting or billing interface are often needed as well. Of course a media streaming feature to enable automated voice interaction is also required.
Each one of the required APIs corresponds to a different external type of resource. The SIP API requires implementation of the SIP signaling protocol to allow the phone to locate and establish a point to point session with the service. Authentication, authorization and accounting are likely to be handled via Diameter, which is a specialized AAA IP protocol. The encoded audio stream will likely be handled via Real-Time Protocol (RTP).
Based on this information we can roughly come up with the need for 3 Resource Adaptors - SIP RA, Diameter RA and RTP RA.
If a simple Voice Mail application demands 3 RAs, what about more sophisticated ones like IPTV, video conferencing, or location aware tour guide?
Going back to the topic of standardization.
The RA architecture allows JSLEE to be very successful, but in order for this to actually happen, there needs to be a follow up process that allows quick standardization of RAs driven by market demand.
It has become apparent that going through a formal standardization process takes 3 to 5 years. This is obviously unacceptable for the case in point.
What is a solution then?...Well it turns out that the main ingredients required are vendor synergy and an independent public forum.
It also helps that the RA architecture has 2 characteristics, which make things easier.
First, it distinguishes the concepts of RA Type and RA Implementation. An RA Type specifies Java interfaces, deployment descriptors and semantic behaviour of an RA, but it leaves to the implementation a lot of freedom to deal with external and system resource management. While an RA Type gives the application developer a piece of mind that applications are portable across different vendor products, an RA Implementation can be a significant competitive differentiator between vendors. At the end of the day the user can choose best of breed implementation for the reality of their production environment without having to rewrite code.
The second feature of the RA architecture is that it natively supports versioning of RA Types. This allows RA Types to be released frequently with incremental improvements without compromising the investments made in applications written for earlier versions.
With all the stars aligned, it took just a few days for the major JSLEE vendors to discuss and agree that RA Type standardization is a necessesity and we all need a quick process with minimum overhead to deliver results. We found that a great independent public authority is no other than the java.net Communications Community.
A few days later, we had an engaged, unfiltered, raw technical discussion in full steam.
Check out the public discussion forum yourself:
JSLEE Resource Adaptor Types
Also, see the official announcement we made to the JAIN-SLEE-INTEREST list:
JSLEE Resource Adaptor Standardization Effort
Eventually Open Source RA Types developed in the community will be submitted to a proper standards body like the JCP, but in the meanwhile we will have de-facto standardization at the speed demanded by users...
Isn't this something.
Saturday, March 18, 2006
Gartner starts serious coverage of event driven architectures
Gartner published a new research document titled: "Cool Vendors in Platform Middleware, Event-Driven Application Servers, 2006". The paper is written by Massimo Pezzini and Yefim V. Natis. Yefim is a well known researcher in the middleware space.
The abstract reads:
The paper also mentions Mobicents as a viable Open Source alternative for JSLEE containers.
Interestingly this publication came out on March 14, which was the opening day for VON Spring. After my second panel at the VON Open Source Summit, I was aproached by several analysts at other major brands who were starting to cover VoIP middleware.
Coincidence or the beginning of something significant?
The abstract reads:
Event-driven application servers are among the most-innovative evolutions in application platforms. Although still leading-edge technology, several commercial products, such as those from jNETx, OpenCloud and WareLite, are emerging in the market.
The paper also mentions Mobicents as a viable Open Source alternative for JSLEE containers.
Interestingly this publication came out on March 14, which was the opening day for VON Spring. After my second panel at the VON Open Source Summit, I was aproached by several analysts at other major brands who were starting to cover VoIP middleware.
Coincidence or the beginning of something significant?
Friday, February 24, 2006
See you at VON Spring 2006
Last week 3GSM gathered 50'000 visitors in Barcelona. The avalanche of news hasn't settled in yet, but there is yet another big telecom show coming up - VON Spring 2006.
I am fully expecting it to be as big and exciting as ever. This time I will be participating on two panels during the Open Source Summit.
If you are interested to meet and chat with me about Mobicents and Open Source IMS, drop me an email or just come to one of the two sessions.
I am fully expecting it to be as big and exciting as ever. This time I will be participating on two panels during the Open Source Summit.
If you are interested to meet and chat with me about Mobicents and Open Source IMS, drop me an email or just come to one of the two sessions.
Wednesday, February 15, 2006
Gizmo Project and Google Talk are Now Connected!
This is really good news. Interconnection between these two open networks is a big new oportunity for creative service providers.
The world of telephony and enterprise applications is merging
BEA entered the VoIP market about a year ago and delivered astounding results. BEA extended the Web Logic Server with SIP Servlet functionality and accumulated annual sales in the hundreds of millions of dollars.
Oracle decided they won't sit on the sidelines and let this oportunity slip. Oracle is jump starting a VoIP product line by hiring a BEA star executive and acquiring HotSip - a small, but well regarded Sip Servlet vendor.
Oracle decided they won't sit on the sidelines and let this oportunity slip. Oracle is jump starting a VoIP product line by hiring a BEA star executive and acquiring HotSip - a small, but well regarded Sip Servlet vendor.
Tuesday, January 17, 2006
Google Talk opens up for server-to-server federation
Google Talk is acting while other VoIP players are talking. One of the two major barriers that prevented mainstream developers from writing VoIP applications is now removed. Google is bridging the isolated VoIP islands by opening up their GTalk network to server federation.
Server-to-Server Federation instructions on the Google Talk Developers page.
Community reaction on the google-talk-open news group.
There are apparently initial connectivity glitches with some XMPP servers, but they seem minor.
Ivelin
Server-to-Server Federation instructions on the Google Talk Developers page.
Community reaction on the google-talk-open news group.
There are apparently initial connectivity glitches with some XMPP servers, but they seem minor.
Ivelin
Subscribe to:
Posts (Atom)