How to install The Java Communications API in a Windows Environment

There is a trick to install the Java Communications API correctly on a Windows system Machine. The following files are the core of JAVA Communiccation API, and they are very important to have them installed on your system for a proper operation:

* comm.jar
* win32com.dll
* javax.comm.properties

For the jdk (Java Developnment Kit) to recognize the serial ports on your machine, it is important to properly place these files in the right folders on your local machine :

%Java_HOME% = the location of your jdk directory.

To Find your JDK directory, Use the Following steps:

1. Click on Start
2. Click on Search
3. Click on For Files or Folders …
4. In the Left hand Side, Click on All Files and Folders
5. Type in jdk* in the textbox under All or part of the file name:
6. Click Search
7. Look for yellow icon that looks like a folder
8. Double Clikc on the folder to open the jdk folder

comm.jar should be placed in:

%JAVA_HOME%/lib

%JAVA_HOME%/jre/lib/ext

win32com.dll should be placed in:

%JAVA_HOME%/bin

%JAVA_HOME%/jre/bin

%windir%System32

javax.comm.properties should be placed in:

%JAVA_HOME%/lib

%JAVA_HOME%/jre/lib

Download Link:

http://www.megaupload.com/?d=XSPXW2PY

The list of embedded simulators for every JDE version

Below there is a list of embedded simulators for every JDE version.


JDE 4.0.25790

6230

6280

6710

6720

7100g

7100r

7100t

7100v

7100x

7210

7230

7250

7280

7290

7510

7520

7730

7750

7780







JDE 4.1.0

7100g

7100r

7100t

7100v

7100x

7250

7290

7520



JDE 4.2.0
8100

8100 - TMobile US





JDE 4.2.1

7130

7130e

8100

8700

8703e

8707

8800



JDE 4.3.0
8120

8130

JDE 4.5.0
8100

8110

8120

8130

8300

8310

8320

8330

8700

8703e

8800

8820

8830

JDE 4.6.0
9000





JDE 4.6.1
8900



8350i (listed in emulators list, but does not work, I recommend to download as standalone simulator)





JDE 4.7
9500



9530





JDE 5.0 (beta)
8900



9000

What Is - The required MIME types for a web server to serve BlackBerry smartphone applications

Description

The BlackBerry smartphone has the ability to download and install applications over the wireless network. For a web server to allow a BlackBerry smartphone to download applications, it must be configured with the appropriate Multipurpose Internet Mail Extension (MIME) types. The following is a list of required MIME types that must be configured on a web server to allow the downloading and installation of BlackBerry smartphone applications.

cod application/vnd.rim.cod

jad text/vnd.sun.j2me.app-descriptor

jar application/java-archive

Axis2 Session Management

Web services are in high demand and a large number of players have entered the web service arena. As a result of this, users are looking for more and more features, and they are trying to do everything by using Web services. By design, Web services are said to be stateless. There was no notion of managing sessions in the Web service world, but now this has changed and users cannot develop an advanced application without managing state. A good example would be banking applications where you log in into the system, withdraw money, and log, out.
If we try to map that into a Web service:

• First, the user logs in into your account (invoking a login method)
• The user withdraws money (invoking some operation on his account)
• The user logs out (completing the transaction).

You easily can understand that the three operations stated above are interrelated, and the same user does all three invocations. So, it means that someone needs to keep track of the user, and another has to keep track of the user data throughout methods invocation. This implies the need for session management.
When it comes to advanced applications, we have to break the rules; otherwise, no one can implement real Web applications. As a result, even though Web services are stateless by nature, upi need to add a layer above it to provide session management.

The Stateless Nature of Axis2

One of the good design principles of Axis2 is that it keeps logic and states separately, so none of its components are needed to maintain session and they don't maintain sessions. In Axis2 handlers, transports and even AxisEngine are said to be stateless; therefore, there is no difference between having multiple instances or one instance of them.
As a best practice, a handler or transport should not keep any instance variable (if it is likely to be changed), because that breaks the stateless nature of Axis2. So, if the handler or transport wants to act in a stateful manner, the correct way is to store the state and Axis2 state hierarchy and use it whenever necessary, rather than keeping instance variable.

Types of sessions in Axis2

As mentioned above, an enterprise web service cannot sustain itself unless the session concept burns into Web service engines. In other words, it is wrong to say that each and every SOAP web service engine should maintain sessions because you can have services that do not require maintaining sessions. A good example could be a Google search service and a Google spell checker service.
Managing sessions directly causes an increase of the memory footprint and to slow down performance, but you need to have a compromise: whether or not you support the session and provide state full service development. Axis2 is meant to be an enterprise Web service engine, so it has to support session management.

Related Articles

• Utilizing a Non-Java Web Service with Axis2
• Avoiding Mistakes Made Using Axis2
• The Axis2 Transport Framework
• Writing an Axis2 Service from Scratch

When sessions are considered, there can be different types of sessions as well, and the lifetime of the session may vary from one to another. Some sessions last a few seconds whereas others last the system lifetime. Axis2 architecture has been designed to support four types of sessions. There are a few differences from one to another; hopefully you can develop any kind of Web service by using the following four types of session scope.

• Request
• SOAPSession
• Application
• Transport

Axis2 context hierarchy

It is useful to understand the types of contexts in Axis2 before discussing types of session in depth. As mentioned above, Axis2 keeps logic and states separately, so contextS are there to store the states. There are five types of contexts in Axis2:

• ConfigurationContext: The runtime representation of THE whole system, to start Axis2 system you need to have A configuration context. The lifetime of configuration context will be the lifetime of the system, so if you store some state (a property) it will last forever (until system shutdown).
• ServiceGroupContext: In Axis2, you can deploy multiple services together as a service group. At runtime, there will be one or more service group contexts (depending on the session scope of the group) to keep states of the group throughout the session.
• ServiceContext: Will represent the runtime of one service; the context lifetime will be the lifetime of the session. There can be one or many service contexts in the system depending on the session scope of the corresponding service.
• OperationContext: This context represents the lifetime of a MEP (Message Exchange Patterns). The lifetime of the operation context is usually less than the lifetime of the service context.
• MessageContext: The lifetime of an incoming message is represented by the message context. If two handlers in a given execution chain want to share data, the best way is to store them in message context. One operation context may have many message contexts.

Irrespective of the session scope, when the session start up and when it finishes, Axis2 will notify the service implementation class, but you have to add two additional methods to your service implementation class.

public void init(ServiceContext serviceContext) {
}

public void destroy(ServiceContext serviceContext) {
}

In addition to that, whenever a service receives a request, it will notify by passing the corresponding OperationContext as an argument. So, if the service wants to access an incoming message's context or an incoming SOAPMessage, he can do that by just adding the following method to the service implementation class; this method will be called before the actual method is called.

public void setOperationContext(OperationContext operationContext) {
}

Request session scope

Request session scope is the default session in Axis2. When you deploy a service without knowing anything about session management, your service will be deployed in the requested session scope. The lifetime of this session is limited to the method invocation's lifetime, or the request processing time. So, when you deploy a service in request scope, you don't have a way to manage session; it is the same as though you don't have a session at all.
Once you deploy a service in request session scope for each and every invocation service, the implementation class will be created. Say you have deploy a service called "foo" in request scope; if a client invokes the service 10 times, there will be 10 instances of the service implementation class. If you want to specify the scope explicitly, you still can do that by adding a scope attribute to the service element in services.xml as follows:

Even if you deploy a service in a request scope, there are many ways of managing sessions in Axis2. One way is to store the state in Axis2' global runtime (configuration context) and retrieve it whenever necessary.

SOAP Session Scope

SOAP session scope has a slightly longer lifetime than a request session, and deploying a service in a SOAP session is required to change services.xml. Managing a SOAP session requires both the client and service to aware of the sessions; in other words, the client has to send the session-related data if he wants to access the same session and the service has to validate the user by using session-related data.
To manage a SOAP session, a client has to send an addition reference parameter in the SOAP header; it is named the serviceGroupId parameter. The SOAP session provides a way to manage the session not only for a single service invocation but also for multiple services in a service group. As long as you are in the same SOAP session, you can manage service-related data in a service context; if you want to share data across other services in the group, you can use serviceGroupContext.
When you deploy a service in SOAP session and when a client tries to access the service in the first time, Axis2 will generate serviceGroupId and send that to the client as a reference parameter in wsa:ReplyTo, as shown below:

   
      http://www.w3.org/2005/08/addressing/anonymous
   
   
               "http://ws.apache.org/namespaces/axis2">
            urn:uuid:65E9C56F702A398A8B11513011677354
      
   

If the client wants to live in the same session, he has to copy that reference parameter and send it back to the server when he invokes the service the second time. As long as a client sends the valid serviceGroupId, he can use the same session, and the service can maintain the session-related data. Unlike a request session, a SOAP session has a default timeout period, so if the client does not touch the service for 30 seconds, the session will expire, and if the client sends the old serviceGroupId, he will get an AxisFault too.
Managing a SOAP session requires you to engage addressing modules on both the server side and client side. Deploying a service in a SOAP session requires you to change services.xml as follows:

Transport session scope

In the case of a Transport session, Axis2 uses transport-related session management techniques to manage session. As an example, in the case of HTTP, it uses HTTP cookies to manage the session. The lifetime of the session is controlled by the transport, not by Axis2; Axis2 stores the service context and serviceGroupContext in the transport session object so that the service can access those contexts as long as the session lives.
One of the key advantages of the Transport session over other sessions is that you can talk to multiple service groups within one transport session. In a SOAP session, you don't have a way to communicate between two service groups, but with the transport session you have that capability. In this case, the number of service instances created depends on the number of transport sessions created.
Deploying a service in a transport session requires you to change services.xml as follows:

If you are using Axis2 nightly builds or planning to use them the next version, deploying a service in a transport session requires additional changes to axis2.xml. That is mainly to improve the memory usage; otherwise, whether you deploy the service in a transport session or not Axis2 tries to create a session object at the transport level; with these changes, it will not create unnecessary objects. To manage the transport-level session, you need to set the manageTransportSession parameter value to true in axis2.xml:

true

Application scope

Application scope has the longest lifetime compared to others; the lifetime of the application session is equal to the lifetime of the system. If you deploy a service in application scope, there will be only one instance of that service and obviously there will be only one service context for that service. In the Axis2 world, if you consider the memory footprint and if you don't want to manage the session, the good candidate is to deploy the service in application scope.
When you deploy a service in application scope, a client does not need to send any additional data to use the same session. To deploy a service in application scope, you need to change axis2.xml as shown below:

Related Articles

• Utilizing a Non-Java Web Service with Axis2
• Avoiding Mistakes Made Using Axis2
• The Axis2 Transport Framework
• Writing an Axis2 Service from Scratch

Managing the session using the service client

Managing the session on the client side involves bit of a work. As mentioned above, both in a SOAP session and Transport session a client has to send the session-related data if he wants to live in the same session. Maybe he can do that for a SOAP session by coping with required reference parameters, but with a Transport session a user must get access to the transport to copy and send cookies.
To make life easier, Axis2 has the built-in capability of managing sessions in the client session by just setting a flag. Then, depending on the service side session, it will send the corresponding data as long as you use the same service client. So, the main requirement is to use the same service client to invoke the service if you want to live in the same session.
If you want to live in the same session, you can create service client as shown below and re-use the created service client object to invoke the service.

Options options = new Options();
options.setManageSession(true);
ServiceClient sender = new ServiceClient();
sender.setOptions(options);

Once you create the service client as shown above, if the service deploys in a SOAP session it will copy the serviceGroupId and send that from the second invocation onwards. If the server sends the session id, such as HTTP cookies, it will copy that to the service context (on the client side) and send it back to the server when the client invokes the service for a second time.

Summary

The stateless nature is one of the main characteristics of Web services, but it is a limitation for advanced Web services developers. Developing an enterprise-level application using Web services is not easy unless you have a session management layer. Axis2 has four levels of sessions to address enterprises-level Web service development issues.

BlackBerry Bluetooth

I am developing an J2ME application on blackberry to enable a bluetooth connection between it and another bluetooth module.
My BB: TMobile 8320
OS: V4.5.0.81(Platform 2.7.0.78)

Now the problem is I have done the device discovery and service discovery successfully, and I have got the bluetooth module SPP service's URL successfully which is this:
btspp://000666019C30:1;authenticate=false;encrypt=false;master=false
where the URL is just the string above, i.e. bstp://...., the J2ME application idles around 20 seconds and then throw a IOException indicating the connection cannot make.
While there is an quite interesting phenomenon that during the 20 seconds, the bluetooth module's LED was SOLID GREEN which means it is in connection status. And also the blackberry's LED blinking in blue which indicates it is communicating through bluetooth. But after the exception threw out, everything back to before, just like nothing happened.

The problem was solved! I am giving the solution in case the same problem may bother other developers in the future.

1. Actually, my code does nothing wrong. The connector.open() method is pretty straightforward and identical on the standard J2ME platform. My application suddenly worked and connected to the Bluetooth module after I ran the Bluetooth sample application from blackberry. I checked its source code, and found before the normal process: device discovery, service discovery, and get connected, there is another important step, which should be the first stage, called stack initialization. In this step, we will initialize the SPP parameters like Baud rate, data format and so on. Here is the statement right from the sample:

this.myPort = new BluetoothSerialPort("SPP",  BluetoothSerialPort.BAUD_9600, BluetoothSerialPort.DATA_FORMAT_PARITY_NONE |                BluetoothSerialPort.DATA_FORMAT_STOP_BITS_1 | BluetoothSerialPort.DATA_FORMAT_DATA_BITS_8,               BluetoothSerialPort.FLOW_CONTROL_NONE, BUFFER_SIZE, BUFFER_SIZE, this );

You can put it in the constructor of your Midlet. One thing needs to be mentioned is to use this function, we have to purchase a code signing key from blackberry or the application will not be allowed to install.

2. If you find your application is frozen during the connection, that is because if certain class was ran in the main thread, the application will be locked, and StreamConnection is one, see here:

http://www.blackberry.com/developers/docs/4.2api/javax/microedition/io/Connector.html

So just put the connection part into another thread, there will not any freeze.

3. Here is another reason that may lead to the problem, though it is not the case for me, I still would like to append it here in case it may help you:

acowart:

Requesting the device's friendlyname (with the boolean set to true) causes a connection to bluetooth, and running service discovery immediately afterwards can fail, since the previous connection may not have disconnected yet.

There are no APIs to programmatically enable or disable Bluetooth.

BlackBerry Setting

APN Setting
Web Service call error: 'APN not specified'.
I fixed this problem on my BB by going to Options->Advanced->TCP/IP and making sure APN Setting Enables is checked and that the correct value for you service provider for APN: is set.
 SingTel
APN: e-ideas
Username: 65IDEAS (or blank)
Password: IDEAS (or blank)

StarHub
APN: shwap or shwapint
username: blank
password: blank

M1
APN: sunsurf
user: 65
pass: user123
If the the APN is enabled and leave blank, the default APN (blackberry.net) will be applied.

After you configure your APN settings you may need to pull the battery to reset the phone for them to go into effect.

Get IMEI number:
Option -- status

System Log
alt + LGLG

Capture Screen
JDE\bin\JavaLoader screenshot 1.bmp

Mobile Apps cross-platform development challenge: PhoneGap vs. Titanium vs. Rhodes

by Mauro Dalu

What is the best cross-platform mobile framework out there?
Let’s take a look at the main three competitors.
First of all, cross-platform compatibility is all about compromising on the native look, feel and features of devices. Therefore, if you’re looking into creating a 3D game or an interactive, multimedia, animated app, you’re looking in the wrong direction.
PhoneGap, Titanium and Rhodes are all based on web technologies and are aimed at web developers that want to leverage their current skills set to the mobile apps world.

PhoneGap and Titanium use HTML, CSS, and Javascript. They both provide Javasript APIs to access the native features of the device (GPS/Geolocation, Vibration, Accelerometer, Sound…). Rhodes instead is based on Ruby and inspired by Rails. It provides a full server environment on the device and provides access to native features of the device through this environment.
Titanium and PhoneGap expose the smartphone features through a set of Javascript APIs, while the application’s logic (html, css, javascript) runs inside a native WebView control. Through the PhoneGap javascript APIs, the “web app” has access to the mobile phone functions such as Geolocation, Accelerometer Camera, Contacts, Database, File system, etc.
Basically any function that the mobile phone SDK provides can be “bridged” to the javascript world. On the other hand, a normal web app that runs on the mobile web browser does not have access to most of these functions (security being the primary reason).
The Titanium website states “While Titanium applications are written using HTML, CSS and JavaScript – they are compiled into native applications (dependent on the mobile device) and run on the device as standalone applications. These applications have a very powerful API for accessing mobile features such as GPS and Camera, on-device Databases and other awesome features.”
This statement does not mean that Titanium can compile your html, css or javascript code into “native” code. They are packaged as resources to the executable bundle, much like an embedded image file. When the application runs, these resources are loaded into a UIWebView control and run there as javascript.
This is done the same way in PhoneGap as well. From architectural standpoint, these two frameworks are very similar. So what about the differences?
Most noticeably, PhoneGap does not expose the native UI components to javascript. Titanium, on the other hand, has a comprehensive UI API that can be called in javascript to create and control all kinds of native UI controls. Utilizing these UI APIs, a Titanium app can look more “native” than a PhoneGap app. Second, PhoneGap supports more mobile phone platforms than Titanium does. PhoneGap APIs are more generic and can be used on different platforms such as iPhone, Android and Blackberry (but their WIKI also lists Nokia’s Symbian and Maemo as well as Palm’s WebOS). Titanium is primarily targeting iPhone and Android. Some of its APIs are platform specific (like the iPhone UI APIs). The use of these APIs will reduce the cross-platform capability of your application.
So, if your concern for your app is to make it more “native” looking, Titanium is a better choice. If you want to be able to “port” your app to another platform more easily, PhoneGap will be better.
How does Rhodes fit into the picture?
“The Rhodes application framework allows developers to create native mobile applications with portability of editing HTML templates and the power of the Ruby programming language. Applications written in Rhodes exhibit the performance and richness of apps written to the native device operating systems with local data but enable developers to have the productivity of web interfaces in HTML. Developers write their applications one time and they then run on all major mobile device operating systems: iPhone, Windows Mobile, Blackberry and more.”
Rails developers will have a quick start with Rhodes and be able to get productive in a matter of days. The framework also has its limitations though. No audio and video support make it suited for data-based apps only, and while you can extend the framework using native calls to the APIs for each device for the parts of the app that require access to features not supported by the framework, it doesn’t necessarily mean that these will work smoothly.
Moreover, developing the native calls for these features exposes the developers to the native SDK and environment and therefore take away the main point of using a cross-platform framework in place of the native SDKs (learn once, write once, deploy on all).
Another advantage of Rhodes upon the other two is RhoSync. RhoSync retrieves data via web services (REST or SOAP) from backend enterprise applications for distribution to downstream mobile devices. It keeps a master store of all enterprise application data and keeps track of the information that users have received. It is written to be far simpler to deploy and configure than similar technologies that have come and gone over the past decade.
This doesn’t mean you cannot code against web services using PhoneGap and Titanium of course.
Finally, another differentiator is the licensing for each of these frameworks.
PhoneGap is open source and free for all to use.
Titanium is free while it is in beta, but will become a commercial product.
Rhodes is a commercial product and costs 500 USD per project, to be paid upfront before you start the development.
Surgeworks has been an early adopter of Rhodes. Even though the technology was the most mature at the time, it did present our developers some surprises and several challenges. The framework has been evolving very quickly: many issues have been fixed since our first approach with it.
Our Rhodes team (Brad Midgley being the project manager and Radu Cojocaru being the lead developer) is actively contributing to the framework evolution by submitting patches. Our first project built in Rhodes should hit the store some time in February.
At the same time, we’re keeping a close eye on PhoneGap and Titanium. I tend to prefer PhoneGap between the two because it is an open technology and supports more platforms.
Now back to one of my initial sentences, about making cross-platform games and multimedia apps. We’re all waiting to see the time in 2010 when Adobe will manage to release Flash CS 5 to build iPhone Apps and there is a hope that some follow up, expensive upgrade (CS 5.5?) will support building native apps for Android and BlackBerry, but until then, you’d better forget about cross-platform games and multimedia apps. I know there’s flash Lite, but can you package that in a native Android and BlackBerry app? and will that compatible with Flash CS 5 iPhone environment?… Too many questions to adopt this technology today.
If you’re looking into cross-platform 3D games, you should check out Unity. They currently only support Mac OS X, Windows and the iPhone… but I bet that support for more mobile platforms will follow in 2010.