Mobile-enabled grid middleware and/or grid gateways - CiteSeerX

IST-2001-32133 GridLab - A Grid Application Toolkit and Testbed

Mobile-enabled grid middleware and/or grid gateways Author(s):

Piotr Grabowski, Bartosz Lewandowski

Document Filename:

GridLab-12-D.2-0001.tex

Work package:

Work Package 12 - Access for Mobile Users

Partner(s):

ZIB, Poznan Supercomputing and Networking Center

Lead Partner:

ZIB

Config ID:

GridLab-12-D.2-0001-1.0

Document classification:

GridLab Deliverable, Prototype, Internal

Abstract:

In this document we present our approach to giving users the opportunity to access grid resources developing appropriate grid middleware in form of Web Service for mobile users.

Last amendment date: 2003/06/03 & time: 10:17:56

Mobile-enabled grid middleware and/or grid gateways

IST-2001-32133

Contents 1 Introduction to Notification, Mobile Access and short document description

2

2 General system architecture 2.1 Server side technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Planed client side technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 JAVA 2 Platform Micro Edition Client - kSOAP package . . . . . . . . . 2.2.2 JAVA 2 Platform Micro Edition Client together with Servlet Gateway for Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Web Service Clients in GridLab . . . . . . . . . . . . . . . . . . . . . . . 2.3 Optional packages and 3-rd parties solutions . . . . . . . . . . . . . . . . . . . . . 2.3.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Apache AXIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 OGSA Transport Layer Security (httpg: protocol) . . . . . . . . . . . . . 2.3.5 Log4J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6 JBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3 3 3 4 4

3 Development 3.1 Zakopane scenario description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Message Box Application Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Software collaboration for first Message Box Java API . . . . . . . . . . . . . . . 3.4 Software collaboration proposal with final Web Services solution . . . . . . . . . 3.5 Message Box Application Description . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Java API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 New Java API methods and objects - User & User Profiles for Stand Alone Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Servlet Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Tomcat servlet container . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.5 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.6 Current state - development . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 10 10 10 13 13

GridLab-12-D.2-0001-1.0 GridLab Deliverable, Prototype, Internal

4 4 5 5 5 5 6 6 6

13 14 14 14 14

1/15


1

IST-2001-32133

Introduction to Notification, Mobile Access and short document description

In the first months of the GridLab project existence, we were focused on the Grid User needs. After several discussions it was clear that Users would like to have access to their grid applications even when they are not on-line via the standard network. The users are also interested in notifications: they want to know if something has happened with their simulation/application even when they are on their way or at home. They would like to be notified in different ways: using EMail, Fax or SMS that could be sent to their cell phones. Analyzing these needs and the strong constraints of the Mobile Devices (the cell phone, Personal Digital Assistants (PDA), or laptops) we have decided to use client - server architecture (with the main intelligence on the server side). We planned to develop web/grid services that could store application messages and send them as notifications to the user. And finally, we are going to develop a service that could allow the mobile user access to the grid. This service is going to work as a Grid Gateway for Mobiles - the client request is processed in the service and then forwarded to the rest of the grid - the response can be translated for the Mobile Device in the gateway or prepared in Services according the Mobile Device constraints - which the gateway is aware. This document describes in detail the mobile services we are developing, the architecture, the technologies and our point of view on grid middleware for mobile users.


2/15


2

IST-2001-32133

General system architecture

During internal meetings it was agreed that we need one common solution that would suit our users needs (and allow us not to rewrite some functionality for different platforms). Due to mobile devices constraints we also agreed to use the client-server architecture (with main ’intelligence’ on the server side). On the server side we could choose from different technologies; however, the final solution had to be easily accessible from other services and from the mobile client side, too ( for client we finally decided to use Java 2 Platform Micro Edition Mobile Information Device Profile - J2ME MIDP).

2.1

Server side technologies

We would like to use one of the standard technologies that could be found nowadays. Taking into consideration the fact that we are going to write codes for Java 2 Platform, we want to use the existing mechanism for it. The first technology is standard Servlet/JSP Pages (with Jakarta Tomcat as a container), the second one is Portlet technology and the third is the Web Service. 2.1.1

Servlets

Using this solution we had to write a dedicated Servlet/JSP framework supporting XSL transformations (XML-> WML, XML->HTML, XML->XML; the output from the transformation is sent to a client device). This is our choice for the beginning just because the Portlet framework was not ready yet and we need a temporary solution for mobile side tests. 2.1.2

Portlets

The Portlet framework is being made by the GridLab Portal Workpackage (WP4). With this solution we can use XSL transformations for serving content to the mobile side too. This is our choice for the future - it will allow us to avoid the redundancy of building two separate portals (one common and one dedicated). 2.1.3

Web Services

The GridLab project as a whole decided to make extensive use of a new emerging technology: Web Services. We were surprised by the fact that Web Services can be accessed from a mobile phone with a satisfactory connection and parsing speed. The question in this case was only if we were going to use WS or not. Now we can say that it is possible to benefit from Web Services, writing software for using mobile devices with MIDP, and we are going to do it for devices with stronger processors and larger memory without package size limitations. All services without the presentation layer which do not require Portal/Portlets can be implemented and served using Web Services.


3/15


2.2

IST-2001-32133

Planed client side technologies

There are plenty of technologies that are emerging in the mobile world nowadays. However, many of them work only on one or several hardware platforms - we have decided to choose between two that are widely distributed and seem to be the leading software platforms of the mobile future in the next years: WML browsers(using WAP) and JAVA 2 Platform Micro Edition. JAVA J2ME enabled devices (communication via HTTP/HTTPS/SOAP with server side) gives us better offline work, data can be stored in small internal repositories (the size of this repository is device dependent and is rapidly growing). Targeted devices for this solution are mobile phones and PDAs. 2.2.1

JAVA 2 Platform Micro Edition Client - kSOAP package

To access our Web Services server from the client side we can use the existing solution provided by Enhydra - these are kXML and kSOAP projects. The kXML project provides an XML pull parser and writer suitable for all Java platforms including Java 2 Micro Edition (CLDC/MIDP/CDC). Because of its small footprint size, it is especially suited for Applets or Java applications running on mobile devices like Palm Pilots or MIDP enabled cell phones. kXML was originally developed at the AI Unit of the University of Dortmund as a ”side product” of the COMRIS project. In the COMRIS project the API was used in the Information Layer module(s) to parse XMLified FIPA messages and to generate template-based XHTML pages. The template-based XHTML generation is currently used in the MLnet teaching server, too. kXML is also used in the Enhydra kXML-RPC and kSOAP projects. Enhydra.org is now the kXML provider, the current version is 2.1.6 and can be obtained from http://kxml.org/ site. kSOAP is an SOAP API suitable for the Java 2 Microedition based on kXML. Because of its small footprint it may be suitable to build SOAP-enabled Java Applets as well. 2.2.2

JAVA 2 Platform Micro Edition Client together with Servlet Gateway for Mobiles

Another solution we are going to implement for mobile devices with strong constraints is Servlet Gateway for Mobiles - the Mobile Command Center Server. Due to small processor power, memory shortages or provider politics (e.g. Nokia), there is a certain number of devices that can not use Web Services to connect to the server - they are to slow or do not give sufficient amount of memory for Web Services packages like kSOAP (additional constraints in Midlet (MIDP application) size). For such devices we are going to implement a gateway that will be accessed from mobile device with HTTP/HTTPS and then information is ’forwarded’ via Web Services to the next service. Support for HTTP is an essential part of MIDP compliant devices so there is always an open way to connect to the service. 2.2.3

Web Service Clients in GridLab

There are plenty of services in GridLab and we are going to use some of them (e.g. we are going to provide information about messages into WP8 MetaData, check WP6 Authorization Server for security information or steer WP8 Visualization Service for scaled down Visualization for Mobile Devices). The clients for our services will be the GridLab Applications that want to store messages or send notifications; these can be Portals or Cactus thorns or user applications.


4/15


2.3 2.3.1

IST-2001-32133

Optional packages and 3-rd parties solutions MySQL

MySQL is a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. See http://www.mysql.com/ for more details. 2.3.2

Tomcat

Tomcat is a servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process. Tomcat is developed in an open and participatory environment and released under the Apache Software License. Tomcat is intended to be a collaboration of the best-of-breed developers from all over the world. See http://jakarta.apache.org/tomcat/ for more details. 2.3.3

Apache AXIS

Axis is essentially a SOAP engine – a framework for constructing SOAP processors such as clients, servers, gateways, etc. The current version of Axis is written in Java, but a C++ implementation of the client side of Axis is being developed. But Axis is not just a SOAP engine – it also includes: • a simple stand-alone server, • a server which plugs into servlet engines such as Tomcat, • extensive support for the Web Service Description Language (WSDL), • emitter tooling that generates Java classes from WSDL, • some sample programs, and a tool for monitoring TCP/IP packets. Axis is the third generation of Apache SOAP (which began at IBM as ”SOAP4J”). In late 2000, the committers of Apache SOAP v2 began discussing how to make the engine more flexible, configurable, and able to handle both SOAP and the upcoming XML Protocol specification from the W3C. After a little while, it became clear that a ground-up rearchitecture was required. Several of the v2 committers proposed very similar designs, all based around configurable ”chains” of message ”handlers” which would implement small bits of functionality in a very flexible and composable manner. After months of continued discussion and coding effort in this direction, Axis now delivers the following key features: • Speed. Axis uses SAX (event-based) parsing to achieve significantly greater speed than earlier versions of Apache SOAP. • Flexibility. The Axis architecture gives the developer complete freedom to insert extensions into the engine for custom header processing, system management, or anything else one could imagine. • Stability. Axis defines a set of published interfaces which change relatively slowly when compared to the rest of Axis. Component-oriented deployment. You can easily define reusable networks of Handlers to implement common patterns of processing for your applications, or to distribute to partners.


5/15


IST-2001-32133

• Transport framework. We have a clean and simple abstraction for designing transports (i.e. senders and listeners for SOAP over various protocols such as SMTP, FTP, messageoriented middleware, etc), and the core of the engine is completely transport-independent. • WSDL support. Axis supports the Web Service Description Language, version 1.1, which allows you to easily build stubs to access remote services, and also to automatically export machine-readable descriptions of your deployed services from Axis. For more details see http://ws.apache.org/axis/ 2.3.4

OGSA Transport Layer Security (httpg: protocol)

Due to security requirements and lack of direct security support in Web Services we are going to use the existing solution from the Globus project. The current work in Globus is focused on OGSA which use GSI based on the implementation of GSI in the Java CoG Kit. To use GSI one must have valid credentials and a set of trusted CA certificates. OGSA provide transport layer security and SOAP layer security. The transport layer security is based around a new protocol called ’httpg’ to indicate GSI-enabled http-based protocol. The SOAP layer security is based on WS-Security, XML Encryption and XML Signature standards. The Java GSI implementation is an implementation of the Java GSS-API. It supports the GSS-API extensions and the new proxy certificate format specifications as defined by the Global Grid Forum. 2.3.5

Log4J

Inserting log statements into your code is a low-tech method for debugging it. It may also be the only way because debuggers are not always available or applicable. This is often the case for distributed applications. On the other hand, some people argue that log statements pollute source code and decrease legibility (Log4J authors believe that the contrary is true). In the Java language where a preprocessor is not available, log statements increase the size of the code and reduce its speed, even when logging is turned off. Given that a reasonably sized application may contain thousands of log statements, speed is of particular importance. With log4j it is possible to enable logging at runtime without modifying the application binary. The log4j package is designed so that these statements can remain in a shipped code without incurring a heavy performance cost. Logging behavior can be controlled by editing a configuration file without touching the application binary. For more details see http://jakarta.apache.org/log4j/docs/ 2.3.6

JBuilder

Borland(R) JBuilder(R) is a cross-platform environment for building industrial-strength enterprise Java TM applications. JBuilder 8 Enterprise simplifies Web and EJB TM development with two-way visual designers and rapid deployment to J2EE TM platform application servers. It provides enhanced productivity with UML TM code visualization, refactoring, code formatting, HotSwap debugging, unit testing, and version control integration. For more details see: http://www.borland.com/jbuilder/


6/15


3 3.1

IST-2001-32133

Development Zakopane scenario description

During GridLab workshops in Zakopane in September 2002 and Eger in April 2003 the end-users from WP2 showed us their needs and described it in the following scenario (taken from WP2 homepage). : ”Mobile Scenarios Devices: * Phones * SMS * MMS * Java-enabled * email * voice * PDA * Email * Standard web browsers * Java * Wireless * Email * text * attached text (logfiles, profiling) * attached images * Fax * text * images Configuration Either from the Cactus parameter file, or portal * personal phone numbers, addresses etc * preferred methods of notification * level of notification (important events, all events) * set whose simulations you want to monitor * set which class (black holes, production, test) of simulations you want to monitor * groups for notification * groups for interaction (who can cancel job) * groups for administration * security levels (eg notification only) Tasks * ”service” numbers to request information, as you can do now for the weather * user gets a message (text/voice) every day about the status of his resources (queues on different machines) * user gets a message (text/voice) every day about the status of his runs on his resources * user gets a message about important events on his resources (message of the day, machine is totally free, machine going down) * user gets a message about important simulation events (started, stopped, event horizon formed) * steer simulations from gui: e.g. pause, stop, stop with checkpoint, start, migrate, new parameter: e.g. blackhole::velocity = 2


7/15


IST-2001-32133

* steer simulations with voice messages Scenarios Setting it up In their personal portal profile users set up their collaborative groups, containing other portal users, who they may want to notify about events, or who may be allowed to interact with their simulations and data: * blackholepeople mikey, huey, luey, davey * gravwavepeople billy, milly, tilly, willy, mikey Each of these users will have to set up details for their choices of messaging, for example, mobile phone number and mobile phone model, email address and preference for HTML or plain text as well as usual connection speed, or fax number. When the user submits a new run through the job submission portal page, one option is to set the types of events on which messages should be distributed. This page is automatically generated from a default list, as well as from the Cactus simulation itself. The users can specify which events they want to be notified about, and who else (which collaborative groups) should be sent these messages. * new black hole event horizon found * supernovae bounce phase commenced * nuclear density reached at stellar center * pathelogical variable values * contraint values getting large * critical system events * data disk nearly full * queue time nearly up Steering From A Java-Mobile Phone: The simulation detects an event which might mean that the run should be stopped * A numerical relativity run detects a new event horizon, at this point the run could either be continued, or checkpointed and the data analysed and verified before continuing with the calculation. * A numerical relativity run detects a possible instability, and reports that one of the metric components has become very large, and needs a decision on whether to continue or to stop the run. The simulation informs the portal (for now) that it has an announcement, included in the announcement there are details to be announced (text message, who to notify, importance level?, security level?, attached images, parameter file, logfiles). The portal sends an SMS (as well as other media) out * Run GridLabID#1: ”ISCO 3.6” New apparent horizon found at t=100. Interaction possible on the GridLab portal. * Run GridLabID#2: ”Brill 2.3” Metric variable gxx now at 201.44. Interaction possible on the GridLab portal. A user receives the SMS on their phone. Since they have a Java enabled phone, they can go straight via a Java interface to the portal. If they have not accessed the portal from this phone before, they need to authenticate to the portal with their username and password. But after they authenticate once, this information is then securely held encrypted on the phone itself, and authentication is not needed for future communications. [If the phone is lost, similarly to a credit card, the user needs to either delete their proxy, inform the portal to disallow mobile interactions, or disable their phone communication with their service provider.]


8/15


IST-2001-32133

The portal recognizes that the user is accessing from a mobile device, and the user is presented with a menu of events from the portal message box which have not been acted on. The user can then easily go to the control screen for the relevant event. The user is presented with a control screen for the simulation, from where they can choose from different options: * stop the run straight away * checkpoint the run and then stop the simulation * continue the run * [pause the run] If the original event was announced to a group of people, and not to a single user, the whole group receive the SMS and see the announcement in their portal message box. How does authentification to the Cactus simulation work?? After one member of the group has taken action on the announcement, the portal (? or the simulation?) announces the action to the group with a further SMS. Visualization To a PDA: The simulation detects a noteworthy event which it can make an image for * A new black hole event horizon forms, and an image is created of its embedding in spacetime. * One period of a gravitational waveform is completed and an image of a line graph of the wave form is created. * Timing information indicates that the elliptic solver is getting longer and longer at each iteration. A bar chart is created to illustrate this slowdown. The simulation announces this event to the portal (or elsewhere?) the announcement includes a message in addition to the URL of the image (which is available because we are doing a Cactus run with the webserver module). The portal sends an SMS and/or an email with the URL location of the image.”


9/15


3.2

IST-2001-32133

Message Box Application Introduction

The aforementioned scenario requires that the WP12 developers should provide a new service that could send and store different kinds of messages. To fulfill the scenarios requirements we have been developing 3 applications. Notification server - Message Box, Mobile Client - Message Reader and Dedicated server for Message Box - Message Box Server (HTTP/HTTPS). The Message Box application was designed as Java API that can be used from an external package like Portlets or dedicated servlet server. This construction is described in the next point. The Web Service extension for Message Box application is described in the ”Software collaboration proposal with final Web Services solution” point.

3.3

Software collaboration for first Message Box Java API

Looking into a scenario and taking into consideration the lack of Portlet support at that stage, we have decided to use the existing ASC Portal software for tests and Super Computing (SC) 2002 presentation purposes, and to show the user what the mobile side of GridLab would look like. Because of the existing two portals (ASC and dedicated for mobiles) we have decided to make a central point the Message Box Application that saves messages into the MySQL database. The first portal saved info into a database, and the second one retrieved it and forwarded to the user.

Figure 1: SC2002 interactions between entities diagram.

3.4

Software collaboration proposal with final Web Services solution

After the Super Computing 2002 some users express their need for using Message Box API from the other GridLab modules than Cactus ASC Portal. Looking at the overall development progress in GridLab and taking into consideration technologies chosen by the GridLab TechniGridLab-12-D.2-0001-1.0 GridLab Deliverable, Prototype, Internal

10/15


IST-2001-32133

cal Board we have decided to use Web Services as the leading technology for our client-server architecture. There are two main services developed by WP12 team: the first one is the Message Box Web Service which will store, send and retrieve different kinds of messages, the second one will be the Mobile Command Center Service which will serve as a Mobile Gateway to other Grid Services (which includes simulation steering and visualization requests to the Visualization Service). The Mobile Command Center will serve request sent from the Mobile Side via HTTP/HTTPS for the mobile devices processor/memory weakness reason. This solution allow us not to require possession of the strongest devices on the market from the user.


11/15


IST-2001-32133

Figure 2: Diagram of Mobile & Web Services interactions between entities. GridLab-12-D.2-0001-1.0 GridLab Deliverable, Prototype, Internal

12/15


3.5

IST-2001-32133

Message Box Application Description

The Message Box Application was the first part of an application set that was prepared to serve notifications. Using this module a Java API developer could easily add messages from different sources into a database and send it or store it for future use. From the developer’s point of view the whole process of dealing with messages consists of obtaining MessageBoxInterface object from MessageBoxFactory and calling appropriate methods of this object (e.g. create, delete, send messages or message folders). In case of sending messages from the Message Box there is a possibility of choosing the appropriate way of doing so: as SMS, e-mail or fax. SMS can be sent by means of the SMS engine provided by GridLab WP4 Portal group which uses direct SMS sending from the ISDN desk phone. E-mails are sent via a standard Java Mail package provided by SUN. There is also a possibility of calling sendFax methods, although this module is not implemented and the fax is not sent. 3.5.1

Java API

As mentioned above the Message Box application was developed as Java API. The main interface is MessageBoxInterface. Apart from small changes connected with user objects there were no major changes from the SC 2002 version. For more information please check the first GridLab WP12 Access for Mobile Users deliverable GridLab-12-D.2-0001-1.0 - ”Mobile-enabled information exchange”. 3.5.2

New Java API methods and objects - User & User Profiles for Stand Alone Solution

In the first working version of the Message Box API that was prepared for SC2002 there was no need for internal user and user profile persistent storage - the ASC portal had its own repository and the unique user identifiers were the only needed data that allow us to properly maintain Messages Repository. However, for stand alone solution in which the Message Box evolve there is the need of persistent users repository to ensure the uniqueness of user identifiers which will address the Messages Database. This is due to possible different sources of Messages, which may have different user data with no unique identifiers. Apart from changes in the database structure we have added new methods to the MessageBoxInterface - all of them can be used for the Message Box User Database access or management. The new methods are: • User getUser( int iUserId) gets user object from the database using user database Id • User getUserByDN( String strUserDN) gets user object from the database using user Distinguish Name • User getUserByName( String strUserName) gets user object from the database using user login name • User createUser(String strUserDN, String strUserName, String strUserPasswd, String strUserLastName, String strUserFirstName, String strUserAddress1, String strUserPhoneNum, String strUserFaxNum ) creates user object in the database, using user data, if user object already exists in database it is returned and the new user is not created. Returns the created object


13/15

Mobile-enabled grid middleware and/or grid gateways 3.5.3

IST-2001-32133

Servlet Framework

Because the project was in its premature stage, we had to write our own servlet framework and test-servlet that uses Message Box API and serve output to the mobile user (via HTTP or HTTPS depending on the MIDP client’s will). 3.5.4

Tomcat servlet container

Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process. Tomcat is developed in an open and participatory environment and released under the Apache Software License. Tomcat is intended to be a collaboration of the best-of-breed developers from around the world. Tomcat is used as mboxserverhttp servlet container in WP12 and will be used to work with Apache Axis to run WP12 Web Services. 3.5.5

Web Services

For building and accessing the Message Box Service we are going to use Apache Axis. The methods already available with Java API will be present in the SOAP objects. The developer can refer to the remote objects just as if they were present in the local environment and like external modules just call methods from the Message Box Java API. 3.5.6

Current state - development

We have written and extended the Message Box Java API and currently we are moving the Message Box into a Web Services. In the next stage we shall implement the Mobile Command Center which allows us to give the user a possibility to steer application/simulation from the mobile device, which will be one of the points addressed to in the next WP12 deliverables: ”Small-bandwidth optimized adaptive grid services” and ”Minimal Grid Interface”.


14/15


IST-2001-32133

References [1] Krzysztof Kurowski, Jaroslaw Nabrzyski, Bogdan Ludwiczak. Document Publication Rules. GridLab 2002. [2] Eric M. Burke Java and XSLT. O’Reilly 2001 [3] http://java.sun.com/j2me/ JavaTM 2 Platform, Micro Edition (J2METM). Sun Microsystems, Inc.. [4] Vipul Gupta and Sumit Gupta KSSL: Experiments in Wireless Internet Security. http://playground.sun.com/ vgupta/KSSL/SMLI-TR-2001-103.pdf [5] kObjects kXML 2. http://kxml.org/ [6] MySQL AB MySQL. MySQL AB http://www.mysql.com/ [7] Apache Software Foundation The Apache Jakarta Project. 1999-2002, Apache Software Foundation http://jakarta.apache.org/tomcat/ [8] Apache Software Foundation The Apache AXIS Project. 1999-2003, Apache Software Foundation http://ws.apache.org/axis/ [9] Apache Software Foundation Log4j Project. http://jakarta.apache.org/log4j/

1999-2002, Apache Software Foundation

[10] Borland Software Corporation JBuilder(R). http://www.borland.com/jbuilder/


15/15