Monday Feb 28, 2011

Connecting securely to GlassFish via JMX

If you are here , you probably are familiar with GlassFish as well as JMX . This blog is about enabling JMX clients to connect securely to GlassFish.

Glassfish has a JMX Connector listening on port 8686 by default, for requests made to the MBeanServer from JMX clients.Typically the protocol is either JRMP over RMI or JMXMP. A user could connect to this port via a custom JMX client or a tool like jconsole to view the MBeans exposed by GlassFish and further manage or monitor the server using these MBeans.

Now , if one was using the server in production , then it would make a lot of sense to connect using SSL or TLS. This blog describes the steps to do that. If you want to know more on how secure JMX connections are made using RMI and SSL, please refer to these very informative blogs from Luis-Miguel and Daniel Fuchs . Here are a series of steps to be followed for enabling secure JMX connection to GlassFish

Glassfish by default has a JMX connector which listens of port 8686. This is named as "system". The domain.xml has an element under admin-service which looks like this


<admin-service type="das-and-server" system-jmx-connector-name="system">
   <jmx-connector name="system" auth-realm-name="admin-realm" address="0.0.0.0" port="8686">
   </jmx-connector>
</admin-service>

To enable secure connections, we need to set an attribute named "security-enabled" to true and also add an "ssl" configuration element as a child of the jmx-connector element. This is done either via the Admin Console or via the Admin CLI. The next steps are for achieving this via the Admin CLI.

Enabling Security for the JMX Connector

The following command sets the security-enabled attribute of the jmx-connector named "system" to true and hence the jmx-connector would have TLS enabled as per the ssl config which we would set in the next step.

asadmin set configs.config.server-config.admin-service.jmx-connector.system.security-enabled=true

The next step is to configure the secure socket that the JMX Connector would create. We do this by adding an element in the domain.xml. This can be achived by Admin CLI as well. Here is a command that adds an ssl element as a child to the jmx-connector element with a default configuration

asadmin create-ssl --type jmx-connector --certname s1as system

This command creates an ssl element for the jmx-connector named "system" using a certificate alias "s1as" The domain.xml looks like this after running the above commands.


<admin-service system-jmx-connector-name="system" type="das-and-server">
   <jmx-connector port="8686" address="0.0.0.0" auth-realm-name="admin-realm" name="system">
      <ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"> </ssl>
   </jmx-connector>
</admin-service>


The JMX Connector in GlassFish is now secure. We need to restart the domain/instance/cluster for this to take effect.

Connecting to the secure JMX Connector

The next part is to connect to this secure connector via a JMX client or jConsole . There are two main steps here .
1. To write a JMX client which can do a SSL handshake with the JMX Connector ( if you need to )
2. Pass the credentials and truststores to this client while connecting

To keep things simple lets use jConsole as an example here as a client. That should take care of #1 .

The next step is to get the certificate named s1as from GlassFish. A simple way of achieving this would be to connect to the admin server "securely", download the certificate that it sends over and then use the saved certificate as the truststore to be passed while connecting to the secure JMX connector. The steps needed to achive this are listed below :

First, ensure the secure admin is enabled

asadmin enable-secure-admin

Restart the domain / server after running this command.

Next , try and run any asadmin command

asadmin --secure=true list-modules

The server then sends the certificate ( s1as) which is then printed on the console like this :


[
[
Version: V3
Subject: CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

Key: Sun RSA public key, 1024 bits
modulus: 97954156793835138341680996103344678953674748997532211467359834975421400284125563262970337639362640745885555344627684588129109590370462160481207032557865487946908660504438107241154897539418460620522517212201504303859663985429597210945869016648453192769222604701698012686618738746521485767623901158049620124549
public exponent: 65537
Validity: [From: Sat Feb 05 21:12:59 IST 2011,
To: Tue Feb 02 21:12:59 IST 2021]
Issuer: CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
SerialNumber: [ 4d4d7003]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D4 50 B1 4E 23 06 45 6E CA 26 28 C8 FB 73 5F 1C .P.N#.En.&(..s_.
0010: 01 A4 11 74 ...t
]
]

]
Algorithm: [SHA1withRSA]
Signature:
0000: 34 1D ED C0 66 56 EB 7A F0 A6 15 E9 CE 95 C1 DB 4...fV.z........
0010: 5D F6 13 E9 57 CB 92 63 7A 50 98 C6 CB 1F 35 BF ]...W..czP....5.
0020: 5A 0F 77 C7 E8 0C CC EF 3C B8 D8 51 E5 64 9A 63 Z.w.....<..Q.d.c
0030: 2B 02 AF C9 66 7C 5B 50 80 E9 1C 40 53 92 7E BF +...f.[P...@S...
0040: 8D F8 9E E2 7D EB 23 E7 AE 8B 74 1E 42 7F 1B B5 ......#...t.B...
0050: 3A 31 8E 9B 2C 87 06 BB 7B CA 6B 83 D3 D5 C1 74 :1..,.....k....t
0060: F9 3C AA 93 18 DB B8 17 E4 AA 75 8D D1 F8 C0 08 .<........u.....
0070: 45 95 70 F0 D5 0A 01 9A ED EA BB 52 DB 1B ED 30 E.p........R...0

]
Do you trust the above certificate [y|N] -->

Choose "y" as the option and this certificate would be stored in a file named .asdmintruststore in your home directory.
Now, we have a server certificate stored in ${HOME}/.asadmintruststore . We will use this as a truststore when connecting to the JMX connector using a client like jConsole.

jconsole -J-Djavax.net.ssl.trustStore=${HOME}/.asadmintruststore

This should bring up the jConsole , and it would ask for the JMX URL or the host / port of the GlassFish installation. You would also need to provide the admin username and password to connect. After this step assuming the authentication goes through, you should be connected securely to the GlassFish MBeanserver on that host/port combination that you provided.

There are a few more topics that could be covered, namely
• Can I see all the MBeans in the domain from the DAS ? ( yes you can )
• Ok, how do I write my own JMX Client that can connect securely to the JMX Connector on GlassFish.

For details, watch this space.

Wednesday Feb 24, 2010

JSR 309 and jVoiceBridge without CAFE


Sailfin CAFE bundles a JSR 309 adapter that works with jVoiceBridge Media Server . This is primarily to support the Conferencing and Player/Recorder features in CAFE. However , this adapter can also be used standalone with jVoiceBridge without using CAFE APIs. This is useful if anyone wants to play around with JSR 309.

Here are the steps that one needs to follow to achieve this.




1. Download Sailfin CAFE from
https://sailfin-cafe.dev.java.net/svn/sailfin-cafe/trunk sailfin-cafe

Getting hold of jVoiceBridge

2. Once you do 'mvn install' the jVoiceBridge will be available at
$CAFE_HOME/cafe/implementation/media/mscontrol/jvb-lifecycle/target/jvb/bridge
where CAFE_HOME is the installation directory where CAFE has been checked out.
Lets call this location as JVB_HOME

3. cd JVB_HOME. Edit run.properties to specify the IP address of the machine where the JVB will run. Also make sure that the SIP port is set to something other than 5060 since 5060 will be used by Sailfin SIP Stack.

Running jVoiceBridge

4. ant -f run.xml should start the jVoiceBridge and spew out the log on the console

Getting hold of the JSR 309 RA

5. The JSR 309/jVoiceBridge adapter is available at
$CAFE_HOME/cafe/implementation/media/mscontrol/jvb-ra/target/jvb-ra.rar

Deploying and working with JSR 309 RA

6. Deploy the jvb-ra.rar to Sailfin using the asadmin command. Make sure that the jVoiceBridge and Sailfin instance are running.
7. Use "jvb/default" as the name of the resource for the 309 RA.
8. Deploy your application that uses jSR309 APIs onto Sailfin and use @Resource annotation to inject the MscontrolFactory.


Note that the 309 implementation is not yet at the FR level of the JSR 309 specification.

Wednesday Feb 03, 2010

Sailfin Webinar


There is a webinar planned for Feb 3rd at 10:00 AM PST, where I would be talking about Sailfin in general and Sailfin 2.0 in particular. Here are the details.


The newly released Sun GlassFish Communications Server (SGCS) 2.0, built from open source Project SailFin, is a scalable, highly available, converged application server that brings the power of Session Initiation Protocol (SIP) servlet technologies to the Java EE Platform. SailFin, based on GlassFish, is a perfect fit for developers familiar with Java EE and GlassFish and looking for SIP solutions.

Attend the webinar and learn:
What is SailFin, what it can do for you and its corresponding eco-system
SailFin architecture, features and roadmap
New features in SGCS 2.0
How to write SIP-based applications
Join us for this live webinar that will provide an overview of SGCS 2.0 and SailFin.

Topic:
SailFin: Delivering SIP capabilities to Java EE, GlassFish developers
Date:
Wednesday, February 3, 2010
Time:
10:00 am PDT / 1:00 pm EDT / 19.00 CET (check your time zone)

In case you are an SDN member you would have got a notification for this. If you are not a member, you could register here !

If you still cant make it, then there would be a replay available.

See you there !


Friday Dec 04, 2009

CAFE : Playing and Recording Media in an application


You would have seen blogs on how CAFE can help you simplify the writing of a Conferencing application . Now a typical conference is incomplete without the facilities for playing a welcome message or the ability to record a message. CAFE now has the ability to support playing of media to calls and conferences and also recording calls and conferences.

How is this done ?
CAFE exposes a MediaParticipant ( org.glassfish.cafe.api.MediaParticipant) interface which represents the 'media-interaction' for the communication . A MediaParticipant is associated with a CommunicationSession and provides the recording support to either a call or conference, whichever is the "Communication" to which the MediaParticipant is added.

The MediaParticipant has two sub interfaces; Player and Recorder . Depending upon the operation(s) that one would want to support ( playing + recording or either one of them), a new MediaParticipant of type Player or Recorder would have to be created and added to the Communication ( the communication being a conference or call). The following snippet of code demonstrates how this can be achieved.





// create a MediaParticipant
@CommunicationSession session;
Recorder recorder = session.createParticipant(Recorder.class, "recorder1");
Player player = session.createParticipant(Player.class, "player1");

// add a recorder as media participant
Conference conf = (Conference) ctx.getCommunication();
conf.addParticipant(recorder);

// add a player as a media participant
conf.addParticipant(player);

Once the MediaParticipant is added, a Player or Recorder instance which has been added to the Communication can be used to record and play. The Player and Recorder expose start() and stop() method to start and stop playing or recording. The trigger for starting and stopping the operation is determined by the application logic in CAFE. The following snippet shows the code which achieves what has been described above.





// start recording using the recorder object added to the conference.
recorder.start("file:///tmp/record.au");

// start playing using the player object added to the conference
player.start("file:///tmp/sample.au");


Similarly the stop() methods would need to be invoked to stop the playing or recording.

What happens under the hood ?
CAFE uses the JSR 309 API to connect to the Media Server ( which is jVoiceBridge in this case ) and to control the conferencing, recording of media and playing of media operations in the Media Server. It would take a whole new blog to describe how the implementation for jVoiceBridge works, and that's in the works. However, to satisfy you curiosity I will describe in brief how is used in this case :

JSR 309 exposes the following interfaces
• MediaSession - representing a whole scope interaction of the application with the Media Server.
• MediaMixer - representing a conference in the media session
• NetworkConnection - representing a call
• MediaGroup - represents a logical group of Player, Recorder, DTMF detector and Signal generator
• Player, Recoder, SignalDetector and SignalGenerator - reprsents the player,recorder, signal detector / generator instances in a Media Group.

When a participant joins a conference , the NetworkConnection corresponding to the participant is joined to the MediaMixer representing the conference. At this time a MediaGroup is also 'joined' to the MediaMixer or the NetworkConnection as the case maybe (i.e. depending upon the fact whether the conference or caller is the target of the media operation ). When a playing or recording operation is requested from CAFE, the Recorder or Player instance belong to the MediaGroup which has been joined to the call / conference is retrieved and the appropriate methods to start and stop recording and playing invoked. The Player or Recorder implementation invokes the appropriate methods in jVoiceBridge to play or record media , hence abstracting the complexities away from the user.

Attachments
Sample application used in this blog. This is a NetBeans project and starts recording a conference as soon as its created. One can also play a file using a simple HTTP Servlet interface.


Wednesday Oct 28, 2009

Next is what ?

Sailfin roadmap on the eve of the release of Sailfin v2

[Read More]

Monday Oct 12, 2009

Sailfin 2.0 is around the corner !



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


Tuesday Sep 08, 2009

Sailfin hits Hard Code Freeze

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.


You can download the Hard Code Freeze build of Sailfin here .

Monday Jun 01, 2009

Sailfin session at Community One today !



My session at CommunityOne ( S304781 ) , titled "Sailfin:Open Possiblities in Communications" is scheduled to start at 10:50 AM at the Esplanade 301.

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


Thursday May 28, 2009

Sailfin at Java One and Community One


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.


Wednesday Feb 11, 2009

Sailfin in detail : Part 2 annotated servlets



There are two ways in which we can define a SIP Servlet to be specific in a SIP Application. One of them is the traditional way of defining it in the sip.xml using the
> servlet <element and the other one is to use the @SipServlet annotation.

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 !!


Saturday Jan 24, 2009

Sailfin in detail : Part 1 app-name


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 / . i.e. If the SIP Application, foo.sar is bundled within an Enterprise Application named as barApp.ear , the app-name corresponding to foo.sar is derived as barApp/foo


    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);
       return (String) sas.getAttribute("newReg");
    }

}





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);
       return (String) sas.getAttribute("newReg");
    }

}

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.

Monday Nov 10, 2008

Milestone 6 and JSR 289 TCK.



Raison d'etre for Milestone 6 ...

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.


Monday Oct 13, 2008

We just crossed Milestone 5


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.


Wednesday Aug 13, 2008

SailFin 1.0 Alpha is here !!




We are releasing SailFin 1.0 Alpha today !
Why Alpha and why now ?
They say that an open source project is in a perpetual beta. Agreed ! Sailfin crossed MS4 early this year in April, where most of the features that we expect to support in 1.0 was in. However there was a need to start testing the Application Server more thoroughly , so that users/developers could use it more reliably to prototype their applications and evaluate the capabilities of Sailfin. The last few months have been spent on testing and stabilizing Sailfin in a cluster setup and also fixing key issues across all modules . Hence this may be a good time to expose this tested binary to all the developers for evaluation and feedback.

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 !

Monday Apr 21, 2008

SailFin @ Milestone4 moves towards Beta !


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.


We had planned for a beta , around this time frame , however while we were planning for the beta , the JSR 289 Specification was in the Public Release stage and there were couple of open issues that the EG was trying to sort out in the spec.  Of course the EG has made
rapid strides in the last four weeks and now the spec. is in the PFD2 stage.

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 !

About

prasads

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today