Web App. Server Vendors look beyond J2EE


News: Web App. Server Vendors look beyond J2EE

  1. Web App. Server Vendors look beyond J2EE (5 messages)

    Just like EJB moved out of the spotlight to become a piece of the larger pie of J2EE, J2EE itself will eventually become yet another element of the big picture of Web Development. SOAP, XML, and the Web Services technologies will soon share the spotlight with J2EE in the enterprise arena. Oracle, Microsoft and IBM, are well aware of this. Will Sun wake up in time?

    Read "Web App. Server Vendors look beyond J2EE".
    For more on Web Services, read Understanding Web Services.
  2. This is a very FUD-filled piece.

    "They're overly obsessed with J2EE being the complete environment, when in fact it is part of the complete environment," said Scott Hebner, director of WebSphere software applications for IBM (stock: IBM). "J2EE without XML and Web services is an incomplete environment."

    IBM really shouldn't talk:

    - IBM WebSphere is the most out of date server on the market.
    - IBM chose not to license J2EE, thinking it wouldn't take off as a marketing brand name. Turns out it was a marketing COUP, especially with customers. Now IBM has to explain why WebSphere doesn't have J2EE to pointy-hairs. This probably pee's them off.

    IBM has done a lot for Java, but they need to stop this "Sun is wrong" line. Most of the community agreed with IBM on this during the days of the "rift" in 1998/99. Since that rift sealed, we've seen J2EE launch like a rocket in the marketplace as *the* brand name for enterprise applications development.

    - Sun *funded* the creation of XML.
    - J2EE includes some of the most sophisticated XML parser implementations on the market. How is it "without XML"?
    - I go to www.xaml.org and I see Oracle, Sun, and IBM's logos. No .NET, no Microsoft.

    J2EE servers will need to expose EJB's with WSDL & UDDI. That's a no brainer. They also probably could wrap SOAP with RMI quite easily.

    But these new protocols are about *different problems* than the J2EE currently is solving -- namely vendor lock-in, developer productivity, and enterprise back-office integration. These problems just don't disappear because of the lure of these "standards", many of which are just specifications to make Microsoft .NET work.

    SOAP is the kind of protocol you'd use to expose yourself as a next generation web service. IS it really going to be enough to hold together a high-volume B2B market? Questionable.

    Microsoft .NET is a good idea in many ways, but let's not forget that J2EE is severely ahead of the game of supporting enterprise systems.
  3. Hi Stu,

      I agree with you that the article goes a bit far, but the core issue at hand is that Sun hasn't trumpeted a strategy for supporting Web Services, like pretty much every one else is. Why is this important? Why do we need to hear the marketing from Sun? Business will need to hear the marketing from Sun to ensure that their investments in J2EE are solid and they will be able to grow their current applications to expose themselves as Web Services if they want to.

    >J2EE servers will need to expose EJB's with WSDL & UDDI.
    >That's a no brainer. They also probably could wrap SOAP
    >with RMI quite easily.

       It may be a no-brainer, but business men likely don't see it that way. The industry needs to know that Sun, as backer of J2EE, has a plan for properly specifying the integration of J2EE with these technologies.

    > These problems just don't disappear because
    >of the lure of these "standards", many of which are just
    >specifications to make Microsoft .NET work.

    Of course they won't disappear. And of course J2EE is and will remain the dominant platform for enterprise development for years to come. No one was disputing that. :)

    Business needs to know that Sun has a plan for integrating J2EE with these Web Services Initiatives, developers need to know that Sun will be there to write new standards if they are needed.

    Anything will do really. Even if Sun officially releases a "Web Services and J2EE Blueprints", a set of PDF's showing how to integrate a Web Services front end with a J2EE back-end, that will be enough to satisfy most people. :)


  4. This article is an example of the media trying to generate conflict and controversy where there is none. Enough articles like this, and sure, businesses will notice.

    But right now, most of the hype about web services are among geeks or trade rags talking about SOAP or .NET, not pointy-hairs.

    I think most business people don't have a clue what a web service is. Most people within *MICROSOFT* don't even understand what a web service is.
  5. I think there is truth to both of your opinions. What I would like to add is that there are also some other concrete steps that Sun can take, that are over and above a "Web Services and J2EE Blueprint", and can go a long way toward completing that big picture of the J2EE platform.
    The one area I would like to point to in this respect, is the messaging support in J2EE, and specifically Message Driven Beans. I think MDB is very narrowly defined as only supporting JMS type messages. I see this as a very severe limitation in the type of messages that can be asynchronously received, and handled by the EJB framework. I mean what about SMTP messages, or messages layered on top of the HTTP protocol, such as ebxml, or soap. I believe that theses non JMS based messages should be treated equaly to JMS messages as far as the EJB (MDB)layer is concerned.

  6. Regarding messaging support for EJB... just picking up on a couple of points that you made:

    With regard to SMTP Messaging - I totally agree with you - however, you will find that most JMS vendors support - or have bridges to SMTP.

    With regard to HTTP messaging - you could argue that servlets are the prime candidate for these - however it is another level of indirection I will agree with you.
    Another point here is that HTTP messaging is a point-to-point messaging protocol. In order for some HTTPMessageBean to reply, it would need generate some sort of XML response.... wouldnt we end up redefining the servlet?