J2EE 1.4 spec leads write an open letter to the community

Discussions

News: J2EE 1.4 spec leads write an open letter to the community

  1. J2EE 1.4 has been officially released. Bill Shannon and Mark Hapner, the co-spec leads for JSR 151 (J2EE 1.4) have written an open letter to the java community, where they talk about J2EE 1.4, the challenges faced by the expert group, and where to go from here.

    Open Letter to the Java Technology Community

    The Java(tm) 2 Platform Enterprise Edition (J2EE(tm)) specification has been a collaborative effort since its inception. The cooperation among competitors and the support of some of the brightest minds in enterprise computing contribute significantly to ensuring its ubiquity in the enterprise. Today nearly 9 out of 10 enterprises deploy application servers based on the J2EE platform. By introducing a highly configurable middle tier into their computing architecture, enterprises can leverage their data systems to reduce cost and complexity, offer new and improved services, while still protecting their substantial investments in their existing systems. J2EE is more than just a technology standard; it is a business strategy used by the world's leading corporations to gain competitive advantage.

    In order to deliver a careful balance of innovation, time-to-market, and interoperability, a diverse group of vendors and software developers joined the Expert Group to develop the J2EE 1.4 specification, the newest version of the Java 2 Platform, Enterprise Edition. This Java Community Process (JCP) program expert group has a goal to collaborate & agree on the standard platform for enterprise computing. Among these experts are BEA Systems, Borland Software Corporation, IBM, Macromedia Inc., Novell Inc., Oracle, Pramati Technologies, and Sun Microsystems and a number of distinguished individual developers.

    The challenge for the J2EE 1.4 Expert Group was to deliver even more innovation to help enterprises leverage technology for competitive advantage. The clear message we received from the J2EE technology community is that the J2EE platform must provide excellent support for Web services. The ease of using XML and related protocols to build reusable software for system independent applications make Web services a perfect fit for the J2EE platform. To that end, the J2EE 1.4 specification delivers the first platform and one of the industry's most comprehensive support for the WS-I Basic Profile; a set of best practices and protocols to ensure interoperability amongst different implementations of Web services. This makes J2EE one of the most interoperable Web services platform ever.

    Now that the specification is complete and has been ratified by the Executive committee of the JCP program, the next step is to release an implementation of the J2EE platform specification for the community. The J2EE SDK will be released on November 24 and will be made available on http://java.sun.com/j2ee. Developers will be able to build and deploy applications on a J2EE 1.4 compatible platform with the SDK or by using products from our licensees including BEA, Borland Software Corporation, IBM, Macromedia Inc., Novell Inc., Oracle, Pramati, and Sun Microsystems.

    In addition to the efforts of the members of the JSR-151 Expert Group and our J2EE technology licensees, we are asking the entire Java technology community to contribute to the future direction of the J2EE platform. We'd like to encourage everyone to download the J2EE SDK to learn about what's new and improved in the platform. Send us your feedback at and tell us what you'd like to see in future versions of the J2EE platform. Become more active in the Java technology community by joining an online community of developers such as java.net. Your input is crucial to the continued success of the world's most popular enterprise platform.

    Sincerely,

    Bill Shannon and Mark Hapner
    Co-Specification Leads, JSR-151


    More information

    The Evolving J2EE Platform: What's New in J2EE 1.4 by Floyd Marinescu

    What's New in J2EE 1.4 an Interview with Mark Hapner

    Sun, Sun Microsystems, the Sun logo, Java, J2EE, and JCP are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

    Threaded Messages (41)

  2. Politics[ Go to top ]

    by using products from our licensees including BEA, Borland Software Corporation, IBM, Macromedia Inc., Novell Inc., Oracle, Pramati, and Sun Microsystems.

    JBoss shells out mucho dinero for J2EE 1.4 certification, and can't even merit a mention on Sun's list of licensees?

    MEOW!
  3. Politics[ Go to top ]

    Maybe it's an extra 500 G's for free j2ee publicity. <shrug> hah.

    Steve
  4. Politics[ Go to top ]

    Sun Microsystems is such a joke of a company...

    Best of luck to JBoss to get the most out of that certification.

    And let's all hope SUNW will disappear soon.
  5. Politics[ Go to top ]

    Does every single thread have to be about JBoss?
    It gets kind of repetitive...
  6. This is good.

    Super will fully support J2EE 1.4.

    Perfecting J2EE!
  7. Boycott the Java Cartel Process (TM)[ Go to top ]

    Become more active in the Java technology community by joining an online

    > community of developers such as java.net. Your input is crucial to the continued
    > success of the world's most popular enterprise platform.

      I'm sick of all this talk about "community". The Java Cartel Process (TM) is a gigantic pony scheme to fool the world that Java is "open" when it's cleary controlled by Sun.

      Allow me to repost the fineprint from the story:

    > Sun, Sun Microsystems, the Sun logo, Java, J2EE, and JCP are trademarks or
    > registered trademarks of Sun Microsystems, Inc. in the United States and other
    > countries.

      How telling? Let's boycott the Java Cartel Process (JCP) and let's use open forums such as Apache, Eclipse, Sourceforge and so on to build a better alternative.

      Viva The Java Republic! More info at http://viva.sourceforge.net/action.html
  8. Boycott the Java Cartel Process (TM)[ Go to top ]

    I'm sick of all this talk about "community". The Java Cartel Process (TM) is a gigantic pony scheme to fool the world that Java is "open" when it's cleary controlled by Sun.


    open != control. Linus "controls" the linux kernel yet this kernel is open. JBoss "controls" their source yet is open. Same way, Sun tries to "control" java yet source is available under SSCL. What would your boycott plans accomplish?
  9. Shared Source != Open Source[ Go to top ]

    open != control. Linus "controls" the linux kernel yet this kernel is open.

    > JBoss "controls" their source yet is open. Same way, Sun tries to "control" java > yet source is available under SSCL.

      You seem to be easily fooled. Sun like its idol Microsoft tries to spread confusion what open-source is using fake open-source licenses such as the Java Research License (JRL) or the Sun Community Source License (SCSL) similar to the Microsoft Shared Source License; don't be fooled.

      For more info about Sun's open source duplicity check out the Viva! page @ http://viva.sourceforge.net/strategy.html
      
    > What would your boycott plans accomplish?

      It send a message to Sun that nobody needs them anymore. Sun is just holding back Java with their SCO-like schemes.
  10. RE: Boycott the Java Cartel Process (TM)[ Go to top ]

    This is nosense.
    Thanks to sun (java) the object oriented paradigm is popular. What oo languagage was so well accept in the market???
    I use java to my solutions and never pay anything to sun.
    So take your access and VB (cause I think you like them) and stop talking this nosense words.

    *Sorry my english
  11. You got to be kidding me!

    Brylex.
  12. The Java Republic Wants You[ Go to top ]

    You got to be kidding me!


     Not really, I'm deadly serious. The Java Cartel Process (TM) is dead. Just witness the stunning success of the open-source Eclipse initiative compared to the latest Sun-led Java Tool Cartel Wannabe.

      - Gerald
  13. Okay here is my feedback. There seems to some fluff added to the J2EE spec in the name of web services. What is the point of making a Stateless EJB web service enabled. Do you want me to open up a EJB container to web access?
  14. WebServices is accessing services over the web. Very simply put, an alternate RPC mechanism. At the end of the web service is the actual service functional processing. In J2EE apps, the processing layer is most likely going to be a Session bean. J2EE 1.4 enables this- while not mandating. Whether to expose a SB as a WS or not is an app design decision.
  15. That's why I called it fluff. Stuff which need not be there and not quite necessary.
  16. I think you have it wrong. J2EE 1.4 specifies the WS-I Basic Profile. This is a subset of the Web Service standards that supports Document-literal and SOAP RPC-literal encoding only. There is no support for SOAP RPC encoded.

    In practical terms, this means that you (or your IDE) will need to provide XML handling capability to build an XML request document to send a request to a service, and provide an XML parser to understand the XML response document contents.

    J2EE 1.4 and WS-I Basic profile are document-oriented Service Oriented Architecture standards. All the convenience of RPC is on the way out.

    -Frank
  17. All the convenience of RPC is on the way out.

    Store-and-forward transport (eg, message broker or JXTA relay) impedes RPC. This is also why socket security is deprecated in favor of XML message security. Another advantage of documents is that they're amenable to multicasting and pipelining. Documents are also more object oriented.
  18. RPC convenience[ Go to top ]

    I agree with your points about Document-oriented SOA. (Especially after seeing how poorly RPC scales.)

    I was thinking about the convenience of being a Java developer that works with objects and doesn't want to think and code in XML. If I had an object like:

    Hashmap ht = new Hashmap();
    ht.put( "Event", name);
    ht.put( "Keycode", keycode);
    ht.put( "CurrentTime", new Date() );

    then I could turn a method that returns the ht object in an RPC Web Service call.

    In a document-oriented world I would be creating an XML tree and stuffing the serialized objects into Elements.

    I'm curious to know which XML library you would recommend and why?

    -Frank
  19. RPC convenience[ Go to top ]

    I agree with your points about Document-oriented SOA. (Especially after seeing how poorly RPC scales.)

    Yeah. RPC's dedication to point-to-point connectivity is a scalability barrier.

    I was thinking about the convenience of being a Java developer that works with objects and doesn't want to think and code in XML. If I had an object like:
     
     Hashmap ht = new Hashmap();
     ht.put( "Event", name);
     ht.put( "Keycode", keycode);
     ht.put( "CurrentTime", new Date() );
     
    then I could turn a method that returns the ht object in an RPC Web Service call. In a document-oriented world I would be creating an XML tree and stuffing the serialized objects into Elements.


    JXTA messages can be encoded as XML documents or as BLOBs, but JXTA shields the developer from XML. A JXTA message has name/value pairs. The values can be serialized object graphs, perhaps including java.util.Map as you show above.
  20. RPC convenience[ Go to top ]

    It doesn't have to be XML. And it shouldn't be Java. You could serialize your hashmap and send it over the wire as-is and the concept is still document oriented. The idea is to separate data from actions, and XML happens to be a convenient format. All that is needed is an agreed upon transport (HTTP), an agreed upon format (XML), and tools to create and digest the documents. An XML parser with something like the jakarta digester or castor xml does this nicely. Combined with apache or whatever else you need for async or transactions and you have the complete toolset.

    SOAP was an attempt to cram all this at through TCP port 80 one command at a time, as signals, mixed with commands, mixed with data, just to avoid reconfiguring firewalls. The old object-oriented(?) idea of data knowing what to do with itself is on the way out, and SOAP itself has moved beyond its own screw the sysadmins through the backdoor mindset. And it doesn't have to be XML over HTTP. The idea is divergent systems communicating with each other. SMTP happens to be a nice alternative to HTTP because a mailserver allows for queueing of requests in a way a webserver doesn't.
  21. RPC convenience[ Go to top ]

    SMTP happens to be a nice alternative to HTTP because a mailserver allows for queueing of requests in a way a webserver doesn't.

    I'm not sure I agree that a webserver can't queue requests. Surely there's some way to configure Tomcat to queue its backlog.
  22. "Web Services" a misnomer[ Go to top ]

    Exposing Session Bean functionality as Web Services does not mean that the EJB container is being opened up to web access. "Web Services" is an unfortunate misnomer, because *transport mechanisms* are explicitly decoupled from *content*.

    A SOAP call obeys a specific XML-derived grammar for its *content*, but it could occur over any synchronous or asynchronous *transport mechanism* (RPC or messaging). So one could think of a Session Bean's Web Service being accessed over JMS, for instance, and not necessarily over HTTP.

    Regards,
    Ganesh Prasad
  23. "Web Services" a misnomer[ Go to top ]

    "Web Services" is an unfortunate misnomer, because *transport mechanisms* are explicitly decoupled from *content*.

    Web service is concerned with only two things: heterogeneity and firewalls.
  24. Hi PPL,

    Pretty good news that J2EE1.4 has finally been release. Congrats to Sun, etc. I was wondering... In the download it says that there is a J2EE1.4 Application server available for download. Is this different from the SunONE AppServer 8 which is going to be the "NEW" Refference implementation? Any thoughts?

    Cheers,

    Smythe
  25. Where's the beef in the open letter?[ Go to top ]

    From my experience, open letters are normally a criticism on a process or institution. For example, Walter Hewlett's open letter to Carly Fiorina, HP's CEO, that the proposed merger between HP and Compaq was a bad idea for HP. That open letter was printed in the San Jose Mercury News and impacted the process HP was undertaking.

    I was hoping the open-letter from Bill Shannon and Mark Hapner would cover their views on the JCP process. The J2EE 1.4 spec was supposed to be done in 2002. Was it the JCP process that kept J2EE 1.4 from being finalized?

    Another thing I wish they wrote in their open-letter was what impact WS-I Basic profile is going to have on J2EE development? In my opinion, WS-I Basic profile is a subset of Web Service technologies, protocols, and encoding styles in use today. WS-I Basic profile basically says to me: Document-literal encoding is the approved way to build Service Oriented Architectures. I agree with this position because, while SOAP RPC-encoding is easy to use, it is not scalable. (See my findings at: http://dev2dev.bea.com/articles/Cohen.jsp and http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/.) I wish Shannon and Hapner stated their reasons why WS-I Basic profile is a good thing.

    Lastly, I attended the J2EE Birds-of-a-Feather (BOF) sessions at last year’s JavaOne conference. The panelists had a fascinating conversation about EJB deployment descriptors. At issue was simplifying deployment of EJB applications. There were a number of different thoughts and ideas put forward. I wish Shannon and Hapner’s open-letter would give us some idea of what to expect in J2EE 1.5.

    -Frank Cohen
    www.pushtotest.com
  26. Get J2EE 1.4 now.[ Go to top ]

    Version 1.4 Developer Release

    The Java 2 Platform, Enterprise Edition ("J2EE") version 1.4 SDK provides a complete implementation of the Java 2 Platform, Enterprise Edition 1.4 specification along with extra features to help developers learn about what's new and improved in the specification. The J2EE 1.4 SDK includes the J2EE 1.4 application server, the J2SE platform as its foundation, and various tools to help developers prototype J2EE applications and learn about the J2EE platform and technologies. Everything a developer needs to get started using the J2EE 1.4 platform, including The J2EE 1.4 Tutorial and Java BluePrints, is available now for download.

    http://java.sun.com/j2ee/1.4/download-dr.html
  27. Exclusionary Reference Implementation[ Go to top ]

    Unfortunately, this new reference implementation is only available for Sun's commercially-supported platforms (Windows, Solaris/sparc, and Linux/x86). ALL prior RI's were pure-Java and would run wherever a version-compatible JVM was available.

    By releasing J2EE 1.4 RI to only these platforms, Sun will be driving away developers whose primary environment is Mac OS X, FreeBSD, Linux/ppc or even Sun's own Solaris/x86. Even Sun's engineers use Mac OS X as their primary desktop(James Gosling, for example).

    What happened to Write Once, Run Everywhere?
  28. Exclusionary Reference Implementation[ Go to top ]

    By releasing J2EE 1.4 RI to only these platforms, Sun will be driving away

    > developers whose primary environment is Mac OS X, FreeBSD, Linux/ppc or even
    > Sun's own Solaris/x86. Even Sun's engineers use Mac OS X as their primary
    > desktop(James Gosling, for example).

    They're probably using JBoss, the real J2EE RI.
  29. How can JBoss be the real RI???[ Go to top ]

    By releasing J2EE 1.4 RI to only these platforms, Sun will be driving away

    > > developers whose primary environment is Mac OS X, FreeBSD, Linux/ppc or even
    > > Sun's own Solaris/x86. Even Sun's engineers use Mac OS X as their primary
    > > desktop(James Gosling, for example).
    >
    > They're probably using JBoss, the real J2EE RI.

    JBoss is not even J2EE 1.anything compatible. How can it be considered a reference implementation?!?!
  30. JBoss is the real RI[ Go to top ]

    They're probably using JBoss, the real J2EE RI.

    >
    > JBoss is not even J2EE 1.anything compatible. How can it be considered a
    > reference implementation?!?!

    Because it works whereas the RI does not.
  31. The real thing?[ Go to top ]

    Cam,

    Have you even tried downloading and installing the J2EE 1.4 SDK? It works just fine for me. To my knowledge, JBoss hasn't released a J2EE 1.4 Compatible Application Server yet, so I'm not sure how you can truthfully claim that it is better than the RI?
  32. The real thing?[ Go to top ]

    Did you actually read the first post in this thread?
  33. The real thing?[ Go to top ]

    Did you actually read the first post in this thread?


    Well, to the best of my knowledge (correct me if I am wrong), they are not yet certified for any J2EE spec, which means != RI.

    I hope and think JBoss will be certified soon (anything else would be a freak of nature), but they are not there yet, so talking about situations and things that do not yet exist almost nudges on vaporware.
  34. JBoss is the real RI ... really ?[ Go to top ]

    You really ought to look at the definition of a RI for a Java spec. It is only a proof of concept, and the SUN RI does that perfectly. RI doesn't mean "what is most downloaded", or "most talked up", or "most marketed". It means simply as I stated above.
  35. Web Services[ Go to top ]

    The clear message we received from the J2EE technology community is

    > that the J2EE platform must provide excellent support for Web services.

    I wonder where they got that from. Guess it's the market leaders trying to push that technology (just my 2Cents). We did a lot of J2EE projects in the past (also integration of several external systems) and we _never_ used Web Services. I wonder if other developers/architects made the same experience.

    Regards,
        Dirk
  36. Web Services[ Go to top ]

    If you are doing any development which is connected to the web you will need Web services, or at the very least a decent XML parser. I know that a lot of ASP sites have gone over to ASP.Net and and they (rather foolishly) open up everything as a SOAP Web service
  37. Web Services[ Go to top ]

    If you are doing any development which is connected to the web you will need Web services, or at the very least a decent XML parser.

    XML parser? We're talking about Web Services. J2SE has had XML support for a long time...
  38. Web Services[ Go to top ]

    If you are doing any development which is connected to the web you will need Web services, or at the very least a decent XML parser.


    Depends on what you mean by "connected to the web". If you develop a web-application with a _user_ interface you normally do it using JSPs (at in a J2EE context).

    If you are integrating services with that application that reside within the enterprise (LAN or whatever) you also don't necessarily need Web Service either (e.g. JCA, direct JDBC access, RMI server with access to native components are only some of the possibilities).

    You also don't need _any_ XML parser for these two scenarios.

    If you want to integrate service that are only accessible via HTTP, I agree you might need Web Services. But from my experience that happens quite rarely. The main problem that you have with this kind of integration is that you rely on a service that is controlled by someone but not your enterprise (or the enterprise for which you develop an application). So, if warranty or service level agreements come into play you have a _REAL_ big problem here.

    Regards,
        Dirk
  39. Q&A about this release[ Go to top ]

    To answer some of your questions
    http://java.sun.com/j2ee/QandA.html

    Just for the record iPlanet 6.x != Java System Application Server 7/8 (used to be called Sun One app server), as the new stuff is a complete rewrite.

    As much as I like JBoss, what they need is the equivalent page:
    http://docs.sun.com/db/coll/s1_asse_en

    Cheers
  40. http://java.sun.com/j2ee/QandA.html


    Q. Have any vendors decided to license the specification?

    A. Yes, we are pleased to name Apache Software Foundation and JBoss Group as the first two licensees of the J2EE specification. Apache and JBoss have taken advantage of the new licensee terms for open source projects; their decision to license 1.4 will further popularize 1.4 and will increase adoption of J2EE through a broader community of developers.


    What are Apache going to license ? Geronimo or Tomcat ?

    what does mean to license J2EE spec. ? the same as licensed as J2EE compatible ? I think that Geronimo project is quite far frm that.
  41. Keep up the good work! Each increment makes our lives easier and makes J2EE the ubiquitous platform to build enterprise applications.

    I have a comment concerning the Web Services though. As it's mentioned in the letter:

    The clear message we received from the J2EE technology community is that the J2EE platform must provide excellent support for Web services.

    I don't see/hear/read any message clear/vague concerning the Web Services coming from the community. I don't think that it's the industry's priority. The message comes from the software/technology vendor companies, alright! Obviously they want us to use WS technology to generate money around it but I don't see it happening.
  42. Keep up the good work! Each increment makes our lives easier and makes

    >J2EE the ubiquitous platform to build enterprise applications.

    not only that !

    Each increment brings us closer to perfection, closer kingdom of God, I mean realms of enterprise computing.