Jiplet Container Home
SIP Servlet API
JAIN-SIP
API
|
Jiplet vs. SIP Servlet
We have received many emails and queries about the topic "jiplet vs SIP
servlet" - queries like what are the similarities and differences, what
is our motivation for not implementing a standard, etc. So we have come
up with this web page that explains this topic in details.
What is a SIP Servlet?
SIP Servlet is a specification created by the Java Community Process (JCP). The SIP
Servlet API is specified by JSR 116. The
API has been created by an committee consisting of telecommunications
and VOIP system providers like Siemens, DynamicSoft, Nokia, etc. JSR
116 enables application developers to create SIP applications using a
high-level Java API and deploy them in a servlet container. It is an
extension of the Java Servlet API created by Sun Microsystems and is
very popular for web applications. A HTTP servlet is a Java class that
handles HTTP requests from browsers. Similarly a SIP servlet is a Java
class that handles SIP messages from SIP user agents. The SIP Servlet
extends the servlet API provided by Sun.
The SIP servlet and the Jiplet are very similar. A jiplet is a servlet
in the sense that it is a Java class that handles SIP messages from the
SIP user agents. It does not currently extend the Java servlet API but
the API is very similar to the servlet API. However, there are
differences between the SIP servlet and the Jiplet API. The most
notable difference is that the Jiplet application use the low-level JAIN-SIP
API to format and parse SIP messages, route the messages to SIP
user agents, manage transactions and dialogs whereas the SIP servlet
has its own API for doing the same. We think that the JAIN-SIP API is a
more versatile API for this kind of stuff and therefore adopted the
JAIN-SIP API instead. Therefore, applications using the jipet
architecture will be able to take advantage of all the low-level
message
handling supported by JAIN-SIP. We do plan to implement the high level
message handling API specified by the SIP Servlet API in the next
releases.
What are the similarities
between the SIP Servlet and the Jiplet API?
When we started this project, we were planning to implement the SIP
Servlet API as a framework for very sophisticated SIP application that
we want to develop. However, we deviated because we thought that the
API is too high level when it comes to SIP message handling and would
hinder development of powerful SIP applications. We may, at some point
implement JSR116 if there is a large amount of interest. Even at this
point, there are a
lot of similarities between the two. Namely:
- The SIP Servlet and Jiplet classes are very similar. Both
have init(), destroy() and do...() methods that has similar usage.
- The Jiplet supports scoped variables like the servlet
API. We have added a few additional scoped variables that the SIP
Servlet specification does not have because we thought that it would
make the jiplet API more useful.
- The jiplet supports other features offered by the servlet
API including forwarding and logging. The Jiplet logging API is more
extensive compared to the Servlet API.
- The Jiplet supports deployment descriptors similar to the
SIP Servlet. The structure of the XML document is very similar.
- The servlet mapping specified by the SIP servlet is
identical with the jiplet. The jiplet defines a new concept called
context-level mapping to provide better support for hosting.
- The security constraint specified by the servlet API is
very
similar to that of the Jiplet. The jiplet supports container-managed
SIP authentication and authorization.
- The jiplet will implement support for resource and EJB
handling similar to those specified by the servlet API in upcoming
releases.
What are the differences between
SIP servlet and the Jiplet API?
It is somewhat difficult to compare the two as the SIP servlet is a
specification and the Jiplet is a actually a finished software product.
The jiplet container comes with a lot of features that are not part of
the SIP Servlet API specification because the API is primarily geared
towards defining the API rather that the container implementation.
Indeed, it will be more appropriate to compare a SIP Servlet
implementation with the jiplet container. Our goal is to refine the
jiplet container to make a container of choice for SIP server-side
development using Java and the J2EE environment. From the first release
of the software, the jiplet container supports plugging in the
container as a part of the JBOSS J2EE server. In general the
differences between the two are:
- The SIP Servlet API specification (yes, even the
specification) is distributed under a commercial license whereas the
Jiplet Container is released under the Apache
Open Source License. The SIP Servlet specification license puts in
a lot of restriction of how the specification is implemented and used.
The Apache license, on the other hand, gives you complete freedom to
download, user, modify, sell or do whatever you want.
- The SIP Servlet API specifies its own high-level API for
formatting, parsing, sending and receiving SIP messages. The jiplet
container uses the JAIN-SIP low-level API for the same. We think that
the JAIN-SIP API is a more powerful API (although it is more difficult
to learn) and is more suitable for powerful SIP applications.
- If you are using SIP servlets, you can switch containers.
That is, instead of using a container from vendor X, you can use a
container from vendor Y and your application will remain unchanged.
That is not the case with the jiplet container since the jiplet
container does not implement a standard API. SIP application vendros
switch containers for two reasons: (1) price and license restrictions
of the container and (2) the performance of the container. The jiplet
container is FREE and uses open-source license and you cannot beat
that. In addition, you can easily switch the underlying JAIN-SIP stack
used in the jiplet conatiner if you need improved performance (although
we think that the NIST JAIN-SIP stack we use is a high performance
stack) because that is where most of the performance-related issues are
involved.
- In our opinion, the SIP Servlet API is somewhat weak
with regards to the support for hosting. Although the Java servlet
specification has a reasonable support for hosting (multiple
contexts) in the web environment, it may not be sufficient for
the telecommunications environment and the SIP servlet specification
does not extend this. We envision that with increasing popularity of
SIP, there will be application service providers who will host SIP
servlet (or jiplet) for their customers. In the upcoming releases, the
jiplet container will implement a comprehensive set of hosting-related
features including robust security mechanisms, isolation of
applications, application quotas, resource limits, etc.
- The jiplet container comes with a JMX interface for
managing the container from an external management application whereas
the SIP servlet does not define any management interface leaving it
open to the implementation.
- The jiplet container define realms (or authentication and
authorization databases) whereas the SIP servlet leaves this open to
the implementation.
- The jiplet container comes with a web-based management
console for dynamically managing contexts and realms. The SIP servlet
leaves this open to the implementation.
- The jiplet container logging API uses LOG4J whereas the
Java servlet API comes with a somewhat inadequate logging mechanism.
LOG4J support printing of logs of various severity levels including
traces. It also defines how the log messages are handled - sent via
e-mail, saved to rotating log files, etc.
Where is the roadmap of the
jiplet project?
We do not have any roadmap as such but we do have a general direction.
- We will receive input from the SIP user community as to
what features they want to see. Depending on the interest level, we
will add them to the jiplet container. We would like the jiplet
container to be a community project rather than implementing a spec
formulated by a committee.
- We will accept contributions from the SIP software
community. Since the jiplet container is open-source, any software
developers can download and modify the software. They can add new
features and contribute it back to the project. You do have to follow
certain standards and guidelines and it entirely up to the discretion
of the lead developer as to whether we accept the contribution.
- We will monitor SIP Servlet and other leading projects and
try to keep up with the features these tools add.
In short, we want to build the jiplet container in the open-source
model of software development.
|