Is BEA preparing for something totally else?
Wednesday 14 December 2005 @ 8:21 pm
Filed under:

During a session at the JavaPolis, hosted by Sun and BEA, a few carefully placed sentences attracted my attention. The Vice President/General Manager of the BEA Workshop Business Unit aka Bill Roth mentioned that 75% of preparing WebLogic is put into the effort of making WebLogic scalable, extensible etc. So why not open up WebLogic for other upcoming languages!

The ability to deploy applications implemented in PHP/Ruby or even .Net onto the WebLogic application server could open a whole other revenue stream for companies like BEA. These companies have already put a lot of effort into the application server space but are feeling the heat of competitors like the Apache Foundation and JBoss.

Opening up WebLogic to other languages would be a logical step into the evolution of WebLogic!

— By Marco Pas     PermaLink

9 Responses to “Is BEA preparing for something totally else?”

  1. Bill Roth Says:

    Thanks for the plug. My point was that 75% of the surface area of an application server is dedicated to things like reliability/availability/scalability and only 25% is about language/vm support. I merely speculated that if you built a sufficent interface between the two “areas” you could then add support for other languages/environments.
    To be clear, this was my observation only and not a reflection of any official BEA product strategy.

  2. Marco Pas Says:

    Thanks Bill for clearing up things. But wouldn’t it be nice to run PHP/Ruby or whatever languages ontop of the WebLogic server :) I personally think it would be very nice to see. My previous experiences with WebLogic in regards to Java are nice so let’s port that towards other languages then :)

  3. Jesper de Jong Says:

    One of the things that Graham Hamilton from Sun told us this morning is that Java SE is going to have support for scripting languages (JSR-226). Mustang will have support for JavaScript. I guess other scripting languages will follow quickly. That would make it easy to run PHP from a servlet, for example.

    He also hinted at something we might get in Java SE 7 (Dolphin): special bytecodes for dynamically typed languages like Groovy and Ruby. There’s no reason why you couldn’t run bytecode which was produced from a Groovy or Ruby source file in Weblogic, is there?

  4. Jesper de Jong Says:

    I meant JSR-223 (not 226), Scripting for the Java Platform:

  5. Bill Roth's Blog Says:

    JavaPolis Notes and a clarification

    My notes from day 1 of JavaPolis 2005, Europe’s largest Java developer show.

  6. Bill Roth Says:

    Quick question for the readers of this page: Which languages would you like to see? Are Ruby
    and PHP? What else?

  7. Marco Pas Says:

    Bill, would I personally would love is PHP. Next to Java I believe there is no larger open source community then the community driven PHP enthousiasts. So my choice has nothing to do with a technology perspective but is more or less driven by a community.

  8. Danny’s Blog » Blog Archive » Says:

    […] BEA’s Bill Roth (vp of the BEA Workshop Business Unit) hinted at JavaPolis and later in his blog and a LogicCMG blog at the possibility of WebLogic server supporting other languages than Java, like PHP or Ruby. I think this is an interesting idea. If, for instance, Ruby or Rails applications could be deployed to a WebLogic server, maybe you could use data sources or JMS queues from within Ruby code, or even call EJBs. You could profit from WebLogic’s scalability. Another advantage I see is that with BEA ‘supporting’ Ruby, it would be much easier to use Ruby in a corporate environment (that is, if they use BEA in the first place). BEA, bring it on! […]

  9. Stephan Janssen Says:

    The keynote from Graham Hamilton is now also online available @
    Enjoy :o )

Leave a Reply


Sha256 mining

Blog Categories

Browse by Date
December 2005

Upcoming Events

Monthly Archives

Recent Comments


XML Feeds Option

Get Firefox  Powered by WordPress

code validations
Valid RSS 2.0  Valid Atom 0.3
Valid W3C XHTML 1.0  Valid W3C CSS