Home

Network technologies for Java-enabled, mobile devices

1. 85 7 6 1 Functionality and implementation testing esses 85 76 27 Testbed ce OR AREIS 85 7 6 3 Test specification and results sse eee 85 Ti O24 User les aS Ks et TRO 92 7 6 3 User test Yesult e A as 93 m 93 CHAPTER 8 8 85 2 95 8 1 COMPARING JINI AND JX D ties eot oett eet cott ti Eats obere a see Ea recta 95 Bile T Differences ereo a a e E ende tte M 95 8 1 2 Similarilies inpr R Mea a ns 96 8 1 3 Advantages and disadvantages seen 97 8 2 JINI AND JXTA ARCHITECTURES FOR EMBEDDED 8 98 8 2 1 Differences siis net en d ie e a teer tree 98 8 2 2 8 ST E e RA ERR te tede series 99 8 2 3 Advantages and disadvantages seen eene 99 8 3 INTEROPERABILITY BETWEEN JINI AND 100 100 8 3 2 Evaluation of the suggested solutions 102 8 4 RELATION TO OTHER DISTRIBUTED NETWORK TECHNOLOGIES 0 2 42221 102 5 4 T Web dd tps n re rige 102 8 4 2 Microsoft NET set Dee creer a en RR RE 103 8 5 THEIPROTOTYBE c
2. No Test case Desired result Result T 6 1 No contacts in the list The user is only capable of entering NT the menu T 6 2 Select a contact A screen for writing a message to the NT chosen contact appears T 6 3 Write a non empty message in the box The message is sent to the contact NT that appears upon choosing a contact and the user returns to the contact list and click OK view T 6 4 Write an empty message in the box An error message is displayed to the NT that appears upon choosing a contact user and the user returns to the mes and click OK sage screen 6 5 Write message that contains more Not possible The user will not be NT than 256 characters allowed to tpye more characters than 256 T 6 6 Write an message non empty or No message is sent and the user NT empty and click CANCEL in the returns to the contact list screen message box T 6 7 Click the MENU button The user is confronted with the con NT tact list menu T 6 8 Recieve a message from a contact The message will be displayed inthe NT when viewing the contact list recieve message view T 6 9 In the recieve message view choose The contact list will pop up NT cancel 610 In the recieve message view choose The user will be presented for a NT reply screen that gives him the possibility to write a message as for T 6 3 to 6 6 T 6 11 Receive a message from a contact The message
3. groupM enu add searchForGroup S tring int receiveMessage ITSMessage Figure C 9 Sequence diagram for viewing the group list and adding a new group Figure C 10 is the corresponding sequence diagram to the collaboration diagram in Figure 7 24 P eerNetwork Network Client seaichF roup String int ITSClient search String String joinGroup String String noE xisting Group create Group String noE xistingGroup create int java lang String java lang String poll int groupinfo receiveM essage ITSMessage listen java lang String java lang String java lang String Figure C 10 Sequence diagram for adding a non existing group Figure C 11 and Figure C 12 constitute an extended version of the collaboration diagram for sending and receiving messages presented in Figure 7 26 What might be noted is that the data format used by the network is hidden from the TSClient instance This is done by letting the ITSClient and the Network Client exchange information using an internal data type called ITSMessage NetworkClient fetches the information from the given ITSMessage and creates a Message to be sent to the PeerNetwork instance Appendix C ITS System UML diagrams and comments ITSClient 8 PeerNet work NetworkC ent ITSMessage String String String ITSMessage
4. F 3 xii List Of Figures FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU RE 2 1 CLIENT SERVER RE 2 2 PEER TO PEER ARCHITECTURE 2 1 0 0 000 00000 RE 2 3 ROUTERS IN HYBRID PEER TO PEER NETWORKS RE 3 JAVA 2 PLATFORM MICRO EDITION cccccceeeessssscscscecceeeeccececececscscscscsceseeeeeseseseneess RE 3 2 RELATIONSHIP BETWEEN J2ME CONFIGURATIONS AND JAVA 2 STANDARD EDITION 14 RE3 3 THE J2M E TREE tere ERI One E 15 RE 3 4 CLDC GENERIC CONNECTION eet nenne en 17 RE 3 5 HTTP NETWORK CONNECTION JCP 37 esses eene enne 18 RE 3 6 MOBILE CLIENT USING TO CONNECT TO INTERNET SERVICES 19 RE 3 7 STANDALONE SERVICE DOWNLOADED TO THE MOBILE DEVICE en 21 RE 3 8 SERVICE EXECUTION ON A REMOTE 21 RE 3 9 SERVICE CLIENT DOWNLOADED TO THE MOBILE DEVICE 2 2250 22 RE 3 10 MOBILE DEVICE TO MOBILE DEVICE SERVICES esee 22 RE 3 11 MIDDLEMAN ARCHITECTURE RE 4 1 JINI COMPONENT OVERVIEW 440 RE 4 2 HOW JIN
5. Figure 5 6 for 2 API The first version of JXME supports the following features Discovery of pipes groups and peers Able to create pipes both point to point and propagate pipes and groups Join groups Communicate with other J users through JXTA pipes 5 6 2 JXTA for J2ME Relay Service JXTA for JZME peers can only acts as edge or simple peers i e they cannot assume the role of more sophisticated peers that offer services to other members in the peer group The peers themselves can per form only basic tasks and heavier operations have to be done by peers called relays as shown in Figure 5 5 The relay is part of the Java 2 Standard Edition J2SE version of JXTA JavaJ and runs ona JXTA Rendezvous peer The relay service is responsible for the following Provide interoperability with JXTA protocol Represent the JXTA for J2ME peer in the JXTA network The relay should act as a proxy for the JXTA for J2ME peer and perform user group and peer discovery Other tasks are to create pipes and groups join groups and communicate The relay will also store all incoming messages for a JXTA for J2ME peer and the J2ME peer will periodically poll the relay to get its incoming messages Filter traffic The relay will filter all incoming queries from the network and respond on behalf of the wireless peer 51 JXTA Trim and optimize advertisements The r
6. String String 4 String int connected boolean 3stopPolling boolean false 8unsentMessages Vector Vector int BSiNetworkClient client ITSClient relayAddress String relayPort int clientName String static getInstance client ITSClient relayAddress String relayPort int clientName String NetworkClient al String groupld String boolean BSteaveGroup boolean BSisendMessage msg ITSMessage boolean BSisearchForGroup groupName String search Type int void ESicreateGroup groupName String void BSisearchContacts contactList String boolean BSisearchContact contact String boolean BSisetPollInterval seconds int BSicloseNetworkConnection ESiconnect handlelnfoMsg message Message handleAcknowledgeM sg message Message ESihandleDataM sg message Message Figure 6 Detailed class diagram for NetworkClient C 2 3 DatabaseClient Figure C 7 shows the detailed class diagram for the NetworkClient Appendix C ITS System UML diagrams and comments DatabaseClient userName String roupName String ontactName String lt static gt gt DBNAME String ITSDatabase GROUP RECORD int 1 lt static gt gt CONTACT RECORD int 2 rs RecordSt
7. In Jini services communicate with the lookup service using RMI which transfer serialized objects proxies to clients that ask for the service The prox ies can communicate with the services using any protocol JXTA communicates using XML or binary messages advertisements that are transfered using the protocols The protocols are independent on transport protocol Essentially the difference lies in that Jini networks consists of mobile objects that are transfered while JXTA networks consists of XML or binary advertisements Location of services is the last area of differences covered in this section Jini uses a central broker while JXTA does not Jini Lookup Service is not really central in any traditional sense since many may be available Contents on the Lookup Services may not overlap and redundant Lookup Services can be equally reachable and so making them naturally fault tolerant and easily load balanced when using auto matic discovery In the Jini vs sense the Lookup Service is more centralized because the lookup info is often located on a limited number of Lookup Services The Lookup Service is itself discovered not pre known In JXTA services are made public through advertisements and devices have to search for the services among all the peers in the network i e there is no central broker to contact In connec tion to this it can be seen that while JXTA seek to implement a pure peer to peer so
8. Figure 8 1 shows a scenario where two technologies A B want to communicate There are three possible scenarios for how this can be achieved as marked in the figure 1 A gateway solves the differences and maps between the communication mode used in A and B 2 A must adapt to support the way B communicate 3 B must adapt to support the way A communicate The next section continues with a description of some sample solutions on how to achieve interopera bility between Jini and JXTA and then moves on to a discussion around the different solutions 8 3 1 Solutions Interoperability between Jini and is not as trivial as many think The technologies are fundamen tally different in that Jini requires Java and is language independent ie Jini is based on object se rialization and proxies while JXTA peers communicate using XML To be interoperable some changes must be imposed in one way or another It would be much easier if one considers Java as present in the network All peer will then be able to communicate using both Java and XML Things get much more complicated if Jini services should be added to a pure JXTA environment where services is im plemented in different programming languages The different solutions described below ate discussed in the next section S 1 Surrogate Brigde S 2 XML support in Jini 5 3 JXTA as communication platform in Jini 5 4 JXTA resource
9. and related profiles 3 1 1 Connected Limited Device Configuration CLDC The intention of Connected Limited Device Configuration CLDC is to serve as the lowest common denominator building block for various kinds of resource constrained java powered devices CLDC needs to be complemented by profiles since it is not a complete self sufficient solution For instance all user interface aspects are outside the scope of the CLDC specification 15 Network capabilities in 2 primary topics addressed the CLDC 1 0 specification are the following areas Java language and virtual machine features Core Java libraries java lang java util Input Output Classes for handling streams of different types Networking general framework for network connection presented in section 3 2 Security Further discussed in section 3 6 Internationalisation Handles different encodings of character data correctly Version 1 1 of CLDC will not include significant extensions to the libraries in CLDC 1 0 but has as goal to make CLDC compliant with the Java Language and Virtual Machine Specification While CLDC 1 0 does not support floating numbers the expert group intend to include support in the revised version CLDC1 1 3 1 2 Mobile Information Device Profile Mobile Information Device Profile MIDP is a set of Java APIs that together with the Connected Lim ited Device Configuration CLDC provide a c
10. 122 Reference Library JumpStart XME XMEwp XTAdraf XTASec XTASpec XTAvn XTAws Kiely Knudsen Krishnan kSOAP KTopley Kumaran Lyng2001 MahLor Mahmoud me4se Project Jump online http www jumpernetworks com jumpstrt html fro J2ME Project page online http jxme jxta org Arora Akhil Haywood Carl Pabla Kuldip Singh JXTA for J2ME Extending tbe Reach of Wireless With JXTA Technology Sun Microsystems Inc March 2002 online http www jxta org project www docs JXTA4J2ME pdf Internet Draft at IETF JXTA v1 0 Protocols Specification http www ietf org internet drafts draft duigou jxta protocols 00 txt JXTA Frequently Asked Questions online http www jxta org project www docs DomainFAQ html Sun Microsystems Inc Security and Project X A online http www jxta otg ptoject www docs SecurityJ XTA PDF JXTA 01 0 Protocols Specification online http spec jxta org v1 0 docbook JXTAProtocols html Traversat Bernard Abdelaziz Mohamed Duigou Mike Hugly Jean Christophe Pouyoul Eric Yeager Bill Project Virtual Network Sun Microsystems Inc February 2002 online http www jxta org project www docs JXTAprotocols pdf JXTA web site online http jxta org Kiely Don Wanted Programmers for Handheld Devices Computer Volum 34 Issue 5 May 2001 page 12 14 Knudsen J
11. Find Lets a requestor discover a service description interface in the broker and retrieve it The requestor uses the description to create a proxy interface usually a SOAP proxy Bind The bind function provides the requestor with the ability to bind to a provider and consume its available services 56 Related work 6 2 3 Web Services and J2ME Access to Web Services from java enabled mobile devices should not be hard to accomplish The only requirement is the ability to handle XML and SOAP and there exists two project exploring both XML and SOAP for J2ME called KXML kXML and kSOAP kSOAP respectively Other XML parsers also exist like TinyXML and NanoXML but these were both ported to the in contrast to the KX ML that was specifically designed for CLDC What might be the problem is the resource consumption of a XML parser since MIDP enabled devices already has minimal resources Sun has taken an initiative to define an optional package to provide standard access for 2 to Web Services JSR 172 The specification request was accepted in the Java Community Process JCP in first quarter of 2002 and anticipated schedule is to release it in the summer of 2003 APIs that are intended to be included are APIs for basic manipulation of structured XML data i e parsing The package will be a subset of JSR 63 APIs for conventions for enabling XML based Remote Procedure Call RPC communication f
12. LI 0 Mes sage Element Message send ava lang String java lang String java Jang String Message il sendMessage ITSMessage Figure C 11 Sequence diagram for sending a message The same is the case when the NetworkClient receives a message from the network The message format is changed and the ITSClient is given an ITSMessage containing necessary information and does not have to concern itself with the data exchange of the network LTS Client Network Client PeerNet work poll int Mess age 1 5 ITSMessage String String String int get x recei eMessage TSMessa ge Figure C 12 Sequence diagram for receiving a message C 4 Collaboration diagrams This section presents the remaining collaboration diagrams of the ITSSystem The diagrams will be shown with reference to the corresponding sequence diagram as done in the previous section Figure C 13 shows the collaboration diagram of the corresponding sequence diagram shown in Figure 7 19 3 authenticateUser String 1 getlinstance client 2 geiuserNamet database ITS Client DatabaseClient Figure C 13 Collaboration diagram for login and authentication Appendix C ITS System UML diagrams and comments The diagram in Figure C 14 represents the collaboration diagram equivalent to the sequence diagram in
13. Manageability and information coherence data is concentrated in one place and as a result they are easy to manage and have no question of data consistency or coherence i e if a bit of data is found in the system the data is correct Security Centralized systems are relatively easy to secure since there is only one host that needs to be protected Major drawbacks are Scalability Theoretically since the number of clients increase the load and bandwidth demands on the server also increase This would eventually prevent the server from handling additional cli ents In practice a server may have enough resources to server the demands of its users as a result of the growing CPU and memory capacity Minar Bandwidth The bandwidth capacity has increased by a factor of 1076 since 1975 all according to Mootes5 law But most of this bandwidth is not used if everyone just goes to the same few sites to get their services Computational power Many people have invested in computational power that are oversize the processing power needed to use the most popular Internet applications like surfing the web and reading sending e mail In other words there might be a lot of unused processing capacity in the client today This suggests that the client side could do more of the processing than they do in cli ent server architectures Fault tolerance The network depends on central points namely server to provide setvice If the cent
14. NF 1 Network technology independence The network technology shall be hidden from the user and be independent of the application so that any network technology can be used Network technologies can be client server protocols and peer to peer technology One should easily be able to change JXTA for J2ME implementation with a HTTP and central server implementation 2 Run in SDK and JWT The prototype should run both in the Software Development Kit SDK and the Java Wireless Toolkit from Sun 3 Run on a JZME compliant device The prototype should be able to run on a cellular phone or PDA supporting J2ME for instance the Mo torola Accompli 008 NF 4 Usability The user should be able to use the service application without training and should get to know it within 10 min 5 Security Information that is exchanged between two parties in private room in the ITSSystem should not be avail able for other parties than the parties involved in the session NF 6 Availability The user should be able to connect to the network and register with the service in 90 of the cases NF 7 Reliability The service should run without problems for 12 hours without the user needing to start the application over again and login to the service If disconnected the user should be able to continue his session when logging on within 5 minutes 67 The Prototype NE 8 Cost The user should be able to control the cost of u
15. RE 7 6 USE CASE DIAGRAM FOR VIEWING THE GROUP 11657 RE 7 8 USE CASE DIAGRAM FOR ADDING en nnne en 66 RE 7 9 USE CASE DIAGRAM FOR VIEWING THE CONTACT 5 2 66 RE 7 10 USE CASE DIAGRAM FOR EDITING THE CONTACT 67 RE 7 11 THE ARCHITECTURE OF THE 9 70 7 12 CELL PHONE CONNECT TO THE 0000 70 xiii List Of Figures FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU RE 7 13 OVERVIEW OF THE CLASS DIAGRAM FOR THE 71 RE 7 14 DETAILED VIEW 72 RE 7 15 THE DATATYPE 5 655 0022000 0 00 a n a a 72 RE 7 16 DETAILED VIEW OF THE ITSCLIENT AND THE 73 RE 7 17 THE EXCEPTIONS IN THE ITSSYSTEM RE 7 18 STATE DIAGRAM FOR THE ITSCLIENT RE 7 19 SEQUENCE DIAGRAM FOR LOGIN AND AUTHENTICATION ccce enne RE 7 20 SEQUENCE DIAGRAM SHOWING HOW TO CONNECT TO THE NETWORK
16. tuit dde dors p D 1 D 2 1 Edit gro p list oi ede eet baste eee d i t de Makes tha Se D 2 D22 Add gro p 5st RE HERREN EUN eee CONGR ERA d D 2 D32 3 Delete gro p tede te dete eene re e HE EH ede ettet re D 2 D3 PUBLIC CGOMMUNICATION 5 D 2 D 3 1 Create and 5 enne D 3 D32 Cange group enin oed deett SEO tee Pg ce a bens D 3 IDE Mui D 3 DS ALERT MESSAGES 5 dee teo eed dete e tetur te eb EE eU PEE To D 4 APPENDIX 3RD PARTY SOFTWARE DEVELOPMENT TOOLS cereo E 1 E 1 JAVA 2 MICRO EDITION WIRELESS 0 220440080 00 E 1 2 POCKET a t eie been Pu ence Can E 2 3 THE JEODE PEATEORM s ec reae eee EET ELO ees ET EE TE ERE AER RR E 2 3 1 me4se Micro Edition for Standard Edition eene E 3 E 4 WEBSPHERE MICRO 0 0060044 000 0 3 APPENDIX PRESENCE AND INSTANT MESSAGING eee ee F 1 2 NP 2 F 2 1 JAIN SIMPLE Presence and JAIN SIMPLE Instant Messaging F 2 F 3 GENERIC PRESENCE AND INSTANT MESSAGING APIS FOR J2ME
17. 50 5 6 1 for 2 Peer The JXTA for J2ME Peer will provide the building blocks necessary to communicate with the for J2ME relay and indirectly with JXTA The first version of the API was presented in late March 2002 and is under constant change which should have minimum to no impact on the applications developed JXME API available consists of three classes PeerNetwor amp Message and Element Figure 5 6 shows the re lationship between the classes The PeerNetwork class is used to communicate with the JXTA network and uses Message to create messages to send to other peers A Message consists of one or more Elements describing attributes in name value pairs The API is implemented in a way that the underlying transport protocol could easily be changed as long as 2 Generic Connection Framework defined CLDC supports the new network technology PeerNetwork lt lt gt gt GROUP String lt lt gt gt PEER String lt lt gt gt String Element lt lt gt gt DEFAULT GROUP String Message i Element lt lt inclu gt gt BSiclose lt lt uses M Message BSigetData 4 etElement WSconnect BSgetMimeType etElementCount 1 1 n BSireate us BSgetName BSi static createlnstance BSgetNameSpace Wiisten WtoString BSisearch
18. Monitoring environment Peer groups permit peers to monitor a set of peers for any special pur pose for instance heartbeat traffic introspection or accountability specification does not dictate when where or why to create a peer group or the type of the group of the membership of the group and does not limit the how many groups a peer can belong to or if nested groups can be formed A peer group provides a set of services where the core services are specified by JXTA but additional peer group services can be developed for delivering specific services The core services are Discovery Service Membership Service Access Setvice Pipe Service Resolver Service Monitoring Service The services are implemented in one or more of the JXTA protocols or none and peer groups are not obliged to implement all these services 5 3 3 Network Transport Exchange of data between peers is made possible by the network transport layer a mechanisms to handle the transmission of data over the network In JXTA the concept of network transport is broken down in three parts endpoints pipes and messages Endpoints Endpoints are network interfaces used to send and receive data i e the initial source or final destination of any piece of data being transmitted over the network Input pipe Output pipe send Point to point pipe Propagate pipe Figure 5 2 Point to point and propagate pipes Pipes Pipes are vir
19. Network technologies for Java enabled mobile devices Master thesis Bjorg Peggy Sveen Lyngstad Trondheim July 2002 Norwegian University of Science and Technology o Faculty of Information Technology Mathematics and Electrical Engineering Department of Telematics Preface This report is the result of my master thesis and concludes my years as student at NTNU The master thesis was suggested by myself as a continuation of my project assigment that was carried out during the autumn 2001 I would like to give my thanks to everyone that have supported and assisted me during the past half year especially those who shared their thoughts around the subjects A special thanks must be given to Jorunn Kaasin for a valuable and creative co operation in the development of the prototype which is part of both our master thesis I would also give a special thanks to my supervisors Ulrik Johansen and Stale Walderhaug at SINTEF Telecom and Informatics for valuable comments my work to professor Rolv Br k for advices and to Joakim for reading and commenting the report Trondheim 8th July 2002 Bjorg Peggy Sveen Lyngstad Abstract Computers are changing radically size decrease and they become increasingly mobile As a result of the decrease in size the computers have limitations in capacity of processing and available memory The ev olution moves computers from being permanently attached t
20. Figure 7 20 2 connect 5 new Thread start 6 poll 1 getinstance ITS Client String int Strin 9 9 9 ITS Client NetworkClient 3 createlnstance java lang String 4 connect java lang String byte 7 poll int PeerNetwork Figure C 14 Collaboration diagram for connecting to the network Figure C 15 is equivalent to the sequence diagram shown in Figure 7 23 1 searchF orGroup String int ITSClient NetworkCli ent 5 groupE xist receiveMessage TS Message 2 search String String 3 polkint 4 Message PeemNet work Figure C 15 Collaboration diagram for adding an existing group Figure C 16 represents the collaboration diagram for the sequence diagram shown in Figure 7 25 4 menuContacts 1 getContacts client d database ITSClient DatabaseClient 2 searchContacts String 5 add searchContacts Stri 3 receiveMessage ITSMessage 6 receiveMessage ITSMessage network NetworkClient Figure C 16 Collaboration diagram for edit a contact list Appendix C ITS System UML diagrams and comments The collaboration diagram in Figure C 17 represents the sequence diagram shown in Figure 7 27 1 destroyAppt 3 connected leaseGroup gt gt Network Client 4 connected close java lang String java lang String java lang String 5 close
21. N lt lt include gt gt RES Peer Group Delete Contact Add New Contact Search for contacts Figure C 3 Use case diagram for private room Appendix C ITS System UML diagrams and comments C 2 Class diagram The class diagrams of Chapter 7 display the public and protected variables and methods of the ITSSys tem which is the most interesting part when the purpose is to understand and get knowledge of the sys tem For people who want to further develop or maintain the system it is necessary to have an overview of the entire system with private variables and methods as well This section shows the detailed class di agrams of the ITSSystem An overview of the classes and interfaces in the system are illustrated in Figure 4 MIDlet from jav ax microedition midlet Runnable from jay a lang Datatypes NetworkClient 55456922 ITSClient 1 1 4 lt lt usesP gt exception 1 DatabaseClient CommandListener from jav ax microedition Icdui Figure C 4 Class diagram showing the overview of the ITSSystem classes C 2 1 ITSClient The class diagram of ITSClient with all the public private and protected methods and some of the vari ables is shown in Figure C 5 Variables concerning the GUI elements like forms buttons and text fields are left out ITSClient boolean userName String group String BSnu
22. Trondheim are you NN N Figure 7 3 Example of usage when chat mode is private To be able to communicate with other in the same area the users have to join a group representing this specific area or distance Hither the user accesses a list of possible groups which exists and picks one of them or the user searches for a group by name If that group does not exist a new group can be created 7 2 Requirements Specification In the requirements specification phase of the system development all the requirements of the prototype are identified Functional requirements specify what the system should be able to do that is the function ality without focusing on the physical implementation Non functional requirements ate the implemen tation requirements and focuses on factors like performance robustness reliability etc UML use case diagrams will describe how a system will look to potential users but is most useful to communicate among the developers to obtain a common understanding of the system A use case diagram is a collec tion of scenarios initiated by an entity called an actor a person a setver etc and each functional re quirement is described by a use case diagram The actors identified in the ITSSystem s environment are The initiator This is the main user in the environment and is the user holding the mobile device and using the client in the ITSSystem The terminator The initiat
23. a PDA a cell phone and other devices Imagine printing out your email from your phone on the printer nearest to you at that mo ment just by choosing the print option or sending a fax to a friend This chapter aims at giving the reader an overview of the Jini network technology its features advantages and limitations as well as usage of the technology for embedded devices First it will give an introduction to Jini then present the architecture and core components of the architecture The rest of the chapter will focus on Jini solutions for embedded mobile devices like mobile phones and PDAs 4 1 Introduction to Jini Network Technology The objectives of Jini are to provide an infrastructure to connect anything at any time anywhere and enable network plug and work i e make every service joining the network available for other users without installation and configuration Jini Hardware and software distinction is abstracted by support ing a service based architecture instead of a computer or device network Kumaran Jini distributed architecture provides spontaneous networking of services where the term services refers to a set of functionality provided by any entity An entity can be a computer hardware device such as computer printer or scanner an electronic device for example audio and video equipment an electric device like microwave oven coffee maker or other household appliance a piece of software or a com bination
24. but when it comes to scalability it has shown to scale nicely That is why this architecture is considered a good architecture for peer to peer Minar 2 2 3 Where to use peer to peer technology The most obvious answere to why peer to peer technology should be used is to utilize the resources in the network sufficiently Especially embedded devices will gain much by using the technology since they can form their own network independent on the Internet architecture s limitations In areas where no infrastructure exists ad hoc networks might be used in rescue operations and for people to communicate from places where there exist other terminals but no infrastructure Peer to peer could replace search sites like Google and provide people out looking for information with up to date information In contrast to search sites today that update their databases once a day or once a week each peer would be responsible to return documents and other matches to the search right away Another area is in distributed computing This is a way of solving difficult problems by splitting the prob lem into sub problems that can be solved independently by a large number of computers Until now the most popular applications of distributed computing have not been peer to peer solutions Examples of 10 Background projects that has gained much attention is SETI home SETI that among other assignments analyses data from the universe and distribute the
25. client endpoints PBXs and other communication systems or devices to communicate with each other An example of us age is to establish and manage multimedia IP sessions SIP is by many predicted to become an important protocol in the future IP mobile phone environment and SIP based applications will be essential ena blers SIMPLE SIMPLE is a set of natural extensions made to the SIP protocol to support Presence and In stant Messaging The specification is the responsibility of the IETF working group SIMPLE 2 1 JAIN SIMPLE Presence and JAIN SIMPLE Instant Messaging Two specifications are undergoing the Java Community Process to become a standard API supporting presence and instant messaging in SIMPLE These are the JAIN SIMPLE Presence JSR 164 and JAIN SIMPLE Instant Messaging JSR 165 that differs from the SIP API for J2ME covered in appendix A in that the latter is platform agnostic and the former are not The specifications are covered under J AIN which is Java s packages for communication across Internet and Intelligent Networks and target at both the J2ME platform and the J2SE platform JAIN SIP API supports the SIP protocol and is dedicated to Java session control in the telecommunication and Internet industry JAIN SIP Lite is an abstract JAIN API to the SIP protocol that is dedicated to user agents run ning on both the J2SE and J2ME protocol JAIN SIP Lite is a lightweight definition of SIP for user agents including JZME d
26. or applications can be supported in the J2ME environment MIDP 2 0 is not yet re leased and not supported in any device and so this section focuses on the network possibilities related to MIDP version 1 0 Several possible scenarios exist and the four main scenarios are presented in this section All uses the network in some way even though not always in the execution of the service They differ in advantages 20 Network capabilities in 2 and limitations and some might not be able be realized directly yet because of the limited network support of MIDP 1 0 3 3 1 Standalone service downloaded to the mobile device The application is available from remote servers and the mobile terminal establishes a connection and downloads the application he desires as shown in Figure 3 7 Access Network 4 Services Services Mobile Client Mobile Server Client Netwotk Figure 3 7 Standalone service downloaded to the mobile device application is installed and configured on the mobile device and is executed on the mobile device without network connection game is an example of such an application Because of the lack of net wotk connection dependence the service can execute independent of whether the network is available not The drawback is the lack of network connection which suits some applications like games But games are also likely to gain advantages of a network connection to play
27. 1 1 DEPENDENCIES IN CHAPTER 8 TABLE 7 1 PROTOTYPE REQUIREMENTS renaire e EO EAE A TABLE 7 2 TEST SPECIFICATION AND RESULT FOR LOGIN TABLE 7 3 TEST SPECIFICATION AND RESULT FOR SETUP TABLE 7 4 TEST SPECIFICATION AND RESULT FOR GROUP OVERVIEW 88 TABLE 7 5 TEST SPECIFICATION AND RESULT FOR GROUP EDITING esee 88 TABLE 7 6 ALTERNATIV TEST SPECIFICATION FOR 4 5 AND 6 89 TABLE 7 7 TEST SPECIFICATION AND RESULTS FOR GROUP CHAT PUBLIC MODE 90 TABLE 7 8 TEST SPECIFICATION AND RESULT FOR CONTACT OVERVIEW PUBLIC MODE 91 TABLE 7 9 TEST SPECIFICATION AND RESULT FOR CONTACT EDITING PRIVATE MODE 91 List Of Tables xvi Chapter 1 Introduction The greatest challenge to any thinker is stating the problem in a way that will allow a solution Bertrand Russel Computers are changing radically Processing power and memory capacity continue to double every 18 months according to Moore s Law and the size decreases Scientists predict that within the next few years the most prevalent computers will be small mobile wireless devices such as cell phones personal digital assistants PDA and pocket sized PCs IDC a market research firm projects that the worldwide annual shipment of intelligent handheld devices will grow from about 20 million in 2001 to about 62 mil lion by 200
28. 3GPP TS 171 specification describe the same for the third generation mobile devices 4 2 Wireless Messaging The purpose of the Wireless Messaging API JSR 120 is to define a set of optional APIs that provides standard access to wireless communication resources so that 3rd party developers can build intelligent connected Java applications The initiative for this JSR which now is out for public review until the end of June came from Siemens and they also have the Specification Lead Wireless Messaging API WMA provides a basic MessageConnection and Message framework with gen eral mechanisms for establishing a messaging application which 15 independent of the underlying mes saging protocol Examples of such protocols are GSM Short Message Service and CDMA SMS The architecture could also be used for receiving GSM Cell Broadcast short messages which is a unidirec tional data setvice where messages are broadcasted by a base station and received by evety mobile station listening to that base station JSR 120 4 3 Java Speech API Java Speech API 2 0 JSR 113 extends the work of Java Speech API 1 0 and is supposed to incorporate speech technology into user interfaces of Java programming language applets and applications The Spec Appendix A Additional packages for J2ME CLDC MIDP ification Lead is Conversational Computing Corporation and the expert group was formed 2nd quarter of 2001 The API is supposed to specify a cross pla
29. Bluetooth links Two of the PANs are connected to an IP network one via a LAN access point and the other via a GPRS UMTS mobile phone The advantages of 5 is that new technology can be incorporated quickly since they are able to support different access technologies all with ad hoc functionality The intended use of ad hoc networks is in areas where there is no available infrastructure or the infra structure is down as a result of an accident Examples of such scenarios are rescue operations or military operations in faraway places In urban areas ad hoc networks can be used to faster utilization and ex tended coverage and local sharing of documents Figure B 3 shown an example of usage of ad hoc on an airport where PDAs mobile devices and portable computers communicate with each other and with access point to other networks like HiperLan 2 and WCDMA Bluetooth Ge Figure B 3 Airport scenario Eric2000 Appendix ITSSystem UML diagrams comments This appendix contains some information about the ITSSystem like total view of the use case di agrams and the class diagrams and all sequence and collaboration diagrams not already presented be fore It also includes a discussion of the non functional requirements that was not relevant for the evaulation of JXTA C 1 Use case The use cases of the prototype ate collected in three diagrams one diagram for the public mode one diagram for the
30. Even though these abilities are limited there exist solutions on how to over come them like the middleman architecture Next generation of MIDP will provide further capabilities and additional profiles are under development at Java Community Process JCP Lyng2001 3 1 Java 2 Micro Edition J2ME The history of J2ME reaches back to Sun s lab where they managed to create a virtual machine imple mentation on a Palm Pilot This project was called the Spotless Project Spotless and the virtual machine created was moved into the K Virtual Machine KVM This virtual machine together with the Spotlet demo was released for early access at JavaOne 1999 The project moved into standardization via the Java Community Process JCP and came out as a set of configurations and profiles and the new name Java 2 Micro Edition Sun had made a couple of attempts to make java smaller prior to the introduction of the K virtual ma chine Those where the Java Card Embedded Java and Personal Java J2ME will replace Embed ded Java EJava while Personal Java PJava is under standardization to be included as a profile in 2 called Personal Profile J2MEFAQ Java Card JCard aims at running Java programs on smart cards i e has different goals than 2 and will exist as a technology on its own J2ME has a software layer stack consisting of three layers on top of the Host Operation System of the device These are the Java Virtual Machine L
31. Nokia The initiative started in the beginning of 2001 and was publicly launched in April 2001 Initial specification is expected to be published by the end of 2001 The objective is to establish a common mobile Instant Messaging and Presence Service IMPS specifi cally optimized for the mobile environment The solution is intended to be transport independent i e capable of being used over many different data protocols in use by wireless and networked applications For this reason Wireless Village bases the specification on XML and aims at making it easy to expand Examples of protocols that can be used are Short Message Service SMS Multimedia Messaging Service MMS GPRS and SIP but initially the specification will support SMS and MMS The specification does neither specify the user interface or restricts the types of device that the product can support thus making is easier for vendors to incorporate in existing solutions Communication between users range for simple text messages to rich multimedia content based mes sages The representation and structure of data on the device or within the networked data repository will not be specified by the protocols but they will describe how IMPS protocol data is represented over the network F2 SIMPLE Session Initiation Protocol SIP SIP is an IETF standard signalling protocol that can be used to estab lish modify and terminate sessions IP network It enables IP telephony gateways
32. PUBLIC ROOM eren enne nnne RE C 3 USE CASE DIAGRAM FOR PRIVATE ROOM RE C 4 CLASS DIAGRAM SHOWING THE OVERVIEW OF THE ITSSYSTEM CLASSES C 3 RE C 5 DETAILED CLASS DIAGRAM FOR ITSCLIENT c ccccccccssesssceececeessssceeececessnssaeeeeess C 3 RE C 6 DETAILED CLASS DIAGRAM FOR NETWORKCLIENT C 4 RE C 7 DETAILED CLASS DIAGRAM FOR DATABASECLIENT C 5 RE C 8 SEQUENCE DIAGRAM FOR JOINING AN EXISTING GROUP ccccccsssesssseeeecsessssceeeeees C 5 RE C 9 SEQUENCE DIAGRAM FOR VIEWING THE GROUP LIST AND ADDING A NEW GROUP C 6 RE C 10 SEQUENCE DIAGRAM FOR ADDING A NON EXISTING GROUP RE C 11 SEQUENCE DIAGRAM FOR SENDING A 55 RE C 12 SEQUENCE DIAGRAM FOR RECEIVING A 55 RE C 13 COLLABORATION DIAGRAM FOR LOGIN AND AUTHENTICATION RE C 14 COLLABORATION DIAGRAM FOR CONNECTING TO THE NETWORK RE C 15 COLLABORATION DIAGRAM FOR ADDING AN EXISTING GROUP eee RE C 16 COLLABORATION DIAGRAM FOR EDIT A CONTACT LIST see RE C 17 COLLABORATION DIAGRAM FOR CLOSING THE CONNECTION AND EXIT RE SCREENSHOT OF THE WIRELESS TOOLKIT FROM SUN 2 RE E22 COMPAQ IPAQ esc oett e mmonooooonon 00 00 1 1 0 xiv List Of Tables TABLE
33. Provider and Broker An API for J2ME is under devel opment to provide access to Web Service for J2ME enabled devices Microsoft NET is Microsoft s answere to the next generation of distributed networking and is built up around many components like the NET Framework XML Web Services Servers Clients and Tools The NET Framework is the programming model or infrastructure for the NET platform and consists of two parts the Common Language Runtime CLR and the NET Framework class library CLR is re sponsible for handling the runtime services like language integration security and resource management The NET Framework class library is a collection of reusable types that can be used to develop applica tions It consists of several libraries that provides standard functionality persistent data management SQL XML data manipulation and libraries for application development Microsoft NET have an im plementation for PDAs and mobile phones called NET Compact Framework that is a subset of the Framework 60 Chapter 7 Prototype Start by doing what s necessary then do what s possible and suddenly you are doing the impossible St Francis of Assisi A prototype application was developed as part of this master thesis The goal was to illustrate some of the features of JXTA for J2ME in use with MIDP and how data services can be used on next generation of mobile terminals As a result the pr
34. Requirements seen enne nennen 63 7 2 2 Non functional Requirements esee ente nnne 67 7 2 3 Requirements and prototype versions sse 66 7 2 4 Summary of requirements esses eene eene eene nennen nne 69 KA DESIGN N 70 L3 TheMrchitecture s t ou REDI 70 73 2 lass i s ded ee ed de e bt p trei testas 71 7 3 3 State Diagram for the ITSClient essere 74 7 3 4 Sequence and collaboration diagrams seen 74 IMPLEMENTATIONS rto tete eet e a dee te 79 74 I Sereen lowa et tre od aede RU iubere 79 7 4 2 Error and exception handling sse 81 74 3 Parallelism 2 itte tet ipe e dem dee e 82 7 4 4 Minimal number of instances sse eene enne nennen 82 74 5 Authentication dn ptem EEE 83 7 4 6 The search functionality eese eene enne 83 7 4 7 Network independence ein e E E E enemies 83 7 4 8 Group membership as Og E ue a ie 83 TAQ User interface sce a t ve Gee eo UR He ACRI NRI VE i 84 KILESSYSTEM IN THE FUTURE 84 7 5 1 Location based technology sse eee 84 TED ITI 84 84 7 6
35. The group menu appears OK Table 7 4 Test specification and result for group overview Test number T 3 2 is not tested since private communication is not supported in this version of the pro totype The group menu reference in T 3 4 is further investigated in the next subsection Group list editing Testing the group list editing requires the user to start the application and log in with or without changes to the setup This will bring the user to a screen showing the different group sin the database if any exist In this screen tap the MENU button The test cases presented here have this screen as starting point No Test case Desired result Result T 4 1 Select Setup from the menu and Enter the Setup screen OK click OK 4 2 Select Add group from the menu Enter the screen for adding a new OK and click OK group 4 3 Select Delete group from the menu Get a list over groups to delete if any OK and click OK T 4 4 Select Exit from the menu and click The application closes OK OK 4 5 In the add group view write new If the group does not exist it will be NOK group name and select Exactly added to the group list and a search search and then click OK for the a group that exactly matches the groupname supplied is started If the group exist nothing will happen The application returns to the group ovetview screen T 4 6 In the add group
36. The input is caught and handled by a listener This makes the ITSClient capable to receive messages from NetworkClient with ordinary call to the receiveMessage method NetworkClient will at initialization initialize and a thread that is responsible for polling the network This thread is unaffected from later method calls from I TSClient on NetworkClient Another solution to the NetworkClient thread is usage of a Timer that starts at certain time intervals It might have been more suitable since a timer can be set to execute at the supplied time interval regardless of the time it takes to handle the incoming message On the other hand timers is not always supported in the hardware and therefore and will therefore not be the best solution 7 4 4 Minimal number of instances Figure 7 13 illustrates the overview of the classes in the ITSSystem The diagram states that only one ITSClient one NetworkClient and one DatabaseClient can exist in an application To ensure this both NetworkClient and DatabaseClient use factory methods to handle initialization of these objects The fac tory method checks whether an instance already exists and if so it returns the existing instance of the object If no instance exists the object will be instantiated and a reference will be kept for later retrieval 82 The Prototype 7 4 5 Authentication Mobile terminals are personal and are mostly used by only one person the owner As a result usern
37. VU Location Reposito Meeting A Server P ER gt Place oa ae O Figure 8 7 JXTA in AMIGOS solution 8 7 Scenarios for the future There are different scenarios on how the future of distributed peer to peer networks will be and which solution is the best This section will point on some main areas of interests 8 7 1 Personal Area Network PAN Jini and is the first step towards an environment where all devices can discover each other and form Personal Area Networks PAN that is to say network technologies are independent of existing or non existing infrastructure Using on top of an ad hoc network technology that is based on a radio interface will provide such an environment The goal of JXME is this PAN scenario in addition to inde pendence from the relay which requires more resources than there exists today 111 Discussion 8 7 2 Improvements to JXTA Discovery in Jini and JXTA takes time today but improvments to the technology and transport network technologies might improve this If JXTA is to succeed it has to prove the community that it is a frame work with advantages more promisting than that of Microsoft NET and other competitors In the end the success of JXTA lies in its ability to move from a research project to a useable framework that is adopted by developers and the community Other improvements to is to define what type of ap plications the technology is best suited fo
38. a suite of MIDlets to be executed on a java enabled device An optioinal file called the Java Application Descriptor JAD which is used to manage the application can accompany the JAR file Retrieval of the application can be done either by Over The Air downloading or by ordinary downloading to the pc and then usage of a cradle or IR connection if available is not formally included in version 1 0 but will be part of version 2 0 of MIDP MIDP2 0 MIDP 2 0 which is soon to be released also includes other improvements This includes security in do main and netwotk additional networking functionality extensions to the user interface and inclusion of a small sound API It was also suggested to include a small XML parser but this is left out for further investigation 16 Network capabilities in 2 User interface extensions includes extension to the low level user interface to allow greater game func tionality and layout control for larger screen sizes A basic sound API called Mobile Media API JSR 135 is also included and allows easy and simple access and control of basic audio and multimedia re sources The security issues added will be discussed in section 3 6 while the extension of the network abilities will be covered in chapter 3 2 2 2 Networking in J2ME Wireless Java applications are by their nature network centric However the devices that these applica tions run on ate less predictable Th
39. according to the level of secu rity IEEE IEEE has several standards including standards for testing and test documentation The test documentation standard IEEE Standard for Software Test Documentation from 1998 829 1998 is available online for a fee It describes a set of software test documents that will provide a common form of reference and increase the manageability of testing The 1991 version is available at 829 1991 This test document will not follow any standard as it would be too extensive to such a small application First it will provide a description of the testbed used in the testing and then presents the test specification test results and comments The test specification covers all the functional requirements of the prototype even though only part of the requirements is implemented 7 6 1 Functionality and implementation testing functional testing should verity the functional design against the functional requirements The test should also detect possible internal inconsistencies and errors in the functional design and validate the functional design against the users needs In practise the functionality testing is executed for the first time in the implementation and this was the case for this system development As a result the design diagrams were somewhat changed during the implementation Implementation testing can be performed by comparing the implementation with the functional design and by testing
40. are hard to solve As research in mathematics continues it is very possible that someone will discover a way to solve most of the modern cryptographic algorithms But for today it provides protection for sensitive data and there are not many acceptable alternatives Knudsen Gollmann 26 Network capabilities in 2 Eavesdropping on insecure communications links be counteracted services mechanisms from communications security Important security services or aspects include Confidentiality Other people should not be able to see sensitive information that is sent over the network Integrity Ensure that the data is not getting changed or corrupted in any way Authentication The process of proving identity Cryptography provides solutions for each of these security aspects Integrity Check Functions also called message digests digital signatures and encryption algorithms also called chipers Knudsen Goll mannp Integrity Check Functions Applies a hash function to a large piece of data to transform it into a small piece of data If only one bit of the original data 15 changed it will result in a totally different value The result of applying a hash function has several names like hash value message digest and checksum It is also sometimes referred to as a digital fingerprint An example of a hash function in use is the Secure Hash Algorithm SHA 1 Digital signatures A digital sig
41. built upon the Generic Connection Framework defined in CLDC that provides a consistent way to access and organize data in a resource constrained environment MIDP implements the HTTP 1 1 protocol but further support of sockets and datagram is to be provided in the next version of MIDP Services or applications can be used and accessed in several ways using MIDP Both by downloading the application to the device to run locally to execute all on a remote server and only retrieve the processed data to the mobile device or a combination of these two approaches The hope is that in the future two mobile devices will be able to communicate independent on the infrastruc ture Today MIDlets are dependent on a relay that acts on behalf of it to access a network But doing so enables the MIDlets to use more advanced network technologies like RMI and CORBA New technol ogies that use this architecture are the Jini network technology and the JXT technology Use of Blue tooth will remove the dependence on a relay but will bind the device to use Bluetooth for all network connections MIDP also have limited security especially when it comes to wireless networking Packages to ensure integrity confidentiality and authentication are needed but not available An API is under development and in the mean time the open source project Bouncy Castle can provide 2 with a cryptography package But adding cryptography to an application or system will not necessari
42. can join the network and instantly make new resources available to the whole network Fault tolerance Failure or shutdown of any particular node does not impact the rest of the sys tem i e a service is not unreachable due to a single point of failure Scalability In theory the more hosts that are added to a decentralized system the more capable a decentralized network becomes The drawbacks of decentralized architectures are Manageability and information coherence Distributed networks are widespread and as a result they are difficult to manage In addition the data in the system 15 never fully authoritative i e a bit of data that is found cannot be trusted to be correct Security The networks tend to be insecure in the sense that it is easy for a node to join the net wotk and statt putting bad data into the system Scalability Scalability was listed as an advantage but only in theory In practice the algorithms that are required to keep a decentralized system coherent often carry a lot of overhead The system may not scale well if the overhead grows with the size of the system Minar Peer to peer is often mixed with ad hoc netwotks see appendix B and many claims it is the same phe nomenon One may say that peer to peer is a paradigm and ad hoc is a realisation of the paradigm where the peer to peer functionality is placed in the lower layers of the protocol stack and therefore is depend ent on the physical medi
43. choices to application developers Krishnan The objectives of the JXTA Project are based on what is considered shortcomings in many peer to peer systems Comp2001 Gong Interoperability Platform independence and Ubiquity Interoperability in is achieved by designing the framework to enable interconnected peers to easily 39 JXTA locate each other communicate with each other participate in community based activities and offer services to each other seamlessly across different P2P systems and different communities Many peer to peer 2 systems are built for delivering a single type of services Napster for example provides music file sharing ICQ provides instant messaging and Gnutella provides generic file sharing These systems are incompatible because of the lack of a common underlying P2P infrastructure Each vendor creates their own user community duplicating effort in creating software and system primitives commonly used by all P2P systems Developers that want to offer the same setvice to two different communities will have to develop the same service twice or develop a bridge system between the communities technology is designed to be platform independent i e it is independent of programming language system platforms and networking platforms The API of many P2P systems is based on a particular op erating system and a specific network protocol and as a result it is u
44. data among computers in screensavers to see if there is life be yond our solar system 2 3 Existing Peer to Peer P2P applications As with all these new concepts a range of projects has been started to provide the necessary technology to realise the concepts This includes projects like Napster ICQ and Gnutella As most peer to peer net work applications they are not purely peer to peer but have a hybrid peer to peer architecture A short overview of these projects which are some of the most well known peer to peer applications will be pre sented in this section 2 3 1 Napster The Napster Napster protocol is composed by clients and servers and seems in the first place to be nothing like a peer to peer networking application The reason why it Napster is introduced to be the originator of the peer to peer paradigm is that it is the first service that take advantage of the possibly enormous amounts of free storage placed in the Internet clients One of the problems of using this unused capacity was that clients did not have a static IP address as a result of the ISP s dynamic IP address assignment This made DNS lookup impossible for address reso lution The solution was to introduce a proprietary protocol that made it possible to bypass the DNS problem and update the dynamic client IP addresses at real time This was first introduced by ICQ in 1996 The Napster protocol works on top of existing Internet and utilizes a proprietary na
45. experience with similar programs and little technical knowledge The rest were telematics and computer science students from NTNU The test persons were first shortly introduced to the service and then they got a list of tasks to fulfil Dur ing the user test the users comment on difficulties and came with suggestions to improvement Some of the problems they had were related to the user interface on the specific emulator Other problems came because an emulator combines the input possibilities of a mobile device with the input devices like mouse and keyboard of a personal computer These types of problems are not taken into consideration in this section None of the test persons were given a user manual before the testing started The reason for this is that in real life users usually want to try out a new program by testing and failing and the user manual is mostly used as a complement Independent of this a user manual is written and can be found in appendix D The tasks that the user were confronted with is listed below 1 Start ITSSystem and log in using SUPER as username 2 Add the group Selbu to the group list and join this group 3 Send some messages Communicate with other users 4 Add the group Trondheim to the group list and join this group 5 Send some message Communicate with other users 6 Set the number of messages to be viewed to 2 and the polling frequency to 3 in setup The Prototype 7 Contin
46. for group or contact with the exact same name as the entered name or to get a search result of groups or contacts with similar names In private mode the user will get a list over online contacts after joining a group and the menu will include options for editing the contact list in addition to most of the existing options There will also be a screen where received messages ate printed and the user gets the possibility of answering the message Figure 7 29 illustrates the flow for a future version of ITSSystem Some of the screens from the previous screen flow are left out because there are no changes SETUP SAVE Tal Menu MENU F4E Delete group Search group OSearch result CANCEL B OExit Change group OK CANCEL CANCEL OK Search result MENU Choose user ED ED Search group Private room Delete contact 2Change group Setup JExit SEND OK Search Delete een Y CANCEL contact contact ew message HELLO CANCEL ANSWE Figure 7 29 Screen flow for future version The next subsection will discuss some implementation issues and the screens illustrated in this section will help getting a better understanding of our solutions 7 4 2 Error and exception handling The prototype has different levels of error handling This includes handling of external errors outside the control of the prototype
47. in a P2P network 5 3 2 Peer Groups Peer Groups is a collection of peers that have a common set of interests J XT ASpec Peers self organize into peer groups and each peer group have a unique identification The JXTA protocols describe how a peer may publish discover join and monitor peer groups The background for introducing peer groups was to divide the network space a need that arose when all peer were able to communicate using the same protocol Earlier P2P solutions were specialized and pro ptrietary and their associated protocols divided the usage of the network space according to application i e for file sharing you used Gnutella for instant messaging ICQ Peer groups divide the P2P network into groups of peers with common goals which are based on the elements in the list below Wilson Scoping environment Peers typically forms and self organize based on the mutual interest of the peers and groups allow the establishment of a local domain of specialization Peer groups can for example be divided based on application they wish to collaborate on as a group or because they want to exchange services only among the members of the group and not the entire P2P network 43 JXTA Secure environment Groups create a local domain of control in which a specific security policy can be enforced It limits the access to peer group resources by forming logical regions without respect to actual physical network boundaries
48. is stored for later NT when writing or recieve a message to retrieval that is to say when the user form another uset leaves the current screen and return to the contact list view Table 7 8 Test specification and result for contact overview public mode Private mode is not implemented in the current version of the prototype and so the above tests have not been performed Contact list menu private mode Testing the contact list menu requires the user to start the application and log in private mode with or without other changes to the setup From the group overview the user must select a group to join and will upon joining a group be presented for the contact list In the contact list view the user must click the MENU button The test cases is presented in Table 7 9 have this as their starting point No Test case Desired result Result T 7 1 Select Setup from the menu and Same result as T 5 8 NT click OK 1 72 Select Add contact from the menu Enters the screen for adding a new NT and click OK contact Table 7 9 Test specification and result for contact editing private mode 91 The Prototype No Test case Desired result Result 7 3 Select Delete contact from the Enters the screen for deleting con NT menu and click OK tact T 7 4 Select Exit from the menu and click The application exits NT OK T 7 5 In the add gr
49. is the act of instantiating the surrogate object and making the call to begin the surrogate s execution while execution is the steady state of a run ning surrogate When a surrogate is executed it can accomplish anything that other Java programs can do for example access other Jini services or provide Jini services themselves During execution the sur rogate object can communicate with devices using any preferred communication protocol such as IP Bluetooth or any proprietary protocol The last two stages of the life cycle is deactivation i e stop ping the surrogate and disposal ie remove the objects associated with the deactivated surrogate JiniSAO Kumaran surrogate host resides host capable machine which is a system that allows the downloading of code can run a surrogate is patt of a Jini network and is accessible to the entity offering the surrogate Jini surrogate architecture assumes that there exists a host capable machine that is connected to both the 36 Jini Network Technology interconnect and the Jini network The surrogate host is responsible for monitoring the interconnect a logical and physical connection between the surrogate host and the device An interconnect strategy is needed to connect the device and is an addition to the surrogate architecture The interconnect strategy described the interconnect protocol between the device and the surrogate host as well as interconnect
50. java lang String java lang String java Jang String 2 closeNetworkConnection ITSClient PeerNetwork Figure C 17 Collaboration diagram for closing the connection and exit 5 Discussion of the non functional requirements This section provides a discussion of the non functional requirments that are not relevant for the evalu ation of JXTA Usability NF 4 states that a user should be able to use the service application without training and should get to know it within 10 minutes A developer designing an graphical user interface GUT for small devices must make it obvious for the user to understand i e be userfriendly In addition he must consider wheth er to make a solution that everyone can understand at once without using a manual or a solution that in the first place is not obvious to understand but where the user can get the desired screen without too many steps The user tests relieved that the GUI of ITSSystem is realtively easy to understand when you have used it for some time but is in some cases not obvious to understand in the first place mostly be cause of the lack of confirmations The best solution would surely be to make the program both very userfriendly and with a natural screen flow which requires a limited number of steps for the user to ex ecute what he desires Security NF 5 is concerned about the security of TSSystem especially according to private room There are th
51. lightweight security and dynamic class loading capabilities Anhinga Virtual Machine AVM A virtual machine implementation of the M2MP and J2ME CLDC extension targeted to run on small mobile wireless devices 37 Jini Network Technology MIDP extension An extension to J2ME MIDP to add lightweight APIs for reflection object serialization marshalled objects and RMI An API for the Many to Many Protocol will be sup plied through the Generic Connection Framework Anhinga Device Profile ADP A profile implementation of the above specification targeted to run on mobile wireless devices Jini Mobile Edition JiniME A variation of Jini Network Technology built on the above infra structure and providing federated service architecture for distributed applications running on mobile wireless devices Anhinga Space A distributed tuple space service patterned after JavaSpace and built on the above infrastructure It will provide tuple space shared among a group of mobile wireless devices Proof of concept applications An application to demonstrate and study the above infrastructure including chat instant messaging collaborative groupware and others The current status of the project is that a Many to Many protocol and a RIT class file Library which lets a program synthesize a class at run time has been developed 4 6 Summary Jini is a distributed network technology designed to handle dynamic environments Th
52. messages from other users when the user is either in the states of private and public mode This is not totally correct since the user can receive messages when viewing the chatting menu or writing a new message as well but the message will only be visible when returning to the communication screen either in public or private mode When the user is in the state calls View group menu no groups are joined and the user get the possi bility to edit the group list to join a group or to view and edit the setup In View chat menu the user sees a menu much the same as the group menu but with some other se lection options The View chat menu state gives the user a possibility of selecting among several alter natives Change group Add group Search contact if in private mode Delete contact if in private mode Setup In this way the user can always add new or delete existing groups contacts and edit the setup easily The diagram does not consider possible error situations Exit will always end the program 7 3 4 Sequence and collaboration diagrams Sequence diagrams and collaboration diagrams illustrated the interaction between objects in a system in time and space respectively Since these diagrams show the exact same information this section will il 74 The Prototype lustrate some of the communication that occurs between object with sequence diagrams and others with collaboration
53. network functions when concentrating on networks of computers mobile de vices and PDAs ate Distributed operation Dynamic network topology Variable link capacity i e less connection stability and variety in connection speed as well as vaty ing network coverage Devices with limited capacity Possible high latency connection Since embedded devices have limited capacity like a small processor small amount of memory and bat tety driven this has to be taken into account when the device becomes part of a network As a result all algorithms and mechanisms implementing the network functionality must be optimized for small power usage Applications written for embedded devices to operate over a network should also be able to adapt to sudden changes in the transmission quality The reason is the variable communication quality in wire less networks which makes it difficult to guarantee for the services that is advertised for the device 2 2 Network architecture and technologies Developing applications executing locally on an embedded device may be useful enough for some but most users demand connectivity to a network They want to be able to have access to services anywhere at any time regardless of device Traditional network technology has some limitations that puts restrictions on applications and reduces the applicability To compensate for these drawbacks and allow for sharing of applications over a net work dist
54. on a central server to provide services instead the services are distributed among the participating nodes and the nodes act as client router or server depending upon the query it receives Hybrid Peer to Peer architectures are dependent upon a central server to provide access to services Several applications have been developed that uses peer to peer network architecture for example Nap ster ICQ and Gnutella 12 Chapter 3 Network capabilities in J2ME You see things and you say Why But I dream things that never were and I say Why note George Bernard Shaw Back to Methuselah Java 2 Micro Edition J2ME is the latest contribution to Sun s Java Platform that in addition consist of Java 2 Standard Edition J2SE and Java 2 Enterprise Edition J2EE It is a collection of APIs focusing on consumer and embedded devices ranging from telematic systems to mobile phones and Personal Digital Assistants PDAs This chapter gives an introduction to the Java 2 Platform Micro Edition J2ME with focus on the Con nected Limited Device Configuration CLDC and Mobile Information Device Profile MIDP It is meant as background information to the master thesis as the possibilities and limitations of CLDC and MIDP was covered in a project assignment last autumn Lyng2001 The network abilities of CLDC and MIDP are the only area that will be covered in detail as this is of interest to this master thesis
55. party objects and recognizes that the delivery of the distributed notification may be delayed Jini transaction model is designed to coordinate distributed objects It is lightweight supports two phase commit and allows the system to handle object oriented transaction handling The model does not de fine the actual mechanisms involved in the transaction but provides rules for the objects involved in the transaction In addition it uses the distributed leasing protocol in Jini An implementation is the Trans action Manager service presented in section 4 2 3 4 2 3 The service component An important concept within the Jini architecture is the service components which denotes the entities that have come together to form the Jini community Such entities could be either hardware and software or a combination of hardware and software A service can be composed of other sub services and is iden tified as java objects within the system Each service has an interface that defines the operations that can be requested by that service and also reflects the service type Kumaran The interface representation of services separates the actual implementation of the service from what the service does and hides that the implementation can change over time and whether it is implemented hardware or software It also hides the fact that there might be multiple implementations The base in terface can be extended to combine or add new functionality For e
56. requirements The first two non functional requirements stating that the system should be network technology inde pendent and run in SDK and JWT are fulfiled in ITSSystem 1 0 Non functional requirements related to JXTA for J2ME are discussed in this section while the rest can be found in appendix C Execution on a J2ME compliant device The third non functional requirement states that the prototype should run on a JZME MIDP compliant device Since access to a device with J2ME MIDP was limited and the available iPaq was not J2ME com patible a lot of time were used to find out how to execute the application on the iPaq The tools and technology inspected during this phase are presented in appendix E and the possible reasons for why we failed to test the application on the iPaq are presented here The Jeode platform seemed like a good solution since the emulating software had been tested by the JXTA for J2ME development team The ITSSystem started on Jeode but when the application tried to connect to the relay the application closed and no network connection seemed to be possible As a re sult the Jeode solution was turned down A drawback is that the Jeode runtime environment with librar ies is large and only a small fragment is used by the emulator In addition the emulator imposed certain problems due to the emulator being under development Next solution was the IBM Websphere The solution took less space than Jeode but needed the app
57. responsibility of the AMIGOS server in several parts that in co operation constitutes and fulfil all services in AMIGOS Meeting places and location servers appear as Jini services and the authentication is left to the meeting places The central user profile repository can also appear as a Jini service and be used by the meeting places to authenticate the users that wants to join the meeting place This solution provide a highly distributed environment with the advantages and lim itations that implies The solution also moves the Meeting Places from being virtually and globally avail able to being localized on a unit in the Jini environment C The AMIGOS service as a JavaSpace Another Jini solution is to use JavaSpace Service to provide meeting places JavaSpace is a Jini service that provides a distributed persistence mechanism for objects in the Jini community A JavaSpace can be found through Jini Lookup Services and can for example hold meeting places for a certain location or area As Jini JavaSpace uses leasing that ensures if a service leaves the room the leases will expire and the connected users will be disconnected from the service This solution have similarities to the first so lution only that the AMIGOS server is replaced with a JavaSpace Users can create meeting places and 107 Discussion place them in the JavaSpace for others to find Solution C solves the complexity introduced in solution B when a JavaSpaces i
58. seconds before it automatically closes and returns to the previous screen If you could not connect to the network or could not get access to the database containing your group list the program will close since the program depends on the network and the database to function larger than 0 The value must be 3rd party software development tools Different tools exist to develop J2ME CLDC MIDP applications and get it running on an iPaq Some of these tools are presented shortly in this appendix Sun has provided a toolkit for help developers in the implementation and some companies have devel oped virtual machines for the iPaq Among other Insignias Jeode platform j9 virtual machine included in their WebSphere development environment 1 Java 2 Micro Edition Wireless Toolkit Java 2 Micro Edition Wireless Toolkit J2MEwtk offers a lightweight way of building and testing a MIDP project It comes with the CLDC and MIDP libraries utilities javadoc documentation and exam ple MIDlets The utilities include emulators for different mobile phones and an easy way to edit the JAD file and the properties included in the file Some of the emulators are shown in Figure E 1 with the wire less toolkit in the background The current version of the wireless toolkit is based on the technical specifications of 2 Connected Limited Device Configuration CLDC 1 0 and of Mobile Information Dev
59. sent The prices for GPRS data are too high and should be notably reduced if a data service like ITSSystem will be worth using Letting the user set the polling frequency can result drawbacks like unneccessary use of bandwitdth An additional functionality could be that the application detected how often messages arrived to the specific user and that the polling frequency was set based on this information and on the current network load Appendix ITSSystem User Manual The Intelligent Transport Service System I TSSystem 1 0 is a communication service for travelling peo ple You can get in touch with other users on the road being in the same area or travelling the same distance as you are The goal of the service is to get the most out of your ttip and not let queues or road work etc get in the way You can achieve this by participating in a group which represents an area ot a distance and exchange information with the other members of this group Each group represents a chat ting room and you will receive every message sent to this group You can keep a list of your groups lo cally and edit this list whenever you want This document will help you to understand the functionality of the service and describes how to use it D 1 Getting started The ITSSystem 1 0 is only about 25Kbyte and can be downloaded to any 2 compatible mobile de vice How the program is loaded onto the device and how the program is found sta
60. service platform that enable users to establish and participate in Meeting Places i e virtual rooms where interaction optionally take place between the participants An interesting scenario would be to include Jini and or JXTA in this service platform and this section will discuss possibly scenarios for incorporation The below suggested solution for usage of Jini and JXTA impose a fundamental change to the suggested architecture for the AMIGOS service They move it from being very centralized to becoming decentral ized Today s vision of AMIGOS is to use central places where the users can fetch information about meeting places and where services are registered In addition visible meeting places for a user is depend ent upon localization and user profile Localization is handled by the central servers and all the central servers share a repository that holds the user profiles In a distributed architecture for the AMIGOS service the following components must be present User profiles that authenticate the users and hold their preferences Meeting Places that users can create join participate and leave Location server The rest of this section will cover Jini solutions and JXT solutions in relation to AMIGOS In each of these two cases the suggested solutions explained then the advantages and limitations of the solutions are discussed 106 Discussion 8 6 1 Jini Jini requires the use of the Java progr
61. static is not a desirable feature in such applications the alternative would require the application to wait for all the data to arrive and to place it into the correct order based on how the packets were sent before the data could be officially received This speed degradation is likely to be unacceptable in applications that are streaming audio or video content Several datagram protocols are available but the most common is the User Datagram Protocol UDP There exist interfaces that are designed to allow implementations of different types of datagram proto cols like IP and WDP along with proprietary beaming protocols that take advantage of the packet nature of datagram for transmitting data UDP requires simpler headers and metadata than TCP as a result of the unreliable nature and is therefore most useful when speed of delivery is crucial In the J2ME envi ronment datagram can be useful due to their simplicity as a lighter weight data transport alternative to TCP For example might it be useful when beaming data over an It port between two devices Another feature of datagram is that the programmer controls the packet size of the transmission If you want to send a large amount of data in a single packet you can up to 64kB You can also send a single byte in a packet 3 3 Service scenarios for MIDP appliations After being through different protocols for data transfer it is time to focus on the different possibilities in which services
62. the list of groups that can be deleted is shown to make the user able to delete more groups T 4 13 Click the CANCEL button in the list The selected group are not deleted OK of groups to delete screen and the user is redirected to the group menu screen T 4 14 Delete all groups and view the delete No groups are listed and the OK but OK group screen ton is not shown Table 7 5 Test specification and result for group editing Test T 4 5 and T 4 6 did not pass The functionality is implemented in the prototype but the for J2ME proxy does not support search yet and so it was impossible to test it sufficiently As a result the prototype is not tested for T 4 10 and T 4 11 since this functionality is not implemented as a result of the above observation The alternative implementation of T 4 5 and T 4 6 is documented and tested in Table 7 6 No Test case Desired result Result T 4 15 Write the name of the group in the If the group does not exist itis added OK text box in the Add new screen and to the local hashtable and the group select Exactly editing menu reappears T 4 16 Write the name of the group in the Same result as for T 4 15 OK text box in the Add new screen and select Similar Table 7 6 Alternativ test specification for T 4 5 and T 4 6 Group chat public mode Testing the group chat requires the user to start the application and log in public mode with o
63. the profile includes class libraries that are far more domain specific than the class libraries provided in a configuration Applications are written for a particular profile and uses implicit the configuration since a profile is implemented on top of a particular configuration By designing this layered design the appli cation is portable to any device that supports the specific profile it is written for A device can support multiple profiles JavaCard J2ME Personaljava Figure 3 3 The J2ME tree Several profiles are under development and version 1 0 is already released for some The relation be tween the different configurations and profiles are shown in Figure 3 3 and explained below For CDC three profiles are being standardized at the moment the Personal Basis Profile JSR 129 and Personal Profile JSR 62 the RMI profile JSR 66 and the Game Profile JSR 134 All these are based on the Foundation Profile JSR 46 as shown in the figure above e CLDC have two main profiles and several specialized profiles that add functionality to the main profiles The two main profiles are the Mobile Information Device Profile MIDP JSR 37 MIDP1 0 and the Personal Digital Assistant Profile PDAP JSR 75 focus fot this assignment is the CLDC and and so the rest of this chapter will provide infor mation about these two specifications Many of the technologies discussed in later chapters will also be available for
64. use cases related to private mode and one diagram for the use cases that are considered common for both public and private mode Login exchange of messages and selection of modus are use cases related to both modus and these use cases are presented in Figure C 1 lt lt include gt gt Select Modus Types of modus 1 Private Room Public Room lt lt include gt gt Change modus Initiator Login Peer Group Receiving messages Sending messages Terminator New Message Reply Message Figure C 1 Use case for login exchange of messages and modus Appendix C ITS System UML diagrams and comments C 1 1 Public room The use cases specific to public room are related to the group list joining of group change of group and editing of the group list Use cases that are related to public room are shown in Figure C 2 N xd Initiator View Group List lh N Edit Group List Change group lt lt include gt gt EE Peer Group Delete Group Add Group Search b Search for groups Add Existing groupCreate new group Figure C 2 Use case diagram for public room C 1 2 Private room The private room specific use cases are related to the contact list but also include the public room use cases shown Figure 2 The additional use cases for private mode are illustrated in Figure C 3 FN Initiator View Contact List View Contact Status Edit Contact List
65. view wtite a new If the group does not exist and a NOK group name and select Similar and search for all groups that contain the then click OK given name as a substring is started If the group exist nothing will happen The application returns to the group ovetview screen Table 7 5 Test specification and result for group editing 88 The Prototype No Test case Desired result Result 4 7 Write an existing group name in the No new group is added and no search OK text box select Exactly or Similar is started since the group already and click OK exists The user returns to the group menu T 4 8 Do not write a group name in the text No group is added to the list An OK box and click OK error message is displayed to the user and the user returns afterwards to the add group screen T 4 9 Click CANCEL in the add new group No group is added to the list The OK screen uset is redirected to the menu screen 1 410 Select View search result from the The user is presented with a list of NT menu and click OK result from the most current search with the Similar option T 4 11 Select a group in the View search The group is added to the group list NT result screen and clik OK and the user is redirected to the group editing menu T 4 12 Choose a group in the list of groups The group will be deleted from the OK to delete and click OK database and
66. www compaq com products handhelds index html IP Surrogate Project online http developer jini org exchange projects surrogate IP index html Jini Technology IP Interconnect Specification online http developer jini org exchange projects surrogate IP sa ip pdf Stang Mark Whinston Stephen Enterprise Computing with Jini Technology TT Pro Jan uary February 2001 120 Reference Library TProf J2ME_spec 2MEFAQ 2MEwtk JAIN Java XTA JavaSpace JCP Jini JiniJ O02 JiniOrg JiniSA JiniSAO JiniSASpec Jini WD JSR 179 5 113 5 120 Yeager W Williams J Secure Peer to Peer networking the example YT Profes sional Volume 4 Issue 2 Mars April 2002 page 53 57 Java Specifications Requests related to J2ME online http jcp org jst tech j2me jsp J2ME Frequently asked questions online http java sun com j2me faq html J2ME Wireless Toolkit online http java sun com products j2mewtoolkit The JAIN APIs online http java sun com products jain Platform project the Java 2 Standard Edition J2SE version of online http platform jxta org JavaSpaces Service Specification online http wwws sun com software jini specs jinil 1html js title html Java Card Technology online http java sun com products javacard Java Community Process online http jcp org Jini Network Te
67. 3 2 Class Diagrams The service consists of three main classes the NetworkClient the DatabaseClient and the ITSClient NetworkClient is responsible for the network connection while the DatabaseClient is responsible for in teracting with the database on the mobile device ITSClient is the main class and takes care of the inter action with the user through a graphical user interface GUI and uses NetworkClient and DatabaseClient to obtain necessary information class diagram giving the ovetview of the system hiding attributes and operations methods is illus trated in Figure 7 13 The responsibility for implementing the different parts 1s also shown as notes in this diagram MIDlet Jorunn from jav ax microedition midlet Kaasin Runnable from jav a lang pea h Bj rg 22 NetworkClient STREETS ITSClient Lyngstad 1 1 1 CommandListener lt lt usesP gt from jav ax microedition Icdui Datatypes exception 1 Database Client Bj rg amp Jo runn gt Figure 7 13 Overview of the class diagram for the ITSSystem Every interaction the network is done through the NetworkClient This class will be implemented using for J2ME and will then be able to interact with any device on the JXTA network NetworkClient takes care of the basic tasks associated with peer group membership like group and user discovery and the joining and creation of g
68. 4 Kiely The evolution moves computers from being permanently attached to being mobile devices and this mo bility results in a change from hard wired network connections to wireless connections Any randomly assembled collection of small mobile wireless devices can be expected to present a highly heterogeneous computing environment This comes as a result of the fact that there is no one manufacturer that dom inates the operating system marked for embedded devices They use a variety of special purpose operat ing systems and processors and are programmed in different languages Further mobile devices is constantly on the move coming into and going out of contact with new devices as their users move around 1 1 The assignment Today mobile wireless devices are used as an extension to the existing wired network and thought of as just additional client devices with wireless connection For example cell phones can be used to send and receive email and instant messaging SMS But the devices have an unfulfilled potential to form personal area networks PANs and participate in distributed applications New technologies will soon make this scenario possible Applications for mobile wireless devices must overcome the diversity in platforms and operating sys tems To get an application running on all devices it must platform independent This can be achieved by use of the Java Programming Language Java is not just a language but also a softw
69. 4 5 The Anhinga Project The goal of the Anhinga Project Anhinga is to develop variations of JAME CLDC Jini and JavaSpace technologies which will run in ad hoc networks of small mobile wireless devices like PDAs cell phones pagers and pocket PCs Administrators of the project is representatives from Department of Computer Science at Rochester institute of Technology an United States university located in Rochester New York State The background for the Anhinga project is that mobile wireless devices represents a potential for build ing distributed communication and collaboration applications that will operate on spontaneously formed ad hoc peer to peer networks of the devices themselves without requiring central servers or a fixed network infrastructure But this potential remains unfulfilled due to lack of distributed middleware de signed specifically for the small mobile wireless device environment The project seek to develop an in frastructure to support distributed computing specifically to support collaborative applications running on wireless ad hoc networks of mobile computing devices Components of the infrastructure are listed below Many to Many Protocol M2MP A simple protocol for communicating among a group of mobile devices in the vicinity in an ad hoc wireless network This will eliminate the complications of traditional packet routing by using broadcast messages J2ME CLDC extension Create an extension that adds
70. 8 2 Jini and JXTA architectures for embedded devices Jini and JXTA have chosen different ways to solve how embedded devices can connect to the Jini and JXTA network respectively Jini has developed the Surrogate Architecture while JXTA has several project targeting different devices among other the for JZME The most interesting case in relation to this master thesis is to compare the surrogate architecture to the JXTA for J2ME project in the JXTA com munity Jini Surrogate Architecture and JXTA for J2ME cannot be compared directly since the surrogate archi tecture is a specification of a framework while JXTA for J2ME is an implementation of JXTA aimed at embedded devices supporting 2 CLDC and CDC JXTA for J2ME provides an architecture that can be compared to the Jini surrogate architecture but the architecture is based on the network capabilities of J2ME MIDP As a result of this fundamental difference the discussion below has to take this into consideration The section comparing the differences and similarities of Jini surrogate architecture and for J2ME takes the overall solution of both technologies into account but assume that the devices using the architecture might support either J2ME CLDC or CDC The section will first consider the differences and similarities and then move on to the advantages and disadvantages of the two specifications 8 2 1 Differences The difference between Jini Surrogate Architecture
71. AP Protocol Specification v 1 1 online http www w3 org TR SOAP The Spotless System online http esearch sun com spotless Sun Microsystems Inc online http www sun com Superwaba online http www superwaba org Microsofts INET i mobile terminaler Telecom April 2002 online http www telecom no art 5064 html Transport Layer Security TLS online http www ietf org rfc rfc2246 txt Topley Kim Building Wireless Web Clients Pitfalls of MIPD Part 1 online http www onjava com pub a onjava 2002 04 17 j2me html Universal Description Discovery and Integration UDDI online http www uddi com Vasudevan Venu A Web Service Primer online http www xml com Ipt a 2001 04 04 webservices index html W3C Web Services Activity web site online http www w3 otg 2002 ws Waba online http www wabasoft com 125 Reference Library White Wilson WSDL WV XML White James P Hemphill David A Java 2 Micro Edition March 2002 Manning Publications Co Wilson Brendon J Prentice Hall 2002 Web Service Definition Language WSDL Specification 1 0 online http www w3 org TR wsdl Wireless Village online http www wireless village org Extensible Markup Language XML online http www w3 otg XML 126 Additional packages for 2 CLDC MIDP This appendix presents some of the packages unde
72. E SIP SIPPING SMS SOA SOAP SPP SSL TCP TLS UDDI UDP UMTS VAME WAP WLAN WSDL XML Public Key Infrastructure Peer Membership Protocol Peer Resolver Protocol Remote Method Invocation Remote Procedure Call Rendezvous Protocol Service Discovery Application Profile Service Discovery Protocol Secure Hash Algorithm SIP for Instant Messaging and Presence Leveraging Extensions Session Initiation Protocol Session Initiation Proposal Investigation Short Message Service Service Oriented Architecture Simple Object Access Protocol Serial Port Profile Secure Socket Layer Transmission Control Protocol Transport Layer Security Universal Description Discovery and Integration User Datagram Protocol Universal Mobile Telecommunications System Visual Age Micro Edition Wireless Application Protocol Wireless LAN Web Service Description Language Extensible Markup Language 117 Abbreviations 118 Chapter 11 Reference Library 3GPPsip 829 1991 Acc008 Amigos Amigos01 Amigos02 Amigos03 Amigos04 Amigos05 Anhinga Avantel Bouncy Brandis CLDC1 1 Comp2001 Comp2001 3GPP requirements on SIP online http www ietf org internet drafts draft garcia sippine 3epp reqs 03 txt 829 1991 IEEE Standard for Software Test Documentation from 1991 online http www ustreas gov hrsolutions docs test Motorola Accompli 008 Features online
73. I EXTENDS THE 0 8000 RE 4 3 DISCOVERY AND INTERACTION WITH SERVICE RE 4 4 JINI SURROGATE RE 5 1 THE 3 LAYER 44000000 RE 5 2 POINT TO POINT AND PROPAGATE 2200 RE 5 3 PROJECT JXTA VIRTUAL TLS TRANSPORT 2 00 000 0 46 RE 5 4 THE JXTA PROTOCOL STACK 0 ccccccccccessssssecececsccsccececesesenssseececsesessaeeecesesenstsaseceeesenes RE 5 5 JXTA FOR 90 i eed aea RE 5 6 JXTA FOR J2ME RE 6 1 THE AMIGOS ARCHITECTURE cere 6 2 GENERIC WEB SERVICE 000 ese sse esses RE 6 3 SERVICE ORIENTED ARCHITECTURE SOA RE 6 4 MICROSOFT NET FRAMEWORK A A RE 7 1 USER INFORMING OTHER USERS ABOUT QUEUE IN AN AREA RE 7 2 EXAMPLE OF USAGE OF THE SERVICE 0441 1000 een emen ee nent nnn eterne ten RE 7 3 EXAMPLE OF USAGE WHEN CHAT MODE IS RE 7 4 USE CASE DIAGRAM FOR LOGIN AND CHAT MODE ccce eene enne nnne eene RE 7 5 USE CASE FOR SENDING AND RECEIVING OF MESSAGES
74. J2ME has gained much attention the last year and many companies like Siemens Motorola and Nokia seem to adopt the platform in their phones An overview 2 15 presented in chapter 3 Background Mobile applications also have several advantages in contrast to ordinary applications as we know it today They are able to be highly mobile services can be dependent on location and a mobile application makes it possible for the user to always be connected But there exist some constraints that have to be taken into account when designing distributed mobile network applications Embedded mobile devices like mobile phones and PDAs operate on the edge of the network and as a result of their mobile nature they require network technologies that are able to operate in an environ ment where some or all the nodes are mobile Today the most common wireless technologies are GSM GPRS and WLAN Soon other technologies like UMTS and Bluetooth will be available These technol ogies are mostly used as access technologies to the Internet but the hope for the future is for the devices to form network without dependence on Internet connection To be able to create such an environment the network functionality must run in a distributed fashion Here nodes will enter and leave the network without further notice while the users will have the same demands for connectivity and traffic delivery as in traditional networks Typical characteristics for
75. Jini that do not use RMI This chapter will focus on the reference implementation of Jini and by doing that also cover the RMI depend ence For other relationships between the component of Jini and Java refer to Figure 4 2 Infrastructure Programming Services model Discovery Lease JavaSpace Jini Lookup Event TX Management Extended Security Transaction Other Services Java VM Java technology Enterprise JavaBeans RMI based APIs Java Naming and Java Security Beans Directory Interface Swing JTS Figure 4 2 How Jini extends the Java platform The dependence on Java and its features gain many benefits for Jini For example the Java virtual machine ensures a homogeneous network and the portable object code gives architecture independence A dy namic environment is ensured using downloadable code and impedance mismatch is solved by the uni fied type system in Java 31 Jini Network Technology 4 2 1 The infrastructure component The core part of the Jini architecture is the infrastructure component Its goal is to provide mechanisms for devices services and users to discover join and detach from the network The following subcompo nents is part of the Infrastructure component Kumaran Lookup service component Discovery protocol component Join protocol component Remote method invocation RMI environment component Security component Jini lookup service is a repository of available services where each servic
76. L messaging may be 40 JXTA more trouble than it s worth especially if the application developer has no intention of taking advantages of capabilities to incorporate other P2P services into their application The platform s abstraction from the network transport has been criticised as a potential area of excess If most P2P applications today rely on the IP protocol to provide a network transport why does JXTA go to such lengths to avoid tying the protocols to a specific network transport Why not specify IP as the assumed network transport and eliminate the overhead JXTA protocols do not by themselves promise interoperability Just because two applications are built on top of JXTA does not mean that they can magically interoperate Developers must design applications to be interoperable Howevet developers can use JXTA which provides an interoper able base layer to further increase interoperability Developers must balance flexibility with performance when implementing their P2P applications JXTA provides the most well rounded platform for producing P2P applications that have the flexibility re quired to grow in the future but this does not indicate that it is the best or most efficient solution for implementing a particular application The core value of the JXTA platform is the capability to lev erage other P2P services and enable widespread development of PZP communities While the technol ogy is in
77. P or HTTP JXTAvn Figure 5 4 shows communication between to peers using a protocol and also how the layers of the pro tocol stack build on top of and rely on the layers below them Realizing that to provide a universal base protocol layer it must adopt a suitable representation that a ma jority of the platform currently available can understand XML was chosen to define all protocols JX 47 JXTA TA But does not depend on XML encoding it is just a convenient form of data representation Protocol can also use binary messages which is more suitable for devices with no XML parser Local Peer Remote Peer Peer Discovery Protocol 2 Peer Discovery Protocol Peer Information Protocol amp Via the Peer Resolver Protocol 4Peer Information Protocol Pipe Binding Protocol 4 Pipe Binding Protocol Figure 5 4 The JXTA Protocol Stack The responsibility of each of the protocols is described in the next subsections Note that a peer only need to implement the protocols that is requires For instance if a device stores all advertisements it uses in its memory the peer has no need to implement the Endpoint Routing Protocol Or if it has no desire to obtain or provide status information to other peers it may choose not to implement the Peer Infor mation Protocol XTAvn 5 4 1 Peer Discovery Protocol Peer Discovery Protocol PDP is used by peers to discover all published JXTA resources and for the to adv
78. RE 38 CHAPTER S etre 39 S LINTRODUCTION TO JXTA iiit itte tite tero t Hl te E eg ir eer codecs 39 5 2 ARCHITECTURE er Re HR Pa eR Pee tare Ote dede De Cds 41 324 o n i atas 42 5 2 2 42 9 2 3 e eee Dp sedie 43 5 3 TERMINOLOGY AND CONCEPTS 222 00 dp 43 DEAD Peers s eee 43 2 2 n eie ont M Et ae dA hse Poteet oce 43 3 3 3 Network Transport stet eque dea RN aR 44 93 2 AdVertisements oie eei e tA nr er iE dd n ROVS 45 3 3 9vEnttity NAMING states tine dab epe 45 Ds SOV SOCUPILY EE 46 S ATHE PROTOCOLS attore ree no ite rinm n rtu P es 47 2 4 1 Peer Discovery Protocol i n ee tet e o t 48 5 4 2 Peer Information Protocol sese eene 46 3 4 3 Peer Resolver Protocol RO RE 49 5 4 4 Pipe Binding Protocol E enne A AATA 49 5 4 5 Endpoint Routing Protocol essen nnn 49 5 4 6 Rendezvous Protocol sese eee nennen enne nennen 49 59 JXLA COMMUNITY s oh eng
79. RE 7 21 COLLABORATION DIAGRAM SHOWING THE SEQUENCE OF JOINING A GROUP 76 RE 7 22 COLLABORATION DIAGRAM FOR VIEWING AND EDITING A GROUP LIST 76 RE 7 23 SEQUENCE DIAGRAM FOR ADDING AN EXISTING 77 RE 7 24 COLLABORATION DIAGRAM FOR ADDING A NON EXISTING GROUP T RE 7 25 SEQUENCE DIAGRAM FOR EDITING CONTACT 1 57 78 RE 7 26 COLLABORATION DIAGRAM FOR SENDING AND RECEIVING MESSAGES 78 RE 7 27 SEQUENCE DIAGRAM FOR EXIT THE APPLICATION eee nennen enne 79 RE 7 28 SCREEN FLOW FOR ITSSYSTEM V1 0 eene eene eene nnne en 80 RE 7 29 SCREEN FLOW FOR FUTURE VERSION e n Innen enne tne seen ennt nnn nen en 81 RE 8 1 INTEROPERABILITY BETWEEN TWO TECHNOLOGIES A AND B eee 100 RE 8 2 IN AMIGOS SOLUTION A AND RE 8 3 IN AMIGOS SOLUTION C esses RE 8 4 JINI IN AMIGOS SOLUTION RE 8 5 JXTA IN AMIGOS SOLUTION RE 8 6 JXTA IN AMIGOS RE 8 7 JXTA IN AMIGOS SOLUTION RE B 1 VARIOUS WIRELESS NETWORKS ERIC2000 RE B 2 NETWORK OF PERSONAL AREA NETWORKS PANS 1 2000 B 2 RE B 3 AIRPORT SCENARIO ERIC2000 sese B 2 RE C 1 USE CASE FOR LOGIN EXCHANGE OF MESSAGES AND 5 022112 C 1 RE C 2 USE CASE DIAGRAM FOR
80. T Re ee A 1 4 SIP API FOR J2ME 2 APPENDIX AD NETWORK 2 1 B 1 APPENDIX C ITSSYSTEM UML DIAGRAMS AND COMMENTS C 1 Cal USE CASE 1 C 1 1 2 2 201 0 0202000 00 0000000 1 0000 nmn ne eenen nenne 2 L2 Private 2 5 2 C2 3 2 PTESGlieht note eot ene estos eet Sd ER REPRE C 3 C 2 2 04 80 100000 00000 4 C23 4 SEQUENCE DIAGRAMS 5 C 4 COLLABORATION 8 22 2 6566800 asse e sese se ease enn 7 C 5 DISCUSSION OF THE NON FUNCTIONAL REQUIREMENTS eene eee enne 9 APPENDIX D ITSSYSTEM USER 1 1 ae D 1 D 1 GETTING 5 de esiste tenen n n D 1 I 2 l HE GROUP LISTA de ete eset
81. The goals are achieved through leasing and code mobility The leasing mechanism in Jini is flexible and necessary in ad hoc net works and the mobile code can move securely from machine to machine on a network In every advertisement 15 valid and available on the network in a specific pre defined amount of time specified in the advertisement The advertisements floating around in the network provides the spontaneous net working since devices can discover services through the discovery protocol 96 Discussion The primary criticism of JXTA has been that it essentially is a renaming and repacking of Jini is promoted by Sun today in much the same way as Jini was Jini was a first step at a distributed computing standard but never took off because it works only with devices that run Java It has been claimed that the step towards is a move by Sun to try to gain acceptance of Jini that has not up to now materi alized as they had hoped On the other hand Sun maybe realized that Java dependency was not the right solution and that a platform and language independent solution was more appropriate may stand a better chance of success than Jini because it works with non Java applications Anyway the two solu tions can be used for different purposes dependent upon what will suite an application best Many are wondering whether the two technologies will converge in the future because of the similarities But the f
82. Web complements the platforms by providing a uniform and widely accessible interface and access The generic Web Service architecture is shown in Figure 6 2 A listener handles the access while a facade expose the operations supported by the business logic The logic is implemented by a traditional middleware platform Vasu 6 2 1 Web Service Platform The Web Service Architecture stack varies from one vendor or organization to another Some of the most popular Web Service architecture stacks developed the last few years are the World Wide Web Con sortium s W3C s stack W3Cws IBM s stack and Microsoft s stack They are all based on some tech nologies that form the common ground called the Web Service Platform These technologies have been discussed in connection with Web Services since the technology s early beginning and are summarized below Extensible Markup Language XML Simple Object Access Protocol SOAP Web Service Definition Language WSDL Universal Description Discovery and Integration UDDI base specifications use an underlying netwotk to transport the data Because of the use of XML and SOAP Web Services are independent of the transport protocol used but most implementations of Web Services use TCP IP and or HTTP The use of Extensible Markup Language XML and Simple Object Access Protocol SO SOAP simplifies the integration and interoperability problems between companies or other tha
83. XT to enable embedded de vices to participate in the community using J2M E and communicate with JXTA peers running on desktops workstations or servers In this way for 2 extends the vision should work any device The vision of JXTA for 2 is to provide an infrastructure for self organizing networks for devices This will allow for the developing of applications for spontaneous ad hoc collaboration One possible scenario is that one could spontaneously setup a Personal Area Network PAN of devices Thus when a PDA comes near a cell phone and or a laptop they could talk to each other When designing JXME several constraints imposed by cell phones and similar devices had to be taken into consideration and influenced the design choices Today s phones have an average total limit of about 123K for storing all MIDlet suites and some manufacturers have even less space In addition the size of persistent storage and heap is limited and the device may have high latency bandwidth JXTA for JXTA for J2ME Peers J2ME Peers Relay JXTA Relay and Proxy and Proxy JXTA Peer JXTA Network JXTA Peer Figure 5 5 JXTA for J2ME JXMEwp A requirement is that the devices use the Connected Limited Device Configuration CLDC and the Mo bile Information Device Profile MIDP This limited implementation was necessary to JXTA enable these devices since the full JXTA implementation requires res
84. against other players in a multi player game 3 3 2 Service execute on a remote server Services are provided and executed on remote server after the client has established a connection After execution the result is transferred to the client and presented to the user The remote server may either be in the Network Operators domain or on the Internet Browsing a website is an example of this kind of setvice This scenario is visualized in Figure 3 8 25721 Lex Services Mobile Client Figure 3 8 Service execution on a remote server Because of the limited resource of a mobile device this is the solution for heavy computational tasks 21 Network capabilities in J2ME since all the computation is left to the more powerful server and only the result is returned to the mobile device to deal with As a result almost no resources are used on the mobile device The disadvantage is that the mobile device is dependent upon a server to execute a task and if the device does not have con nection to the network it will not be able to execute the service 3 3 3 Service client downloaded to the mobile device The user downloads an application that acts as a local client This client application interacts with the service via a connection to a remote server where the service is provided and executed as visualized in Figure 3 9 This download mechanism is provided by Sun s OTA Lyng2001 An emai
85. ame and password is not that important as it would be if the device where to be used by many persons username is required in the prototype since this is used to identify the user in the ITSSystem By now the user types the username at start up Another solution could be to have the username and alternatively a passwotd as an application property stored in the JAD file accompanying the application jar file Using an application property allows you to customize a MIDlet suite for a particular customer user For ex ample as part of a servlet controlled download process the customer could be asked to enter an e mail address and a preferred username The process could then generate a random password and a custom version of the MIDlet suite and send the username and password to the user by e mail At application statt up the username and password has to be supplied but afterwards it is up to the user to set if he wants to supply username and password at all login 7 4 6 The search functionality The search functionality of the prototype is implemented but not supported in the proxy server and as a result nothing will happen if a user tries to search for a group The thought is that the user when adding a new group to his list of groups should search for the group to obtain the id if existing The search can be for exact matches to the specified group name or for similar group names At exact search the user will get the group id in return I
86. amming language and therefore limits the availability of meeting places to a Java environment Four possible scenarios ate suggested A Discovery of the AMIGOS server B Decentralized responsibility e C The AMIGOS service as a JavaSpace D Meeting Places as JavaSpaces A Discovery of the AMIGOS servet The easiest solution is to use Jini to locate AMIGOS servers through the lookup service That is the AM IGOS server is represented as a Jini services and announced to the Jini lookup service Services or clients that want to find the AMIGOS server send a request to the lookup server and receives a proxy that han dles all communication to the server Authentication and the handling of meeting places and location is left to the AMIGOS server Location servers can also be services themselves allowing other Jini clients to find their position This solution will also allow discovery of peripherals like printers or other useful entities in the network B UserProfile ERF repositoty 2 Location Request setvice server receive proxy A 0 4 Location i servet Request service Service A receive i 1 Register service 3 Communicate with AMIGOS server 3 Communicate with Meeting Place 1 Figure 8 2 Jini in AMIGOS solution A and B B Decentralized responsibility A more advanced solution is to split the
87. and for J2ME is the same as discussed for Jini and above In addition several other differences are introduced in relation to the architectures for embedded devices Specification Target devices Availability main difference between the Jini Surrogate Architecture and JXTA for J2ME comes in relation to whether they are specifications or not While the surrogate architecture is a specification JXTA for is an implementation of JXTA aimed at embedded devices supporting J2ME CLDC or CDC But both define an architecture that are based on the capabilities of the involved devices zarget devices of Jini Surrogate Architecture and JXTA for J2ME differs in more than way The Jini Surrogate Architecture is a common platform used by a range of devices from sensors to applica tions written in Java or another language does not have common platform to support embed ded devices and provides a variety of different packages and solutions dependent on the device and its capabilities If a device supports XML and is able to listen for incoming requests it uses the JXTA pro tocols otherwise specialized solutions are needed One of these packages is JXTA for J2ME that require support for 2 CLDC or CDC and uses HTTP to contact a relay that acts on its behalf on the net work 98 Discussion Availability can be defined to what degree an embedded device will be able to participate i
88. and internal errors like wrong parameter values and null pointer errors External errors is handled by usage of specific exceptions introduces in the prototype DatabaseExcep tion and NetworkException These are thrown if any critical error has occurred in communication with 81 The Prototype the database or network The ITSClient is left to handle the exception but if the error is thrown upon initialization of the DatabaseClient or NetworkClient the prototype is unable to continue and is there fore ended DatabaseException is thrown if the DatabaseClient is unable to initialize contact with the data repository which in our design is the database included with MIDP the Record Management System If a user fails to contact the database the application will not be able to run properly since it depends on the database to retrieve and store groups If the TSClient receives a DatabaseException at initialization the user will get information about the error and the network connection will be closed before the application exits This means that all ongoing activity will be cleared up before ending DatabaseException will also be thrown when storing of data to the database fails As with initialization an error message will be displayed to the user but the application will not exit this time NetworkException is thrown only if the NetworkClient cannot connect to the network which is of crit ical importance to the application An error me
89. ansfer Protocol Generic Access Profile Generic Object Exchange Profile General Packet Radion Service Global System for Mobile Communication Hypertext Transfer Protocol Secure HTTP Institute of Electrical and Electronics Engineers Inc Internet Engineering Task Force Instant Messaging and Presence Service Internet Protocol 115 Abbreviations ITSSystem J2EE J2ME J2SE JAD JAR JCA JCE JCP JNI JSR JVM JXME JXTA KVM L2CAP LAN MID MIDP MMS NAT OBEX OTA P2P PAN PATS PBP PDA PDAP PDP PEP PIP Intelligent Traffic Service System Java 2 Platform Enterprise Edition Java 2 Platform Micro Edition Java 2 Platform Standard Edition Java Application Descriptor Java Archive Java Cryptography Architecture Java Cryptography Extension Java Community Process Java Native Interface Java Specification Request Java Virtual Machine JXTA for J2ME Juxtapose Kilobyte Kuaui Virtual Machine Logical Link Control and Adaption Protocol Local Area Network Mobile Information Device Mobile Information Device Profile Multimedia Messaging Service Netwotk Address Translation Object Exchange Protocol Over The Air Peer to Peer Personal Area Network Program for Advanced Telecom Services Pipe Binding Protocol Personal Digital Assistant PDA Profile Peer Discovery Protocol Peer Endpoint Protocol Peer Information Protocol 116 Abbreviations PKI PMP PRP RMI RPC RVP SDAP SDP SHA 1 SIMPL
90. anslation The three last libraries are dependent upon the Data and XML classes XML Web Service classes support the development of lightweight distributed components which will work even in the face of firewalls and network address translation NAT software Web Forms classes include classes that enable rapid development of Web graphical user interface GUI applications while Windows Forms classes support a set of classes that allow you to develop Windows based GUI applications Related work that provide a common consistent development interface across all languages supported by the NET Framework NETov NET fto Currently NET is only available on Windows but Microsoft claims that is will be available on Linux some time in the future In a worst case scenario NET will never migrate beyond the Windows world otherwise it might become an alternative development platform to Java 6 3 1 NET for Java developers Microsoft NET is also available for Java language developers through Microsoft Visual JH NET Microsoft s Java development tool for the Windows platform J is Microsoft s implementation of the Java programming language An existing Java application can also be moved to the Microsoft NET Framework with use of Microsoft Java Language Conversion Assistant JLCA The tool will automati cally convert existing Java language source code into C Or at least this is what Microsoft claim NET Java 6 3 2 NET Compa
91. any Java 1 3 enabled platform and is free of charge It also allows developers to test their applications on different emulated target devices The wireless toolkit is presented in more detail in Appendix E 7 4 1 Screen flow To get a better understanding of the system and the implementation issues discussed next this subsection will presents the user interface of the system and the flow between the different screens in the user in terface First the focus is on the implemented version of the ITSSystem and then we turn to the pto posed user interface for the rest of the system Figure 7 28 shows the flow between the different screens ITSSystem version 1 0 The screens dis played are those available for the uset and should be viewed to possible customer to check the usability of the program Note that one error screen is shown as an example In this case the user is trying to add a group without specifying the name of the groups which is a non valid situation This is brought to the users attention by specifying the type of error The error screen can appear when other error situations occur but with different messages according to the situation screen with the title Join group is shown twice in the diagram because it has to appearances first is when no groups exist and next is when they are When no groups exist the OK button is unavailable as the possibility of joining a group is not present The same screen is also
92. architecture 2 1 Embedded devices Mobile embedded devices are small microprocessor based consumer products like hand held battery operated products such as cell phones two way pagers and personal portable organizers They where named embedded devices because the small computers inside them have a very focused operation Most mobile devices communicate with other devices by a wireless link When implementing applications for embedded mobile devices their limitations have to be taken into account These limitations are Limited memory and processing power Limitations in input possibilities normally a keyboard with approximately 12 18 keys Small screens Limited network connection possibilities Battery driven with limited lifetime Applications must also take security issues into consideration During the last years several initiatives have been started in order to develop an application development environment for embedded devices Most of these have been aimed at the Palm Platform like IBM and their Java virtual machine J9 and the VAME Visual Age Micro Edition IDE that wrap all native C methods for the Palm API in Java An other example is the Waba Waba or SuperWaba SWaba solution Java 2 Micro Edition J2ME a general Java application environment for embedded devices came as an initiative from Sun in 1999 The platform provides functionality that suites devices with different de mands within the embedded market
93. are platform i e programming environment that has gained great success after its introduction in 1995 The basic char acteristic of Java is that it hides the complexity of devices from applications Applications see the stand ardized interfaces of Java and do not have to deal with the special characteristics of different devices and as a result applications are portable between different platforms Java 2 Micro Edition is a version of Java designed to run on small devices with limited memory and several cell phones and PDAs with J2ME support are available with more on the way Introduction Low level technology needed to make ad hoc peer to peer mobile distributed architectures a reality is al ready available like WLAN and Bluetooth High level network technologies are under development two initiatives from Sun and Jini both support applications in a mobile environment The master thesis will be based on a project assignment that was carried out in autumn 2001 Java on Mobile Devices and will not include aspects that were covered in that report The assignment is to in vestigate the networking capabilities in the J2ME version for mobile devices like cell phones and PDAs and find explore abilities and limitations of the network technologies Jini and JXTA This report will give a short introduction to JAME CLDC MIDP Java APIs for embedded devices like mobile phones and then focus on the network abilities provi
94. as scaling change and complexity which are involved in state of the art networking JXTA JXTA and Web Services differs in a significant way when it comes to the architecture While Web ices uses a central server to keep track of services JXTA services are distributed in the network and an nounced using advertisements UDDI provides a similar service as JXTA and both are based upon XML Differences are that clients must register as UDDI clients to be able to access the system for searching and sharing of business op portunities in contrast to JXTA where there is no sign up process or fee This way is more loosely organized than UDDI users SOAP uses XML as do JXTA and both have protocol specifications to enable remote service access However JXTA provides additional protocols and services to implement a full P2P application Because both use XML SOAP compliant messages can be sent between JXTA peers through J pipes in a scenario where Web Services appear as JXTA resources 8 4 2 Microsoft NET Microsoft NET is a very diffuse platform and the architecture might seem like a bunch of technologies that are grouped togheter to provide desired functionality programming language independence and dis tributed computation The best way to compare the technology is by looking on the intentions and how they are realized The objective of NET is to provide interoperability among nodes in a network and this is accompl
95. assume that the service is unavailable The second solution solution B makes it easy to for a user to create meeting places and make it available for others with no intervention from other parties Creators of meeting places are responsible for the management and can withdraw the meeting place from the lookup setvice at any time without causing 108 Discussion faults as a result of the lease mechanism The initiator also sets up the requitements in connection to the meeting place like who is allowed to participate and the meeting place is responsible for authenticating the user Since lookup services will only have overlapping information about meeting places and a user connects to the nearest meeting place it might be possible to assume that all registered meeting places in a lookup service are in the vicinity of the lookup service Meeting places can be found according to loca tion and user profile which require the user to know his position and user profile The search can be based on templates that states requirements for the meeting place for example type of interest location and so on Browsing meeting places is possible based on the same mechanism Drawbacks of solution B are that meeting places must handle the authentication of the user and that there are no mechanism to authenticate the user before he gets a list of existing meeting places if this mechanism is not built into the client application itself This could be solv
96. ation between Java programs Benefits are anonymity between applications uncoupled communication programs can communicate through time space and vast savings in design and development time Processes in JavaSpace program do not interact directly but indirectly through or more spaces space is a persistent object store that is network accessible shared transactional secure and able to store executable content Elements in a space are called entities i e collections of typed objects An entity in a space cannot be modified directly but has to be taken out modified and then written to the space Jini is used to locate a space and in Sun s implementation the spaces are identified by name An example of a JavaSpace is a distributed array Each array element is an entry in a space the entry stores content and position in the array and protocols are defined to add or remove array elements As a result multiple processes can concurrently access the array through the space JavaSpace have a lease mechanism which 34 Jini Network Technology is based on the Jini lease model and all operations on the JavaSpace are transactional safe i e all opera tions are atomic and based on Jini transaction model Another feature that is made possibly through use of JavaSpace is ad hoc upgrading of new software The user of the software each has contract with the provider for how long the software is available and can upgrade upon expir
97. ave impact on JXTA for 2 and the non functional requirements are a way to evaluate this network technology package 8 5 1 Design Decisions Accotding to the object oriented philosophy of Java an application should be divided in object that can be reused when necessary But as a result of the resource limitations of small devices the developers may be fotced to move away from this philosophy to be able to reduce the MIDlet memory usage Objects must be allocated from runtime memory as opposed to primitive data types int long boolean etc which are allocated directly on the stack Even though the MIDP API consists of several classes objects are only used when it clearly makes functional sense to use them Otherwise primitive data types are used Viewed in this light the l TSSystem was designed with a relatively small number of classes All code could have been placed in one single class but the first non functional requirement required network independ ence In addition the development of the classes was to be shared between two developers To make the application easier to understand ITSClient and NetworkClient could have been divided into smaller classes Since ITSSystem is a small program this would not have caused any problems but a solution with minimal number of classes was chosen in order to optimize the code and make the implementation size as minimal and efficient as possible 104 Discussion 8 5 2 Non functional
98. ayer Configuration Layer and Profile Layet 13 Network capabilities in 2 Java 2 Platform Micro Edition Optional Packages A Optional Packages Personal Java 2 Profile Enterprise Java 2 Edition Standard Foundation Profile MID PDA JZEE Edition Profile Profile Java J2SE Java Virtual Machine N CardVM Figure 3 1 Java 2 Platform Micro Edition The configuration layer covers the most fundamental features in the java environment and defines the minimum features of the java virtual machine and the java class library available on all devices in a wide spectrum of capabilities also called a horizontal market These features are automatically included in the profiles that extend this particular configuration and are assumed to be present for profile implementa tion on all devices Today two configurations are defined in J2ME the Connected Device Configuration CDC JSR 36 and the Connected Limited Device Configuration CLDC JSR 30 The two different configurations is targeted at two broad categories of products CDC is developed for shared fixed connected information devices This categoty of devices have a large range of user interface capabilities memory budget in the range of 2 to 16 megabyte and persistent high bandwidth network connections most often using TCP IP Examples are TV set top boxes Internet TVs Internet enabled screen phones high end communicators and autom
99. be able to communicate with Jini resources that is Jini serv ices appear as JXTA peers It has also been claimed that is should be possible though non trivial to write a Jini framework in C ot another programming language In such an environment a language independent protocol like JXTA is needed S 4 JXTA resources as Jini services The fourth solution is a suggestion to make JXTA resources available for Jini clients A Java version of the resource is registered in the lookup server and is available for Jini clients The proxy down loaded to the client upon service request communicate with the JXTA peer using the JXTA protocols 1 Jumpers developed by Jumper Network JumpNet is a dynamic gateway that separates public and pri vate address spaces 101 Discussion 8 3 2 Evaluation of the suggested solutions The former section gave an overview of some of the different solutions to interoperability between Jini and JXTA This section will discuss the solution in realtion to advantages and limitations S 1 Surrogate Bridge The surrogate bridge is a simple and attainable solution as of today A reference implementation of the surrogate architecture exists so does an IPInterconnect implementation advantage of the solution is that it creates no dependence on platform or programming language required in the JXTA environment as long as the surrogate representing the resource is imple ment
100. blem with partial failure which in distributed systems can lead to unchecked resource consumption Traditional solutions have been system administration that has proven error prone and costly and it often happens when it is too late Distributed leasing is a protocol for man aging resources using a renewable duration based model for allocating and freeing the resource referenc es This provides a method of managing resources in an environment where network failures can and do occur Leases are time based grants of resources or services according to a contract between grantor and holder that is negotiated for a set period of time Leases can be shared or exclusive and can be can celled renewed expire or obtained and manipulated by third parties In a distributed environment re soutces are allocated only as long as continued interest is shown and the holder of the lease is responsible to renew lease before expiry The concept of leasing ensures that the network is self healing The distributed event notification component extend Java event model the JavaBeans component event delega tion model to work in a distributed network Clients register interests and receive relevant notifications and as such allow for use of event managers Various delivery models supported like push pull and 33 Jini Network Technology filter and the mechanism uses the distributed leasing protocol The model allows an event to be handled by third
101. c research projects are under development like Terminodes and an initiative has been taken to standardize ad hoc protocols This work is done by Mobile Ad hoc Networking MANET Working Group a working group inside the standardization body Internet Engineering Task Force The goal is to develop specifications for routing in mobile ad hoc networks and introduce these as standards through IETF C Pic Bluetooth scatti k 1 MANET Residential WLL Internet e i M 4 Infrastructure mode bre Ad hoc mode Figure B 1 Various wireless networks Eric2000 Generally speaking networks have evolved in a way where the responsibility of the infrastructure security and application is left to the users of the network This evolution will continue with the introduction of ad hoc netwotks To put things in perspective ad hoc networks can be compared to traditional cellular and mobile networks These are dependent upon an infrastructure since coverage is offered by base sta tions and radio resources are managed from a central location and services are integrated in the system Appendix Ad Network Technology As networks move away from central management they evolve into ad hoc operations that could be sin gle hop or multi hop Multi hop support in a network implies that packet data can be routed via other nodes in the network to reach the receiver in contrast to single hop networks whe
102. can themselves establish instances of the generic service i e the Meeting Place without in volving the network operator Amigos01 Amigos03 Users should be able to get to know the valid and established Meeting Places The visible Meeting Places can be dependent on context information as geographical position or information from the user s profile and is determined by the generic browsing service Users can join Meeting Places and participate in sev eral at the same time but might be blocked from joining according to features set by the owner of the 53 Related work Meeting Place or charged for the participation Meeting Places are designed with great flexibility regard ing what actually happen in the Meeting Place and configuration of the actual behaviour should be easy for the initiating user Amigos03 Example of a Meeting Places is Background Music where party music is chosen based on the musical taste of the users present at the party or contribution of media files from the guests Others are Community Wall a electronic bulletin board for sharing of information to a com munity of users and Mega Chat that is an entertainment service providing conferencing among partici pants and works a lot like chat with the exception that it are able to translate text to speech Amigos05 As a result of the requirements specified the generic functions in AMIGOS is logon log off browsing Meeting Places and establishing participa
103. centrate on the Web Service Platform and the primary 102 Discussion Web Service Model the Service Oriented Architecture SOA Technologies in the Web Service Platform UDDI SOAP and WSDL UDDI is a centralized business registry that enables business to business communication SOAP is designed to enable accessing remote service with other SOAP applications and WSDL is used to desribe the available services Jini The objective of Jini and Web Services is somewhat similar but target different areas Where Jini is based on service delivery over a network Web Services provides service delivery over the World Wide Web Web Service s SOA model share many similarities with the Jini architecture Both depend upon a central server to keep track on the services available and clients in the network get information about the serv ices by asking the central server Services publish their presence to the central server The difference emerge upon closer examination of the technologies that constitutes the platform of both technologies Where Web Services uses WSDL to describe the services stores them in UDDI and transfer the descrip tions using XML and SOAP Jini uses mobile code proxies to represent the services both in the central server and on the client requesting the service and supports communication with the central server using RMI Jini could be used to develop Web Services but is able to solve much mote difficult issues such
104. chnology Sun s official Jini site online http www sun com jini JavaOne Webcast Match 25 29 2002 San Francisco online http www jini org content webcast Apr2002 index html Jini org the Jini community s web site online http jini org Jini Surrogate Architecture Specification online http developer jini org exchange ptojects surrogate The Jini Technology Surrogate Architecture Overview online http surrogate jini org overview pdf Jini Technology Surrogate Architecture Specification online http www jini org standards sa pdf Jini WirelessDevice Project online http developer jini org exchange ptojects wirelessdevice Java Language Conversion Assistant online http msdn microsoft com vstudio downloads jlca default asp Location API for J2ME online http jcp org jsr detail 179 jsp Java Speech API 2 0 online http jcp org jsr detail 113 jsp JSR 120 Wireless Messaging API online http jcp org jsr detail 120 jsp 121 Reference Library 5 129 JSR 134 JSR 135 JSR 164 JSR 165 JSR 172 JSR 177 JSR 180 JSR 186 JSR 187 JSR 30 JSR 36 JSR 37 JSR 46 JSR 62 JSR 66 JSR 75 JSR 82 Jump JumpNet JSR 129 Personal Basis Profile Specification online http jcp org jsr detail 129 jsp JSR 134 Java Game Profile online http jcp org jsr detail 134 jsp JSR 135 Mobile Media API onlin
105. choose Join group the group list will appear In addition you can enter the setup from this menu CANCEL will bring you back to the group list D 2 2 Add group will bring you back to the menu D 2 3 Delete group To delete groups from the list you choose Delete group from the menu Then the group list will appear and you must select the group you want to delete and click OK The same screen will reappear after deleting the group with an updated group list where the deleted group has been re moved CANCEL will bring you back to the menu without deleting any of the groups D 3 Public communication OK To add a new group choose Add group from the group editing menu and click OK The screen shown at the left will then appear To add groups to the list you must either know the group name of an existing group or add a new group Enter the group name in the text field and click OK to add a new group to the group list The updated group list will then appear CANCEL ED Delete from list JTRONDHEIM BACK OK ITSSystem 1 0 includes the possibility to communicate with the whole group you are participating in Private communication with only one other user is not supported in this version MENU SEN After joining a group you will receive all the messages sent to this group and you can send messages to the group The messages you send and receive will be printed to the screen together w
106. ct Framework The NET Compact Framewotk is a subset of the NET Framework that is designed to on smart devices providing support for managed code and XML Web Services It enables the execution of secure downloadable applications on devices such as personal digital assistants PDAs mobile phones and set top boxes In this way it is a key part in Microsoft s goal to provide customers with great expetiences at any time any place and on any device INETcomp telecom01 NET Compact Framework is designed to run on multiple hardware platforms and operating systems but will first be available on devices running the Microsoft Windows CE operating system This includes Pocket PC and Pocket PC 2002 devices Microsoft Smartphone and devices running Windows CE NET No other supported platforms are announced at the moment Languages that will be supported are Microsoft Visual and Microsoft Visual Basic Other NET languages will run as long as they con form to the subset of the Common Language Runtime CLR that the NET Compact Framewotk sup ports NETcfaq J2ME and the NET Compact Framework is in other words competitors in the world of small devices But until NET Compact Framework supports both Java and a multitude of platforms J2ME is more attractive to Java developers 6 4 Summary This chapter presents the AMIGOS project and two upcoming technologies that relate to Jini network technology and JXTA AMIGOS Advanced Multi
107. ction such as peer discovery These mechanisms are already defined by the JXTA protocols 8 5 The Prototype The prototype developed as part of the assignment demonstrate the use 2 MIDP and JXTA for J2ME in an instant messaging chatting application where the users could participate in different groups according to location The objective of the prototype was to explore possible ways to implement applications on mobile termi nals and get to know J2ME MIDP and JXTA for J2ME One of the main conditions for an application development platform and related packages to succeed it to make them easy to learn and use Both MIDP JXTA for J2ME is relatively easy to use if a developer is familiar with the Java programming language The main challenge is the limited resources like cpu and memory on most mobile devices JXTA for J2ME imposed another challenge in that the APIs is under development As a result the API can sud denly change and so it did halfway through the development causing some rewriting of code During the development both advantages and limitations of MIDP and JXTA for J2ME were revealed in addition to several challenges related to design decisions and non functional requirements The next section will cover some main areas and discuss these in relation to JXTA for JZME This includes the design decisions the non functional requirements and possible other network technologies that could have been used Design decisions h
108. cts File permission Allows access to all relevant files such as class files jar files and related files Socket permission Allows access to an open network socket on any port The permissions associated with the Java runtime environment is placed in a java policy file and separate security policy file can be specified to set application specific policies In addition to the permission class es defined in Java Jini also defines one for discovery permissions which specifies permission to connect to a Jini lookup service that is serving a particular group Systems administrators can establish different policies depending on where the Java code originated for example the local file system or a remote ma chine Downloading mobile code gives an opening for viruses which is also mobile code So before code can move to another machine in the Jini environment it must satisfy the client s security policy witch should only allow downloading from trusted machines Other problems could be the lookup server sending a client to the wrong location since there is no way a lookup server can validate a service s purpose Com puting ITPro 4 2 2 The programming model component Jini programming model is based on the Java application platform to form a distributed extension This is done by introducing a set of interfaces or components Kumaran Leasing Event notification and Transaction Leasing is introduced to solve the pro
109. d to a result list that the user can examine at a later point From this list the user can choose the group to be added to the group list and then later choose to join the group If the network client receives a message containing information about a suitable group this information is passed to the ITSClient If the search was for an exact match the group is added to the group list If no message about an appropriate group is received within a predefined time interval the group is con sidered non existing and a new group will be created if the user chooses to join the group at a later time This is illustrated in Figure 7 24 4 noExistingGroup createGroup String gt 1 searchForGroup String int 3 joinGroup String String E gt ITSClient lt NetworkClient 8 groupInfo receiveMessage IT SMessage 2 search String String 5 noExistingGroup create int String String 6 poll int 9 listen String String String 7 Message PeerNetwork Figure 7 24 Collaboration diagram for adding a non existing group If a uset chooses to participate in a private room instead of a public the list of contacts is selected from the database Since only the contacts which are reachable in the same group as the user will be presented for the user the client need to check which contacts are participating in that group at this moment This is done by calling the method in NetworkCl
110. damental processing unit of any P2P solution They can manifest in the form of a processor a process a machine or a user and can include sensors phones PDAs as well as PCs servers and supercomputers They can also be an application distributed over sev eral machines and the connected devices like PDAs might not be directly connected to the network but for instance via a synching cradle Peers are capable of communicating using the protocols required by a peer but does not need to understand all the JXTA protocols see section 5 4 A peer can still perform at a reduced level if it does not support a protocol Wilson Each peer performs some useful work but the work is dependent upon the type of peer There exists today three types of peers and they define a set of responsibilities for the peer in relation to the P2P net work as a whole The different types of peers are Wilson Simple peers A simple peer is the simplest type of peer on the network and provides and consumes resources from other peers on the network It is not responsible for forwarding mes sages on behalf of other peers or providing third party information to the network Rendezvous peers Provides simple peers with a way of discovering other peers and advertise ments on the P2P network Router peers Router peers provide routing services to enable peers inside private internal net works behind firewall and NAT equipment to participate
111. ded as part of these platforms Two distributed network technologies Jini and JXTA will be introduces and an overview over both technol ogies will be provided Both Jini and JXTA have solutions for incorporation of embedded mobile devic es the surrogate architecture and the JXTA for J2ME respectively which both will be presented The use of Jini and JXTA will be discussed to find advantages and limitations and possible usage of the two technologies in the AMIGOS project at Department of Telematics NTNU should be presented A prototype is to be developed as part of the master thesis One of the requirements is that it should be carried out as in a software development project including requirement specification design implemen tation and test Depending upon study of Jini and the most suitable of the two technologies should be used in the prototype 1 2 Objectives and limitations The objective of the assignment is to get an overview of the capabilities Java enabled devices have to communicate in networks One of the critical aspects of 2 is network connectivity but the question is how the abilities provided today can be used and possible extended to support features outside the or dinary client server architecture Technologies related to client server processing and the support of different types of terminals accessing a server will not be considered or discussed Neither will low level peer to peer technologies like B
112. diagrams All diagrams will be found in Appendix C Figure 7 19 shows the login sequence involving the ITSClient and the DatabaseClient The client must first create an object of the DatabaseClient and then retrieve the user name from the database used to authenticate the user Where the username shall be set and where to keep it has some alternative solutions that will be covered in the implementation notes client database ITSClient DatabaseClient DatebaseClient gt getUserName authenticateUser String x Figure 7 19 Sequence diagram for login and authentication ITSClient NetworkClient ITSClient String NetworkClient connect createlnstance java lang String PeerNetwork gt connect java lang String byte new Thread start poll e poll int Figure 7 20 Sequence diagram showing how to connect to the network For the client to connect to the network it has to create an object of the NetworkClient This is shown in Figure 7 20 NetworkClient will create an instance of PeerNetwork one of the classes of the JXTA for J2ME package and then make this connect to the network by calling connect To be able to re ceive messages the NetworkClient must poll the relay proxy and this is
113. dled as part of the protocol stack responsible for sending the data over the network before the data is sent E commerce applications uses the Secure Socket Layer SSL developed by Netscape and the hope is that it will work nicely for 27 Network capabilities in 2 m commerce as well Mahmoud Sun has been working on a stripped down version of SSL called kSSL and has already delivered it as part of the MIDP 1 0 3 reference implementation and the J2ME Wireless Toolkit 1 0 3 kSSL will be included in the MIDP 2 0 specification and this will then be able to support the secure version of the HTTP protocol HTTPS and secure socket connections MahLor Gupta To further improve the security in J2ME a security API is under development at Java Community Proc ess JCP JCP JSR 177 Security and Trust Services for J2ME JSR 177 It is proposed as an op tional package to be used together with several J2ME profiles and anticipated schedule for the specification is first or second quarter of 2003 The objective is to define a collection of APIs that pro vide security services to 2 enabled devices This will make the device become trusted and as a result provide security mechanisms to support a wide variety of applications based services such as access to corporate network mobile commerce and digital rights management Many of the setvices rely on the interaction with a security element in the device for secure storage and
114. done using a thread that is ini tialized and started when the NetworkClient is initialized 15 The Prototype The joining of a group is illustrated in Figure 7 22 The numbers in the collaboration diagram indicates the messages order in the sequence and conditions are represented with square brackets When the user decides to join a specific group the NetworkClient will start listening to the pipe where messages from the group are sent Pipes and other features of JXTA are presented in Chapter 5 If the user is already member of a group the NetworkClient will call the 1eaveGroup method before starting to listen to the new pipe representing the new group Messages ate retrieved by polling the proxy If the proxy has received some messages to the client this message is forwarded to the I TSClient as ITSMessage 2 connected leaveGroup 1 joinGroup String String A AL NetworkClient ITSClient 7 noEmptyMsg receiveM essage ITS Message 3 connected close String String String 4 listen String String String 5 poll int 6 Message PeerNetwork Figure 7 21 Collaboration diagram showing the sequence of joining a group Figure 7 22 illustrates the viewing and editing of a group list The first thing happening is that the client gets the groups from the database The second operation 2 is executed if the user chooses to view the group menu Adding new gr
115. e relay must both be pre known by the device as of today since there are no mechanisms that supports discovery of the relays In addition both Jini and JXTA aims for independence of the relay Psi Naptic a communication technology company has removed the dependency on RMI and made a lite version of Jini available for embedded devices and as a result there is no need for a relay JXTA also has goal to limit the dependency upon a relay server first by having a discovery mechanism to discover telays dynamically and when the abilities in J2ME CLDC MIDP allow it implement a version of JXTA for J2ME that communicate directly with the JXTA community 8 2 3 Advantages and disadvantages The assumption for discussing the advantages and disadvantages of the Jini Surrogate Architecture and JXTA for J2ME is that the device must be java enabled with the JZME MIDP library It also assume use of the reference implementation of the Jini Surrogate Architecture in addition to the IPInterconnect ref erence implementation when it comes to Jini In the case is uses the current implementation of JXTA for J2ME All these reference implementations uses the Java programming language According to this the advantages and disadvantages are e Complexity Jini surrogate architecture is more extensive than JXTA since it is a specification that is dependent upon interconnect specifications to be able to connect the devices to the Jini net work The devel
116. e http jcp org jsr detail 135 jsp JSR 164 JAIN SIMPLE Presence online http jcp org jsr detail 164 jsp JSR 165 JAIN SIMPLE Instant Messaging online http jcp org jsr detail 165 jsp JSR 172 J2ME Web Service Specification online http jcp org jsr detail 172 jsp JSR 177 Security and Trust Services API for J2ME online http jcp org jsr detail 177 jsp JSR 180 API for J2ME online http jcp org jsr detail 180 jsp JSR 186 JAIN Presence online http jcp org jsr detail 186 jsp JSR 187 JAIN Instant Messaging online http jcp org jsr detail 187 jsp JSR 30 J2ME Connected Limited Device Configuration online http jcp org jsr detail 30 jsp JSR 36 J2ME Connected Device Configuration online http jcp org jsr detail 36 jsp JSR 37 Mobile Information Device Profile online http jcp org jsr detail 37 jsp JSR 46 Foundation Profile online http jcp org jsr detail 46 jsp JSR 62 Personal Profile Specification online http jcp org jsr detail 62 jsp JSR 66 RMI Optional Package Specification Version 1 0 online http jcp org jsr detail 66 jsp JSR 75 PDA Profile for tbe J2ME Platform online http jcp org jsr detail 75 jsp JSR 82 Java for Bluetooth online http jcp org jsr detail 82 jsp Project JumpStart online http www jumpernetworks com jump html Jumper Network owner of the Jump Jump and JumpStart JumpStart project online http www jumpernetworks com
117. e trieved from a Location Server The Location Server is situated outside ServiceFrame and compute the location of a device based on information from the device from the network or information from both client and network As a result of the placement of the location setver it will be accessible for any device on the network Brandis Terminals covered are GSM mobile phones hand held computers PDAs portable computers and or dinary telephone PSTN ISDN and the connections that should be supported is 9 6 kbps GSM data GPRS Bluetooth WLAN and LAN In addition it should support a variety in operating systems like Windows Linux and Microsoft Pocket PC and the JZME environment 54 Related work 6 2 Web Services The goal of Web Services is to make application functionality available over the Internet in a standard ized programmatic manner Application should be able to communicate regardless of the implementa tion language platform they were developed for and the object models and internal protocols they use Frisk XML Request middleware 21807 ssoursng ssoursng 29093811 XML Response Figure 6 2 Generic Web Service Architecture Web Service features are based on the combined strength of different middleware like RMI Jini COR BA and DCOM in addition to the strength of the Web simple access and ubiquity Services are effec tively implemented in a traditional middleware platform and the
118. e Since the ma jor mobile terminal manufacturers have announced J2ME MIDP support in their phones and take part in the standardization I believe that these conditions will be fulfilled within the next few years When it comes to developing commercial applications using JXTA I will not recommend this at the cur rent time JXTA for J2ME relies on the reference implementation which has been reported to be unsta ble unreliable and slow In addition JXTA for J2ME is under constant change and does not support all the advanced features that would give applications value like full search capabilities A commercial ap plication may be possible some time during 2003 since the JXTA reference implementation constantly changes and is improved by the community Jini and JXTA have several possible areas of usage in AMIGOS which is a service platform that enable users to establish and participate in virtual rooms called Meeting Places An introduction to these distrib uted architectures will bring the AMIGOS architecture from being very centralized to being distributed with all the challenges this introduces Some examples are reduced consistency of data reduced security and loss of central control Possible scenarios range from just discovering AMIGOS servers to spliting the AMIGOS service in several parts that co operate to provide the full service In my opinion JXTA is the most suitable solution since it has more features that cover the needs
119. e same destination target For instant if a user is driving a car in a specific area and wants to get information about the traffic there the user can register to a group representing this area and receive information or ask questions to everyone else registered in that group or only to one specific user in the area The dif ference between unicasting and multicasting the message will be described later Another example is the case of a user travelling from Oslo to Trondheim that may need to exchange information with other trav ellers on the same journey Figure 7 2 shows a scenario were a user is looking for a gas station in a specific area Does it exist a just past one in gas station in this 51 Bowen street area a a Gas statio NS Figure 7 2 Example of usage of the service The call outs are actually text written on a mobile terminal for instance by a passenger In principle the application could be controlled both by speech and physical interaction from the user since a user driving will not be able to write messages by hand while driving Speech recognition is on its way but there is still a long way to go and as a result this version of the prototype will only realize the possibility to send text Group belonging for a user could be decided based on location information supplied by for example Glo bal Positioning System GPS Such a solution allows the device to find information about the locatio
120. e a base P2P infrastructure over which other P2P applications can be built seeing that standards are absent in the P2P world Current P2P solutions use different protocols architectures and implementations The base of JXTA consists of a set of protocols that are language independent platform independent and network agnostic i e they do not assume anything about the underlying net wotk Each protocol serves a special purpose and is used to exchange messages between the entities in the P2P network This chapter will give a brief introduction to JXTA its goals its terminology and concepts the architec ture and protocols One of the projects in the JXT community is to develop a JXTA implementation for 2 enabled devices and a description of this implementation will be provided 5 1 Introduction to X Project JXTA envisions a world where each peer independent of software and hardware platform can benefit and profit from being connected to millions of other peers The vision of JXTA as stated in the vision statement is quoted below Project X is building a core network computing technology to provide a set of simple small and flexible mechanisms that can support P2P computing on any platform anywhere and at any time The project is first generalizing P2P func tionality and then building core technology that addresses today s limitations on P2P computing The focus is on creating basic mechanisms and leaving policy
121. e choices one can regard the strengt of both Jini and and the advantages and disadvantage are discussed below Efficiency both transfer and cpu It is shown in several studies that any ASCII based protocol is inherently less efficient than a binary one JXTA is a verbose ASCII protocol and will so be even less efficient In addition JXTA depends upon generation and parsing of XML which is very resoutce consuming Compare this to the object serialization in Jini which requires minor resources Operations on by Type Jini uses Java objects which enables asking for things by type and to manipulate full Java objects The benefits are the same as one expect from type checking inherit ance and polymorphism when working with objects rather than text JXTA operates on XML or binary messages that cannot hold a state in the same way as an object only textual information Interoperability makes is possible to communicate with non Java participants while the core Jini only can talk to entities in the network with Java support For Jini clients to talk to non Java participants the non Java participants must use the surrogate architecture Discovery mechanisms The discovery mechanism of JXTA is more standardized than in the Jini and RMI environment For example services be accessed despite of firewalls although RMI has a proxy mechanism called RMIProxy that might help in these cases JXTA rendezvous hosts can though a
122. e device Jini Network Host Capable Machine Surrogate Host Surrogate Host Resources Private protocol urrogate protocol Suttogate Interconnect i object Dependent Code ru Interconnect Figure 4 4 Jini Surrogate Architecture A surrogate host is a framework that provides a Java application environment specially designed for the hosting of surrogates and so provides a place for the device to participate in the Jini network The appli cation environment might be composed of J2SE or J2ME CDC Foundation Profile Jini APIs and life cycle support of surrogate objects uploaded into the environment by the limited capability device In oth words the surrogate host is responsible for managing the life cycle of the surrogate which consists of the stages device discovery surrogate retrieval execution deactivation and disposal The life cycle starts with the limited capability devices using a surrogate protocol to discover the nearest surrogate host or the surrogate discovers the device It then uploads its surrogate object also known as a setvice proxy object to the surrogate host The surrogate object contained as class files in a JAR file can also be located elsewhere than on the device After uploading the device delegates the control thread to the surrogate host which from then on manages the life cycle of the surrogate object such as activa tion retrieval execution deactivation and disposal Activation
123. e e Fer ree TE ke e edad ius 49 5 6 THE UX TA FOR 5 50 5 641 JXTA for J2ME PeF au teet e ER RR RU ERN te 51 5 6 2 JXTA for J2ME Relay Service essen eene 51 SUL SUMMARY PO edt ta ipe OF pde 52 20 else ee oe ee aod ee det no 53 6 1 T HE AMIGOS PROJECT P OREILLE DR E NL 53 6 2 WEB SERVICES I 55 6 2 1 Web Service Platform sse eene eene nnns 55 6 2 2 Web Service Models csse dedit t ite ta eec 56 6 2 3 Web Services and J2ME sse eene eene nennen nennen 57 6 3 MICROSOFT cce b i pee D re Ret D EHE 57 6 3 1 NET for Java developers eene eene nnne 59 6 3 2 NET Compact Framework essent eene nennen 59 OA SUMMARY s D RR IN Lr eH 59 CHAPTER 7 THE PROTOTYPE eei ce eene sore nere evade on 61 TADS YSTEM OVERVIEW ren Por e eer ep n a v TRE P E 61 Teh D Service Specification ee ee e tee 62 TAD Realization i d s pad eee nte endet ete 63 Table Of Contents 7 2 REQUIREMENTS SPECIFICATION ccccccccccccccecscscccsescscscecesssssessssesesesecscecucacscecscenstscseseeaeecs 63 7 2 1 Functional
124. e exchange of information between the participants using rules agreed upon by all par ties The protocols in PZP are needed to define every type of interaction a peer may perform as part of the PZP network This includes Finding peers on the network Finding what services a peer provides Obtaining status information from a peer Invoking a service on a peer Creating joining and leaving peer groups Creating data connections to peers Routing messages for other peers Advertisements simplify the protocols required to make P2P work since they dictates the structure and representation of the data and only leaves the protocol with the organization of exchanging advertise ments The six protocols in JXTA defined today are Peer Discovery Protocol PDP Peer Information Protocol PIP Peer Resolver Protocol PRP Pipe Binding Protocol PBP Endpoint Routing Protocol ERP Peer Endpoint Protocol PEP Rendezvous Protocol RVP All protocols were designed to be easy to implement on unidirectional links and asymmetric transpotts intention was for the protocols to be as pervasive as possible and easy to implement on any trans port permits any unidirectional link to be used when necessary and this might improve the overall netwotk connectivity in the system Efficient bi directional communication can be realized by imple menting the protocols on reliable and bi directional transports such as TCP I
125. e is stored as a Java object and made available for clients to download on demand The lookup service is placed in the lookup server which client entities assume always is present on the network The interfaces operations available on the lookup service is registration access search and removal of services Jini discovery and join protocols are used to find and join a group of services and are based on UDP multicast The three protocols are Computing The multicast request protocol Locate one or more lookup servers The unicast discovery protocol Used by clients and servers to communicate with a specific lookup server The multicast announcement protocol Used by a lookup servet to announce its presence on the network When a lookup setver invokes this protocol clients and services that have registered interest in receiving announcements of new lookup services ate notified 2 Request service 4 Communicate with service Figure 4 3 Discovery and interaction with a service Discovery in the Jini network start with the service multicasting a packet with reference to itself and re ceives a RMI reference to one or more lookup services The Jini client locates a service by querying the nearest lookup service and as response it receives a proxy representing the service Request to the service is sent to the downloaded proxy which handles all communication with the remote service As a result the usage of a service is independe
126. e precise nature of the network connection depends both on the de vice and on the services provided by the network to which it is connected Some may be directly connected to the network while others are only able to access it through a gateway Regardless of this wireless Java devices that conform to the MIDP specification is required to provide the illusion that it is directly connected to the network Networking capabilities J2ME is provided by the Generic Connection Framework defined CLDC The framework gives a consistent way to access and organize data a resource constrained environ ment The approach used has the benefit that the application code stays the same regardless of the kind of connection that is used Implementation of the protocol definition is left to the different profiles for example supports the first version of MIDP the HTTP protocol 3 2 1 Overview Requirements for the networking and storage libraries vary from one resource constrained device to an other and different networks demand for different types of communication The requirements for hav ing a small footprint J2ME system has therefore led to the generalization of the J2SE network and I O classes that is extensible flexible and coherent in supporting new devices and protocols Instead of using a collection of totally different kinds of abstractions for different forms of communications a set of te lated abstractions are used at the application prog
127. e technology is based on the assumption that Java is present in the network and ensures a homogeneous environment by use of mobile code that is transferred between clients in the network Three components constitute the Jini architecture the infrastructure component the programming model component and the service component Entities with abilities in the network are defined as services whether they software entities hardware entities or a combination Services are registered with lookup services and clients can request a lookup service for a particular service and receive a proxy representing the service as response The proxy han dles all communication with the remote service and thus creates independence between the client and the transport protocol used The only element that is discovered in Jini using a discovery protocol is the lookup service These features are part of the infrastructure component The network ensures self healing i e that the community can adapt to changes for example that entities join and leave without further notice This is done through leases that is to say that clients can uses a service for a predefined time before it has to revise the agreement i e update the lease Jini transaction model can ensure secure transactions between entities and clients can ask to receive notification if some thing of interest becomes available i e event notification These features are part of the programming model comp
128. ective peer group service is not affected if a peer fails since it is available from another peer member Services might be built by the community or by the Project team Services built on top of the JXTA platform provide specific capabilities that are required by a variety of P2P applications and can be combined to form a complete P2P solution 42 5 2 3 The application layer The application layer provides common P2P applications like instant messaging by building on the ca pabilities of the service layer Sometimes it is difficult to determine what constitutes an application and what constitute a service since an application may encompass only a single service or aggregate several services An application is usually indicated by the presence of user interface One example is the JXTA Shell an application built on top of the Peer Commands which is a service As a result the JXTA Shell is spread across the Application Service boundary Applications JXT include those built by the community and the Project JXTA team which mostly contribute with demonstration applications like the shell 5 3 Terminology and concepts specification defines a number of concepts that are common for networks and as a result are the primary components of the JXTA platform This section will give an overview of these concepts 5 3 1 Peer Peers are the nodes in a P2P network and the fun
129. ed This way a MIDlet will be able to participate in distributed environment and become part of a network and makes the use broader than if the terminal should access setvices di rectly via HTTP Advantages of the middleman architecture are Not all devices are IP enabled promotes loose coupling and therefore simplifies interactions between objects Enables the user to use RMI CORBA or any distributed technology from a MIDP enabled device 23 Network capabilities in 2 The drawback is that the MIDlet must know the address to a relay or the user must supply the applica tion with the address Both solutions constitute an inflexible implementation 2 5 New network technologies for J2ME enabled devices Several network technology is under development and will be provided on embedded mobile J2ME en abled devices in the future Some is under development the Java Community Process JCP JCP while independent communities develop others Packages from JCP include the usage of Short Message Service SMS and supplementary technologies Others includes a Location API that might be useful and a SIP API which all are of minor importance and is therefore covered in Appendix A Several additional packages and profiles are under development for J2ME and several are about to be finished An overview of the different Java Specification Requests JSRs that relates to J2ME can be found at J2ME_spec API for Bl
130. ed by forcing authorization after discovery Solution B also introduces another complexity a client cannot have the total overview of all meeting places It has to initiate a search that does not guarantee that all the existing meeting places are found Solution C suggests the use of JavaSpace The advantage is a persistent environment where meeting plac es can exist It relies on the mechanisms in JavaSpace among other it leaves the authentication to the JavaSpace This solution has similarities to solution A and share the same advantages and limitations Solution D suggest that JavaSpaces can themselves be meeting places As solution C it relies on the mech anisms of JavaSpace but authentication of the user is left to the Jini environment The Jini environment has no mechansims to provide such authentication before a user contacts a lookup service The solution has similarities to the decentralized solution B and share the same advantages and disadvantages 8 6 2 JXTA As Jini does not consider the implementation of the meeting places and concentrates on how to find the different entities in the AMIGOS environment The only requirement is that all entities must be able to generate and parse XML There are three different scenarios of using JXTA in AMIGOS Discovery of the AMIGOS server B Decentralized responsibility C Meeting places as peer groups A Discovery of the AMIGOS servet The first scenario sugges
131. ed in Java Jini services require no change neither does JXTA resources The drawback is that the Surrogate host may be the bottleneck if many peers tries to connect Jini services It also creates a dependency on a central resource the surrogate host S 2 XML support in Jini XML support in Jini solution tighten the two network technologies in higher degree than the previ ous suggested solution The advantages is that rather than just exchanging a document peers will be able to exchange objects between mobile agents that allow them to do more than read the document they ex change but collaborat on them Disadvantages 15 that several changes has to be made to the Jini lookup server and some to the architecture In addition the solution is dependent upon Java which limits the peers that can participate in the network It also creates problems like how the lookup server will know that an advertisment or discovery messages comes from a Java enabled peer or not S 3 as communication platform in Jini Using as communication platform will make Jini independent of RMI which is the bottleneck for today s embedded Java enabled devices This way they may be able to participate in the Jini community without use of the surrogate architecture When it comes to the advantages in relation to JXTA the so lution will make more services available for Java enabled peers JXT peers can get information abo
132. elay should filter unnecessary advertisements since a JXTA for J2ME peer does not have enough memory to store all incoming advertisements Mes sages and incoming advertisements are stripped down to a minimum so that they will be small Translate Messages for J2ME peers uses binary messages and the relay service will have to translate JXTA XML messages into binary messages and vice versa Relays not a new idea for JXTA They are already used to access JXT peers behind firewalls and allow networks using NAT to communicate with the outside world JXT peers do not have to maintain a static relationship with a designated relay and is therefore unlike the client server model JXTA peers can change relays dynamically or be in relationship to multiple relays at the same time A future scenario is that peers can search for JXTA relays and configure one of them to be its default 2 7 Summary is a new distributed platform designed to solve a number of problems in modern distributed com puting especially the area broadly referred to as peer to peer P2P computing The objective is to pro vide interoperability between entities in the network be platform independent and offers ubiquity i e any device with a digital heartbeat can participate specification defines a number of concepts that are common for P2P networks and as a result is the primary components of the JXTA platform The concepts are pe
133. ent 4 receiveMessage IT SMessage 2 send String String String Message 3 poll int peerNetwork PeerNetwork Figure 7 26 Collaboration diagram for sending and receiving messages When the user wants to end the running of the application the client will tear down the connection to the network through the NetworkClient The NetworkClient will unsubscribe from the pipe it has been listening to This is illustrated in Figure 7 27 78 The Prototype ITSCli ent NetworkClient PeerNetwork DatabaseClient destroyApp closeNetworkConnection connected leaveGroup conne cted close String String String close String String String storeGroups String storeContacts String Figure 7 27 Sequence diagram for exit the application All the remaining UML diagrams be found in appendix 7 4 Implementation The prototype was implemented using 2 Wireless Toolkit J2MEwtk and the supplied emulator in this toolkit The code was written in emacs and includes comments to the implementation The J2ME Wireless Toolkit J2MEwtk offers a lightweight way of building and testing a MIDP project It comes complete with the CLDC and MIDP libraries utilities Javadoc documentation and example Midlets The toolkit runs on
134. ers peer groups endpoint pipes messages advertisements entity naming and security peer is a node in a network while a peer group is a self organized collection of peers that have a common set of interests Communication be tween two peers the form of messages goes through pipes from one endpoint to the other Adver tisements are language neutral metadata structures that describe the network resources i e they dictate the structure and representation of the data They are published and exchanged between peers to discover and find available resources and have a lifetime that specifies the availability of the associated resource Entities in the network are identified by a unique ID that are independent of network and other system specific notation Security is provided through use of Transport Layer Security TLS and digital certifi cates and in addition the transport independent design provides end to end transport security The base of the JXTA specification consist of a set of protocols that are language independent platform independent and network agnostic i e they do not assume anything about the underlying network Six protocols are already defined The protocols enable discovery of resources on the network the possibility to obtain status information about other peers to bind a pipe to a physical peer endpoint find an appro priate route to another peer subscribe to a propagation service and a protocol to perform
135. ersions of the CLDC specification Lyng2001 The KVM includes a simple sandbox where the java application must run and ensures a closed environment in which the applica tion can only access those APIs that have been defined by the configuration profiles and licensed open classes supported by the device But a security checking of API calls which is available in J2SE is not included with few exceptions As MIDP 1 0 does not support any additional features than those already provided in CLDC there practically does not exist any security for the user to deal with KTopley The result is that MIDlets is a potential threat to the user The limited security included ensures that MIDlets have no access to information stored on the phone such as telephone number lists or calendars and a MIDlet is not allowed to take directly control over the device The data stored by the MIDlets is private to that MIDlet and its suite so it can only harm its own data 3 6 2 Network security and cryptographic solutions When transmitting data over a netwotk it is possible someone is eavesdropping at various points in the network i e listen in on the data that is transmitted This is the reason that something is needed to keep sensitive data from being stolen One solution to this problem is use of cryptography Cryptography is the science of secret writing and is a branch of mathematics that is based on the idea that certain kinds of mathematical problems
136. ertise its own resources Since every peer resource is described and published using an adver tisement the protocol helps a peer to discover an advertisement The protocol can be extended to sup port more superior discovery mechanism but the inclusion of this default protocol ensures that JXTA peers can understand each other at the very basic level 5 4 2 Peer Information Protocol Peer uses the Peer Information Protocol PIP to obtain status information about other peers for in stance state uptime traffic load and capabilities Receiving a PIP message leaves the peer with several options It can ignore the ping send a simple acknowledgement consisting only of its uptime or send a full response which includes its advertisement 48 5 4 3 Peer Resolver Protocol Peer Resolver Protocol enables a peer to send a generic query to search for peers peer groups pipes or other information to one or more peers and receive response or multiple responses to the query In other words the protocol implements a query response protocol where a query to a peer only can be sent after the peer is discovered via PDP The intention of the protocol is to standardize the format of these queries The response message is matched to the query via a unique id included in the message body PRP is typically implemented only by those peers that have access to data repositories and offer advanced search capabilities 5 4 4 Pipe Binding Prot
137. ery on a peer s behalf 5 3 5 Entity Naming To uniquely identify items on a P2P network like peers peer groups pipes and contents some informa tion to represent the uniqueness is needed A peer using TCP IP transport could be identified by its IP 45 JXTA address but use of system dependent representation is inflexible and cannot provide a system of identi fication that is independent of the operating system or network transport Any device regardless of their operating system or network transport should be able to participate in an ideal P2P network As a result a system independent entity naming scheme is a requirement for a flexible P2P network A ID uniquely identifies an entity and serves as a canonical way of referring to that entity IDs are normally presented as URNs which are a form of URIs that are intended to serve as persistent location independent resource identifiers JXTA IDs are presented as text 5 3 6 Security Security is not implicit in the JXTA framework but the framework provides the means for strong security to be implemented using well understood trusted approaches The XML messages allow adding a large variety of metadata information to messages such as credentials digests certificates public keys and sim Credentials ate a token used to identify the sender of the messages and can be used to establish pub lic private key and digital certificate technolog
138. ethod beside the constructor and inherited methods is recetveMes sage ITSMessage This method is called by the NetworkClient when an incoming message has arrived for the user The class diagram for the ITSClient and the DatabaseClient is illustrated in Figure 7 16 The DatabaseClient uses the Record Management System javax microedition rms package of MIDP to achieve a mechanism for MIDlets to persistently store data and later retrieve it RecordStore is the class representing the collection of records that contributes the database The database will consist of contacts contact ids groups and group ids 72 The Prototype MIDlet from javax microedition midlet lt lt gt gt MIDIet lt lt gt gt startApp lt lt gt gt pauseApp BSigetAppProperty key String String BSinotiftyDestroyed BSinotityPaused BSiresumeRequest lt lt gt gt destroyApp unconditional boolean ITSClient BSiTSClient BSireceiveMessage msg IT SMessage void BWSicommandAction c Command d Displayable void CommandListe ner 1 lt lt 5 5 gt gt 1 from x micro ed tion lod ui DatabaseClient WSigetUserName String BSigetGroups String I BSigetContacts String WSi static DatabaseClient BSistoreGroups groups String boolea
139. etwork is not reachable But as long as the mobile terminal has contact with a network there is nothing indicating that it cannot run undisturbed for 12 hours If a user disconnects from the network he cannot continue his session when logging on within 5 minutes since the state of the user is not stored anywhere When the network connection closes the user will go off line but he should still be able to execute the tasks that are not dependent on network connection like editing the group list etc Response time NF 9 states that the user should receive response from the relay within the set poll interval As of today the messages are placed in a queue at the relay server and the first message in the queue is returned upon request form a client As a result the desired response time is rather optimistic since it assumes that the next message in the queue is the response to the last request from the client In situations with low traffic this might be the case but at times where several request are made between the poll intervals for example 105 Discussion at start up there will be problems to fulfil the requirement Another problem is when several messages are received from the network for example while performing a search An improvement could be that the server could return all messages in the queue upon a request from the client 8 5 3 Alternative network technology solutions Another technology that could be used to connect
140. eved by use of Global Positioning System GPS or other positioning sys tems Next generation of mobile communication like UMTS will include positioning 7 5 2 Speech Another improvement of the system would have been if the user could control the application by use of speech In the current version the driver is dependent on passengers to send and retrieve information With introduction of speech recognition and speech control a driver on his own would be able to use the prototype This could be very useful for truck drivers for instance who drives mostly on their own Control by speech should also include that the receiving message could be presented from the terminal by speech and not only by text The user should be able to choose type of control and communication either speech or text 7 5 3 Maps To further improve the service the user should have the possibility to send and receive maps over a spe cific location Maps should also be available on different servers on the network J2ME already supports 84 The Prototype downloading of png images using HTTP so this should be a minor addition that adds great value to the service 7 6 Testing Different standards exist for testing of application These states the procedure for testing i e what to go through when testing Other focuses on the security requirement for the application and states demands for the development testing acceptance management and maintenance
141. evices JAIN SIMPLE Presence and JAIN SIMPLE Instant Messaging are both proposed by Panasonic Infor mation and Network Technologies Laboratory and were accepted as specifications in the Java Commu nity Process in January 2002 The goal is to create an API that is independent on a specific SIP SIMPLE vendor and to allow integration with other JAIN solutions JAIN SIMPLE Presence provides a standard portable and secure interface to manipulate presence infor mation between a SIMPLE client watcher and a presence server presence agent Capabilities that are needed to support presence are presence servers receiving subscription requests authentication and au Appendix F Presence and Instant Messaging thorizing requests sending notifications read write presence information etc and presence clients buddy and buddy list manipulations sending subscriptions receiving notifications etc JAIN SIMPLE Instant Messaging provides a standard portable and secure interface to exchange messag es between SIMPLE clients Instant messaging capabilities are sending messages receiving messages opening and closing messaging sessions resuming messaging sessions etc E3 Generic presence and instant messaging APIs for J2ME There exist a multitude of messaging protocols as well transport protocols For the user it would be of great value to have one API to deal with and not be concerned of the underlying protocols Two APIs are under deve
142. execution This might be secure storage to protect sensitive data such as the user s private keys public key certificates service credentials and personal information Other areas might be to ensure a secure execution such as cryptographic op erations to support payment protocols data integrity and data confidentiality And last add security fea tures that J2ME applications rely on to handle value added such as user identification and authentication banking payment ticketing loyalty applications and digital media play It is suggested to implement the security element as smart cards as they are widely deployed in wireless phones such as SIM cards in GSM phones As a result the specification will provide an access model that enables appli cations running on 2 enabled devices to communicate with a smart card inserted in the device JSR 177 2 7 Summary J2ME is a collection of APIs focusing on consumer and embedded devices The main components configuration and profiles where the configuration covers the most fundamental features in the java en vironment and the profiles defines additional functionality like user interface storage and network capa bilities One of the two configurations is the Connected Limited Device Configuration CLDC which is the fundament for the Mobile Information Device Profile MIDP the profile in focus in the rest of the chapter netwotk capabilities of MIDP is
143. f the group does not exist the group will be created when the user chooses to join the group Search for similar groups will result in a list of groups that the user can access from the group menu The reason for not viewing the search result immediately after the search is because of the asynchronous na ture of JXTA When the list is viewed the user can choose the most appropriate group to be added to the group list 7 4 7 Network independence non functional requirement NF 1 which demands network technology independence is fulfilled by putting all the network functionality in one class NetworkClient None of the network specific classes are visible for the ITSClient The data type ITSMessage is introduced to exchange information between the ITSClient and the NetworkClient The application is also independent of how local data is retrieved and stored since all functionality for fetching stored information and storing information is hidden in the DatabaseClient To further ensure the independence an exception hierarchy for the l ISSystem is introduced The super class ITSException is abstract meaning that it can only be instantiated by instantiating one of its sub classes ITSException has two subclasses NetworkException and DatabaseException These exceptions makes the ITSClient able to make decision on background of the information notify the user and end the application if a critical exception occurs As a result the ITSClient i
144. first of all illustrate the concepts of J2ME CLDC MIDP and the possibilities with JXTA for J2ME When the requirements for the main functionality were fulfilled the usability was con sidered After carrying out a couple of user test some changes needed to be done to the system If this was a teal system and not a prototype meant to demonstrate and understand the technology of J2ME the user tests would have been taken more under consideration Section 7 6 5 will summarize the result from the user tests and alternative solutions will be presented 7 5 ITS System in the future In this version of the ITSSystem the service is actually a chatting service that could be used in other oc casions as well By using location based technology the service could be more specific for the domain it was actually intended for Many improvements must have been made to the system to make it really use ful and this chapter will make some suggestions for future versions of the system Some of the solutions are not yet possible because of missing or incomplete technology 7 5 1 Location based technology Ideally the application should be able to figure out where the users are situated and join the appropriate group based on this information If more than one group is available the user should be asked to choose between the given groups for the area In this way the user should be able to use the service without knowing the location Such a solution could be achi
145. g Web Services and Microsoft NET In addition the reader should read the brief discussion in chapter 8 JXTA If JXTA is the area of interest and the usage of the technology in relation to J2ME MIDP the reader should concentrate on chapter 3 chapter 5 and the prototype in chapter 7 In addition the reader should take a look at the parts of chapter 8 that discusses the prototype Software development project Readers interested in the software development project should concen trate on chapter 7 and the part of chapter 8 that discusses the prototype Several of the appendixs also includes information about the prototype like appendix C D E and F Chapter 2 Background Discovery consists in seeing what everyone else has seen and think what no one else has thought Albert Szent Gyorgi Embedded devices have gained great success and analytics recognise that these computers will become a common part of our society during the next decades The technology has many possibilities but also limitations Both will influence the networking capabilities for embedded devices This chapter will start by providing an overview of embedded devices their capabilities and limitations in general and in relation to application development and network technologies It then moves on to give an introduction to network technologies before moving on to a presentation of the client server net work architecture and the new peer to peer network
146. generic re quest response queries The protocol uses XML or binary messages to transfer information between peers JXTA for J2ME JXME is a project that aims at providing JXTA functionality to java enabled embed ded wireless devices a result of the network limitations in MIDP the implementation is dependent upon a relay to do most of the work The other part of the implementation the JXTA for J2ME peer provides a simple API that uses HTTP to communicate with the relay 52 Chapter 6 Related work Variety s the very spice of life that gives it all its flavor William Cowper Different projects are initialized and focuses on technologies that are related directly or indirectly to the network technologies discussed in the former chapters This chapter takes a brief overview of some of them and their functionality according to java enabled mobile devices The project presented is the AM IGOS project at NTNU which includes different technologies to form Meeting Places for users to es tablish and participate in Other interesting new technologies are Web Services and the NET technology from Microsoft which both have some of the same goals as and Jini 6 1 The AMIGOS project AVANTEL Advanced Telecom services Avantel is a project co operation between NTNU Telenor and Ericsson established in early 2001 and is the starting point of the AMIGOS project AVANTEL is related to and support the intent
147. group The advertisement holds information about the meeting place like location requirements for joining and so on To discover a meeting place or browse meeting places a peer first need to join the peer group Then the peer are able to send a discovery message to the peer group The peer that created and announced a specific meeting place must manage it like setting require ments that limits the users that can join the meeting place and giving users access C Meeting places as peer groups The last suggested solution is based on the previous solution explained above but differs in one signifi cant way Meeting Places are peer groups themselves and it is the joint responsiblity for the peers in a peer group to manage the it like setting requirement for access and giving access Advantages and limitations The first suggested solution only introduces discovery of the AMIGOS server and as a result re move the dependency on pre knowledge in the clients when it comes to the location of the AMIGOS server In addition it introduces JXTA mechanisms like fault tolerance As communication is done using XML this allows for the entities to be implemented in any programming language and run on any plat 110 Discussion form The solution also introduces mechanisms to further support usage of other resorces in the network like printers scanners etc Solution B introduces a decentralized mechanism that is more fault tolerant t
148. han the previous solution since the responsibility is shared among many entities in the network The solution solved the problem with authorization since a peer must be authorized before it is alowed to join the AMIGOS group and browse the Meeting Places But it also introduces a complexity a client cannot have the total overview of all meeting places It has to initiate a search for meeting places that does not guarantee that all existing meeting places are found The last suggested solution uses nested groups a functionality that is not dictated in the specification As of today the mechanism is not available in the reference implementation but it introduces new possibil ities as sketched in solution C The main group represents the AMIGOS service and the peers in the peer group handle authentication and jointly have overview of the meeting place peer groups The distributed environment can be both an advantages and a disadvantage since all assignments are shared among the patticipating parties As solution B solution C introduces a complexity in relation to the total overview of meetins places a peer must initiate a search for meeting places that does not guarantee that all existing meetin places are found C The AMIGOS 4 Communicate with Peer Group the meeting place through private pipes qe 7 d Meeting VOX Place 1 y 3 Discove responses 2 Discovery User Profile
149. hat to install and how to run the application Appendix Presence and Instant Messaging Presence and Instant Messaging is an old concept in the computer software industry Many software and proprietary protocols have been developed to support exchange of messages between users both in the computer network environment the telephony world But most of these solutions are not interoperable Lately several initiatives have been made to create a standard protocol for presence and instant messag ing Presence is the notion of an entity being a part of a network The entity can be for example a mobile device a PC or a telephone Concepts important to Presence would be when an entity enters and exits a network and relevant information about the entity such as location duration relationship to other en tities and similar Instant messaging is the action of exchanging messages between two entities in a net work The capabilities included are sending and receiving messages opening and closing messaging sessions resuming messaging sessions and other actions relevant for message exchange Presence and instant messaging protocols that have been devised or that are currently being designed is Wireless Village WV SIMPLE Jabber AIM MSN and Yahoo Some are intended for legacy networks and others for IP telephony networks Jabber is an open XML based protocol Multiple implementations exist and these have mainly been used to p
150. he Jini service ID to allow a serialized Java Object to be returned to the peer There is already a project going on to integrate an XML parser in the Jini architecture Jump Jump Sev eral other changes are also proposed with the objective to embrace P2P in Jini A project based on the Jump project JumpStart JumpStart has proposed to incorporate Jini with the assumption that Java developers wants a tool that allows objects to be moved around The project caused a large discus sion in the JXTA community and has not been accepted as a JXTA project at present time In addition to the above mentioned changes JumpStart will use Jumpers in the form of pre configured set of peer routers to forward messages on behalf of the peers S 3 JXTA as communication platform in Jini A third solution is to make Jini use JXTA instead of RMI to communicate between nodes in the network Since both Jini and are protocol frameworks where Jini solves application protocol problems while JXTA solves transfer protocol problems it should be possible to use JXTA to transport Jini que ries and proxies Jini is not dependent upon RMI and may gain by using JXTA which is independent of programming language and platform messages can transfere any information including proxies and Jini queries and can include information describing the information included in the message This way JXTA resources with Java support will
151. his would have been taken into consideration before the final result of a program was released 7 7 Summary This chapter has presented the design and implementation of the ITSSystem a prototype developed to show some of the features of JZME MIDP for J2ME I TSSystem is a first generation location based system where users being a specific area are able to communicate and exchange information related to the users location Typical areas are big cities or distances where users are out travelling for example driving from Oslo to Trondheim 93 The Prototype Both functional and non functional requirements were stated and a design where made All the necessary components for a working system was included but only part of the system were implemented the pub lic room In public room users can participate in a group according to location and messages from one group member is sent to all members of the group The user is able to join groups add or delete groups in his private list and edit setup to control how many messages that are visible at a time in a conversation and how often to poll the proxy setver Some implementation issues were discussed like how the implemented prototype meets some of the non functional requirements how errors and exception are handled and some limitations of the proto type Also some thoughts for the future for further improve the value of the system where mentioned Like controll
152. http developers mototola com developers wireless 9lobal uk A008 html Advanced Multimedia In Group Organised Services AMIGOS online http www item ntnu no avantel AMIGOS html Rational behind AMIGOS see Amigos Dictionary for AMIGOS see Amigos Requirements Specification for AMIGOS see Amigos Use Cases for AMIGOS see Amigos Examples of Meeting Places in AMIGOS see Amigos The Anhinga Project online http www cs tit edu anhinga Advanced Telecom services AVANTEL online http www item ntnu no avantel Bouncy Castle cryptography package online http www bouncycastle org Joakim von Brandis Sammer job at PATS with focus on location services in AMI GOS June 2002 JSR 139 Connected Limited Device Configuratin 1 1 online http jcp org jsr detail 139 jsp Gong Li X 174 A Network Programming Environment IEEE Internet Computing May June 2001 Gong Li Sun Microsystems Inc A Network Programming Environment IEEE Internet Computing volume 5 Issue 3 May June 2001 page 88 95 119 Reference Library Computer Computing EJava Eric2000 Forte Frisk GNUpl Gnutella Gollmann Gong Graham Gupta IBM IEEE Insignia iPaq IPInt IPIntSpec ITPro Computer Volum 34 Issue 7 July 2001 page 21 Golden G Richard Service Advertisement and Discovery Enabling Universal Device Cooperati
153. ice Profile MIDP 1 0 The wireless toolkit runs on any Java 1 3 enabled platform and can be downloaded and used free of charge from java sun com alis Qum Was es cr a Figure E 1 Screenshot of the wireless toolkit from Sun J2MEwtk Optionally the toolkit can plug into Sun s Forte for Java Community Edition IDE Forte Forte is a de velopment environment from Sun and the Java Community Edition can be downloaded and used free Appendix E 3rd party software development tools of charge Doing so makes the developer able to develop and test applications from start to finish but the developer is free to choose development tools since the toolkit is only capable of compiling running and packaging the application 2 Compaq iPaq Pocket PC An iPaq Pocket PC is a powerful mobile device from Compaq iPaq They are powered with Microsoft Windows and are not equipped with any development tools or platforms for running Java applications Figure E 2 Compaq iPaq An iPaq can use different PCMCIA cards by usage of an expansion pack that holds the cards that can be attach to the iPaq This is useful to get the iPaq online by using a WLAN card or a GPRS card which is of interest in connection with MIDP application development Other cards used could be a GPS card to determine the current location of the iPaq IPaq are powerful handheld devices and are able to run full Java 1 3 under Linux Most at
154. ide of the firewall and both parties must support HTTP transport In addition the firewall must allow data transfers but the HTTP transfer need not be restricted to port 80 The other solution is that the JXTA node can be configured to communicate via a HTTP proxy servet and in this setting the above mentioned peers become routers for P2P traffic among the other peers in the peer group Multiple peers can route P2P JXTA messages across the firewall Today the set ting to support firewalls and HTTP transport is done in configuration files but more advanced treat ments are expected to come JXTAfaq 5 2 2 The service layer The service layer includes network services both common and desirable in the P2P environment but may not be absolutely necessary for a P2P network to operate Example of setvices are searching for re sources and peers sharing of documents between peers peer authentication and Public Key Infrastruc ture PKT services Services on the JXTA network is published discovered and invoked by cooperation and communication between peers Two levels of services are recognized by the JXTA protocols Peer Service Peer Group Service A peer service is accessible only on the peer that is publishing the service and if that peer fails the service also fails Services provided by a peer group is composed of a collection of instances of the service run ning on multiple members of the peer group a result the coll
155. ient called searchContacts For each contact that is online the client will receive a message containing information about the contact and the contact is add 77 The Prototype ed to the users visible list This is illustrated in Figure 7 25 client ITSC database network DatabaseClient Net work Client getC ont acts searchBuddies String receiveMessage TSMessage edit editList add searchB uddies String receiveMessage ITSMessage delete deleteContact String Figure 7 25 Sequence diagram for editing a contact list If the user wants to delete one of its contacts this is done by removing the user from the internal contact list of ITSClient The changes will be reflected in the database after storing the list to the database upon closing the application On the other hand if the user wants to add a new contact the NetworkClient need to search for the contacts in the JXTA network which in turn will return information about the contact to the ITSClient The contact is added to the internal contact list and stored in the database upon closing the application as shown in Figure 7 27 When the user is either participating in a public or private room it can start sending and receiving mes sages This is shown in Figure 7 26 1 sendMessage ITS Message client network ITSClient lt NetworkCli
156. ierre tree th ree ot are e EX EVER EE ted E eR e Pea ede agn 104 6 5 1 Design Decisions iii agen Pada ey act ROI ec Mee i EN Res 104 8 5 2 Non functional requirements esses eee 105 8 5 3 Alternative network technology solutions esses 106 8 6 JINI AND JXTA IN 106 ONE EC ERE a 107 8 6 2 c tide teet t E tita eet ten eei eite OE gs 109 xi Table Of Contents 8 7 SCENARIOS FOR THE FUTURE ccccccsessssessssssscscscscececeeeececscscececececsescsescsseseseseseseeeseeeeeeeees 111 8 7 1 Personal Area Network 111 8 72 Improvements to IX TA suce e HERO IR ER na ae Oia ER 112 8 7 3 The existence of an optimal solution essen 112 CHAPTER 9 CONCLUSION cccessisseccsccscescccesesstteacscccsecsscteccsccseonscctenesccsueccccdeavesssbsvccs cocessseasesosts 113 CHAPTER 10 ABBREVIATIONS e e na Eee ea Un ERE 115 CHAPTER 11 REFERENCE 1 1 14 e e en ases ee 119 APPENDIX A ADDITIONAL PACKAGES FOR J2ME A 1 Az LOCATION API FOR J2M E 1 A 2 WIRELESS MESSAGING reper eee 1 3 EET NER E
157. ies to implement an effective approach to authentication Project JXTA have made three choices when it comes to security J XT ASec ITProf Adoption of Transport Layer Security TLS TLS End to end transport independence of JXTA protocols Use of X509 V3 digital certificates where centralized certificates authorities not are mandatory but not excluded either Transport Layer Security TLS is an industry protocol for secure transport of information and a continua tion of Secure Socket Layer SSL TLS is currently under development by the Internet Engineering Task Force Network Working Group The implementation of TLS chosen by the JXT A project to be included in the JXTA distribution is Pure TLS PureTLS from Claymore Systems Application Data Application Data 1 Messages JXTA Messages Pipes it peerlD2 1 Virtual TLS Transport peer D4 Pipes of peerID6 Firewall Relay peerID3 02 Relay Figure 5 3 Project JXTA Virtual TLS transport JXTASec Figure 5 3 visualizes the JXTA TLS transport On the physical level peers are connected through fire walls and designated relays TLS connections create a virtual layer on top of the physical layer where JXTA messages can be exchanged securely 46 End to end transport independence was one of the design choices of project is of
158. iew contact list The user shall be able to see a list over personal contacts This list will only contain the contacts that are online and participating in the same group as the user Figure 7 9 illustrates F 11 and shows that a user may edit the lists as stated in the next requirement Initiator View Contact List View Contact Status Edit Contact List Figure 7 9 Use case diagram for viewing the contact list F 12 Edit contact list The user shall be able to edit the contact list either by deleting contacts or adding new one by searching for contacts in the group 66 The Prototype P 12 is illustrated in Figure 7 10 and is identical to the use case diagram for requirement F 9 Edit Contact List Initiator Peer Group lt lt include gt gt Delete Contact Add New Contact Search for contacts Figure 7 10 Use case diagram for editing the contact list A use case diagram showing the entire system can be found in Appendix 7 2 2 Non functional Requirements The non functional requirements for ITSSystem includes both general requirements for the develop ment and some performance attributes Performance attributes ate included to be able to validate the technology but is not of vital importance for this prototype Later versions should seek to fulfil these requirements Each non functional requirement is assigned an identity in the format NF lt number gt where lt number gt is a sequential number
159. ing A software distributor can have multiple versions of the same software running and place new software in the JavaSpace on upgrading When users ask for an upgrade access to the new service might be granted JiniJO02 Jini transaction service is an implementation of the Jini transaction interface and provides distributed trans actions for the distributed objects The transaction model is a completion protocol that uses two phase commit but it does not guarantee ACID properties and leaves it to the individual object to handle them It also supports nested transaction leasing and even notification and can be used by any application that needs a distributed transaction within the Jini community Kumaran 4 3 The Jini community The Jini community explores develops and evolves the Jini network technology Their website JiniOrg share ideas related source code documentation and other development work based on Jini technology The site facilitates collaborative development by providing discussion forums news groups chat mailing lists and anything else that brings the community together Jini community is building the necessary structures in the network technology while Sun has the over view of the technology and the community Developers can participate in projects or create a new project if none of the existing projects covers the developer s interests All projects are licensed under the Sun Community Source License New projec
160. ing and Presence Leveraging Extensions SIMPLE 2 Session Initiation Proposal Investigation SIPPING Ad Hoc Network Technology Peer to peer is often mixed with ad hoc networks and many claims it is the same phenomenon One may say that peer to peer is a paradigm and ad hoc is a realisation of the paradigm where the peer to peer functionality is places in the lower layers of the protocol stack and therefore is dependent on the physical medium Other peer to peer realisations might concentrate on making the implementation of the paradigm independent on the network technology and so solves the problems at the application lay The term peer to peer is mostly used about the latter Ad hoc network is a network that forms without any central management and consists of mobile nodes that uses a wireless interface to send packet data The networks are self organized and independent of infrastructure and the organization and maintenance is influenced insignificant by the environment but be handled by the users of the network Self organized networks are not intended as replacements for existing and future infrastructure based networks but as a complement in areas where cost limitations and environment demands such a network Both wired and wireless networks can be defined as ad hoc but the wireless environment is considered the most interesting since the greatest challenges are found there A number of ad ho
161. ing the application by speech deciding the location based on location based technology and alternative network solutions last part of the chapter presents the test specification and the test result for the implemented proto type using the wireless toolkit from Sun and the results of the user test that where carried out 94 Chapter 8 Discussion The important thing in science is not so much to obtain new facts as to discover new ways of thinking about them Sir William Bragg number of subjects have been covered in this master thesis and what would be interesting is to see how they all relate to each other J2M E MIDP has shown that it has several capabilities to support net work connection both client server and peer to peer technologies like Jini and JXTA Even though Jini share many features they have several differences both among themselves and in relation to other technologies This chapter will provide a comparison of Jini and JXTA both the main architecture and the solution for embedded devices Further it will look at different scenarios on how to make the two technologies inter operate before moving to see how they part from Web Services and Microsoft NET As part of the as sigment a prototype was developed to gain experience with and a discussion of some areas of the protype is provided Jini and might be used in many project and the second last secti
162. inter near itself It connects to the Jini network and asks for a printer and is given the reference to the printer It is then able to ask the printer to print out the mail for it without any con figuration issues A more in depth presentation and discussion of Jini both in general and for J2ME de vices will be provided in chapter 4 3 5 2 JXTA The JXTA project defines a set of protocols that makes it possible to operate on a peer to peer basis and a message format to be used to communicate As a result JXTA is independent of implementation lan guage and platform The reference implementation is in Java but there are projects going on to imple ment the protocols in both C and other languages A more in depth presentation and discussion of both in general and for J2ME devices will be provided in chapter 5 3 5 3 Bluetooth Bluetooth is a wireless point to point networking specification intended to replace the cable s connect ing portable and or fixed electronic devices The key features are robustness low complexity low power low cost and high speed It is intended for use as a personal area network PAN connecting devices such as cell phones PDAs printers and headsets together when they are near each other 24 Network capabilities in 2 The Bluetooth standard is divided in two groups core and profile The core specifications describe the details of the various layers of the Bluetooth protocol architec
163. investigated in MIDP 2 0 Then the attention is turned to network communication and cryptography and what security packages that are available to MIDP or soon to come 3 6 1 Application security on the device The security in Java 2 Standard Edition 25 though both powerful and flexible exceeds the amount of memory size available for virtual machines supporting CLDC It also requires a certain amount of ad ministration that may be beyond the knowledge expected of a mobile device user CLDC and MIDP introduce low level KVM security and application level security The low level secu rity is concerned with verification of java classes while the application level security focuses on the exe cution of application on the java enabled device To ensure that the virtual machine KVM does not do any harm to the device in which it is running the java classes must be verified This verifier ensures that the Java class file cannot contain references to invalid memory locations In J2SE this verification is done prior to execution but sine MIDP enabled devices have memory constraints the classes must be pre verified meaning that the verification process takes place before downloading the application Prior to execution the in device verification process is carried out using the information generated by the pre verify tool When CLDC was designed the security model was kept simple and it allows for more comprehensive security solutions in later v
164. ion to an XML schema that defines a SOAP based protocol used to discover and register Web Services 6 2 2 Web Service Models Different models can be used for the Web Service architecture but the primary model is the Service Ori ented Architecture SOA model is a distributed approach that assigns different roles to the involved parties in a Web Service while abstracting all details in what manner a service is actually implemented or build The description of the physical parts that must be included to build a working system is left to the SOA component model which will not be discussed further Other models are under development that is modelled for highly distributed environments Frisk a Publish WSDL UDD SDL UDDI Requester Provider C Service Description gt p Figure 6 3 Service Oriented Architecture SOA The SOA is the fundamental architecture for Web Services and is illustrated in Figure 6 3 SOA defines three roles Requester Provider and Broker The requester is the point of initiation for a request while a pro vider is the point of request consumption and hosts the exposed service descriptions The broker is a repository which keeps service descriptions and allows a requester to find the services it wants to use The primary functions in SOA are explained in the list below Publish Lets a provider advertise its service interfaces to a broker
165. ions and visions of PATS Program for Advanced Telecom Services Pats a research program agreement between NTNU Compaq Computers Norway Ericsson and Tel enor which vision is to establish a virtual centre of excellence on advanced heterogeneous services and fast service development Avantel The focus of AVANTEL is to utilise platforms and development environments in combination with mo bile terminals and demonstrate the new range of possible telecom services available with introduction of new technologies These technologies is among others GPRS and UMTS and new software develop ment libraries APIs for service logic like Parlay OSA which is a set of open standardized APIs to ac cess core network functionality AMIGOS Advanced Multimedia In Group Organized Services Amigos is a service platform under de velopment in the AVANTEL project Further it is an example service that aims at giving the activities in the AVANTEL project a unifying direction The AMIGOS service is a generic service that provides users with the possibility to establish and participate in Meeting Places i e virtual rooms where interac tions optionally take place between the participants Amigos02 A Meeting Place might be limited to ge ographical areas and the interaction is exchange both received and possibly sent of computer based information and media streams like text audio and graphics One of the key points is that the users of the service
166. ished by providing a framework where applications can be written in any programming language as long as it is supported in the runtime and all applications are available if they uses the INET framework Jini Microsoft NET uses concepts from the Java programming language such as a common run time exe cution environment Jini and NET have the same objective to provide interoperability among nodes in a network but the objective is accomplished in different ways But while Jini uses Java and runs on many platforms NET is language independent Microsoft also claims that NET will be available on different platforms but until now only Windows is supported Jini depends upon Java and as a result the services are independent on platform 103 Discussion JXTA As NET is independent of programming language but in such a way that it also is platform in dependent applications can communicate with other applications written in another language and execute on another platform than windows i e it does not require any plug in to handle further plat forms as does NET Web Services aspects of the NET platform uses XML but this does not alone make JXTA and NET comparable since the two platforms have different goals NET focuses more on the traditional client server architecture of service delivery and might form the foundation of a P2P application which would require developers to specify core P2P intera
167. itecture eese eene enne R R 6 2 2 2 Peer to Peer Network 8 2 2 3 Where to use peer to peer eene 10 2 3 EXISTING PEER TO PEER P2P APPLICATIONS eese nnne nennen enne 11 ZIL NQDSIOE ence ee petites 11 su e MR MEME TRAE PAM IAE 11 2 3 3 Gn lella i5 ss TRE rede deitas 11 2 4 Na ee aee RS 12 CHAPTER 3 NETWORK CAPABILITIES IN J2ME eee eren notante tones etae etta esten aoo 13 3 1 JAVA 2 MICRO EDITION J2ME esses enn nnne nennen nennen innen nnne 13 3 1 1 Connected Limited Device Configuration CLDQC sse 15 3 1 2 Mobile Information Device Profile seen 16 3 2 NETWORKING IN 17 SUME A C AE ia bE 17 3 2 2 Protocol implementations for MIDP 1 0 18 3 2 3 Protocol support in the future sese 19 3 3 SERVICE SCENARIOS FOR MIDP APPLICATIONS 20 3 3 1 Standalone service downloaded to the mobile device sse 21 3 3 2 Service execute a remote 21 3 3 3 Service client downloaded to the mobile device
168. ith the username The number of messages viewed at a time is at default set to three but can be changed in the setup The figure to the left shows the public communication screen Appendix D ITSSystem User Manual D 3 1 Create and send a message To create a new message to send click the SEND button The screen to the right will then appear Write your message in the text field and click SEND to distribute the message to the group CANCEL will bring you back to the public communication screen without sending the message D 3 2 Change group If you want to connect to another group you have to select the Change group option from the menu The menu to the left appears if you click MENU from the public communication screen Change group will disconnect you from the current group and bring you to the group list were you can choose another group You can also choose to add a new group to join This is achieved by choosing Add group from the menu and you will then enter the Add new screen After adding a group to the list the group list will appear and you can choose to join the newly created group or one of the other groups You can also edit the setup from this screen and return to the menu after saving the setup If you click CANCEL you will return to the public communication screen and you will still be participating in the same group The same thing will happen if you choose the Back to lt group name gt o
169. its early stages today it is expected to mature over time to provide a robust and reliable framewotk for P2P computing community has discussed the possibility to submit the JXTA protocols to an outside organi zation and process for formal standardization and most appropriate forum to standardize JXTA proto cols was considered IETF Late June 2002 it was announced that the JXTA protocols has been accepted as an Internet Draft J XT Adraft and has started the way to standardization rest of this chapter will focus on the JXT specification and the reference implementation of the specification which is written in Java and imposes several dependencies For example the pro tocols implemented to support HTTP and TCP IP transport 5 2 Architecture JXTA architecture consists of three layers the platform layer the service layer and the application layer as shown in Figure 5 1 JXTA Community Applications Applications Shell Service Layer JXTA Community Service Sun JXTA Services Peer Groups Peer Monitoring Platform Layer JXTA Core Applications Layer Security Figure 5 1 The JXTA 3 layer architecture The boundary between services and applications is not rigid An application to one customer can be viewed as a service to another customer The entire system is designed to be modular allowing developers to pick and choose a collection of services a
170. k CAN The public communication screen OK CEL appears without sending the message just written 5 8 Select Setup in the menu and click The user enters the Setup screen NOK OK but does not leave the group The group is only left if the user alters var iables in relation to the network like relay address and port T 5 9 Select Change group in the menu The user leaves the group and enters OK and click OK the group list screen that lists the available groups if any T 5 10 Select Exit in the menu and click The application closes OK OK T 5 11 Click BACK when in the menu The user is still participating in the OK same group and the screen for public communication appears Table 7 7 Test Specification and results for group chat public mode T 5 8 was not passed since the prototype never leaves a group upon exiting the Setup screen since the variables for relay address and port is never checked for changes As of today the user will always be member of the group until he actively leaves the group Contact overview private mode Testing the contact overview requires the user to start the application and log in private mode with or without other changes to the setup From the group overview the user must select a group to join and The Prototype will upon joining a group be presented for the contact list The test cases presented in Table 7 8 have this as their starting point
171. l client is an ex ample of a service Access Network 581 w Network Mobile Servet Client Figure 3 9 Service client downloaded to the mobile device The advantage of this scenario is that the heavy computational task are left up to the more powerful serv ices but the client can itself do minor computation and is so less dependent upon the servet to complete a task It also creates possibilities for the client to be part of the enterprise and makes the user able to store information at one place and fetch it independent on device time and place As the previous scenario this service scenatio creates a dependence on a central server and as a result the setvice is dependent on network connection Access Netwotk Services Services Client Figure 3 10 Mobile device to mobile device services 22 Network capabilities in 2 3 3 4 Mobile device to mobile terminal services Mobile devices might wish to establish connections with each other to provide receive and use interac tive setvices The setvices may be downloaded to the devices via the interaction of the mobile devices ot a combination of one of the above mentioned scenarios The services may execute locally without re lying on servers to support the service Examples of such services are interactive games and sharing of calendar information As of today this sort of communication has to go through one
172. li cation packaged as an IBM file type jxe Java Executable to make it run As a result the Websphere en vironment had to be set up on a computer to generate the file This was a time consuming process because of the insuffienct information and messy presentation of the information that was provided The installation of the iPaq was neither a trivial task but at the end it succeeded with help from other devel opers Even so the application did not execute but left an error message complaining that something was wrong with the jxe file Availability NF 6 states that a user should be able to connect to the network and register with the service in 90 of the cases Network connection is dependent upon the device in use and available network connection capabilities for this device The most likely solution for devices using the first version of the ITSSystem is using the GSM network as access network to the Internet Then the availability of the network is de pendent upon the availability of GSM covered areas and whether the base stations are busy or not i e maximum other incoming or outgoing connection is reached In addition the current application is de pendent on the rendezvous peer that act as relay to be up and running Reliability The non functional requirement NF 7 which is concerned about the reliability has not been taking into consideration when implementing ITSSystem The services of the application are inaccessible when a n
173. likely to gain success with the introduction of GPRS and 3G if its capabilities is made visible for the potential users Adding new features requires more resources on the devices which is likely to increase according to Moore s law combination of MIDP and the Jini surrogate architecture creates possibilities for the device to utilize resources that otherwise would have been unavailable for example printers scanners and other comput ers At the moment Jini is not recommended to be used in commercial applications since the surrogate architecture is young not fully tested and needs further research Requests to the lookup service has also proven to be slow and the delay will limit the usability of applications since users require fast responses Even so the Jini surrogate architecture seems more thought out than the JXTA alternative when it comes to giving all devices access to a networking environment Java enabled or not 113 Conclusion JXTA is very promising with its independence on both programming language and platform What might prevent the use of the architecture is the complexity i e many concepts and protocols to keep track of In my opinion this is the most suitable architecture for highly mobile Java enabled devices in the future since the JXTA for J2ME package is easy to use and does not necessarily require any knowledge of JXTA The conditions are that J2ME will gain success and that the capabilities of MIDP increas
174. lizing trends in software engineering intersecting with available technology Powerful networked computers and inexpensive bandwidth Intersecting this trend is the growth in the available of powerful networked computers and inexpensive bandwidth Peer to peer requires the availability of numerous interconnected peers to be effective Popular programs Also non technical issues was important like the popularity of products like Napster Gnutella and similar programs Figure 2 2 Peer to peer Architecture Decentralized architectures like peer to peer have almost opposite characteristics as centralized systems favourable properties of the peer to peer architecture are Capacity Takes advantages of unused processing capacity in the Internet Exploit available band width across the entire network by using a variety of communication channels and filling band width to the edge of the Internet Independence Prevent the dependency on a central setver to provide services Configuration Remove the limitations of demand for configuration before use and is therefore classified as a self configured network architecture Decentralized Consists of mobile nodes where each node has the same status and can request and provide services for each other and create a network without a central control Reduce net work congestion by enable communication via a variety of network routes Background Extensibility Any node
175. logies Jini and JXTA Jini is a distributed network technology that is designed to handle dynamic environments It is based on the assumption that Java is present in the network and ensures a homogeneous environment by use of mobile code that is transferred between clients in the network All resources in the network are defined as setvices can be found through a lookup service a sort of repository holding reference to all serv ices Jini provides the surrogate architecture to make resource constrained and or non java enabled de vices able to participate in the Jini community JXTA 15 a distributed platform that tries to standardize peer to peer The objective is to provide interop erability between entities in the network be platform independent and offer ubiquity i e any device with a digital heartbeat can participate defines a number of concepts that are common for peer to peer networks like peer peer group and pipes These concepts are the primary components of the JXTA plat form The base of the JXTA specification is a set of protocols that enable discovery of resources on the network and the ability to connect and communicate with these resources JXTA provides a package that makes it possible for J2 ME enabled devices to participate the community To find out the possibilities and limitations of JXTA for 2 a prototype was developed as part of the master thesis The prototype called Intelligent Traffic Service S
176. lopment to support a protocol agnostic API for instant messaging and pres ence JAIN API for Instant Messaging JSR 187 and JAIN API for Presence JSR 186 The former is intended to provide a standard framework for developing and deploying new Java instant messaging ap plications and services while the latter focuses on a framework for presence Both frameworks will re quire no prior knowledge of the underlying protocol which could be for example SMS MMS WAP WSP HTTP or HTTPS In addition the applications should be interoperable i e able to run over a wide variety of protocols such as Wireless Village SIMPLE Jabber AIM MSN and Yahoo The presence specification covers presence from the entity that is when and how a device enters an exits a network and addresses the interfaces a client require to communicate with a Presence server Java spec ification JSR 123 Presence Availability and Management JAIN PAM addresses the needs and concerns of presence for a server within a network Both specifications are proposed by Panasonic Information and Network Technologies Laboratory and accepted in the Java Community Process in May 2002 The work is estimated to take up to three years from the time the Expert Group start its work
177. lso be created in Jini but there is no standard for it Communication layers The communication layers in JXTA are abstracted and runtime bound and so addresses some of the pitfalls you might encounter with Jini when crossing netwotk device and platform boundaries Flexibility XML gives more flexibility than object serialization Some disagree with this point arguing that Java is a very dynamic and flexible language and no example has been shown for something in XML that cannot be done in Java if one assumes that XML is used in communica tion between Java systems 97 Discussion Complex JXTA might seem overwhelming with many concept and protocols to keep track of Jini appeats simple with its clients services and lookup servers Debugging Debugging is easier in JXTA than in Jini since developers are able to look at a JXTA stream and understand what is going on To debug Jini or more precisely RMI special debugging tools are needed to read the objects being passed back and forth and peek into what RMI is doing under the covers The debugging tools often use the Java reflection library and a developer can use the library directly if he wishes The Java reflection library API represents or reflects the classes interfaces and objects in the current Java Virtual Machine It can be used to fetch information about a class fields methods constructors superclasses and all other information in realtion to the object
178. lue tooth and WLAN nor access technologies like GSM GPRS and UMTS Other areas that will not be covered in relation to J2ME are technologies like XML SOAP or SyncML XML is a markup language that handles structured information SOAP is a XML HTTP based protocol for accessing services ob jects and servers in a platform independent way while SyncML is used to synchronize data over a net work 1 3 Reader s guide As this report is extensive and some parts might be of more interest for some readers than others this reader s guide is included to guide the readers in finding what they are looking for First a presentation of the chapters will be given and then some tips for different kinds of readers Chapter 1 Introduction The chapter you are reading now Introduces the assignment its objec tives and limitations In addition it provides a readet s guide Chapter 2 Background The document starts with a background chapter that gives and introduc tion to mobile embedded devices and the network technology paradigms client server and peer to peet Chapter 3 Network capabilities in 2 Presents the JZME with focus CLDC and MIDP and the network capabilities in these technologies today and what capabilities are on their way Chapter 4 Jini Network Technology Presents the Jini Network Technology and the surrogate architecture for embedded devices Introduction Chapter 5 JXTA Focus a peer to pee
179. lution Jini is with its lookup service an hybrid peer to peer solution 6 1 2 Similarities Jini and JXTA share a number of similarities despite the differences covered above These similarities are Protocol Frameworks Services Discovety Spontaneous networking and recovery from failure Jini and JXTA are both Protocol Framworks for creating peer to peer structures A framework involve the structuring of processes while protocols involve the transfer of information JXT consist of six proto cols that handles all communication while Jini has three protocols that handle discovery and join of serv ices Services are an essential idea in both specifications Both address the problem of presenting services as available on a network or across networks A user should be able to access services at any time from any device and independent of location Jini and JXTA both use discovery protocols to find services Discovery in Jini consists of discovering the Lookup Service while in JXT discovery is general i e used to find services and other entities in the network directly But there is no limitation in the Jini architecture that keeps it from running lookup serv ices anywhere and so approximating JXTA and pure peer to peer architecture Spontaneous networking and recovery from failure is solved in both network specifications One of the key ideas behind Jini is spontaneous networking and another is recovery from failure
180. ly make it more secure Comprehensive system level approach to security also has to be done and cryptography is just one of the tools in your box MIDP 2 0 will imptove the security by introducing certificates and verification of the MIDelts and SSL to make secure http and socket connections But until this version of MIDP is final and supported in all devices there is limited security against malicious MIDlets 28 Chapter 4 Jini Network Technology Any sufficiently advanced technology is indistinguishable from magic Arthur Clark Jini is the Arabic word for magic and is a distributed dynamic networking architecture developed by Sun Microsystems Sun The vision of Jini is that you can plug in any Jini enabled device into a network and automatically discover and use the variety of other Jini enabled devices in your vicinity Any resources available on the network are available to your Jini enabled device as if it were directly attached to it or the device had been explicitly programmed to use it Adding new devices is easy and adding or moving services can be done without extensive configuration The Jini technology enabled device can announce itself to the network and tell other devices how to talk to it and immediately become accessible to other devices in the network The devices can come together to form an improvised community with no hu man intervention A Jini enabled device can be a digital camera a new printer
181. m supported in 1 0 The database has to be extended to support saving of the contact list and to re trieve the contact list at start up new contact might be added to the contact list and saved to the da tabase and a user must be able to delete contacts from the list 7 2 4 Summary of requirements Table 7 1 summarizes the requirements for the ITSSystem Number Name Functional Requirements 1 Login F 2 Modus of communication F 3 Change mode of communication F 4 Send messages F 5 Receive messages F 6 View group list 7 Join group F 8 Change group F 9 Edit group list F 10 Add group F 11 View contact list F 12 Edit contact list Non functional requirements 1 Network technology independence NF 2 Run in SDK and JWT NF 3 Run on a J2ME compliant device NF 4 Usability 5 Security NF 6 Availability NF 7 Reliability NF 8 Cost NF 9 Response time Table 7 1 Prototype requirements 69 The Prototype 7 3 Design This section will go through the design phase and is illustrated by class state sequence and collabo ration diagrams A class diagram shows how the classes of a system relate to one another while the state diagram focuses on the state changes in just one object While the sequence diagrams shows how object communicates with each other over time collaboration diagrams shows how objec
182. mberOfMessages int int String String Wirsclient ESistartApp void ESicommandAction c Command Displayable void ESipauseApp0 void ESidestroyApp void BSireceiveMessage msg ITSMessage void BSiauthenticateUser userName String Boolean ESisetup void BiviewList void ESladdNew void mypublicMode void ESisendMessage void ESiviewMenu menuType String void ESiviewAlert void BSihelpScreen void Figure C 5 Detailed class diagram for ITSClient Appendix C ITS System UML diagrams and comments C 2 2 NetworkClient Figure C 6 shows the detailed class diagram for the NetworkClient NetworkClient lt lt gt gt final SIMPLESEARCH int 1 lt lt gt gt final ADVANCEDSEARCH int 2 9 lt lt 1 gt gt final ITS SYSTEM GROUP String ITSSystem lt lt static gt gt lt lt final gt gt ITS SYSTEM GROUP String lt lt static gt gt lt lt final gt gt UNICAST String JxtaUnicast static lt lt final gt gt PROPAGATE String JxtaPropagate static final PREFIX String ITS lt lt static gt gt instance NetworkClient network PeerNetwork state byte expollInterval int 10 tsSystemUp boolean false tsSystemAck int tsClient ITSClient String
183. media In Group Organized Services 15 a service that provides users with the possibility to establish and participate in Meeting Places i e virtual rooms where interactions optionally take place between the participants A Meeting Place might be limited to geographical areas and interac tin includes exchange of information and media streams like text audio and graphics Web Services is a service architecture where applications are able to communicate regardless of imple mentation language platform they were developed for and the object models and internal protocol they use The Web Service Platform consists of four parts that forms the common ground Simple Objecct Access Protocol SOAP is based on Extensible Markup Language XML and provides a way to invoke services across the Internet Web Service Definition Language WSDL describes operational informa tion i e where the service is located what the service does and in what manner a requester can make a connection to the service The UDDI database stores and distributes references about the offered Web Services defines a way to describe a company s capabilities and a way for companies to queti each other s 59 Related work capabilities The platform is independent on the transport protocol used to transfere the exchanged data The primary Web Service model the Service Oriented Architecture SOA assignes different roles to the involved patties in a Web Service like Requester
184. ming model or infrastructure for the NET platform Microsoft explains the NET Framework as an environment for building deploying and running Web services and other applications NET faq Basically the NET Framework is just a single platform that anybody can de velop for using a system similar to that used in Java The difference is that any language could be used also within a specific program The current available languages are Managed C C Visual Basic and JScript and more are about to come The framework consists mainly of two patts The Common Language Runtime CLR The NET Framework class library In addition there is a third part the applications that can range from traditional command line or graph 57 Related work ical user interface GUD to applications based on ASP NET such as Web Forms and XML Web Serv ices ASP NET is a programming framework for building web based applications The NET Framework provides a fully managed protected and feature rich application execution environment simplified de velopment and deployment and seamless integration with a wide variety of languages An overview of the NET Framework is shown in Figure 6 4 The Common Language Runtime CLR is the foundation of the NET Framework It is responsible for run time services such as language integration security enforcement and memory process and thread man agement It also manages code at execution time and enf
185. ming service linking the dynamic client user addresses to a specific Napster name To be able to maintain the specific Napster naming technique the Napster server has to be included in every network transaction The Nap ster server offers a naming server a search engine for mp3 files and the Napster client application using the services offered by the server 2 3 2 ICO ICQ is an application where users can keep track of their contacts send instant messages and share files across the netwotk It is the first application that made creating a public network address effortless since ICQ does not depend upon knowing IP addresses domain name servers or hosting facilities Just give the PC a network address and that PC can talk to any other PC with an address in the ICQ name space 2 3 3 Gnutella Gnutella Gnutella is a program that offers sharing searching and downloading of a large amount of file types Unlike Napster the Gnutella protocol does not maintain any form of central caches and does not offer a new naming policy to deal with the dynamic client IP addresses A central IP address table is not necessary either and the reason why 1s that the peer IP address is broadcasted when a peer connects to the Gnutella network Gnutella peers are also connected to different peers for every single connection that is initiated Even though Gnutella does not provide a central server it has the same configuration problem as Napster who to contact
186. mmetric Installation of MIDlets should only take place when the software comes from trusted sources but today there no mechanisms for the user to be completely sure who is actually providing a MIDlet or that the MIDlet code has not been interfered with on the route to the device J2SE includes an authentication mechanism i e public key cryptography and certificates but this is not included in the MIDP 1 0 speci fication MIDP 2 0 introduces an improved domain security model that has been supplied to include signing of applications and verification of certificates In this way the user should be able to verify the MIDlet provider Cryptography support is provided in J2SE through the Java Cryptography Architecture JCA and the Java Cryptography Extension JCE But both are too heavy for the MIDP platform So far there does not exist any solutions to cryptography in J2ME from Sun Solutions still exists like the Bouncy Castle cryptography package Bouncy an open source effort based in Australia Some claim it is a wonderful piece of work featuring a clean API and a formidable toolbox of cryptographic algorithms Knudsen Bouncy Castle offers a lightweight J2ME distribution of their software which other open source cryp tography packages lack There exist security solutions to some of the problem encountered 2 MIDP that does not involve handling the security on application level It is still cryptography but it is han
187. n BSistoreContacts contacts String l boolean Figure 7 16 Detailed view of the ITSClient and the DatabaseClient To further make the ITSClient independent of the network and storage and retrieval of data some ITSSystem specific exception classes are introduced The hierarchy is shown in Figure 7 17 The detailed class diagram can be viewed in Appendix C Exception from java lang lt lt abstract gt gt ITSException F amp T SException BSigetMessage DatabaseException NetworkException Figure 7 17 The exceptions in the ITSSystem 73 The Prototype 7 3 3 State Diagram for the ITSClient Figure 7 18 shows the state diagram for the ITSClient Regular UML syntax is used so square brackets represent conditions and ovals represent states Exit EE Login Setup temario mens lt Join group Delete New Join Private Delete New New Delete Delete Write Message View chat menu Setup New Edit Contact List New Private amp Edit Figure 7 18 State diagram for the ITSClient The state diagram can to a certain degree be translated directly to the screen flow illustrated later in this section but the states concerning communication in private mode is left out From the diagram is seems that it is only possible to receive messages that is
188. n Chapter 2 to 6 are independet of the other chapters while chapter 7 require some knowledge of 72 MIDP which is covered in chapter 3 and JXTA for J2ME covered in chapter 5 The different sections the discussion in Chapter 8 is dependent upon different chapters and these dependencies are summarized in the table below Section of Depends chapter 8 upon chapter 8 1 4 5 8 2 4 4 5 6 8 3 4 5 8 4 4 5 6 2 6 3 8 5 2 3 5 7 8 6 4 5 6 1 8 7 Table 1 1 Dependencies in chapter 8 There are different ways to read this report according to time and interest Each chapter includes a sum mary at the end where the most important points in the chapter are summarized A reader with limited time should concentrate on the abstract the summaries in each chapter and the conclusion For a more in depth understanding of the conclusion a reader can supply the above mentioned parts with the dis cussion in chapter 8 Jini and JXTA in AMIGOS A reader interested in the use of Jini and JXTA in the AMIGOS project should read chapter 4 and chapter 5 and the part of the discussion concerned with AMIGOS If the read er is not familiar with AMIGOS the part concerning AMIGOS in chapter 6 should be included Introduction Jini and JXTA A user interested in Jini and and how they compare to related technologies should concentrate on chapter 4 and chapter 5 in addition to the parts in chapter 6 presentin
189. n without the need for a user to supply the device with this information Unfortunately this is a scenario for the future but this prototype will just as well be a locationbased service In contrast to GPS or similar technology called second generation of locationbased equipment this service will be of first generation This means that the user is responsible for typing in the location to join a suitable group As the service is location based groups basically represents locations but could in practice represent oth er areas of interest In this way the service become a generic service that can be used for much more than the initial thought 62 The Prototype 7 1 2 Realization To use this service the user must log into the service with a username and then decide whether to join a public or private room In a public room the messages will be sent to every member of the group while in the private room there will be an exchange of messages between two persons in the same group The user then selects one of the users in a contact list and sends an instant message to this user The two last figures have illustrated examples of messages which could be sent in a public room Figure 7 3 shows a scenario where it could be favourable to be in touch with other persons travelling the same route and where instant messaging would be the preferable chatting mode Hi Ben can see you are on your Yes and I m way to ready for a break
190. n be retrieved and stored at start up and closure respectively In addition the user should be able to add an existing group to the group list and change between the different groups in his list Groups can also be deleted from a users group list The user should be able to send messages to the group and receive message from the group he is cur rently participating in The total number of messages visible at all time might be set by the user in setup as well as the polling frequency Version 1 1 F 1 Login F 2 Modus of communication F 3 Change mode of communication F 11 View contact list Version 1 1 introduces the second mode of communication the private room The user can choose be tween public and private mode in setup and at any time change mode Public mode is the default mode When entering the private room the user is presented for a list of contacts user in a private room shall also join a group and can only communicate with the contacts participating in the same group the com munication will be supported in version 1 2 Version 1 2 68 The Prototype F 4 Send messages 5 Receive messages user should be able to send and receive messages from users in the contact list while in private mode Version 2 0 F 8 Change group F 11 View contact list F 12 Edit contact list Version 2 0 supports the main functionality of private room in addition to the functionality of public roo
191. n in Figure 3 5 The ap plication is not required to know about what sort of network it is using even though it might take advan tages of such knowledge to optimise transmission Non IP transport for example TL PDC P or WSP Figure 3 5 HTTP Network Connection JCP 37 The interface HttpConnection provides the additional functionality to request headers parse response headers and perform other HTTP specific functions Each device implementing the MIDP must sup port opening connections using the http URL scheme defined by 2616 RFC2616 This includes the full specification of RFC2616 HEAD GET and POST requests and the absolute forms of URLs 18 Network capabilities in 2 Using makes the device able to call Internet services that are based on the HTTP programming model such as CGI script PHP and Servlets as shown in Figure 3 6 Internet Request Response Mobile HTTP Server Client Figure 3 6 Mobile Client using HTTP to connect to Internet Services It is up to those implementing the MIDP to support other protocols The only requirement is that the protocol should use the Generic Connection framework An example is Motorola s Accompli 008 that provides support for Sockets 008 3 2 3 Protocol support in the future next version of MIDP will introduce several new types of connection for mobile devices but not all are mandatory yet Some will remain optional
192. n the network In Jini a host capable machine must be set up specific as a surrogate host for a device or a number of devices solves the availability issue by making each rendezvous peer able to be a relay for embed ded devices 8 2 2 Similarities Despite the differences the two architectures for embedded devices share some common properties Objective Network independence Dependence upon a relay The objective of Jini and JXTA is to support access to services from any device and the Jini surrogate ar chitecture and JXTA for J2ME extends the area of availability of the technology As a result they fulfil the goals of both Jini and JXTA Network independence is a central goal both in Jini and JXTA even if dependencies is introduced in the im plementations of the specification Jini Surrogate Architecture does not specify how the devices intercon nect with the surrogate host This is left to different interconnect specifications as for example the IPInterconnect WirlessDevice Project Bluetooth interconnect for JZME aims at supporting different interconnect protocols when they are available as the lowest common denominator As of today this is HTTP but the packages are built to make a change to other protocols easy as long as the new protocols are supported in the Generic Connection Framework The architectures are both dependent upon a relay to act on the devices itself The Jini surrogate host and th
193. nature is like an integritycheck function except it is produced by a particular person the signer The scheme consists of a signature algorithm and a verification algo rithm To create the signature the signer must have a private key while a corresponding public key can be used by anyone to verify that the signature came from the signer Certificates are really just an extension of digital signatures which is a document signed by some authority that proves your identity It s like a driver s license except it is based on digital signatures Examples of digital signa tures scheme are El Gamal Signatures Digital Signature Algorithm DSA and the RSA algorithm Encryption algorithms Chipers An encryption algorithm can be used to enctypt or decrypt data Encryption means to make an unreadable mess of the supplied data called cipher text The cipher text can be decrypted back to the plaintext provided in the first place This requires use of keys Using keys the cipher text will be different for each key In symmetric algorithms the same key is used for encryption and decryption while in asymmetric algorithms also called public key algorithms different keys are used for encryption and decryption Chipers can operate in different modes that determine how plaintext is encrypted into cipher text This affects the use and security of the cipher Examples of chipers are Data Encryption Standard DES which is symmetric and RSA encryption that is asy
194. nd applications that suites their needs JXTA 5 2 1 The platform layer The platform layer is also known as JXTA core layer and provides the absolutely essential elements to evety P2P solution The elements of the core layer are listed below and ate ideally shared by all P2P so lutions Peers Peer Groups Network Transport Pipes Endpoints Messages Advertisements Entity Naming Identifiers Secutity and Authentication Primitives Protocols discovery communication monitoring The first six elements is discussed in section 5 3 while the protocols are covered in section 5 4 Note that six main protocols are implemented as services but located in the Platform Layer and designated as core services to distinguish them from the service solutions of the Service layer core layer is the fundamental core of the JXTA solution and all other aspects of a JXTA P2P solution in the Service ot Applications layer build on this layer to provide functionality peers create a virtual network where peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and or are on different network transports Communication across a firewall or NAT Network Address Translation is solved in two ways in the reference implementation Either at least one peer in the peer group inside the firewall must be aware of at least one peer outs
195. ng Using Sockets and RMI from MIDP enabled Devices January 2002 http wireless java sun com midp articles socketRMI 124 Reference Library RFC2396 RFC2543 RFC2616 SETT SFrame02 SIMPLE SIP SIPPING SkaKau SOAP Spotless Sun SWaba telecom01 TLS Topley UDDI Vasu W3Cws Waba RFC2396 Uniform Resource Indicator URI Generic Syntax online http www ietforg rfc rfc2396 txt SIP Session Initiation Protocol online http www ietf org internet drafts draft ietf sip rfc2543bis 09 txt RFC2616 Hypertext Transfer Protocol 1 1 online http www w3 org Protocols rfc2616 rfc2616 html SETI Home online http setiathome berkeley edu Breck Rolv Husa Knut Eilif Melby Geir ServiceFrame Whitepaper draft Ericsson May 2002 SIP for Instant Messaging and Presence Leveraging Extensions SIMPLE Includes 4 inter net drafts online http www ietf org ids by wg simple html Session Initiation Protocol SIP Includes 25 internet drafts online http www ietf org ids by wg sip html Session Initiation Proposal Investigation SIPPING Includes 12 internet drafts online http www ietf org ids by wg sipping html Skaflestad Odd Arild Kaurel Nina Peer to Peer Networking Configuration Issues and Distributed Processing Arcticle written in realtion to subject SHE50AC Autumn 2001 Simple Object Access protocol SO
196. ng in public mode Follows the result as for T 2 1 2 5 Click the EXIT button The application closes OK T 2 6 Choose public mode as the communi The application will be started for OK cation mode public mode communication Follows the same result as T 2 1 T 2 7 Choose private mode as the commu The application will be started for NOK nication mode vate mode communication Follows the same result as for T 2 1 T 2 8 Change the polling frequency to or An error message is displayed and the OK an empty string user will return to the setup screen T 2 9 Change the value of number of mes An error message is displayed and the OK sages to 0 or an empty string user will return to the setup screen T 2 10 Supply non valid IP address in the error message is displayed and the NT relay field or a port number that is user will return to the setup screen smaller or equal to 1024 Table 7 3 Test specification and result for setup In the setup the user gets the possibility to edit the communication mode relay host and port number of messages to view in public mode and the poll frequency Version 1 0 of the system does not support the possibility to private communication but Private is anyway shown as a choice If the user selects Private an error message will appear Setting the relay host and port is no supported in this version so changes t
197. nlikely that two systems will inter operate Further offers ubiquity It is designed to be implemented any device with a digital heartbeat including sensors consumer electronics PDAs appliances network routers desktop computers data centre servers and storage systems Designers of P2P often seek profit as fast as possible by targeting the largest installed base of consumers and in doing so choosing Microsoft Windows as target platform A result might be that many dependencies on Wintel specific Windows Intel features are designed into the system As it is very likely that other devices and systems will have great profit of P2P technology betting on any particular segment of hardware or software system is not future proof JXTA has several advantages and limitations some were found under the study of JXTA others were pointed out in Wilson The advantages are Seeks to provide a standard way to communicate in network Provides a far more abstract language for peer communication than previous specialized pro tocols enabling a wider variety of service devices and network transports to be used in P2P net works JXTA does not dictate any particular programming language or environment Extensible Markup Language XML or binary representation of data is used to exchange mes sages both understood by a majority of the platforms currently available XML provides a stand ards based format for s
198. nline http www openp2p com pub a p2p 2002 01 08 p2p_topologies_pt2 html Napster online http www napster com Microsoft INET site online http msdn microsoft com library default asp url nhp Default asp conten tid 28000519 Frequently Asked Questions About the Microsoft NET Compact Framework online http msdn microsoft com vstudio device compactfaq asp The NET Compact Framwork Overview online http msdn microsoft com vstudio device compactfx asp Microsoft INET Frequently Asked Questions FAQ online http msdn microsoft com library default asp URL library techart faq111700 htm Microsoft NET Framework Technical Overview online http www gotdotnet com team framework Dot Net 20Framework 20Technical 200verview 20v3 doc Microsoft Visual JE Beta 2 online http msdn microsoft com visualj jsharp beta asp and Java online http www gotdotnet com team java Framework Product Overview online http msdn microsoft com netframework prodinfo overview asp Program for Advanced Telecom Services PATS online http www item ntnu no avantel pats html PersonalJava online http java sun com products personaljava Png library from sixlegs com online http www sixlegs com softwate png PsiNaptic online http www psinaptic com Claymore Systems the developer of Pure TLS online http www claymoresystems com Mahmoud Qusay Advanced MIDP Networking Accessi
199. nt on transfer protocol which can change without affecting the client Join is the action of a service placing an object representing its capabilities into the lookup service for oth er clients and services to find and use The discovery join and service usage is shown in Figure 4 3 The small dark boxes is the proxy that rep resents the Service and the dotted line shown how a service first is places with the lookup service and 32 Jini Network Technology then downloaded to the client Communication between the proxy and service is shown as a solid drawn line Jini uses Java s Remote Method Invocation RMI facility for all interactions between either a client or a service and the lookup server after the initial discovery of the lookup server The reason to use RMI is that the technology is able to pass entire Java objects and their code and works in any compliant Java virtual ma chine RMI also provides automatic serialization transport and deserialization of objects and have to bust and configurable security like RMI over SSL and authenticated principal Jini security component 18 based the Java s security model Kumaran This model provides features like dig ital certificates encryption and control over mobile code activities such as opening and accepting socket connections reading and writing to specific files and using native methods Jini services use these secu rity models while Jini uses the two security aspe
200. nveying of quality of service information e A protocol that provides multiplexing and transport protocol and is based the ETSI standard 07 10 Itis the cable replacement protocol included in Bluetooth meaning that it has support for serial cable emulation and other cable emulations SDP Service Discovery Protocol Defines a protocol for locate services provided by or available through Bluetooth devices and to determine the characteristics of those available services OBEX Object EXchange The purpose of the OBEX protocol is to enable exchange of data objects Typical example could be an object push of business cards to someone else The profiles included in the JZME implementation of Bluetooth are listed below Generic Access Profile GAP Defines the generic procedures related to discovery of Bluetooth devices and link management aspects of connecting to Bluetooth devices It also defines proce dures related to use of different security levels In addition this profile includes common format requirements for parameters accessible on the user interface level Service Discovery Application Profile SDAP Defines the protocols and procedures to dis cover services registered in other Bluetooth devices and retrieve any desired available information relevant Serial Port Profile SPP Defines the requirements for Bluetooth devices necessary for setting up emulated serial cable connections using RFCOMM between tw
201. o bile entertainment navigation systems CLDC targets personal mobile connected information devices like cell phones pagers and per sonal organizers These devices have very simple user interfaces minimum memory budget start ing at about 128 kilobytes low bandwidth and intermittent network connections where the network often is not based on the TCP IP protocol suite java util javaio javax microedition Figure 3 2 Relationship between J2ME configurations and Java 2 Standard Edition One of the keys to get Java running on small devices is to reduce the size of the runtime classes installed with the runtime environment 2 was designed from scratch with focus on compatibility with the 14 Network capabilities in 2 other Java platforms Compared to these J2ME does only include the most classes and repre sents a subset of the J2SE runtime classes By definition all J2ME configurations must adhere to a nested relationship In other words the CLDC fits completely inside the CDC There are no classes methods ot other functionality in the CLDC that are not also in the CDC This relationship and the relationship to Java 2 Standard Edition is shown in Figure 3 2 The Profile Layer defines the minimum set of Application Programming Interfaces API available on a particular family of devices i e a specific vertical market like mobile phones and PDAs It is typical that
202. o become mobile devices and this mobility results in a change from hard wired network connection to wireless connection The new embedded devices that are highly mobile creates a demand for network technologies that makes it able to have access to services anywhere at any time and on any device An client server architecture is not the best solution is such highly mobile and heterogeneous environment neither is the older dis tributed network technologies like CORBA and DCOM A more suitable solution is to use new distrib uted peer to peer network technologies with its independence on infrastructure and able to handle a highly mobile environment where nodes come and goes with no further notice The challenge is to make these technologies work with the application environment on the devices Java 2 Micro Edition J2ME the new Java programming environment for embedded devices has several capabilities when it comes to network connections Concentrating on the Connected Limited Device Configuration CLDC and Mobile Information Device Configuration MIDP these specifications pro vide network connection through the Generic Connection Framework defined in CLDC MIDP only im plements the HTTP1 1 protocol and the only possibilitiy to use more advanced network protocols are by use of a middleman or relay The relay can act on the MIDP device s behalf and can provide access to for example CORBA and DCOM or to the new peer to peer network techno
203. o peer devices Generic Object Exchange Profile GOEP Defines the requirements for Bluetooth devices necessary for the support of the object exchange usage model 2 6 Security security in MIDP is limited and as a result MIDlets is a potential threat to users Some improve ments will come with the next version of MIDP and these will further limit the risk But other risks still exists not so much on the mobile device itself but in communication with entities on a network Even though MIDlets have great opportunities when it comes to networking a lot of applications will not be possible without some form of data security Any information transmitted over wireless links is subject to interception Some of that information could be sensitive such as credit card numbers and 25 Network capabilities in 2 other personal information The solution needed depends the level of sensitivity To provide com plete end to end security solution you must implement it on both ends the client and the server and assure yourself that intermediary systems are secure as well One solution to consider when handling highly sensitive information is encryption the sender encrypts the data before transmitting it over the wireless link the authorized receiver receives the encrypted data and decrypts it using a key provided This section first considers the limitations of the current version of MIDP and which improvements that are
204. o these fields will not be handled In other words the default values for relay and port is used upon connecting to the network If a user enters the setup while still member of a group he will not leave the group as long as relay address and port is unchanged In the current version this is not implemented so the user never leaves the group he is member of Group overview Testing the group overview requires the user to start the application and log in with or without changes to the setup This will bring the user to a screen showing the different groups in the database if any exists The test cases presented here all have starting point from this screen and all tests must be completed independent of the others The test cases and results are presented in Table 7 4 The Prototype No Test case Desired result Result T 3 1 Select a group in the list when in pub If no groups are available this choice OK lic mode will not be possible Otherwise the user joins the selected group and the screen for public communication appears T 3 2 Select a group in the list when in pri If no groups are visible this choice NT vate mode will not be possible Otherwise the user joins the selected group and the user will be presented with a list of his contacts if any T 3 3 View the group overview screen with No groups listed and the OK but OK no groups present ton is not visible T 3 4 Click the MENU button
205. ocol The Pipe Binding Protocol PBP allow a peer to establish a virtual communication channel or pipe be tween one or more peers by binding two or more pipe ends of the connection input and output pipe to a physical peer endpoint PBP is used by the peer to create a new pipe bind to an existing pipe and unbind from a pipe at runtime and use PRP for sending and propagating pipe binding requests 5 4 5 Endpoint Routing Protocol A peer uses the Endpoint Routing Protocol ERP to discovery a route for a message to a destination peer Two peers might not be directly connected to each other as a result of different network transport protocols or separation by firewall or NATs ERP is used to determine the routing information by asking peer routers for available routes The peer itself becomes a peer router by implementing the Endpoint Routing Protocol Endpoint Routing Protocol is also known under the name Peer Endpoint Protocol PEP 5 4 6 Rendezvous Protocol The Rendezvous Protocol RVP allows a peer to subscribe or be a subscriber to a propagation service In a peer group peers can be rendezvous peers or peers listening to rendezvous peers The allows messages to be sent to all of the listeners of the service In order to propagate messages the RVP uses the PRP An earlier version of this protocol is called Peer Membership Protocol PMP and is a more specialized protocol intended for manage group membership for example sub
206. of AMIGOS than Jini prob lem with Jini could be authentication of the user since Jini has no mechanism to suppott this The plat form and programming independence in JXTA will make AMIGOS available for all devices JXT also has the mechanisms to divide the envitonment in several smaller environments peer groups which will suite the Meeting Place scenario presented in AMIGOS Today devices that form ad hoc network and communicate peer to peer is just an area of research De vices have the potential but neither ad hoc and peer to peer technologies nor programming environ ment for embedded devices are fully developed In addition the smallest one lack the necessary resources to be able to participate Embedded devices need a killer application to make people see the potential and usage area of them and until the time where all these factors are present we must be content with what is available 114 Chapter 10 Abbreviations AMIGOS API AVANTEL CA CDC CLDC CLR CTS DES DNS DSA ERP FTP GAP GOEP GPRS GSM HTTP HTTPS IEEE 5 Advanced Multimedia In Group Organised Services Application Programming Interface Advanced Telecom Services Certificate Authority Connected Device Configuration Connected Limited Device Configuration Common Language Runtime Common Type System Data Encryption Standard Domain Name Server Digital Signature Algorithm Endpoint Routing Protocol File Tr
207. of hardware and software The network technology is an open architecture that enables developers to create network centric serv ices that are highly adaptive to change Jini technology can be used to build adaptive networks that are scalable evolvable and flexible as typically required in dynamic computing environments Jini network technology has several advantages and limitations some were found during the study of the technology others were pointed out in Jini The advantages are 29 Jini Network Technology Jini provides an environment for creating and managing dynamically networked components applications and services that scale from the device to the larger enterprises The technology is based upon mobile code i e it moves data and executables via a Java object between entities and so extends the Java programming model to the network and ensures a homo geneous environment No user interaction or configuration is required to allow devices on a network to bring services on off line Enables network self healing and services can dynamically join and exit with no impact on the net wotk or the network users i e the community adapts to changes Consumers of Jini services do not need prior knowledge of the service implementation to be able to use the service Jini is a protocol independent distributed computing architecture The proxies can interact with its home service using any distributed protocol fo
208. ommunication systems or devices to communicate with each other SIP prima rily addresses the call setup and tear down mechanisms of sessions and is independent of the transmission of media streams between caller and callee Several extensions to SIP are proposed like SIMPLE SIM PLE an extension of SIP to support presence and instant messaging The specification is the responsi bility of the SIMPLE IETF working group The purpose of the SIP API for J2ME JSR 180 specification is to enable SIP applications to be executed memory limited terminals especially targeting mobile phones The specification was proposed by Nokia Corporation and accepted in April 2002 and scheduled to be finished the second quarter of 2003 It will not make any assumptions on the standard and application used and will be based on the SIP spec ification in the RFC2543 RFC2543 and potential extensions required by IETF SIMPLE and SIPPING SIPPING work It will also take 3GPP requirements 3GPPsip into account The specification is made possible by the introduction of TCP and UDP support in MIDP 2 0 Other requirement that must be included in MIDP is a more rigid security model since the specification will base its work on the MIDP security model and the Generic Connection Framework defined in CLDC The target is to provide one API and prevent that there will become several different SIP APIs in the MIDP devices using TCP or UDP 1 SIP for Instant Messag
209. omplete J2ME application runtime environment targeted at mobile information devices MIDs like mobile phones The main goal of the MIDP expert group was to establish an open third party application development environment for MIDs The memory and net work requirements of a MIDP device ate 128 kilobytes of non volatile memory 8 kilobytes of non volatile memory for persistent data created by the applications 32 kilobytes of volatile memory for the Java runtime that is to say the Java heap The device should support two way wireless networking with limited bandwidth achieve broad portability the MIDP considers absolute requirements i e no optional require ments which are Applications i e defining the semantics of a MIDP application and how it is controlled User interface or UI includes display and input Persistent storage Networking HTTP 1 1 Timers MIPD introduces a new application model which omits the constraints of having one unique launch point It introduces a state machine where the application can be in one of the three states active paused and destroyed and transit between the states The central goal of this application model is to provide support for controlled sharing of data and resources between multiple possibly simultaneously running MIDlets which is the basic unit of execution in MIDP MIDlets can be packaged as Java Archive JAR file either as a single application or as
210. on IEEE Internet Computing September October 2000 EmbeddedJava Application Environment online http java sun com products embeddedjava Frodigh Magnus Johansson Per Larsson Peter Wireless ad hoc networking The art of networking without a network Ericsson Review No 4 2000 online http www ericsson com about publications review 2000_04 article124 shtml Forte for Java online http wwws sun com software Developer products ffj Frisk Charlotte Broberg Ronny Web Services in Telenor Master thesis at Department of Telematics NTNU June 2002 GNU public license online http www fsf org copyleft gpl html Gnutella online http www gnutella com Gollmann Dieter Computer Security John Wiley amp sons 1999 Gong Li Project JXTA A Technology Overview online http www jxta org project www docs TechOverview pdf Graham Ross Lee Intelligent Information Systems LAB Link pings university online http www ida liu se conferences p2p p2p2001 hybrid html Gupta Vipul Bringing Big Security fo Small Devices 2001 JavaOne presentation http playground sun com veupta KSSL 2246gupta pdf WebSphere online http www embedded oti com wdd IBM s WebSphere platforms supported online http www embedded oti com compat Institute of Electrical and Electronics Engineers Inc online http www ieee org Insignia online http www insignia com Compaq iPaq online http
211. on propose several scenarios on how they can be used in the AMIGOS project before moving on to some future scenarios 8 1 Comparing Jini and X This section will first provide an overview over the main similarities and differences of Jini and JXTA and then point out the advantages of each technology taken that Java is already chosen as programming language 8 1 1 Differences Jini Network Technology and JXTA have a lot in common but they were designed with different as sumptions The difference between Jini and can be summarized in respect to three areas The platform required Communication Location of services The main different between Jini and JXTA is in the required platform Jini assumes the present of Java the network while have no assumption when it comes to programming language Jini requires Java to publish setvices If a device does not suppott Java a special proxy service Java 1s necessaty and the developer will have to implement the bridge The reference implementation of Jini is also dependent upon TCP IP as transport protocol JXTA is language independent and platform independent since it is entirely protocol based thereby allowing endpoints to be implemented in a variety of ways The JXTA 95 Discussion reference implementation is in Java but JXTA is currently being developed C Perl Smalltalk and Py thon Communication is achieved differently for Jini and
212. onathan Wireless Java Developing with Java 2 Micro Edition June 2001 Krishnan Navaneeth The Jxta solution to P2P online http www javaworld com javaworld jw 10 2001 jw 1019 jxta p html The RSOAP project SOAP for J2ME online http www ksoap org Topley Kim 2 in a Nutshell O Reilly March 2002 Kumaran 5 Jini Technology An Overview Prentice Hall Inc 2002 The RXML project online http www kxml org Lyngstad Bjorg Java on Mobile Devices Project Assignment Norwegian University of Science and Technology Faculty of Electrical Engineering and Telecommunications Department of Telematics ITEM Autumn 2001 Qusay H Mahmoud Nicholas Lorain Wireless Software Design Techniques online http wireless java sun com midp articles uidesign Mahmoud Qusay Wireless Java Security online http wireless java sun com midp articles security Micro Edition for Standard Edition me4se online http me4se org 123 Reference Library MIDP1 0 MIDP2 0 Minar Napster NET NET cfaq NETcomp NET faq NET fto NETJ NETJava NETov Pats PJava Pnglib PsiNaptic Pure TLS Qusay Mobile Information Device Profile 1 0 online http java sun com products midp JSR 118 Mobile Information Device Profile 2 0 online http jcp org jsr detail 118 jsp Minar Nelson Distributed Systems Topologies Part 2 o
213. onent service components are the entities that come together to form the Jini community and are based upon the infrastructure component and use the programming model component Example of services is the lookup service the JavaSpace service and the transaction service Jini Surrogate Architecture makes resource constrained and non java enabled device able to participate in the Jini community A client can download a surrogate object to a surrogate host The surrogate object represents the client on the Jini network and the surrogate host acts on behalf of the client As part of the surrogate architecture there is defined several interconnect protocols for different transport proto cols that connect a client with the surrogate host 38 Chapter 5 JXTA Putting things next to each other which is really what peer to peer is about having groups of things come into affiliation into juxtaposition for a while and then move on Bill Joy short for Juxtapose as in side by side is an open source project that defines a set of protocols for ad hoc pervasive peer to peer computing It started as a research project called Juxtapose at Sun Mi crosystem Sun in the summer of 2000 led by Chief Scientist Bill Joy In April 2001 the project contin ued development in an open source community the JXTA community where everyone who wishes may contribute to the further development strives to provid
214. onent Figure 4 1 shows the relationship between the three components of Jini and some of the subcompo nents Notice that the infrastructure component and the service component both uses the programming model component and that the Lookup Service is part of both the Infrastructure component and the Services 30 Jini Network Technology Programming model Services Jini services Lookup service Infrastructure uonoersuely uoneorrnou JUMAA Discovery join and security Java technology Java virtual machine Operating system Network transport Figure 4 1 Jini component overview Jini extends the java platform as shown in Figure 4 2 The technology assumes that java is always present on the network either in the services themselves or as a java wrapper In other words Jini requires that each device either run a Java virtual machine JVM or associates itself with a device that can execute a JVM on its behalf This assumption is made since services are identified by Java type and proxies may need code to download Service implementations that are non java can wrap the legacy language in Java and make calls to legacy with Java Native Interface JNI Remote Method Invocation RMI is fundamental to the reference implementation of Jini but the fea tures provided by Jini should be available independent of this package For example PsiNaptic PsiNap tic a communication technology company has implemented a version of
215. onnectin to the server before sending packages i e communication is connectionless meaning that there is no established channel between the sender and receiver All datagram transmissions are considered successful and so datagram allows data to be sent regardless of whether the server the message is intend ed to even exists Thus the connection is consideres unreliable since a packet that gets lost is not resent automatically by the protocol implementation The result is that there is no guarantee that the packets will arrive in the same order they were sent if at all and the protocol does not provide support for reas sembling data packets in right order This in contrast to sockets where the communication is connection otiented meaning that the connection is set up at initialization and all packets are reassembled and re transmitted if necessary If a server does not support sockets or is not listening for socket connections an exception will be thrown As a result data sent using sockets is considered reliable Features of han dling the unreliable nature of datagram might be implemented by the application itself One primary advantage of using datagrams is the speed Datagram has no overhead of ensuring that packets arrive in the correct order or that they arrive at all For some applications the speed is more im portant than the data integrity such as audio streaming or video streaming where a missing data packet may appear as static Although
216. ook up setvice e g DNS in Internet The most peer to peer like solution is displayed in model 2 in Figure 2 3 In this scenario the router does not forward messages as a router in the traditional sense but contains an address resolution table to assist peers in finding fellow peers All communication is between the two peers not through the central server and so the server is downgraded to a simple lookup service As a result of this congestion problems are avoided through the relatively small amount of processing when performing lookup possibility is to distribute this address resolution table into a distributed catalogue and hence be able to define the system as pure peet to peer protocol The reoccurring problem will how ever be how to gather the sufficient pre knowledge to register and communicate with other peers and Background at the same time be guaranteed reliable communications Model 1 Peer 1 Be 1 Request Router 7 2 Address Figure 2 3 Routers in Hybrid Peer to Peer networks system combining centralized and decentralized elements enjoys some of the advantages of both Ex tensibility and fault tolerance is the contribution from decentralization while the centralisation contrib ute with more coherence than a purely distributed system since there are fewer hosts that are holding authoritative data Security and manageability is as difficult as in decentralized systems
217. op view write the name If the contact not already exist in the NT of the new contact contact list it will be added to the contact list and a search for the con tact is started If the contact exist show an error message T 7 6 Do not write a name for the contact No group is added An error message NT empty string and click OK is displayed to the user and the user returns to the add contact screen T 7 7 Click CANCEL in the add new con No group is added The user is redi NT tact screen rected to the menu screen T 7 8 Select DELETE in the menu and The contact will be deleted from the NT then choose one of the contact in the list and the user will be redirected to list that is displayed the contact list editing screen T 7 9 Click the CANCEL button in the The selected group is not deleted and NT delete contact screen and click OK the user is redirected to the contact list menu screen T 7 10 Delete all contacts and view the delete No groups are listed and the OK but NT contacts screen ton is not shown Table 7 9 Test specification and result for contact editing private mode 7 6 4 User test tasks Another important part of the testing is the user test This involves inviting a number of potential users to try out the program and valuate the user interface and the user friendliness Nine persons were invited to be testers for the program four male and five female Three of the persons had no
218. oper must program both the surrogate and the device to communicate with the surrogate which are two different packages The relay in XTA is part of the JXTA network and operate using the binary version of the JXTA protocols making the developer able to concentrate on small and simple API at the device Availability of implementation There is available a reference implementation for Jini Surrogate Architecture and an IPInterconnect reference implementation JXTA for J2ME is implementa tion and is available with minor shortcomings in the relay like lack of search capability Transport protocol dependence The available implementations in relation to Jini Surrogate Architecture makes the devices dependent upon IP which might not be implemented by all J2ME 99 Discussion enabled devices for J2ME is dependent upon HTTP which is the only protocol supported in the smallest profile MIDP Security Both Jini Surrogate Architecture implementation and JXTA for J2ME rely on the secu rity already present in the devices In addition the relays are covered by the security mechanisms in the respective network technologies 8 3 Interoperability between Jini and X TA Interoperability is the ability of software and hardware on multiple machines from multiple vendors to communicate This can be achieved in different ways as visualized in Figure 8 1 4 Figure 8 1 Interoperability between two technologies A and B
219. or can connect directly to another user using ITSSystem This other user is called the terminatot The peer group This is an abstraction of all possible users in the ITSSystem environment When peer group is used in the use case diagrams it signalizes that all users are involved to fulfil a requirement 7 2 1 Functional Requirements This section described the requirements that are made to the functionality of the prototype application The functional requirements will be described by text and illustrated in UML use case diagrams Each functional requirement is assigned an identity in the format F lt number gt where number is se quential number 63 The Prototype F 1 Login User shall be authenticated prior to service usage The user is required to log on to the service at start up The login includes an authentication of the user based on username F 2 Modus of communication The user can choose whether to be in the public mode of communication where messages ate received and sent to the whole group or in private mode where the messages are exchanged between two users patticipating in the same group The user select between the two modus before joining a group F 3 Change mode of communication When the user is connected to a group the user shall be able to change the communication mode from public to private or the other way around Figure 7 4 shows the use case diagram for F 1 F 2 and F 3 Authen
220. or mote servers in the netwotk that acts as telays on behalf of the mobile device This sort of architecture middleman architecture is described in the next section The hope for the future is to enable direct connection from one mobile device to all other mobile device independent of infrastructure like today s GSM network This scenario will be cov ered in detail in later chapters 3 4 Middleman Architecture To overcome the network capability limitations of CLDC and MIDP a so called middleman architecture ot relay architecture might be used This architecture is shown in Figure 3 11 and discussed in Qusay and is used to enable the mobile device applications to use other network technologies than HTTP CLDC and MIDP have no support for socket or datagram connection In addition the K Virtual Ma chine does not support all the features of the Java language and the virtual machine both because they are too expensive to implement and their presence would impose security issues As a result there is no support for object serialization and consequently there is no support for Remote Method Invoca tion RMJ either Mobile Client i Sockets MIDlet Figure 3 11 Middleman Architecture Figure 3 11 shows how a MIDlet connects to a Servlet using HTTP The Servlet can then connect to setvices using sockets CORBA RMI or other java technologies To access other services both CGI scripts and PHP might be us
221. orces code robustness by implementing a strict type and code verification infrastructure called the Common Type System CTS In addition it has a role at development time with features such as lifetime management strong type naming cross language exception handling and dynamic binding This reduces the amount of code a developer must write to turn business logic into a reusable component NETfto NETfaq The Common Language Runtime 1s displayed as the lowest layer in Figure 6 4 XML Web Web Services Forms Windows Forms ASP NET SS Se Data and XML Classes Base Framework Classes Figure 6 4 Microsoft Framework The NET Framework class library is a comprehensive object oriented collection of reusable types that you can use to develop applications for example by usage of ASP NET The library consists of five class li braries as visualized in the upper three layers of Figure 6 4 Base Framework Classes Data Classes XML Classes XML Web Services Web Forms Windows Forms The Base Framework classes provide standard functionality such as input output string manipulation se curity management network communication thread management text management and other similar functions Data classes support persistent data management and include SQL classes for manipulating per sistent data stores through a standard SQL interface while the XML casses enable XML data manipula tion and XML searching and tr
222. ore lt lt 5 gt gt instance DatabaseClient ESiDatabaseClient DSi static getInstance DatabaseClient BSigetUserName String etGroups String Bonn String toreGroups groups String boolean BSistoreContacts contacts String Boolean Figure C 7 Detailed class diagram for DatabaseClient C 3 Sequence diagrams Chapter 7 provided some of the sequence diagrams of the prototype The rest are presented here with some additional information and a more in detailed view The diagrams will not be explained further since this is already done with the corresponding collaboration diagrams same goes for the collaboration diagrams presented in C 4 Figure C 8 is the corresponding sequence diagram to the collaboration dia gram in Figure 7 21 SClient PeerNetwork Network Client joinGroup String String connected leaveGroup connected close java lang String java lang String java lang String isten String String String JE poll int Message noE m pty Msg receiveM essa TS Message a Figure C 8 Sequence diagram for joining an existing group Figure C 9 represents the sequence diagram to the equivalent collaboration diagram in Figure 7 22 Appendix C ITS System UML diagrams and comments client database netwo rkClient ITS Client DatabaseClient NetworkClient getGroups
223. ormation about the area they are travelling in This might be information about a new road detours because of traffic accidents or roadwotk or simply to get explanation about the way if a map is out of reach Some solutions already exist like radio programs dedicated to travelling people informing about things to pay attention to when driving These programs are most widespread and useful in big cities and the information might be useless if you are not in the specific area where the information is relevant The same is the case when a driver is on a long distance trip and listens to a radio program passing on travel ling information for drivers in the whole country Other drawbacks are that these radio programs ate gen erally only broadcasted during holidays or in rush hours 61 The Prototype The Intelligent Traffic Service ITS system aims to solve these problems A client running the service should be available for downloading to the users mobile device over the air and installed with little or no interaction from the user The terminal must support J2ME CLDC MIDP Figure 7 1 illustrates a situ ation where this service could be useful for other travellers long queue in Gliese KE Gee gl Warning about Figure 7 1 A user informing other users about queue in an area 7 1 1 Service Specification The idea of this service is to let travelling people communicate with other in the same area or with th
224. ototype is based upon instant messaging Instant messaging is a well known way to communicate with other people on the Internet Because of the many ways to realize such communication many is trying to standardize how instant messaging is implemented so as to ensure compatibility between different implementation The standardization effort is presented in Appendix F This chapter will go through all the phases of the development process from analysis and requirements specification to design implementation and test The modelling language used is the Unified Modelling Language UML Analysis is done through service specification including user needs and scenarios and 1s the basis for the requirement specification Use case diagrams accompany the requirements specifica tion by visualize the functional requirements and their dependencies Class diagrams sequence diagrams and collaboration diagrams are used in the design phase Next it will explain some of the implementation solutions and suggest alternative solutions for some cases before turning to the test specification and related results The prototype is an Intelligent Traffic Service ITS system as suggested by professor Do Van Thanh at Department of Telematics ITEM at NTNU It was developed using the Java Wireless Toolkit WT J2MEwtk from Sun and tested on the included emulators 7 1 System overview People travelling with cars or other vehicles may be interested in getting inf
225. oups involves call to the searchForGroups method of NetworkClient which asynchronously returns an ITSMessage with groupName and groupld 2 edit edit List gt 1 getGroups client i database ITSClient DatabaseClient 4 receive essage TSMessage add searchForGroup tring int network NetworkClient Figure 7 22 Collaboration diagram for viewing and editing a group list Adding a group to a contact list may involve a number of steps When the ITSClient calls network search ForGroups groupName typeOfSearch the NetworkClient must first check whether the group already exists or not The sequence of adding an existing group is shown in Figure 7 23 76 The Prototype ITSClient PeerNetwork NetworkClient searchForGroup String int gt search String String poll int gt Message groupExist receiveMessage IT SMessage Figure 7 23 Sequence diagram for adding an existing group When a user wants to add a group to the group list he will supply a group name and indicate whether the group must have the exact same name or similar name of the supplied group name The Network Client will then initiate a search to find the id to the group or similar groups When searching for similar groups the resulting groups are adde
226. ources that exceeds the resources of em bedded devices An implementation for CDC is also under development and according to one of the project owners it runs fine with Personal Profile Current implementations of the J2ME platform specifically CLDC 1 0 and MIDP 1 0 have several con straints and to provide true peer to peer communication a relay is needed MIDP 1 0 does have limited libraries lack of an XML parser support for outgoing only and no security support These limi tations are reflected in the JXT A for J2ME s capabilities As a result JXME is implemented using HTTP transport For messages JXME uses binary messages that conform to JXTA s Binary Message Format and security is not supported Other features than security that are unsupported are relay setvice router service and rendezvous service These features will be supported when cell phones mature and have better support for them and MIDP have available libraries to support them intention for the future is to provide for true peer to peer communication without the need of a relay MIDP 2 0 will provide for such an opportunity since it includes further network protocol support As of today to accomplish the goals while considering the constraints in using 2 a relay server is needed to perform some of the work In addition this relay will make JXTA available for devices behind a NAT JXME is therefore split in to modules a Peer and a Relay Service
227. ption D4 Setup You can edit the default setup values by selecting Setup in one of the menus or by choosing to edit the setup in the login screen In this version of ITSSystem there are two values that can be set in the setup The polling frequency and the number of messages viewed in the public com munication screen The polling frequency decides how often to ask for messag es from the network As default the poll frequency is set to 10 seconds If you are planning to have an ongoing chat you may want to set this field to a lower value On the other hand if you don t need to get messages very often and are not planning to send too many messages either you can spare the network for much traffic and your self for much money if you set it to a higher value The number of messages is set to three as default T ED elp for setup Poll frequency sets ov often to check new messages SAVE will change the setup and you will return to the previous screen if you entered setup from one of the menus otherwise you will get the group list screen If you click HELP the screen to the left will appear This screen will give you information about the fields in the setup and you can return to the setup by clicking BACK Appendix D ITSSystem User Manual D 5 Alert messages If something goes wrong or you fill in invalid values an error message like the one to the left will appear This will be viewed for some
228. r Today this is left to the community to decide on which ap plications will succeed and which will fail As Li Gong said in Comp2001 JXTA s version 1 0 is more a starting point for the developer community than a finished product 8 7 3 The existence of an optimal solution Distributed network technologies will continue to be discussed and compared argumenting that one of them is THE solution But none are THE solution to every problem they are all just tools and all have their place The challenge is to choose the one that make sense for the problem at hand 112 Chapter 9 Conclusion My interest is in the future because I am going to spend the rest of my life there Charles F Kettering Embedded devices has gained great success the last couple of years and their real value will become vis ible when network capabilities are introduced As these devices have limited capabilities and are highly mobile the network environment are required to handle these challenges The most suitable network ar chitecture is a distributed one that follows the peer to peer paradigm since these architectures can handle that clients come and go with no further notice Peer to peer architectures are concerned with independ ent of infrastructure at the application layer and handle everything from discovery of resources to usage of these resources without pre knowledge of their localization The solution for embedded devices and
229. r architecture from Sun and the JXTA for J2ME package aimed at J2ME enabled devices Chapter 6 Related work The chapter is dedicated to related work like the AMIGOS project that might find Jini and JXTA useful and the competitive technologies Web Services and Microsoft NET Chapter 7 The Prototype Describes the prototype that was developed in relation to the project in cooperation with Jorunn Kaasin The prototype is called Intelligent Traffic Service System ITSSystem Javadoc and Java code is enclosed on the CD accompanying the report Chapter 8 Discussion The discussion includes comparison of JXTA and Jini and a discussion around their solution for embedded mobile devices A melting of the two network technologies is considered and how they differ from NET and Web Services The chapter also includes a discus sion around future use of Jini and JXTA in the AMIGOS project and a discussion of the proto type Chapter 9 Conclusion The report is concluded in chapter 9 with some recommendation and thoughts around the future of the technologies discussed The report also includes a number of appendixes in relation to the subject presented in different chapters These are not considered directly connected to the assignment but just as additional information for the interested reader Parts of the chapters or whole chapters can be read if the reader is interested but they are not mandatory to understand the discussion and conclusio
230. r development for J2ME MIDP that is of interest in relation to network connectivity and possibilities Today there are 37 Java Specification Requests related to J2ME and most are intended as optional packages that will work with any profile whether it is based on CLDC or CDC An overview of all specifications in progress can be found at the Java Community Process site JCP The process of how specifications are standardized was covered in last autumn s project Lyng2001 4 1 Location API for J2ME The location specification JSR 179 is proposed as an optional packages targeted to work on CLDC 1 1 as a minimum and related profiles as well as profiles based on the CDC Its intention is to enable devel opers to write mobile location based applications and the purpose it to provide a compact and generic API that produces information about the device s present physical location to Java applications The API is intended to work with most positioning methods such as GPS or E OTD but require that the device using the API supports some mechanism to determine its physical location Security issues like access control and policy for permissions is necessary but out of the scope of the API MIDP 2 0 s security model will provide one way to establish the required security framework The GSM 03 71 specification suggest a set of standards for implementing location services LCS on GSM mobile terminals and networks and the 3GPP TS 071 specification and
231. r example RMI CORBA DCOM or a proprietary protocol Jini offers an open development environment for creating collaboration through the Jini Commu nity and the technology is available for free limitations of Jini are Assumes that Java is everywhere i e all services be transported as java mobile code and run on a Java virtual machine or have an entity that can run this virtual machine on behalf of the serv ice Assumes that a Jini Lookup Server always is present on the network witch might not be true If none exists Jini will not be able to work Dependent upon TCP IP which is most often not supported in wireless mobile devices The reference implementation from Sun is dependent on the remote method invocation RMI technology This dependence is related to downloading of stubs and enabling of a connection between an interested client and the lookup service 4 2 Jini Architecture In the simplest way Jini can be seen as consisting of three entities the services the lookup servers that catalogue available services and the clients that requires the services These entities are built up of com ponents and sub components of the system architecture of Jini The system architecture of Jini consists of three components that collaborate with each other to achieve the overall system objectives These components are The infrastructure component The programming model component and The service comp
232. ral server goes down everything does Extensibility Centralized systems are hard to extend since resources can only be added to the central system Background 2 2 2 Peer to Peer Network Architecture Distributed network technologies try to compensate for some of the limitations of the client server ar chitecture They provide a client with an interface to call for services and so limits the client s knowledge of where to find the services The services are distributed among a number of servers and the client s request is sent to or several of those but the client is unaware of who is responding But this archi tecture classifies computers in servers and clients and only servers can provide an answer to a request eatlier distributed network technologies like CORBA and DCOM highly advanced and are to extensive and heavy for embedded devices Later distributed network technologies have included the mobile environment at design time and hence is also available for the mobile devices An architecture that has gained much attention the last years is the peer to peer architecture Figure 2 2 shows the Peer to Peer architecture consisting of interconnected nodes The paradigm consists of distributed network technologies like Jini and JXTA discussed in later chapter of this report Peer to peer came into existence as a result of different possibilities Decentralizing It is a natural result of decentra
233. ramming level Interfaces gt Connection gt gt lt lt gt gt Input Connection OutputConnection lt lt 1 gt gt Stream Connection lt lt int erface gt gt x Interfaces Datagram C onnection Stream Conne ctionN otifier lt lt 1 gt gt ContentConnection Figure 3 4 CLDC Generic Connection Framework This platform independent framework provides its functionality without dependence on specific features of a device It provides a hierarchy of connectivity interfaces as shown in Figure 3 4 but it does not im plement any of them 17 Network capabilities 2 All connections created using a single static method in a system class called Connector and if cessful the method returns an object that implements one of the generic connection interfaces This ob ject is created on background of the Uniform Resource Indicator URI provided when calling the static method The URI syntax is defines in IETF standard 2396 2396 It is composed of three parts a scheme an address and a parameter list The general form is lt scheme gt lt address gt lt parameters gt The scheme identifies how the connection is made for example socket http file or datagram while the address identifies what to connect to and the parameters identify other information that is required by the protocol to establi
234. ransport mechanism But some protocols like HTTP are often implemented using sockets If open standards is an issue in the development and the developer is not in control of both the server and the client sockets may not be a good way to implement communication capabilities in the application Exceptions exist though As sockets purely provide the transport mechanism another data format or protocol could be used in con junction with sockets for example XML Using XML allows the application to take advantage of sockets while using non proptietary or publicly defined XML schema This still requires coordination between client and server application to ensure that they both support the same connection types 19 Network capabilities in 2 Version 2 0 of MIDP introduces both a socket class and server socket class making the mobile java enabled device capable of exchanging information without use of a middleman or relay Sockets can both be two cellular phones that send messages to each other or a mobile device that connects to a J2SE or J2EE server application MIDP applications using sockets will still be dependent on the infrastructure to find the server and vice versa If the mobile device cannot connect to the wireless network the application would not be able to exchange messages between client and server Datagram Datagram are designed for sending packets of data over a network The client is not required to set up a c
235. re a node must have direct contact with the receiver of the data WLAN is an example of a single hop network while PRnet is a multihop network Figure B 1 shows some selected networks that are mapped to two independent aspects of an ad hoc network Horizontally direction shows the level of central control while the vertical axis is divided after usage of radio multihopping Since ad hoc networks consist of equivalent nodes that communicate over wireless links without central control they will remove the limitations imposed by base stations and routers Beyond this the problem for ad hoc networks are the same as for the traditionally cellular and wireless networks optimalization of bandwidth power control and improvement of transmission quality The multihop nature of ad hoc networks and the lack of fixed infrastructure produce new research work like announcement discovery and maintenance addition there is addressing and self routing Internet or corporate IP network E m 45 Dm 5 Figure B 2 Network of Personal Area Networks PANs Eric2000 Ad hoc networks with limited range can form Personal Area Networks PANs to improve communica tion between different mobile devices and eliminate the need for cables Mobile devices can be mobile phones and PDAs The PANs can communicate between themselves and have connection to Internet as shown in Figure B 2 Here four Bluetooth PANs are connected via portable computers and
236. reas and interaction includes exchange of information and media streams like text audio and graphics Use of Jini and JXTA in realtion to this project will give a totally different solu tion than the one envisioned by the developers The AMIGOS architecture of today is very centralized but with introduction of Jini or it would become distributed and the functionality of AMIGOS might be split in several parts Vili Table Of Contents PREFACE Roles shied eom eoe NE bU 10 V ABSTRACT neon nie o Stes EIST OFE XIII EISEORTABE BS 3deetteete t eee eer ceteri ebore ete XV CHAPTER I INTRODUCTION eee enero anne ee Een sseos tesisi oseese 1 PHE ASSIGNMENT vhs sag iet e EE IB e e acta cae 1 1 2 OBJECTIVES AND 8 222 2 2 2 0 4 0 00000000000000000000000000000000000500558 2 1 7 READER S 2 CHAPTER2 BACKGROUND e sien eet si einen ooo so no eoe vos unen aca da en Ge eta ee sa oer e uv Do eae 5 2 H EMBEDBED DEVIGES eec eee etes ete ie et eue eed ec e reco 5 2 2 NETWORK ARCHITECTURE AND 6 2 2 1 Client Server Arch
237. ree security aspects that has to be taken into consideration confidentiality integrity and authentication Confidentiality and integrity imply that information that is exchanged in the ITSSystem must be prevent ed from unauthorized listening or corruption of data The way to do this is through encryption The cur rent version of JXTA for J2ME has no security built in and JZME MIDP has no security mechanisms for encryption a result the current version of the ITSSystem cannot prevent unauthorized parties from snooping But packages like Bouncy Castle an open source cryptography package could be included to ensute privacy until further security is provided in J2ME Authentication could be done using a username and passwotd but the problem is who is going to verify that a party is who he claims to be Cost NF 8 covers the possibility for the user to control the cost usage i e the money spent TSSystem 1 0 realize this by setting the poll frequency In order for this to influence the costs the billing of the network usage must be according to the amount of data sent not the time the user is online This is decided by Appendix C ITS System UML diagrams and comments the access network used to connect the mobile device to a network As of today the leading cellular netowork is GSM which is circuit switched and charge according to time GPRS and 3G networks on the other hand are packet switched and charges according to amount of data
238. ributed technologies like CORBA TINA and DCOM was developed The newest leaf to dis tributed network technology paradigm tree is the Peer to Peer P2P network technology 2 2 1 Client Server Architecture In the client server network architecture the client connects to a server using a specific communication protocol to obtain access to a specific resource One such protocol could be Hypertext Transfer Protocol HTTP or File Transfer Protocol FTP In this scenario the burden is places upon the server when it comes to processing and delivery of the service and the requirements for the client is small This archi tecture is used by most popular Internet applications like the Web and e mail The client server archi tecture is shown in Figure 2 1 Background Figure 2 1 Client Server Architecture The background for adopting this client server strategy from the beginning was the availability of com putational power Equipment was expensive and one could not expect the client side to possess much computational power On the other hand this model was developed at a time when most machines on the Internet had resolvable static IP addresses it was possible to find a machine using a simple name that was translated to an IP address by use of a DNS Today we can observe that this architecture has several advantages and some major drawback The ad vantages are Simple The primary advantage of centralized systems is their simplicity
239. ring type int BSisearchContacts contactList String boolean BSisearchContact contact String boolean BSisetPollInterval seconds int BSicloseNetworkConnection Bruno Figure 7 14 Detailed view of NetworkClient I TSClient extends the MIDlet class of JZME MIDP and since MIDlet is the basic unit of execution in MIDP ITSClient is responsible for the application entry and leaving of states during the MIDlets whole life cycle The different states are pause active and destroyed To react to the different command actions received from the user ITSClient implements the CommandListener interface ITSMe sage lt lt gt gt final GROUPINFO int 1 lt lt gt gt final CONTACTINFO int 2 lt lt gt gt final MESSAGE int 3 BST SMessage content String receiver String sender String BST SMessage content String receiver String sender String type int WSgetContent String BSgetReceiver String WSgetSender String BSgetTypeQ int Figure 7 15 The datatype ITSMessage The ITSClient will implement the graphical user interface and includes all the methods used to create the screens with the appropriate text button lists and textboxes ITSClient will use the DatabaseClient to retrieve and store information to the database and use the NetworkClient to communicate with the JXTA network The only public m
240. rom J2ME The included packages are subset of the JSR 101 specification JAX RPC 6 3 Microsoft NET Microsoft INET NET is Microsoft s answer to the next generation of distributed networking a soft ware platform where software is delivered as services It is a language neutral environment for writing programs that can easily and securely interoperate Programs are not targeted a particular hardware and operating system combination but will run wherever NET is implemented The intention is that user should be able to access their information across all devices Microsoft NET is a set of Microsoft software technologies for connecting the world of information people systems and devices It enables software integration through the use of XML Web Services as well as to other larger applications via the Internet Microsoft NET spans clients servers and services and consists of NET fto NET Framework A programming model that enables developers to build Extensible Markup Language XML Web services and applications A set of XML Web services for example Microsoft INET My Services A set of servers including Windows 2000 SQL Server and BizTalk Server that integrates runs operates and manages XML Web services and applications Client software such as Windows XP and Windows CE Tools such as Visual Studio NET to develop XML Web services and Windows based and Web applications Framework is the program
241. roups Since the only supported protocol in MIPD for communication over network is HTTP the Network Client uses a JXTA proxy At specified intervals it asks the proxy if messages has arrived for the user NetworkClient implements java lang Runnable and creates a thread for the task of polling the relay The public attributes and methods of NetworkClient are shown in Figure 7 14 The non functional requirement NF 1 states that the system should be independent of the network The realisation of the NetworkClient fulfils the requirement since it hides the interaction with the network for the user and all exchange of data inside the system is system specific not network specific Commu nication and exchange of information and data is done using an ITSSystem specific datatype called ITS Message included in the Datatypes package The class diagram for TSMessage is shown in Figure 7 15 71 The Prototype lt lt Interface gt gt Runnable from java lang NetworkClient Wx lt lt static gt gt lt lt final gt gt SIMPLESEARCH int 1 lt lt gt gt lt lt final gt gt ADVANCEDSEARCH int 2 lt lt gt gt getinstance client ITSClient relayAddress String relayPort int clientName String NetworkClient BSjoinGroup groupName String groupld String boolean BSlleaveGroup boolean BSisendMessage msg ITSMessage boolean BSisearchForGroups groupName St
242. rovide instant messaging and presence service American On line s AOL Instant Messenger AIM is beginning to be provided as a service for mobile users The Wire less Village standardization effort is targeted at the mobile marked while SIMPLE is targeting IP telephony networks Both Wireless Village and SIMPLE is covered in more detail later in this appendix JAIN JAIN is a set of API s that aims at enabling the integration of the Internet and Intelligent Network IN protocols This is referred to as Integrated Networks The initiative consists of two areas of devel opment The Protocol API Specification specify interfaces to wire line wireless and IP signalling The Application API Specification address the APIs required for service creation within a Java framework spanning across all protocols covered by the Protocol API Specification All specifications aimed at integrated networks are part of JAIN This includes the presence and instant messaging packages that are being standardized at the moment through the Java Community Process Four of these specifications are covered in later sections of this appendix two in relation to SIMPLE and two in relation to generic presence and instant messaging protocols 1 SIP for Instant Messaging and Presence Leveraging Extensions SIMPLE Appendix F Presence and Instant Messaging Wireless Village Wireless Village is an industrial consortium founded by Ericsson Motorola and
243. rted stopped and removed from the device depends on the target device and the operating system OS used The I TSSystem consists of two files TSSystem jad and ITSSystem jar The JAD Java application descriptor file describes among other things the size of the JAR file and should be loaded into the device first to check whether a full load of the JAR file is worthwhile The JAR file contains the program and should be loaded onto the terminal in order to run the ITSSystem When you have installed the program and got a username you can start the ITSSystem You will first get the screen to the right Log in using your username and click OK EXIT closes the program Editing the setup is explained in part D 4 D 2 The group list The first screen that appears after login if you choose not to edit setup is the group list pictured to the left The group list is a list of the groups you might want to participate in The first time you log in this list is empty and you must add the groups you are interested in When you have added groups to your list you can select one of them to join This is done from the group list shown to the left Click OK to join the group you have selected If you click the MENU button the group editing menu will appeat Appendix D ITSSystem User Manual D 2 1 Edit group list The menu shown to the right is the group editing menu From this menu you can add new groups or delete existing groups If you
244. s endpoints services and content can be described by advertisements Advertisements are language neutral metadata structures that describe the network resources i e they dictate the structure and representation of the data Project JXTA standardizes a set of advertisements and developers ate free to subtype these advertisements to create their own types The core advertisements XT ASpec Peer advertisement Peer Group advertisement Pipe advertisement Module advertisement Peer Info advertisement Content advertisement Peer Endpoint advertisement Advertisements are cached published and exchanged between peers to discover and find available re sources Peers discover resources by searching for their corresponding advertisements and each adver tisements has a lifetime that specifies the availability of the associated resource in the network The reference implementation provides three ways for peers to discover an advertisement Wilson No discovery The peer relies on a cache of previously discovered advertisements to provide information on peer resources Direct discovery Peers on the same LAN may be capable to discover each other directly without relying on an intermediate rendezvous peer by use of the broadcast or multicasting capabilities of their native network transport Indirect discovery Requires use of a rendezvous peer to act as a source of known peers and advertisements and to perform discov
245. s as Jini services 100 Discussion S 1 Surrogate Brigde The simplest solution is to use the surrogate architecture and let the surrogate generate and parse XML documents This solution will only create a bridge between Jini and JXTA and the two networks will continue to be separate JXTA resources be announced on the Jini lookup service the surrogate host on behalf of the JXT resource and peers can use Jini services by browsing the content in the Jini Lookup Service The surrogate host themselves could be advertised as resources in the usual way on the JXTA network S 2 XML support in Jini Lookup Server Another possibly solution to interoperability is to incorporate an XML parser in the Jini Lookup Service so that it is able to parse XML documents and assume that all JXTA resources are implemented in Java The lookup service can then act as a JXTA Rendezvous peer and parse JXTA Peer Advertisements and Peer Discovery Peers can either use the solution of discovery through the Peer Discovery Proto col PDP or unicast discovery messages to a Jini Lookup Service The services will be returned as seri alized Java objects where encoding of the object state is left to the peer IDs in Jini and JXTA must be matched for example by letting Jini IDs be matched to the peer IDs associated with each service allow ing JXTA peers to use XML to advertise and discover the services This can again be matched to t
246. s located all available Meeting Places can be browsed C Baas Location server 2 Request setvice receive prox 3 Communicate with AMIGOS JavaSpace Figure 8 3 Jini in AMIGOS solution C D Meeting Places as JavaSpaces Representing Meeting Places as JavaSpace have similarities with solution C The difference is that a Java Space is one Meeting Place and not the total AMIGOS service This leaves more to up Jini mechanisms The Meeting Places can be found through the lookup service using templates setting requirements for the search for example location or interests This requires the user to know his user profile and possibly his location UserProfile Repository Location server 2 Request setvice receive prox 3 Communicate with Meeting Place 1 Figure 8 4 Jini in AMIGOS solution D Advantages and limitations Solution A only provides a discovery mechanism and as a result the clients are not dependent on know ing the exact location of the AMIGOS server The advantage is that a proxy represents the AMIGOS servet in the Jini community and makes the client independent when it comes to communication proto col i e the client does not need to know how to communicate with the AMIGOS server since this com munication is handled by the proxy The lease mechansim of Jini also ensurs fault tolerance that is if the AMIGOS server goes down the clients will not be able to renew the lease and as a result
247. s not concerned with network dependent or database dependent exceptions only drawback of this version of the ITSSystem when it comes to network dependence is that a user must be able to supply an IP address and port to a proxy he wants the application to connect to This dependency will hopefully be removed in the future when the JXTA for JZME packages itself takes re sponsibility to find the nearest proxy and connect to it 7 4 8 Group membership A user of ITSSystem can only be member of one group at a time There is no limit in JXTA for 2 on how many groups a user can be member of The reason for this limitation in ITSSystem is based on 83 The Prototype usability issues If a user had the possibility to be member of more than one group the program had to be much more complex leading to lower usability user could also in principle be able too be in both private and public communication mode at the same time Again this would require to much from the user as the program would have become even more complex and hard to follow 7 4 9 User interface One of the challenges with making programs for mobile terminals is the limited input possibility The developers of such programs must choose between a solution which is easy to use but requires several screen and clicking or a solution which is not obvious to understand at first but does not require so much effort when first understood The ITSClient should
248. scribing obtaining information and cancel a membership 5 5 XTA community started as a research project at Sun Microsystems but upon recognizing that the effort would ben efit from expert coders outside of Sun the JXTA community was formed and the web site JX TAws was opened in April 2001 The JXTA community allow all developers to join in the effort of creating JXTA and all specifications and implementation code is open for developers under the Apache Software License Participating members of the JXTA Community use the JXTA web site to provide papers on the tech nology tutorials and hosts JXTA projects These projects can be initiated by JXTA community mem bers after approval by the community and anyone that wants is welcome to join Projects can be divided in six broad categories core components services applications demos and tutorials forge early stage JXTA projects and other The core components projects include the platform project the reference implementation of JXTA in Java and implementation of JXTA in other languages like C Perl Smalltalk and Phython Other projects are more specialized for specific devices for example for Pocket and a TINI binding 49 JXTA most interesting project in connection with this report it the JXTA for J2ME JXMEBE project XME 5 6 The for J2ME project JXTA for J2ME J XME also known as XME is an implementation of J
249. sh a connection such as a connection speed Examples of URI are http www an yaddress com 8080 socket localhost 8080 and datagram 127 0 0 1 8099 White Topley discusses some of the pitfalls of MIDP in his article Topley and point out that there are differ ences between HTTP clients written for 25 and MIDP HTTP clients A porting is not possible since the MIDP HTTP support currently presents a lower level interface than its J2SE counterpart This re sults in that MIDP client will have to handle details such as a server redirection which is taken care of automatically for desktop devices One must also always be aware of the resource limitations imposed by MIDP devices and restructure the code accordingly 3 2 2 Protocol implementations for MIDP 1 0 The network support included in MIDP is based on the Generic Connection framework from CLDC A requirement for MIDP 1 0 is the support for accessing HTTP 1 1 servers and services The reason behind the HTTP support is the fact that MIDP enabled devices may not have built in support for the IP pro tocol and HTTP can either be implemented using IP protocols such as TCP IP or non IP protocols such as WAP Because of the variety of wireless networks a gateway might be required that can bridge between the wireless transports specific to the network and the wired Internet This gateway will be responsible for URL naming resolution so that the device may access the Internet This is show
250. since the type of connection is dependent on the resources of the MIPD enabled devices And as long as these devices have today s constrains is the only protocol suitable Datagram and sockets are introduced in MIDP 2 0 and will be discussed next In addition some actions are taken towards mote netwotk security and MIDP 2 0 MIDP2 0 will provide a framework to provide both secure http connections HTTPS and secure socket connections This is covered in section 3 6 Sockets Sockets provide the functionality to establish connection between two systems and communicate as if the connection was a stream This 15 a primitive but lightweight and useful method of communication sockets has low overhead this can be one of the fastest methods of exchanging data and issuing com mands between two systems White The drawback is that sockets only define the connection and the low level data transport mechanism and leaves the client and sockets listeners to define a protocol of how the two systems communicate In other words the sockets provide connection but the format of the exchange information is left to the implementer The result is that there are few restrictions on what you can do with sockets but everything you do will need to be determined and built Sockets are useful in cases where speed is more important than adhering to open protocol standard since using sockets probably means you will be implementing a proprietary data t
251. sing the service for instant by choosing how often to poll for incoming messages 9 Response time The user should receive response from the relay within the set poll interval which can be set by the user 7 2 3 Requirements and prototype versions When implementing the system it is important to break the system up into smaller parts In that way not everything need to be implemented at the same time and testing of a particular requirement will be easier This is the reason for making versions of the system where the first version will only satisfy some of the requirements the next version will implement additional of the requirements and so on In the last ver sion all the requirements will be satisfied The goal is that the prototype developed in this project should be of version 1 0 Version 1 0 F 1 Login F 2 Modus of communication F 4 Send messages F 5 Receive messages F 6 View group list F 7 Join group F 8 Change group F 9 Edit group list F 10 Add group By version 1 0 the prototype should support enough functionality to work as a stand alone service and be useful for the users The first rollout will include features for the user to login with a username No passwotd is required Communication can only go through public room in this version and the user will be presented for a list of groups and should be able to join one of these groups The group list is stored in a database where it ca
252. sonalJava 1 2 and support both Linux and Windows CE It can be bought online for about 20 The disadvantage with the Jeode solution is that the virtual machine is rather big around 5 Mb where the emulator described next uses a small fragment 3 1 4 Micro Edition for Standard Edition MEASE me4se micro edition for standard edition is a project which purpose is to make 2 APIs like the user interface LCDUD and the network packages the Generic Connection Framework availa ble for the standard edition of java J2SE The motivation is to enable some limited development support for platforms where no emulator is avail able and allow demonstration of MIDlets before installation on the device It should also enable Person alJava devices to run MIDlets which is of interest for the iPaq at disposal when developing the prototype Distribution of me4se is under the GNU Public License GNUpl and the package is developed by a theme of independent software developers Me4se uses the png library from sixlegs com for PNG sup port Pnglib which must be downloaded and installed with the me4se package Using me4se an application using JXTA for J2ME and MIPD will execute on the iPaq as long the appli cation does not try to establish a network connection Drawbacks for the Jeode plus me4se solution is that it is a rather troublesome process to have get a MI Dlet to execute and that the me4se is still under development and migh
253. specific additions to the surrogate programming model The interconnect proto col defines mechanisms for discovery retrieval and availability and interconnect specific APIs which all are device and interconnect dependent The surrogate host is responsible for implementing the inter connect protocol Different Interconnect projects ate being developed and some of them are listed be low JiniSASpec IPsurrogate TCP IP interconnect IPInt IPIntSpec WirelessDevice Bluetooth interconnect Jini WD SmartCard Smart Card interconnect IEEE1394 Firewire iLink bus interconnect surrogate programming model support the life cycle and other interconnection protocol require ments The advantage of the surrogate architecture is that it does not depend on any particular capability of a device managed by surrogate i e it is device independent They to not need to be java enabled and memory processing and communication constraints will not prevent it from participating in the surro gate architecture Other advantages is that Jini s Plug and work goal is fully supported in that discov ety code downloading and leasing of distributed resources are preserved and the architecture is network independent i e it supports various networks and multiple protocols on the same physical network The limitation is the assumption that a host capable machine exists which is both connected to the intercon nect and the Jini network
254. ssage will be given to the user before the application clear up ongoing activity and exits This includes storing the group list to the database Internal errors include malformed parameters and occurrence of null pointer objects The ITSClient han dles situations where the user leaves mandatory text fields empty by alerting the user with an error mes sage The methods in NetworkClient checks all critical parameters whether they set to null or not and takes different actions according to this In addition the NetworkClient always ensure that the client is never participating in more than one group and that it is part of a group before sending a message DatabaseClient will return null if no groups exists and this is handled by the ITSClient by not displaying any groups and not give the user the possibility to click ok in the group list view If no groups exist when closing the application the DatabaseClient will receive null and then delete all records in the database concerning groups 7 4 3 Parallelism Several operations will occur at the same time in the application The ITSClient must handle user input and possibly receive messages from the NetworkClient at the same time The NetworkClient will have to tespond to calls from the ITSClient and at the same time poll the proxy at set intervals This parallelism is handled by use of threads TSClient handles the user interface which is a thread on its own awaiting input from the user
255. sse 22 3 3 4 Mobile device to mobile terminal services essen 23 3 4 MIDDLEMAN ARCHITECTURE eene ener 23 3 5 NEW NETWORK TECHNOLOGIES FOR 2 ENABLED DEVICES cene 24 SIME EM 24 202 JXTA tss oe ice vei Tate Tenere tente utn ee ever eise rare oe 24 Sis hat te 24 3 6 SECURITY 2 190 sided a etii Hood Ma et 25 Table Of Contents 3 6 1 Application security on the 4 26 3 6 2 Network security and cryptographic solutions essere 26 ST SUMMARY A ette edes A UP ERE CI Eine At A otn 28 CHAPTER 4 JINI NETWORK TECHNOLOGY eee ee eee ee een sese setae seen sese teens sesta 29 4 1 INTRODUCTION TO JINI NETWORK 29 A2 JN ARCHITECTURE 30 4 2 1 The infrastructure 32 4 2 2 The programming model component essere 33 4 2 3 The service component RE WAR rd 34 4 3 THE JINE COMMUNITY 55 tete toto erret pe ae ede toca NEE 35 4 4 JINI SURROGATE ARCHITECTURE 35 45 THE ANHINGA PROJECT tetra tussles cuted bite pb ard p Prep 37 tr RR de B eoe rre M E E
256. t must be proposed to the community to review the project description and so as to avoid duplication of projects Each project has an owner and a mailing list and documents regarding the projects are made available for the community on jini org JiniOrg Projects of interest in relation to embedded devices are The Surrogate project goal of the Surrogate project to investigate the use of third party computational resources to Jini enable devices that can not directly interact with a Jini network and to define a standard way for doing this Jini WirelessDevice Project The purpose is to create the standard needed in order to make a Jini enabled wireless device Focuses on Bluetooth interconnect between the surrogate architec ture and a device The Anhinga Project Developing variations of JAME CLDC Jini and JavaSpace technologies that run in ad hoc networks of small mobile wireless devices such as PDAs cell phones pagers and pocket PCs The Jini community creates and agree upon standards which are intended for use by developers as guide lines when developing software using Jini technology A standard starts as an initiative from one person a group of person and all interested parties may collaborate on the proposed standard Today there are three standards and two of them are the Jini Technology Core Platform Specification and the Java Space Service Specification A Print specification the Surrogate Archi
257. t not support all the features in MIDP yet 4 WebSphere Micro Environment IBM has renamed its VisualAge to WebSphere IBM and included a development environment for J2ME applications supporting both CLDC MIDP and CDC with additional profiles called WebSphere Micro Environment The environment includes an emulator debugging and creation of executables re quired by their own virtual machine 19 WebSphere Micro Environment is companied by a runtime environment for a wide area of devices IB Mrt among other the PocketPC run an ARM processor i c an iPaq Their virtual machine is ex tended version of the J9 the virtual machine first developed with the Palm as target to support J2ME An evaluation version of Device Developer with Micro Environment is available for free from IBM at the moment but it is time consuming to get to know the program and find out the necessary steps to take to create a MIDlet since the documentation is insufficient The same counts for the runtime envi ronment on the pocket pc Except from this it seems like a good solution for a virtual machine The platform takes minimal of space since a user can decides and pick the programs and libraries he wishes and so reduce the virtual machine to a minimum only capable of running applications If the user later decides that he wants to develop application on the iPaq he only installs the necessary libraries The drawback is that it is not easy to understand w
258. t that the AMIGOS server appear as JXTA peer It advertise its presence and clients find the peer or resource by using the JXT discovery protocol Authentication and handling of meeting places and location is left to the AMIGOS server 4 Communicate with A AMIGOS server through private pipes Client 2 Discovery 1 Advertise its Dresence Pipe 3 Discovery responses Figure 8 5 JXTA in AMIGOS solution A 109 Discussion This solution will also allow discovery of peripherals like printers or other useful entities in the network B Decentralized responsibility A decentralized responsibility aims at splitting the responsibility of the AMIGOS server in several parts which in cooperation constitutes and fulfils the total of servces in AMIGOS Meeting places location servers and devices appear as JXTA peers and ate members of the same peer group The peer group is responsible for authenticating the peers joining the group and only members of the group are able to see the other members B 4 Communicate with the meeting place through private pipes Meeting Place 1 Advettise its 3 Discove presence responses A Pipe User Profile Meeting Location Repository Place 2 Server The AMIGOS Peer Group Figure 8 6 JXTA in AMIGOS solution B Meeting places can be created and then join the AMIGOS peer group They announce their presence through advertisements to the peer
259. t want to exchange data Extensible Markup Language XML XML is a markup language for documents containing structured information The adoption of XML is based on the need for a technology to enable usage of richly struc tured documents on the web Simple Object Access Protocol SOAP is a framework built on XML that allows a program to invoke service interfaces across the Internet without the need to share a common programming language or distributed object infrastructure While XML provides a cross platform ap 55 Related work proach to data encoding and formatting SOAP defines a simple way to package information for ex change across system boundaries Web Service Definition Language WSDL WSDL describes operational information of Web Services i e where the service is located and what the service does It also describes in what manner a requester can make a connection to a Web Service WSDL defines an XML grammar for describing this kind of infor mation Another technology that takes care of service descriptions is the Universal Description Discovery and Integration UDDI UDDI The UDDI database stores and distributes references about the Web Serv ices different companies offers but the most important characteristic for UDDI is that it defines a next layer up that lets two companies share a way to query each other s capabilities and to describe their own capabilities The UDDI specification consists of many documents in addit
260. t without further changes to the setup In the group view screen the user will have to select one group to join 89 The Prototype which will bring him to the group chat room The test cases presented here have this screen as starting point and is summarized in Table 7 7 No Test case Desired result Result 1 51 Click NEW in the group chat screen The New Message screen with a OK text box and the possibility to click SEND and CANCEL appears 5 2 Click MENU the group chat A menu with the options Change OK screen group Setup and Exit appears T 5 3 Write a message and click SEND The name of the user and the message OK will appear on the screen The maxi mum number of messages printed to the screen depends on the value set in setup or the default value 3 The message is sent to the group and the application returns to the contact list view 5 4 Receive a message from another user The name of the other user the OK in the same group for example send sender and the message will appear from another emulator on the screen T 5 5 Click OK in the group chat with a An error message is displayed and the OK empty message string user returns to the message send screen T 5 6 Write a message that contains more Not possible The user will not be OK than 256 characters allowed to type more characters than 256 T 5 7 Write a message and then clic
261. tecture specification and the IPIn terconnect specifications are waiting to be standardized 4 4 Jini Surrogate Architecture Many devices are not capable of participating in the Jini network because of memory processing and communication constraints or just because they are not Jini enabled or have no java virtual machine Even if a device does support Java technology for example J2ME it may not meet all requirements to 1 Atomicity Consistency Isolation and Durability ACID 35 Jini Network Technology support a full Jini implementation Jini Surrogate Architecture specification JiniSA is a Jini community project dealing with Jini enabling of devices By using the surrogate architecture devices that could not easily take advantage of Jini technology may now become part of a network of Jini technology enabled services and or devices The surrogate architecture defines a surrogate execution environment and a sur rogate programming model and provides requirements for interconnect specifications Figure 4 4 shows the Jini Surrogate Architecture As Jini the surrogate architecture relies on mobile ob ject but the direction of the motion is reversed Where the mobile objects in Jini are loaded into a device the objects in the surrogate architecture are moved out of the device and into a surrogate host These objects known as surrogate object are written in the Java programming language and represent and act on behalf of th
262. tempts to place Java on the iPaq have resulted in support for Personal Java PJava and lately also CDC and the Personal Profile the new version of PersonalJava included in J2ME under development But there are some pos sible solutions to run a kvm for MIDP on an iPaq Run the PersonalJava virtual machine from Sun supporting version 1 1 and supply with the me4se emulator Run the virtual machine from Insignia the Jeode platform which suppott version 1 2 of Personal Java i e version 1 1 8 of the standard edition of java On top of this virtual machine supply the me4se emulatot Using the kvm for Pocket PC running an ARM processor included in WebSphere Micro Environ ment from IBM The two next sections will introduce the Jeode solution and the IBM solution The Jeode platform Jeode platform is developed by Insignia Solutions a company that seeks to become key provider of provisioning infrastructure software that focuses on the technologies needed for wireless carriers handset manufacturers and others in the Java eco system to fully capitalize on the Java standard Insig nia Appendix E 3rd party software development tools The Jeode platform is an independent implementation of a Java virtual machine both for PersonalJava 1 2 and EmbeddedJava 1 0 3 and is roughly equivalent to JDK version 1 1 8 The PDA edition is tailored for Pocket PCs PDAs and related handheld devices is compatible with Per
263. ten compared to TCP IP that links Internet nodes together where JXTA technology connects peer nodes with each other Different transport standards can be used to transport the JXTA messages like TCP IP with no impact on the messages since these have pre defined format and may include multiple data fields importance of this is that encrypted content will always remain encrypted regardless of protocol conversions that may occut between networks Digital certificates ate used in to ensure the identities of parties to a transaction and fulfil the require ments to authentication and non repudiation Digital certificates are issued by a trusted party i e a X509 V3 compliant certificate authority CA But a centralized is not always appropriate in peer to peer computing since the involved parties want to be able to conduct a secure transaction without in volvement of a centralized framework The JXTA solution is to allow peers to become their own certif icate authorities generating their own root certificate that verifies that they are associated with a specific public key JXTA security model allows peers form peer groups where a member can be designated as the for that group But a peer group can also use a well known certificate authority to issue the cer tificates 5 4 The Protocols Protocols are needed at every data exchange to dictate what data gets sent and in what order it gets sent They structure th
264. test plan for version 1 0 was made with test cases and the desired results The testing were separated in five parts according to the main functionality of the ITSSystem 85 The Prototype 1 Login 2 Setup 3 Group overview 4 Group list editing 5 Group chat public mode 6 Contact overview private mode 7 Contact list editing private mode The test specification includes a number for each test with by it can be referenced later a test case de scription or scenario the desired result and the result of the test using the testbed described in chapter 7 6 2 Tests can be passed not passed NOK or not tested NT Login The starting point for the test cases assosiated with login is at application launch Table 7 2 shows the test plan for login and authentication No Test case Desired result Result T 1 1 Log in with correct username and The Choose group screen appeats OK choose default setup with a list over the groups if any 12 Log with correct username and The setup screen appears OK choose to edit setup 1 3 Log in with wrong username An error message stating Incorrect OK username appears T 1 4 Click the EXIT button The application closes OK Table 7 2 Test specification and result for login Test T 1 4 has as result that the application will close upon hitting the EXIT button Closing implies that the connection to the database and the ne
265. tform interface to support command and control recognizers and speech synthesizers and consider future incorporation of dictation and other features Especially ap plication on embedded platforms will require speech which will allow them to perform various speech related functions for example speech recognition and text to speech The specification itself will not provide any speech functionality but access to speech functionality provided by supporting speech ven dors through a set of APIs and event interfaces Target platform is J2ME but whether it is both configurations or just CDC is not specified As the re quirements to the target platform are access to sound resources and adequate computing resource it might sound like it is intended for CDC and related profiles AA SIP for 2 Session Initiation Protocol SIP SIP is an IETF standard signaling protocol that can be used to estab lish modify and terminate sessions IP network The SIP specification abstract session from the phys ical network configuration and transfer to the application layer and supports user mobility An example of usage is to establish and manage multimedia IP sessions SIP is by many predicted to become an im portant protocol in the future IP mobile phone environment and SIP based applications will be essential enablers SIP is an IETF standard protocol for IP communications enabling IP telephony gateways client end points PBXs and other c
266. the hope for the future is that they are able to form private net works Personal Area Networks when they come in reach of each other Peer to peer provides the necessary functionality at the application layer while ad hoc technologies like WLAN and Bluetooth handles routing and data transmission at the lowest layer in the protocol stack A PAN will create exiting possibilities when it comes to sharing of information and usage of the available resources in the network Network solutions for embedded devices are dependent upon the capabilities in the programming envi ronment on the devices 2 MIDP which is a Java programming environment for mobile phones provides simple protocol support that limits the network capabilities But use of a middleman or relay makes the Java enabled devices able to join in networked applications The future promise that devices will be able to operate in PANs and the next version of MIDP will introduce further network support that will enhance the networking capabilities Several years will pass before the enhanced specification of MIDP is available in devices MIDP 1 0 was released in september 2001 and is just starting to be implemented in mobile phones The first phone with Java support came in fall of 2001 and Nokia released their first in May 2002 A number of other phones are announced to come during the year but as people buy fewer phones it will take time to build a base of users MIDP is more
267. the non functional requirements The implementation testing was executed during the im plementation of the different versions and after each version was completed In this way we did not con tinue with the implementation of a new version until the previous were functioning Since version 1 0 was the last version that was implemented a complete system testing was performed when finished 7 6 2 Testbed The prototype was implemented using J2M E Wireless Toolkit J2MEwtk and the supplied emulator in this toolkit It was also tried tested on an iPaq using a WLAN card both with the Jeode virtual machine from Insignia with the me4se emulator and by usage of the j9 virtual machine from IBM Unfortunately there where some problems with both platforms Using the Jeode with me4se the application went down since it could not establish network connection with the proxy The j9 virtual machine had no desire of running at all An introduction to the tools used in the implementation and testing of the prototype is given in Appendix E When it comes to phones the prototype was tested on a Nokia Communicator 9210 with a beta imple mentation of J2ME and as with the Jeode solution it failed trying to connect to the network The testbed presented in this document is the wireless toolkit with supplied emulators If some of the solutions for the iPaq had been mote successful these as well would be a testbed 7 6 3 Test specification and results detailed
268. ticating User lt lt include gt gt Login Peer Group lt lt include gt gt hitiator Select Modus Types of modus lt lt include gt gt m Change modus N Private Room Public Room Figure 7 4 Use case diagram for login and chat mode F 4 Send messages The user shall be able to send messages to a group public mode or to a specific person in the contact list private mode F 5 Receive messages The user shall be able to receive messages from members of the current group when in public mode and from members in the contact list when in private mode F 4 F 5 is illustrated in Figure 7 5 When the user is in private mode the sending and receiving of messages involve a second use the terminator while in the public mode the message is sent to and ceived from the whole group the peer group A message to be sent can both be a new message or a reply to an incoming message when in private mode 64 The Prototype BS Receiving messages 9 9 Peer Group Initiator Sending messages Terminator New Message Reply Message Figure 7 5 Use case for sending and receiving of messages F 6 View group list The user shall be able to view a list of groups The list consists of the groups of interest for the user F 7 Join group The users shall be able to join a group To join a group the user selects one of the groups in the group list 8 Change group The users shall be able to s
269. ting a group Since the TSClient already have implemented a method for viewing error messages and confirmation this would not have be a time consuming improvement of the system Another suggestion from some of the test persons was to arrange the editing and joining of groups a different way When the group list appears the user should select one of the groups and the next screen will give the user the possibility of either join or delete that specific group The reason for not choosing this solution is that the primary goal of this service is to join a group and communicate in that specific group If the user must first select a group and then a new screen with the possibility to join that group appears the user must go through an extra screen before he can start to communicate Other comments were concerning the names of the different buttons For instant if a user wants to write a new message the SEND button must be pressed Some of the users did not think this was obvious and wanted a more informative name for the button like NEW MESSAGE and SEND MESSAGE The problems with this is that the text is to long The last suggestion that were made from some of the users was to let the user decide whether to leave the group or not when editing the setup or adding a new group for instance The user test was a very effective way of testing the usability of the program Nothing was changed after these final user tests but in a real situation t
270. ting in and leaving a Meeting Place Amigos04 The modeling and implementation of the important service execution components in AMIGOS are intendend to be done using ServiceFrame a framework from Ericsson ServiceFrame has as objective to address the principal underlying problems seeking to provide sound and viable solutions that enable rapid develop ment of advanced hybrid and personalized services without sacrificing the quality SFrame02 The thought structure of the AMIGOS system is shown in Figure 6 1 Location Server AMIGOS server Terminal User Manager Manager Service Manager Figure 6 1 The AMIGOS Architecture The AMIGOS Server will be implemented using ServiceFrame where three of the main components the Terminal Agent the User Agent and the Service Manager Upon connecting to the server a client request is handled by the Terminal Agent which forward the request to the User Agent for authentication The User Agent is responsible for all information about the user which are stored as user profiles in a central repository and authenticate the client by compating the submitted credentials agains the creden tials in the user profile database A Meeting Place Service Manager is responsible for keeping track of the available and valid meeting places in the AMIGOS environment that can be situated anywhere on the netwotk Meeting Places shown to a uset may depend upon the users location and the location is r
271. to a network instead of is the Jini network tech nology Jini could be used as a replacement to JXTA or in addition to JXTA For example if connected to the Internet the mobile device could consult a lookup server Jini Lookup Server to find the groups available and avoid the time consuming job to search the JXTA network On the other hand if a connec tion to the Internet is out of range mechanisms could be used to search for groups This solution will create a demand for interconnect between the two technologies and different scenarios were dis cussed in section 8 3 The most suitable would be the Surrogate Bridge since it require less work than the others The prototype could also have been implemented using pure http and used a relay server in the form of a servlet php or cgi script to connect to distributed technologies like CORBA or RMI see Figure 3 11 Alternatively a client server model could be used where a central server could be implemented to host the service and the mobile device could connect to the server using HTTP Such a solution would re quire the service to keep track of the users in a database and store forward and route messages to the right users This would lead to much load on the server which could be a bottleneck for the service In addition the application would then be dependent on the infrastructure 8 6 Jini and JXTA in AMIGOS AMIGOS Advanced Multimedia In Group Organized Services is a
272. to get up and running To be able to start communication Gnutella introduce the concept of rendezvous points One such point has to be known to the peers and these can be found at some Gnutella enthusiast server running gnuCache which has some similarity with the DHCP functionality Some central elements had to be added to make the Gnutella protocol work smoothly but besides that the Gnutella is strongly based on peer sharing storage resources As a result Gnutella have a hybrid peer to peer architecture 11 Background 2 4 Summary Embedded devices have limited resource and require network technologies that can handle mobility ie that the devices appear and disappear from the network without notice Applications for embedded de vices should be connected to a network to be able to fulfil the wishes of its users access to services ywhere at any time on any device Java is an application development platform that looks promising for embedded devices Traditional network technology like the client server architecture puts restrictions on applications and reduces the applicability To compensate for this several distributed network technologies were devel oped like CORBA and DCOM but none considered the requirements of the mobile environment be fore the peer to peer paradigm was introduced in the latest distributed network technologies like JX TA and Jini Peer to Peer is a network technology that does not rely
273. tructured data that is well understood well supported and easily adapted into s a human readable format making it easy for developers to debug and comprehend Provids P2P functionality to every device with a digital heartbeat JXTA is available for peers behind firewalls and NATs Limitations of XTA e Many claim that the JXTA initiative to create standard comes to early since peer to peer has not had time to mature JXTA constitutes an extensive framework This might prevent the use of the specification since there is plenty to learn before it can be used and a lot to keep track of JXTA does not attempt to address how services are invoked with exception of core services Sev eral standards exist for defining a service invocation such as the Web Service Desctiption Lan guage WSDL but none have been chosen specifically by the JXTA Protocol Specification JXTA provides a generic framework for exchanging information between peers so any mechanism such as WSDL could potentially be used via to exchange the information required to invoke services The designers of JXTA infused a lot of flexibilities throughout the JXTA Protocols Specification and some have criticised this flexibility Though JXTA s use of XML specifies all aspects of P2P communication for any generic P2P application JXTA might not be suited to a specific standalone P2P application In an individual application the network overhead of XM
274. ts interact accordance to space 7 3 1 The Architecture The architecture is dependent on the network technology used This prototype will use the net work technology presented in chapter 5 and the JXTA for 2 JXME package that is designed for J2ME enabled devices Relay Figure 7 11 The architecture of the ITSSystem Mobile devices represented as cell phones in Figure 7 11 are dependent upon a relay proxy server on the Internet to connect to the JXTA network The proxy servers are responsible for forwarding messages to the appropriate ITSSystem client by sending it to the proxy server where that particular client is reg istered iii En Internet network Wireless Data Communication ES A f A Y JXTA Relay Client communication Access ITSSystem Wireless Internet infrastructure Server Figure 7 12 A cell phone connect to the proxy Netwotk technologies used for transport will influence the way a mobile terminal will connect to the re lay Figure 7 12 shows a scenario for a cell phone using GSM or GPRS The client will then have to use to connect via a wireless link to a terminal access server before connecting to a proxy server This is the 70 The Prototype most likely scenario for drivers but the hope would be that the phone itself could decide the most ap propriate transport technology to use at any given time and place and change this when appropriate 7
275. tual communication channels that are used by peers to send and receive messages between setvices or applications over endpoints The term virtual refers to the fact that peers do not need to 44 know their actual network addresses to use them Pipes are uni directional and asynchronous connects two more endpoints and offers two modes of communication Point to Point Pipe Connects exactly two pipe endpoints an input pipe end that receives mes sages sent from the output pipe end Propagate Pipe Connects one output pipe to multiple input pipes and messages are sent to all listening input pipe ends in the peer group two communication modes are visualized in Figure 5 2 Bi directional reliable and secure pipe serv ices have been implemented on top of the core pipe services Messages Communication in JXTA environment is done by sending and receiving messages The messages containers of the data being transmitted over a pipe from one endpoint to another To make JXTA in teroperable a standard format is needed for the messages JXTA uses messages in XML format but both XML and binary payloads can be sent The messages are defined as an ordered sequence of named and typed contents called elements As a result of the choice between XML and binary each JXTA transport can use the most appropriate format for moving data 5 3 4 Advertisements network resources like peers peer groups pipe
276. ture from the radio interface to link con trol Related topics are also covered such as interoperability with related technologies testing require ments and a definition of various Bluetooth timers and their associated values The second group the profile specification is concerned with the use of Bluetooth technology to sup port various applications Each profile specification discuss the use of the technology defined in the core specifications to implement a particular usage model and include a description of which aspects of the core specifications that are mandatory optional and not applicable The purpose of a profile specification is to define a standard interoperability so that products from different vendors that claim to support a given usage model will work together In general profile specifications fall into one of two categories cable replacement or wireless radio The Java APIs for Bluetooth Wireless Technology JSR 82 is developed for usage on CLDC and covers pure transmission of data The intention of this API is to support registration of services and discovery of devices and services It is capable of establishing L2CAP and OBEX connections and conduct all these activities in a secure fashion protocols covered are L2CAP Logical Link Control and Adaptation Protocol Resides in the data link layer and sup ports higher level protocol multiplexing packet segmentation and reassembly and the co
277. twork is closes for all open connections and that all groups and contacts are saved to the database Setup Testing the setup requires the user to start the application and choose edit setup at start up This will bring the user to the setup screen and he will be presented to several possibilities to regulate the running of the application The test cases presented here have starting point from this screen and is presented in Table 7 3 No Test case Desired Result Result T 2 1 Use the default values in the setup ITSClient connects to the relay OK screen and the user is presented for the group overview a list of groups if any exists T 2 2 Change the value of the relay host The application check that it is a valid NOK and or relay port IP address and that the port number is above 1024 and then connects to the specified relay The group over view is displayed for the user a list of groups if any exists Table 7 3 Test specification and result for setup 86 The Prototype No Test case Desired Result Result T 2 3 Change the polling frequency Checks whether the set polling fre OK quency is bigger than 0 then set the new pollfrequency before following the same result as for T 2 1 2 4 Change the value of number of mes Check whether the value is bigger OK sages than 0 Only the selected number of messages are viewed at once when the user is chatti
278. ue to communicate in group Trondheim 8 Change group to Selbu 9 Delete the groups Trondheim and Selbu 10 Exit the program The problems that the users had depended partly on the experience they had with similar programs like chat programs or instant messaging programs and with mobile terminals The result of the test is pre sented in the next sub chapter 7 6 5 User test result For the test persons with little technical background and no experience with similar programs the main challenge was to understand the screen flow in the program and how to return to a specific screen The menus specially confused them They were specially confused by the menus Since both were called menu they expected that the menus were the same and had some problems with understanding why some options in the menu had changed Other persons with more technical background suggested also that the menus should be similar or almost similar For instance they meant that Delete group should be an option for both of the menus Many of the test persons stated that they wanted confirmations when they edited something like the set up group list Specially after saving the setup they would like that a confirmation screen appeared as suring them that the setup was changed Some of the users wanted the same thing to happen when editing the group list while others were satisfied with the current solution where the group list were updated after adding or dele
279. uetooth was released in Spring 2002 and last part of this subchapter will give a short introduction to the main features Jini and JXTA network architectures are each developed by a community the Jini Community and the Jxta community respectively Both introduces something new to networking and are part of the new paradigm called peer to peer network technologies and both were originally developed for devices run ning J2SE or J2EE but are lately supplemented with compressed versions to be used with J2ME While Bluetooth covers peer to peer in all layers of the protocol stack including ad hoc and Jini aim at the application layer The hope for next generation of mobile phones is independence of transmission technology 1 that phones themselves finds the most appropriate bearer technology for his position at the time and when moving out of range or the signal from another bearer technology is stronger switch seamlessly over without user interaction or the user noticing anything 3 5 1 Jini Jini differs from all known network technologies It defines all devices on the Internet as services and the technology is developed around this concept A device should be able to be part of a Jini network and thereby be able to request services from the network One example might be a printer which is part of the Jini network A mobile device requires printing out a mail but it has no desire to install drivers it only wants to use a pr
280. um Other peer to peer realisations might concentrate on making the implemen tation of the paradigm independent on the network technology and so solves the problems at the application layer The term peer to peer is mostly used about the latter There are two major forms for the peer to peer paradigm Pure All nodes are Peers and each Peer may function as router client or server according to the status of the query This form is presented above Hybrid Some nodes are router terminals that facilitate the interconnections between peers Hybrid Peer to Peer Architecture notion of peer to peer has been extended to cover a range of protocols and solution that does not fully satisfy the pure peer to peer definition Many peer to peer protocols have introduced a central ele ment in the peer structure to be able to offer a consistent connection The central element may be intro duced as a static routing table or as a dynamic combined group manager and routing table SkaKau be consistent with the idea of peer to peer networking the management functions should be assigned to the peers A central routing table with no further functionality than routing is accepted as a necessary element in hybrid peer to peer networks The central router may be configured to play different roles One of two typical configurations Graham is router as a router in a traditional sense e g Internet routers while the other solution is more of a l
281. undamental difference of universality via XML or Java mobile code may be enough to keep the two technologies in the market until one or the other technology becomes obsolete 8 1 3 Advantages and disadvantages Despite the significant differences the technologies seem very similar and one can envision them con verging or one taking precedence over the other In connection to this the different outcome dependens upon whether one is already committed to Java or not If one is already committed to a Java platform the differences decrease The two first differences above will become insignificant and the third is ad justable in Jini to essentially mirror system In other words the major difference is usage of Java mobile code in the Jini protocols or the XML protocols of JXTA Without adjustment to the location of services the difference also includes whether one wants a centralized lookup of services or not Both so lutions are still discovery processes Another thing that has to be mentioned is that the reference imple mentation of Jini depends upon RMI to transfer java data objects between Jini services Taking this into account it creates another dependency since all devices running Java must have RMI suppott or they must use the surrogate architecture The rest of this section will assume that Java has been chosen as programming language and that the reference implementation of the specifications is used In relation to thes
282. used then users chooses to 79 The Prototype delete groups and here as well is the OK button removed when no groups exists When there exists group in the list the possibility to join one of the groups is made available for the user four username EXIT OK OK amp Default Y T a ED Join group o groups in list dd new from the menu iew messages 3 SAMI SETUP SAVE OK amp Add group amp Join group MENU TRONDHEIM BACK SEND CANCEL Back to lt gt CANCEL Figure 7 28 Screen flow for ITSSystem v1 0 In later versions when private room is supported and the search functionality is made available in the JXTA proxy additional fields and screens will be part of the system The setup screen will have additional fields for choosing between private and public mode Joining and editing of groups will be similar for private and public communication but when the possibility for searching for groups and contacts is han dled in the JXTA proxy the screen for adding new groups will look somewhat different In the current version adding a group means adding it to the local group list and when joining the group it is checked whether the group already exist of not Future version should change this functionality to a search pro 80 The Prototype cedure where the user can choose to search
283. ut the Jini services and use them if they have Java support The disadvantage is that the solution requires several changes to the Jini implementation as well as in the lookup service Lookup services and other services that wants to join the Jini network must be able to generate and parse XML which is very resource consuming But services might use binary messages in this way limit the burden Another disadvantage is that not all J peers can use the extended service area S 4 resources Jini services The 5 4 solutions is somewhat similar to the S 3 solution but concentrates on the JXTA resoutces Advantages are that Jini clients will be able to use services both on the Jini network and on the JXTA netwotk But the solution impose several requirements on the peers which should be spared from details in the interconnect In addition only resources with Java capabilities will be able to use the solution 8 4 Relation to other distributed network technologies It might be interesting to look at Jini and in relation to two related distributed network technolo gies Web Services and Microsoft NET This section first considers Web Services in relation to the tech nologies in question and then takes a look on Microsoft NET 6 4 1 Web Services Web Services consist of different technologies and models and be compared to other technologies in a multitude of ways This discussion will con
284. witch from one group to another This includes disconnecting from the pre vious gtoup and joining a new group 6 7 and F 8 is shown in Figure 7 6 In addition a requirement for editing the group list is shown This is covered in the next requirements 7 Initiator View Group List F Peer Group N Edit Group List Change group Join Group Figure 7 6 Use case diagram for viewing the group list F 9 Edit group list The user shall be able to edit the group list by deleting groups and adding new groups This means editing the local list located in the user s database Figure 7 7 shows F 9 and also the next requirement F 10 Add group which is a sub requirement of F 9 65 The Prototype Edit Group List Initiator Peer Group lt lt gt gt J Delete Group Add Group Search for groups Figure 7 7 Use case diagram for group list viewing and editing F 10 Add group Users shall be able to add new groups This includes first of all searching for the group in the network and if the group does not exist create the group F 10 is illustrated in Figure 7 8 When the user wants to add a group a search among the existing groups is initiated If no group are found a new group is created lt lt include gt gt Initiator Add Group Search gt N Peer Group 7 Add Existing group Create new group Search for groups Figure 7 8 Use case diagram for adding a group F 11 V
285. xample old clients can use the base interface while new clients use extended interfaces This allows for evolution of implementation without changing clients or infrastructure Only base interfaces need to be common the community of develop ers can define new ones Services are built over infrastructure components using application components as their building blocks and can be written by anyone as long as it is in compliance with the Jini specification Examples of serv ices are The lookup service The JavaSpace service and The transaction manager service Jini lookup service is part of both the Infrastructure and the Service layer of the Jini Architecture and was covered in section 4 2 1 The lookup setvice differs from the other services in that it 1s the only service that can be found using a discovery protocol all other services are found through requests to the lookup service Having the lookup service as any other service is an advantage in that it can be managed like any other service interaction is the same and it is possible to have multiple instances of the lookup service within the same network without conflicts Jini JavaSpace Service JavaSpace provides an optional distributed persistence mechanism for the objects within a Jini community It is simple and can be transactional secure The service uses parallel program ming in a distributed system where cooperating software ensembles and provides high level communi c
286. ystem ITSSystem was developed in co operation with Jorunn Kaasin and the essential feature is the ability for users to communicate with each other dependent upon their location It includes requirements specification design implementation vii Abstract notes and test specifications and result The prototype showed that JXTA for 2 is easy to use and has the most necessary capabilities but the lack of more advanced capabilities limits the possibilities Several other initiatives than Jini and JXTA have been made to provide distributed platforms that are able to communicate between different entitites reagardless of platform and implementation language They all differs in the way the independence is provided Web Services is a service architecture based on usage of XML SOAP WDSL and UDDI Microsoft NET is Microsoft s answer to distributed platforms The infrastructure the NET Framework provides runtime services and class libraries and NET services will always run where NET is installed Jini and JXTA might provide capabilities that are valuable in relation to existing development project AMIGOS Advanced Multimedia In Group Organized Services a project at Department of Telematics NTNU is a service that provides users with the possibility to establish and participate in Meeting Places i e virtual rooms where interaction optionally takes place between participants A Meeting place might be limited to geographical a

Network technologies for Java-enabled, mobile devices

Contents

Download Pdf Manuals

Related Search

Related Contents