Pramati first to implement EJB 2.0 PDF2 Local Interfaces


News: Pramati first to implement EJB 2.0 PDF2 Local Interfaces

  1. At Java One last week, I was surprised to see a demo from India's favourite application server vendor: Pramati Technologies. In this demo, they built, deployed and ran fully EJB 2.0 PDF2 compliant entity beans (including local interfaces!!).

    Congragulations Pramati, its refreshing to see someone beat BEA at API support once in a while. :)

    EJB 2.0 Compliant Pramati 3.0 is still in Alpha mode, their schedule release schedule has not yet been determined.

    Check out Pramati 3.0 Server.
  2. First?

    Come on, Floyd, get your facts straight. I would settle for a tie :-)

    More seriously, I talked with the Pramati guys, and yes, I was impressed. Good job there.


  3. tie?

    May be for full EJB2.0 :), but not for local interfaces.

    Anyway, thanks for your wishes.

    I think PDF2 should be read as proposed final draft 2, just to avoid any ambiguities.

  4. Uh? We shipped local interfaces in WLS 6.1 at the opening of JavaOne.

    Feels like I'm back in high school :-D
  5. Uh? We shipped local interfaces in WLS 6.1 at the opening of JavaOne.

    Oooopss!! Damn, not good for me to be uninformed then.. :) Cedric, keep me posted on these things. :)
  6. I checked out the Pramati stuff, too and it was pretty cool.

    Jumping on the BEA bandwagon, though, I would point out that it probably is a tie, if not an edge in BEA's favor. After all, Pramati 3.0 is in alpha mode while BEA WLS 6.1 is in beta mode with GA scheduled for some time in July.

    So, technically, both companies announced at the same time with (likely) equivalent beta implementations in the local interface space. But, you should probably point out that Pramati 3.0 is a beta of all of their EJB 2.0 stuff: not just local interfaces but CMP & MDB, too. WLS 6.1 is only beta-ing local interfaces, automatic table generation for CMP entity EJBs, read-mostly caching across a cluster for entity EJBs, DB PK generation with CMP integration.

    So, despite this timeline finagling, the Pramati stuff is pretty cool from an EJB perspective and I'm glad to see that other app servers are aggressively pursuing EJB 2.0 PFD2.

  7. I interpret this primarily as a suggestion to other commercial vendors that they release public alphas as well, or adopt the "release early, release often" credo of open source. I do like Pramati, and WebLogic as well, but a demo of an implementation of local interfaces hardly represents any sort of technological one-upsmanship. On this particular issue: Most vendors have had technically "illegal" local pass-by-reference optimizations since EJB 1.0, and I would suspect few have had much trouble wrapping it behind the new API (it's in our own JRun 4.0, so it must be available in our more prestigious counterparts).

    Of course, it's the entire product and not merely the technology that matters to companies looking to commit to an enterprise platform. I think this is the reason that WebLogic dominates even when its technology isn't necessarily the best or first in every area (good stuff, but not the best or first in every area -- clustering in Gemstone vs. WL, for example, or interoperability in Borland App Server vs. WL, or deployment and client invocation subsystem in JBoss vs. WebLogic). WL's business, user ed, and tech cycles are so tightly in sync that theirs may be the best overall product even when specific technologies meet stronger competition. Maybe this product mindshare is why beating (or tying) them to an API implementation seems so surprising. I have so much respect for Cedric and team, though, that I'll admit even I expect them to be first to market with new stuff -- even though at this point BEA, like Microsoft, is probably one of the few companies that can afford not to be first to market and still not worry about loss of developer mindshare.
  8. I am glad to see that this bit of competition is bringing all the best minds from the different vendors together. :) Sean, I really liked your article in Java Developers Journal, thanks for mentioning and Mastering EJB. Much appreciated!

    Sean, Cedric, I agree that being first to implement local interfaces does not make one team superior to another, particularly given that many vendors have had local call optimizations such as declarative flags for toggling serialization. However I was just really impressed that Pramati had working code that actually used PFD2 local interfaces.

    Perhaps my surprise was due to the fact that this event broke the paradigm I have been accustomed to, the paradigm of BEA consistently being the first to implement the API's (obviously due to the hard work of Cedric and his team), be it in beta or what not. In that spirit, It was a pleasure to give Pramati credit where credit was due, and let other vendors know that there is still hope. :)

    Sean, as the Buddhists would say, acquisition of wealth causes more stress because once one has wealth, he must continually worry about losing it. To counter your last statement, I would say that because BEA is on top, this makes it more important than ever that they continue to be first to market, not to maintain *marketshare* (for the reasons you stated) but to maintain developer mindshare. Developers respect and lookup to companies that implement the specs first, giving them the tools and toys they need to keep their skillsets up to the latest cutting edge advancements in J2EE.

    That said, part of BEA's marketing strategy has been "announce early, release early, announce often". Having been reading all these vendors press releases every day since TSS was launched, I can tell you that this motto is probably one of the most powerful (and least utilized outside of BEA) tricks up a J2EE vendors sleeve. It is probably the definitive way to get developer mindshare, which translates to marketshare when developers have influence over their managers product choices.

    I can tell you that I have probably posted more BEA press releases on TSS than any other vendors, but this is simply because BEA spits out more press releases that are of interest to developers. Sadly, I rarely see announcements from Allaire/Macromedia, IBM, Pramati, etc, and I monitor the wires for news from them daily.

    Well, enough of my marketing rant, I just can't stress enough how imporant it is to public perception for the production team to maintain close communication with their marketing folks. So far, BEA has been the only one that gets this.
  9. While BEA isn't the only company who understands the value of keeping the business and techncal cycles in sync, I certainly agree that they've done the best job of it in the J2EE app server space. I'm sure you're quite right about the lack of comparable press releases from many of us. Since you mentioned my company by name: Macromedia does a good job with this sort of thing on the Flash and tools side, but it's true that the general public (heck, even our competitors!) didn't seem to be aware that we've also had a full J2EE server for more than a year. So your point about lack of marketing in the J2EE area is well taken. Perhaps part of the issue is that some of us are aimed more directly at the ISV/OEM market, where we're often re-branded. But that strategy would make for a very uninteresting tangent not directly relevant to your remarks.

    Suffice to say I admire the success of WebLogic as a product, and agree that it's something of a minor event when one of their competitors manages to out-announce and out-release them to an API -- which is a testament not to their technology per se, but to the technology as a complete product.

    Thanks for your compliments on my JDJ article; I mentioned you guys in my JavaOne session as well. So: Pramati, WL, and TSS -- nice job all around!
  10. and I would suspect few have had

    > much trouble wrapping it behind the
    > new API

    You would be surprised... Though innocuous-looking, the implementation of local interfaces has a whole lot of quirks associated to it, like the fact that you are now bubbling up two kinds of exception depending on the kind of object it emanated from. Realize that these come from the guts of the server and you will get an idea of the tricks you must use to get there.

    Thanks for the kind words, though. We'll do our best to keep surprising you ;-)

  11. Thanks for the warning Cedric, but we'd already handled the intricacies in JRun's original illegal/value-add management of local pass-by-reference (which wasn't a mere metadata element), so handling them for the new API more or less meant re-adding what we'd previously ripped out for CTS 1.2. The same goes for much of the value-add we'd previously had to pull (such as our pre-MDB) that now have more legitimate standards-based lives and can be re-added. Still, as Floyd pointed out, what matters is the quick release, which you guys do very, very well.

    Sorry I missed you at JavaOne, but congrats on a strong presence there. I'm still toying with IONA at the moment, but will give your work in WL 6.1 a try shortly.