| |
|
| -FAQ |
General
Does iBus//Mobile Support SOAP?
At present, we support SOAP WebServices in two different ways:
-
JMS-via-SOAP:
For *client* applications that do not have any JMS libraries available:
A mobile client can use kSOAP to send and receive
JMS messages, by calling on a "JMS WebService" we provide.
That WebService runs inside the iBus//Mobile Gateway.
The interface (WSDL) of that service is much like
"send(Message)", "receive() -> Message", and a few more.
-
SOAP-via-JMS:
For *server* applications that need to invoke SOAP services in a
reliable or asynchronous way:
A JMS application running on a server can enqueue a JMS
message. The application has set certain JMS header properties
specifying the URL of the WebService, the parameters to pass
to the SOAP request, etc. The JMS message is queued. The iBus//Mobile
Gateway processes these requests asynchronously, and decoupled
from the originator. The Gateway invokes the WebService, and
places the result of the SOAP request into another JMS queue. The
originator reads responses asynchronously from the response queue.
hence, the server applications needs not to block. The gateway
can retry failed SOAP requests until it succeeds (or gives up),
and then put the result in a queue.
Does iBus//Mobile Support Microsoft .NET?
iBus//Mobile provides a JMS client library for the .NET platform.
This allows you to import the JMS package into C#, J#, VisualBasic.NET or C++.NET.
.NET applications can communicate with Java/JMS
applications, as well as with J2EE MessageDrivenBeans. The full JMS
feature set is available here.
What
is the difference between iBus//Mobile and a data synchronization middleware
(SyncML)?
Synchronization
middleware was designed for data-oriented applications. E.g., for synchronizing
your PDA calendar with your corporate calendar server. iBus//Mobile is
a Wireless message oriented middleware (MOM). Wireless MOMs are better
suited for interaction-oriented applications, such as order processing,
messaging, financial information, and games. iBus//Mobile hosts on-device
message queues which are transparently synchronized with the message queues
on a JMS server. iBus//Mobile will switch transparently from online to
offline operation, without user intervention. Hence, iBus//Mobile applications
provide very good reponse times and interactivity, guarantee the delivery
of important user data, and are always "in sync".
What
is the difference between iBus//Mobile and a Wireless CORBA ORB?
CORBA
embodies a request/response RPC model, which was designed and optimized
for wireline networks. iBus//Mobile embodies an asynchronous, "store-and-forward"
messaging model, which was designed and optimized for wireless networks.
Therefore, with iBus//Mobile a better "experience" can be conveyed to the
enduser.
What
are the differences between iBus//Mobile and other Wireless MOM products?
To
date, iBus//Mobile is the only store-and-forward mobile middleware available
on the market, which fully supports device mobility, J2ME, and which is
compatible with the JMS standard. Other offerings are either not developed
in Java, or try to force you into using vendor proprietary middleware APIs.
|
Protocol-specific
What
is GPRS, and why is it important for Wireless JMS?
General
Packet Radio Services (GPRS) is a packet-based wireless communication service
that promises data rates from 56 upto 114 Kbps and continuous connection
to the Internet for mobile devices. GPRS is part of the GSM standard and
is becoming widely available in Europe, the US, and in Asia. GPRS is typically
charged on a per-volume on not on a per-time basis. The packet-oriented
nature of GPRS, and the fact that mobile devices can be permanently connected
via GPRS, makes this bearer particularly interesting for JMS: Servers can
push JMS messages to mobile devices, and JMS messages can be efficiently
transmitted via GPRS packets. iBus//Mobile provides various features particularly
suited for GPRS (and other packet-based bearers). E.g., a UDP-based reliable
messaging protocol that can deliver better performance than TCP or HTTP,
various transmission parameters that can be tuned (retransmit delays, flow
control, transmission windows, etc.), dynamic adaptation to changing bandwith,
reliable messaging in spite of holes in network coverage, data encryption,
etc.
What
is the maximum allowable Datagram size in iBus//Mobile?
On
J2SE, the Datagram size limit is 64KB, which is as per the specifications.
Note
that since version 3.0, iBus//Mobile will transparently fragment and reassemble
JMS messages that are larger than the maximum datagram size supported by
the underlying network.
Why is it dangerous to use UDP/HTTP without the Reliability QoS on top?
Because
there is a chance that the JMS subscriptions and JMS messages get lost
between the Client and the Gateway. And without the reliability layer,
lost data will never be re-sent. As a result, the iBus//Mobile session
may be inconsistent on the Gateway, leading to unexpected behaviour. To
avoid this, we recommend that whenever you use UDP, you should always enable
Reliability as well.
Similarly
on HTTP, the order in which HTTP requests reach the JMS provider may vary
depending upon the threading implementation on the servlet engine being
used by the gateway (catalina by defaut). Hence, to avoid any out-of-order
messages, you need to have the Reliability QoS enabled when using
HTTP.
How is HTTP implemented in MIDP, is it through polling from the client side?
The
standard MIDP APIs only support HTTP 1.1, But HTTP is a request-reply (synchronous)
protocol. How then does the HTTP in iBus//Mobile work? The iBus//Mobile
MIDP Client implements JMS on top of HTTP as well as on UDP and TCP. As
for the HTTP implementation, we have done it in what we believe is the
most optimal manner :
The
MIDP Client opens two HTTP connections to Tomcat, which is running
inside the iBus//Mobile Gateway.
One
connection is used for sending client data up to the server. Each HTTP
request going over this connection simply puts the data on the servlet
and immediately returns.
For
the "return route" from the Gateway to the Client, the second connection
is kept open. This means that I send one HTTP request on this connection,
and this _blocks_ on the server _until_ there is at least one message to
get back to the client. Of course if there are multiple msgs (as would
be the case with a fast publisher), they would all be transported with
the same Http-reply.
As
soon as these messages are delivered to the client, another HTTP request
is shot off immediately, which will again block and wait for data on the
server.
Of
course the entire logic is embedded in our HttpBearer Protocol Object,
so the application developer sees no difference between TCP and HTTP. Hence
with this mechanism, we can support a HTTP client as a pure JMS subscriber
as well - without the overhead or the uncertainties involved with simple
polling. Of course, strictly speaking we _are_ polling, but in a very optimized
manner.
And
thus we manage to elegantly "bridge" the request-reply world of pure HTTP,
with the asynchronous world of JMS...
What
happens if the proxy times out the "return route" http request?
Such
situations will be handled in a transparent manner by the Reconnection,
Reliability and the Store-Forward QoS layers.
What
configuration steps are required for HTTPS, is it the same tunneling protocol
as in HTTP?
On
MIDP, HTTP and HTTPS are used in the same way - you only need to change
your URL from "http:" to "https:". The underlying iBus//Mobile implementation
is also identical for HTTP and HTTPS. The specific steps required to enable
HTTPS in MIDP, are described at length in the Online Documentation -> "MIDP-Specific
Notes" -> "Installation Notes"
On
Applets, you would use the browser for the HTTPS connection. On J2SE or
Personal Java, you need to set up your own PKI to use HTTPS.
|
Session Management
What
is a Session on the Gateway?
A Gateway
Session represents one iBus//Mobile JMS client application. It is associated
with a mobile client via the sessionId, which should be unique for each
application within each mobile client (device).
The
Gateway holds all the active sessions in a ClientSessionManager object.
Each time a new client connects to the Gateway, a session is created for
this client in the ClientSessionManager. Similarly, if a client disconnects,
the session is removed from the manager. Also, the Gateway will terminate
idle sessions to preserve resources (notably heap space and connections
to the JMS provider). See the item about session
timeouts.
The
Gateway configuration file ibusmobile_config.xml contains the configuration
required for handling sessions on the Gateway. Different "Session Acceptors"
are configured for this purpose.
What
is a Session Timeout?
This
is the duration (in milliseconds) after which a session on the Gateway
is deemed to be invalid, and is removed from memory.
What
are the default Session Timeout values, and why?
-
What are
the default timeouts for UDP, TCP and HTTP? :
The current
defaults, as defined in the ibusmobile-config.xml file, are :
TCP
never. UDP 30 sec. HTTP 60 sec.
-
Why is
UDP set to timeout in 30 sec.?
To avoid
sending UDP packets to a device that is switched off. Only if Reliability
is enabled, will the session be kept alive. So for example a pure consumer
receiving messages will stop receiving UDP messages after 30 sec. if no
reliability QoS is active. If reliability is enabled, it sends regular
keep-alive signals from the consumer to the Gateway, and hence the session
does not time out.
-
Why is
the TCP timeout set to never?
Because
it is connection-oriented. When a client dies, the gateway knows immediately
and it removes the session from the Gateway. Hence the Gateway never need
to timeout a TCP session.
-
Why is
the HTTP timeout set to 60 sec.?
With HTTP,
the Gateway side does not always know when a client disconnects abruptly
from the Gateway. In order to allow such a client
to
be able to connect back to the gateway, we need to clear out the Gateway-side
HTTP session after a time. This we do after 60 seconds
What
happens after a Session times out
- The
session is removed from the Gateway
-
If a client connects with the same sessionId : A new session is created
with the sessionId. This session behaves like a brand new session.
When
does the Gateway activate / deactivate sessions?
When
the gateway receives a new connection from a client, it loads any session
for that sessionId, from disk. If none is found (e.g. if it is a new sessionId
or if the gateway has been started in a "clean" mode), a new session is
created.
The
session is removed when :
-
the client disconnects (a DISCONNECT_REQUEST) is sent to the Gateway
-
the client dies (a CLIENT_FAILURE) is sent to the Gateway
-
the session times out
When
do the sessions on disk get cleaned up?
When
you do
-
Start
-> Programs -> iBus Mobile -> Start Clean Gateway, or
-
Programmatically,
when you start the Gateway with the flag -DIBUSMOB_DELETE_CLIENTSTORE=true.
Note that
it you should use this flag=true only if you want to clean up all the current
session information on the Gateway.
SessionId
and JMS ClientId
-
How
is sessionId different from a JMS clientId in iBus//Mobile?
Both the
JMS clientId and the iBus//Mobile sessionId are identifiers that should
be set uniquely by the application developer.
ClientId
is the "usual" JMS clientId used for setting up the JMS Connections.
SessionId
is an identifier for each logical session that is established between the
mobile device and the iBus//Mobile Gateway. Thus the sessionId uniquely
identifies a session, i.e. :
(i)
For the simple case, when you have just one application running on your
device, the sessionId is a unique identifier for the device itself.
(ii)
However, if you have multiple applications running on the same device,
then each of these applications will need to have a unique sessionId.
Thus,
if applications A1 and A2 are running simultaneously on a mobile device
whose IP number is a.b.c.d, then each application should set a unique sessionId,
e.g. "a.b.c.d.A1" and "a.b.c.d.A2".
Although
technically we could have reused the clientId for session management as
well, we did not want to force the usage of the same object for two different
purposes. Of course the simplest way when running just one application
is to use the same string as the sessionId and clientId.
-
How
do I set these two values when initializing my JMS client?
The ClientId
is set on the JMS Connection as per the JMS specs :
qcon_.setClientID(jmsClientId_);
Here is
the API you use for setting the SessionId in your JMS client initialization
code :
ProtocolStackRegistry.registerQos(url,
qosName, qosParams, sessionId_, doStoreFwd_, doReliability_, doSecurity_);
Thus,
the sessionId_ is passed in as part of the method signature, to emphasize
its importance in registering the QOS. This is how framework is informed
of the sessionId of the client (for that application).
Additionally,
you may also set the sessionId directly as part of the qosParams, by doing
:
qosParams.put(QoSConst.KEY_SESSION_ID,
sessionId_);
However,
this is not required, since the framework does this for you (in #registerQos)
in any case.
-
What
is a proper usage strategy for setting the SessionId?
The sessionId
is used for locating the correct session on the gateway when doing a reconnection,
so it is imperative that each device keeps a unique sessionId per application.
You could use something like an IP address to uniquely identify each device
- the iBus//Mobile framework does not place any restrictions. Only when
you start running multiple applications simultaneously on a device, will
you have to go for (ip + appName) or something as the sessionId.
From
our point of view, there is really no "right" or "wrong" approaches to
setting this value. One way is that each device looks up its IP address
and uses it as a Client_id. Alternatively, there can be numerous application-specific
unique id's that you may wish to associate with a device. e.g. the name
of the owner of the device, her log-in user name, her social security number,
or just some random number from a (good) random number generator.
|
Hardware-specific
What
special provisions do I need to take for the "Siemens M20 Terminal" modem?
For
that particular modem, you need to enable the "SMSC" property located in
the ibusmobile_config.xml file, and set it to the phone number of the SMSC
(SMS Control Centre) used by your network operator. Also, we recommend
you set the "pauseAfterWrite" property to "500". The other modems we tested
do not require these special settings. Please check the iBsu//Mobile Installation
Manual for a list.
I
get a "java.lang.UnsatisfiedLinkError: SerOpenPort" exception when I start
the gateway. What's wrong?
It
looks like ou are on a unix system and have not yet installed the serialio
lib in your Java Runtime Environment. You have to copy the serialio lib
that is located under $IBUSMOBILE_HOME/gateway/lib/<solaris_sparc |
linux>/ to your $JAVA_HOME/jre/<lib | bin>/ (the location depends on
the platform and Java VM). Please make an appropriate softlink afterwards,
i.e. libjspLux86.so -> libjspLux86.so.3.5
More
information can be found in the Installation manual of iBus//Mobile.
I'm
getting stange errors like "bad interpreter: No such file or directory"
when trying to start iBus//Mobile.
This
could be a problem of wrong end-of-line characters in your files. If you
run iBus//Mobile on a unix system, please be sure to extract the archive
with the -a option, i.e. "unzip -a ibusmobile.zip".
|
Programming for
Native Devices
Why
does the Gateway print NOTE : DestinationAccessor.handleEmptyDestination:
No destination found for Mobile: EmailMessage : xyz. Sending to DeadLetterQueue?
This
is an interesting situation. It happens because there is an SMTP server
and an IMAP server configured, both being accessed from the email module.
So what is happening is as follows
-
New message
"xyz" is sent via SMTP from the backend over the Gateway to the SMTP Server.
-
You receive
this message "xyz" in your mail client (email inbox), and you are happy.
-
Now -
The EmailTransceiver is (still) listening for new messages as well. So
he sees this "xyz" message as a new message on the IMAP server, picks it
up and tries to route this message to any configured destination. Then
he finds that there is no routing set up for this message, so he put it
into the DeadLetterQueue. That's the log statement you see.
-
So the
NOTE simply means that this (reply) email "xyz" could not be routed by
the Gateway, and has therefore been placed in the JMS DeadLetterQueue.
How
do I set up the "From:" address for sending an Email from my backend service?
If
you are usingXml=true in your Email Transformer (Check via Admin GUI ->
Config -> Email Transformer), you do element.setAttribute(XmlHelper.PROPERTY_ORIGINATOR_KEY,
"backendXml@softwired-inc.com"); look in ch.softwired.demo.services.xml.EmailXmlService.java
for the full source code.
If
you are using JmsHeaders (i.e. usingXml=false in your EmailTransformer
configuration), you set emailMsg.setStringProperty("IBUSMOB_MessageOriginator",
"backendXml@softwired-inc.com"); look in ch.softwired.demo.services.jms.EmailService.java
for the full source code.
Why
do I get this SAX Error when running my SMS / Email backend service: "Exception
in onMessage: ch.softwired.gateway.base.MobileGatewayException: XmlHelper.createXmlDocumentFrom
SAX Error: org.apache.crimson.parser/P-067"?
This
occurs due to a configuration problem :
You
have set usingXml=false in your Sms / Email Transformer (Check via Admin
GUI -> Config -> ( Sms or ) Email Transformer), but your backend service
expects XML in the incoming JMS message. For example, you have started
the ch.softwired.demo.services.xml.EmailXmlService (which expects XML),
but the Gateway is configured to use JMS Header and not XML.
To
correct this, you can either
(a)
Change the Gateway configuration to usingXml=true, which will then work
with the backend Xml-based service. Or
(b)
Stop the backend service, start the one which expects JMS Headers, in this
case the ch.softwired.demo.services.jms.EmailService.
How
do I set up SMS using a mobile phone and iBus//Mobile?
You
need to attach the mobile phone to the computer on which the iBus//Mobile
Gateway will be running. This is done either using a serial cable, or by
inserting a modem card into the PC using either the PCMCIA or PCI slots.
A
list of supported cellular phones and modem cards is provided in the iBus//Mobile
Installation manual, System Requirements section.
You
must then edit the file %IBUSMOB_HOME%\gateway\etc\ibusmobile_config.xml
file and change the entries "port" and "speed" which are located in the
"SmsTransceiver" property group.
For
example:
change
the default value of COM5 to the port in which the mobile phone is connected
to. The default transmission speed (baud rate) is 115200, you should check
to make sure the mobile phone will support this.
Please
note that if the phone is connected to the Gateway via serial cable, then
you really don't need to install any modem device driver software, since
iBus//Mobile only utilizes the basic text messaging capabilities of the
integrated modem. However, you will need to install driver software for
modem cards.
IMPORTANT:
Before changing the configuration file, use the Windows "HyperTerm" application
(or any other terminal emulator, such as "tip" under Unix) to connect to
the phone or modem card. Just to verify that the port name and speed setting
are correct. In HyperTerm, you should be able to enter
ATZ
press
the Return key and get back "OK" from the modem.
This
must be correctly configured before you can try starting the Gateway.
If
everything is working conrrectly as above, close the terminal application
and start the iBus//Mobile Gateway.
DEBUGGING:
To debug the installation, use the iBus//Mobile Administration Console
to enable "Monitoring" in the SMS modules, by clicking onto the button
labelled "SMS on". Now use the "mping" tool described in the iBus//Mobile
Administration Manual to request the Gateway to deliver an SMS. Finally,
use your cellular phone to send an SMS to the modem attached to the Gateway.
|
|
JMS semantics
Is
there any special handling of Queues vis-a-vis Topics in iBus//Mobile?
In
general, no. Queues and Topics behave as expected in respect to the JMS
specification. The only exception is the scenario where you have multiple
iBus//Mobile applications receiving from the same Queue. In such a case,
there is a danger of one message reaching multiple devices, thus breaking
JMS semantics. This aspect will be addressed in the next release of iBus//Mobile.
For now, we recommend that you use durable topics for such a scenario,
or that you use one queue per device, when sending data from a back-end
to mobile devices.
Why
is it important for my application to do a connection.close() in the end,
before it exits the VM?
The
Client needs to inform the Gateway that the connection is going down, and
that the Gateway may clean up any sessions associated with this connection.
This Disconnect Handshake between the client and the Gateway is triggered
on connection.close(). Thus, if you exit without closing the connection
in this manner, your client session is left dangling on the Gateway. This
is at best a memory leak; at worst it is dangerous since the session could
consumer messages, resulting in alternate messages getting lost with Queues,
for example.
Is
there a relationship between Durable messages and the Store-Forward QoS ?
Short
answer : No. These are two independent concepts.
Long
answer :
Sending
Durable messages (via the DeliveryMode.PERSISTENT flag) has the meaning
defined by the JMS spec, namely that the message is stored on persistent
storage on the server as part of the client's publish (or send) operation.
This ensures, for example, that a consumer that is not connected when the
message was sent out, will still receive this message.
Using
the Store-Forward QoS (via the doStoreFwd flag in the #registerQos method),
on the other hand, specifies whether you will run your iBus//Mobile JMS
client in "disconnected mode". You should set this flag to true if you
expect that your iBus//Mobile JMS client will lose network connectivity
rather often, and / or for longer periods of time. The client then writes
the JMS messages to a local storage on the device, and forwards them to
the gateway when network coverage is available. If doStoreFwd is set to
false, no data is written to local storage. In such a case, if the client
loses network coverage, it will eventually block in a "publish" (or "send")
call, until network coverage is restored.
In
summary therefore :
Use
Durable messages if you wish to ensure that your consumer gets all the
messages on that topic, even when it was not connected.
Use
StoreForward to ensure that messages get sent from your producer even when
the network connectivity is intermittent.
This
also implies that you can use both Durable messages and the StoreForward
QoS together in your application.
|
Disconnected
Operation
How
does iBus//Mobile work in disconnected mode?
To
enable disconnected operation, you need to enable "store-and-forward" by
setting the doStoreForward argument to true, when you call ProtocolStackRegistry#registerQos.
The store-forward mechanism persists the messages on the client, so even
if the client cannot connect and gives up, it will send these messages
whenever it does manage to connect (Provided it uses the same sessionId).
The
gateway does not try to reconnect to the client, it will wait until the
client reconnects. As part of the reconnection behavior, the gateway will
look at the undelivered messages for this client - provided it is a durable
subscriber or if there is a Queue connection from this client to the gateway
- and send them across. A technical detail here : the gateway itself does
not need to store the messages in a separate store, it simply uses the
JMS provider (e.g. iBus//MessageServer) to keep these messages until they
are delivered to the appropriate client(s).
From
the Store-Forward and Reliability perspective, how does iBus//Mobile behave
in the following situations :
(a)
The Gateway goes down and comes up again
(b)
The (bearer) connection between a client and the gateway is broken and
then re-established,
(c)
Your MIDP-enabled phone rang. What should you do after you return control
to the Java MIDLET?
(d)
A Mobile Client is switched off and then restarted.
The
four situations mentioned above are distinguished using the following terminology
in iBus//Mobile :
This is
the term we use for situation (d) above.
If
your client switches off and back on again, it connects to the Gateway
as a brand new client, albeit with the same sessionId as before. So the
gateway will create a new session for this client, and will therefore start
from scratch as far as this client is concerned. No existing session will
be reloaded.
The connection
between the client and the gateway gets broken (for various reasons) and
is then re-established. This term therefore covers the situations (a),
(b) and (c) listed above.
As
far as Reconnection is concerned, the iBus//Mobile framework uses two values
for achieving the reconnection :
(1)
QoSConst.KEY_DO_RECONNECT flag
The
framework handles reconnects "transparently", as long as the QoSConst.KEY_DO_RECONNECT
flag is set to true. If you do want reconnection, you need to set this
to true, and optionally you can set some more parameters defining how frequently
and how many times you want the reconnection to be attempted.
params.put(QoSConst.KEY_DO_RECONNECT,
String.valueOf(doReconnection_));
params.put(QoSConst.KEY_RECONNECT_INTERVAL,
String.valueOf(reconnectInterval_));
params.put(QoSConst.KEY_RECONNECT_RETRIES,
String.valueOf(reconnectRetries_));
So
for the situation (c), for example to setup your reconnectInterval_ and
reconnectRetries_ such that the client does not "give up" on the reconenction
before you finish your phone call. e.g. If you set the values to trying
5 times every 10 seconds, and if your phonse call lasts more than a minute,
the client would have exitted after giving up on the reconnect. Also, set
the reconenctInterval and retries based on your usage scenario. Note that
trying to reconnect too frequently will use up resources on the phone.
(2)
SessionId
For
the client to be able to reconnect to the same session on the Gateway,
you need to ensure that you are using the same sessionId on the client.
As explained earlier, it is this sessionId that is used for re-establishing
the connection to the gateway.
Other
than that, you do not need to do anything. The framework will do all the
necessary setup to reconnect your client with the gateway. The gateway
is programmed, as part of the framework, to handle reconnections. So when
your client manages to reconnect to the gateway (after your phone call),
the gateway will locate the correct session using the sessionId, and everything
then on will be "back to normal".
How
does the gateway distinguish a Client Restart from a Reconnection?
iBus//Mobile
provides different mechanisms to allow the gateway to make this distinction
:
-
Disconnection
handshake : When a client shuts down, it performs a handshake before disconnecting
from the gateway
-
Bearer-level
signalling : For connection-oriented bearers like TCP, the disconnection
can be spotted at the socket level
-
Gateway-side
session storage : The Gateway stores existing sessions on the local storage.
When a new sessionId is encountered, the Gateway first checks in this storage,
to check if the same client (sessionId) had connected before.
How
do I "clean up" the store-and-forward database?
In
order to ensure guaranteed delivery as well as store-and-forward communication,
both the iBus//Mobile client and the gateway need to write information
to a database. On the gateway, this information is kept in the directory
%IBUSMOB_HOME%\gateway\sessiondb. On the client, this information is written
to files with the suffix .data, .meta, .ack, and .index if its a J2SE client.
Or to the MIDP record store if its a MIDP devices. (Other databases can
be supported as well, through the iBus//Mobile IStoreAccess API).
Occasionally,
you might want to "clean up" this state. For example, after upgrading to
a never iBus//Mobile release, or to delete the databases of iBus//Mobile
applications you are not going to use any more:
-
On windows,
select "Start Clean Gateway" from the iBus//Mobile program group.
-
On unix,
pass the "clean" argument to startgateway.sh
-
You must
reset the client side database whenever you reset the gateway, and vice
versa. On the client, set the QoSConst.KEY_RESET_STORE property to true:
Hashtable
qosParams = new Hashtable();
qosParams.put(QoSConst.KEY_RESET_STORE,
"true");
ProtocolStackRegistry.registerQos(...
qosParams, ...);
We recommend
that you always clean up the gateway and client store-and-forward state,
in these situations:
-
After
upgrading iBus//Mobile (incl. minor upgrades and patches)
-
When you
have the impression that any of the gateway or client database files got
corrupted somehow
-
If you
have manually deleted any .data, .meta, .ack, or .index file
-
If you
have manually deleted any files located in %IBUSMOB_HOME%\gateway\sessiondb
The effect
of using a corrupted or inconsistent store-and-forward database can be
that your application catches an IOException, or that JMS messages are
not delivered to your application any more.
|
Deployment
What
is the size of the iBus//Mobile Client?
Starting
with iBus//Mobile R2.1, the client library is provided in various configurations,
in order to be loadable on different devices with different capacities.
We are essentially shipping the library for two different targets :
| Platform
|
QoS'
|
Approx.
Jar
Size
|
Comments
|
| J2SE
|
TCP,
UDP
Store-Forward,
Reliability
Client
Reconnection
|
180
KB
|
-
Without
any compression, application-packaging etc.
-
Can be
used directly on Applets, WinCE, Symbian and J2SE platforms, since typically
you do not face tight memory-constraints on these devices.
-
Excluding
Security (size depends upon selected security provider)
|
| MIDP
|
Different
options :
|
. |
-
Typically,
MIDP devices have much smaller memory limits. Hence we offer the various
subset packages of iBus//Mobile
-
Packaged
sample MIDlet using Dash-O-EE
|
| HTTP,
reliable client with reconnection
|
87KB
|
-
No Security.
-
Sample
jar available for download on our web-site
|
UDP,
reliable
client
with reconnection
|
86KB
|
-
No Security
-
Sample
jar available for download on our web-site
|
How
can I start multiple instances of the gateway?
You
need to create a new ibusmobile_config.xml and a new tomcat directory with
a modified server.xml file. In the new configuration files the port numbers
for TCP/UDP/HTTP connections have to be changed. For more details see the
document MultipleGateways.html in the directory /doc of the iBus//Mobile
installation.
I
have developed my MIDlet using iBus//Mobile. How do I package it to be
as small as possible?
Use
a tool such as Dash-O-EE, with options such as:
-
Set Obfuscation
to true
-
Remove
all unused classes and methods
That is
how the smaller libraries (UDP+Reliability, UDP+Reliability+StoreForward)
were created.
Please
refer to the MIDP documentation for details.
What
is the typical development lifecycle of an iBus//Mobile client application
?
iBus//Mobile
can use a variety of transport protocols and bearers to communicate with
the gateway. Also, you could be developing for a wide range of devices.
For convenience, we suggest the following development process :
Use TCP/IP
as the bearer during the initial development and testing phase
Run your
application under an emulator (where applicable).
Test the
client application in this simple set up.
Once it
has sufficiently stabilized, reconfigure the application to use a wireless
bearer, for example.
Finally,
the client application should packaged in such way that it can be installed
on the target device or computer. Please refer to the Online Documentation
to see how to package your application with iBus//Mobile, on your platform
of choice.
How
do I pick the right JMS JAR files among the many options provided?
iBus//Mobile
provides a range of JMS JAR files, optimized for the various platforms
on which you might want to deploy. Basically, two different sets of JMS
libraries are provided:
-
For deploying
JMS applications at the SERVER BACK-END: For that you should use the msrvClt.jar
and the jndi.jar files located under %IBUSSRV_HOME%\..\client\lib This
applies to when the iBus//MessageServer JMS provider is used. If you are
using another JMS provider, e.g., BEA WebLogic, then you need to use the
JMS libraries provided with that product.
-
For deploying
JMS applications on MOBILE DEVICES: Here you must use the JARs located
under %IBUSMOB_HOME%\client\\lib E.g., to run a mobile application on J2ME-MIDP,
you would use the library %IBUSMOB_HOME%\client\midp\lib\ibusmob-jms-midp.jar
Always
be careful that you do not confuse or mix up these two options. The main
differences between the two sets of libraries are that
-
is optimized
for server applications at the back-end. It delivers more throughput at
the expense of a larger memory footprint. But
-
is optimized
for low memory footprint, for sending messages across wireless networks,
and it allows JMS applications to be operated fully disconnected from the
network: Persistence is provided locally by the client library.
How can I run iBus//Mobile 3.0.0 with JDK 1.4.0?
To enable the iBus//Mobile Gateway 3.0.0 to run on JDK 1.4, you need to edit
the startup script of the Gateway.
-
Stop the
Gateway
-
Add environment
variable JAVA_HOME. Where JAVA_HOME is the directory where the Java 2 SDK
is installed.
-
on windows:
SET JAVA_HOME=C:\Java\jdk1.4.0
-
on unix:
export JAVA_HOME=/usr/java/jdk1.4.0
-
Edit the
startup script startgateway with your prefered editor.
-
on windows
edit: %IBUSMOB_HOME%\gateway\bin\startgateway.bat
-
on unix
edit: $IBUSMOB_HOME/gateway/bin/startgateway.sh
-
Modify
the JAVAVM variable definition in the startgateway script
-
on windows modify:
IF NOT "X%JAVAVM%"=="X" GOTO hasvm
SET JAVAVM=java
:hasvm
to:
IF NOT "X%JAVAVM%"=="X" GOTO hasvm
SET JAVAVM="%JAVA_HOME%\bin\java"
:hasvm
-
on unix modify:
if [ -z "$JAVAVM" ]; then
JAVAVM=java
fi
to:
if [ -z "$JAVAVM" ]; then
JAVAVM=$JAVA_HOME/bin/java
fi
-
Modify
the TOMCAT_PATH variable definition and change the %TOMCAT_HOME%\lib\tools.jar
component to %JAVA_HOME%\lib\tools.jar
The elipsis ... denotes other existing components
-
on windows
modify line:
SET TOMCAT_PATH= ... ;%TOMCAT_HOME%\lib\tools.jar; ...
to:
SET TOMCAT_PATH= ... ;"%JAVA_HOME%\lib\tools.jar"; ...
-
on unix modify line:
TOMCAT_PATH=... :$TOMCAT_HOME/lib/tools.jar: ...
to:
TOMCAT_PATH=... :$JAVA_HOME/lib/tools.jar: ...
-
Delete
the directory %IBUSMOB_HOME%\gateway\tomcat\work and all its subdirectories
-
on windows
delete: %IBUSMOB_HOME%\gateway\tomcat\work
-
on unix
delete: $IBUSMOB_HOME/gateway/tomcat/work
-
Restart
the Gateway
Important Notices:
-
iBus//MessageServer will NOT run with JDK 1.4
-
Java 2 Runtime Environment (JRE) doesn't include the tools.jar library, use the
Java 2 SDK, SE v1.4.0.
How to run iBus//Mobile and iBus//MessageServer on two different machines?
You could deploy the iBus//Mobile LE on two different machines and run the iBus//Mobile Gateway on
one machine and the iBus//MessageServer (JMS Provider) on the other.
iBus//Mobile Gateway act as a JMS client with the iBus//MessageServer (JMS Provider).
To enable the iBus//Mobile Gateway running on a different machine, you will have to
change the configuration of the JMS client library.
-
Install iBus//Mobile LE on the two different machines.
-
On the machine hosting the iBus//Mobile Gateway:
-
Edit the JMS client library configuration file: %IBUSSRV_HOME%\..\client\lib\config.ibusjms.txt
with your favorite editor.
-
Locate and modify the lines:
## Further parameters
## ==================
##
## -----------------------------------------
## ibusjms.topicConnectionFactory.serverName
## ibusjms.queueConnectionFactory.serverName
##
## Define the hostname on which iBus//MessageServer is running.
##
##
ibusjms.topicConnectionFactory.serverName=localhost
ibusjms.queueConnectionFactory.serverName=localhost
##
to define the hostname on which the iBus//MessageServer will run, like:
## Further parameters
## ==================
##
## -----------------------------------------
## ibusjms.topicConnectionFactory.serverName
## ibusjms.queueConnectionFactory.serverName
##
## Define the hostname on which iBus//MessageServer is running.
##
##
ibusjms.topicConnectionFactory.serverName=hostname_of_messageserver
ibusjms.queueConnectionFactory.serverName=hostname_of_messageserver
##
-
Start the JMS provider with the startserver script on the machine hosting the iBus//MessageServer.
( Administration => Expert Controls => Start JMS Provider )
-
Start the Gateway with the startgateway script on the machine hosting the iBus//Mobile Gateway.
( Administration => Expert Controls => Start Gateway )
|
|
|
|
