A lot of companies began entering the provisioning server market in early to mid 2000, shortly after the MIDP 1.0 JSR approval. In May 2001, the "OTA User Initiated Provisioning Recommended Practice for MIDP Version 1.0" was finalized; and in the same month, JSR-124: J2EE Client Provisioning Spec went into JSR review. A year later, we began to see a consolidation of the provisioning server market. Motorola acquired 4thpass in September 2002 and Sun Microsystems acquired Pixo in July 2003, ceasing Sun's courtship of another major player, Mobilitec. Sun used Pixo's Mobile Download Server as the basis of its J2ME Verified (TM) Program beginning the Summer of 2003. The committee finalized the JSR-124 Specification in August 2003. The market had reached maturity.
I originally started the code for JVending in February 2003, in the middle of the consolidation and maturity phase of the market. I intended to write an article to demonstrate the basics of OTA provisioning and DRM. Due to a hectic schedule that year and to the fact that writing a Java byte-code parser took much more work than I had anticipated, I did not finish the code until October 2003. By February 2004, there were still no open-source implementations of a J2ME provisioning server, so I decided to open-source the original alpha/demo version on sourceforge in hopes of expanding it into a production system.
The primary goal of JVending is to create a system (based upon JSR-124) to allow individual users a way to provision content on a server (or PC) and to have their content available over a wireless network. One aspect of this is to plug the provisioning servers into a P2P network so that we integrate the wired and wireless sharing of content. This would allow a user to share, say an MMS message, from their handheld to their friend's PC or vice versa. This requires building a content system in such a way that it could operate outside of a carrier environment. Carriers have many different ways to block external content delivery including blocks based upon URL, content type and device type. This led me on a path to start looking at how to use J2ME clients and P2P based systems to bypass carrier lock-in. This, in turn, led to my work on the J2ME MMS client during February - March 2004, which demonstrates how to work around the carrier restrictions using J2ME/MIDP 2.0. MMS delivery and provisioning will be an important part of JVending.
During April - May 2005, I did not have much time to spend on JVending, due to projects at work, my JavaOne preparation and personal time constraints. Fortunately, Rashmi, one of the developers on JVending, prototyped and built the stocking of PAR files using Hibernate, which we released in May. This was the first step toward making a serious commitment to JSR-124. In May, JDJ published my article Building A J2ME Multimedia Messaging Service Client. In June, I gave the the presentation "Provisioning and Digital Rights Management"; on JVending at JavaOne 2004 in San Francisco. Toward the end of the presentation, I spent time talking about P2P provisioning and how it can avoid certain carrier blocks. Having worked for a carrier, I know the methods they use to block users from using data services unless the user pays for them. This makes good business sense if applied selectively. It does, however, have an effect on innovation because you may have deployed a popular product or service that suddenly stops working because that carrier decides to close a loophole in the network (which you did not realize was a loophole). One of my early concerns for JVending was a user having a popular provisioning site only to have their IP address blocked by the carrier. For JVending to be successful, it had to take into account this factor. That became the motivating force behind creating a federation of provisioning servers that shared data. JVending is not a P2P file distribution system with wireless capabilities, but rather is a federated, mobile provisioning system that uses P2P protocols to create robustness and availability in the system. This distinction may be meaningless to the user but is very important to the direction and design of the product
Early on (even prior to incorporating P2P), I decided to make DRM a central component of JVending. At JavaOne 2004, I stated that DRM and mobile P2P distribution have to go together, otherwise we could end up with the legal mess of the current P2P system in the Internet space. DRM support has proven to be problematic. In July 2004, I found out that three weeks earlier the US Patent office granted DigitalContainers U.S. Patent No. 6,751,670 for Tracking electronic content. The nature of the patent is sufficiently broad that it appears to encompass viruses and Trojan horses, which predate the patent by more than a decade. On a less humorous note, it also looks as though it may encompass what I was doing with DRM security wrappers, which are the only way to secure the content without needing special software on the device. I decided to turn to OMA DRM which depends on client software, and is a standard in the industry. As of January 2005, OMA DRM is now subject to licensing fees. Due to potential IP licensing and patents, I recently decided to drop DRM support from JVending. While IP protection is important, it means that I have to leave copyright protection off of a content distribution system. A damned if you do and damned if you don't situation.
Mid-July 2004, I tried to get JVending re-started by recruiting new developers and forming areas of responsibility, but this didn't work out for various reasons. So I decided to implement most of the JSR-124 spec and then other developers could code to the API, which is well documented. I was prepared to do a major release in early September 2004. After demonstrating JVending to a former coworker of mine in August, he got excited about the idea and asked me to hold off open sourcing and to consider commercialization. The P2P distribution could solve some of the bottlenecks in content distribution that exist in the industry. In September, I was convinced enough that I began to work on a commercial version of JVending. I put the MMS integration work on hold and began focusing on stabilizing the core provisioning components surrounding JSR-124.
With a couple of other guys, we worked on the business plan for commercialization. However, after doing more research, we found that the provisioning space was so competitive that we decided to drop the idea in November of 2004. I began working on completing an open source version. This brief stint at commercialization did realize definite advantages for JVending. First, I rewrote the stocking code and created a proper stocking API based upon filters. Second, I built the XML configuration files for easy deployment. Third, JVending now supports web services. This happened by chance since a developer, who was willing to donate his time to work on the portal only knew .NET. So I set up a web service interface as a way for him to query the catalog from a .NET server. Fourth, I built a PPG adapter, which is an absolute requirement for carrier deployments. With a little tweaking, I got the PPG adapter hooked into the peer network, so you can now send mobile content directly to the device (provided some peer on the network has access to a PPG).
In early December, I recognized a crucial problem. I had designed the peer content distribution for a closed, trust-worthy corporate environment. JVending could not handle large PAR file downloads in the wild. There was the possibility that someone could issue multiple searches to the provisioning server causing a denial of service. I needed some way to deliver large amounts of data between provisioning servers and decided to integrate BitTorrent into JVending. On December 14th, the MPAA began shutting down the BitTorrent servers, so I put aside the integration work and began designing a similar system (without centralization) that was more tightly integrated into JVending. I cleaned up a lot of the P2P code and created the federation API. There is still a lot of work left to handle distribution of large files, but once that is complete, you will be able to shift the entire content base of one content provisioning server to another provisioning server.
In January 2005, I established the primary goals of JVending as expanded P2P support and JSR-124 compliance. Sometime in May of 2005, I started thinking about how to port JVending to run on CDC. Coincidently, the Project JXTA group released a CDC version of JXTA, so in June of 2005, I decided to start work on on a CDC port of JVending. As part of this, I attempted to start a JXTA Content Repository Spec, to define an embedded version of the spec; but this never got off the ground due to lack of interest within the community.
A short time later, I became frustrated trying to modularize JVending to make it easier to port to CDC. The problem was that JVending was too monolithic. When I built it, I encapsulated as much as possible to give me the flexibility to make changes. However, the encapsulation of DAOs, config files, and various objects made it difficult to swap out implementations (like JDO for Hibernate). It also made unit testing difficult.
In July of 2005, I needed the registry and configuration components from JVending for an embedded device project that I was working on, so I stripped out the components and Registry-CDC was born. I was also never particularly happy with the ANT builds that I had for JVending; and by this time, Maven had me completely hooked. The ANT build always felt like an embarrassing, smelly part of the project, so I decided to drop the JSR-124 compliance and P2P goals and migrate all of JVending to Maven. I gave it a couple of attempts with the code base, but it was a huge task.
After these frustrating attempts to clean up the build and modularize the code, I decided to take a break and to develop an embedded JXTA Content Repository in Ruby. Don't ask me what was going though my head, and why I thought this was going to be easier, but at the time it seemed like a good idea. The first thing that I needed to do was a to create Ruby JXTA bindings for support on a mobile device. That led to another interesting project that started to turn my attention away from JVending and Java (see the following blog for some idea of what I was thinking at the time ). Unfortunately such a project was going to take some dedicated mental effort, which at the time I could not muster with my work schedule; so I dropped the idea in September of 2005, although I am still working with Ruby and very likely will approach this project in the future.
In October of 2005, I decided to take baby steps toward my goal. I realized that a lot of complexity within JVending was with the configuration and DAOs, and I particularly needed to get the DAOs pluggable because there is no way the existing Hibernate implementation would port to a device. So I continued to work on registry-cdc and registry-j2se. I also started stripping out other non-essential projects. You will also find the WAP/Push-Initiator projects are mavenized builds of the old wap-push code. Finally, in November/December, I dumped the higher-level application components, like the portal and JXTA, and was left with something modular that I could build on and customize.
So here we are at provisioning-j2ee 2.0.0-Alpha1 release. This is very much a developer release and will continue on smaller releases cycles, as I don't think that annual cycle cuts it. The current goal for JVending this year is simple: pass the JSR-124 TCK. After that, I will add in additional functionality like the JXTA federation, Web Services and a CDC port.