Binod P.G is a senior staff engineer at Sun Microsystems, where he work as the architect of the GlassFish Communication Server (http://sailfin.dev.java.net). Binod has vast experience in Java EE, distributed enterprise computing and telecommunication both in legacy platforms like Mainframes and also in Unix/Linux and Microsoft. He has been researching on convergence of different communication technologies with enterprise distributed computing for the last few years. Binod has posted 2 posts at DZone. View Full User Profile

SailFin CAFE Fundamentals: CommunicationBeans and Agents

01.22.2010
| 10941 views |
  • submit to reddit

SIP Servlets provide a server side Java abstraction to SIP protocol and it is based on familiar servlet model. This enables an application developer to use Java servlet programming to write Converged applications. What exactly is the meaning of "converged applications"? SIP Servlet Specification explains this as follows

"While the SIP Servlet API can certainly be implemented independently of the HTTP Servlet API, it is expected that many interesting services will combine multiple modes of communication, for example, telephony, Web, email, instant messaging and other server side components like Web services and other Java EE interfaces."
SIP Servlet specification defines SIP Application Session, which is a session that holds child protocol sessions (Http Session and Sip Sessions). The lifecycle of this Application Session is defined by the application itself. Thus it provides a flexible mechanism to share data between HTTP and SIP Sessions on an application defined scope. SIP Servlets also enable Java EE components to compose and send SIP requests as per RFC 3261.

SIP Servlets is one step in the right direction. I.e it provides a way to write applications that mixes SIP with other Java EE technologies. However, this forces application developer to learn SIP protocol. That would take the developer to the SIP RFC hell. Take a look at this RFC to list SIP RFCs and imagine an average web developer starting to write SIP applications.

H2G2. Dont Panic!

With that introduction, lets see how does SailFin CAFE simplifies the SIP application development.

Communication Beans

SailFin CAFE provides what is called "Communication Beans". Essentially they are stateless POJOs that are annotated appropriately. The main difference is that, the bean handles the SIP protocol (and many other telco industry specifications from OMA, 3GPP and IETF) by default and thus hides it from the developer. The developer can then write his logic to modify the behavior of Communication Beans. This is done from the perspective of modifying the behavior of "communication" it is handling rather than SIP protocol itself. By default the CommunicationBean will act as a simple B2bUA. Take a look at this 2-party call and this instant messaging examples for details.

A CommunicationBean can contain annotated methods to handle different events in the Communication. Take a look at this example, which creates a Conference from the incoming call. Effectively this converts the incoming two party call to a conference. Under the hood, CAFE would use a JSR 309 resource adapter to create the media mixer with a media server and do the necessary SDP negotiation. Whenever each event (annotated method) gets executed, the injected CommunicationContext would provide the relevent objects to the CommunicationBean implementation. Such objects are the Communication Object, The participant which invoked the event, Instance of Message (for example a DtmfSignal or TextMessage). etc.

Convergence in CAFE and Agents.

A CommunicationSession object is injected into HTTP Servlets and CommunicationBeans (When we have Java EE 6 based SIP Servlet containers, this would also work on all kind of Java EE artifacts. Thanks to JCDI). An application can use this object to create any kind of Communication. Different entities in a communication (eg: Communication, Participant, RegistrationProcedure) etc have different lifecycles and there might be different events happening pertaining to these entities. A converged application might need to execute logic based on such events. For example, in a music player application, when the communication gets "established", the application might want to play a music. Similarly, in a conference application, when the host of the communication "joins" the conference, recording might be activated. Obviously these events will be invoked in the CommunicationBean. But then how will application write their logic linking all these events?

To handle with this, CAFE provides the ability to attach "Agent" objects for different Communication artifacts. An "Agent" is an application defined object that contains data and logic specific to the application. An Agent can be Attached to a Communication or a Participant (or the same Agent can be attached to both). Now, application invoke the Agent to perform the application specific logic whenever the event occurs. Given Communication artifacts are accessible both from Web Application and from the CommunicationBean, the Agent facilitate Converged application development in an organized way.

A music player example application is checked in here, which uses most of the functionalities mentioned in this blog. Post any questions you may have of dev@sailfin.dev.java.net. Or follow SailFin on twitter at http://www.twitter.com/sailfincs.

From http://weblogs.java.net/blog/binod

Published at DZone with permission of its author, Binod Pg.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: