Featured Whitepapers
Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Java in the management sphere, Part 3

Java embraces the future with JMX, Jini, and Jiro

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
In the first two articles of this series, I defined the management space, acknowledged its legacy, and set the stage for Java's entrance into it (see "Read the Whole Series!" below). I also penned a brief look at Java's history and at Sun's pioneering efforts in two technologies -- JMAPI and Java DMK. Those technologies led to the development of Java Management Extensions (JMX), which brings us to present-day Java. In this article, I discuss Jini and Jiro, as well as recap the influence of JMX. But first, here is a speculative look at the future of management applications in general.



You may recall that, over time, management applications become as complex and strategic as the network itself. As each enterprise acquires its own heterogeneous network, management applications have to fill the need exposed by that growth. Moreover, two trends are obvious: everything is getting smarter, and everything is either connected or getting connected to the Web. Thus the typical heterogeneous network is growing dramatically even as its complexity increases.

Figure 1. A plethora of smart, connected devices



Not a week seems to go by without a news story about the newly acquired intelligence of some unexpected device. Intelligent devices -- your coffeemaker, microwave oven, cell phone, automobile, wristwatch, sneakers -- are rapidly becoming the norm. Soon, almost everything we use in our daily lives will be smart by means of ultracheap microprocessors, and they will most likely be connected, and therefore manageable, via the Internet.

It is safe to say that some legacy interfacing will be required for these new devices. What are the other implications of this growth? Beyond the obvious barrage of devices that will require the coding of new managed objects (at the very least), you might one day need a systems administrator to install and configure a third-party MP3 player in the Internet-connected LAN that is your sport utility vehicle. Simply put, by inheriting the benefits of the legacy, we also inherit some of the problems.

Consider this analogy: 50,000 people attend a sporting event in a large stadium. The game is close, and everyone stays until the final moment. All 50,000 people leave the stadium at the same time. From a programming perspective, what model might you employ to most optimally and safely empty the stadium and move each person from seat to exit? Would a central-point-of-control model work best? It would let you analyze the status of each exit, the number of other people in proximity, and the relative cost of queuing. However, this model could not account for the relative physical capability of each person in the stadium, as some people move faster and more efficiently than others. Would a distributed model work better, one in which each "agent" makes its own decision based on its own imperfect, changing information base and rule set?

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources