www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject JSR 307
Date Fri, 22 Sep 2006 12:08:13 GMT
Is anyone looking at JSR 307, the new mobility ApI stuff?
http://jcp.org/en/jsr/detail?id=307

"This JSR provides two APIs: one to establish packet data sessions with 
particular attributes such as bandwidth, latency, QoS or destination APN 
(for GPRS) and another for providing a framework for managing network 
mobility for mobile platforms and applications on those platforms. Data 
control and network mobility control are linked together because many 
use cases for the data capabilities in this JSR also include operations 
that need information about the available networks (to determine what 
services to offer to the user)."


I dont really want to add any extra workload, but think it is utterly 
wrong to not think about J2SE needs in this area.

"3 The Executive Committees would like to ensure JSR submitters think 
about how their proposed technology relates to all of the Java platform 
editions. Please provide details here for which platform editions are 
being targeted by this JSR, and how this JSR has considered the 
relationship with the other platform editions.

The target platform is the MID Profile on Java ME"


Every time your laptop has to have its proxy settings changed as you 
move from work to home, every time your Java app hangs because the DNS 
address of a machine changed or because the network went away without 
telling you, its because there's no consideration of network awareness 
in J2SE applications.


1. Java RMI needs to become aware of network state changes.
2. all server-side applications need to be offered the option of being 
notified of network adapters coming and going, so they can re-listen on 
new devices.
3. J2SE DNS support needs to stop assuming that an nslookup is eternal. 
I know it makes sense for applet security, but its time to move on and 
recognise that outside of applets, IP addresses change over the life of 
a long running client or server application.

In the PC business (and Geir probably has those numbers more accurately 
than me), we see the following trend
  -the primary machine for business and home users is becoming a laptop, 
with the server being the place that applications get deployed. The main 
exceptions to this are embedded clients for specific workers, and living 
room/home entertainment systems. Even server-side, the push towards 
adaptive and self-healing applications creates pressure for adaptive 
networking infrastructure in which a network partition is a transient 
event, rather than something requiring a system reboot.

The fact that J2SE/Java EE doesnt have any real network awareness API 
(there is an offline operation exposed only to JWS, and some slightly 
more flexible proxy support in Java 5) means that Java client 
applications dont work reliably on laptops, and server side apps are 
more brittle than neccessary. Presumably, the fact that Sun doesnt make 
laptops makes them unaware of these issues, and the mobile phone vendors 
arent going to care about laptops either. That leaves it to us.

If nobody wants to get on the commitee, the least Apache can do is 
provide some feedback at this early stage about why desktop and server 
side Java must not be left out. I will do it, unless there are other 
volunteers.

Comments?

-steve

Mime
View raw message