Daniel Brookshier's Blog

Jini Archives

Save P2P by stopping the INDUCE Act.

I just received an email from Ray Gao of P2PJournal.com. Apparently the lobbyists are at it again. This time your MP3 player is at risk. This also opens the door to a lot of other anti-P2P shenanigans from other companies. The INDUCE Act is just plain bad to the bone.

But first, let me say that I am 100% legal. I don't steal music. I buy a lot in fact (you gotta see my iTunes bill). Stealing is stealing. But the music industry wants to stamp out fair use. That's why I am hot about this issue.

Please take a look at this anti-P2P bill currently being proposed at the congress. And, sign the petition oppose it. Tell your congressman that this bill should not become a law.

I just sent a free fax from the site urging my reps in Congress to stop the INDUCE Act. Convincing even a single Senator will force a real debate on the bill.

Check out: www.savetheipod.com which will allow you to fax congress with a few clicks (I used auto form fill on my browser to do most of the work).

www.savetheipod.com has more info about the INDUCE Act and a form to fax your Senators and Representative. It only takes a few seconds to send a fax and it is really important that we respond to this legislation quickly.

Take a look at www.savethe.com for more information and details on the lobbyists and specific congressmen that are paid to be lobbyists lapdogs.

JavaOne - Day Three - More friends, JXTA, epackaging of an app server and open source

Greetings!

We can't solve problems by using the same kind of thinking we used when we created them - Albert Einstein

I got to attend Brad Neuberg's tech session on P2P Sockets and Paper Airplane. Paper Airplane is a Mozilla plugin written with JXTA. It is a great example of extending a known metaphore into the P2P world. Brad talked about a shared Wiki and other services like SOAP via the JXTA network. Check out http://p2psockets.jxta.org/ and http://paperairplane.dev.java.net/ for more info. I really think this is a great way of doing things. There is a freedom from servers and a freedom to communicate. There are a few things to work out, but Brad has a lot of great ideas in this area that need to be explored.

Email==Face

Got to meet more people today. From the JXTA community, to my book readers, to business customers. Most I have never seen or talked to except via email. Some of these people have been emailing me for years and this is the first time I have seen them in person. JavaOne is getting to be a watering hole where everyone meets. Forget the sessions, it's about meeting the smart people of the world in person.

UML

I also got to teach a short class on UML today for NoMagic and ExitCertified (Sun's education partner). I had room full of people willing to learn UML and we had some fun too. Speaking of UML, I overheard someone say that the white-board is the best place to do UML. All I have to say is that is misleading. Using a white-board to think about a design is nice, but you need to capture the design for the long run. A white-board can't be emailed to your customer. A white-board can't be filed away to be referenced years later by a maintenance developer. You can't edit the same white-board to change the design over the course of ten years of maintenance. Use tools, free or otherwise and be a professional.

Creating an Artificial Einstein with JXTA

One of the more visionary people I met today (well... yesterday because it is now 2:00am) was Jeff Zhuk of ITS Inc. Jeff is using Open CYC and JXTA to create a distributed knowledge system and expert system. How cool is that? I have done similar things, but Jeff is going for a massive solution that integrates thousands of people to build an expert system via peer to peer computing. In addition, Jeff teaches Java, JXTA, and JINI. He has all the pieces and is looking for help.

Einstein and Java Enterprise Server

Spent the morning at Sun looking at Java Enterprise System (JES). JES is a new way to deploy and license the infrastructure of an internet business. Sounds innovative, but I would say it just shows that there are finally some smart people at Sun thinking about doing things right. JES is built on the idea that most portals are really built of a dozen or so applications like the portal application framework, web server, application server, calendar, email, instant messaging, LDAP, single sign on and many others. All of these pieces are usually put together one at a time and with a lot of work dedicated to getting them to actually work as a single unit. My past is littered with the with the wasted and long hours or complete failures because of applications not mixing well. What Sun has done is create a clean integration of all of these tools that runs smoothly and is tested as a unit to discover integration problems. The end result is a lot of the core business software is up and ready to use in a few hours. Think about the Integration of all the software components that make up the infrastructure. They are like building an airplane from little pieces and a blueprint. Instead, JES is a fully assembled and tested Lear Jet.

Like I said, not really innovative, but it takes a lot of work and politics to integrate all your standalone products into a single install, with a single interface for management, and one application to license, and get maintenance agreements on. My hat is off to the guy that proposed such a departure in the Sun way of doing business.

But now to the second part of the innovation of JES that might give JBoss a run for their money. The JES set of componenets in the common install management tools is available with a cool procing model. Think about having it all with a portal application framework, web server, application server, calendar, email, instant messaging, LDAP, single sign on and many others for just $100 a year per full time employee. This is just the business model for pricing and not some magic number that is part of the CPU count, the number of gigabytes of storage, email accounts, your first born child, and a chariot that turns into a pumpkin at midnight. The key is that this is just a way to price the system, it is not the price for the number of actual users. This just buys support for the tool and your software updates.

This is more cool and obvious if we look at a company that has 100 employees for a cost of 1000*$100 (it is free up to 99 employees but there is no maintenance). Now even though the company bought the 1000 employee license, they can have a million customers and their 1000 employees use the system without any additional costs(except for the pesky hardware). A good example is Google with 5,000 employees and 7 million customers would only need to pay for the 5,000 employee license. The economies of scale look like open source with maintenance.

The tools are all based on open standards, not open source. Seeing and modifying code is not an option. But when you have a good maintenance agreement, the risk and cost of maintaining open source verses a maintenance contract is about the same or better since most of the components are usually used as is and not customized. Because they are tested as a suite, there is even less need for the IT department to be fiddling with code that should be considered infrastructure rather than custom applications. Of course this is still a modular system and you can swap out almost any piece with an open source or commercial alternative (like the application server).

Is Sun really a winner with JES? Hard to say at this point. They have happy customers so far with the first release and a model that is hard to ignore. The application server and all those component parts are newly rewritten and running fast and seem scalable. They could be a market leader in their own J2EE market. Really! Stranger things have happened. Stay tuned.

One more day

One day to go here at JavaOne. Time to pull out all the stops and meet as many people as you can and collect ideas and business cards. Make friends, learn from them, and help them as much as you can. We are all in this together and we are a community. Get out there and make the Java world a better place!

If you already know about a P2P service, is that bad?

They have been lead to believe that P2P applications should not start with any information and should only be allowed to discover things in the network. They fell in love with the idea of discovering treasures by looking in hidden places. Hard to tell if it is wunderlust or just an old idea that stuck in thier minds from old assumptions. The P2P literature has not helped much either because most discussed P2P in terms of searching. This is not surprising, considering that most of the current P2P is oriented toward file sharing where 'all' data is 'discovered'.

The second thing that many in P2P talk about is discovery of a service as opposed to a file. This is what I call a inverse software agent. Software agents usually get passed from computer to computer to do work. The inverse agent is one that you discover some place else and use on your PC to interact with other agents. An example might be a datin service that you discover and then use to interact with others that are single. The inverse agent makes sense, but there is very little support for it. Yes, it is a good idea, but the software and security support is not there. It is thousands of times more efficient to just write and distribute an application rather than a plugin to extend your network capabilities. An application that genericly finds and loads applications is overkill unles it is very generic - at which point it then loses its value. Catch-22.

Making all applications start with a search at a higher level of framwork is also not a JXTA strength. JXTA is multipurpose. It is not partcularly useful as a search tool(at least without a specific type of search). It is not even optimized for searching. Yes, there are search mechanisms, but they are very limited.

There is one area of search optimization that the JXTA team is working on very hard: Finding another computer listening to a pipe address. Simply, a computer that wants to accept information or create a two-way conversation. That’s what most network applications do, so that’s a reasonable area to optimize. That also means that even if we discover the application somehow, we still have the system to discover other computers in a P2P network.

But why throw away the purest view of ad-hoc networking? Well, I am not throwing it away. Just putting it back where it should belong. Applications should be applications - not a service.

Lets talk about the real crux of the argument, the well-known ID and how it is not a violation of a dynamic P2P network.

A Priori ID / Well-Known-ID

I was once taught a Latin phrase that has stuck with me but I have found difficult to follow all the time: “Eschew Obfuscation.” Translated it is simply, “avoid complicated language”. The problem with this sage advise is that when a new technology comes around we get ne buzzwords too. In JXTA, a well-known or a priori ID is an ID that is already known or can be created from known information. The best example of this is an email address. You know your email address, so does your email provider, and so do your friends. Because an email address is usually simple, like turbogeek@ cluck.com, it is simple for any application to require it as a way to identify you. In effect, your email address becomes an ID, plus it can be used for email.

But lets get back to confusing buzzwords for a moment. An ID in JXTA is a URN or Universal Resource Name. URN’s can have many formats, but they are just a unique identifier. The JXTA form of the ID is found everywhere in JXTA from groups to pipes and to identify versions and types of code or data. ID’s are everywhere in JXTA

But where is the discovery or ad-hoc cpability of this P2P system? Mainly in managing the network to discover peers and route messages. The network is created ad-hoc except for a few seeded peers that are used to discover the rest of the network. Beyond that, there is no requirement or preference that peers ‘discover’ information. Thus for well-know identifiers, the network is crreated on the fly to connect peers via an identical ID.

Discovery in JXTA, as I have said, is a little inefficient for data searches. There are many methods for creating efficient searches. I describe one earlier in a prior blog on a six degrees of separation search (a Kevin Bacon network search). The six-degree search used well-known ID’s created from email addresses to create connections between PC’s. Using the well-known ID increased the efficiency of the network.

This finnaly brings me back to the guys that think a known ID is 'not' a way to build an ad-hoc network. You should have seen that the ID is indeed a transiant thing - at least by clients when using an email address. The connection between peers is also ad-hoc and discovered via pipe routing whenever you are mathing peers with identical ID. In addition the ID can be formed to represent any subject, service, location, thing, or person. All you need is agreement between peers looking for the representation. Sounds like well-known ID are the poster boy for P2P.

I Dream of JINI

Perhaps it is the dream of JINI applications that lingers in the P2P purist's minds? If just walking into a room with a WiFi PDA connects you to a local printer is cool, why can't you apply the same thing to P2P? For example, if I log into JXTA, shouldn't it automatically guess I am not looking for a printer?

P2P is not as straight forward as JINI. Realizing that there is a printer is not the same as discovering a service that does printing and thus might be useful. To look at this another way, you could create aJXTA dating service. If we apply a JINI model, a PDA owned by a single person would aoutomatically load the dating service and start looking for a mate. Might be nice, but really a bit of overkill. On the other hand, if I run a dating application enabled with JXTA, I can use data about your likes and dislikes to create an ID that can match you to someone else like you.

The bottom line? Feel free to use JXTA ID’s created from known data. It is not against the spirit of P2P. The well-known ID is also an eligent way to solve many P2P problems. No one will call the P2P thought police. If they do, send them to me and I'll give them your Get out of Jail Free card.

This work is licensed under a Creative Commons License.