A few weeks back I was at a customer site talking to them about Java development. The customer had constructed a high performance financial trading platform in Java without the use of an application server. The sales guy I was with couldn't fathom how that was possible. He couldn't grok how the J2EE hammer couldn't drive this particular users nail. This alien idea is something that many of us Java old timers have known for a long time. I mean app servers didn't show up until a few years after the development of Java. The java.net package pre-dates EJBs. I wish this idea would come more naturally to developers' minds when they architect a solution. I've seen many of them get snagged on the barbs of the EJB spec much too often. In fact, I saw another example of this at another customer site the very next week. Here they were trying to shoehorn a market data application into an app server using message driven beans. Oh the humanity! Sometimes folks, it's best to just open up a damn socket and send the int down the wire. Then today I find this article which makes a parallel point about web services and Jini. This article supports my point that you shouldn't approach every problem in the same way and that some of the benefits derived from using these big frameworks (SOAP and J2EE) come with some costs in flexibility, performance, and agility. I was at JavaOne and heard the Orbitz talk. I was impressed. I've never implemented anything in Jini, it wasn't mature enough the last time I did this kind of server side programming, but you can bet your bottom dollar the next time I have to write a service and I control both ends Jini Is going to be part of the solution. That is if it makes sense.