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.