Next is what ?
Wednesday Oct 28, 2009
Sailfin roadmap on the eve of the release of Sailfin v2
[Read More]
Sailfin roadmap on the eve of the release of Sailfin v2
[Read More]
Sailfin 2.0 is ready to be released now and we have a bunch on new features and enhancements. Sailfin 1.0 was the first release which laid that stage for what Sailfin had to offer in terms on features and value and Sailfin 2.0 takes off from there. Of course, if you simply count the number of features in Sailfin 1.0 and Sailfin 2.0 , the latter may seem like a release with lesser features. Note that Sailfin 1.0 was the first release and we put in a lot of features that were deemed as needed to 'get the bird off the ground'. Now in the next release we have added features that would make it fly faster, farther with lesser number of glitches than ever.
So what's the underlying theme in Sailfin 2.0 ?
The main theme was to provide a truly Highly Available SIP Application Server , remove bottlenecks around UDP and HTTP performance, make Sailfin work reliably on multi-homed machines, provide improved logging and call flow support.
Main feature list
Here is a list of main features that are a part of Sailfin 2.0 release :
• Supporting traffic separation on Sailfin using multi homed machines ( blog)
• Support for improved logging
• Support for tracing SIP calls ( access logging) and SIP Message inspection ( blog)
• Support for High Availability of SIP sessions (blog)
• Support for Rolling Upgrade with High Availability enabled (blog)
• Enhanced DCR features ( blog)
• Enhanced tooling support for Eclipse ( blog)
• Support for a STUN server ( blog)
• Sample for demonstrating HA !
Call for ACTION !!
Go ahead and download the latest build of Sailfin 2.0 which is a Release Candidate build and take it for a spin
The Hard Code Freeze for Sailfin v2.0 development has been reached. What this means is that we stop adding code and fix issues which are a must-fix . Most issues that fall into this category are those which result from Stress test issues and regressions in functionality and boo-boos ( end of the day we are all humans :-) )
The last 6 weeks has seen some hectic activity in testing as well bug fixes. Here is a list of issues that have been fixed and integrated since Soft Code Freeze. In addition the Application Server has also been subjected to Stress Tests lasting upto 169 hours. These tests include tests for testing the behaviour of a clustered setup with Session Replication enabled in the event of a failure.
I will be talking briefly about the value proposition of Java EE and SIP Servlets in developing applications and services for the Telco service providers and then explaining how Sailfin is a fits in this space
SailFin has a better presence that ever before at Java One and Community One this year. Two Java Ones ago , Sailfin was announced. Today we have had one full blown release and we are working towards another big release in October. In addition to the releases, we have an 'Ecosystem' of projects that work with Sailfin that are coming up.
Here are the sessions connected with Sailfin :
• Community One on June 1 @ 10:50 AM . This session explains Sailfin from a developer perspective, and how an ecosystem around Sailfin can be used by developers to create voice enabled applications.Google Cal Event
• Java One on June 4th @ 9:30 AM . This session talks about an easy methodology to develop voice and media enabled applications on Sailfin , without deep diving into SIP Servlets. Google Cal Event
• Java One on June 5th @ 10:30 AM . This session talks about a Converged Application development framework, that works with Sailfin primarily and also with other SIP Application Servers. Google Cal Event
• Java One Hands-On-Lab on June 3rd at 11:40 AM . This is a DIY hands on lab that guides you through developing a Custom Application Router for SIP Application composition in Sailfin. Google Cal Event
The ecosystem projects that I mentioned earlier are :
• JVoiceBridge : which is a Java based media server and media mixer that can be used for audio conferencing.
• SailFin Samples : which is a repository of samples using SIP Servlets, Java EE and other Web 2.0 technologies which run on Sailfin.
Once the annotation is used to define the servlet, then we need to have a mapping for the servlet,which, can be use the main-servlet mechanism or the servlet-mapping mechanism.Ideally if we use the main-servlet mechanism , we need not specify a sip.xml (deployment descriptor ) for defining servlets or servlet-mappings. In other words, if these are the only configuration data to be specified in the sip.xml , then we need not specify the sip.xml and instead use an annotation called @SipApplication to define a set of servlets to belong to an application.
This blog takes the example of an application and explains how @SipServlet annotation can be used alongwith the servlet-mapping mechanism and also explains the use the @SipApplication annotation.
@SipServlet
Lets start with the @SipServlet annotation. Any class which implements javax.servlet.sip.SipServlet and is annotated with @SipServlet is deemed as a Sip Servlet. There are attributes to this annotation that help in defining this Servlet.
name
used to specify the name . In the absence of this attribute the class name ( not he Fully Qualified , but just the plain class name ) is taken as the servlet-name.
applicationName
used to specify the app-name of the application to which this servlet belongs. Typically this is used to associate an annotated Servlet with a particular application. The value of the attribute is the app-name element in the sip.xml or the value of the applicationName attribute in the @SipApplication annotation.
description
Description for the servlet
loadOnStartup
This maps to the load-on-startup element in the sip.xml and specifies the order in which the servlet has to be loaded when the application is starting
All these attributes are optional. Now, lets look at this sample application which has two SIP Servlets, one of which is annotated and the other one is defined in the sip.xml. The annotated servlet has a mapping in the sip.xml.
The snippet below shows the definition of the RegisterServlet defined by an annotation.
| @javax.servlet.sip.annotation.SipServlet public class RegisterServlet extends javax.servlet.sip.SipServlet { |
The snapshot below shows the sip.xml for defining the servlet-mapping for the RegisterServlet.
Since we did not specify the name attribute for the Servlet, the servlet-name used in the mapping is the classname of the SipServlet i.e. RegisterServlet. This servlet will be invoked for all REGISTER requests. Now lets says if we have defined the name attribute in the RegisterServlet, as name="Registrar" then we would need to mention the the servlet-name in the servlet-mapping element as "Registrar".
@SipApplication annotation
Now, lets take a look at how the @SipApplication annotation can be used. This annotation is a package level annotation and is defined in a package-info.java file. The package-info.java looks like this :
@javax.servlet.sip.annotation.SipApplication(
name="AnnotatedApp",
sessionTimeout=30,
distributable=true)
package net.java.servlet;
Note the package definition at the end of the file. This is the package for which this annotation is defined and all Sip Servlets within this package would be part of the SIP Application defined by this annotation. If there are other servlets in other packages that need to be added to this application , then the user needs to specify the name of the application in the applicationName attribute of the @SipServlet annotation. For example,
package com.example;
@SipServlet(applicationName="AnnotatedApp")
public class MySipServlet extends SipServlet {
adds the above defined SIP Servlet to the SIP Application named AnnotatedApp , even though it belongs to another package.
The @SipApplication annotation has the following attributes :
name
states the name of the application
displayName
maps to the < display-name > element in sip.xml
description
maps to the < description > element in sip.xml
distributable
maps to the < distributable > element in sip.xml
smallIcon
maps to the < small-icon > element in sip.xml
largeIcon
maps to the < large-icon > element in sip.xml
proxyTimeout
maps to the < proxy-timeout > element in sip.xml
sessionTimeout
maps to the < session-timeout > element in sip.xml
mainServlet
maps to the < main-servlet > element in sip.xml
The mainServlet element is used to specify a single servlet as the main-servlet and this will be the servlet invoked for all requests and the servlet defined as the main-servlet is responsible for delegating the incoming requests. In case the main-servlet is invoked the servlet-mapping mechanism is not used.
But that calls for another blog post !!
Let me start off by stating the motivation behind this blog. JSR289 has gone through some changes in the way @Resource annotations are used to inject SipFactory, SipSessionsUtil and SipTimer objects into a Sip Servlet or a Java EE components like EJB, HTTP Servlet or an MDB. In the final release , the syntax for doing so has been finalized as
@Resource( name="sip/<app-name>/SipFactory) SipFactory sf;
where app-name is the name of the application whose SipFactory / SipSessionsUtil or SipTimer is to be injected. The app-name is a configuration element which is specified in the deployment descriptor sip.xml.
In case of Sailfin , we also derive the app-name if its not specified in the deployment descriptor. The purpose of this blog is to explain how app-name is treated in Sailfin.
Lets start with the rules first !
• There is an app-name available for each application that is deployed in Sailfin. This is true both for application that correspond to the SIP Servlet v1.1 specification and those which correspond to the SIP Servlet v1.0 specification. • Case I : There is no app-name specified in the sip.xml ( deployment descriptor) 1. In this case the app-name is the name of the archive without the extension. i.e. if the archive is named as foo.sar , then the app-name is derived as foo . 2. If the SIP Application is bundled within a Java EE Enterprise Application, then the app-name is derived as • Case II: There is an app-name specified in the sip.xml ( deployment descriptor) 1. In this case the app-name is taken as it is defined in the sip.xml. This is true for both standalone SIP Applications and SIP Applications bundled within an Enterprise Application. 2. A key assumption made here is that the app-name is not duplicated. • In both these cases the Application Router would use the app-name specified or derived by Sailfin to identify the application. |
Now lets look at a simple example to see how these rules are applied in a simple SIP Application !
Sample 1
The first sample is a Converged SIP Application which injects a SipFactory into a Sip Servlet using @Resource annotation. This sample will be used to show both Case I and Case II for a standalone SIP Application.
The sample has a SIP Servlet which listens to SIP REGISTER requests and creates a SipApplicationSession, using SipFactory. The SipFactory is injected using a @Resource annotation, and is available in the JNDI namespace as follows:
sip/<app-name>/SipFactory
Note that to inject the SipFactory in the SIP Servlet in a standalone SIP Application , we do not need to use the name attribute, since there is only one SipFactory instance available per SIP application.
A look at the JNDI tree ( using the Sailfin Admin Console) show how the SipFactory JNDI name is constructed using either a derived app name ( Case I ) or using the app-name specified in the sip.xml ( Case II)
Case I :
• The JNDI tree : Note the JNDI name of the SipFactory, SipSessionsUtil and SipTimer objects, have the app-name as the name of archive in which the SIP Application is packaged. i.e. ConvergedSipApplication
• The sip.xml : Note that the app-name attribute is missing.
Case II :
• The JNDI tree : Note the JNDI name of the SipFactory, SipSessionsUtil and SipTimer objects, have the app-name as the value of the app-name specified in the sip.xml.
• The sip.xml : Note that the app-name attribute is present and specifies the app-name as ConvergedApp
Sample 2
In this sample, we add the SIP Application developed above, to an Enterprise Application. Hence we have a Converged Enterprise Application , with an EJB module and SIP Application within. The use case here is
• A SIP Servlet listens to REGISTER requests, creates a SipApplicationSession and adds the SipURI received from the UAC as an attribute in the SipApplicationSession.
• An HTTP Servlet would then invoke an EJB , which in turn retrieves the same SipApplicationSession using a key, and then get the attribute that was set in the SIP Servlet. The SipApplicationSession is looked up using a SipSessionsUtil object, an instance of which is injected into the EJB using the @Resource annotation.
Hence as you can see we have an EJB and SIP Application co-located within an Enterprise Application archive and sharing a SipFactory and SipSessionsUtil instance. In the next few steps we see how we use the app-name to get hold of the SipFactory or SipSessionsUtil instance within the EJB.
The app-name used will be dependent on the condition that we have specified the app-name in the sip.xml or not.
Case I
The app-name is not specified in the sip.xml. Hence the app-name is derived from the archive name of the EAR file appended with the archive-name of the SIP Application.
• The JNDI Tree show the JNDI name of the SipFactory, SipSessionsUtil and SipTimer objects.
• The @Resource annotation in the EJB used to inject the SipFactory and/or SipSessionsUtil has the name attribute specified, with value of this attribute being
sip/ConvergedEnterprise/ConvergedSipApplication/SipFactory
| @Stateless public class TalkBackBeanBean implements TalkBackBeanLocal { @Resource(name="sip/ConvergedEnterprise/ConvergedSipApplication/SipFactory") SipFactory sf; @Resource(name="sip/ConvergedEnterprise/ConvergedSipApplication/SipSessionsUtil") SipSessionsUtil ssu; public String findWho() { SipApplicationSession sas = ssu.getApplicationSessionByKey("CSA",false); |
Case II
In this case , the app-name is specified in the sip.xml ( as in the earlier sample) and the value of the app-name element is ConvergedApplication
• The sip.xml snippet shows the app-name being specified.
• The @Resource annotation in the EJB ( TalkBackBean ) uses the app-name specified in the sip.xml as the name attribute.
| @Stateless public class TalkBackBeanBean implements TalkBackBeanLocal { @Resource(name="sip/ConvergedApplication/SipFactory") SipFactory sf; @Resource(name="sip/ConvergedApplication/SipSessionsUtil") SipSessionsUtil ssu; public String findWho() { SipApplicationSession sas = ssu.getApplicationSessionByKey("CSA",false); |
I am attaching sources for the sample applications that I have used in this blog.
• Converged Enterprise Application (Case I) src | binary
• Converged Enterprise Application (Case II) src | binary
If you try it out, build it using NetBeans and deploy it using the Admin Console of Sailfin.
SailFin 1.0 reached another milestone when we passed the JSR289 TCK with build 59. This build is available as the Milestone 6 build and can be downloaded here .
In addition to passing the JSR 289 TCK, there have been additional fixes in the following areas :
• Sip Session Replication
• Converged Load Balancer
• Administration
• Sip Container
• Annotation support
We fixed around 141 issues between Oct 6th and Nov10. Thats quite a number and a big reason why you should try out this Milestone.
In case you want to test Sailfin in a pre-production scenario, this would be a good time, since we have fixed issues that cropped up during longevity runs.
Wikipedia defines Milestone as not only a sign a of distance traveled but also as an indication of the direction being taken.
So , what's the point ?
Sailfin is headed for a General Availability release around 15th of December, and as a step in the direction we have completed adding the additional features needed by JSR289 which were not present in Sailfin 1.0 Alpha.
The API now refers to the Final Release of the JSR 289 . The additional work includes support for
• IWR ( Invalidate when Ready) mechanism for Sip Sessions
• Support for RFC 3891 and RFC 3911
• Support for Application Router Provider mechanism.
• Support for annotations defined by JSR289 ( @SipApplication, @SipApplicationKey, @SipServlet and @SipListener)
• Support for RFC 4474 as defined in the JSR289.
&bull and more ...
Apart from the updates on the JSR289 what's now new and improved is :
• an access log for SIP Messages is now available, which can be configured from the domain.xml (under sip-service)
• SIP and HTTP Session replication , which now moves to a beta quality state, from an alpha quality that it was in August and CLB ( Converged Load Balancer)
• support for a 6 instance cluster using a 32 bit JVM. New improved Shoal bits.
Where can one get all these and more ?
Milestone 5 !!
Sailfin 1.0 b54 is the build that signifies that we have reached another Milestone and that would be Milestone 5 following our numbering convention so far ...
Download MS5
Try it
Find Issues ? File Issues !!
Questions and Feedback ? dev@sailfin.dev.java.net is the address to direct all of these.

What constitutes this Alpha release ?
This release has all the features that were there in the MS4. These features have been tested functionally and key issues have been fixed. In addition tests have been run on Sailfin in a multi-instance cluster setup for a 7 days in a row and issues uncovered were fixed.
In short, modules like
• Administration
• Deployment
• Monitoring
• SIP Network Manager
• SIP Container
are more robust and stable now. The focus on the SIP Network Manager has been on the TCP side.
JSR 289 was approved a month ago and we are working on making the SIP Servlet Container compliant with JSR289. Its still work in progress and the work is happening as I type !
Other features which are available but are of an Alpha quality are
• High Availability ( SIP and HTTP Session Replication )
• Converged Load Balancer
• Application Router ( With a facility to deploy a custom Application Router)
• OverLoadProtection for SIP Container
It would be good to have your feedback and / or issues on all these features and Sailfin in general. BTW, we have a new look for the download page as well !
Sailfin hit MS4 early in April ! We could have called it the "Spring Milestone" after the last milestone was released in "Winter" around Christmas. We called it MS4 instead following the convention.
Yes its been a while since we put up a milestone, however there is a reason for that happening that way !
The main additions in this Milestone can be found here
In terms of features, this milestone was more of a top-up . However there has been a significant value add in terms of testing, both functional as well as system testing. While the product has still not undergone all the stress that we expect to subject it to , its looking better than ever before on that front.
Given that and some quaility issues that we saw in the product, it made a lot of sense to put out a milestone release now and have a beta later on.We are now planning for a beta in Summer and we will keep the community posted !
Looking forward to the testing , feedback and inputs from the community!
SailFin blogs has had quite a few entries around CLB, Application Router and DNS .
SailFin also features at Java One this year - there is a HandOn Lab that showcase how a converged application can be developed using NetBeans and SailFin and there is a technical session that talks about the architecture of SailFin. There is also another HandsOn Lab that
talks about performance tuning !

We hit Milestone 3 on Dec 10th 2007, and a certified binary corresponding to the Milestone 3 features has been made available since Dec 22nd.
So what does a certified binary mean ?
Typically a certified binary has has series of regression tests, sanity tests run. These tests validate the basic container level features such as that of the SIP Container, EJB Container, Web Container. In addition that the Java EE TCKs are run to make sure that the Application Server remains compliant to the Java EE spec. In case of the Milestone builds of Sailfin, key functional tests corresponding to the new features are also used to certify the builds. This helps us isolate the known issues in these new features and also to propose workarounds.
What's new in MS3 ?
The main features that got delivered in this Milestone are in the areas of Deployment, Administration and Monitoring of the SIP Container, CLB (Converged Load Balancer), Security .There were also features in Session replication that are available now, but the plan is that Session Replication is expected to be completed only by Jan 21st 2007. Here is a list of features with some details.
Support for Annotations in JSR289 Annotations like SipSessionListener, SipApplicationKey, SipApplication, SipSessionAttributeListener, SipServletListener, Administration for SIP Container Monitoring of the SIP Container Security Converged LoadBalancer Session replication |
What's next ?
Our next milestone is on Jan 21st 2008 which is the feature freeze date for all modules including Session Replication and JSR289 based SIP Container. There is a small caveat as far as JSR289 based container goes, since the spec. has not gone final yet, one can never say that the code has been frozen till the spec is final. Hence the plan for JSR289 based container is to get the code as close to the JSR289 PR draft as possible.
The feature freeze on January 21st would be the freeze for the beta release of Sailfin, due in March of 2008. We are looking to stabilize the features that have come in , between now and Jan 21st. Any and every feedback that comes would contribute towards the quality of the product. The detailed schedule is available here
Getting the binary
The Milestone3 binary can be obtained from here.
One can also navigate through the download link on the Sailfin site to the download page, where
Nightly Builds ( unstable , built every night )
Promoted Builds ( stable , built every week )
Milestone Builds ( stable and certified )
can be downloaded.
Bugs are expected and we welcome them and they can be filed at IssueTracker
I attended a conference ( IMSAA 2007 ) on IMS Architectures and Applications in Bangalore last week. Here is a brief trip report !
[Read More]
GlassFish is a Java EE 5 based application server with high availability and scalability aimed at the enterprise customer.Its a project on java.net , the main project therein being the application server. There are several sub-projects under the Glassfish project which use GlassFish as the runtime.
Saifin is a subproject under GlassFish. It adds the SIP Servlet Container based on JSR 289 to GlassFish. In addition to the SIP Servlet Container , Sailfin also aims to provide High Availability of the SIP Servet Container and a loadbalancer for both SIP and HTTP traffic . Given the functionality , the Sailfin codebase requires GlassFish as its underlying runtime. The WebContainer from GlassFish and the SIP Servlet Container becomes the converged container that is typical of the SIP Application Servers based on JSR289
Sailfin Application Server is built by overlaying Sailfin codebase on top of Glassfish Application Server v2.1. This becomes the open-source SIP Application Server on java.net ( the only one on open source ? )
There are two terms from the previous statement that I would like to clarify :
Why do we overlay Sailfin ?
The Sailfin codebase is loosely couple with Glassfish, in the sense that there are no code-changes made in Glassfish code base which are related to functionality provided by Sailfin. Theoretically a user should be able to add Sailfin functionality to any Glassfish Application Server .
Why Glassfish 2.1 and not Glassfish v2 ?
GlassFish v2.1 would be have some SPIs that would allow extension of the deployment and administration functionality. Sailfin makes use of these SPIs to overlay the Sailfin code on top of GlassFish. Hence in order to use Sailfin we need a version of Glassfish that exposes these SPIs and that is Glassfish v2.1 !
Here is a schematic that explains it :

How is Sailfin distributed ?
Sailfin is distributed as a single bundle with the underlying GlassFish included. The bundle comes with the same jar based installer as GlassFish. Update: The underlying GlassFish comes with all the fetaures as a normal GlassFish v2.
As per TIME "I" am the Person of the Year , alongwith many others who have contributed to content on the Web . Web 2.0 was termed a hype , and has been termed as a "social experiment" by the TIME magazine. I guess the truth is somwhere in between.
I had a blog last year , but I did not blog about 2005 , however I am doing so for 2006. I guess I would blog more in 2007... I realize that I do take blogs seriously more than last year . Maybe TIME is not off the mark there !
Home pages were a rage in late 1990s, but did not go far due to several reasons . Blogs/YouTube/Flickr is providing a much bigger platform for self expression , so much so that mainstream media websites have folks on ther roll blog ! Its so easy write a trip report with pictures and videos thrown in without need a dedicated server at your end ...
But with practically no barriers for entry into the blogosphere, (except for an account and time and access to a PC) we have many opinions, many viewpoints and practically no regulator. Do people have the sense to discern facts from opinions ? Maybe 2007 would tell !
On a personal note , I felt that this year went by very fast , yes, faster than 2005 or 2004 ! While I have no resolutions for 2007, I do hope that I will accomplish what I set out do , I will set out to do what I can , and I have the sense to figure what I need and what I can do ! So help me God !
Congratulations to you and the entire team Pr...