This project won Best On Technology Award at SIMagine 2003
Java Card Applets Generation Tool
Project description
Application for automated generation card applets and
J2EE based proxy server. This system will allow to access web services
without hard coding. The application automatically generates a card
applet using just a web service definition (WSDL) file. To get web service
applets will communicate with our J2EE based proxy server via SMS based
custom protocol. The proxy will translate applet's requests for web
services into SOAP and redirect them to the server that provides the
web services in question. The SOAP responds being translated into SMS
get back to the card applet. So this system will automate the process
of creating and adding new elements (applications) to the SIM card menu.
Marketing appeal
Due to ever increasing Java usage it the web services
area on the market, we feel strong that our approach that allows automating
software development for accessing web services using cellular phones
will make a difference. It may decrease development cost and time. This
product could be, for example, a good add-on to Schlumberger Sema IDE.
Market applications
This system could be used not only by Telcos for fast
and cheap new services development and delivery to their clients but
clients themselves.
Source data and problem domain
As a matter of fact, Web Services have become a standard
for businesses to make the information about the services they provide
available for their current and potential clients. Web Services have
an open standard in the ground, which guarantees true interoperability.
For example, a Java application can access the information of an application
that runs on Microsoft .NET platform.
From the point of view of a user that retrieves information about the
Web Services available, each service is an XML file in WSDL (Web Service
Definition Language) format. The file describes how to deal with the
service, what to expect as parameters and results.
The client application generates an XML file in SOAP (Simple
Object Access Protocol) format and passes it to a component with Web
Services support functionality. Most often, SOAP communications between
the client and the server occur via HTTP. The client sends a SOAP requests
and the server, provided the requests is valid and corresponds to one
of the services available, returns a SOAP respond, that is an XML file
in the SOAP format.
The interface to Web Services functionality is transparent
to the user.
Now about what our project is concerned with. Even the
latest and most advanced Java Cards have very limited resources, which
makes it impossible to include client applications into the card applet
to deal with XML. The application developed within our project is consent
with the Java Card development mainstream and the application on the
host computer has advanced functionality to overcome above-mentioned
limitations.
The host application, using a WSDL file as incoming parameter,
can generate a Java Card applet in form a source file (.java file) that
includes all essential logic to generate a SMS request sent to OTA application
that acts as a proxy-server. This OTA application is a part of our project
and has the following functionality:
Receives incoming SMS from the Java Card applet
Parses these SMS, generates a corresponding SOAP
XML, and passes it to a Web service
Receives a SOAP respond from the Web service, parses
it, generates a corresponding SMS, and sends it to the card applet
that initiated the request.
This is the way that our application makes it easier and
more efficient to personalize SIM-cards. New services easily become
available for cellular phone users and exactly the way they were intended
by businesses, that is in form of Web Services. This solution eliminates
duality in Web Services design: one for non-wireless applications and
the other for wireless ones.
Web Services support ensures interoperability, so the
side receiving request does not have to be a Java application.
When it comes to programming the Java Card, the generator
eliminates the necessity to program SIM Toolkit API calls. This could
be potentially beneficial for Telcos because card personalization could
be done with no involvement of programmers.
The generator is a Java application that receives a WSDL
file as command line parameter and outputs applet source code on the
screen (the standard output device). The output, of course, can be redirected
into an arbitrary file. This solution has been chosen to make it as
easier as possible to integrate with existing SIM Toolkit IDEs, for
example, Schlumberger's Views). The generator comes with no GUI, which
was done on purpose. GUI has to be used from the IDE the generator will
be included into.
The future uses of a generator of this kind we see as
a part (extension, plug-in, add-on) of SIM Toolkit applications development
tools.
Developed components
The Java package (.jar file) includes the following components:
· XML parser to parse WSDL files and SIM Toolkit applet generation component
· Support classes for parsing WSDL and generating SIM Toolkit applets
· OTA application that receives SMS, containing incoming parameters
from the applet; translates them into SOAP requests; then receives SOAP
responds as results of those requests; and then sends SMS to the original
applet.
· Helper class for all SOAP related tasks.
The package uses Java classes from Java XML Pack from
http://java.sun.com (available for FREE). There have been used two packages:
JAXP for parsing XML files and JAXM for dealing with SOAP.
Description of the package
Source code (.java files) and byte code ( .class files)
jar file for the package ru.inetique.simsoap
Test WSDL file from www.xmethods.net
bat file to run the generator
Java Card applet that has been generated for the
test WSDL file
This document
PowerPoint slides
Description of the files included into the package:
WSDL2Applet.java is the main class. The generator gets
running by the following command (see run.bat):
Entering that particular command generated TemperatureService.java
file, which is a Java Card applet and used as a sample file.
SoapOta.java is the OTA application.
WSDLParser.java generates the code.
SAXParserWrapper.java parses the WSDL file.
SOAPBean.java sends/receives SOAP messages. SoapOta uses
this class for communicating with the Web Service.
The other classes are helper objects that store WSDL description
elements such as ports, messages, links, and etc. In other words, SAXParserWrapper
implements Java mapping for WSDL by translating XML description into
a set of Java objects.
Note: the generator and OTA application use JAXM and JAXP
package, which is why they have to be available via CLASSPATH.
Sample applet
A WSDL file from http://www.xmethods.net has been used
to generate the sample applet.The file describes the Web-service that
provides with temperature forecast by zip-code:
public TemperatureService() {
// Register to the SIM Toolkit
Framework
reg = ToolkitRegistry.getEntry();
// Define the menu entry
reg.initMenuEntry(MENU_ENTRY,
(short)0, (short)MENU_ENTRY.length, PRO_CMD_DISPLAY_TEXT,
false, (byte)0, (short)0);
reg.setEvent(EVENT_FORMATTED_SMS_PP_ENV);
zipcode = new byte[20];
userData = new byte[150];
}
Applet requests a zip code from the user and passes this information
alongside with web-services description to the OTA application. The
address of the application is stored in the array OTA_ADDRESS.
Further development
This is what could be added later:
1. Using standard mapping for WSDL when it is included
in Java (now it is JSR 110).
2. Paging for long messages, that is splitting long messages into several
parts for the applet and SoapOta.
3. Better type support.
4. Data processing, according to the business rules, before sending
back to the applet.
5. A demo Web Service could be done by using XML Pack too. Therefore
the whole demo project could be done by using Sun software only. Also
UDDI accessing facilities could be added to the project (that is, the
process of getting WSDL files to process could be automated). Because
these facilities do not interfere with the Java Card application itself,
they have not been included into our project.
For further information please do not hesitate to contact us at:info@inetique.ru