What about Java EE 6, anyway?

Discussions

News: What about Java EE 6, anyway?

  1. What about Java EE 6, anyway? (65 messages)

    Well, lets just say i do have the capacity to move past financial news and make some comments on something that is going right at Sun: of course I am talking about the impending release of Java Platform, Enterprise Edition 6 (Java EE6), as this seems to be the only thing that is consistently executing in a leadership position right now, and that includes the competition with Spring and .Net...there is not much in the way of comparing JEE6 with Spring 2.5/3x and .Net 2/3x, as they are each fulfilling their own niche, so i won't do that justice, i'll leave it to a discussion on TSS to vet that one out, but I will talk about what Enterprise Java means to Sun's overall business, as I have made some references to it in previous posts... For your background reference, details about the Java EE6 platform can be found here: http://jcp.org/en/jsr/detail?id=316 There are a lot of big questions remaining over what this release will actually deliver on: with JEE3, there were some JAX web services integration via the Web Services Pack; JEE4 formalized that JAX integration; and JEE5 re-wrote the EJB and JPA specs to make it more viable to more developers...now, with a focus on making JEE6 more palatable to more developers, especially at the "web-tier", there is this thing called profiles that is being introduced: i think this is a mistake, but i have been wrong before, and do not feel like fighting it, in the limited scope of what such a protest would make...essentially, profiles means that after years of arguing with my former colleagues at Sun about calling the Sun Web Server a 'light-weight' application server because it served up JSPs and Servlets, that is exactly what the JEE6 expert committee is about to certify, with the real significance being that Tomcat will be able to call itself "JEE-compatible", as will the Spring Application Platform... why is this important? well, to state the obvious, it destroys the very value proposition that made JEE the de-facto Internet application development paradigm, as customers faced a far-less costly portability exercise...for instance, develop a JEE application in Glassfish, with or without EJBs, and there is no explicit guarantee that it will work with other so-called application servers, as it is up to the vendor to determine which 'profile' to support... Read the rest at http://douglasdooley.blogspot.com/2008/08/jee-6.html.

    Threaded Messages (65)

  2. Re: What about Java EE 6, anyway?[ Go to top ]

    I think the primary value proposition of the full EE stack was to the Java EE app server vendors. Most everyone else realized that in many cases it is actually quite clear that you only need a few portions of the overall standard. In such cases it is only reasonable to expect that there be reasonable standardization of and portability between implementations of these pieces -- without dragging in everything else. Furthermore it was clear that even if you bought into the entire Java EE stack this really didn't give you full portability between any two vendors for any complex application -- so ala carte technology consumption does not mean lower portability. In essence Sun is declaring that Java EE is a (somewhat) modular architecture -- you don't need to have everything to use some of it and can use alternative Java technologies in places as appropriate.
  3. Re: vendors or customers[ Go to top ]

    Jess, Am i to believe that all the hundreds of customers and thousands of developers that adopted JEE over its lifespan did not value portability as the key metric for such adoption: you are making the claim, it seems, that it was only the vendors who saw value in making components and/or applications inter-operable across platforms, and that is why they provided a complete application server, specification by specification... I would assume that one of your arguments, if my above statement is true of your opinion, that it was merely adopted by the vendors in order to charge more, but this does not stand-up now that Glassfish, JBoss, and Geronimo are free for deployment and WebLogic and WebSphere offer Express editions... I agree that you can develop a "modular" architecture for development of different JEE technologies, but the implementations themselves, if they are not the same in adopting the same set of technologies will no longer offer complete portability if the profile choice is offered... therefore, customers will not know explicitly that a vendor's implementation is compatible with another JEE vendor's implementation, and this to me destroys the very essential value proposition that established JEE in the 1st place... apologies if i am repeating myself...
  4. Re: vendors or customers[ Go to top ]

    Jess,

    Am i to believe that all the hundreds of customers and thousands of developers that adopted JEE over its lifespan did not value portability as the key metric for such adoption...
    Portability in JEE is a hoax. The spec left such wide holes that it allowed vendors to fill them enough to make migrating between the platforms impractical if not impossible. Just look at EJB descriptors or Weblogic's APP-INF (which was a good idea, by the way) Not that it's bad, it's just someone using portability in JEE as an argument most likely have never tried to deploy an EAR developed for one platform into another. To me the value of J2EE/JEE is in the simplified container-based programming model with that one can develop complex application being concerned about infrastructure such as threading, database access, transactions, mailing, JNDI etc. (That* works once you picked up a JEE vendor. Regards, Slava Imeshev Cacheonix: Portable Distributed Cache
  5. Re: vendors or customers[ Go to top ]

    Portability in JEE is a hoax. The spec left such wide holes that it allowed vendors to fill them enough to make migrating between the platforms impractical if not impossible. It depends on which part of the spec you are looking at of course. Java EE is a rather large spec. I haven't found a lot of really wide portability holes in JSP, Servlet, JSF or JavaMail, just to name a few. The most obvious holes are in EJB3, specifically the JNDI names. The @Resource(mappedname="vendor string here") is terrible. You can override it in XML, but in a way that only adds to the horror. EJB3 is quite a nice spec otherwise, but these JNDI names are just terrible if you want your application to be easily deployable to multiple application servers. Luckily, the word is that these names will -finally- be standardized in EJB3.1. I'm holding my breath :)
  6. Re: What about Java EE 6, anyway?[ Go to top ]

    Most everyone else realized that in many cases it is actually quite clear that you only need a few portions of the overall standard. In such cases it is only reasonable to expect that there be reasonable standardization of and portability between implementations of these pieces -- without dragging in everything else.
    I never really understood why some people have so much problems with "dragging in everything else". Is it the bytes that sit on your HD? Or the download time when downloading e.g. Jboss from the web? I've been building and have seen a lot of Java applications that used only some parts of Java EE, but I never felt that the fact that there was more available was a problem in any way. E.g. I have seen applications build mainly out of Servlets that used JTA and JSP. They didn't make use of e.g. Javamail, but I'm not really sure why the availability of Javamail would hurt the application in any way. I've also seen applications that used JSF and JPA extensively and used a little of Javamail but didn't make use of e.g. EJB3. In that application too, having EJB3 available, but simply not used, did not seem to influence the application in any way. There are many more configurations I've seen, but I think you'll get the point ;)
  7. I very highly value the portability. I've been able to make application server choice pretty much transparent for several applications. Over time that has helped us tremendously. We migrated a while back from Oracle to Glassfish and the results were great, but more importantly, the process was painless. It would have been much harder to convince the client if we'd had to spend a lot of our budget on migration issues, but as it is, there were few if any (Spring was a huge help here as well). In fact, we were able to do an evaluation of multiple servers, secure in the knowledge that we could choose the servers on their own merits rather than worrying about some kind of lock-in. I disagree with the notion that portability only helps the JEE vendors. It is much more helpful to us because the app server choice is based on things like cost, admin feature sets, reliability, performance, and support rather than "will my code work there?". Portability works against vendors like IBM and (especially previously) Oracle, who are more than happy to lock you into their exhorbitantly priced products that follow their own weird, burdensome "standards".
  8. Re: What about Java EE 6, anyway?[ Go to top ]

    I disagree with the notion that portability only helps the JEE vendors.
    I never meant to imply that portability only helps Java EE vendors. Rather the notion that the only way one can ensure portability is to portray Java EE as a inseparable monolithic entity which must be provided in its entirety is both false and only helps app server vendors.
  9. Re: What about Java EE 6, anyway?[ Go to top ]

    Peter, Thanks a lot for posting this. Many of us in the Java EE 6 EG are actually very eager to know what folks in the community really think about the profiles effort, as well as how they would like Java EE extensibility in general to look like (the other big agenda item). For example, one of the extensibility features being discussed is general-purpose DI. I would hope the spec lead will blog about this soon (perhaps after things are discussed in slightly greater detail in the next few weeks). In the meanwhile, Roberto did blog about profiles here some time ago: http://weblogs.java.net/blog/robc/archive/2008/02/profiles_in_the_1.html. Cheers, Reza
  10. There are a lot of profiles in J2ME. Moreover, it encourage vendors to support not only profiles but even particular JSR. It confuses developers and end users that can't predict if their new J2ME device will be able to perform required operations.
  11. Java EE in Open Source Trend[ Go to top ]

    i hear the certification is amazing expensive, and Java EE 5.0 also is not gaining the momentum yet, see the penetration of EJB3, the trauma still in the market. CMIIw. with the current Sun's stock, and JCP is part of Sun, not an independent body.. i prefer JCP as independent body that become one of the entity that responsible for future Java can adopt more cool thing then. with the price from the high end Java EE container that very expensive, and global resession, i see the open source container will become another alternative for new market, esp for the company that want to become mega company that doing merger, they will use the high end. but i see the linkin architecture also a cool one that make the importancy of JavaEE 6.0 is not as important as the cost that will show.
  12. Re: What about Java EE 6, anyway?[ Go to top ]

    ...JEE6 expert committee is about to certify, with the real significance being that Tomcat will be able to call itself "JEE-compatible", as will the Spring Application Platform...
    I think it would be a very bad thing to define a Web Profile as only what is in Tomcat. Really, honestly, how can you call it a Java EE 6 Web Profile without including *everything* a developer would need to develop web applications using Java EE 6??? I think that having SpringSource on the expert group pushing their own agenda could be detrimental to Java EE, and I really hope the expert group agrees that the "B" version of Web Profile with JSF, WebBeans, etc. should be used. Or, maybe even scrap the idea of profiles to avoid fragmentation and confusion about what Java EE really is. Developers aren't forced to use any of the features in EE if they don't want to, and they are free to use a non Java EE container such as Tomcat.
  13. Re: What about Java EE 6, anyway?[ Go to top ]

    I too think profiles are a mistake, and will lead to confusion and portability problems. This seemed to be the sentiment at JavaOne this year too. It does seem that certain parts of the EE6 expert group are pushing an agenda that doesn't have much support in the community. Matt http://www.c2b2.co.uk
  14. Re: C2B2[ Go to top ]

    Matt, I know it may be partially influenced by your comments, that I agree with, but from a moderately objective and singular viewpoint, it looks like C2B2 is an incredible consultancy, have you guys ever built re-usable applications and/or components that have been used across different JEE application servers?... just checked out your web-site, and it is impressive, doug
  15. Re: C2B2[ Go to top ]

    Doug, We have Si customers that develop on one application server and deploy on another, although this is not as common as it used to be. We also have customers that develop commercial applications that can be deployed across a number of application servers. Both of these a good examples of a scenario where having a single JEE profile is a large advantage. Matt http://www.c2b2.co.uk
  16. Re: What about Java EE 6, anyway?[ Go to top ]

    I agree Matt, and am doubtful of how profiles will play out in the real world. Portability has been very important in the majority of projects I've been involved in over the last 8 years or so. When working on product-based development, portability means access to a wider market segment including customers with incumbent app server investments. When working on project-based development, portability means local development on something cheap and light, deployment to something expensive and much heavier weight, whilst still being able to change production should serious performance or resiliance problems be uncovered at the last minute. Over the years I've had to reports J2EE compatibility problems to just about every major app server vendor, commercial and open source. This involves quoting the Sun specs at their support staff and having a discussion over any ambiguities. This can be a painful process, but the addition of Java EE Profiles would make this just about impossible. I've never seen it, but I can only conclude that the Java EE certification test suite must currently have serious coverage gaps, and Java EE Profiles would make this worse still?
  17. As many of you, I agree. I feel that the concept of profiles is primarily beneficial to the vendors. Now any vendor may call their product a JEE-compliant server which in turn may proof very problematic indeed. Developers may be under the impression that they can use any of the JEE-components and will realize too late, that their appserver of choice doesn't really support their new app. Of course, most developers are well-informed about current technologies and thus must will realize soon enough. However, what if the developer is not the decision maker? If management says: "Tomcat is free and there are lots of books on it so there is market acceptance and best: its JEE-compliant, so we use it as our appserver". In such a case you'd end up in a pretty sticky situation (I am not bashing Tomcat, its just an example). This may not be a problem, but it could become a problem. After many years of development with J2EE 1.3, 1.4 and Java EE 5.0, I would prefer if there is one Java EE 6.0 profile. It doesn't hurt to have some extra functionality in your appserver, you never know when you gonna need it. Naturally, I am a little bit like "two-face" in the latest Batman flick ;) I do see some advantages with profiles. In theory, your application will be more secure the fewer services the application server provides (smaller attack surface), then again, what are firewalls for? :) I myself "personalized" many JBoss installations to exactly fit my applications' needs. An idea for the Java EE 6 Expert Group would be to have one profile, but add the concept of plugins/modules so one can disable/enable JEE6 services. Thus, all Java EE 6-servers support everything, when needed. In reverse, you could disable the services which aren't needed.
  18. Profiles = $ for Sun[ Go to top ]

    The real reason that profiles have come about is to expand the pie for licensing the EE brand for Sun. At this time there are only a handful of EE licenses; only a couple of them are large to generate any real revenue for Sun: IBM, Oracle/BEA and SAP. The addition of profiles effectively lowers the barrier of entry to get a EE certified product to the market; thereby increasing the number of expected vendors that will release EE products (especially on the low end).
  19. Re: What about Java EE 6, anyway?[ Go to top ]

    What about it? In a world that is moving towards cloud computing is JEE still relevant? This whole discussion looks like navel gazing to me. Outside Sun and the closed world of the JCP does anyone care? Judging from the particpants in this thread I guess not. JEE was never a developer community led effort and has always served the interests of a small cartel of vendors. However benevolent Sun has been in the past, the JEE developer community has never been truly free. JEE was a big step forward in 1997 and represented an improvement on what went before, but who cares now? The discussion about profiles has more to do with JEE application server certification then anything else. Who needs them? JEE has been modular from the outset. One of the things JEE got right was to have separate containers and to separate the container from the services, allowing people to mix and match services. So people have been using services independently for a long while leading to Spring and Hibernate. So profiles are out there already. Another point, does enterprise computing still exist? All the Enterprise Applications I've seen recently are in fact web applications running behind a firewall. The future is "the web as a platform"; vendor independent and language independent. I find it ironic that Suns slogan use to be "The Network is the Computer". Well that dream is being realised on the web by companies like Amazon, Google, Yahoo etc. The services provided by these vendors aren't totally open, but they do provide developers with more openness than can ever exist on a single proprietary platform. Sun could have been bolder by opening up the JVM/JEE platform sooner encouraging true Open Standards to emerge. Anything they do now though (Open source Java, JRuby, Jython, JEE Profiles etc) is too little too late. The world has moved on, and thats a good thing. Paul.
  20. Re: navel gazing[ Go to top ]

    Paul, I am sure the customers that will continue to utilize JEE as their platform for development and deployment will care; whether u think cloud computing will replace all development is basically beside the point, although that is in itself a total guess, and more likely to be a marketing statement from Salesforce.com, than anything that is being seen by Oracle, IBM, SAP, Sun, and Red Hat... Beyond what vendors offer, the question remains, and here u may have a point - - what is the preferred deployment scenario: in-house or hosted on a "cloud"?...that is a valid question, and will be an ongoing evaluation based on a host of criteria that is only beginning to be understood... but that is essentially completely off-topic, un-related to JEE6's relevance, and a false prophet for what comes next following Enterprise Java's hey-day...for 8 years people have been talking about how web services would replace the need for Java, then scripting, now clouds, and i just wonder what those new-faced applications will be written in, and how they will inter-operate... will it all be so magically easy? or will customers still have their own IT departments? i am betting more on the latter than the former, at least for the next 3 years, which is why a discussion on JEE6 is warranted... your anti-Java arguments are predictable, and like i said, it will be somewhat interesting to see how much app development moves to pure-hosted, but that is not enough of a cause to take up to ignore the importance of getting JEE6 right, unless someone has a vested interest in its demise, there has to be some analysis and decisions made on what is best for the multi-billion dollar Enterprise Java market...
  21. Re: navel gazing[ Go to top ]

    unless someone has a vested interest in its demise, there has to be some analysis and decisions made on what is best for the multi-billion dollar Enterprise Java market...
    Hi Douglas, I agree that JEE is not going to disappear over night. My argument is that it is now just another legacy platform in "the enterprise". Why? Because the focus has always been "the multi billion dollar XXX market". I'm sure that there is still money in Cobal, but I don't see it as part of my future. You can't control and own markets. Markets tend to have a mind of their own people will do what they want to do. Its called freedom. My argument isn't anti-Java, it is anti closed proprietary platform. It is interesting that the parts of JEE that have flourished the most are the bits that are based on open standards. For example the Servlet API (HTTP/CGI) and JDBC (SQL). Sun is trying to guess where the market is going next. Which means that it is providing zero leadership and will always be playing catch-up. In the beginning JEE was catching up with CORBA, then the web, then WS-* Web Services and now RIAs. In fact in most of the instances where Sun ha tried to lead the JEE platform has failed miserably like with EJBs and Applets. If the platform was open then Sun wouldn't need to guess what to do next or whether to follow Microsoft. The developer community would lead and determine what they needed for themselves. I agree that I don't know for sure what's coming next. But what I can say is that the general direction is clear. We are moving towards (more) open APIs. We have open source languages (now including Java), open operating systems (GNU/Linux) and open web services APIs (HTTP/REST/Atom etc). There is still space for proprietary platforms (for instance Flex, Amazon S3, Googles GData, etc), but these platforms must build on open standards providing much more freedom to their developer communities. This means being willing to give up a lot more control. Something that Sun has been very reluctant to do until very recently. Hence my point about too little too late. Paul.
  22. Re: agreed[ Go to top ]

    Open standards dominate, and open source implementations follow that metric... what do you think of Spring, and particularly the SpringSource Application Platform? its tough to argue that JEE is more closed than Spring... Sun as the dominatrix of Java is a little skewed, and headline-grabbing, but not really true, although i am basically arguing that they finally use that so-called veto to get rid of the profiles campaign, as many in this thread think that it is counter-productive... i am still somewhat unclear as to what your point is beyond that the marketplace determines best what technologies win, as opposed to vendors deciding for everyone...in other words, with openJDK, Glassfish, JBoss, and Geronimo, a democratic vote on JCP specifications, and open forums such as this discussion on TSS, what else do you want?... "too little too late" - - i just dont know how we would determine that, what replaces JEE? - Rod thinks Spring - VB guys think .Net - Rosenberg thinks SOA and "clouds" my money is still on Enterprise Java, because beyond fashion, openest, and inflammatory comments about Sun's control (of which i have been guilty), customers still have to make decisions, and the safe choice remains the 'legacy' platform of app servers...
  23. Re: agreed[ Go to top ]

    Open standards dominate, and open source implementations follow that metric...

    what do you think of Spring, and particularly the SpringSource Application Platform?

    its tough to argue that JEE is more closed than Spring...
    Open sourced and open standards are too different things in my opinion. I don't believe that SpringSource is a community led endeavor is the same way that Apache is for instance. Spring is a proprietary platform. The fact that they "give away" the source code as a "loss leader" and try to make their money in other ways is just clever marketing trick. I agree that Spring presents the opportunity for much greater vendor lock-in then JEE.
    Sun as the dominatrix of Java is a little skewed, and headline-grabbing, but not really true, although i am basically arguing that they finally use that so-called veto to get rid of the profiles campaign, as many in this thread think that it is counter-productive...
    I don't want to paint Sun as the bogey man in all of this. In fact if it wasn't for Sun we probably would have all been compelled to become Microsoft Programmers long ago :) Sun started out in Open Systems and only became a proprietary platform vendor to ward off the impending threat from Microsoft. Most of my criticisms of Sun come down to incompetence. They have found themselves in a leadership role and just aren't very good at it. They started off with some interesting ideas (Jini, JavaSpaces, "The Network as the computer") and lost their way. Others like Adobe, Google and Amazon have learned from their mistakes and could do better IMO.


    i am still somewhat unclear as to what your point is beyond that the marketplace determines best what technologies win, as opposed to vendors deciding for everyone...in other words, with openJDK, Glassfish, JBoss, and Geronimo, a democratic vote on JCP specifications, and open forums such as this discussion on TSS, what else do you want?...

    "The market determines bets what technologies win" - yes that is my point. Democratic? Please. If Sun wanted to pole the JEE developer community then they could easily. I have a vested interest. I want to use what technology I like when I like. I don't want to be locked into the technology strategy of any specific vendor or cartel of vendors.
    "too little too late" - - i just dont know how we would determine that, what replaces JEE?

    - Rod thinks Spring

    - VB guys think .Net

    - Rosenberg thinks SOA and "clouds"

    my money is still on Enterprise Java, because beyond fashion, openest, and inflammatory comments about Sun's control (of which i have been guilty), customers still have to make decisions, and the safe choice remains the 'legacy' platform of app servers...
    The Application Server has been replaced already. It started with Tomcat and Pico-container, then Spring and Hibernate and now Groovy and Grails looks very attractive. The components of JEE are thriving. It is the "certified platform" that has languished. I wouldn't go any where near WebSphere or Weblogic again and I know lots who say the same. The idea that the JCP has finally realised that people want to pick and mix the bits of JEE that suites them is laughable. Developers don't need permission, it has happened already. Just like the move to dynamic languages and the adoption of REST instead of WS-*. The community are voting with their feet and gestures like "JEE Profiles" are too little too late. BTW I agree that the legacy JEE platform is "the safe bet". Thats fine. It provides a natural home for the "risk adverse" enterprise. It isn't the future though which is why I believe that most forward thinking developers just won't be that interested in JEE6 in the same way that most didn't take much interest in JEE5. Paul.
  24. re: good post[ Go to top ]

    Paul, Fair enough, it is tough to understand the JEE5 market, especially with the leader (JBoss) not being in it... JEE6 is important to not just Sun, but to everyone who needs an alternative to a .Net world, including Spring, with or without profiles, good discussion, thanks for the participation, doug
  25. Re: re: good post[ Go to top ]

    Paul,

    Fair enough, it is tough to understand the JEE5 market, especially with the leader (JBoss) not being in it...
    Ouch (again) ;) As I've said before - JBoss implemented the more important and useful aspects of EE 5 two years ago - that choice was driven by customer demand. Also - I don't think IBM WAS is EE 5 certified yet; if you ignore WAS CE - like most people seem to :) Without getting into the details of which API is in which profile - I think the JCPs new stance - ie. standardizing what people already use vs. trying to inflict standards is very encouraging and should be encouraged. I don't buy the argument that portability will suffer as a result of the profiles. Everything we're talking about is based on open, stable, well adopted standards.
  26. Re: JBoss' official position[ Go to top ]

    Rich, Are you in Raleigh, is this the approved message of JBoss proper, and will it be the position of your organization that JEE6 profiles are not an imminent threat to the portability concept, put forward by 4 successive generations of releases that mandated compliance with a single specification?... If I understand correctly, if the above is true, your own and, by extension, your organization's position is that JBoss 4.2.x is 'good-enough' for compliance since it implemented the "most important and useful" standards in the spec., though not the complete spec., and though it is not certified as compatible with JEE5... your 3rd sentence is troubling, as EJB3 and WebBeans are direct results of the work by JBoss developers, and if I am catching your implication, it is fully supportable that people don't bother with these as they are being "inflcit"ed on the Enterprise Java market... in short, i couldn't more fundamentally disagree with your assertions, your position, and find that if this is the official position of JBoss, it is a massive deviation from its historical position on the fundamental value proposition of Enterprise Java...
  27. Re: JBoss' official position[ Go to top ]

    Hi Douglas, I like your passion, but I think that its misguided. I sense you are a true believer in open systems. I ask you to stop and ponder what "open" really means. The dream you have in mind is just that a dream. There is no golden specification, no golden hammer and the world is not a uniform place. Also the JCP is in no position to impose anything on anyone. Any specs they endorse are optional and it is up to the vendor and developer communities to opt in if they choose. Openness is not about imposing uniformity Stalin style, it is about creating open markets by removing artificial barriers to interoperability, competition and choice. In this regard the JEE Service API specs are adequate. As far as application servers are concerned, all that is needed here is pluggable architectures so that people can opt-in to services they choose. William is right, and RoR is a shining example (worked out with developer community consent and without the need for a proprietary pseudo standards body like the JCP incidently). As for SpringSource and JBoss what do you expect? They are just businesses not unlike the original cartel (Oracle, IBM, Sun), whom they hope to replace. They will exploit any advantage they can to gain market share. For JBoss it is JEE4 certification, for Spring it is ease of use or whatever. William, The grand plans of the original Java platform was nothing less then world domination. I sat through a number of architecture tutorials during 1998 at Valtech that made this very clear. The Java platform was meant to replace everything. We were even going to have Java in our jewelery :) In practice, reality kicked in and everyone soon realised that JEE would have to co-exist with ever else already existed in the enterprise. The "brown field" wasn't going anywhere, and EAI was born. At this point the market for JEE components evaporated (if it ever existed) since no one was about to throw out existing components and services and JEE would have to learn to interoperate with systems like SAP (as someone else as rightfully pointed out) through JCA, messaging etc. So where does that leave us today? Well it means the JEE platform was design for a purpose which no longer exists. World domination is no longer on the cards. The Cartel have been undermined by open source upstarts like SpringSource and JBoss and the vibrancy of the Java developer community as lead to a host of alternative solutions, including web frameworks, DI, ORM etc, finally culminating in Groovy/Grails, JRuby/Rails etc which make the original Application Server concept look pre-historic. It may be painful to hear this, but it is this very same vibrancy that is driving the Ruby and other dynamic language communities today, as some of the best Java developers move on to more fruitful ground. For example Groovy was an offshoot of the Pico-container project. Like I say, navel gazing... Paul
  28. Re: Navel gazing[ Go to top ]

    One more point. Just as world domination is no longer on the cards for the Java Platform, it is no longer on the cards for Microsoft either. I think that is has been paranoia at Sun and within some parts of the Java community over Microsoft that has led to poor vision and leadership. Well in the Web 2.0 world no one fears Microsoft. In that world Microsoft is an irrelevance. The web is an open platform, where even Lisp can thrive if you believe Paul Graham :) Microsoft can't own the web. They tried and failed, Apache/GNU/Linux and Mozilla made sure of that :) So now they are trying to buy there way in, but Yahoo isn't selling :) I believe the world is a much more open place now then it was in 1995. I believe that Sun could be much bolder in freeing up the Java market if it had the vision and courage to do so. I may be wrong, but services (rather then re-usable components) seem to be the future, and the web is a great service platform. If and when cloud computing takes off on the web, then enterprises are going to wonder why they can't achieve the same behind the firewall. At this point what ever standards are established on the web will find themselves within the enterprise as well. I believe this is the future we should be planning for. Paul.
  29. Re: JBoss' official position[ Go to top ]

    Rich,

    Are you in Raleigh, is this the approved message of JBoss proper, and will it be the position of your organization that JEE6 profiles are not an imminent threat to the portability concept, put forward by 4 successive generations of releases that mandated compliance with a single specification?
    Doug, it's precisely because I believe in standards and portability that I believe the profile idea is a good one. It remains to be seen if the EG can agree on the right set of APIs - but that's a tough one. Failure of the Java EE EG to do anything is the very thing that will fracture enterprise Java and cause Java EE to be less relevant to more people. Then you'll have a real portability problem. That's my opinion and I've stuck with it since we first started talking about profiles in 2004. You need to very carefully think through the consequences of what you're promoting.
    If I understand correctly, if the above is true, your own and, by extension, your organization's position is that JBoss 4.2.x is 'good-enough' for compliance since it implemented the "most important and useful" standards in the spec., though not the complete spec., and though it is not certified as compatible with JEE5...
    No it's not good enough for compliance - it's not certified and we don't hide that from anyone. We're not misleading anyone and we're not devaluing the Java EE brand.
    your 3rd sentence is troubling, as EJB3 and WebBeans are direct results of the work by JBoss developers, and if I am catching your implication, it is fully supportable that people don't bother with these as they are being "inflcit"ed on the Enterprise Java market...

    in short, i couldn't more fundamentally disagree with your assertions, your position, and find that if this is the official position of JBoss, it is a massive deviation from its historical position on the fundamental value proposition of Enterprise Java...
    My position is consistent - JBoss has done as much as any vendor to improve enterprise Java and further it's adoption. Not by force feeding people technology they don't want but by improving the fundamental technology itself and giving developers what they want. It's completely irrational, IMO, to believe that if everyone rallies around Java EE then everything will be fine. Many developers have turned to alternative frameworks, technologies and even languages because Java EE hasn't given them what they want. This is not a potential future threat - this is a well trodden path and has been for a couple of years. Rich Sharples JBoss, a Division of Red Hat http://blog.softwhere.org
  30. have we ignore other..[ Go to top ]

    - I think community overlooks other serious vendors like SAP. Wasn't j2ee server suppose to replace legacy erp's it was the business case. Then they shifted focus to integration, websrv etc.. I have done lot of integration work, one of our client want to migrate all it apps to SAP including integration in NetWeaver. I know netweaver is java server but still a black box for integration consultant like me. - Thanks Amit
  31. Re: have we ignore other..[ Go to top ]

    Are you referring to the early days of EJB when vendors like IBM were promoting a market for reusable business components? IBM create their "San Francisco Project" which supposedly had some 3000 EJBs implementing accounting and some other common business functions. Of course the idea of EJBs being components much less portable and for which there would be a market never panned out. J2EE and Java still don't support component packaging and deployment very well. We're still struggling with that - trying to use OSGi bundles and jsr 277 to fix that. It's no wonder companies like SAP did not see the value of decomposing their products into components and rewriting them to run in application servers. So now we use web services or JCA to connect to them instead. That was probably always going to be the more practical path anyway.
  32. Paul, I am interested in what you see the alternative to JEE being? As far as I can see it there's only really .NET which provides the complete platform needed to build complex enterprise applications and then only on Windows. IMHO Spring is just JEE with the bits they don't like missed out (Session Beans) and a load of proprietary apis thrown in. REST and WS-* services are just the protocol and tend to be written in JEE or .NET so this in not the alternative. I also don't see how the application server has already been replaced, Tomcat is an Application Server and so is the Spring server they just don't support the full JEE spec. There were application servers before JEE and if JEE disappears there will be application servers after as well, just supporting different standards. WebLogic and WebSphere have their place, if you've ever had to roll out, monitor and tune a production infrastructure containing multiple clusters with 10+ managed servers then you'll understand where I'm coming from. I hear a lot of people saying that JEE is dead but currently I don't see what the alternative is. Steve http://www.c2b2.co.uk
  33. Hi Steve,
    I hear a lot of people saying that JEE is dead but currently I don't see what the alternative is.
    Really? I find this hard to believe. Let me quote Reza on the role of Profiles:
    * It makes being Java EE certified easier, especially for new entrants and I am not talking about just SpringSource. * It counters the claim (correct or off-base) that Java EE is bloated and intended only for large corporations. * It hopefully sends a signal to vendors that they should make application servers more lightweight and hence more manageable (in terms of start-up time, installation, configuration, deployment, administration, etc), as opposed to what I see happening in the past -- vendors treating the app server as a vehicle to sell high-end products -- thus turning the entire Java EE concept into a way of selling bloatware... * From the developer end, I think it eases the learning curve in that you don't have to deal with a whole host of APIs that are really pretty high-end -- beginning from JMS to JCA and the like...
    Which is why people started to create simpler alternatives in around 2000. There are many and the choice is not either EJB or Spring even though Rod Johnson would like you to believe so:) Like I said before, JEE already splits out services into seperate SPIs and most (90%?) of JEE applications are simple Web applications requiring just a web container (Tomcat). On top of this you can mix in any JEE service you like yourself without EJB or Spring. I think the issue is cultural. If you are willing to take responsibility for your own solution and follow the YAGNI principle, then you have a wealth of alternatives available to you that allow you to create simple light weight Web Applications. This can be done very easily and simply without the need for the whole JEE platform. Let me list a few things at your disposal: * Freemaker/Velocity (templating languages) * A whole host of web frameworks * Guice, Picocontainer, Hivemind, Xworks,... as IoC Containers * A whole bunch of Persistence solutions based on JDBC * ... And this is before I mention the non Java JVM/JEE options like JRuby and Rails, Groovy and Grails and coming soon Jyphon and Django. All of this has been created by the Java community and is available open source. The JEE service APIs are sufficient IMO, Application Servers are just vendor lead bloat-ware. Here is a link to a very good book that describes the JEE open source alternative: http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471463620.html Paul.
  34. Paul, I agree there are alternatives if you are only developing lightweight web applications however if you need to go beyond that and integrate your web application into the rest of the organisation's architecture then these are not really a complete alternative. If you need asynchronous messaging then you need JMS, if you need multiple resources in a transaction then you need JTA, if you need to invoke components remotely then you need EJB or Web Services all of which are components of JEE. I still think splitting JEE into profiles removes the ability to move up to these apis if they are needed. I've seen this before with people deploying to Tomcat, suddenly their requirements change and they need JMS in their architecture, then they start having to find and bolt in a JMS implentation or migrate their solution over to Glassfish or JBoss or another JEE application server. I think my definition of an application server is broader than yours, to me an application server is a server process that serves applications and handles all your workload management, clustering, fail over, connection pooling, socket handling, thread management, transaction management etc. for you, while you concentrate on writing the code. In this way Tomcat and the other "light-weight" containers are application servers just not JEE compliant application servers. When your choosing which application server to deploy to you need to assess whether it satisfies your non-functional requirements for Cost, Performance, Scalability, Availability, Manageability, Supportability, Security etc. This is where the JEE vendors try to distinguish their offerings, with JEE, as it's a standard, at least there is competition and we get a choice. Fragment or destroy this and we remove the choice and we're back to the 90's, before JEE, building enterprise applications with proprietary apis targeted to a single vendor's application server. Steve http://www.c2b2.co.uk
  35. Paul,

    I agree there are alternatives if you are only developing lightweight web applications however if you need to go beyond that and integrate your web application into the rest of the organisation's architecture then these are not really a complete alternative.
    Hi Steve, Respectfully, I must say I disagree. I have done a lot of EAI integrating with true enterprise back-end systems. Integrating using messaging is just as easy from a servlet as from an EJB. As for distributed transactions and two phase commit, 99% of applications don't need it. Those that do were probably doing it long before JEE, using something like Tuxedo or Cobal/CICs. Again you can integrate with these heavy weight back-ends using messaging if you really need to. Like I said, the real issue is cultural. If you focus on simple design and only use the features you really need when you need them (YAGNI), then you can get away with a much lighter solution most of the times. If you go beyond the marketing, the real use-cases for a full blown Application Server are relatively few. Paul.
  36. Hi Paul, I think you are misinterpreting my points. My initial question was what is the alternative platform to JEE that gives you everything JEE gives you i.e. Web Applications, Web Services, Remote Objects, ORM mapping, Messaging, JTA, Database Access etc. The only alternative I see is .NET in the windows world. You can argue whether you need this stuff, some people do and some people don't, everybody will have a different perspective on which bits are important to them many of our customers need the whole stack. At least with a JEE compliant app server they know they've got it, this may change with profiles. My point on application server choice is that when choosing an application server for deployment you have to move away from a developer perspective and look at what people need to do to support the solution operationally. At this point your priorities change and light-weight does not necessarily mean better. With JEE, as it is a standard, I can develop on a light-weight server and deploy to a server which provides heavyweight operational support. Steve http://www.c2b2.co.uk
  37. Hi Paul,

    I think you are misinterpreting my points. My initial question was what is the alternative platform to JEE that gives you everything JEE gives you i.e. Web Applications, Web Services, Remote Objects, ORM mapping, Messaging, JTA, Database Access etc. The only alternative I see is .NET in the windows world. You can argue whether you need this stuff, some people do and some people don't, everybody will have a different perspective on which bits are important to them many of our customers need the whole stack. At least with a JEE compliant app server they know they've got it, this may change with profiles.

    My point on application server choice is that when choosing an application server for deployment you have to move away from a developer perspective and look at what people need to do to support the solution operationally. At this point your priorities change and light-weight does not necessarily mean better. With JEE, as it is a standard, I can develop on a light-weight server and deploy to a server which provides heavyweight operational support.

    Steve
    http://www.c2b2.co.uk
    Hi Steve, I understood your question. My point is that they are viable alternatives both for development and deployment. Just take a look at a typical RoR deployment on the web and you will see that there are simpler viable deployment alternatives that provide similar reliability and performance. The same applies to Java deployments. Many people are using mutiple Apaches, Tomcats, Squid Servers, hardware load balancers etc without an Application Server in sight. Paul.

  38. Hi Steve,

    I understood your question. My point is that they are viable alternatives both for development and deployment. Just take a look at a typical RoR deployment on the web and you will see that there are simpler viable deployment alternatives that provide similar reliability and performance.

    The same applies to Java deployments. Many people are using mutiple Apaches, Tomcats, Squid Servers, hardware load balancers etc without an Application Server in sight.

    Paul.
    Paul, By operational perspective, I think Steve was thinking about the ability to monitor and manage (via JMX and other technologies) large numbers (10s) of clustered servers in a consistent and controlled manner across the enterprise, in a manner that allows for completely seamless failover (down to the level of JTA transactions). Large organisations (national government, multinational corporations, etc) usually look for this kind of functionality in their larger systems, and these kinds of requirements for operational systems can be pretty intense. I also think we are talking about different scales here, RoR and similar languages are absolutely great for throwing together interactive web sites and data driven applications, but the big players (banks, government departments, telcos, etc) still seem to be betting on Java EE for their larger systems. When I see banks start to implement trading systems in RoR, I will consider it as an alternative to Java EE, until then, I see it (and similar technologies) as operating in a different niche. Matt http://www.c2b2.co.uk
  39. Paul,
    By operational perspective, I think Steve was thinking about the ability to monitor and manage (via JMX and other technologies) large numbers (10s) of clustered servers in a consistent and controlled manner across the enterprise, in a manner that allows for completely seamless failover (down to the level of JTA transactions). Large organisations (national government, multinational corporations, etc) usually look for this kind of functionality in their larger systems, and these kinds of requirements for operational systems can be pretty intense.

    OK. I agree these are intense requirements Failover protection? Well if you truly need this then an Application Server is definately on the cards.
    I also think we are talking about different scales here, RoR and similar languages are absolutely great for throwing together interactive web sites and data driven applications, but the big players (banks, government departments, telcos, etc) still seem to be betting on Java EE for their larger systems.

    When I see banks start to implement trading systems in RoR, I will consider it as an alternative to Java EE, until then, I see it (and similar technologies) as operating in a different niche.

    Matt
    http://www.c2b2.co.uk
    There is always a degree of inertia in large instituitions. As Doug pointed out earlier, such organisations tend to be risk adverse and they want a vendor on the hook to blame when things go wrong. Such cultural/political concerns can be very different from the actual application requirements. I come from a telco background and most/all of the heavy lifting was done in C/C++. Java was used for EAI, which meant the integration of backbone services and web presentation. Light wieght JEE or RoR etc are ideal for such requirements. I have yet to see people replace heavy weight back-end systems with Java, but it has been over eight years since I last worked inside a telco so things may have changed. The real issue is the actual application requirements. Fail-over protection is a pretty high level of service guarantee. What is the mean time to failure of modern hardware? What are the consequences of your user lossing his/her session? If you really do need fail-over protection then I agree that an Application Server is a valid option. The question in most instances is whether you really need it? Paul.
  40. Re: navel gazing[ Go to top ]

    Paul, You said you thought that Java EE would be replaced by "clouds", but those cloud services have to be implemented in some technology. They aren't really clouds you know. ;) Also, in the enterprises I've worked in we have too many core business applications that we have to create ourselves. Our non-core applications can move to packages applications and clouds, but they don't constitute the bulk of our computing requirements. So we have to implement our enterprise services in something and Java is our choice for new development. As to your point about the "open standards" based parts of Java EE, I differ somewhat with your analysis. The standards you cited are the easier ones to implement (as a vendor) and the easiest ones to use as a developer. I think “easy” is more important here than “open”. A big problem with the EJB side of Java EE is that it has been too complicated relative to the value it delivers in most cases. (I also think the whole Entity bean thing was an abomination.) There have been improvements in the Java EE spec over time, but it has always been a bit of too little and too late. Other J2EE application server services are also becoming redundant. Today we can push many of the Java EE services down to the ESB, network and system platform (e.g. VM management). You don’t need an app server for managing or balancing workloads, managing failover or multi-protocol support. When you strip it all down, the only thing in the Java world that requires Java EE is the "global transaction" which is generally associated with two-phase commit, but which is also used to flow transactions to other TMs. The implementation of the JTS has always been the most proprietary part of most application servers, especially BEA’s and IBM’s. If you recall, back in the early days before J2EE became an official standard (2000), BEA and IBM were implementing their Java transaction management as thin layers on top of their proprietary TMs, Tuxedo and Encina respectively. Today, the only argument we (where I work) have for using WebSphere is its ability to integrate with our legacy COBOL/CICS. There is literally nothing else it does for which there isn’t a better, cheaper and easier alternative.
  41. Re: navel gazing[ Go to top ]

    Paul,

    You said you thought that Java EE would be replaced by "clouds", but those cloud services have to be implemented in some technology. They aren't really clouds you know. ;) Also, in the enterprises I've worked in we have too many core business applications that we have to create ourselves. Our non-core applications can move to packages applications and clouds, but they don't constitute the bulk of our computing requirements. So we have to implement our enterprise services in something and Java is our choice for new development.

    As to your point about the "open standards" based parts of Java EE, I differ somewhat with your analysis. The standards you cited are the easier ones to implement (as a vendor) and the easiest ones to use as a developer. I think “easy” is more important here than “open”. A big problem with the EJB side of Java EE is that it has been too complicated relative to the value it delivers in most cases. (I also think the whole Entity bean thing was an abomination.) There have been improvements in the Java EE spec over time, but it has always been a bit of too little and too late. Other J2EE application server services are also becoming redundant. Today we can push many of the Java EE services down to the ESB, network and system platform (e.g. VM management). You don’t need an app server for managing or balancing workloads, managing failover or multi-protocol support.

    When you strip it all down, the only thing in the Java world that requires Java EE is the "global transaction" which is generally associated with two-phase commit, but which is also used to flow transactions to other TMs. The implementation of the JTS has always been the most proprietary part of most application servers, especially BEA’s and IBM’s. If you recall, back in the early days before J2EE became an official standard (2000), BEA and IBM were implementing their Java transaction management as thin layers on top of their proprietary TMs, Tuxedo and Encina respectively. Today, the only argument we (where I work) have for using WebSphere is its ability to integrate with our legacy COBOL/CICS. There is literally nothing else it does for which there isn’t a better, cheaper and easier alternative.
    Hi William, I agree with what you say here. What goes "inside the cloud" hasn't been "standardised". Personally I think that is a good thing. I think that standards should be applied to stable, global accepted interfaces, anything else is premature standardisation and can inhibit innovation. For example, web standards are implementation technology independent which means that all programming languages are first class citizens on the web. Personally I think this is a good thing. I also like the idea of extensible standards. The Atom protocol is a good example of this. As for my analysis, well it was more of a statement. I agree with your analysis though. I still think that even a simple EJB standard would have been premature. I just don't think a third party market in re-usable enterprise components was feasable (in hindsight). Looking outside Java, RoR or Django are not standards. They are just frameworks based on a well understood MVC design pattern. This allows alternative frameworks that conform to the same HTTP/CGI and SQL interfaces to compete equally. This is what I mean by open. The whole Java platform thing only worked as long as you used Java everywhere and an Application Server for everything. This doesn't provide much choice. It is an all or nothing proposition irrespective of your actual requirements or preferences. Open systems should allow you to mashup solutions using various technologies, which is what is occuring on the web right now. They should also leave the door open to future innovations which is something I believe that the web as achieved successfully over the last 15 years. Paul.
  42. Re: navel gazing[ Go to top ]

    Hi William, What you said has got me thinking:
    Today we can push many of the Java EE services down to the ESB, network and system platform (e.g. VM management). You don’t need an app server for managing or balancing workloads, managing failover or multi-protocol support.
    Web standards focus on loose coupling and service interfaces. Implementations are deemed private and are not governed by standards. This means that how a service is implemented can evolve over time without breaking the standard. You make a good point that a number of Application Server features could be pushed into the VM, perhaps with direct support in the Java language itself. So why were these things ever seen as good candidates for standardisation in the first place? I think we need to look at motive here. Was the purpose of the JEE standards to provide standard interfaces so that Java systems could use external services (e.g. XA, SQL, HTTP/CGI, etc) in a standard way? Or was the purpose to generate a third party market in internal Java software that vendors could exploit? "Standards" like JSF, EJB, and the JEE platform (Application Server) seem to be purposed to address the latter concern. In effect they are aimed at solving a problem Java developers never had in the first place. Paul.
  43. Re: navel gazing[ Go to top ]

    If you recall at the time it was being introduced, J2EE was often spoken of as a Java version of CORBA 3.0. So, it seems that they were just copying the architecture of older application servers, i.e. Tuxedo, Encina and CORBA. These app servers were trying to fill in the gaps of what was missing from the underlying infrastructure and trying to do so in a way that was (system) platform independent. However, times have changed and now we have many more tools and capabilities for doing this. It seems that we've grown an entire new layer of infrastructure between the app server and the O/S that decouples the application and its run-time from the supporting infrastructure. These infrastructure services and capabilities either implemented with with open standards APIs or completely transparent to the application seem to be obsoleting the traditional application server architecture and raison d'etre.
  44. Re: navel gazing[ Go to top ]

    If you recall at the time it was being introduced, J2EE was often spoken of as a Java version of CORBA 3.0. So, it seems that they were just copying the architecture of older application servers, i.e. Tuxedo, Encina and CORBA. These app servers were trying to fill in the gaps of what was missing from the underlying infrastructure and trying to do so in a way that was (system) platform independent. However, times have changed and now we have many more tools and capabilities for doing this. It seems that we've grown an entire new layer of infrastructure between the app server and the O/S that decouples the application and its run-time from the supporting infrastructure. These infrastructure services and capabilities either implemented with with open standards APIs or completely transparent to the application seem to be obsoleting the traditional application server architecture and raison d'etre.
    Yes, you are right. I remember evaluating an early version of Oracle Application Server (OAS). It was just a Java wrapper around a C/C++ CORBA product and it didn't work :). Then there was NetDynamics which was a CORBA application server which was seen as the bench mark at the time. The NetDynamics wikipedia entry makes interesting reading: http://en.wikipedia.org/wiki/NetDynamics_Application_Server Finally Weblogic turned up and it was a stable pure Java implementation that worked well. I remember thinking that a lot of this App Server stuff was premature, who knows what the future may bring? Back then it was the best show in town, and it gave us more than we needed, so we jumped onto the bandwagon like everyone else :) I guess we should remember the past less we repeat it :) Paul.
  45. Re: navel gazing[ Go to top ]

    William, As I recall it we always had many tools and capabilities for doing enterprise development unfortunately they all had vendor specific proprietary apis. JEE was an attempt to give developers a standard way of accessing this infrastructure e.g. JTA for TP Monitors, JMS for messaging systems, JDBC for database, JavaMail for email servers etc. Servlets for CGI, JSP for web scripting, JCA for EAI, EJB for CORBA like functionality and to make the semantics of RMI better defined. I think where it went wrong a bit was to start defining things like JSF and to some extent JPA (although EJB 2.x entity beans needed to be killed off some how). IMHO JEE shouldn't dictate how developers build applications just how developers access external resources. The argument over whether application servers are a good thing is orthogonal to whether JEE is a good thing. Application servers were around before JEE and are still around w/o JEE. ROR, Apache (PHP), Mule, Spring AS and Tomcat are application servers just not JEE compliant application servers. Pushing the Application Server into the OS is the Microsoft .NET approach as a Java developer I want to be O/S dependent so I need a whole set of apis to insulate me from this, JEE anyone? Steve http://www.c2b2.co.uk
  46. Re: navel gazing[ Go to top ]

    Steve, I agree that the Java EE value proposition versus the proprietary app servers was in large part the open APIs that abstracted way proprietary services and capabilities. That was an improvement, but one CORBA already provided - which is why people often referred to J2EE as CORBA 3 for Java. I don't think J2EE went far enough in terms of abstraction and it was still too complex in too many ways. Why all the EJB interfaces? Why was there more than one call required to invoke an EJB? Why do I have to see all that? As to my argument that the application server architecture of the 1990's (including Java EE) is too much and most of it is no longer necessary. I wasn't talking about pushing the application server functionality into the O/S. I'm referring to a new layer that has sprung up between the O/S and the execution environment - where the app server lives. That layer includes the ESB, smart network devices, storage subsystems and virtual machine management (e.g. hypervisors and surrounding management). These things weren't around when the first application servers (pre-Java EE) appeared. They weren't around when J2EE appeared either. Today I can load balance, do fail over, work load manage, secure and everything else an application server does - except global transaction management - without using an application server and without relying on the O/S. I'd keep the interfaces and JTS, but I'd provide them as components (OSGi) that you can install into the JVM as you need them. The products should be the components and not a huge monolithic application server. What Spring has done with their platform is a good step in that direction. As for JSF and JPA (I like JDO), I think what you are getting at is the plethora of various specs, frameworks and concepts that are in some cases overwhelming developers. I agree, but I these things have people who want them, but that's where the installable components come in. JSF, JPA - pretty much everything - should be installable components that you use if you want to and leave out and ignore if you don't. Bill
  47. Re: navel gazing[ Go to top ]

    Hi William,
    I agree, but I these things have people who want them, but that's where the installable components come in. JSF, JPA - pretty much everything - should be installable components that you use if you want to and leave out and ignore if you don't. Bill
    Agreed. This is to answer to keeping everyone happy. They do this in RoR with their plug-in mechanism. Paul.
  48. Re: .Net profiles[ Go to top ]

    I'll leave it to you guys to decide whether this is relevant to this discussion: http://www.theregister.co.uk/2008/08/11/visual_studio_sp1_milestone/
  49. Re: navel gazing[ Go to top ]

    William,

    As I recall it we always had many tools and capabilities for doing enterprise development unfortunately they all had vendor specific proprietary apis. JEE was an attempt to give developers a standard way of accessing this infrastructure e.g. JTA for TP Monitors, JMS for messaging systems, JDBC for database, JavaMail for email servers etc. Servlets for CGI, JSP for web scripting, JCA for EAI, EJB for CORBA like functionality and to make the semantics of RMI better defined.

    I actualy agree with you Steve. These were all good things. At issue is the bundling.
    I think where it went wrong a bit was to start defining things like JSF and to some extent JPA (although EJB 2.x entity beans needed to be killed off some how). IMHO
    I agree here too.
    JEE shouldn't dictate how developers build applications just how developers access external resources.
    I totally agree. If Sun had stopped here then I wouldn't be complaining :)
    The argument over whether application servers are a good thing is orthogonal to whether JEE is a good thing. Application servers were around before JEE and are still around w/o JEE. ROR, Apache (PHP), Mule, Spring AS and Tomcat are application servers just not JEE compliant application servers.
    Yes I agree. But they are all diferent types of Application Server, targeting diferent market segments. The one size fits all is where JEE got it wrong. It is also why Bruce Tate wrote his famous "Don't let me eat the Elephant Again" article. Profiles could be the solution, but they are coming pretty late in the day.
    Pushing the Application Server into the OS is the Microsoft .NET approach as a Java developer I want to be O/S dependent so I need a whole set of apis to insulate me from this, JEE anyone?

    Steve
    http://www.c2b2.co.uk
    People are pushing stuff into the VM with Ruby too. Take a look at Maglev which is building on the Gemstone "Application Server" by embeding distributed persistence within a Ruby VM. There should be scope for this type of innovation within the Java world too. Hopefully now Java is open sourced such things are now possible. Paul.
  50. What about it? In a world that is moving towards cloud computing is JEE still relevant?

    This whole discussion looks like navel gazing to me. Outside Sun and the closed world of the JCP does anyone care? Judging from the particpants in this thread I guess not.The discussion about profiles has more to do with JEE application server certification then anything else. Who needs them? The world has moved on, and thats a good thing.

    Agree! Paul, guess what d real problem(there is one u'll agree) is?IMO ->lack of developer-friendly innovation.An annoying absence of tools that just work both for the average developer and the oft-evangelized "enterprise applications" diehard zealots.I'll love to see a new JEE that can best the C# 2008+LINQ+ASP.NET 3.5+WCF+IIS combination. That would be some innovation(developer-friendly that is).
  51. Re: What about Java EE 6, anyway?[ Go to top ]

    The discussion so far seems to reflect my own suspicion that Java EE adopters wouldn't really care about Profiles that much anyways and neither do folks that are not Java EE adopters. I hope that's not really true. Personally, I see Profiles as valuable for the following reasons: * It makes being Java EE certified easier, especially for new entrants and I am not talking about just SpringSource. * It counters the claim (correct or off-base) that Java EE is bloated and intended only for large corporations. * It hopefully sends a signal to vendors that they should make application servers more lightweight and hence more manageable (in terms of start-up time, installation, configuration, deployment, administration, etc), as opposed to what I see happening in the past -- vendors treating the app server as a vehicle to sell high-end products -- thus turning the entire Java EE concept into a way of selling bloatware... * From the developer end, I think it eases the learning curve in that you don't have to deal with a whole host of APIs that are really pretty high-end -- beginning from JMS to JCA and the like... I definitely think the JCP is a much more open process than most people realize :-). I also strongly believe that we need something more than just one minimal Web Profile that's really just a Servlet container... Cheers, Reza
  52. Re: 4 v. 1[ Go to top ]

    Reza, You have been the single best communicator for the JEE expert committee probably in its history, as u have correctly assessed that candor has been one of the problems of the limitations, whatever they may be, of JEE adoption, so good job, and much appreciated, my main point remains: your four bullet-points are all valid, and agreeable, but do they trump the problem that I have identified at least in this thread, of the halt on portability that would be a result of the profile implementations... can you recommend how the portability value proposition, which seems central to JEE, will be accounted for if the profiles implementations are certifed JEE-compatible... how should it be said to customers?...how should developers mitigate the information that will be needed to know what platforms adhere to what - - will the JCP sponsor something akin to TSS' Application Server Matrix, or will it pay TSS to do so, its going to get a lot more complicated if the profiles implementations are included in the final release of JEE6, so a lot more coordinated information will be needed, do you agree?...
  53. Re: 4 v. 1[ Go to top ]

    Doug: First of all, I really appreciate the kind words. I'm just trying to do what I think is best for an industry/profession that I've put in a lot of years into and hopefully will be putting in a lot more years into. And thankfully I'm not just talking about Java EE but enterprise computing in general :-) I agree the two biggest risks with Profiles are compatibility and developer confusion. And believe me these problems are not being overlooked. In fact, it's been the biggest issue talked about in the expert group and from my own perspective in private one-on-one discussions. The danger is particularly significant if the minimal Web Profile is the only one around... I think the danger is offset by two facts: * To some degree the lack of compatibility and fragmentation in Java EE has already taken place. The Web Profile just makes this fact official and acknowledging what a whole bunch of people are already doing. In a way, the minimal profile just brings these incompatible configurations under the Java EE umbrella so that hopefully folks using these configurations see themselves as part of a bigger picture rather than the currently rampant "step child/outsider" sentiment, especially in some segments of the open source community. And again, I'm not just talking about SpringSource. * I am currently working with SpringSource to see if they would support more than just the minimal Profile. Thus far, the answer has been a yes (albeit its not the resounding yes I would hope for). I think this small fact goes a long way to solving the compatibility issue given SpringSource thought leadership among countless people in the industry. I think the message from SpringSource is that they are also *for* putting the choice of which Profile is right for them in the hands of developers, not the hands of vendors... At any rate, great post and thank you for sharing your thoughts. I'll try to see that other folks on the EG read your blog too... Cheers, Reza
  54. Re: JEE6 podcast[ Go to top ]

    All, Here is a recently published podcast on JEE6: http://blogs.sun.com/glassfishpodcast/entry/episode_015_java_ee_6 I couldn't sit through the whole thing, its too late right now to listen to the same pitch that i have basically heard before, but a couple of thoughts: 1. The expert committee is operating according to market principles more than at any other time, in other words, they are responding to purported demand, which i would like to assume this is a good thing, though i think it would be good to provide some data points on why certain changes have been included in JEE6; all in all, i think things look fairly o.k.... 2. There is next to no, if not zero, discussion on the topic of profiles and the impact on portability, which raises a question concerning Reza's response that he feels that it is priority #1 with the expert committee; if this were actually the case, wouldn't we have a better understanding of how to manage the transition to non-portability... 3. This profiles, pruning, extensibility, and scripting focus is a done deal, as i suspected, there is no way that things are going to be re-evaluated this late in the stage of development of the specification, but I thought it would be good to raise on TSS anyway, this has been a good discussion, even if influencing decisions at this point will be minimal... 4. The lack of clear-cut support for WebBeans, and especially JBI as a requirement in the spec. is disappointing and a missed opportunity; sometimes, especially recently, Sun has not had the guts to stand up to vendors with vested interests that go against enhancements to the Java platform, in the name of 'big-tent' policies...though WebBeans may get in, JBI will not, and that doesn't make sense to me... all in all, the JEE6 EG is doing a fine job, getting this important release ready, so i am content that things will probably work out, but i would be remiss if i don't fully re-state the main outstanding caveat: in the interests of detente with Spring, primarily, and with potential web-tier developers, secondarily, the portability issue needs more emphasis, more support, and more information provided as to how to keep the dream alive: a fully functioning developer-led marketplace of components and applications that can be deployed across a broad range of platforms without the enormous costs typically associated with such porting; this is a value proposition that .Net can ensure, and even Spring, due to its monopoly and total control of technology standards utilized in their platforms: what will remain as JEE's distinguishing competitive advantage?...
  55. Re: JEE6 podcast[ Go to top ]

    The second part of the podcast (Q&A session) will be posted tomorrow. It starts off with Web Profile questions...
  56. Re: merci[ Go to top ]

    Looking forward to the Q&A...
  57. Re: JEE6 podcast[ Go to top ]

    Doug:
    This profiles, pruning, extensibility, and scripting focus is a done deal, as i suspected, there is no way that things are going to be re-evaluated this late in the stage of development of the specification, but I thought it would be good to raise on TSS anyway, this has been a good discussion, even if influencing decisions at this point will be minimal...
    I don't think this is entirely true. As I said, I'll try to make sure at least some folks in the EG look at what was said here. However, at the end of the day, it's important to recognize that none of this is black and white, so there is no solution that will make everyone happy all the time...that being said, clearly it's in no one's best interest to do something that has serious shortfalls... Cheers, Reza
  58. Quite right but...[ Go to top ]

    ...the crucial thing is not so much portability of applications but portability and exposure of developers. With J(2)EE you could be fairly sure that people who mastered building on top of Oracle Application Server would make a decent job when building on top of WebLogic or Glassfish. When people only used Tomcat there was a large chunk of programming paradigms they were quite probably not exposed to. So when today, somebody anounces himself as a JEE developer, I would expect decent knowledge of Messaging, JPA, EJBs, Servlets, JSP, JSF, Database Access and Application patterns for WebApps and EJBs in general...
  59. Re: What about JEE 6, anyway?[ Go to top ]

    Greetings everyone. Let me introduce myself and I'll see if I can provide a little more insight around profiles. I'm the IBM guy responsible for our Java EE delivery. I'm also a long standing EE EG member, former EJB EG member, was the spec. lead for JSR 109 (Web Services for EE), and have been involved in J2EE since before there was a J2EE. I can trace back the rationale for why the EJB architecture is the way it is and the origin of CMP/BMP. J2EE was started as a platform to contain everything an enterprise needed for an IT environment and even today with all we have added, we are not there yet (e.g. processes and portals). IBM has always been committed to standards. Yes, we do offer proprietary APIs and services, but generally this is done because the market has requested the function and there is not a broad enough interest to provide standardization. We generally hear from our customers when lack of standardization in some particular area is causing problems and we try and fix it. Standards are key to building a strong ecosystem. They serve two purposes: portability and interoperability. While it is possible to succeed solely on being innovative and we certainly encourage it when we can, it is much much more difficult to do that. My hat is off to anyone that is able to be successful solely on their own proprietary innovation. One of the things we've heard in the past is EE is too big or too monolithic. There are customers (or potential ones) that do like what EE offers, they just aren't interested in all of it. Some of these claims are based on reality, some on just hype from people driving particular agendas, some is just negotiating tactics for getting a better deal. Regardless, it's a perceived market need. When a vendor recognizes a perceived market need, they will naturally attempt to react to that. After all, a vendor that doesn't address market needs won't last very long. A vendor needs freedom of action to be able to react to market needs in a timely fashion. There are a number of things we can do to address the perception of bloat. One is that we start getting rid of the technologies that nobody took an interest in or were introduced too quickly and have now been bypassed by other technologies. Examples of this are EJB CMP/BMP, JAXRPC, and JSR88. I don't think removing these helps much with the physical bloat problem, but it helps immensely with the conceptual bloat problem. In other words, how much do you need to understand to know what Java EE is all about? Are there concepts that aren't worth learning any more and we should drop them? I think the answer is yes and this will do a lot for reducing "bloat". Another thing we can try to reduce bloat is to look at consolidating gratuitous conceptual differences. How many filters, handlers, and interceptor models do we really need? How many different ways do we need to represent business logic? Each of these differences may add value, but they add cost in terms of skills required to understand and use them as well. As a platform, we need to look at ways to get more consistency rather than looking like a bunch of piece parts thrown together. I'm not saying to ignore value, but we need to think bigger than individual technologies and their definition of some API. Lastly, we get to profiles. Remember in my first few statements that the vendors really are looking for freedom of action? Today, the Java EE platform is defined as one thing and one thing only. It's basically an all or nothing affair and there is a compliance test suite that validates that all or nothing proposition. In some cases, JSR technologies have evolved independently from the EE platform and retain a TCK that can be used to individually determine compliance of the inclusion of that in a product. However, those few independent technologies are not generally enough to adapt to changing market needs. So, we have a practical limitation. To be compliant, you have to pass a test suite and the test suite says it's all or nothing. We could try to fix the practical limitation, but there's a HUGE effort required to make that happen for the general case. Certainly, it would be ideal (from a vendor perspective) if any technology could be combined with any other at any time. This provides the most freedom of action. However, it does one other thing. It offers no guidance whatsoever on what APIs a developer should constrain themselves to in order to be portable to other app server runtimes. The idea of profiles is that it DOES provide guidance on what APIs you can use and be portable. In addition, if the evolution of your application requires more than a profile can offer, it should be seemless to move the app to full EE and take advantage of additional capabilities. This is not the ideal case, but seems to be the best compromise between allowing freedom of action to address market needs yet still retain the concepts of a platform. Looking around at the various discussions I've seen on EE profiles, there seem to be two philosophies. One philosophy is essentially geared towards a roll your own app server and the other is essentially a regression of sorts to J2EE's roots. The roll your own app server variant defines a core kernel of function (servlet and JSP), but everything after that is up to the developer to add to their own taste. This is designed to appeal to those that like complete control over what they use. However, I don't view this as a platform and yes, the only portability here is if you constrain your app to servlet and JSP. As such, I have to say I'm not in favor of this. I agree that this pattern can be used to build some really cool stuff, but I can do that today with Tomcat++ and I don't need a platform moniker to make it happen. The original J2EE platform had enough technology in it to cover presentation, business logic, and persistence. Those are the core essentials to an enterprise and you can do quite a lot with just that set of technology. The mini-platform camp is attempting to address this core set of requirements, but using current technology. In other words, start with a proper subset of EE that addresses the core needs of a business and if the business needs more, there's a simple means to grow. In this case, there is portability because all the technology you need is there and compatible as you move from runtime to runtime or profile to full EE. As a compromise between flexibility and retaining the value of a platform, it works for me. I hope this helps explain some of the rationale around profiles and I thank all of you for caring enough to speak up and voice your opinion. No matter what you may think, we really do try to listen.
  60. Re: What about JEE 6, anyway?[ Go to top ]

    Hi Jim, Thanks for tis insight. It is always interesting to hear the perspective from some one on the other side of the vendor/developer fence. There are three themes that you mention that interest me: 1. Portablility 2. Innovation 3. Standards Portability of runtime components from one platform implementation to the next is a pretty high ask, and I'm not sure whether it is something that developers are specifically interested in. For example, we never had this with Unix. At the least you had to re-compile your source code for each platform, and at worst you needed write a far amount of platform specific code. The GNU build has a configure phase for example, where platform specifc issues are addressed. Yet people see Unix as an open, portable environment, why? I would hazard a guess and say that people are more interested in conceptual portability first and foremost. Source and binary code portability are nice to haves but not essential. Knowing that all Unixes work more or less the same is a massive benefit, and allows different Unixes to innovate and differentiate themselves by addressing different market niches. I'm writing this on Mac OSX for instance, which is Unix, but a vary different variant then HP/UX or AIX. This brings me to the next point, Innovation. IBM has a massive research budget. What is research for if not to innovate? Alan Kay talks about the pink plane which is incremental improvements on what we have now, and the blue plane which is orthogonal to this and represents a conceptual shift, a new way of thinking that provides a step change improvement over what we have now. Surely it is important to your customers that what they pay in license fees is invested into researching "blue plan" alternatives? The fruits of this investment may break concept portability over what they have now, but it may also represent a massive improvement and hence a massive return on investment to your license paying customers. This brings me to my last point: Standards. What are they and who do they serve? The enterprise contains lots of technologies, representing different waves of "blue plane" thinking. From Mainframes to Mini-Computers all the way up to modern PDAs like the Blackberry. It is unreasonable to expect binary portability of software components across all these technologies. At best all that can be hoped for is that these technologies are made to interoperate, working together to provide a functional whole. To my mind this is the primary role of standards. Imagine if you couldn't use your Blackberry unless you bought replaced your e-mail server? What you want is an e-mail gateway that allows the PDA to interoperate with what you have right now. I understand your predicament, but I believe I have a way out. Why not make the market decide? Along side your "standard" JEE platform, why not build and market a light weight alternative? Along side your massive investment in Java, why not maintain your investment and marketing of Smalltalk too? VisualAge for Smalltalk was a successful product by all accounts. IMO this would have represented leadership. Years after effectively killing of IBM Smalltalk, dynamic languages are now all the rage. How about building what you believe in, porting as many familiar concepts as make sense, interoperate with established standards where applicable and innovate where you can add significant value? This is happening right now with the iPhone. Everyone that buys the iPhone realises that it isn't a standard platform like J2ME or Symbian and that their iPhone applications aren't binary portable to any other phone and will only work on the iPhone. Yet despite this they still choose to buy an iPhone because of the value proposition it provides. It works with their e-mail server, it allows them to access the web using a standard browser, yet it innovates in HCI. This is how markets should work IMO. The iPhone is popular, but it isn't for everyone. Some people have a bunch of J2ME apps that they must retain. For these the iPhone is unattractive. This is OK, the iPhone isn't trying to own the whole PDA market, just a self selecting market segment. Even with profiles, I believe that the J2EE standard platform will still represent very few choices to its customers and will provides near zero innovation and as such can not be held up as encapsulating a vision. What is lacking is leadership. This is why I believe people are looking elsewhere. Regards, Paul.
  61. Re: end of discussion[ Go to top ]

    Rich, Jim, and Paul, I see that this thread is going to come off the front-page sometime early next week, so I am going to summarize the points you were making in my own words, and feel free to correct me if I am off: 1. Rich - JBoss is de-emphasizing JEE as the primary development and deployment specification for users; from previous threads, including discussions on JBoss AS 5, there is the promotion of the capabilities to switch between development methodologies and running those applications within JBoss, i forget what terms Muzilla and Sacha were using to describe this effort (i remember now: "re-factoring"), but it seems to me that JBoss no longer sees its primary role as a Java application server, but rather as just an application server... 2. Jim - IBM with WebSphere initially and more-to-date with Geronimo has made significant contributions to the JEE specification, all this is well-known, and i appreciate you getting involved in this written conversation; from your comparison of: roll-your-own app server v. full-JEE, i am taking away that you think developers will utilize the profiles implementations to start small and deploy larger...my only question is when customers start with business logic in EJBs, or persistence, or JAX integration and look for deployment platforms, will they be dis-enfranchised from the remainder of the market that does not support these technologies...my main argument is that this potential dis-enfranchisement will result in less-uptake of the core JEE technologies to begin with, and will result in further splintering, additional non-compatibility, and reduced market share for Java application servers... 3. Paul - i understand you don't like the current arrangement that app server vendors have with developers, even as Glassfish through Sun's work on the JVM, and JBoss' work on "re-factoring" present additional development options for users at no-cost; and, that you don't like the 'heavier' JEE technologies regardless of their availability mechanism in the form of vendor offering; what i don't get is the dismissal of the goal of portability at the component level, especially as you seem to be a developer yourself: would not a viable marketplace for portable applications and components make developer skills more valuable? or, is it that you would prefer inter-operability via web services standards, rather than the objective of automatic re-deployment across platforms... Conclusion: I still see the development paradigm as a competitive one with the scripting/'dynamic' languages competing with JEE, while JEE competes with .Net... And perhaps i am missing the point of profiles, by allowing new implementations to take up the cause of JEE to compete with .Net development, and thus demand for products and services that are not tied to MSFT... But, i still contend that the main proposition of Enterprise Java is to provide consistency across a number of vendors, and associated offerings to give customers relief from the lock-in that would be a reality from adopting .Net... Perhaps the benefits of the 'dynamic' languages overcomes the downside from the dilution of portability, and thus the argument against vendor lock-in, but i am still thinking that customers make decisions and the introduction of profiles will cause a re-consideration of strategic investments in technologies and platforms... Maybe the market needs this every once-in-awhile, maybe its worth the risk, maybe JEE will win even without a true portability argument as it has more today with JEE5, but after a decade of keeping MSFT and by extension Visual Studio out of the key Internet application development practices worldwide, I wonder what the next decade will bring... I can be accused of ostrich-like opinions to just hope to keep the status-quo, but I still have yet to hear a commitment to a mitigation plan to overcome the agreed upon problems that will come with profiles, until then, i see JEE6 as a risk as much as an opportunity...
  62. Re: end of discussion[ Go to top ]

    Hi Doug, Thanks for the discussion. Its been interesting here the points of views of others and its got me thinking about my views/prejudices.
    ide, I wonder what the next decade will bring...

    I can be accused of ostrich-like opinions to just hope to keep the status-quo, but I still have yet to hear a commitment to a mitigation plan to overcome the agreed upon problems that will come with profiles, until then, i see JEE6 as a risk as much as an opportunity...
    I don't think you are an Ostrich :) You are just reminding us of the promises made for the J2EE "component" model, and what it would mean for component re-use and portability in the future.
    what i don't get is the dismissal of the goal of portability at the component level, especially as you seem to be a developer yourself: would not a viable marketplace for portable applications and components make developer skills more valuable? or, is it that you would prefer inter-operability via web services standards, rather than the objective of automatic re-deployment across platforms...
    OK let me explain. I'm not dismissing it. I wish I could. I am saying it doesn't exist. We do not have a third party market in re-usable JEE components. It was a nice idea, but it didn't work. This is what I mean by "premature standards". We all bought into something that was unproven. JEE is not the first vendor driven component standard to have failed. It is the last in a long line of failures, such as DCE, OpenDoc, COM, CORBA, etc. Paul.
  63. Re: end of discussion[ Go to top ]


    1. Rich - JBoss is de-emphasizing JEE as the primary development and deployment specification for users; from previous threads, including discussions on JBoss AS 5, there is the promotion of the capabilities to switch between development methodologies and running those applications within JBoss, i forget what terms Muzilla and Sacha were using to describe this effort (i remember now: "re-factoring"), but it seems to me that JBoss no longer sees its primary role as a Java application server, but rather as just an application server...
    We're merely reacting to the market demand. JBoss always has and will continue to be about more than Java EE - it's merely one of the global computing standards that we have to support. We call the different platform configurations - "personalities". Don't get too hung up on the re-factoring - it merely describes the re-architecture work that has happened in AS 5. I don't think anyone is suggesting that you can just switch between Seam, Spring,Grails,Java EE and jRuby - the AS 5 value proposition is we can support those personalities (and more) without forcing you to switch or modify the operational infrastructure. Java (the platform) will continue to be our focus - all of our products are based on the Java platform. We're making significant investment in the Java platform (IcedTea / OpenJDK, AS 5) and the App Server will continue to be a about Enterprise Java. But even Java is changing to meet market demand - it's no longer just about the Java language. Rich Sharples JBoss, a division of Red Hat blog.softwhere.org
  64. Re: What about JEE 6, anyway?[ Go to top ]

    Portability ... For example, we never had this with Unix. At the least you had to re-compile your source code for each platform, and at worst you needed write a far amount of platform specific code. The GNU build has a configure phase for example, where platform specifc issues are addressed. Yet people see Unix as an open, portable environment, why? I would hazard a guess and say that people are more interested in conceptual portability first and foremost. Source and binary code portability are nice to haves but not essential.
    Portability is always a goal and has never been an absolute. There are just too many ways that portability can be broken. However, that doesn't remove the value that "portability" brings and those that know how to steer around the problem areas can realize more benefit than most. The most typical example is ISVs that want to build applications that run on multiple vendor servers. They realize that not everything will be consistent across vendors (e.g. deployment plans, bindings, extensions, admin, etc.), however, it is quite possible for them to build applications that run with very little change across multiple vendors. Another case, is customers that want to build on one platform (e.g. Windows or Linux) and have production deployment on another (e.g. zOS mainframe). If this was not possible, our customers would be screaming. Lastly, there is a trend in the industry to move development to low cost open source app server platforms (e.g. Geronimo / WebSphere Community Edition, JBoss, etc.) and deploy on the larger vendor systems. This also requires a degree of portability. There's still a fair amount of barriers to adoption to this pattern, but it has been recognized. Lastly, there's the compliance test suite itself. There are a huge number of test cases in this suite and while it is not a typical set of developer applications, it is quite remarkable that the test cases can be run as binaries without change or recompilation across all the app servers that certify as compliant. I'm not saying that any random app is likely to be portable, but the potential to realize portability benefits is very real.
    Innovation. IBM has a massive research budget. What is research for if not to innovate? ... Surely it is important to your customers that what they pay in license fees is invested into researching "blue plan" alternatives? The fruits of this investment may break concept portability over what they have now, but it may also represent a massive improvement and hence a massive return on investment to your license paying customers.
    Not sure where you were going with this. I didn't mean to imply that innovation was not a big part of IBM. If you want to see a glimpse of the future of Enterpise Computing and other related areas, see Jerry Cuomo's blog at http://www.ibm.com/developerworks/blogs/page/gcuomo. Innovation is alive and well and running in many directions at IBM (still #1 in annual patent generation). The existence of innovation is not necessarily at odds with portability either. Virtualization is one example. There's a fair amount of innovation in our WebSphere Virtual Enterprise product that allows management and provisioning of apps across a pool of large numbers (hundreds) of nodes. This is non-intrusive, so apps remain just as portable as they always were, yet they are able to take advantage of those services. In other cases, portability can be achieved by using library techniques where the innovative code is bundled with an application so it remains somewhat portable when deployed to other environments. Examples of this are Struts frameworks and JPA persistence frameworks. If you want a non-standardized vendor specific example, then our ObjectGrid product or Web 2.0 functionality would suffice. Yes, it is possible to innovate in a way that is non-portable and introduces vendor lock-in if some developer takes advantage of that. That means a developer has a choice. If portability is more important to them, they can choose not to take advantage of specific vendor extensions that would cause lock-in. There are many customers that follow this pattern. If it provides value to a developer as a solution to some problem they would have had to invent a solution for themselves, then they could choose use the extension and to realize that value. For many customers, time to value is important and they will do whatever is necessary to meet their objectives. Obviously, there are gray areas in between and customers also fall into. There's no one right answer for everyone.
    Standards. What are they and who do they serve? The enterprise contains lots of technologies, representing different waves of "blue plane" thinking. From Mainframes to Mini-Computers all the way up to modern PDAs like the Blackberry. It is unreasonable to expect binary portability of software components across all these technologies.

    At best all that can be hoped for is that these technologies are made to interoperate, working together to provide a functional whole.
    Standards provide for different purposes and I suppose we could get into a debate on whether the JCP is really a standards organization or an industry group providing joint specifications, but I try not to get caught up in the fine grained details. Ultimately, the various standards bodies have specifications that cover both portability (e.g. programming model) and interoperability (e.g. protocols). I wont' debate too much the lack of components that work from PDA to mainframe, but not for the reason you'd expect. In more cases than not, the programming model IS consistent or could be. It's that the qualities of service tend to differ and an optimal use requires different algorithms or code blocks etc. to be used (e.g. use of caches and locks for multi-request large scale mainframe use vs. single user single thread access for simple devices).
    Why not make the market decide? Along side your "standard" JEE platform, why not build and market a light weight alternative? Along side your massive investment in Java, why not maintain your investment and marketing of Smalltalk too? VisualAge for Smalltalk was a successful product by all accounts.
    Be assured that IBM (as most vendors) is market driven. We do what our customers want because they won't buy our products if we don't. You need to realize, though, not all customers are created equal. What our customers want may not be the same thing as what JBoss customers want which might be different from what customers using Tomcat and Spring want and like I said earlier, we're constrained by the compliance testing rules of all or nothing. If you're asking why don't we build a non-EE light weight alternative, the answer has to do with growth. Migration is very expensive for a customer to undertake, so you really REALLY want to avoid going off in directions that put a customer on a dead end path. A light weight alternative needs to be a proper subset to avoid that migration cost as they grow. I'm not part of the VisualAge team and I don't have specifics on its history (other than I know what it took to extend/enhance it for Java use), but I would have to guess that the product's life was governed by the market as well. Look at where we ended up. We recognized the market need for a new, extensible development platform, based on the programming language the industry was moving to. We wrote Eclipse and contributed it to open source to build up a community based ecosystem around it and then Rational built their products on top. I'd have to guess that the market appreciated the effort.
    IMO this would have represented leadership. Years after effectively killing of IBM Smalltalk, dynamic languages are now all the rage. How about building what you believe in, porting as many familiar concepts as make sense, interoperate with established standards where applicable and innovate where you can add significant value?
    I remember when PCs first came out. I was looking at all kinds of systems from the IBM Personal Computer to home builds. At the time, it was clear to me that a kit with dual CPU system (8080 and z80) with CPM and the ability to manage not just 64K of memory, but 192K(!) was the better technical solution. In the end, even though it was a better technical solution, it was not the better choice. What I'm saying is that we can build products that are good, but the market may move on and those products need to evolve with the market or face extinction.
    This is happening right now with the iPhone. Everyone that buys the iPhone realises that it isn't a standard platform like J2ME or Symbian and that their iPhone applications aren't binary portable to any other phone and will only work on the iPhone. Yet despite this they still choose to buy an iPhone because of the value proposition it provides. ... This is how markets should work IMO. The iPhone is popular, but it isn't for everyone. ... Even with profiles, I believe that the J2EE standard platform will still represent very few choices to its customers and will provides near zero innovation and as such can not be held up as encapsulating a vision. What is lacking is leadership.

    This is why I believe people are looking elsewhere.
    I can't fault your argument. I agree that products can be built in a proprietary way and fill a market need. Anyone that buys a Windows or Mac PC is really buying proprietary technology and getting value out of it. Standards can fulfill a role here in allowing proprietary products to exchange information in an interoperable fashion. Now, we get to the purpose of standards. Standards are used to drive ubiquity. They help build an ecosystem around a common view/understanding of how things are supposed to work. Let's use your iPhone example as an illustration. Let's assume that the iPhone concept grows to more than a market subset. Instead, it defines a significant market segment. All the phone vendors will be building similar products, but they all work differently. Customers pay premium for extensions because the extensions only work on one kind of phone even though every vendor has that kind of extension for their phone. The secondary vendor market (VARs) have to do triple or quadruple duty to include their particular value add, but in four different ways on four different vendor phones. There may have been innovation at one point, but the market has responded and what once was new and innovative is now a hurdle. This is ripe for standardization. Personally, I have a hard time using standards processes for innovation. Standards proceed too slowly and generally almost never get it right the first time (e.g. JSR88 and JAX-RPC). It is much better to let the market innovate independent of standards and then standardize when the differences start to become gratuitous. As an example, Hibernate and TopLink innovated and evolved independently, but the market recognized that many of the differences weren't really warranted. To broaden the relevance, standardization in the form of JPA took place and now we innovate on other things in that space. Standards also provide for stability so that things that worked on one version continue to work on the next. This tends to stifle innovation somewhat because of the need to remain compatible or the alternative is to break customer expectations (forcing them into expensive migration scenarios) by introducing incompatible changes and then deal with the corresponding market reaction. I don't view profiles as innovation in standards. Profiles are an evolution of standards (actually the process around standards) to address a market need that can't easily be solved with innovation. The compliance methodology of the standards we use today is constraining any innovation that could occur and the economics of making changes in reference standards (those that have specs, reference implementations, and compliance tests) makes it somewhat prohibitive to do the ideal change. In terms of vision, I think there's often a perception that vision is related to new and sexy. That's not true. The original vision of J2EE has not changed. It has always been to define a collection of all the middleware a business needs to run its IT. I think we're just recognizing that not all businesses need the same amount of middleware, so we are looking back to where we started. For businesses that don't need the full platform that EE provides, define a platform that does meet their needs and allow a way for them to gracefully grow their need. You may ask how we get to one particular definition of a subset without allowing the market to choose it, but the EG's job is to provide the expertise and background in dealing with the market to understand where the cut mark should be and it's the industry's job to provide feedback on it during public review periods. It's not like we're in the dark here. We see what parts our customers use of the full platform. We see how customers roll their own app server environments with Tomcat and Spring and Hibernate. We see patterns of applications that use presentation frameworks and follow MVC best practices. The big picture in all of that is not that hard to understand. I do agree that this does not provide for the kind of innovation that might occur if everyone chose to assemble an app server themselves from piece parts and the market trended towards a common set, but there's value in having a platform that is fully integrated to start with (back to the portability issue and the barriers to adoption of gratuitous differences for common concepts) and customers have always had the piece parts assembly option regardless of the existence of Java EE (e.g. buy vs. build).
  65. Re: What about JEE 6, anyway?[ Go to top ]

    Hi Jim, Thanks for taking the time to explain your position. We aren't in total agreement, like for instance it may be an idea to talk to the IBM Smalltalk people about that chapter in IBMs history before assuming that the death of IBM Smalltalk was soley driven by market forces. Having said this, I do braodly agree with your conclusion. Standardisation should follow innovation. Once an innovative idea has been proven in the market, then defining a standard is useful in avoiding gratuitous differences and conceptual overload. Historically however IBM has been as responsible for using premature standardisation as a means of growing and ring fencing markets. In the long term history has shown that this just doesn't work. Which IMO is why we are discussing profiles today. I mentioned Apple and the iPhone. Another innovative product is Flex from Adobe. They have managed to re-use a lot of the current DHTML concepts to build rich internet client in a familiar way, whilst delivering a unfamiliar end user experience. So I agree, innovation and complying with standardise concepts are not orthogonal. There is value in a bundled product I agree, I just think there is more value in a framework that facilitates extensibility by defining extension points in a common way and allowing people to plug-in both standard and innovative extensions as they see fit. Of course this means that the developer community need to be willing to take more control and more responsibility. Whether developers are willing to do so, has noting to do with vendors. So in one respect perhaps we (the developer community) have ended up with the JEE platform we deserve. Regards, Paul.
  66. Re: What about JEE 6, anyway?[ Go to top ]

    Hi jim, I just wanted to clarify:
    Standardisation should follow innovation. Once an innovative idea has been proven in the market, then defining a standard is useful in avoiding gratuitous differences and conceptual overload.
    What I mean to say is that a standard way of doing things can emerge once the a given approach becomes widely accepted in the market. This doesn't necessarily call for a standards body like the JCP. The Hayes AT modem command set is a classic example: http://en.wikipedia.org/wiki/Hayes_AT_command_set The Hayes AT commands became the standard way to interface modems and was adopted by a lot more companies then Hayes :) After investing a good portion of my youth learning 'premature standards' like CORBA, JEE EJB1.x, JEE EJB 2.x, SOM, OpenDoc etc all being pushed by vendors, all unproven and all with limited success in the market, you can perhaps understand why I'm a little bitter :) I am also slightly suspicious of the motives of a body like the JCP. I just don't think the primary goal is to serve my interests as a developer and more importantly the interests of my customers. Of course I don't know and I'm sure you are all nice guys. I just though that it would be good to end with some open honest feedback about my prejudices and where they stem from. Paul.