Category Archives: JXTA

JXTA

Java, JXTA, oponia

Face Time with JXTA and Shoal Engineers

1 Comment

The second day at the show was a little more of a grind than the first. Aching feet and all that. But the reaction was still overwhelmingly positive. I had more of a chance to have some chats with the JXTA team and also with one of the people responsible for the Shoal project.

It seems the JXTA team is pining for a new book on JXTA and at least one person suggested I write it! (Uh… yeah… in my plentiful spare time!) I must admit it’s tempting. Another temptation to consume time I don’t really have came from a Shoal engineer interested in a) integrating Shoal with Spring for declarative clustering of Spring apps, and b) using this method to cluster JXTA super-peers (that was actually my idea, since our super-peers are Spring apps.)

Finally someone from Sun’s ISV Engineeering team was very enthusiastic about the idea of us porting our app–or some variation on it–to SavaJe, and since we’ve been considering a mobile version, it’s definitely worth a look-see.

We’ve met a lot of our goals for this conference, so the last day should be pretty easy-going. As Leigh says, the last thing we’re hoping for is a visit from a Java Rock Star.

Java, JXTA, oponia

“Wow. Cool…”

Leave a comment

We heard a fair bit of that yesterday here at the oponia “pod” in the Java Playground @ JavaOne 07. We’ve all become pretty slick at giving the demo and Leigh is mastering the art of snagging total strangers and forcing them to watch it. Most of them end up being glad they did. Another thing we’ve been hearing quite a bit is: “hey, this actually looks really useful.” Umm… yeah. We kinda planned it that way, but we’re glad you agree. 😉

We had some pretty stiff competition for attention from the singing, dancing Robosapiens, the world’s fastest robot, and a Java-powered submarine. (It is a playground, after all.) Many thanks to Mike Duigou and Henry Jen for their fabulous demos of oponia’s ucaster in the JXTA pod.

I didn’t get to look around too much myself, but the coolest thing I’ve seen so far (besides the Robosapiens) was the Sunspot programmable sensor technology. Maybe today Mark and I will go find out what Nokia and Motorola are doing here. Well, we’re due back on the floor in a few minutes so… more later.

Java, JXTA, oponia

oponia at JavaOne

Leave a comment

I’m thrilled to announce that we (oponia networks) will be premiering our “hyper-simple” sharing and collaboration platform at JavaOne this year. You’ll find us in the Java Playground in the Pavilion from May 8 to 10.

More info on the product will be available before the show (our team is working frantically on the material now), and I’ll post again when it’s ready to share.

I’d like to say a very special “Thank you!” to Bernard Traversat and Stephanie Kaul of Sun for providing us with this opportunity to showcase our JXTA-based product in such a great venue. Hope to see you there!

JXTA

Why Spring?

1 Comment

Mark Petrovic asks: “Can you say a bit about why you are using Spring in this overall context?”—referring to my earlier post on configuring JXTA with Spring.

I suppose the reason is that over the last few years I have written several servers, mostly experimental prototypes. I quickly got tired of writing and maintaining the large amounts of “glue” code needed in almost every situation: where and how to get application configuration constants and preferences; where and how to specify which implementations of an interface to use in some particular case; etc. Then one day I picked up Rod Johnson’s Expert One-on-One J2EE Development without EJB which, in addition to being a thoughtful critique of Java architecture-as-usual is also a good introduction to Spring.

I built my next server with Spring and have never looked back. In fact, it’s so useful that I don’t consider it only for servers anymore. It’s lightweight enough to use for just about any purpose. Also, if I have to write a web application, I prefer the design of Spring MVC to Struts. And when you throw in the fact that you get declarative transactions and aspects, caching with EHCache, and countless other goodies with virtually no effort, it’s almost too good to be true.

So…I’m writing a fairly complex JXTA application (not a prototype this time) and Spring was the natural choice to make that as pain-free as possible. I hope that answers the question. I’m not by any means a Spring expert. It solves a lot of problems I encounter again and again, but it does a lot more that I haven’t even discovered yet. I will also add that it’s the best designed and written piece of code I’ve seen in many years. Just reading through the source you can learn a lot about how to craft great software.

Java, JXTA

Configuring a JXTA Peer in Spring

4 Comments

Important update: This article is old and out of date. This method will no longer work with the current version of the JXTA platform. I am looking into what changes might be required to the platform and/or the example. I’ll post the results in a new entry and link to it here when it’s ready. I notice many people searching for JXTA+Spring configuration and landing here. Sorry for the inconvenience. VW, 23/07/2008

The new net.jxta.platform.NetworkConfigurator class provides a clean and straightforward way to configure an instance of the JXTA platform without a UI. It can be used programmatically (see the main() method for an example of stand-alone use) or—because it is a Java Bean—declaratively deployed inside containers like Spring.

Here is a simple example of a Spring context file, applicationContext-rdv.xml, which configures a Rendezvous Server:


    
        
        .jxta
        
        2752
        
        
             urn:jxta:uuid-XXXXXXXXXXXXXXXXXXXXXXXXXX...
        
        
        
            uuid-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        
        
           MyNetPG
        
        
            My Infrastructure Group
        
        
        
           com.mycompany RDV1
        
        
           Rendezvous Node
        
        user
        pwd
        
        9700
        9701

And here’s what MyJxtaBean.java might look like, in part:


public class MyJxtaBean {

    private NetworkConfigurator netConfig;
    
    private PeerGroup infrastructureGroup;
    
    public MyJxtaBean() {}
    
    public setNetConfig(NetworkConfigurator netConfig) {
        this.netConfig = netConfig;
    }
    
    public synchronized void start() {

        /*
        * Simplest case, we don't overwrite an existing configuration, nor
        * do we load and alter/ammend it. Only if there is no PlatformConfig
        * available, construct a new one using the bean's properties.
        */
        if (!netConfig.exists()) {
            try {
                netConfig.save();
            } catch (IOException io) {
                System.out.println("Error saving PlatformConfig");
            }
        }
          
        try {
            infrastructureGroup = PeerGroupFactory.newNetPeerGroup();
        } catch (PeerGroupException pge) {
            System.out.println("Couldn't create NetPeerGroup");
            System.exit(1);
        }
    }
}

Now all your applicaton has to do is get the MyJxtaBean from the context and call start() to start the JXTA platform.


    applicationContext = 
        new ClassPathXmlApplicationContext("applicationContext-rdv.xml");
    myPlatform = (MyJxtaBean)applicationContext.getBean("myJxtaBean");
    myPlatform.start();

There’s more to writing a JXTA application, of course, but I hope this example demonstrates how NetworkConfigurator takes some of the mystery out of JXTA plaform configuration, while making it easy to combine JXTA and Spring.

Update: April 10, 2007 Christopher Marsh-Bourdon points out a flaw in this example when used with Spring 2.0.1. It’s related to the specification of the JXTA home directory. You can read Christopher’s analysis of Spring’s FileEditor Anomaly and solution to the probelm here. Thanks, Christopher.

JXTA

JXTA Pipes vs. Sockets

2 Comments

Some people are unsure about when it is appropriate to use JxtaSockets and when it appropriate to use Jxta Pipes (especially the JxtaBiDiPipe). These are a few of my reasons for deciding to choose sockets over pipes:

  • if your messages are (or could be) larger than 64K. Since 64K is the maximum message size for JXTA messages, you’re going to have to chunk them anyway. Why not let the socket layer take care of it for you? The socket code will ensure chunks are reassembled in the right order, and will take care of retransmissions if used in reliable mode.
  • If you need to make sure messages are received in the order they are sent. My understanding is that with pipes messages *usually* arrive ordered, but there’s no guarantee.
  • If you want to handle flow- and congestion-control automatically. With pipes, you’re on your own in figuring out how quickly to send messages, when to back off, and so on.
  • If you have existing code based on java.net.Socket, which you wish to convert or adapt to work in a JXTA network. Just don’t forget that you must explicitly flush() the output stream.

One exception is JxtaBiDiPipe. It has a reliable mode, so some of these reasons don’t apply. A JxtaBiDiPipe is reliable like a “reliable mode” socket, but you still have to do the message chunking yourself. You can use it in place of a socket if you don’t care about having a stream-based interface.

A further complication involves the use of secure sockets created using a JxtaUnicastSecure pipe and the TLS transport. Since reliability, flow- and congestion-control are provided by the TLS layer, you should turn the reliable mode off on the socket in this case to avoid inefficient duplication of effort.

In practical terms, it boils down to this for me: I generally use pipes for application-level protocol messages (usually unreliable JxtaBiDiPipes) and sockets for sending data (usually based on secure pipes, with the socket’s “stream”/reliable mode turned off.)

For a more detailed discussion of Pipe and Socket implementations and some common pitfalls, see “Demystifying Pipes, JxtaSockets, JxtaMulticastSocket, and JxtaBiDiPipes” by Mohamed Abdelaziz (hamada).

Distributed Computing, JXTA, oponia

oponia networks

Leave a comment

Since “What are you up to these days?” is becoming a FAQ, here’s the short answer: I co-founded a technology company called oponia networks. We’ve got some money, some super-smart people, and a cool project on the go. Our lawyers won’t let me say much about what we’re doing just yet, but I can say that we’re developing distributed applications for the consumer and enterprise markets. We think we’re going to change the way people use the web—but then doesn’t everybody say that these days? Heh.

Stay tuned for some more info on the alpha in a few days…

Distributed Computing, JXTA, Syndication

P2P Multicast Feed Distribution with FeedTree

2 Comments

I’ve been interested in P2P approaches to syndication for a while, and FeedTree is a research project offering one solution to the problem. This poster provides a good overview of how the system works. A more detailed technical description is available here.

In a nutshell, an HTTP proxy on each reader’s machine becomes a node in a Pastry overlay network. The node then joins a multicast tree for each subscribed feed, and updates are pushed to all subscribers using the Scribe group messaging protocol. Feeds are either directly published into the network by FeedTree-aware publishers, or are polled by some subset of interested nodes on behalf of all the others. A digital signature can be added to the feed by the publisher to prevent spoofing. Configuring your feed reader to use the proxy is quite simple, in most cases, and then you’re set. Publishing takes a bit more work to set up, at present, but I don’t see why you couldn’t eventually wrap a simple GUI/wizard around this process to make it painless.

I had every intention of giving FeedTree a go before posting this, but here’s the rub: “Step 2: Be sure that your computer is accessible from the Internet on port 29690.” Well, I could have done so, but it would have required re-configuring my entire home network first. I couldn’t justify the effort just to try out one piece of software. I suspect most software end-users either wouldn’t have the permissions necessary to meet this requirement; wouldn’t know how to go about it; or, like me, wouldn’t be sufficiently motivated to take the trouble. Alas, methinks this is a showstopper if FeedTree is to become anything more than a research project. That’s a shame.

The “not even on the napkin” approach I had in my head was based on JXTA, of course (a JXTA-based solution would remove the need to hack your network, making it end-user friendly, for one thing.) Rather than pushing updates to subscribers, I envisioned peers using the Discovery service to advertise and search for feeds. To wit: rather than polling feed A every hour, the peer would first try to discover a copy of the feed less than one-hour old. If none could be found, only then would it poll feed A’s source, and publish an appropriately time-stamped advertisement for other peers to discover. The FeedTree “push” approach provides for more timely updates than this if the publisher injects the feed directly into the FeedTree network. Also, I can see the potential in my scheme to end up with “too many” peers polling for a feed, if their desired polling frequencies are too much out of synch. This requires considerably more thought. FeedTree also allows multiple “volunteers” to poll a feed in order to maintain a certain level of timeliness, but the overall polling frequency is better controlled.

Anyway, I’m glad to see someone doing real work on alternatives to uncontrolled HTTP polling for feeds. Ultimately, though, I don’t see anything gaining wide usage that isn’t dead-simple to install and use, without regard to network topology. (Imagine that you did get FeedTree installed on your laptop at home. As soon as you take the machine to the office, or to school or wherever…you’re hosed. *sigh*) And without mass adoption and seamless mobile usage, no solution will be able to make any real dent in the scaling problem.

JXTA

JXTA Joins The Army

Leave a comment

Via Sun:

Boeing recently selected JXTA(TM) Technology to provide the peer-to-peer (P2P) discovery service for the System of Systems Common Operating Environment (SOSCOE) for the U.S. Army’s multi-billion dollar Future Combat Systems (FCS) initiative.

Although it is a little disturbing that this is the second time JXTA has been mentioned in connection with “network-centric warfare”, it’s also great news for a sadly under-appreciated technology. As Alexis Smirnov points out, JXTA does a fantastic job of making very hard things possible, but simple things are still difficult. Not only that, but so far it hasn’t been heavily promoted by Sun, so that even if you’re an architect with a hard problem that JXTA can solve, you probably don’t know it. Let’s just call it “fashionably obscure” for now, but hopefully not for much longer.