Implementing a Bridge from Java Servlet API-based Components to Jini Network Technology

1. Implementing a Bridge from Java Servlet API-based Components to Jini Network Technology JavaOne BOF #844 June 4, 2001 Jeff Hackert, Nextel Communications, Inc. Jon Strabala, Mark Karmelich Quantum Systems Integrators, Inc www.QuantumSI.com

2. Topics • Jini/J2ME goals and sample application of traditional Jini Communities • MIDP Wireless devices can’t do Jini, but can join Jini Communities via JSB, the Jini/Servlet Bridge • Jini/HTTP Midlet (JHM) provides Jini services without having to write code for each service API • Overview of JSB/JHM organization and design • Customization Filters and JHM Extensions

3. Jini & J2ME: The Goal • When roaming in the mobile world, we want to discover, use and/or subscribe to appropriate services as needed without forward knowledge • discover • traditional Jini service discovery • use • select and utilize one or more services concurrently • subscribe • permanently enable and “use” a service

4. Jini & J2ME: The Goal (cont.) • appropriate • Discovery filtering: i.e., what services are appropriate to be discovered. • Activation filtering: i.e., what subscribed to services are appropriate to run. • Discovery and Activation filtering via Location, Severity, Time, Device, and Identity/Role profiles

5. Jini & J2ME: The Goal (cont.) • as needed • asynchronous notification of events from an active service or channel • asynchronous startup of a channel to a service that has been subscribed to • without forward knowledge • Generic code to find and use existing and (or “to be written” future) services, anywhere and at anytime

6. Jini & J2ME: The Problem • Today’s small, wireless devices can not participate in a Jini community in a generic portable fashion • These devices can make HTTP requests, but cannot dynamically download classes • Limited APIs on the device prevent direct Jini client participation i.e., missing RMI, missing Reflection, etc.. • Limited environment model, i.e., only one active MIDlet, no fixed IP address, etc.

7. Jini & J2ME: The Solution • The Jini/Servlet Bridge (JSB) coupled with a generic Jini/HTTP MIDlet (JHM) can enable any J2ME/HTTP-capable device to request and utilize generic services in a Jini network. • Jini profile-based discovery and activation • Allows one time use or permanent subscription • True “single sign on” i.e., device roaming • Concurrent active services (or channels) from different vendors and/or physical servers

8. Jini/Servlet Bridge (JSB) • Provide a generic Jini service API for bridging Jini communities to any active JHM (i.e. a J2ME/HTTP-capable device) • Maintain a proxy object for each active JHM • provide attribute info to Jini/Server side • manage database or record store for profiles • manage discovery and activation filters • manage channels, both JHM and Jini side.

9. Jini/HTTP MIDlet (JHM) • A JHM is a generic MIDlet which supplies a display for a JHM proxy object • A JHM is a specialized WWW browser for Jini that can display “pages” for • finding services • using and/or subscribing to services • notifications i.e. handling asynchronous events • enabling display focus to a specific service • multiplex TCP/IP connections across HTTP • Interface with JSB provides for JSB control of wireless device’s display, soft keys, etc.

10. Traditional Jini Service Mr. Portal Software needs a Jini Service: User: “Hey Mr. Portal, where is the movie Pearl Harbor playing in my neigborhood, at what show times, and can you book me some tickets?” “Mr. Portal” Software Request to Jini Community: “Is there a service of type MovieService out there?” Joe’s Movie Service Software provides this Service: “Joe’s Movie Service” Software Notification from Jini Community: “I’m of type MovieService and I’m available.” The selected implementation (i.e. class file) is downloaded from Joe’s Movie Service Software. Mr. Portal Software uses the Jini Service “Joe’s Movie Service” and answers the User

11. Traditional Jini Service (cont.) • Jini works, I can do anything - but I have to code! • Was the Jini service stub (i.e. interface) MovieService already defined ? • If not then Mr. Portal is out of luck • Assuming the Jini service stub is defined, Mr. Portal still must understand the API to use it. • The Jini service does not provide a “service UI”, so Mr. Portal has to write UI code to interact with the User.

12. Jini/Servlet Bridge Service Mr. JSB Portal (an implementation of a Jini/Servlet Bridge) allows any “JSB” Service (i.e., any Jini service that implements the JSB Jini interface) to register. “Mr. JSB Portal” Software Request to Jini Community: “Is there a service of type JSBout there that is public or that matches my non-public subscriber list?” Responses from Jini Community - build available services to be proxied to any JHM Mr. JSB Portal is the “Jini community” for any JHM that attaches to Mr. Portal (remember that a “JHM” is a MIDlet running on a wireless device) All Jini services that can talk to Mr. JSB Portal implement the JSB interface and must have been registered with Mr. JSB Portal Mr. JSB Portal does not need to understand any API except the base JSB, thus new services can be defined and registered with Mr. JSB Portal at any time.

13. Jini/Servlet Bridge (cont.) Mr. JSB Portal allows User to participate in the Jini community “Mr. JSB Portal” Software User: “I am located in Santa Monica, CA. What sort of services of type ‘entertainment’ are available?” Mr. JSB Portal: Returns a list of 0 to N services. For example we might have two: “SoCal Opera” and “MovieMania” User: Selects both “MovieMania” and “SoCal Opera” Mr. JSB Portal: Downloads Jini code (for Jini services of this type that implement JSB interface) and attaches a channel of the JHM proxy object for each service. User: Selects focus to and Interacts with the “MovieMania” service UI. “SoCal Opera” emits an asynchronous “alert” that seats have become available for tonight's show of “Don Giovanni”, user allows focus to shift to “SoCal Opera” via soft key and buys tickets.

14. Jini/Servlet Bridge (cont.) • Mr. JSB Portal needs no knowledge of the workings or UI needed by either “MoviaMania” or “SoCal Opera”. In fact the services could have been written years after Mr. JSB Portal started business. • The JHM MIDlet can multitask different Jini services to the User, overcoming a limitation of current MIDP implementations. • JHM only multitasks JSB compliant services and allows an orderly way to handle focus changes and asynchronous events.

15. Jini/Servlet Bridge Design • The JSB has to accomplish the following • Manage a database of wireless “clients” that access the JSB • Create proxy object to participate in Jini community for each desired Jini Service • Establish and maintain one or more “channels” between clients and Jini Services • Queue and pass data between client and Jini service through the “channel”

16. Jini/Servlet Bridge Design (cont.) JSB proxies clients and manages “channels” JHM Midlet “client” on wireless phone JSB Portal Servlet Software User HTTP requests and responses Proxy for Client #1 Proxy for Client #2 1. Method calls of JSB interface (includingget/send data, and open/close socket) Channel A ... Channel B Channel C etc. Proxy for Client #n Jini Service A 2. TCP/IP reads and writes over supplied socket Jini Service B Jini Service C etc.

17. Jini/Servlet Bridge Issues • JSB must keep track of all clients, services and channels • Client can only “request” via HTTP, but JSB must be able to send data back to the client • To be useful, Bridge must be able to provide TCP/IP “connection” to a stream of data in a Jini Service -- but HTTP is connectionless • Jini Services provide specific interfaces, but we want the Jini/Servlet Bridge to be generic to avoid needing future knowledge of service APIs

18. JSB Issues: Keeping track • JSB must maintain a database • active clients • Jini services • channels between them • Clients can come on-line and off-line at any time • Servlet must be able to handle out-of-sync clients, i.e., client MIDlet dies and restarts, has no idea that it has JSB requests pending

19. Simulated Two-way Connection • The wireless device is not a “on-line peer server”, so JSB can not independently “send” data to the wireless device • JHM (MIDlet extension for using JSB) provides a polling mechanism in a separate thread to continually check for data from the JSB • By threaded polling, JHM/JSB emulates and creates a bi-directional connection where each side (JHM and JSB) can send/receive data

20. Simulated TCP/IP Connection • JSB assumes that client can only do HTTP and HTTP does not provide a persistent connection • JSB can maintain a emulated TCP/IP Connection with the Jini Service • JSB can queue streaming data bound for a particular wireless client • As client makes HTTP requests to JSB, JSB can send data back to client via HTTP responses • Alternatively, JHM/JSP provides for using a real TCP/IP channel if the client can open a two-way socket to the server (MIDP does allow this).

21. Jini Servlet Bridge “Connections” 1. JSB maintains an active TCP/IP session with a Jini Service on a non-Jini client’s behalf Jini/Servlet Bridge Active TCP/IP session, Jini Service data going back and forth 2. Jini Servlet “queues” data bound for client HTTP response with queued data local storage 3a. JSB and client can communicate via TCP if the client supports it HTTP request Jini/HTTP MIDlet Wireless non-Jini client 3. Wireless non-Jini client makes periodic HTTP request to get data from TCP/IP feed

22. JSB Generic Interface • Jini Services provide specific interfaces, but we want the Jini/Servlet Bridge to be generic • Each Jini service must allow a generic ASCII-based layer on top of specific layer, e.g.,:public String getMovieInfo(String movie, String neighborhood)translates to something generic:public String getInfo(String key)where, in this case, “key” is a parseable combination of “movie” and “neighborhood”, etc.

23. JSB Generic Interface (cont.) • All Jini Services must use this “wrapper” interface that encompasses all commands/responses to service. • Example (on next page): JiniServletServiceIF (“IF” stands for “Interface”) • Methods must be implemented by each Jini Service • Methods are called by the JSB, acting as a proxy for a non-Jini wireless device

24. JSB Generic Interface (cont.) • JiniServletServiceIF Interface class: public interface JiniServletServiceIF { // methods include a “msg” Vector, into which // error or status msgs are placed // open/close service public boolean startService(Vector msg); public boolean stopService(Vector msg); // fetch something from this service public String getInfo(String key, String parms, Vector msg); // send something from this service, return true public boolean sendInfo(String key, String parms, Vector msg); // open a TCP/IP connection to this service public Socket openConn(String key, String parms, Vector msg); // close TCP/IP connection to this service public boolean closeConn(Socket socket, Vector msg); }

25. Example: find service Wireless non-Jini client 8:response back to the client that a service is found to supply “movie” info (returns a “handle”) 1: HTTP request to find service of a “moviefinder” type Jini Control 2: Jini: find “movie” services Jini Servlet Bridge 3: Jini:here are some services 4: Jini: give me your class Jini Service 5: Jini:here’s my class 6: API: initService() 7: return true

26. Example: open connection Wireless non-Jini client 4:HTTP response with a “connection handle” 1: HTTP request to open a streaming TCP/IP connection to a service Jini Servlet Bridge Jini Service 2: API: openConn() 3: return Socket a: in thread, socket read() b: returns data local storage

27. Example: send data to stream Wireless non-Jini client 1: HTTP request to send a command to the TCP/IP stream, e.g., “stream me the dialog from the Pearl Harbor movie” 4:HTTP response that the command was sent okay Jini Servlet Jini Service 2: socket.writeBytes() 3: return successful write a: in thread, keep reading() b: returns data local storage

28. Example: receive from stream Wireless non-Jini client 3:HTTP response with the streaming dialog from the Pearl Harbor movie: Look out! Here comes a torpedo!Aggh! The Arizona is sinking! 1: HTTP request to get data coming back from the TCP/IP stream Jini Servlet Jini Service 2: Read from local storage a: in thread, keep reading() b: returns data local storage

29. Customizing Filters • Key component of searching for Jini services is creating filters for desired Jini content • Generic MIDlet (JHM) provides standard “search” capabilities and ability to create on-the-fly menus based on Jini services found by the JSB • JSB provides means to accept geographic location information to filter requests geographically (e.g., show my movie times in my area) • JHM and its Proxy have interface class for JHM extensions to obtain GPS info from the wireless device or network, if such a capability exists

30. Jini/HTTP Midlet (JHM) Extensions • Developers can write classes to extend the JHM to write custom apps that make use of the generic model • Custom apps understand the API of the remote Jini service • Downside, requires a MIDlet suite load • Upside, can fully take advantage of full J2ME functionality provided to MIDlets • Upside, since JHM is extended basic JHM/JSB generic functionality still exists.

31. Jini/HTTP Midlet (JHM) Extensions • Example: Federal Express could provide a Jini Service for shipping, and a JHM MIDlet extension class that sends the appropriate commands through the JSB to work with the Jini Service • Custom JHM extension allows use of device serial interface to talk with GPS and bar code device • Full interactive Java GUI works without active peer JSB • Lower cost per tracking unit and RF access

32. Summary • Jini is powerful, but limited in that: • Jini clients need forward knowledge of API • Most wireless device can’t do Jini directly and thus can’t freely, generically find and use services in the Jini community • The Jini/Servlet Bridge (JSB) and associated Jini/HTTP Midlet (JHM) solves both problems

33. Contacts Jeff Hackert, Sr. Systems IntegratorNextel Communications, Inc.Jeff.Hackert@Nextel.com Jon Strabala, Chief Technical OfficerQuantum Systems Integrators, Inc.Jon.Strabala@QuantumSI.com Mark Karmelich, VP EngineeringQuantum Systems Integrators, Inc. Mark.Karmelich@QuantumSI.com Code samples, this presentation and more info: http://www.QuantumSI.com/developer