JSR 307

[Steve Loughran <st...@apache.org>]

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

Re: JSR 307

[Steve Loughran <st...@apache.org>]

Steve Loughran wrote:

> Vista: Better than WinXP, they say :)

see http://www.microsoft.com/whdc/system/pnppwr/powermgmt/PM_apps.mspx

-Notice how the APIs are all C-level and not in the C# space.
-there's a new state, "AWAY_MODE", which is effectively "pretending to 
be off"; you can do work there, discreetly. Its for media centres and a 
spam relays, I guess.
-there is a test tool to put the system through various states, but that 
comes in the (paid for) DDK, so isnt freely available.

Re: JSR 307

[Steve Loughran <st...@apache.org>]

Geir Magnusson Jr wrote:
> 
> Steve Loughran wrote:
>> 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.
> 
> Plus, your operating system is probably really crappy too.

WinXP dates from 2000/2001, when wifi was a premium thing and bluetooth 
completely unsupported. You can see design decisions that were barely 
valid then are obsolete now. Maybe vista will fix it, but my laptop will 
migrate to linux -probably ubuntu linux- before then

> 
>>
>> 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.
> 
> Hm.  What would you want it to do?  Any stateful connections *should*
> terminate, right?

Yes, but your app could know to stop listening when one adapter goes 
away, to listen on a different port, or to do something when the IP 
address of the NIC it is bound to change suddenly. I certainly know rmi 
doesn't like the latter.

> 
> What to do isn't entirely obvious to me - how do you distinguish a
> termination of a connection due to mobility factors, vs plain old failure?


Now there is a thought. in a mesh world everything is just a possibly 
transient network partition.

> 
>> 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.
> 
> Maybe. I don't have any numbers right now (I'm in yetanotherplane), but
> I wonder.  First, I resent being chained to a laptop sometimes - limited
> power, small screen (compared to the big beautiful things we can find on
> desktops now).  But then I resent also the fact that my data isn't
> easily movable.  (Web3.0!)
> 
> The other thing is that with decent bandwidth and virtualization, I'm
> fairly convinced that we'll return to apps deployed on the client, but
> in a dynamic manner.

Perhaps virtualisation removes some of the system inconsistencies that 
make classic client apps deployable, but they dont reduce your 
management costs.


> 
>> 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.
> 
> Yes, but given how startled and uncomfortable my windows box gets when
> anything - anything- changes...  maybe the java platform is a good place
> to start, but I worry what can be done if the underpinnings are soft.
> Java needs to be able to promise that any JRE can offer the same
> facilities...

Usually Java promises less than the platforms offer. But what do we have 
today:

WinXP: SENS (COM+) events to notify apps of network state changes, 
WM_POWER broadcasts to notify windows of power events, API calls to poll 
power, API calls to enum and poll NIC cards.

Linux: some adaptiveness. Its improving, anyway.  With state published 
in /proc, you could probably read it without needing any JNI libraries. 
bluetooth support is built in and easier to code against than windows, 
even if some profiles (headsets) are still unimplemented.

MacOS: I hear their Java is very adaptive, handles proxy transitions &c.

Vista: Better than WinXP, they say :)

> 
>> 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?
> 
> Well, we can certainly comment on this, or even start out own SE JSR.  I
> do think that we'll be boiling the ocean if we do try both ME and SE at
> the same time.  There probably is a lot of learning we can do though
> from the ME people.

They inevitably have different goals, presumably to enable interesting 
mobile apps. And to do that, the apps need to know when the devices are 
in wifi mode and data is free+fast versus slow-and-possibly-paid for.

I have some former colleagues who work for a little startup bought by 
nokia; they have an interesting view of the future.
-outside the UK, few mobile telcos have lock down on handset purchases 
any more.
-the handset vendors are looking to a world of unlimited data xfer
-the telcos are still trying to retain value add, but their tax on every 
packet is a barrier to fun devices. Look at how the data cards all come 
with 'no IM', 'no Voip' restrictions, to see a losing battle in progress.
Java APIs that let apps know when they are in a data rich hotspot and 
can do fun things help both the handset vendor and the service vendor, 
that being one direction they want to go in.

For laptops, we have that perennial power struggle
  -Sun resent having the chore of supporting Java on windows, and, with 
no laptop line of their own, aren't motivated to
   work on the problem.
  -Microsoft resenting java and have no incentive to make it more mobile.
  -Apple do see strategic benefit in a more mobile Java SE, but do it 
behind the scenes with tight MacOS integration.
  -PC OEMs staying out of the whole game
  -Linux developers and Java developers not well integrated.

Maybe we should do a Java SE mobility/power API. And target 
Harmony/Kaffe first :)

-steve

> 
> geir
> 
>> -steve
>>
>>
> 

Re: JSR 307

[Geir Magnusson Jr <ge...@apache.org>]

Steve Loughran wrote:
> 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.

Plus, your operating system is probably really crappy too.

> 
> 
> 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.

Hm.  What would you want it to do?  Any stateful connections *should*
terminate, right?

What to do isn't entirely obvious to me - how do you distinguish a
termination of a connection due to mobility factors, vs plain old failure?

> 
> 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.

Maybe. I don't have any numbers right now (I'm in yetanotherplane), but
I wonder.  First, I resent being chained to a laptop sometimes - limited
power, small screen (compared to the big beautiful things we can find on
desktops now).  But then I resent also the fact that my data isn't
easily movable.  (Web3.0!)

The other thing is that with decent bandwidth and virtualization, I'm
fairly convinced that we'll return to apps deployed on the client, but
in a dynamic manner.

> 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.

Yes, but given how startled and uncomfortable my windows box gets when
anything - anything- changes...  maybe the java platform is a good place
to start, but I worry what can be done if the underpinnings are soft.
Java needs to be able to promise that any JRE can offer the same
facilities...

> 
> 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?

Well, we can certainly comment on this, or even start out own SE JSR.  I
do think that we'll be boiling the ocean if we do try both ME and SE at
the same time.  There probably is a lot of learning we can do though
from the ME people.

geir

> 
> -steve
> 
>