there is rather no need to send a big image files to old mobile devices or HTML to mobile device without a web browser. Some of this types as almost useless with respect to mobile devices, e.g. Currently, JeromeDL can handle five types of resources: PDF, RTF, document scans, HTML and URL links. To keep communication time as short as possible, additional data is sent only when requested. Therefore, it decreases the cost of communication with the JeromeDL server. Semantically enhanced search in JeromeDL attempts to find results ac- curately. Consequently, the first screen after initiating a mobile search module contains only one search field for entering a search query.

One of the most important differences between mobile and desktop applications, is the size of the information which can be shown to the user. Using mobile bookmarking module described later (see 4.3), user can add resources found during the search process to his/her bookmarks. After obtaining the search results (see Fig 4(c)), the user can request additional information about the resources e.g. A user can perform a simple search, advanced search (see Fig 4(b)) or even semantically enhanced search. The searching interface module attempts offer the same functionality as the classic web based interface for JeromeDL. Finally the user can also initiate a distributed search over an L2L (HyperCuP) network of JeromeDL instances.

The application checks automatically if the server is on-line before perform- ing any operations on it. A user can choose the library from a list of available JeromeDL instances or add a new one (see Fig 4(a)). It allows users to look for specific resources anywhere, anyplace and anytime. The search interface module enables searching on JeromeDL digital libraries. Business classes handle operations and store information about friends, user identity and messages (email and SMS). Operations are performed in separate, independent threads and results received from services are passed to the MIDlet class. It utilizes kSOAP functions to invoke FOAFRealm Web Services. All the network communication is done by the Worker class. It builds screens and shows appropriate information. The MIDlet class is responsible for the communication with user. DigiMe consists of a standard MIDlet class, worker class and a collection of business classes (see Fig 3). It will be possible to invoke Web Services using a secure (SSL) connection. In the next version of SOA for FOAFRealm, the session identifier will be more secure based on time-out mechanisms. External application receives the information after successful login. A special session identifier is requested to invoke any method. The SOA layer does not only expose FOAFRealm methods to the external application, but also provides secure access to these operations. The searching interface (next application module) uses simple servlet invoking and does not needs kSOAP or any other Web Services libraries (for more details see Sec 4.2). That is why we were forced to employ kSOAP - an alternative SOAP library for J2ME, which co-operates well with RPC/encoded messages. Axis builds SOAP messages in RPC style encoded Native J2ME SOAP implementation (JSR172 ), which can work with document/literal style only. FOAFRealm features are exposed through the Web Services Standard using Apache Axis platform.

They are based on services available in FOAFRealm (SOA layer). of DigiMe’s functions include: profile management and mobile bookmarking (see sec 4.3).

Digime the great