1

Implementing a Bridge from Java Servlet API-based Components to

Jini Network Technology

JavaOne BOF #844 June 4, 2001Jeff Hackert, Nextel Communications, Inc.

Jon Strabala, Mark KarmelichQuantum 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 ServiceMr. 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 ServiceMr. 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 JSB out 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”

JSB Portal Servlet Software

Proxy for Client #1

JHM Midlet “client” on wireless phone

User

Proxy for Client #2

...Proxy for Client #n

Jini Service A

Channel A

Channel BChannel

C etc.

HTTP requests

andresponse

s1. Method calls of JSB interface (includingget/send data, and open/close socket)

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 ServiceJini/Servlet Bridge

Active TCP/IP session,data going back and forth

2. Jini Servlet

“queues” data bound

for client local storage

Jini/HTTP MIDlet

Wireless non-Jini client

HTTP request

HTTP response with queued data

3. Wireless non-Jini client makes periodic HTTP request to get

data from TCP/IP feed

3a. JSB and client can

communicate via TCP if the client

supports it

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 servicepublic boolean startService(Vector msg);public boolean stopService(Vector msg);// fetch something from this servicepublic String getInfo(String key, String parms, Vector msg);// send something from this service, return truepublic boolean sendInfo(String key, String parms, Vector msg);// open a TCP/IP connection to this servicepublic Socket openConn(String key, String parms, Vector msg);

// close TCP/IP connection to this servicepublic boolean closeConn(Socket socket, Vector msg);

}

25

Example: find service

Jini Service

Jini Servlet Bridge

Wireless non-Jini client

1: HTTP request to find service of a “moviefinder” type

2: Jini: find “movie” services

3: Jini: here are some services

6: API: initService()

7: return true

8: response back to the client that a service is found to supply “movie” info (returns a “handle”)

Jini Control

4: Jini: give me your class

5: Jini: here’s my class

26

Example: open connection

Jini ServiceJini Servlet Bridge

Wireless non-Jini client

1: HTTP request to open a streaming TCP/IP connection to a service 2: API: openConn()

3: return Socket

4: HTTP response with a “connection handle”

a: in thread, socket read()b: returns data

local storage

27

Example: send data to stream

Jini ServiceJini Servlet

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” 2: socket.writeBytes()

3: return successful write

4: HTTP response that the command was sent okay

a: in thread, keep reading()b: returns data

local storage

28

Example: receive from stream

Jini ServiceJini Servlet

Wireless non-Jini client

1: HTTP request to get data coming back from the TCP/IP stream

a: in thread, keep reading()b: returns data

local storage

3: HTTP response with the streaming dialog from the Pearl Harbor movie: Look out! Here comes a torpedo!Aggh! The Arizona is sinking!

2: Read from 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