Java Reference
In-Depth Information
The two bottom components in Figure 11.8 are the clients of the
relevant native SIP stack. The ECom resolver plug-in resolves incoming
SIP requests to SIP client MIDlets. The native SIP stack client layer
uses the native SIP API on behalf of all running SIP client MIDlets and
updates the ECom resolver plug-in with information required by listening
SipConnectionNotifier objects.
ProsandConsoftheIntegrationApproach
Let us look at each of the integration criteria and evaluate how the
integration approach performs:
Java strategy - The option of providing a tightly integrated JSR-180 SIP
is in accordance with the general Java strategy.
Strict requirement - SIP is not necessarily an obvious case for manda-
tory integration. A different
type of
integration could have been
applied.
Customizability - Symbian OS licensees are not required to customize
or extend either the JSR implementation or the native SIP API while
integrating Symbian OS onto their UI platform.
Consistency - The tight integration approach ensures system-wide
unified behavior and functionality across Java and native applications.
Performance - The parsing of String objects, due to the nature of the
SIP protocol and the String -based design of JSR-180, was optimized
as much as possible. The rest of the functionality uses the optimized
native API.
ChallengingtheIntegrationApproach
As we have stated previously, SIP is an application layer protocol; it does
not have to be integrated with native Symbian OS services. Therefore,
a legitimate and interesting question is, why not implement JSR-180 SIP
purely in Java? We now consider the option of providing a pure Java
implementation for JSR-180 SIP.
A pure Java implementation would mean that parsing of String s,
validation of parameters, handling of SIP state machines as defined in the
RFCs, routing of messages inside or outside SIP dialogs, bearer protocol
support, and more would be implemented in pure Java.
A pure Java implementation would have had no impact on customiz-
ability. Performance would have remained fit for purpose by sticking
to the principles of writing efficient and optimized Java code, and, of
course, not forgetting the pre-compilation of Java bytecode into ARM
instructions during the CLDC-HI VM build process (see Section 10.8 for
more information).
Search WWH ::




Custom Search