Skip to end of metadata
Go to start of metadata

javax.naming.Context code seems to assert javax's role in EJB paradigm. The javax Context package plays a vital part in establishing EJB client-to-server connection. But is javax Context derived from EJB concept or is it merely a coincident in playing the vital role of connecting EJB clients to servers? We can look at the code of core EJB essence to answer that question. 

The server on android phablet, success in deploying
 EJBs with JNDI names listed.
The client on android phablet, success in getting EJB
context and invoking methods in the supercomputer server.


 The phablet has a "fullscreen" free app so that it gives a comfortable viewing size for the terminal program "Terminal IDE".

The phablet has a chroot directory of Fedora 19 ARM. When log in with X server, XSDL, from the same phone, the screenshots are these,

First starting XSDL then mate-session desktop
from android Terminal IDE.
The chroot mate-terminal javac The chroot EJB server in wallet phone The chroot EJB client in wallet phone



. The chroot is started based on startfedora.sh , credit to Ingvar from http://ingvar.blog.redpill-linpro.com/2011/05/20/running-fedora-on-the-galaxy-s/ .

And a chromebook can run EJBs in chroot with fedora19 thanks to crouton project's enter-chroot script and fedora-cloud's small image. The chroomebook jboss-as works as these pictures,

Cloudbook chroot starting Xorg and gnome Cloudbook with fedora19 chroot Cloudbook EJB server and client




, if you can partially swap fedora19 cloud image's /usr/share/X11/ synaptics/touchpad configs with http://craigerrington.com/chrome/x_alarm_chrubuntu.zip to get touchpad working.

The cloudbook can act as a X display only for the phablet as the following pictures,

EJB server/client working in ARM phablet displayed
by cloudbook. It's recognized as an android device
even though the display is rendered in cloudbook.
Fedora19 ARM does not have flash plugin for firefox.
But, fedora19's firefox browser supports html5. So,
some youtube videos, such fermilab's video about
higgs, plays OK.



And what do we have now? The confidence that EJB's ubiquity warrants the general public's consensus of best practice in coding EJB. It's not just about community or standard.

Conclusion

I doubt Eclipse and/or NetBean can help organize developer devices for EJB programming and Java programming in general. The development cycle includes testings, on the road or on the go. When a keyboards is absent, the testing environment should shift to the phablet cloud automatically with lest synchronization points. That means jar files, source files  should have 1 copy in a cloud provider and one copy in the phone's disk. When a developer sits down at a table/desk to type on a keyboard, the chrome/cloudbook should have access to the phone's disk.  All these kinds of work requires setting nfs, and windowing displays. More complicated yet, when the phone moves in and out of LAN and 4G, and acting as a hotspot itself, the cloudbook should follow the move and shift cloudbook's Internet traffic to the best route while keeping access to phone's disk at all time. That requires automatic firewall adjustments on the phone. The cloudbook can be assigned different DHCP IP addresses beyond the phone's control.

Beyond the limitations of IDEs , we can draw parallels between EJB evolution and consumer computer evolution. EJB, encompassed in programming, has some of its jobs covered by javax, and MS Windows, encompassed in computer quality testing, has some of its jobs covered by linux. A diagram can help illustrate this parallel. 

To a certain extend, the parallels maybe can be drawn against Android too. When you emphasize programming to an extreme, it becomes pervasive and obscure platform and/or operating system. 

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.