Discussions

News: Analysts see Java EE dying in an SOA world

  1. In "Analysts see Java EE dying in an SOA world," Burton Group analyst Richard Monson-Haefel says that "JEE5's failure to address complexity is a harbinger of the Java EE platforms' fall from dominance in the enterprise development platform arena." According to the report, service-oriented architecture is the death blow. Even with the simplification of enterprise APIs in Java EE 5, the "platform has grown too complex to be workable for enterprise developers." However, a later statement is that "JEE5's failure to address complexity is a harbinger of the Java EE platforms' fall from dominance in the enterprise development platform arena." The implication is that the complexity is in the wrong place, not addressing actual problems, but existing in development and deployment. SOA emphasizes interoperability more than cross-platform deployment, and the analysts say that Java EE is ill-suited for this (despite the existence of efforts such as Project Tango to directly address this.) In many ways, according to the analysts, Java EE is caught between advances on both the services side and the low-end deployment side. Ruby (for example) is taking over rapid development and deployment of simpler applications that were formerly perceived as bread and butter for Java, while SOA de-emphasizes the need for Java implementation of services. The questions focus, then, on value and models. The value of Java (and Java EE) in the future is based on developer productivity. If Java EE is simple enough and interoperable enough to cater to a service bus' needs, then developer productivity will remain high enough to make Java a valuable tool in the SOA arsenal. Models focus on how applications are actually developed. A services-oriented model has been a goal for analysts for years, and only recently has it built up measurable steam; some developers say privately that while services are valuable, they're not yet valuable enough to upend a successful development model that's been in place for decades. Time-to-market and time-to-develop factor in as real considerations. While services can speed up both of them, but only if the services already exist; a developer suggested that people from some development environments think SOA is expressed as "everything just works without considering that SOA [components] developed in COBOL and PL/I take more time and are harder to test thatn JEE-based applications." In other words, most applications don't need a service model, and wouldn't benefit from one. As a result, catering to a service model would be a waste of resources and time. One architect from a Fortune 100, dismissed the report, saying that it's "an analysts group's cry for attention by trolling." What do you think? Do you see Java as being only mildly relevant in the future, relegated to the same status as CORBA?

    Threaded Messages (153)

  2. Java dead, news at 11 ..[ Go to top ]

    So many final death blows. Sooner or later it has to be fatal, right? Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  3. Re: Java dead, news at 11 ..[ Go to top ]

    As much as I'd like to switch to a less complex solution, all the alternatives seem to suffer from the same complexity problems. ------------------ Freelance Java Projects
  4. Forgetting Spring[ Go to top ]

    Java won't die anytime soon, any more than C++ has. Java EE still has life. Spring has some traction. POJO modeling is simpler than EJB. It promotes good object-oriented practices, like designing to interfaces. It continues to improve. Spring might make a difference if it spreads. Rails is for web-based CRUD operations on relational databases. It hasn't solved problems like security, etc. I don't know if the containers are enterprise quality. It's a great fit for its niche, but that doesn't make it an enterprise tool. It's possible to duplicate some of the success of Rails in Java, as long as you follow that philosophy of making choices and sticking to them. Code generation and standards can give Java EE that same lift. It's more likely that SOA will turn out to be CORBA than Java will. Some of the differences are ubiquitous protocol (HTTP), elimination of ORBs, etc., but there are still issues. Method calls on distributed objects will always perform slower than in-memory calls. Piling complications like SOAP and verbose XML messages might make SOA an elegant, badly performing architecture. There's a sweet spot between services that are "God/Winnebago" scale and too-fine grained. It might be hard to hit. Will we look back on ESBs and think they were the equivalent of ORBs without an OMG standard to guide them? It's not a one language/one tool world. I think some of the folks who have moved beyond Java just like to sell more books. %
  5. Hi
    It's not a one language/one tool world.
    I agree. The moment someone suggests that something other than Java or J2EE may be more appropriate in a given role we get these same defensive responses. I don't see JEE going away anytime soon either. My argument is that it should be complemented by other approaches in the enterprise space, replacing it's use in areas where it has never been that well suited (e.g simple CRUD apps or simple EAI). Paul.
  6. Re: Java dead, news at 11 ..[ Go to top ]

    So many final death blows. Sooner or later it has to be fatal, right?

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
    Yes. UNIX (as well as all clones) has been dying too, for some time now, like 3 decades in a row... The last death blow was Windows NT. It's still barely recovering from that blowj.. sorry, blow. Java's death is imminent too. I'm not sure if it will be from .NET or Lisp...
  7. All this stuff about SOA somehow making Java irrelevant is just nonsense. "Advances on the SOA side" have no bearing on the viability of the technologies used to build services. And if anything SOA is strengthening Java because (other than .NET) all of the major SOA solutions are built with Java and require Java either for their development programming models or at least as a runtime.... Floyd
  8. Cameron: " Java dead, news at 11 .." Floyd: "All this stuff about SOA somehow making Java irrelevant is just nonsense." Guys, it takes less than two minutes to read the article. Look more closely.
    He took pains to emphasize that he is only sounding the death knell for the Java EE platform and not the Java language. "The Java programming language is not threatened here," the Burton analyst said. "I think the Java programming language is going to continue to thrive and be the mainstay for most enterprise development for years to come."
    Now, I have to admit that Richard Monson-Haefel doesn't sound extremely coherent in the article, and I wonder if he's spent too much time out of the trenches now. SOA is an architectural concept, while JEE5 is a specific platform which can be used in an SOA implementation. Saying 'SOA will displace JEE5' is kind of like saying 'AOP will displace AspectJ.' Richard seems to be stating that there is an SOA platform, whose components will be mostly implemented in Java, and whose ease-of-use is significantly better than JEE5. Well, what is it? I imagine you could see Spring evolve into something like this in the coming years, but I have trouble believing that such a platform would completely deprecate JEE5 in larger corporations.
  9. SOA is an architectural concept, while JEE5 is a specific platform which can be used in an SOA implementation. Saying 'SOA will displace JEE5' is kind of like saying 'AOP will displace AspectJ.'
    You are only right where procedural code is concerned. However, JEE (as opposed to Java), is primarily about things like deployment, administration, configuration, monitoring, security, distribution architecture, distributed transactions, interface/contract versioning, etc. All the declarative infrastructure and management stuff. And these these things could be replaced by competing SOA standards. SOAP is an alternative to RMI/IIOP. WS-Transactions is an alternative to JTA and so on. So there are competing standards. SOA is not just an architectural pattern. It's set of standards and they compete with JEE standards to a considerable degree.
  10. god the bus rules integration guys[ Go to top ]

    finally found a new workflow platform....oh god Hogwash. The SOA model is a pure integration platform. If you have no other choice go that route. Otherwise forget it. It will fail just like ORBs, and enterprise message bus, and business rule engines failed. Meta application models have their place but making them the default is a total joke.
  11. The Burton Group is missing another clue in their argument: IBM, Computer Associates, Oracle, and the like are all pushing for architecture-independent SOA with less complexity. Some of those vendors go as far as suggesting products and services that will enable legacy technologies like COBOL, PL/I, CICS, etc. to support SOA applications. In many cases, those tools are mere plug-ins for the legacy system... plug-ins written using JEE technologies. The complexity of JEE is minimal when compared to .Net or to some of those chimera-like application stacks that try to bring SOA to legacy environments that weren't designed to support it, like mainframes. Those machines are optimized for batch processing and fast I/O in batch mode. SOA applications may be made to run adequately in them when coded in something other than Java, but not after lots of performance tuning and headaches for the developers. The vendors themselves suggest using JEE (whether their brand or any of a variety of open-source offerings) to really leverage their hardware and provide integration. The Burton Group analysts either just don't spend enough time working on mission-critical enterprise applications, or they have their own-brand solution to sell... and comments like these are just a way to create FUD in the minds of the clueless (of which there seem to be plenty in the corporate world). At least one company is bound to take the bait, right? Cheers, Eugene Non-stop action. A quest to save the world. A vulnerable hero. It's the most exciting thriller of the decade. The Tesla Testament.
  12. The Burton Group analysts either just don't spend enough time working on mission-critical enterprise applications, or they have their own-brand solution to sell... and comments like these are just a way to create FUD in the minds of the clueless (of which there seem to be plenty in the corporate world). At least one company is bound to take the bait, right?
    Exactly. Who is going to pay big $$$ for a report titled "Everything is great in Java Land"?
  13. The complexity of JEE is minimal when compared to .Net or to some of those chimera-like application stacks...
    He, you should really check articles like this or this before saying such things.
  14. Edgar, Could you please elaborate what this wonderful thing called WCF puts on the table regarding environments like mainframes? I'll quote the original poster with the right context:
    The complexity of JEE is minimal when compared to .Net or to some of those chimera-like application stacks that try to bring SOA to legacy environments that weren't designed to support it, like mainframes.
    Javier
  15. Could you please elaborate what this wonderful thing called WCF puts on the table regarding environments like mainframes?
    WCF proposes a simple and highly configurable paradigm for exposing logic and entities to other processes. It's not confined to one specific protocol or to talk to Windows-only environments. You're right in the fact that, regarding mainframe connectivity, it puts little new on the table, but after that (crucial indeed) step, WCF is simpler to use and more flexible than JxEE.
  16. Actually, both Java and .Net can interoperate with mainframes, though without WCF and with some 3rd-party help: http://www.iona.com/products/artix/artix_zos.htm Incidentally, WCF out of the box supports only three transports: HTTP, MSMQ (interoperability? forget it!), and plain TCP/IP. So, you want your services to talk on something like JMS? Websphere MQ series? AMQP? You'll need to go to third parties anyhow.
  17. The complexity of JEE is minimal when compared to .Net or to some of those chimera-like application stacks...
    He, you should really check articles like [link to MSDN] or [link to MSDN] before saying such things.
    Just out of curiousity, aren't you still the "Microsoft Regional Director for Ecuador"? Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  18. The complexity of JEE is minimal when compared to .Net or to some of those chimera-like application stacks...


    He, you should really check articles like [link to MSDN] or [link to MSDN] before saying such things.


    Just out of curiousity, aren't you still the "Microsoft Regional Director for Ecuador"?
    Yes, I am, Cameron, for some 3-4 years now, and I still do projects with Java when the customer or the scenario demand it. But let's not talk about the messenger but about the message: Eugene said that .NET was far more complex than JEE so I pointed to a couple of articles that show that WCF is a far more simple and homogenous animal than a chimera, it would be great if you can offer information that proves otherwise.
  19. Eugene said that .NET was far more complex than JEE so I pointed to a couple of articles that show that WCF is a far more simple and homogenous animal than a chimera, it would be great if you can offer information that proves otherwise.
    Edgar, The burden of the proof is on you. As I mentioned on another message Eugenes quote was incomplete. Better you said: "On related news, there is preliminar information that shows a future version of a product further simplifies Windows development of web services" Cheers Javier
  20. The complexity of JEE is minimal when compared to .Net or to some of those chimera-like application stacks...
    He, you should really check articles like [link to MSDN] or [link to MSDN] before saying such things.
    Just out of curiousity, aren't you still the "Microsoft Regional Director for Ecuador"?
    Yes, I am, Cameron, for some 3-4 years now [..] But let's not talk about the messenger but about the message
    When I talk to someone, I like to have some understanding of whom it is I am talking to. There's nothing wrong with working for Microsoft or liking .NET. I like .NET fine myself.
    Eugene said that .NET was far more complex than JEE so I pointed to a couple of articles that show that WCF is a far more simple and homogenous animal than a chimera, it would be great if you can offer information that proves otherwise.
    I wasn't trying to argue with you. I have a stack of complaints about Java, and I have a stack of complaints about .NET. I am an equal opportunity critic ;-) I know Eugene, and if he is telling you that there is something that is too complex with .NET, you can either assume that he isn't smart enough to write example code for MSDN (MSDN obviously being a perfect reflection of real-world use cases), or perhaps there is something to learn from him. I don't currently work with web services in .NET so I cannot comment on the matter with any credibility (which assumes that I have some in other areas?), but I assume that he is trying to say is that Microsoft may have made the examples and demos easy to do, but his problems in his applications have been extremely hard to solve with .NET. (The "simple stuff is easy, hard stuff is impossible" design flaw?) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  21. Re: Check WCF .NET Framework 3.0[ Go to top ]

    I don't currently work with web services in .NET so I cannot comment on the matter with any credibility (which assumes that I have some in other areas?), but I assume that he is trying to say is that Microsoft may have made the examples and demos easy to do, but his problems in his applications have been extremely hard to solve with .NET. (The "simple stuff is easy, hard stuff is impossible" design flaw?)
    I've done some web services and as long as you stay in the box/on straight and narrow, it's pretty easy. Now deploying them on a production server - that's another story. I can't seem to just deploy a new .Net web app. It is always deploy and then google to try to figure out what was wrong. Of course there is the usually changing of the debug flag. Everytime a new version of VS.Net or .Net or IIS or Windows comes out - something else doesn't work. :( Now Java? Dump .war and go.
  22. Re: Check WCF in .NET Framework 3.0[ Go to top ]

    The complexity of JEE is minimal when compared to .Net or to some of those chimera-like application stacks...

    He, you should really check articles like this or this before saying such things.
    Don't need to. I use it on pretty much a daily basis. If you look at certain aspects of .Net with blinders on, then previous quote would seem to be incorrect. But looking at the big picture, it's not.
  23. Those who live by the SOA (sword) die by the SOA (sword).
  24. Do you see Java as being only mildly relevant in the future, relegated to the same status as CORBA?<<
    You do mean Java EE, right? The article states specifically that this has little or no bearing on Java's relevance in the myriad other ways in which it is applied. I believe, and the article seems to indicate this as well, that Java has a great deal of relevance going forward. I agree that complexity can kill the embrace and implementation of a technology and that perhaps as a matter of attrition Java EE will become only mildly relevant in the future. As an architect with a software development company I can tell you that the criteria I use to select Java EE technologies as part of a solution strategy are extremely rigorous. In other words, I won't use Java EE technologies if I don't have to. And to the greater extent that is because of the reduction in productivity and agility that going with the tech has, in my experience, incurred on my projects. It's my belief that this is the case regardless of the latest <<Insert Framework/Approach/Technology>> here.
  25. Hi Craig,
    I won't use Java EE technologies if I don't have to. And to the greater extent that is because of the reduction in productivity and agility that going with the tech has, in my experience, incurred on my projects.
    ...ditto. Compexity kills. This simple point seems largely lost on the J2EE community, as they regularly turn their nose up at simpler alternatives(PHP, Ruby etc.) using silly arguments about "industrial strength" and "future proofing". Java is a rather nice language, but in hindsight the heavy weight Enterprise appserver model has turned out to be a big mistake (over kill) in a lot of cases, and IMO EJB3 is no better. Rod Johnson had it right when he said that Java is more than J2EE. Personally, I wouldn't mind getting my hands on simpler EAI techology like say Ruby Web Services and Ruby on Rails, as an alternative lightweight and dynamic way of integrating back-end services. I feel that such an approach would prove much more agile and productive. Paul.
  26. Personally, I wouldn't mind getting my hands on simpler EAI techology like say Ruby Web Services and Ruby on Rails, as an alternative lightweight and dynamic way of integrating back-end services. I feel that such an approach would prove much more agile and productive.

    Paul.
    Having worked a little with Jython, I think that there is definitely going to be a future combining dynamic languages with static languages like Java. The dynamic vs. static argument is flawed in that both sides are right and both sides are wrong. Each approach has it's place and the idea that you can't use both together is dead wrong.
  27. Hi James, I totally agree. There seems to be a general laziness amongst Java EE developers to try/learn anything "different". Not surprising really, once you've invested years of your life mastering the details of Servlets/JSP/EJB/Weblogic etc, it's hard to believe that there could be something much simpler out there that does pretty much the same job. So much for the marketablility of your hard earned skills. There seems to be a "Silo" mentallity with Java EE developers "bunkering down". Also complexity is often promoted by vendors, consultancies and some developers as a revenue generator. IMO the Java EE industry has become somewhat self serving and are busy naval gazing. I've been involved from the beggining (1997) and I've seen this mentallity develop over the years. To be honest I'm pretty sick of it! I see myself as a pragmatic programmer, with a focus on getting the job done. In order to do this I try to keep an open mind, able to evaluate all the technology options open to me. One of the reasons why I'm learning Common Lisp at the moment :^). Paul.
  28. There seems to be a general laziness amongst Java EE developers to try/learn anything "different". Not surprising really, once you've invested years of your life mastering the details of Servlets/JSP/EJB/Weblogic etc, it's hard to believe that there could be something much simpler out there that does pretty much the same job. So much for the marketablility of your hard earned skills.
    You are right. But you would also be right if you substituted C or C++ or PERL or .... a wide range of languages. Programmers can be lazy.
    IMO the Java EE industry has become somewhat self serving and are busy naval gazing.
    Are you sure you mean that.....?
  29. Hi Steve,
    IMO the Java EE industry has become somewhat self serving and are busy naval gazing.
    Maybe naval gazing isn't the right words. But to me the Java EE industry does seem constrained. After selling the J2EE AppServer as the solution to all problems on the server any new Java EE solution is naturally constrained to work within this incumbent context. Hence EJB3.0 is merely a wrapper around EJB2.1 with much of the incumbent complexity still there under the covers. What is needed IMO is a radical re-think and a fresh approach. I don't see this comming from the Java EE community. Their actions so far have been reactionary IMO. The cutting edge for new ideas is now elsewhere IMO. Paul.
  30. Hi Steve,

    IMO the Java EE industry has become somewhat self serving and are busy naval gazing.


    Maybe naval gazing isn't the right words. But to me the Java EE industry does seem constrained.
    I was referring to the use of 'Naval' [pertaining to the navy] as against 'navel' :)
    After selling the J2EE AppServer as the solution to all problems on the server any new Java EE solution is naturally constrained to work within this incumbent context.

    Hence EJB3.0 is merely a wrapper around EJB2.1 with much of the incumbent complexity still there under the covers. What is needed IMO is a radical re-think and a fresh approach. I don't see this comming from the Java EE community. Their actions so far have been reactionary IMO. The cutting edge for new ideas is now elsewhere IMO.

    Paul.
    I think you are plain wrong. EJB 3.0 is certainly not merely a wrapper around EJB 2.1. There are major advances - it includes JPA (although it has some faults) is a full-featured and very rich transparent persistence ORM that is based on cutting-edge products like Hibernate - which is anything but reactionary. JEE5 includes JSF, which is an innovative foundation for many exciting new projects, products and approaches.
  31. Here's the problem...[ Go to top ]

    There seems to be a "Silo" mentallity with Java EE developers "bunkering down". Also complexity is often promoted by vendors, consultancies and some developers as a revenue generator.
    There seems to be this magic bullet concept that the stuff we do is not complex. That if only someone would Do It Right, the complexity would Go Away. Let's take simple web apps for an example. Web apps aren't hard. They're tedious, but not hard. The protocol is pretty bone head stupid. You get strings, you send strings. At the one end we have basic CGI scripts. Suck in strings from the port, chew on 'em, spit them back out. Perl, Python, PHP. Java up'd the ante a bit with Servlet containers. Now we have this layer that does some of the chewing for us. We get not only embedded code and HTML ala PHP, we also get "free" sessions and a simple way to bundle up applications -- the War file. I mean, it doesn't get much simpler. Install tomcat, plop app.war in the webapps directory, and *boom*. Web app. It works. It's "simple". But, in fact, it's not really simpler at all. The underlying problem still remains. Still need to suck in strings, chew on them, and spit them out. Still need to tie network ports to servers, deal with permissions, configure db drivers and crap. The fundamentals remain the same, we just have this new extra layer to understand on top of the fundamental problem. Have you ever looked at Tomcat? It's a large, complex system. We add that complexity to the problem in order to simplify it. But just because it's shrouded in "simplicity" is no reason that it can be ignored. If you want to understand how your application is performing and behaving, you need to understand your application, Tomcat, Java, the JVM, the OS, it's network stack, your drive configuration, your network configuration, the datacenter it's deployed in, etc. etc. etc. And that's just a web app. bobsblog.com. 99% of the time, we can simply focus on the PHP or JSP file. That's where the root of almost all of the problems are -- in our source code written on top of all these other layers. The computers are powerful enough that we can "ignore" the peformance and configuration of everything that gets between "HotNews.jsp" and your browser. But that doesn't mean it's gone. That doesn't mean it ceases to exist. All of that complexity is still there, buried, and waiting to rear its ugly head at some inopportune time like a dormant volcano. Something that's going to have you on the phone to some remote spot of the world, scatching your head and going "WTF". The reason folks get entrenched in to their ways when it comes to developing these systems is simply because no matter WHAT solution you use, no matter HOW "easy to use" they are, the fundamental complexity is ALWAYS there. But when you swap out some major component, you basically gain nothing but a new chunk of dark matter that you need to learn and decipher and understand. Yet, in truth, it doesn't give you much overall gain in the big picture. Now you have a big stinking pile of risk and unknown doing essentially the same thing that your current known and battlescarred infrastructure is doing. So, we tend to get entrenched because as we work on more and more complex systems, the "Devil we know" becomes much more important. We've already been burned and seared by having our systems have contact with the real world, and the knowledge that carries us forward enables us to be responsive to changes in the business. We know which twisty passages that look all alike to go down, and, as important, which ones not to go down. Whether we create our own infrastructure from scratch or rely on someone else, there's a reason why folks in this industry are conservative about change. The complexity never goes away. The problems are always the same. We can pile layers and layers of tools and code and patterns and abstractions upon it, but like the Princess and the Pea, we still know what lies underneath. For all of the simplicity and comfort all those extra layers provide, unlike the Princess, we're still responsible for them and the Pea. Now that's not to say there aren't better ways to do things. Yea, Tomcat adds a bunch of complexity to the overal system, but it adds value as well. We're complicit in the maze we build. But don't damn us because we don't hop on to every bandwagon that passes by. Projects have an insane amount of momentum and can be very difficult to turn. Good luck with your Common Lisp. The new boss will be same as the old boss, but maybe you'll like its personality better.
  32. Re: Here's the problem...[ Go to top ]

    Hi, I can see I've hit a nerve. Looking into Common Lisp can't be described as jumping onto a band wagon after all it's been around for over 50 years :^). The most sensible things I hear knowadays comming from the programming community tend to come from Dave Thomas and the Pragmatic Programmers, Alan Kay of Smalltalk, and "windowing Desktop" fame has said a lot of sensible things over the years aswell, but people tend to ignore him too. There is a difference between learning all the minute detail of the latest JEE JSR because you're likely to need it to get your next job interview and ensuring that you have a solid grounding in computer science and software engineering concepts and principles. My favorite example of this is OO languages and OO design. I spend half my life wading through procedural code written in a supposedly OO language by supposedly OO programmers, why? At the beginning I didn't get OO either, so I took the time to learn Smalltalk, it made me a much better C++ programmer. With the rise of dynamic languages I've been using Ruby a bit recently which re-kindled my interest in Smalltalk. The conceptual power of both of these lnaguages has generated an interest in the grand daddy of them both Lisp. As senior developers if we don't have a deep appreciation of such things how can we hope to evaluate the technology options in front of us? You may be happy taking a vendors word for it, but I for one am not! BTW. The next time you sit down to code, time how much time you spend thinking, coding and getting feedback through testing(executing the code) versus how much time you spend, compiling, re-deploying to tomcat, messing around with ant etc. We as programmers do this type of stuff all day; code a little, test and then code some more. In Lisp they call this cycle the REPL (read-eval-print loop). Time not spent thinking, coding and testing is wasted time, perhaps as much as 50% of your day. They worked this out in Lisp over 50 years ago, which is why the REPL cycle is immediate. This is what people mean when they complain about poor productivity and complexity in Java EE, it simply lacks this immediacy. Perhaps you should take a look at Lisp too:^) http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html Paul.
  33. Re: Here's the problem...[ Go to top ]

    As senior developers if we don't have a deep appreciation of such things how can we hope to evaluate the technology options in front of us? You may be happy taking a vendors word for it, but I for one am not!
    I think that almost as bad as taking a vendor's word (I mean, anyway, does anyone really do that?) is not keeping up with the latest state of technologies like JEE and consequently making claims about it based on past experiences, rather than current situations. I use JEE for almost all development, and I don't recognise much of the JEE you describe.
    BTW. The next time you sit down to code, time how much time you spend thinking, coding and getting feedback through testing(executing the code) versus how much time you spend, compiling, re-deploying to tomcat, messing around with ant etc. We as programmers do this type of stuff all day; code a little, test and then code some more. In Lisp they call this cycle the REPL (read-eval-print loop). Time not spent thinking, coding and testing is wasted time, perhaps as much as 50% of your day. They worked this out in Lisp over 50 years ago, which is why the REPL cycle is immediate. This is what people mean when they complain about poor productivity and complexity in Java EE, it simply lacks this immediacy.
    You really need to take a look at Spring, facelets, groovy and a range of other technologies that can be used with JEE. If you think that development with JEE always requires substantial compiling and re-deployment, you are very much mistaken, and not simply keeping up with the latest innovations in this area (I would especially look at Spring 2.0's dynamic language support with refreshable beans). Of course, with JSP, JEE has allowed the equivalent of REPL for years. You are wrong to claim that JEE lacks this immediacy.
  34. Re: Here's the problem...[ Go to top ]

    You are wrong to claim that JEE lacks this immediacy.
    From my experience, the lack of RELP in JEE is mostly due to some irrational zeal that JEE application must always be (re)deployed as .WAR/.EAR file. Even when all decent appservers support class reloading at runtime (either via custom classloader tricks or hotswap) and deployment of "exploded" applications. Of course, there is also an enterpricey app server that forces you through 5-step wizard on each redeploy... Spring et all are sometimes helpfull (automatic redeployment or reloading of configuration when files change) and sometimes not (no reinitalization on falure or change) - it all depends on how you design and configure them.
  35. Re: Here's the problem...[ Go to top ]

    You are wrong to claim that JEE lacks this immediacy.

    From my experience, the lack of RELP in JEE is mostly due to some irrational zeal that JEE application must always be (re)deployed as .WAR/.EAR file. Even when all decent appservers support class reloading at runtime (either via custom classloader tricks or hotswap) and deployment of "exploded" applications.

    Of course, there is also an enterpricey app server that forces you through 5-step wizard on each redeploy...

    Spring et all are sometimes helpfull (automatic redeployment or reloading of configuration when files change) and sometimes not (no reinitalization on falure or change) - it all depends on how you design and configure them.
    Hi Bostjan, Not sure about the Spring hot deploy stuff (I've never used it), but application server/web server hot deploy doesn't always work (something to do with whether you've changed the shape of your classes I think). So after getting burnt a few times you re-build, re-package, re-deploy, restart Weblogic etc each time just to be sure. Also, debugging means remote connecting to the "server" (localhost). So you end up having to configure a socket connection to your own machine, just to run the debugger! REPL just never was the idea. The idea was to build a middleware platform with administration, deployment, configuration etc. as some else has rightly pointed out earlier. Just look at all the roles in the original JEE specs: Deployer, Packager, Administrator etc. No one at Sun stopped to think that developers would end up performaing all these roles and that they would need to do them each time they wanted to test a change. So you end up having to do all this just to test a single line of source code! Paul.
  36. RPEL and JEE deployment woes[ Go to top ]

    Not sure about the Spring hot deploy stuff (I've never used it), but application server/web server hot deploy doesn't always work (something to do with whether you've changed the shape of your classes I think). So after getting burnt a few times you re-build, re-package, re-deploy, restart Weblogic etc each time just to be sure./blockquote> Well, I know a few people who fell into this trap by getting burned a few times. I also know production system that has scheduled downtime every Saturday. Reason: to restart all the software. No real reasons (memory leaks, data corruption), but "just to be sure". With the buggy software we the developers have to use and also produce, a restart is always safer than various "hot" redeploys, whether in JEE, Ruby, Lisp or .NET. As far as class modifications that break hot swap go, they're far rarer than the most common change where you change only the method bodies. Changing fields or method signatures usually comes with changes the state of the running program. I.e. if you add a field to a class, you usually want to have it set to something non-null when the program is initialized. So you'd either have to set them manually (which you can't in Java, as you can't even hot swap the change in) or you can just restart.
    Also, debugging means remote connecting to the "server" (localhost). So you end up having to configure a socket connection to your own machine, just to run the debugger!
    A socket! What a horror! Surely you had to pay expensive network consultants to peform such a high-tech procedure? I wouldn't know, as I use shared memory transport. ;)

    REPL just never was the idea. The idea was to build a middleware platform with administration, deployment, configuration etc. as some else has rightly pointed out earlier.
    JEE standard paid no thought to RPEL, but app server providers did. And I can't really think of one feature in JEE standard that would hinder RPEL. Those roles are just terms used to describe related responsibilites. As you well know, standard does not demand that each role must be filled by different person or that work performed by those roles must not be scripted and automated.
  37. Whoa, I seriously messed up quoting...
    Not sure about the Spring hot deploy stuff (I've never used it), but application server/web server hot deploy doesn't always work (something to do with whether you've changed the shape of your classes I think). So after getting burnt a few times you re-build, re-package, re-deploy, restart Weblogic etc each time just to be sure.
    Well, I know a few people who fell into this trap by getting burned a few times. I also know production system that has scheduled downtime every Saturday. Reason: to restart all the software. No real reasons (memory leaks, data corruption), but "just to be sure".

    With the buggy software we the developers have to use and also produce, a restart is always safer than various "hot" redeploys, whether in JEE, Ruby, Lisp or .NET. As far as class modifications that break hot swap go, they're far rarer than the most common change where you change only the method bodies. Changing fields or method signatures usually comes with changes the state of the running program. I.e. if you add a field to a class, you usually want to have it set to something non-null when the program is initialized. So you'd either have to set them manually (which you can't in Java, as you can't even hot swap the change in) or you can just restart.
    Also, debugging means remote connecting to the "server" (localhost). So you end up having to configure a socket connection to your own machine, just to run the debugger!
    A socket! What a horror! Surely you had to pay expensive network consultants to peform such a high-tech procedure? I wouldn't know, as I use shared memory transport. ;)
    REPL just never was the idea. The idea was to build a middleware platform with administration, deployment, configuration etc. as some else has rightly pointed out earlier.
    JEE standard paid no thought to RPEL, but app server providers did. And I can't really think of one feature in JEE standard that would hinder RPEL. Those roles are just terms used to describe related responsibilites. As you well know, standard does not demand that each role must be filled by different person or that work performed by those roles must not be scripted and automated.
  38. Hi,
    JEE standard paid no thought to RPEL, but app server providers did.
    And I can't really think of one feature in JEE standard that would hinder RPEL. Those roles are just terms used to describe related responsibilites. As you well know, standard does not demand that each role must be filled by different person or that work performed by those roles must not be scripted and automated.
    I read these responses on TSS and sometimes I wonder whether we all share the same universe. When you have had to unpackage an EAR you bought off the self and re-package it with EJB's of your own so as to avoid class-loader problems like I have you know that the roles in the JEE spec are more than just names. Another good example is pi*sing around with JNDI configurations. Other than the bit I've quoted the rest of your post makes my point. JEE hot-deply cannot be used relied upon. There are work arounds like sticking to a lightweight Java webserver (like resin) that you can run inside your IDE (debugging without sockets), but especaily when you get to App Servers the fact that ease of development and testing wasn't designed in from the beginning has a real impact on productivity. BTW before you so readilly dismiss other languages, there are languages out there (LISP, Smalltalk, Python, Ruby just to name a few) were REPL immediacy works and can be relied upon. Don't knock it untill you've tried it. Paul.
  39. Re: RPEL and JEE deployment woes[ Go to top ]

    but especaily when you get to App Servers the fact that ease of development and testing wasn't designed in from the beginning has a real impact on productivity.

    BTW before you so readilly dismiss other languages, there are languages out there (LISP, Smalltalk, Python, Ruby just to name a few) were REPL immediacy works and can be relied upon. Don't knock it untill you've tried it.

    Paul.
    The thing is... there are always compromises, and I don't think you are comparing like with like. Immediacy and clustering and security and performance and robustness aren't easily put together. It is easy to simply say 'use Ruby or LISP', but those languages don't implement WebSphere (for example) - scale solutions. There are solutions which possibly come close in dynamic languages (such as Gemstone/Smalltalk), but they usually have highly proprietary approaches (definitely 'vendor driven'!) to these problems and (in the case of Smalltalk) lack performance. Anyway, compared to the horrors of C/C++ development that preceeded much use of Java, I don't think it is entirely fair to say that ease of development wasn't a significant factor in the take-up of J2EE.
  40. Re: Here's the problem...[ Go to top ]

    Hi,

    I can see I've hit a nerve.

    Looking into Common Lisp can't be described as jumping onto a band wagon after all it's been around for over 50 years :^).
    No, jumping off of Java is the current bandwagon. I've been coding CL for 10 years. Been there, done that, got the bookshelf to prove it. I was coding Smalltalk in '85-'86. Got that bookshelf too. So, yea, I've been around the block a wee bit myself. I Get It. I've also owned BMWs, Toyotas, etc., yet I now drive a Ford. It's my second, not including my wifes. Java is a fine environment. At the scale we work at, it does most everything we can ask of it, using a mixture of tools, using a mixture of idioms and methodologies. We can cherry pick all the bits we like. It lacks macros. Sucks. No multi-methods. Bummer. But, life goes on. Java is expressive enough. Expressiveness can help combat complexity, but it doesn't cure it, and it simply hides it under a different flavored sugar coating. The complexity is still there. Always will be, and the complexity is what kills. No matter how you hide it, you still need to understand it, you still need to have access to it, and you still need to manipulate the environment within which is breeds. Java is more than suitable to this task. It offers just crazy amounts of flexibility. All sorts of rope available to hang yourself with. If the problems were simple, the tools would be too. Have you looked at the assortment of Hammers at the hardware store recently? Talk about a simple problem, and even the professionals there can't seem to get it right. So, enjoy CL. It's a hoot. Really! But when the metal meets the road, you're still pumping bits through the socket and rows to the DB -- and at that level, most everything looks the same.
  41. Re: Here's the problem...[ Go to top ]

    Hi
    Java is a fine environment.
    I agree. I think the Java language is fine, Java EE though IMO is a mixed bag.
    I've also owned BMWs, Toyotas, etc., yet I now drive a Ford. It's my second, not including my wifes.
    I like your analogy with cars and I do get your point. My point is that you wouldn't use a 2 seater sports car to take the kids to school or a people carrier on a romantic weekend with just you and the wife. Horses for courses.
    No matter how you hide it, you still need to understand it, you still need to have access to it, and you still need to manipulate the environment within which is breeds. Java is more than suitable to this task. It offers just crazy amounts of flexibility. All sorts of rope available to hang yourself with.
    I agree totally with this point too as far as Java is concerned. As for Java EE, the difficulty is that you don't have access under the hood. The engine bay is sealed, you take what your given whether you need it or not. I get your point, but I simply do not think that Java EE is always the best choice; and I believe increasingly there are better options for different pieces of the enterprise pie. Regardless of language, I believe that all the different pieces in the enterprise should be able to integrate together in harmony and SOA does offer this possibility (personally I prefer messaging, but that is a different discussion).
    Have you looked at the assortment of Hammers at the hardware store recently? Talk about a simple problem, and even the professionals there can't seem to get it right.
    This is my point entirely, you don't use a sledge hammer to crack a nut. Paul
  42. Re: Here's the problem...[ Go to top ]

    As for Java EE, the difficulty is that you don't have access under the hood. The engine bay is sealed, you take what your given whether you need it or not.
    No, it certainly isn't sealed. JEE is a kit of parts. You can choose the pieces you want. Even the implementations are open source - from Tomcat to JBoss. You can even add in or substitute non-JEE pieces, such as Spring, JDO or Tapestry.
  43. Re: Here's the problem...[ Go to top ]

    Nah, that's a simplistic view. I think it can be proven formally and empirically that systems can vary greatly in complexity. Let's take one case, working with file uploads, which is very common in any content management style app (and there are lots of those). If you deploy a .war or even just have to deal with the possibility that someone might deploy your app as a .war, you cannot store uploaded files within the application's file structure, so other people can download that file. In PHP you can. In standard J2EE you can't. That's it. This use-case is definately more complex in JEE, because you have to work around the .war issue. Does that mean JEE is always more complex? Certainly not. You have to look at it use-case by use-case and if you do that with all the use-cases you actually have to cover, then you eventually know whether JEE was more or less complex than PHP (or Ruby) for that particular application. Trouble is that many people find JEE too complex for many frequent types of applications. Some say, just don't use the parts you don't need. But that's exactly where JEE's design just lacks. The problem is this: JEE leaks complexity. E.g. You cannot avoid to deal with the insane develp/deploy/change cycle that JEE forces upon you. The .war issue is a good example of this problem. If some inherently complex enterprise deployments need that kind of packaged module deployment as a single file, then there should be an abstraction that shields developers from it when they don't need it (virtual file system?). At least the designers should have erred on the side of simplicity instead of forcing everyone to act as if they were hired to implement the merger of WalMart and Citigroup. I want to be able to load and save files in my application file structure. I don't want to use getResourceAsStream(..) in one case and the file APIs in the other or store uploaded files in a database. JEE promised to be an application development platform that lets me deal with my business problems and shields me from technicalities. But this is not a business problem, this is a pure technicality that wasn't even there before JEE introduced it. So, in this case, JEE is just unfit for it's stated purpose.
  44. Re: Here's the problem...[ Go to top ]

    Nah, that's a simplistic view. I think it can be proven formally and empirically that systems can vary greatly in complexity.
    Ummm...of course.
    Let's take one case, working with file uploads, which is very common in any content management style app (and there are lots of those). If you deploy a .war or even just have to deal with the possibility that someone might deploy your app as a .war, you cannot store uploaded files within the application's file structure, so other people can download that file. In PHP you can. In standard J2EE you can't.
    And this can be easily worked around with any of the containers that I'm aware of. Every container I know will allow File I/O from the app tier (even though the spec says "no"), and every container I know can be deployed from an exploded war/ear file. Just don't use the container "war exploder" lest it obliterate your CMS data.
    At least the designers should have erred on the side of simplicity instead of forcing everyone to act as if they were hired to implement the merger of WalMart and Citigroup.
    EJB3 is addressing this a bit, but I'm actually glad they dealt with it up front. The reason I'm glad is that it better exposes the issues involved in porting an app from container to container, as well as integrating disparate bits within the container (remember, EJB is really a component model). My fear is that had they done the "simple is as simple does" method, the compliance level of container portability would have suffered since the use case would have been lower. Folks wouldn't have written their apps portably, and apps wouldn't have ported as easily as they do now. (yea, apps have issues, of course they do, but they DO port.) And if you didn't have container portability, JEE would have been dead at the gate. Having a standard with only one "real" implementation and a bunch of "broken" ones does no one any good. And portability has grown over the years as things got a bit more explicit with folks actually porting applications.
    I want to be able to load and save files in my application file structure. I don't want to use getResourceAsStream(..) in one case and the file APIs in the other or store uploaded files in a database. JEE promised to be an application development platform that lets me deal with my business problems and shields me from technicalities. But this is not a business problem, this is a pure technicality that wasn't even there before JEE introduced it. So, in this case, JEE is just unfit for it's stated purpose.
    The file system was hand waved away because there were other mechanisms available to plug that hole. When you live in a distributed environment (pretty much a foundation of early EJB), file systems don't necessarily map well to that environment. They also don't map very well to the very transactional nature of the JEE tier. Clearly, the DB was JEE preferred technique for persisting data. But, you can also use JNDI. Of course most don't. Most said "Boy, this is a silly limitation, we'll just do it anyway." As an aside (funny that you bring this up), I'm working on a small CMS project as we speak. I'm storing the data outside of the app tree. Then I'm having a Filter intercept where it SHOULD be in the app tree, and then if it's not there, it copies it from outside the app tree into the app tree, and then just continues with the request to let the container actually serve it up. Why am I doing that? Because I want to be able to upgrade the app with a simple .war drop. I want to leverage the remote deployment options of my container. I also want to leverage the 80 gazillions lines of code and man years of testing that went in to the containers "how do I serve up content that ends with .gif". Since I won't be working with GB downloads, since 99% of my content is static, I have no problems duplicating the data, or eating the copy cost on first access to my "cache". I keep my portability, and let the container do what the container does, without having to store stuff in the DB, at the cost of a simple filter and a few MBs of disk space. Voila.
  45. Re: Here's the problem...[ Go to top ]

    Let's take one case, working with file uploads, which is very common in any content management style app (and there are lots of those). If you deploy a .war or even just have to deal with the possibility that someone might deploy your app as a .war, you cannot store uploaded files within the application's file structure, so other people can download that file. In PHP you can. In standard J2EE you can't.


    And this can be easily worked around with any of the containers that I'm aware of. Every container I know will allow File I/O from the app tier (even though the spec says "no")
    That's extactly what I mean, and it's the same with a huge number of small things. The spec mandates something completely nonsensical and we have to work around it using mechanisms offered by particular containers and tools, destroying portability, adding brain bloat. It's the kind of knowlege that is unproductive waste.
    At least the designers should have erred on the side of simplicity instead of forcing everyone to act as if they were hired to implement the merger of WalMart and Citigroup.
    EJB3 is addressing this a bit, but I'm actually glad they dealt with it up front. The reason I'm glad is that it better exposes the issues involved in porting an app from container to container, as well as integrating disparate bits within the container (remember, EJB is really a component model). My fear is that had they done the "simple is as simple does" method, the compliance level of container portability would have suffered since the use case would have been lower. Folks wouldn't have written their apps portably, and apps wouldn't have ported as easily as they do now. (yea, apps have issues, of course they do, but they DO port.) And if you didn't have container portability, JEE would have been dead at the gate.

    Having a standard with only one "real" implementation and a bunch of "broken" ones does no one any good. And portability has grown over the years as things got a bit more explicit with folks actually porting applications.
    You are right in principle. I remember very well the days of Tuxedo and MQ Series. But I refuse to believe that portability cannot be achieved in a smarter way. The .war issue is a point in case. It destroys portability and it isn't hard to think of a portable solution that facilitates both the simple and the complex cases. It's just bad design.
    I want to be able to load and save files in my application file structure. I don't want to use getResourceAsStream(..) in one case and the file APIs in the other or store uploaded files in a database. JEE promised to be an application development platform that lets me deal with my business problems and shields me from technicalities. But this is not a business problem, this is a pure technicality that wasn't even there before JEE introduced it. So, in this case, JEE is just unfit for it's stated purpose.


    The file system was hand waved away because there were other mechanisms available to plug that hole.
    Yeah, but if I think about it, I'm just stunned. How can anybody just "wave away" a reasonably simple structure for organising data that has been with us for decades and that everybody knows very well? It's such a crazy idea, I really can't believe they did that. If they had done it consistently, I would say it was innovative. But they didn't. They kept the notion of a file system tree around, but made it read-only (the .war)
    When you live in a distributed environment (pretty much a foundation of early EJB), file systems don't necessarily map well to that environment.
    Why not? Virtual distributed file systems of all kinds have existed for a long time.
    They also don't map very well to the very transactional nature of the JEE tier.

    Clearly, the DB was JEE preferred technique for persisting data.
    If that's what they were thinking, why did they not specify a way to store application resources in the database and map HTTP requests to queries? Probably because it'd be rather inefficient. So they took away the file store without providing a comparably simple alternative.
    As an aside (funny that you bring this up), I'm working on a small CMS project as we speak. I'm storing the data outside of the app tree. Then I'm having a Filter intercept where it SHOULD be in the app tree, and then if it's not there, it copies it from outside the app tree into the app tree, and then just continues with the request to let the container actually serve it up.

    Why am I doing that?

    Because I want to be able to upgrade the app with a simple .war drop. I want to leverage the remote deployment options of my container. I also want to leverage the 80 gazillions lines of code and man years of testing that went in to the containers "how do I serve up content that ends with .gif".

    Since I won't be working with GB downloads, since 99% of my content is static, I have no problems duplicating the data, or eating the copy cost on first access to my "cache". I keep my portability, and let the container do what the container does, without having to store stuff in the DB, at the cost of a simple filter and a few MBs of disk space.

    Voila.
    So there you have a workaround for something that shouldn't be necessary in the first place. I had similar situations, but with the additional requirement that JSP pages had to be added to the system. I was thinking about the kind of solutions you came up with. But, in the end decided against it because I'd have to care about caching, checking whether the JSP was updated, which would have effectively forced me to duplicate all the update checking, caching and security configurations that the container already provides. And of course the user would have to configure the file paths. It's just useless added complexity with great potential for errors. 80 gazillion lines of code is no excuse for such an insanity. There's another issue that has bugged me for years: How can I add database connections, message queues, URL connections, etc, at runtime? That's something that comes up frequently in integration scenarios (which is the field I work in). Effectively you can't. You have to stop the application, reconfigure it, and then start it again. In some cases that's logically inevitable, in others it is not. The result is an "enterprise" system that basically behaves like windows 3.1. But that's not the biggest issue. The big issue is that adding connections works differently for every single app server. So when I write an administration console for my integration app, I have to write a plugin for every app server I want to support. Why do I not rely on the app server administration console? Because they cover all the general cases and thus come with a lot of complexity that I can't force onto my users. What I need is a subset of configuration tasks customised for the particular roles that exist in my integration scenario. So, in this case, it's not simplicity that I'm missing. Quite the contrary. I'm missing fundamental capabilities required in typical complex enterprise situations. I don't think there is anything that JEE is used for more frequently than integration. But it still lacks a very important feature for an integration platform: A standardised API for management of resource adapters. They gave us JMX. But that's just a way for vendors to make their _own_ management APIs available. There is no f***ing addJDBCConnection() or addMessageQueue() API in all those thousands of pages of JEE spec. Why not? So, in my opinion, JEE falls short at the low end _and_ at the high end of complexity.
  46. Hi Paul I completely agree with you. Java is a good OO language but lets face it, it's not the centre of the world. Another thing...enterprise scale applications don't need to be complex. Spring and other lightweight architectures/containers offer better solutions to developing enterprise applications. For example I have created an application using Spring's JMS support which is so much easier to develop than the traditional approach. I'm sure EJBs and other JavaEE features are beneficial but I am yet to be amazed. POJOs and declarative services via AOP is the way forward. Amin
  47. Hi Paul

    I completely agree with you. Java is a good OO language but lets face it, it's not the centre of the world.

    Another thing...enterprise scale applications don't need to be complex. Spring and other lightweight architectures/containers offer better solutions to developing enterprise applications. For example I have created an application using Spring's JMS support which is so much easier to develop than the traditional approach.

    I'm sure EJBs and other JavaEE features are beneficial but I am yet to be amazed.

    POJOs and declarative services via AOP is the way forward.

    Amin
    Hi Amin, I agree. lightweight IoC containers, POJO's and ORM tools like Hibernate have shown the way. The truth is that J2EE Application Servers were never very OO, hence the call to get back to Plain Old Java Objects. I'm back using Weblogic at the minute after years away, and boy isn't it tedious. Rod Johnson makes the point well when he says that Java is more than EJB. IMO Ruby developers are taking the same idea of getting back to basics one stage further. The pure OO integrity, immediacy of development and deep reflectiveness of Ruby opens up new opportunities for improved productivity IMO. Time will tell. Paul.
  48. Compexity kills.
    But, very often (at least in my experience), so does over-simplicity and underpowered software which can't expand or scale to meet increasing demand.
    This simple point seems largely lost on the J2EE community, as they regularly turn their nose up at simpler alternatives(PHP, Ruby etc.)
    Which, is flatly contradicted by the existence of JSRs for BeanShell and Groovy, and scripting support in Java 6.0, and thriving projects such as JRuby.
    using silly arguments about "industrial strength" and "future proofing".
    As has been discussed at length in other threads, these arguments certainly aren't "silly". Far too much "throw-away" software has already been and still is being written. As someone who deals with this on a daily basis, I find the idea that software isn't written with at least some consideration of future expansion and future use rather depressing, and a sorry reflection on the state of IT.
  49. Hi Steve,
    Far too much "throw-away" software has already been and still is being written.
    Lets not get into this one :^) What you may describe as "throw away" software, I could choose to describe as clean, simple and crisp code that delivers business value in a timely manner, perhaps to be be refactored another day or replaced. I do not see my code as static, written once and living for ever. I see it as an evolving entity meeting the differing needs of the business in a timely maner at differing times in it's lifecycle. Whether it lasts a week or a decade before succumbing to change is not the point IMO. The point is how easy it is to change when change is needed. Interstingly some "non-throw-away code" architectures like some Java EE tend to be resistant to change, by not conforming to good OO principles and instead opting for anti-patterns like DTO's enforced for no good reason. Dynamic businesses are not static, and they are increasingly requesting software that evolves and emerges over time too. They aren't willing to wait 6 months+ before they can see a release and realise a return on their investment either. They want early and frequent releases, addressing emergent requirements, as they emerge, hence the increasing interest in Agile approaches and emergent design. I think we start with different assumptions and there is space for both of us. What is needed is choice IMO. With more technology variety will give us more choices, I don't see Java EE going away any time soon :^).
  50. I do not see my code as static, written once and living for ever. I see it as an evolving entity meeting the differing needs of the business in a timely maner at differing times in it's lifecycle. Whether it lasts a week or a decade before succumbing to change is not the point IMO.
    Well, I think it is at least part of the point.
    The point is how easy it is to change when change is needed.
    Which is what part of what I would call "future proofing" - one of those "silly" arguments :)
    Interstingly some "non-throw-away code" architectures like some Java EE tend to be resistant to change, by not conforming to good OO principles and instead opting for anti-patterns like DTO's enforced for no good reason.
    Yes, but you are talking about only a small part of JEE.
    Dynamic businesses are not static, and they are increasingly requesting software that evolves and emerges over time too.
    More 'future proofing', and also 'industrial strength'...
    They aren't willing to wait 6 months+ before they can see a release and realise a return on their investment either. They want early and frequent releases, addressing emergent requirements, as they emerge, hence the increasing interest in Agile approaches and emergent design.
    Indeed. Projects are delivered on short timescales using Java + Spring + Hibernate, which is why JEE has adopted a considerable number of ideas from those frameworks.
    I think we start with different assumptions and there is space for both of us. What is needed is choice IMO. With more technology variety will give us more choices, I don't see Java EE going away any time soon :^).
    I think there has always been a considerable amount of choice, and it is increasing. JEE is about choice - it is not an 'all-in-one' system that has to be used in its entirety. (It has been much misused because of that approach).
  51. Fearing PHP[ Go to top ]

    Compexity kills. This simple point seems largely lost on the J2EE community, as they regularly turn their nose up at simpler alternatives(PHP, Ruby etc.) using silly arguments about "industrial strength" and "future proofing".
    I avoid deploying anything onto my servers that utilize PHP for one reason. Security. I was tempted to deploy some very good sounding PHP tools until I looked into my Apache access logs. I noticed reams and reams of attacks on my site using a variety of known PHP attack mechanisms. Maybe these have all been resolved. I don't know. But they cause me to doubt the "industrial strength" nature of PHP. John Murray Sobetech
  52. Who is this[ Go to top ]

    Nice soap :-) "The goal of the virtual machine is to provide for code portability, while in SOA, interoperability is far more important," he said. "Why go through all that trouble to build portable code, when in SOA, you want to leave the code where it is? Fundamentally, the virtual machine approach to distributed computing is through the serialization of objects leading to remote method invocation, while SOA runs on the exchange of messages between services with contracted interfaces." Yes. And a few levels lower it is all zeros and ones. Why go through all that trouble if you just want to exchange messages. Lol. At least Richard M H has it right when he says: "SOA certainly diminishes the importance of a common programming model," the Burton analyst said. "Because it's not what's serving up the communications that's important, it's the communications itself. It's the data you're exchanging. It's the method in which you're exchanging the data that matters, not the programming model behind the data." But what does he propose as an alternative for a 'common programming model'. Don't we really want a common 'API' to build (SOA) services on? Or does RMH suggest we all go back to the early 90s and use those 3872832 different frameworks in perl/java/ruby/shell/python/C++ and reinvent the wheel again? "Finally, ZapThink's Bloomberg said the Enterprise JavaBeans/Servlet/Java Server Pages framework doesn't jibe with SOA." Probably because he left out JMS and Web Services. Which is interested because he wrote a book about Web Services. S.
  53. Ruby (for example) is taking over rapid development and deployment of simpler applications that were formerly perceived as bread and butter for Java
    Yeah, right: Dice.com... Ruby on Rails: 57 jobs Java: 14297 jobs And this has not changed that much for a long time. Even assuming RoR is being used for many internal projects (as are many other technologies), the above statement (especially the phrase 'taking over') is plainly nonsense. (Unless there are very few 'simple applications').
    One architect from a Fortune 100, dismissed the report, saying that it's "an analysts group's cry for attention by trolling."
    Well, indeed.
  54. Rails vs. java jobs?[ Go to top ]

    Ruby on Rails: 57 jobs Java: 14297 jobs
    I don't suppose that can be attributed to the fact that Rails is a very narrow (by design) specific framework and Java is a complete language, maybe? Nah, that wouldn't make your pithy soundbite sized comment make sense. Or is it because Rails, in any sort of "production" sense is MAYBE 18 months old, and Java over 6 or 7 years, easy? Nahhhh... Or because Java has been sold, sold, sold, sold by a mega corp and Rails by grassroots evangelism? COULDN'T BE! No, wait, it must be that because it takes over 14,000 java programmers to do what 57 Rails programmers can... =) (ObDisclaimer: Java and J2EE pays my salary, and I'm happy with it, it's just that I try not to be a tech bigot.)
  55. > Ruby on Rails: 57 jobs
    > Java: 14297 jobs

    I don't suppose that can be attributed to the fact that Rails is a very narrow (by design) specific framework and Java is a complete language, maybe? Nah, that wouldn't make your pithy soundbite sized comment make sense.

    Or is it because Rails, in any sort of "production" sense is MAYBE 18 months old, and Java over 6 or 7 years, easy? Nahhhh...

    Or because Java has been sold, sold, sold, sold by a mega corp and Rails by grassroots evangelism? COULDN'T BE!

    No, wait, it must be that because it takes over 14,000 java programmers to do what 57 Rails programmers can... =)


    (ObDisclaimer: Java and J2EE pays my salary, and I'm happy with it, it's just that I try not to be a tech bigot.)
    But it still doesn't prove that (according to the article) "Ruby (for example) is taking over rapid development and deployment of simpler applications that were formerly perceived as bread and butter for Java".
  56. Re: Rails vs. java jobs?[ Go to top ]

    > Ruby on Rails: 57 jobs
    > Java: 14297 jobs

    I don't suppose that can be attributed to the fact that Rails is a very narrow (by design) specific framework and Java is a complete language, maybe? Nah, that wouldn't make your pithy soundbite sized comment make sense.

    Or is it because Rails, in any sort of "production" sense is MAYBE 18 months old, and Java over 6 or 7 years, easy? Nahhhh...

    Or because Java has been sold, sold, sold, sold by a mega corp and Rails by grassroots evangelism? COULDN'T BE!

    No, wait, it must be that because it takes over 14,000 java programmers to do what 57 Rails programmers can... =)


    (ObDisclaimer: Java and J2EE pays my salary, and I'm happy with it, it's just that I try not to be a tech bigot.)
    It doesn't matter what it can be attributed to - that is not the point. You are arguing against things I was not discussing - I never raised issues of how these these technologies were marketed. I never even mentioned if this was a good or bad thing. The point is that the article claimed that Ruby was actually taking over from Java in certain areas. All I was claiming was that for whatever reasons, it seems that this is a wildly exaggerated claim.
  57. Re: Rails vs. java jobs?[ Go to top ]

    No, wait, it must be that because it takes over 14,000 java programmers to do what 57 Rails programmers can...
    ObDisclaimer: Java and J2EE pays my salary, and I'm happy with it, it's just that I try not to be a tech bigot.)
    Really - and that is backed by the previous quote?
  58. No, wait, it must be that because it takes over 14,000 java programmers to do what 57 Rails programmers can...


    ObDisclaimer: Java and J2EE pays my salary, and I'm happy with it, it's just that I try not to be a tech bigot.)


    Really - and that is backed by the previous quote?
    If you're going to quote me, please try harder to get the context. My original posting clearly had a smiley there, indicating sarcasm.
  59. Since most analysts can't even agree on the definition of a Service Oriented Architecture (or when they can it's so fluffy that just about any MOM / RPC middleware can lay claim to being SOA**) its humorous that they can claim that it will kill JEE 5.0. Even more humorous is the contention that SOA is somehow simpler than JEE 5.0. Have they not read the WS-* specs? Richard's comments that developers are flocking to Ruby for its simplicity and that Web Services offer a language independent interface into the backend are reasonable assertions. The extrapolation to SOA being the death knell for JEE 5.0 is delusional, though. ** Given that anyone involved in SOA goes to so much pain to deny the reality that SOA pretty much is Web Services and you're very lucky if you don't get stuck with HTTP as your protocol.
  60. Richard's comments that developers are flocking to Ruby for its simplicity and that Web Services offer a language independent interface into the backend are reasonable assertions.
    I don't think it is. I simply don't see any evidence for it. I see a lot of interest in Ruby. I see a lot of news about Ruby, and I see Ruby (and Rails) being influential. However, in terms of developers moving substantially towards it, and actually using it for a large number of projects, I just don't see any figures that back that up. (If I am wrong, I would be intested to know what evidence there is). Development tends to be reactionary. To mix metaphors badly, I don't think developers flock towards anything - I think as a herd, they tend to crawl :)
  61. Hi Steve, I agree. I don't see signs of people flocking to anything in particular, but people are beginning to ask questions which is a good thing. There are a number of positive trends at the moment, like the growing interest in Agile development, interest in dynamic languages also interest in functional languages, none of these have a particularly strong vendor push which I think is a good thing. With developers starting to think for themselves it is likely that a number of new viable and interoparable technologies will arise with us able to pick and choose the right tool for each job. As I've said several times before, I don't believe that one language/standard etc will ever fit all scenarios. Paul.
  62. This guy gotta be kidding!!![ Go to top ]

    Honestly! This Monson-Haefel guy shouldn't have wrote a line of code of enterprise Java in his life. As many fellow developers have, I have implemented many software architectures that proves not only that Java EE is not dying, but is also a major SOA enabler for many organizations. Let's face it, legacy systems are usually hard to expose, and Java's portability is the most powerful tool available in the market to address the challenge to integrate systems deployed in many different platforms into a SOA. I can't imagine myself struggling with Rails (or place your favourite new technology here) trying to handle all the issues I have to face every day against a AS/400 system with the easiness and reliability I find in all the JavaEE platform. If complexity is the big concern of the analysis, my experience dictates me that there's no such a thing as a complex JavaEE stack, only lazy minds incapable of realize that you don't need to use the full JavaEE stack of technologies on every case. If you use just what you need and design your application well, you'll get a great solutions most of the time. Jorge Suarez
  63. Honestly! This Monson-Haefel guy shouldn't have wrote a line of code of enterprise Java in his life. As many fellow developers have, I have implemented many software architectures that proves not only that Java EE is not dying, but is also a major SOA enabler for many organizations.
    You're kidding, right? RMH has a number of resources on EJB. (See, for example, Enterprise Javabeans 3.0, by Bill Burke and Richard Monson-Haefel.)
  64. +1 ! We all start playing with J2EE, EJB design patterns and all that with Monson-Haefel books and litterature. It is really interesting to see his opinion on Java @ entreprise level ! Richard is one of the most valuable specialist on this field, it does not mean that he has got truth... but It simply means that ideas and reflexions from him must be considered !!! Stephan
  65. "platform has grown too complex to be workable for enterprise developers."
    I think enterprise computing will just come to an end since enterprise developers can't handle complexity. Maybe business should starting hiring video game developers since games seem to get more complex every year and they seem to be handling it ok. Or maybe we should figure out how to build enterprise applications on top of Halo? Personally, I think it may be best to hire developers that understand and can handle complexity instead of believing all the vendor hype about how they can solve all that complexity stuff for you, thus allowing you to hire "commodity" developers. Don't get me wrong, I'm all for avoiding complexity when it is not needed, but finding simple solutions to complex problems is usually a pipe dream, or just good marketing. The trick is learning not to introduce complexity for simple problems. Of course, my opinion is tainted with marketing, too, since I make my living by solving complex problems in the enterprise. Chris K.

  66. Maybe business should starting hiring video game developers since games seem to get more complex every year and they seem to be handling it ok.
    I know you say that slightly with tongue in cheek but there is some validity in that statement. As an individual who came over from the lower paying / long hour simulation and game industry, I can attest to the efficiency of the programming trends and practices in that industry. They don’t drink allot of Kool-Aid in that industry and they tend to shun fluffy ideas like SOA or MVC or any of the new, I can publish a book if I invent it, buzz words, methodologies / frameworks / patterns. Instead they focus on the core benefits of programming, code reuse and abstraction. A fair amount of simulation/game systems are pluggable and allow AI /UI / graph / network programmers to focus on their domain without worrying about the other domains implementation whether that implementation is code or these nasty XML config files that everyone seems to think we need. Most game / simulation programming uses variations of the observer pattern to broadcast events across any given amount of subscribers. Instead of tightly coupling events to single procedural method that then instances a bunch of objects, then pass data to and reads from said object to affect an outcome, many simulation systems will register listeners who then provide callbacks with the data these listeners need. Each listener then performs its domain specific functionality independent of reliance on master routine. If new logic is needed in a domain that specialist then wires into the observer to add that functionality at event time. Variations of this simple pattern reduces complexity 1000 fold (I made that number up), yet it has been lost to ideas like SOA and MVC. SOA is just a new name for connecting two disparate systems; we have been doing “SOA” since two machines were connected on a network. Don’t get me wrong ideas like multi-platform messaging and separation of logic from presentation are great ideas and they complement reuse and abstraction, but it seems that people in the enterprise space take them too far to the point that they sacrifice reuse and abstraction in another area such as breaking good old fashion OO. SOA is a step back to procedural programming and it relies on a lowest common denominator mentality. It sacrifices robustness for interoperability. Sometimes interoperability is more important (communication with another companies system) most of the time it is not.
  67. Halo developers? Goodbye.[ Go to top ]

    I know you say that slightly with tongue in cheek but there is some validity in that statement. As an individual who came over from the lower paying / long hour simulation and game industry, I can attest to the efficiency of the programming trends and practices in that industry. They don't drink allot[sic] of Kool-Aid in that industry and they tend to shun fluffy ideas like SOA or MVC or any of the new, I can publish a book if I invent it, buzz words, methodologies / frameworks / patterns.
    Well, thank goodness they don't belive in MVC, that fluffy pattern has shown itself worthless in enterprise design.
    Instead they focus on the core benefits of programming, code reuse and abstraction.
    Last I checked when they came out with Halo 2 they had to rebuild the entire game engine from scratch. Plus, modern games cost millions of dollars, take years to develop, and often are buggy until some patches have come out so I wouldn't say they have any kind of edge on software development practices. For the most part a video game is just a fat client that tends to be the only main process running on a machine. Of course they don't worry about integration, SOA, legacy systems, etc. It is a fun thing to throw out there but I don't think there is any kind of real comparison at all you can make between the quality and efficiency between these two types of developers at the architecture and design level. I'm not saying game programming is easier (you are) but that its concerns and constraints are a world apart from enterprise programming.
    A fair amount of simulation/game systems are pluggable and allow AI /UI / graph / network programmers to focus on their domain without worrying about the other domains implementation whether that implementation is code or these nasty XML config files that everyone seems to think we need. Most game / simulation programming uses variations of the observer pattern to broadcast events across any given amount of subscribers. Instead of tightly coupling events to single procedural method that then instances a bunch of objects, then pass data to and reads from said object to affect an outcome, many simulation systems will register listeners who then provide callbacks with the data these listeners need. Each listener then performs its domain specific functionality independent of reliance on master routine. If new logic is needed in a domain that specialist then wires into the observer to add that functionality at event time. Variations of this simple pattern reduces complexity 1000 fold (I made that number up), yet it has been lost to ideas like SOA and MVC. SOA is just a new name for connecting two disparate systems; we have been doing “SOA” since two machines were connected on a network.
    yep, that's all it is. Funny how all those network sims don't have to worry about SOX, various security policies, transactionality, business processes. What personally do you have against MVC? First design pattern you read about after "coming over" from the gaming industry?
    Don't get me wrong ideas like multi-platform messaging and separation of logic from presentation are great ideas and they complement reuse and abstraction, but it seems that people in the enterprise space take them too far to the point that they sacrifice reuse and abstraction in another area such as breaking good old fashion OO.
    Hmm...seems like Corba and DCOM went down the distributed OO track with mixed results. Silly enterprise people.
    SOA is a step back to procedural programming and it relies on a lowest common denominator mentality.
    Wow, you've nailed it. Wonder why we get paid more and get to work shorter hours?
    It sacrifices robustness for interoperability. Sometimes interoperability is more important (communication with another companies[sic] system) most of the time it is not.
    Have you ever worked on an enterprise system? Interoperability is pretty important when you have maybe 15 information silos of various technologies. I think what us silly enterprise people are going for is robustness and interoperability. I'm going to file this under: "I'm new to this, it is complicated so I don't get it, so it is bad and the people doing it are morons, unlike me." ______________ George Coller DevilElephant
  68. Well, thank goodness they don't believe in MVC, that fluffy pattern has shown itself worthless in enterprise design.
    I never said that I don’t believe in them re-read my post. I said that many game developers do not buy into them hook line and sinker, they use the best parts and trash the rest. There is nothing wrong with MVC as an architectural idea the problem lies with most individual’s implementation. People have become so bean oriented that they put all logic in the controller and no object specific logic gets encapsulated with the object thus sacrificing code reuse and increasing complexity just to follow a pattern. MVC coupled with Java has been moving towards this more and more. It is a flaw with the designers but it is the inevitability of architectural ideas that are not cemented.
    For the most part a video game is just a fat client that tends to be the only main process running on a machine. Of course they don't worry about integration, SOA, legacy systems, etc.
    Kernel, AI engine, scene graph, sound controller, physics engine all heavily decoupled many of which separate processes and sometimes even servers. Communication with various OEM systems, OpenGL, DirectX, sounds about like integration to me.
    It is a fun thing to throw out there but I don't think there is any kind of real comparison at all you can make between the quality and efficiency between these two types of developers at the architecture and design level. I'm not saying game programming is easier (you are) but that its concerns and constraints are a world apart from enterprise programming.
    I never said that either where easy, the only point I was making was that complexity can be managed and it is handled quite well my some game designs you inferred the rest.
    Funny how all those network sims don't have to worry about SOX, various security policies, transactionality, business processes. What personally do you have against MVC? First design pattern you read about after "coming over" from the gaming industry?
    Everything you cited has to be dealt with in any MMORPG. I don’t have anything against MVC I have something against over-architecting to adhere to some conceptual idea because someone said it is right with no flexibility it becomes a golden hammer.
    Hmm...seems like Corba and DCOM went down the distributed OO track with mixed results. Silly enterprise people.
    Please re-read the last part of my post and re-evaluate this sentence. At points in time sacrificing OO for interoperability is correct, most of the time it is not. You restating what I have already stated.
    Wow, you've nailed it. Wonder why we get paid more and get to work shorter hours?
    Unfortunately in your quest to jump the gun and flame me you took the sentence that this is in response to completely out of context. What I was saying is given two languages that where never meant to communicate with each other you will have to strip them down to their lowest common denominator for compatibility. Not that it takes lowest common denominator programmers to build enterprise systems. You SHOULD NOT BUILD AN ENTIRE PLATFORM ON LOWEST COMMON DENOMINATOR TECHNOLOGY which is exactly what SOA does. It should be relegated to system integration where it shines.
    Have you ever worked on an enterprise system?
    Does Google count? They run some software I help build. How about Hotels.com Or how about Travelocity do they count. Should I continue?
    Interoperability is pretty important when you have maybe 15 information silos of various technologies. I think what us silly enterprise people are going for is robustness and interoperability.
    I agree, if you re-read this sentence “shun fluffy ideas like SOA or MVC or any of the new, I can publish a book if I invent it, buzz words, methodologies / frameworks / patterns” added to this sentence “but it seems that people in the enterprise space take them too far to the point that they sacrifice reuse and abstraction” and conclude it with this sentence “Sometimes interoperability is more important (communication with another companies system) most of the time it is not.” You will see that I pretty much said that interoperability is important but that some people have taken the SOA and MVC thing way to far the fact is SOA is procedural programming and it is a step backwards. And MVC adhered to it a very strict sense is like trying for 5th normal form in relational design, a great idea on paper but muddled and unnecessarily complex in implementation.
    I'm going to file this under: "I'm new to this, it is complicated so I don't get it, so it is bad and the people doing it are morons, unlike me."
    File it wherever you want, I did nothing to provoke such a response from you I stated a point of view, if you don’t agree with it fine, but put your flamethrower away and lets try to refrain from generalizations and insults and debate the issue at hand. You have generalized assumptions about me and eluded to me making generalizations about all enterprise developers, these are not retorts to a sound justification as to why game developers seem to handle complexity in their systems quite well. I have offered a well pointed analysis as to why that may be, if you would like to refute it, please do so but do not infer meaning for me I am quite capable of speaking for myself. For the record I have been in the enterprise space for quite some time I know my way around the block and I know that Java server side suffers from some extreme over architecting. That is why you are seeing the open source projects now dominate the server side library landscape. Those in the know are sick of this over architecting that does nothing to reduce complexity and are taking matters into their own hands.
  69. Everything you cited has to be dealt with in any MMORPG. I don’t have anything against MVC I have something against over-architecting to adhere to some conceptual idea because someone said it is right with no flexibility it becomes a golden hammer.

    Funny you should bring up MMORPG's--To date these are the most bug-ridden pieces of software you will ever encounter. Many of the MMORPG companies have faced lawsuits over game down-time and instability, and have lost. Bugs/issues exist for years without being fixed. Patches to add new functionality usually breaks existing functionality. Exploits can go unstopped for days flooding virtual economies with duped money. Yeah, these developers should be writing my banking application... :P
  70. Tell us it isn't so...[ Go to top ]

    For the record I have been in the enterprise space for quite some time I know my way around the block and I know that Java server side suffers from some extreme over architecting. That is why you are seeing the open source projects now dominate the server side library landscape. Those in the know are sick of this over architecting that does nothing to reduce complexity and are taking matters into their own hands.
    +1 When people readily consume half baked vendor pushed ideas in the vein hope that it will secure their careers, they tend to get pretty defensive when someone rightly points out that perhaps they would have been better served getting "in the know" and thinking for themselves. Ask VB6 programmers, they will tell you. Hiding under the skirt tails of a vendor is no guarantee of a secure future. Your arguments are well reasoned and rational, but don't expect a rational response, there are a lot of scared people out there! If you had built your career on someone elses say so you would be scared too. Paul.
  71. Re: Tell us it isn't so...[ Go to top ]

    When people readily consume half baked vendor pushed ideas in the vein hope that it will secure their careers, they tend to get pretty defensive when someone rightly points out that perhaps they would have been better served getting "in the know" and thinking for themselves.

    Ask VB6 programmers, they will tell you. Hiding under the skirt tails of a vendor is no guarantee of a secure future.
    You are confusing two things here. JEE may be driven by ideas from vendors, but it is not subject to the whims of a single vendor, like VB6. That is one of the attractions of JEE - compatible implementations are available from multiple sources. On the other hand, some of the alternatives you are suggesting are subject to the insecurity you claim is present with JEE. Let's take Ruby as an example. It is a great language, but its development is driven largely by the writer of Ruby, 'Matz'. There will be a major new version sometime soon - Ruby 2.0. There will be incompatibilities with current versions. For example, the implementation of continuations - something many consider a significant feature of Ruby - will apparently be a 'low priority' in Ruby 2.0. So, were continuations in Ruby 1.0 a 'half-baked' idea? Where is the security for developers?
    Your arguments are well reasoned and rational, but don't expect a rational response, there are a lot of scared people out there! If you had built your career on someone elses say so you would be scared too.
    Using any development language or tool, you are trusting someone else's say so. Which is preferable - systems and APIs designed and maintained by a multi-vendor committee, with multiple implementations (commercial and open source), or a language and APIs that can change at the whim of a few developers?
  72. development complexity[ Go to top ]

    I think enterprise computing will just come to an end since enterprise developers can't handle complexity.
    A shallow talent pool definatly exists due to the quickly expanding technologies. Even with experienced developers there isn't a large pool of true OO folks around. And J2EE requires this type of approach to really work effectivly. Technologies like soap are great becasue they brake up enterprise development into smaller poorly written pieces instead of one large one. This lowers the number of developers and the amount of maintence while raising the amount and frequency of feedback. J2EE implementations can quickly getaway from a large team that isn't keeping a close eye on quality. -Todd
  73. The author is picking up on the OO to SOA paradigm shift but seems to be looking at the computing world with SOA blinders on. From 1980 to now, we have evolved additional paradigms for constructing computing systems. Pre 1990 it was functional procedural style programming. From 1990 to 2000, the emphasis in the industry was OO style programming with data and methods encapsulated in objects. The enterprise tiered architectures over the last ten years proved that for separation of tiers and for scalability, the focus needs to be on the data transferred between tiers. Each paradigm can serve a particular purpose depending on the computing system or part of the computing system being developed. SOA expands on the data model but also goes way beyond just the data model - mediated visibility, behavior models that contain actions models and process models, policies between different ownership domains, trust models, etc. All of this is necessary for specialized computing interoperability between different ownership domains. Java EE, however, can certainly play a role in the construction of certain pieces of an enterprise SOA. Danny http://www.soamodeling.org
  74. this just in[ Go to top ]

    The Burton group has announced it is worthless, and have decided to sell their souls to the highest bidder or any bidder. this non sense about SOA is retarded. SOA is just a new name for the same thing people have been doing with enterprise apps for over a decade. Yeah, and using SOA standards makes it less complex. This silly SOA hype needs to go away already, since it's just renaming the same old thing large companies have been doing for a long time. peter
  75. Just for the record, Richard Monson-Haefel is one of the best-known EJB figures. Besides, his famous EJB book, he was one the founders of OpenEJB container. Beauty of Java and in particular Java EE is its flexibility. Ironically, this flexibility leads to an extreme complexity which turns out to be its worst enemy. I have been Java for over 10 years, and I have seen many many developers - who have tried hard - but have not managed to hang on with Java. In my personal experience, 80% of developers - whom I have met- have given up on Java because its complexity. Yes, there is absolutely time that Java as a whole became simpler. It could be through simpler specifications, frameworks or even sample-applications. Back to SOA versus Java EE discussion. It seems that we are comparing apples and oranges? SOA is an architecture for integration of heterogenous resources. Doing so, SOA makes some sacrifices as integration happens through data-messages. Currently, several features that are trivial, in a homogeneous programming language like Java, are missing. Among others, SOA does not have a concept of type-safety, compilation etc. One of the drive-forces behind SOA is integration of legacy systems, also COBOL, CICS etc. Companies have made large investements in these systems, and they want to have a return of investement in a web-arena. I cannot see this kill Java EE.
  76. Hi, I agree with much of what you say. I've had the same experience over the last 10 years too. All you need to do is look at the average JEE bookshelf with the typical tomb sized volumes to realise that JEE has become too much. As for the relevance of SOA, Ive had experience of using JEE as an enterprise integration technology; integrating legacy systems as you mentioned. In such a role most of the heavy lifting is performed by the exisitng legacy systems. The role of Java EE is to integrate these legacy services and perhaps provide a user (web) interface. In this role something like Ruby is just as applicable as JEE, even more so IMO. Imagine a web based repository of services; where you can try out different services and see what they do interactively and in real-time. Ideal for a dynamic language. After verifying that your selected services do what you want you can script them together into a new application, testing as you go bottom up. The role of "enterprise glue" is much better suited to a dynamic environment and as I understand it this type of functionality has already been developed in Ruby on Rails and they are in the process of factoring it out. Add to this the ability to quickly prototype a web user interface and create perhaps a local application specific database, you have a means to rapidly develop new enterprise application based on existing legacy components. JEE was meant to have delivered this component based approach, but for one reason or the other this promise hasn't materialised. I've seen an architecture that came close though, using Tuxedo services as the enterprise backbone and JEE for EAI. An interactive tool allowed you to test your Tuxedo services interactively. Linking such functionaly to a dynamic language could lead to a highly productive enterprise component scripting environment IMO. Paul.
  77. Hi Paul I appreciate your view and experience on the subject of SOA. With my ignorance about Ruby and its abilities, let me address SOA and Java EE from another perspective, namely an organization's ability to absorb and build competency in various technologies. With my architect hat, I have disqualified several "interesting" technologies like .NET in our environment because of our organization's limited resources. It takes money, resources and not to mention lot of time to build knowledge around a give platform. Once this knowledge has been built, it is difficult to simply jump to another technology. This is the obvious reason why we still have many COBOL systems around.... On the other hand, one cannot be too conservative and stick always to the good-old-technology. So, there is a balance here. Correct me if I am wrong, but I cannot see yet Ruby be appealing enough to replace our strategic choice of technology, namely Java? Another issue is the balance between static configuration (like XML), scripting language and strong languages (like Java). In my experience, many times one over-uses XML or scripting languages. To give you an example, many rule engines use XML to represent rules. The syntax of such XML rules often get very complicated, and non-developers are not able to make adjustments to the rules. In such cases, it would be much better if the rules were actually written in Java. So back to your world of web services, the business process among those services, the question remains whether XML or a scripting language is good enough? Or is a strong language like Java an overkill? A last remark, Java-world is too eager to use Java for all purposes including integration in a heterogenous environment. E.g. JBI is heavily promoted by SUN. As of this writing, it seems to me that a more neutral platform (with XML,...) is a better approach for integration in heterogenous environments.
  78. Hi Nader,
    Hi Paul

    I appreciate your view and experience on the subject of SOA.
    Thanks.
    With my ignorance about Ruby and its abilities, let me address SOA and Java EE from another perspective, namely an organization's ability to absorb and build competency in various technologies. With my architect hat, I have disqualified several "interesting" technologies like .NET in our environment because of our organization's limited resources. It takes money, resources and not to mention lot of time to build knowledge around a give platform. Once this knowledge has been built, it is difficult to simply jump to another technology. This is the obvious reason why we still have many COBOL systems around.... On the other hand, one cannot be too conservative and stick always to the good-old-technology. So, there is a balance here. Correct me if I am wrong, but I cannot see yet Ruby be appealing enough to replace our strategic choice of technology, namely Java?
    I understand you, but I get very nervous when I hear people use the word "strategic". In my last project we used Java and Ruby side-by-side both in the same IDE (Eclipse). At the coal face where the work gets done by programmers it didn't present a problem. At the lofty "strategic" level of management however, well that's a different problem. The way we dealt with this is that we didn't tell them :^). Easy actually since we were only using Ruby to automate user acceptance testing otherwise it could have been a "big issue". There are barriers to adopting new technology, but IMO they tend to be more political and pyschological then real. For example, we seem willing to adopt new web technologies and languages all the time with very little problem (JavaScript, CSS1.0/2.0, HTML4.0, JSTL, AJAX etc). So why not adopt a lnaguage like Ruby?
    Another issue is the balance between static configuration (like XML), scripting language and strong languages (like Java). In my experience, many times one over-uses XML or scripting languages.
    I agree, I think XML is over used too. As for scripting languages, I think "scripting" is a poor term. For example the only thing Bash and Ruby have in common is that they are both interpreted. I prefer the term dynamic languages, although I also use the term "scripting" since a lot of people aren't familiar with the term dynamic. IMO dynamic languages are under-utilised. There are lots of problems that we currently solve with static languages that are better suited to dynamic languages IMO.
    To give you an example, many rule engines use XML to represent rules. The syntax of such XML rules often get very complicated, and non-developers are not able to make adjustments to the rules. In such cases, it would be much better if the rules were actually written in Java.
    IMO yes. I would also say that it would be much better still if the rules were written in Ruby. That way they could be changed dynamically. In a sense a rules engine is an attempt to bring dynamic behaviour to a static system. Dynamic languages allow you to change the code (rules) whilst the system is still running.
    So back to your world of web services, the business process among those services, the question remains whether XML or a scripting language is good enough? Or is a strong language like Java an overkill?
    What makes a language "Strong"? Ruby is strongly typed; the difference with Java being that the type checking occurs at runtime rather then being performed up front at compile time. Java does runtime type checking too (dynamic casts). The main difference IMO between Ruby and Java is that Ruby requires a different programming style, a style that most programmers with a C/C++ background aren't use to. Both approaches have there place IMO. For example Visual Basic is a dynamic language too, and it proved pretty popular. Its popularity could have had something to do with the ability of a dynamic language to provide immediate feedback (fast code/test cycle).
    A last remark, Java-world is too eager to use Java for all purposes including integration in a heterogenous environment. E.g. JBI is heavily promoted by SUN. As of this writing, it seems to me that a more neutral platform (with XML,...) is a better approach for integration in heterogenous environments.
    I agree. I think this was a weakness with JEE from the beginning. They assumed that Java would eventually take over the world. Technology aimed at making JEE a good enterprise citizen, like JCA was an after thought IMO. But please no more XML.. :^). Thanks for your post, I found it considered. BTW in an earlier post some one makes mention of JPython (Python running on the JVM) which is another way of integrating dynamic (scripting) and static code, JRuby is an attempt to do the same thing with Ruby. Paul.
  79. Hi Paul You have convinced me to take deep look into Ruby. Thanks.
  80. Bad example[ Go to top ]

    Hi,

    I agree with much of what you say. I've had the same experience over the last 10 years too. All you need to do is look at the average JEE bookshelf with the typical tomb sized volumes to realise that JEE has become too much.
    What has that gotta do with whether JEE is hard to use or not? Any popular concept will almost certainly have a lot of text published to satisfy demands.

    As for the relevance of SOA, Ive had experience of using JEE as an enterprise integration technology; integrating legacy systems as you mentioned. In such a role most of the heavy lifting is performed by the exisitng legacy systems. The role of Java EE is to integrate these legacy services and perhaps provide a user (web) interface. In this role something like Ruby is just as applicable as JEE, even more so IMO.

    Imagine a web based repository of services; where you can try out different services and see what they do interactively and in real-time. Ideal for a dynamic language. After verifying that your selected services do what you want you can script them together into a new application, testing as you go bottom up.

    The role of "enterprise glue" is much better suited to a dynamic environment and as I understand it this type of functionality has already been developed in Ruby on Rails and they are in the process of factoring it out. Add to this the ability to quickly prototype a web user interface and create perhaps a local application specific database, you have a means to rapidly develop new enterprise application based on existing legacy components.
    So how do you handle distributed transactions, if the chain of services that you call each updates a different transactional repository, how are you gonna ensure all or nothing (Please dont try to claim that such scenario is unlikely in an enterprise environment)? As for your Enterprise Integration with JEE, which part of JEE specifically did you use to claim that it is difficult? Were you using EJBs? JCA? servlets? JMS? Perhaps you are using the wrong approach.

    JEE was meant to have delivered this component based approach, but for one reason or the other this promise hasn't materialised. I've seen an architecture that came close though, using Tuxedo services as the enterprise backbone and JEE for EAI. An interactive tool allowed you to test your Tuxedo services interactively. Linking such functionaly to a dynamic language could lead to a highly productive enterprise component scripting environment IMO.

    Paul.
    It has, JEE comprisees of a lot of different technologies, think of it as a toolbox with many different tools inside. Each has its own use, and different combinations for different solutions. If people are using the wrong tool or combination to solve the wrong problems, then it is the fault of the user or perhaps the documentation or the lack of proper text, not the problem of the tool/toolbox (in this case JEE) itself. As for JEE5, if anything, it has actually made some of the parts in JEE (i.e. EJBs) a lot more pleasurable to work with. The same set of rules still apply as before, use the right tool for the right job. Also, SOA, IMO, is a very good complement to JEE (just another tool in the box, although its not part of the JEE spec). I dont see why a lot of people wants to pick one or the other.
  81. Re: Bad example[ Go to top ]

    Hi Steve, Most of your response could be summarised as JEE can do that too. I agree, I'm just saying that it could be done better. I thought I respond to one specific point though:
    So how do you handle distributed transactions, if the chain of services that you call each updates a different transactional repository, how are you gonna ensure all or nothing (Please dont try to claim that such scenario is unlikely)
    First of all distributed transactions existed long before JEE, and it wasn't an issue for most of use as we seldom needed them (most of us seldom need them today). If you do need a distributed transaction then you can do them the way they have always been done using a transaction monitor. There are many TM's that pre-date JEE and you can interface to them using C, which means Ruby. My point is that you don't need a full blown J2EE Application Server to do such things. Paul.
  82. My goodness ![ Go to top ]

    Thank God somebody told me, is all I can say, while there's still time to save my career by switching to a scripting language. HAHAHAHAHAHAAHHAHAAHHAHAHAHAHA - AH - AH - -AH - Ah, well, let us wait for the next quarter, when the analysts will doubtless have something different to say.
  83. SOA hype[ Go to top ]

    As I mentioned here http://www.theserverside.com/news/thread.tss?thread_id=41224#213134 I wished the Enterprise Java panel at the SS symposium would have talked a bit more about SOA in general. Has anyone dowloaded ServiceMix and played with it? Even with such a great framework, SOA doesn't come across as a simple concept to implement across (our) enterprise. Has anyone gone to an Oracle/etc SOA presentation? (Let alone priced out their SOA stack). Tell me that looks like it comes without complexity. At the end of the day it's just complexity with a different flavor. In fact, I found it amusing that at the last Oracle SOA conference I went to, the project lead of a real-world SOA solution admitted that the part of their SOA functionality which was to be handled by Business Analysts was pushed back to the developers because it was too complex for the business. For my company at least, SOA seems like overkill when faced with challenges that can be solved with EAI concepts. And Spring is simplifying this in a lot of ways for us.
  84. AnalystS? Was there anyone else heralding the end for JxEE in that article? Richard! First of all, let me say that your books arent bad. They did in fact give quite a few readers a decent 101 in the fundamentals of enterprise programming and concepts.
    'It had its time but nobody uses it any more because it was too complicated.'
    Regarding this article; Someone once said "What you feel is what you are, what is within;" What you feel right now is fear. Fear that age is catching up with you and Java EE is getting far too complex for you. Even so, I'm sure you'll be able to get a few books on SOA sold in the near future, of course, till you see the end of that too. Keep the faith.
  85. I can't say, that Java EE will completely die - this sounds for me a little bit too dramatically ... But, in the past has Java EE already lost some of their leader positions to advanced and distinct technologies, how e.g. Lightweight Container (Spring & Co), Persistence ( Hibernate,...), which has shown potent and flexible solutions - which can be exist very good independently and outside of an EJB-Container. The integration of Service-oriented Architectures ( SOA ) needs a distinct stragegy and has their centrum in transparent solutions how the Enterprise Service Bus ( ESB ) and Java Business Integration ( JBI ). I think, that in such Strategy has - together with many other service-adaptable tools, languages and solutions - many of the magnificent Java EE Technologies their right to exist as an advanced and standardized service provider, too, Roland --- SOA Kompetenznetzwerk Information & Collaboration-Portal for SOA & ESA in German Language http://soa-competence-network.de http://esa-competence-network.de
  86. The simpler parts of JEE - servlets, JSP, Java Beans have been very sucessful. I think EJB will gradually fad away and JSF will not gain traction. EJB has been poor. I guess it suffered from trying to standardize all the App Servers , COBRA etc. I expect it will fad away to be replaced by some sort of Message-based environment based on JavaBeans, SOA or something. JEE has always been weak on the user interface side of things. JSF is a complex implementation to me. It would probably be best if JEE gave up on the user interface and left it to Eclipse to provide some environment that just generated some code that ran in the servlet/jsp/Java Bean world. Maybe JEE should just make enhancements to servlets/JSP/Java Beans to support them. .NET is better in this area because it is all done in Visual Studio. I think 90pc of JEE developers are just using servelts/JSP and java beans. EJB is just used by large scale systems that need distributed objects....
  87. The simpler parts of JEE - servlets, JSP, Java Beans have been very sucessful. I think EJB will gradually fad away and JSF will not gain traction.
    Well, regarding JSF, my strong impression is you are out of date here. It certainly has gained traction. Yet again in this context, I shall mention popular frameworks like Facelets and Seam which are based on JSF. Although the de-facto standard for Java web development (Struts) is still (and will probably remain) very widely used for some time, JSF has started to show significant take-up in the past year.
    JSF is a complex implementation to me.
    It is far simpler to develop with than Struts, in my experience.
  88. JSF is a complex implementation to me.


    It is far simpler to develop with than Struts, in my experience.
    What kind of applications are you developing? Are you a real world developer or just doing development to amuse yourself?
  89. JSF is a complex implementation to me.


    It is far simpler to develop with than Struts, in my experience.


    What kind of applications are you developing? Are you a real world developer or just doing development to amuse yourself?
    OK, I'll take the bait. I am a real world developer. I work in a wide variety of areas, from scientific and numerical software development to commercial websites. I use JSF as an individual developer to write small web applications for internal use within organisations, and I am part of a team currently using JSF for a major re-engineering of a corporate website (previously based on Struts). I use MyFaces+Facelets - a great combination.
  90. OK, I'll take the bait. I am a real world developer. I work in a wide variety of areas, from scientific and numerical software development to commercial websites.
    No bait there, Steve. I am not the first person raising this question on serverside.com.
    I use JSF as an individual developer to write small web applications for internal use within organisations, and I am part of a team currently using JSF for a major re-engineering of a corporate website (previously based on Struts). I use MyFaces+Facelets - a great combination.
    (OK, here comes a bait.) So is your company using its fund to amuse you? or is it in the business of IT consulting?
  91. The blight of the Architect[ Go to top ]

    Hi,
    (OK, here comes a bait.) So is your company using its fund to amuse you? or is it in the business of IT consulting?
    I'm not baiting anyone, and I do not want to make this personal, but I think you raise a good point. "Strategic" decisions made by lofty strategist and Architects are often responsible for the over complexity we see. At 10,000 feet I can imagine how something like Weblogic or WebSphere sounds like a great proposition, all that "industrial strength" goodness for free. If you've got to programme the stuff day in and day out though the shine quickly wears off and you quickly realise that it can become a nightmare. The whole thing is not designed with testing in mind, so as a programmer there is often no quick and easy way to get feedback. Some people say that the only people that should make design and technology decisions are those that actually code and are on the hook to deliver production systems. I use to be an Architect once, and even though I use to verify my ideas by coding them myself it wasn't the same as living in a production environment day in and day out. It would be interesting if you could get those architects who still remember how to code to do production support or maintenance for a few months, they may not be so enamoured by their glossy "industrial strength” enterprise platforms then! IMO if you don't code day-to-day then when it comes to technology selection your opinion doesn't count. Paul.
  92. At 10,000 feet I can imagine how something like Weblogic or WebSphere sounds like a great proposition, all that "industrial strength" goodness for free. If you've got to programme the stuff day in and day out though the shine quickly wears off and you quickly realise that it can become a nightmare. The whole thing is not designed with testing in mind, so as a programmer there is often no quick and easy way to get feedback.
    Having spent a lot of time working on WebLogic, and in particular when it was a whole lot *less* stable and polished than it is today, I can honestly say that for many purposes, it will save a development team a boat-load of time. Where we lose the time is in projects that are (a) large and (b) require a full build and deploy cycle for testing what seem like simple changes. However, WebLogic has always had the ability to edit a JSP then refresh the browser window, and has always supported application hot deployment (i.e. "edit then ant then refresh the browser window"). For web apps, I also find Caucho Resin (another J2EE application server ;-) to be very helpful for rapid develop/test cycles. I have seen a lot of "more agile" projects building their own extensive infrastructure, when an application server would have provided it out-of-the-box. Some of our customers have even built their own application servers. That's not agile -- that's brain-dead! ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  93. At 10,000 feet I can imagine how something like Weblogic or WebSphere sounds like a great proposition, all that "industrial strength" goodness for free.

    If you've got to programme the stuff day in and day out though the shine quickly wears off and you quickly realise that it can become a nightmare. The whole thing is not designed with testing in mind, so as a programmer there is often no quick and easy way to get feedback.


    Having spent a lot of time working on WebLogic, and in particular when it was a whole lot *less* stable and polished than it is today, I can honestly say that for many purposes, it will save a development team a boat-load of time. Where we lose the time is in projects that are (a) large and (b) require a full build and deploy cycle for testing what seem like simple changes. However, WebLogic has always had the ability to edit a JSP then refresh the browser window, and has always supported application hot deployment (i.e. "edit then ant then refresh the browser window").

    For web apps, I also find Caucho Resin (another J2EE application server ;-) to be very helpful for rapid develop/test cycles.

    I have seen a lot of "more agile" projects building their own extensive infrastructure, when an application server would have provided it out-of-the-box. Some of our customers have even built their own application servers. That's not agile -- that's brain-dead! ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
    Hi Cameron, You missed the point (sadly). My point was to avoid using an App Server if you can. I was say that at least 80% of the times people buirnden themselves with such things that: A) It wasn't of their own choosing (the developers I mean). B) It wasn't needed. Keep It Simple! Paul.
  94. You missed the point (sadly). My point was to avoid using an App Server if you can. I was say that at least 80% of the times people buirnden themselves with such things that: A) It wasn't of their own choosing (the developers I mean). B) It wasn't needed. Keep It Simple!
    I do hear what you are saying, but I disagree: Using an app server _is_ keeping it simple. For me, it is analogous to not using Linux for a server because it has too many features. I would rather use Linux, but use a version that lets me disable the 90% of the features that I don't need. With a full-blown zillion-dollara enterprise-class yadda-yadda J2EE app server, I can still disable (or at least ignore) the cruft. (Definition of cruft: Those things that you don't need _today_ ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  95. You missed the point (sadly). My point was to avoid using an App Server if you can. I was say that at least 80% of the times people buirnden themselves with such things that:

    A) It wasn't of their own choosing (the developers I mean).
    B) It wasn't needed.

    Keep It Simple!


    I do hear what you are saying, but I disagree: Using an app server _is_ keeping it simple.
    Yes.. So Simple infact that everyone is moving to Tomcat, Spring and Hibernate... Another Sun JEE Blue print design (anti) pattern bites the dust :^) Paul.
  96. You missed the point (sadly). My point was to avoid using an App Server if you can. I was say that at least 80% of the times people buirnden themselves with such things that:

    A) It wasn't of their own choosing (the developers I mean).
    B) It wasn't needed.

    Keep It Simple!


    I do hear what you are saying, but I disagree: Using an app server _is_ keeping it simple.


    Yes.. So Simple infact that everyone is moving to Tomcat, Spring and Hibernate...

    Another Sun JEE Blue print design (anti) pattern bites the dust :^)
    Tomcat is an application server, and provides a good chunk of the overall J2EE stack. Using Spring and Hibernate on an application server is very popular, yes. Most of the Spring functionality was originally developed to make J2EE development simpler. .. and you don't have to get me started on Sun's blue-prints ;-) .. check this out: http://developers.sun.com/learning/javaoneonline/2006/coreenterprise/TS-5397.html Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  97. You missed the point (sadly). My point was to avoid using an App Server if you can. I was say that at least 80% of the times people buirnden themselves with such things that:

    A) It wasn't of their own choosing (the developers I mean).
    B) It wasn't needed.

    Keep It Simple!


    I do hear what you are saying, but I disagree: Using an app server _is_ keeping it simple.


    Yes.. So Simple infact that everyone is moving to Tomcat, Spring and Hibernate...

    Another Sun JEE Blue print design (anti) pattern bites the dust :^)


    Tomcat is an application server, and provides a good chunk of the overall J2EE stack. Using Spring and Hibernate on an application server is very popular, yes. Most of the Spring functionality was originally developed to make J2EE development simpler.

    .. and you don't have to get me started on Sun's blue-prints ;-) .. check this out:

    http://developers.sun.com/learning/javaoneonline/2006/coreenterprise/TS-5397.html

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
    OK. Let me be more specific. J2EE can be split into two broad categories: services and containers. The top level container IMO is the Application Server itself and Tomcat doesn't qualify (Tomcat is not J2EE 1.x compliant). There are a whole host of container based services and application server needs to support to be fully JEE compliant. Tomcat is a Servlet Container, and I agree the Servlet API is on of the successful aspects of JEE. A lot less successful IMO has been the EJB containers. Along side the containers are the JEE services like JDBC, JTA etc some of which can be utilised both in and outside the container, and some of which can't (e.g JNDI). Right with that sorted, my beef is with J2EE complaint Application Servers. As I've said before J2EE is a mixed bag containing good and bad. Paul.
  98. Hi Cameron, Reading back through several posts there seems to be a general confusion over exactly what J2EE actually is. Well here is a quote from the Sun website: The Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing multitier enterprise applications. The J2EE platform simplifies enterprise applications by basing them on standardized, modular components, by providing a complete set of services to those components, and by handling many details of application behavior automatically, without complex programming. This is what Richard Monson-Haefel is referring to when he says:
    "JEE5's failure to address complexity is a harbinger of the Java EE platforms' fall from dominance in the enterprise development platform arena."
    BTW: Richards book on EJB's is how I learnt how to programme EJBs many moons ago, so I would suggest that he knows a thing or two when it comes to J2EE. And this is what I've said: The top level container IMO is the Application Server itself and Tomcat doesn't qualify (Tomcat is not J2EE 1.x compliant). There are a whole host of container based services an application server needs to support to be fully JEE compliant. The goal behind the J2EE standard is quite clear it is to create a standard platform (Application Server) to host J2EE applications (Servlets, JSP's, EJB's and now all the beans needed by JSF). The fact that people have chosen to unbundle many of the underlying services is testimony to the fact that the standard platform has proven unwealdy over the years. Paul.
  99. You missed the point (sadly). My point was to avoid using an App Server if you can. I was say that at least 80% of the times people buirnden themselves with such things that:

    A) It wasn't of their own choosing (the developers I mean).
    B) It wasn't needed.

    Keep It Simple!


    I do hear what you are saying, but I disagree: Using an app server _is_ keeping it simple.


    Yes.. So Simple infact that everyone is moving to Tomcat, Spring and Hibernate...

    Another Sun JEE Blue print design (anti) pattern bites the dust :^)


    Tomcat is an application server, and provides a good chunk of the overall J2EE stack. Using Spring and Hibernate on an application server is very popular, yes. Most of the Spring functionality was originally developed to make J2EE development simpler.

    .. and you don't have to get me started on Sun's blue-prints ;-) .. check this out:

    http://developers.sun.com/learning/javaoneonline/2006/coreenterprise/TS-5397.html

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java


    OK. Let me be more specific. J2EE can be split into two broad categories: services and containers. The top level container IMO is the Application Server itself and Tomcat doesn't qualify (Tomcat is not J2EE 1.x compliant). There are a whole host of container based services and application server needs to support to be fully JEE compliant.

    Tomcat is a Servlet Container, and I agree the Servlet API is on of the successful aspects of JEE. A lot less successful IMO has been the EJB containers. Along side the containers are the JEE services like JDBC, JTA etc some of which can be utilised both in and outside the container, and some of which can't (e.g JNDI).

    Right with that sorted, my beef is with J2EE complaint Application Servers. As I've said before J2EE is a mixed bag containing good and bad.

    Paul.
    I agree on this. I want my application server to do two things : 1) Offer standard enterprise APIs (JTA, JMS, ...) 2) Allow me to expose my component to a given protocol (Servlet, JMX, remote EJB). I don't need my application server to force me to use any component model (except when it's for point 2). This should not be the application server responsability. Why? Because I hate deploying and the only good reason to deploy is when you want to expose your components to a particular protocol. This may be why servlets, jmx and the remote part of EJBs are successful technologies. My opinion is to just standardize a good IoC/AoP container in the JVM if people absoluty want a standard object container allowing to inject enterprise services. Anyway, I don't see the point of making an embeddable container standard since it is bundled with the application. It will still run no matter on what application server the application is deployed. So basically all the extra stuff found on a application server I don't care. It doesn't mean it's bad (I really like JSF but it shouldn't be distribuated as part of an application server). Plus, right now the innovation is really happening in the framework area so let's stop standardize them. It doesn't serve any purpose except to give starters an idea of where to start and build some tools support.
  100. Hi Alexandria,
    I agree on this. I want my application server to do two things : 1) Offer standard enterprise APIs (JTA, JMS, ...) 2) Allow me to expose my component to a given protocol (Servlet, JMX, remote EJB).
    I don't need my application server to force me to use any component model (except when it's for point 2). This should not be the application server responsability. Why? Because I hate deploying and the only good reason to deploy is when you want to expose your components to a particular protocol. This may be why servlets, jmx and the remote part of EJBs are successful technologies. My opinion is to just standardize a good IoC/AoP container in the JVM if people absoluty want a standard object container allowing to inject enterprise services. You have mentioned using AOP and IoC together before. I think you said Spring 2.0 is exploring this approach. Any pointers to material on this would be apreciated. The reason why I haven't hastened to follow this stuff up though is that the whole IoC bag has been done for years in Smaltalk without the need for an IoC container. In Smalltalk IoC is just a design pattern (See Kent Beck's Smalltalk Best Practice Patterns). IMO IoC is merely a way of decoupling objects and leaving composition to the latest possible moment (when your bean composer weaves the objects together on demand) as apposed to static linking. So given this, another alternative is weaving static (Java) objects together using a dynamic language, say JPython or JRuby. I know for sure that PicoContainer has been looking into such an approach. The approach you are advocating sounds very interesting (although I do find true AOP a bit frightening:^)). I would love to read a detailed explanation if you know of a link. Thanks in advance, Paul.
  101. Hi Alexandria,
    I agree on this. I want my application server to do two things : 1) Offer standard enterprise APIs (JTA, JMS, ...) 2) Allow me to expose my component to a given protocol (Servlet, JMX, remote EJB).
    I don't need my application server to force me to use any component model (except when it's for point 2). This should not be the application server responsability. Why? Because I hate deploying and the only good reason to deploy is when you want to expose your components to a particular protocol. This may be why servlets, jmx and the remote part of EJBs are successful technologies. My opinion is to just standardize a good IoC/AoP container in the JVM if people absoluty want a standard object container allowing to inject enterprise services.
    You have mentioned using AOP and IoC together before. I think you said Spring 2.0 is exploring this approach. Any pointers to material on this would be apreciated. The reason why I haven't hastened to follow this stuff up though is that the whole IoC bag has been done for years in Smaltalk without the need for an IoC container. In Smalltalk IoC is just a design pattern (See Kent Beck's Smalltalk Best Practice Patterns). IMO IoC is merely a way of decoupling objects and leaving composition to the latest possible moment (when your bean composer weaves the objects together on demand) as apposed to static linking. So given this, another alternative is weaving static (Java) objects together using a dynamic language, say JPython or JRuby. I know for sure that PicoContainer has been looking into such an approach. The approach you are advocating sounds very interesting (although I do find true AOP a bit frightening:^)). I would love to read a detailed explanation if you know of a link. Thanks in advance, Paul.
  102. Hi Alexandria,

    I agree on this. I want my application server to do two things :
    1) Offer standard enterprise APIs (JTA, JMS, ...)
    2) Allow me to expose my component to a given protocol (Servlet, JMX, remote EJB).


    I don't need my application server to force me to use any component model (except when it's for point 2). This should not be the application server responsability. Why? Because I hate deploying and the only good reason to deploy is when you want to expose your components to a particular protocol. This may be why servlets, jmx and the remote part of EJBs are successful technologies. My opinion is to just standardize a good IoC/AoP container in the JVM if people absoluty want a standard object container allowing to inject enterprise services.


    You have mentioned using AOP and IoC together before. I think you said Spring 2.0 is exploring this approach. Any pointers to material on this would be apreciated.

    The reason why I haven't hastened to follow this stuff up though is that the whole IoC bag has been done for years in Smaltalk without the need for an IoC container. In Smalltalk IoC is just a design pattern (See Kent Beck's Smalltalk Best Practice Patterns).

    IMO IoC is merely a way of decoupling objects and leaving composition to the latest possible moment (when your bean composer weaves the objects together on demand) as apposed to static linking.

    So given this, another alternative is weaving static (Java) objects together using a dynamic language, say JPython or JRuby. I know for sure that PicoContainer has been looking into such an approach.

    The approach you are advocating sounds very interesting (although I do find true AOP a bit frightening:^)). I would love to read a detailed explanation if you know of a link.

    Thanks in advance,

    Paul.
    I mainly refer to what I have seen of Spring 2.0 and from my experience using it. I have used SmallTalk in the past (but not Ruby, haven't got the time yet) and I really liked writting program in that language. But as soon as I had to read someone else program, oh my god, it was hard. Maybe it was because there weren't any tests written but my opinion is while it is more powerful and easier to write programs using a dynamic language, it is much harder to get in someone's else code. IMO a dynamic language is great to create and wire objects in a very loose way and to decorate them (injecting infrastructure code). But on the other hand, I still think that a static language is better to express a domain model (easier to understand and refactoring support) except maybe for volatile business rules. A IoC/AOP container gives me this hybrid model. Note that I haven't had a lot of experience in using dynamic languages so I try to stay open on the subject. But after having used Spring for the last year, I really think the hype is justified. Spring allows your application to scale up and down which is almost impossible to do in the traditional J2EE world. You have to deal with all the complexities even when you don't need them. Spring fits really well with agile approaches. I think the best documentation on the subject is Rod Johnson's book. Really worths the read.
  103. Hi Alexandre,
    But as soon as I had to read someone else program, oh my god, it was hard. Maybe it was because there weren't any tests written but my opinion is while it is more powerful and easier to write programs using a dynamic language, it is much harder to get in someone's else code.
    Using a dynamic language does require a different programming style. For people more familiar with a C/C++ approach it can take some getting use to. The other thing about Smalltalk is the syntax is a bit different you either love it or hate it. Give Ruby ago it is a lot more C/C++/Java friendly whilst retaining much of the power of Smalltalk. I guess this is a personal thing, but try persevering a little longer. I found that Smalltalk improved my C++ tremendously and I'm sure that many Java programmers today are finding that Ruby is improving their Java. After all, as a programmer it is always good to have more than one string to your bow. Back to the Java world:
    I really think the hype is justified. Spring allows your application to scale up and down which is almost impossible to do in the traditional J2EE world. You have to deal with all the complexities even when you don't need them. Spring fits really well with agile approaches.
    I've used spring and I agree. The problem with the hype though is that it is very easy to over use Spring. I used Spring to create an hierarchical bean factory just to tie together the three tiers of a web application. We were using an in-house web framework and I used Spring to tie together our web-tier controllers with a service facade and a hibernate persistence manager. This was cool, but there was some junior members on the team that wanted to use Spring for everything. I could see how less experienced people could easily get into a mess. In the right hands it great.
    I think the best documentation on the subject is Rod Johnson's book. Really worths the read.
    Yes I've read a couple of his books ("J2EE design" and "J2EE without EJB" where he talks about Spring). He is a good writer and makes some good points on the subject of complexity and J2EE. Has he got a new book out just on Spring? In a previous post on a different thread you spoke about using aspectJ to gain some of the features of a dynamic language in Java. This was very different to the normal dynamic proxy AOP style Rod has spoken about in the books I've read. It sounded real interesting. Please supply the title of the book you mean. Regards, Paul.
  104. Hi Alexandre,

    But as soon as I had to read someone else program, oh my god, it was hard. Maybe it was because there weren't any tests written but my opinion is while it is more powerful and easier to write programs using a dynamic language, it is much harder to get in someone's else code.


    Using a dynamic language does require a different programming style. For people more familiar with a C/C++ approach it can take some getting use to. The other thing about Smalltalk is the syntax is a bit different you either love it or hate it. Give Ruby ago it is a lot more C/C++/Java friendly whilst retaining much of the power of Smalltalk. I guess this is a personal thing, but try persevering a little longer. I found that Smalltalk improved my C++ tremendously and I'm sure that many Java programmers today are finding that Ruby is improving their Java. After all, as a programmer it is always good to have more than one string to your bow.

    Back to the Java world:

    I really think the hype is justified. Spring allows your application to scale up and down which is almost impossible to do in the traditional J2EE world. You have to deal with all the complexities even when you don't need them. Spring fits really well with agile approaches.


    I've used spring and I agree. The problem with the hype though is that it is very easy to over use Spring. I used Spring to create an hierarchical bean factory just to tie together the three tiers of a web application. We were using an in-house web framework and I used Spring to tie together our web-tier controllers with a service facade and a hibernate persistence manager. This was cool, but there was some junior members on the team that wanted to use Spring for everything. I could see how less experienced people could easily get into a mess. In the right hands it great.

    I think the best documentation on the subject is Rod Johnson's book. Really worths the read.


    Yes I've read a couple of his books ("J2EE design" and "J2EE without EJB" where he talks about Spring). He is a good writer and makes some good points on the subject of complexity and J2EE. Has he got a new book out just on Spring? In a previous post on a different thread you spoke about using aspectJ to gain some of the features of a dynamic language in Java. This was very different to the normal dynamic proxy AOP style Rod has spoken about in the books I've read. It sounded real interesting. Please supply the title of the book you mean.

    Regards,

    Paul.
    AspectJ integration are the new main features of Spring 2.0 which is in RC-2 at the moment. No book out yet. Spring updated documentation and example are the best reference on the topic : http://static.springframework.org/spring/docs/2.0.x/reference/new-in-2.html
  105. You missed the point (sadly). My point was to avoid using an App Server if you can. I was say that at least 80% of the times people buirnden themselves with such things that:

    A) It wasn't of their own choosing (the developers I mean).
    B) It wasn't needed.

    Keep It Simple!


    I do hear what you are saying, but I disagree: Using an app server _is_ keeping it simple.
    Yes.. So Simple infact that everyone has moved to Tomcat, Spring and Hibernate... The Sun JEE Blue print design (anti) patterns have bitten the dust. They got it wrong, get over it :^). BTW EJB3 is not the answer, it's just more of the same. Paul.
  106. Re: The blight of the Architect[ Go to top ]

    Yes.. So Simple infact that everyone has moved to Tomcat, Spring and Hibernate..
    I realise that job adverts aren't always a good guide to what is being internally within companies (I posted some Ruby on Rails job figures earlier, and I am sure they significantly underestimate use, even though my general point holds), but it does not take more than a few minutes of research to see that large app server skills are very much in demand. As this is the case, I do find it puzzling why people post statements like this.
  107. Re: The blight of the Architect[ Go to top ]

    Yes.. So Simple infact that everyone has moved to Tomcat, Spring and Hibernate..


    I realise that job adverts aren't always a good guide to what is being internally within companies (I posted some Ruby on Rails job figures earlier, and I am sure they significantly underestimate use, even though my general point holds), but it does not take more than a few minutes of research to see that large app server skills are very much in demand.
    OK let me adjust the tense of my verb:
    Yes.. So Simple infact that everyone is moving to Tomcat, Spring and Hibernate..
    And what you say about the skills market just makes my original point: The people that decide such things no nothing about programming. As this is the case, I do find it puzzling why people post statements like this. And I can't understand why people insist on trying to defend the indefensable, but I guess that's just human nature. Paul.
  108. Re: The blight of the Architect[ Go to top ]

    Yes.. So Simple infact that everyone has moved to Tomcat, Spring and Hibernate..


    I realise that job adverts aren't always a good guide to what is being internally within companies (I posted some Ruby on Rails job figures earlier, and I am sure they significantly underestimate use, even though my general point holds), but it does not take more than a few minutes of research to see that large app server skills are very much in demand.
    OK let me adjust the tense of my verb:
    Yes.. So Simple infact that everyone is moving to Tomcat, Spring and Hibernate..
    And what you say about the skills market just makes my original point: The people that decide such things no nothing about programming.
    As this is the case, I do find it puzzling why people post statements like this.
    And I can't understand why people insist on trying to defend the indefensable, but I guess that's just human nature. Paul.
  109. Re: The blight of the Architect[ Go to top ]

    Yes.. So Simple infact that everyone has moved to Tomcat, Spring and Hibernate..


    I realise that job adverts aren't always a good guide to what is being internally within companies (I posted some Ruby on Rails job figures earlier, and I am sure they significantly underestimate use, even though my general point holds), but it does not take more than a few minutes of research to see that large app server skills are very much in demand.


    OK let me adjust the tense of my verb:

    Yes.. So Simple infact that everyone is moving to Tomcat, Spring and Hibernate..


    And what you say about the skills market just makes my original point: The people that decide such things no nothing about programming.

    As this is the case, I do find it puzzling why people post statements like this.


    And I can't understand why people insist on trying to defend the indefensable, but I guess that's just human nature.

    Paul.
    I am not attempting to defend anything. I expressed no value judgement (although, to be honest, if my bank attempted to host its entire customer website purely on tomcat (or Ruby on Rails), I might be a little cautious about remaining a customer). What interests me is facts. Wild claims are of no use in making decisions about technologies and platforms (which is why I find statements such as 'JEE is dying in an SOA world' rather irritating). I see these sorts of statements often in IT forums. Usually it is something like 'soon, Firefox will take over from Explorer', or 'Linux desktops will be the standard in a few years - Windows is dying'! Usually this sort of thing is wishful thinking, or a poor attempt at propoganda, so it is surprising to see this sort of thing coming from a respected (I assume) analyst. Facts about technologies are important, no matter what you feel about them. Which is why statements like 'everyone is moving to Tomcat, Spring and Hibernate' (no matter what the tense) is of no help at all, as it plainly isn't factual, and to broadly claim that 'The people that decide such things know nothing about programming' is equally incorrect, (as are most such generalisations).
  110. Re: The blight of the Architect[ Go to top ]

    I am not attempting to defend anything.
    You could have fooled me :^)
    What interests me is facts.
    Well in a world full of opinions (including your own) you are going to have a hard time :^)
    Wild claims are of no use in making decisions about technologies and platforms (which is why I find statements such as 'JEE is dying in an SOA world' rather irritating).
    Check my posts, I make no such claims.
    Facts about technologies are important, no matter what you feel about them. Which is why statements like 'everyone is moving to Tomcat, Spring and Hibernate' (no matter what the tense) is of no help at all, as it plainly isn't factual, and to broadly claim that 'The people that decide such things know nothing about programming' is equally incorrect, (as are most such generalisations).
    My opinions based on my experience are valid and I stand by them. Paul
  111. Re: The blight of the Architect[ Go to top ]

    Well in a world full of opinions (including your own) you are going to have a hard time :^)
    No, because it is often not that hard to get at the facts behind opinions if you know how to look. I am also very cautious about opinions (my scientific background, I guess).
    Wild claims are of no use in making decisions about technologies and platforms (which is why I find statements such as 'JEE is dying in an SOA world' rather irritating).


    Check my posts, I make no such claims.
    If you re-read my post, you will see I was referring to the article mentioned at the top of this thread, not your posts.
    Facts about technologies are important, no matter what you feel about them. Which is why statements like 'everyone is moving to Tomcat, Spring and Hibernate' (no matter what the tense) is of no help at all, as it plainly isn't factual, and to broadly claim that 'The people that decide such things know nothing about programming' is equally incorrect, (as are most such generalisations).


    My opinions based on my experience are valid and I stand by them.

    Paul
    I have no knowledge of the depth or time of your experience, but I suspect there are few developers with sufficiently broad personal experience of the entire IT world to qualify them put forward generalised factual statements like 'everyone is moving to Tomcat' (for example). That is why many people look to analysts who we assume put major resources into research on these matters - which is why the report mentioned in this thread is such a surprise. I think the only answer is for developers to research things for themselves as best they can, which is, unfortunately, time-consuming.
  112. Re: The blight of the Architect[ Go to top ]

    I have no knowledge of the depth or time of your experience, but I suspect there are few developers with sufficiently broad personal experience of the entire IT world to qualify them put forward generalised factual statements like 'everyone is moving to Tomcat' (for example). That is why many people look to analysts who we assume put major resources into research on these matters - which is why the report mentioned in this thread is such a surprise. I think the only answer is for developers to research things for themselves as best they can, which is, unfortunately, time-consuming.
    Steve, Let me put it more plainly. Goverments are elected on opinions, great moments in the history of man are based on people acting on opinion, Doctors make life and death decisions based on their medical opinion. There are two types of factual data: Qualitative and Quantitive. My opinion is a Qualitative fact, along with others who share my opinion I am sure that if your conducted a survey then we represent a sizeable community (statically significant :^)). You've got your opinion, I've got mine. I'm all for sharing - humans have been doing so for millennia :^). BTW: For a more rational and reasoned argument behind my opinions see my earler posts. The sentences you've chosen to quote are just the executive summary :^) Paul.
  113. Re: The blight of the Architect[ Go to top ]

    There are two types of factual data: Qualitative and Quantitive. My opinion is a Qualitative fact, along with others who share my opinion I am sure that if your conducted a survey then we represent a sizeable community (statically significant :^)).
    No, sorry, I have no idea what you are talking about here (and I have degree-level training about data analysis and statistics) :) All I am trying to say is that anyone who makes unqualified (and obviously unjustified) broad statement like "everyone is moving to Tomcat, Spring and Hibernate" Without providing strong evidence (not just opinion) should expect to be critised for it, and subject to strong debate. This must be getting tedious for people, and I am revealing a tendency towards being pedantic, so I shall stop now!


  114. I do hear what you are saying, but I disagree: Using an app server _is_ keeping it simple.

    For me, it is analogous to not using Linux for a server because it has too many features. I would rather use Linux, but use a version that lets me disable the 90% of the features that I don't need.

    With a full-blown zillion-dollara enterprise-class yadda-yadda J2EE app server, I can still disable (or at least ignore) the cruft.

    (Definition of cruft: Those things that you don't need _today_ ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
    Sure, I'd use WebLogic if I could afford it, but then I couldn't afford Coherence. :-) Everyone's gotta make resource-constrained decisions, and fortunately there's opensource to fall back on in some categories.
  115. ?[ Go to top ]

    IMO if you don't code day-to-day then when it comes to technology selection your opinion doesn't count.

    Paul.
    Rather sweeping, wouldn't you say? I know quite a few people who do nothing BUT coding day to day, and their opinion is that whatever they're coding in (and have been, for the past 6-15 years or more) is all they ever want to use. Given a choice, they'd never change, for any reason. This might not be how it is in your shop, but the IT organizations that hope to survive need visionaries, strategists, and tacticians all.
  116. Re: ?[ Go to top ]

    IMO if you don't code day-to-day then when it comes to technology selection your opinion doesn't count.

    Paul.


    Rather sweeping, wouldn't you say?
    I thought it was a sweeping statement the first time some one said this to me. But over time I've become convinced that they were right. Whether or not your developers are on the look out for ways to continually improve their performance is a different point, but having people from outside the development team who ultimately are not on the hook to deliver code making such decisions IMO is a bad idea. Paul.
  117. IMO if you don't code day-to-day then when it comes to technology selection your opinion doesn't count.

    Paul.


    Rather sweeping, wouldn't you say?

    I thought it was a sweeping statement the first time some one said this to me. But over time I've become convinced that they were right. Whether or not your developers are on the look out for ways to continually improve their performance is a different point, but having people from outside the development team who ultimately are not on the hook to deliver code making such decisions IMO is a bad idea.

    Paul.
    That may be, but it appears that you're making a presumption that those that aren't coding day-in/day-out aren't also on the hook for making a *product* delivery (of which code generation is only a small part).
  118. IMO if you don't code day-to-day then when it comes to technology selection your opinion doesn't count.

    Paul.


    Rather sweeping, wouldn't you say?

    I thought it was a sweeping statement the first time some one said this to me. But over time I've become convinced that they were right. Whether or not your developers are on the look out for ways to continually improve their performance is a different point, but having people from outside the development team who ultimately are not on the hook to deliver code making such decisions IMO is a bad idea.

    Paul.


    That may be, but it appears that you're making a presumption that those that aren't coding day-in/day-out aren't also on the hook for making a *product* delivery (of which code generation is only a small part).
    It's not a presumption, it is merely an acknowlegement of the situation as I see it. At the end of the day the only thing that we as developers are judged upon is working software (code). Everything else is merely a intermediate work product with no inherent value of it's own (try selling technical documents to your customers with no working software). So you can architect all you like, if the resultant software (working code) is over complex and poor then who is to blame? The architect or the developers? Who gets to stay late bug fixing, on the hook to get the thing working? BTW: I much prefer the term Programmer or Developer to Coder. The term Coder has a conitation that implies that programming is a mere mechanical brain dead task that can be readily performed by lesser mortals once all the clever Analysis and Architecting is done. Paul.
  119. Uninformative[ Go to top ]

    I find it amazing that such an article which is clearly anti-JEE could even be considered as an informed view of the current SOA reality. Nowehere is there mention of the only other currently viable SOA alternative: MS .NET. And, according to one analyst in this article: "Unfortunately, none of these facets of Java, or any other virtual machine-based, object-oriented runtime environment for that matter, are ideally suited as a platform for SOA." MS .NET would be just as doomed as JEE in the SOA world. Honestly, articles like this should be left unpublished if they aren't willing to go the extra mile and discuss the subject in an unbiased mannor. The only alternative solution briefly mentioned in the beginning is Ruby on Rails... Is it truly the only other language available to us in SOALand?
  120. IMO if you don't code day-to-day then when it comes to technology selection your opinion doesn't count.

    Paul.


    Rather sweeping, wouldn't you say?

    I thought it was a sweeping statement the first time some one said this to me. But over time I've become convinced that they were right. Whether or not your developers are on the look out for ways to continually improve their performance is a different point, but having people from outside the development team who ultimately are not on the hook to deliver code making such decisions IMO is a bad idea.

    Paul.


    That may be, but it appears that you're making a presumption that those that aren't coding day-in/day-out aren't also on the hook for making a *product* delivery (of which code generation is only a small part).
    I like this term "Code generation". Usually come from people producing a big design up front. Coding and designing are practices that you can't separate, so it's more about developing. I agree with Paul on this one. Code in the end is the product. Try to sell documentation without a working product. If "code generation" is only a small part of your effort, then you are in for trouble.
  121. Code in the end is the product. Try to sell documentation without a working product. If "code generation" is only a small part of your effort, then you are in for trouble.
    Just to be clear, "code" and "working product" are two very different things ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  122. OK, I'll take the bait. I am a real world developer. I work in a wide variety of areas, from scientific and numerical software development to commercial websites.


    No bait there, Steve. I am not the first person raising this question on serverside.com.
    As far as I remember, you are. I may be mistaken. No matter how foolish and ignorant my posts may have seemed, I don't remember anyone questioning whether or not whether I was a serious developer. As with so many things, I may be wrong.

    I use JSF as an individual developer to write small web applications for internal use within organisations, and I am part of a team currently using JSF for a major re-engineering of a corporate website (previously based on Struts). I use MyFaces+Facelets - a great combination.


    (OK, here comes a bait.) So is your company using its fund to amuse you? or is it in the business of IT consulting? Is that a serious question? If so, why?
  123. I don't remember anyone questioning whether or not whether I was a serious developer.
    In a recent thread (less than a month) someone questioned if you were an average developer, remember? If I have time next week, I will try to find that post for you. The impression, I guess, comes from the large number of posts you have made, rather than from the quality of the posts.
  124. I don't remember anyone questioning whether or not whether I was a serious developer.


    In a recent thread (less than a month) someone questioned if you were an average developer, remember? If I have time next week, I will try to find that post for you.

    The impression, I guess, comes from the large number of posts you have made, rather than from the quality of the posts.
    Posting flamebait all the time is certainly better...
  125. I don't remember anyone questioning whether or not whether I was a serious developer.


    In a recent thread (less than a month) someone questioned if you were an average developer, remember? If I have time next week, I will try to find that post for you.

    The impression, I guess, comes from the large number of posts you have made, rather than from the quality of the posts.
    Questioning whether or not I am an average developer is not the same as questioning whether or not I am a serious developer. I am not sure what an average developer is. Part of my role (both out of personal interest, and in my job) is to research technologies, in order to help advise which products and approaches should be used in future projects. As someone with a research background (a Ph.D.) I find vigorous debate a valuable way to test my ideas - there have been several occasions where I have found being proved wrong valuable... (one such occasions was a thread on Ruby last years on TSS). This is one of the reasons I post on subjects that interest me, and which are related to products , tools or strategies I used.
  126. struts, JSF[ Go to top ]

    I'm not Steve, but I've done some "real world" financial and retail applications using Struts, WebWork, and most recently JSF. While the JSF paradigm is a little different, I haven't found it to be any /harder/ than struts, nor significantly more complex. Mind you, I use more IDE tools with JSF which makes it easier, but JSF is well suited FOR tools.
  127. Re: struts, JSF[ Go to top ]

    I'm not Steve, but I've done some "real world" financial and retail applications using Struts, WebWork, and most recently JSF. While the JSF paradigm is a little different, I haven't found it to be any /harder/ than struts, nor significantly more complex.

    Mind you, I use more IDE tools with JSF which makes it easier, but JSF is well suited FOR tools.
    I guess am more used to the JSF component and event-based way of working because I have been developing GUIs mostly using that way of working since the mid 80s, starting with Digitalk Smalltalk. It feels natural to me.
  128. Re: struts, JSF[ Go to top ]

    What was it like using Struts/WebWork with WebSphere Portalets?
  129. Re: struts, JSF[ Go to top ]

    I'm not Steve, but I've done some "real world" financial and retail applications using Struts, WebWork, and most recently JSF. While the JSF paradigm is a little different, I haven't found it to be any /harder/ than struts, nor significantly more complex.

    Mind you, I use more IDE tools with JSF which makes it easier, but JSF is well suited FOR tools.
    What was it like using Struts/WebWork with WebSphere Portalets? :-)
  130. Struts and WebSphere[ Go to top ]

    What was it like using Struts/WebWork with WebSphere Portalets [sic]? :-)
    I honestly can't say; I've done WebSphere Portlets too, but it was a few WebSphere versions ago (4.x, pre JSR 168), and at the time I hadn't mixed them with Struts. Not even sure WebWork (2.x, anyway) was around then.
  131. SOA is not that good[ Go to top ]

    I have been using an SOA solution for the past three and half years. I can't wait for the day to convert all the stuff back to JEE. Some of the difficult things in JEE may turn out be simple. But most of the simple things in JEE turn out to be very difficult. SOA is a long way to go before it offers anything resembling JEE. Do not drink this kool-aid.
  132. Ok, so many have discussed how JEE is a heavyweight model, mostly based on their experience with EJB. I'm not going to re-discuss all that's been told both about JEE containers and EJB. The overlooked topic here is how easy it can be to develop a SOA application with a simpler approach to JEE. What if all you had to do in order to build was write a simple, POJO based application? You can write something like that in a matter of hours! The key technology here is Apache Axis. Yes my dear friends, Axis is a mature, widely technology used to make things go SOA in an instant fashion. Just rename your Business classes from .java to .jws, drop it into your Axis directory, and it will auto-gen your WSDL, publish it in Tomcat, and support it. It also has tools for generating proxy classes from WSDL files, so that you can easily access WebServices. So... It's JEE Right? I'm talking about an application running inside a servlet container. It doesn't matter if you use Hibernate, EJB, DAOs or Prevayler, all you gotta do is write your business logic in simple POJOs. So... Don't bury me yet.
  133. JEE! I'm Dying![ Go to top ]

    Can't really blame an article for having an eye-catching title, can you? JEE is a pretty big-ass spec to "seriously" think it is dying. I doubt if servlets, JMS, JMX, mail, etc are going away any time soon. I think they are kind of focusing on the big app containers and EJBs in particular. Is there a technology platform that is better suited for enabling SOA? I'm pretty sure enterprise Java will outlive all of our careers in one form or another. ______________ George Coller DevilElephant
  134. Richard is smoking crack[ Go to top ]

    Like reformed smokers (the health lobby’s Jehovah’s witnesses) there is nothing more vocal than a re-formed technology advocate. Poor old JEE has two very vocal ones in Richard and Bruce Tate at the moment. “JEE will die in 5 years because it is too complex” First of all five years is a long time. And it’s a fair prediction since the general rule of thumb with any technology is that it starts to decline after 10 years. For JEE that milestone will be reached next year so it would be reasonable to expect that the platform’s use would start to decline thereafter. Accept that I don’t see any reason to think that this will happen. Here’s why: 1) A sizeable chunk of his argument revolves around complexity (JEE is too complex) and SOA (SOA is simpler than JEE and will cure all the world’s ills) The complexity argument is often thrown at JEE (often by advocates for alternative frameworks) but JEE isn’t at all complex for implementing simple solutions (the JSP,Servlet, JSTL, JDBC stack is pretty easy to learn and much the same as the LAMP stack for example). Anyone who thinks SOA is simple hasn’t read the damn WS* specs. And SOA is no more a panacea than was XML. 2) The programming model change really isn’t that dramatic for developers of JEE. As Richard points out this is the 3rd such change and JEE’s momentum really didn’t slow down after the second one because Sun did a lot of work to smooth the transition path. Much the same is true now though accept that the community around JEE is much more involved this time around. 3) There are alternatives to JEE for solving some problems. Competition is particularly fierce in the web space because web apps seem quite simple as noted elsewhere on the thread. But PHP, ASP etc. have been valid alternatives for building web apps for some time yet JEE still continues to do well. Ruby on Rails is getting a lot of attention at the moment and rightly so, but I don’t see if becoming mainstream simply for a number of reasons. There isn’t a decent IDE for it for a start, and whilst I personally like the Ruby language a lot I think it (the language) is too idiomatic for wide enterprise adoption. Its also unproven in the Enterprise and the lack of wide-spread vendor support will hurt its credibility in the market place. There are other less direct reasons too: 3) The open source community is very supportive of JEE embracing it and adding capabilities of their own (almost all Java web frameworks build on top of the servlet/JSP API for example) – think of Spring, Struts, Cocoon, ECHO). 4) JEE is used in an awful lot of companies as their development platform of choice to run their entire business. In the retail and banking sectors other components of the API (EJB’s, JMS, WebServices, Connectors, Applets.). Even if all new JEE development were to stop today many of these systems will see be running, supported and evolving, in 10 years plus time (much like the last enterprise standard COBOL). 5) JEE is well supported by propriety vendors of various types – BEA, Oracle, IBM, Google all have Java products or toolkits, companies like Retail-J, Reflexsys etc. have bet their business on JEE. 6) The new JSF component web API is a very good fit with so called “Web 2.0” (AJAX) and the increasing use of mobile devices requiring different mark-ups and a lot of component libraries are emerging for it already. This doesn’t grantee JEE will be the development platform of choice for WEB 2.0 (.NET is getting similar capabilities via “Atlas” for a start), but it does put it in a strong position. And Google’s support through GWT helps also. 7) Platform independence of Java is still an important card. Companies who run Solaris, or AIX, or Linux, or make heavy use of Mobile devices, are all likely to stick with Java for obvious reasons. And that is a lot of companies. 8) There is a huge slice of enterprise problems that JEE solves that nothing else really does. Projects I have worked on since jumping from the Microsoft world to the JEE world include bioinformatics systems that scan enzyme and molecular models looking for drug targets, retail systems where huge amounts of data has to be passed to and from thousands of clients and devices distributed across a store network, banking systems where the banking engines run on mainframes with bespoke software (written in COBOL) that hasn’t been touched since some time in the early 80’s but now we need an internet bank on top of them. And that’s just my projects. Now all of these could doubtless be built with C++, .NET, RUBY or whatever. But you’d spend so long writing the pluming code that you get for free from JEE I don’t know why you’d bother… Now maybe in five years time the next solution for Enterprise software will arrive but if it does it will be quite a while after it before everyone decides to move to it. And I don’t see any sign of it so far…
  135. He is smoking crack.[ Go to top ]

    Like reformed smokers (the health lobby’s Jehovah’s witnesses) there is nothing more vocal than a re-formed technology advocate. Poor old JEE has two very vocal ones in Richard and Bruce Tate at the moment. “JEE will die in 5 years because it is too complex” First of all five years is a long time. And it’s a fair prediction since the general rule of thumb with any technology is that it starts to decline after 10 years. For JEE that milestone will be reached next year so it would be reasonable to expect that the platform’s use would start to decline thereafter. Accept that I don’t see any reason to think that this will happen. Here’s why: 1) A sizeable chunk of his argument revolves around complexity (JEE is too complex) and SOA (SOA is simpler than JEE and will cure all the world’s ills) The complexity argument is often thrown at JEE (often by advocates for alternative frameworks) but JEE isn’t at all complex for implementing simple solutions (the JSP,Servlet, JSTL, JDBC stack is pretty easy to learn and much the same as the LAMP stack for example). Anyone who thinks SOA is simple hasn’t read the damn WS* specs. And SOA is no more a panacea than was XML. 2) The programming model change really isn’t that dramatic for developers of JEE. As Richard points out this is the 3rd such change and JEE’s momentum really didn’t slow down after the second one because Sun did a lot of work to smooth the transition path. Much the same is true now though accept that the community around JEE is much more involved this time around. 3) There are alternatives to JEE for solving some problems. Competition is particularly fierce in the web space because web apps seem quite simple as noted elsewhere on the thread. But PHP, ASP etc. have been valid alternatives for building web apps for some time yet JEE still continues to do well. Ruby on Rails is getting a lot of attention at the moment and rightly so, but I don’t see if becoming mainstream simply for a number of reasons. There isn’t a decent IDE for it for a start, and whilst I personally like the Ruby language a lot I think it (the language) is too idiomatic for wide enterprise adoption. Its also unproven in the Enterprise and the lack of wide-spread vendor support will hurt its credibility in the market place. There are other less direct reasons too: 3) The open source community is very supportive of JEE embracing it and adding capabilities of their own (almost all Java web frameworks build on top of the servlet/JSP API for example) – think of Spring, Struts, Cocoon, ECHO). 4) JEE is used in an awful lot of companies as their development platform of choice to run their entire business. In the retail and banking sectors other components of the API (EJB’s, JMS, WebServices, Connectors, Applets.). Even if all new JEE development were to stop today many of these systems will see be running, supported and evolving, in 10 years plus time (much like the last enterprise standard COBOL). 5) JEE is well supported by propriety vendors of various types – BEA, Oracle, IBM, Google all have Java products or toolkits, companies like Retail-J, Reflexsys etc. have bet their business on JEE. 6) The new JSF component web API is a very good fit with so called “Web 2.0” (AJAX) and the increasing use of mobile devices requiring different mark-ups and a lot of component libraries are emerging for it already. This doesn’t grantee JEE will be the development platform of choice for WEB 2.0 (.NET is getting similar capabilities via “Atlas” for a start), but it does put it in a strong position. And Google’s support through GWT helps also. 7) Platform independence of Java is still an important card. Companies who run Solaris, or AIX, or Linux, or make heavy use of Mobile devices, are all likely to stick with Java for obvious reasons. And that is a lot of companies. 8) There is a huge slice of enterprise problems that JEE solves that nothing else really does. Projects I have worked on since jumping for the Microsoft world to the JEE world include bioinformatics systems that scan enzyme and molecular models looking for drug targets, retail systems where huge amounts of data has to be passed to and from thousands of clients and devices distributed across a store network, banking systems where the banking engines run on mainframes with bespoke software (written in COBOL) that hasn’t been touched since some time in the early 80’s but now we need an internet bank on top of them. And that’s just my projects. Now all of these could doubtless be built with C++, .NET, RUBY or whatever. But you’d spend so long writing the pluming code that you get for free from JEE I don’t know why you’d bother… Now maybe in five years time the next solution for Enterprise software will arrive but if it does it will be quite a while after it before everyone decides to move to it. And I don’t see any sign of it so far…
  136. Hi, just comming back to the article. Has anyone a link to some more detailed summary of the report? Maybe some of the controversies come from a journalistic misunderstanding? Well, if he means with J2EE a kind of application platform that could serve as a unified architecture than i must agree. It's been dead at least since the failure of EJBs. And again, if the few positive words abot Java relate to J2EE than it's also true, it will survive. But in SOA Architectures it's going to be a tough competition against other technologies, just because SOA maybe so greatly heterogenous. And It seems logical that in some areas J2EE is going to loose, just due to it's complexity. We will keep some of them maybe, if we learn such lessons as Ruby is currently giving us. michal

  137. ... and how far is Developers and some Manufacturers Vision from the real aspects of a necesary and definitive coming Service-oriented Architecture ? Can we find now - after reading this more than 80 interested articles - satisfactory answers to such questions ? Roland SOA Kompetenznetzwerk -----
  138. When trying to solve everything in one framework, you are actually killing it.
  139. I don’t get it. I am under the impression that SoA and Java EE mostly complementary. In this logic, if SQL become popular, does it also can kill Java EE? I am not expert but based on my limited knowledge they are two different things addressing two different aspects (of course may have few overlaps).
  140. .NET or Java???[ Go to top ]

    The company I work for is starting up discussions to choose a strategic platform to use for enterprise development. In order to get some background industry info, I've created a short survey at http://www.dotnetorjava.com. This survey tries to assess what is widely used today and what the consensus is among IT professionals as to which platform is best suited for enterprise software development. By taking just 5 minutes to fill out the survey, you'll help create worthwhile information that I imagine many people here would be interested in. Also, you'll be eligible to win a free iPod that will be given away at the end of the survey (8/7). To answer the survey, go to http://www.dotnetorjava.com. Thanks for your help and please help spread the word! Gary gmui@muitropolis.com
  141. Re: .NET or Java???[ Go to top ]

    Your survey is flawed. I think most large companies have a list of platforms blessed by Corporate IT, with Java and .NET both on the list (along with Windows and probably several Unix variants), and most developers at least occasionally deal with several different languages.
  142. Re: .NET or Java?[ Go to top ]

    Erik, Thanks for your response. I agree that across large organizations, many do in fact have both platforms as approved technologies. I also know though that some large banks have a preferred platform and that to use the other, they have to get approval for each project. In my case, our group wants to rationalize a choice in how we do things. While across an entire organization, it's not likely to settle with one technology, but within a group of 20 or so developers, it doesn't make sense to use both .NET and J2EE for platforms that basically do the same types of things. Our group is comprised of different businesses that have been merged through acquisition, so that's how we got to where we are. We currently have production systems built in J2EE, Mainframe, and .NET. As we look to re-engineer our Mainframe and .NET systems, we're looking to decide what platform we should choose. Thanks for your input - I hope this better explains our particular position and interest in what people generally use.
  143. Re: .NET or Java?[ Go to top ]

    Erik,
    Thanks for your response. I agree that across large organizations, many do in fact have both platforms as approved technologies. I also know though that some large banks have a preferred platform and that to use the other, they have to get approval for each project.

    In my case, our group wants to rationalize a choice in how we do things. While across an entire organization, it's not likely to settle with one technology, but within a group of 20 or so developers, it doesn't make sense to use both .NET and J2EE for platforms that basically do the same types of things. Our group is comprised of different businesses that have been merged through acquisition, so that's how we got to where we are. We currently have production systems built in J2EE, Mainframe, and .NET. As we look to re-engineer our Mainframe and .NET systems, we're looking to decide what platform we should choose.

    Thanks for your input - I hope this better explains our particular position and interest in what people generally use.
    I should have been more clear. From a survey construction point of view, it's really annoying to have "select only one" questions when several apply, and even determining a primary choice is impossible. So I think your driving off some people (such as myself) who would have normally completed the survey. Personally, I would say standardizing on a single platform in a large organization is generally a bad idea. The reason is a lot of software these days is purchased and customized rather than built from the ground up. Typically the product is more important than the platform on which it is built, and having people skilled in the platform is essential for success. So I think outright standardization, at least is a large organization, is not a good policy.
  144. Old programming practices never die - they wither away. Then after many years you're surprised when somebody tells you how many xxx-systems there are still left in the world. For those working with them though it is no fun when your tools leave the spotlight. So I am not interested in whether it is dead or not - what I'm waiting for is some kind of statement from all those that vehemently stood up for and defended all versions of EJB from beginning to end. And BTW instead of SOA, put "SOA and REST and all types of XML communication" And instead of J2EE put "Object Relational Mapping" (J2EE is just a subset). It is just not practical to convert 2, 3 or 4 times between objects and XML and/or SQL during the ride. But at least I have had been entertained under the way! The most fun was the thread "TSS is looking for J2EE success stories". From then it was all downhill. Maybe TSS one day will release all those "Success stories that we have secretly received and will publish at a further date"? Best regards Rolf Tollerud
  145. Re: will an apology be forthcoming?[ Go to top ]

    an apology is NEVER forthcoming. Ask the SOA marketeers about "Component Based Development" ya know that was supposed to solve everyones problesm just like SOA about 6 years ago ;) just add a layer of abstraction, bring to a boil and serve. Yeah the industry has never lacked for an abstraction but wheres the improvement? SOA will have another name in 2-4 years. And it will rot the current investments in SOA.
  146. "For some unknown reason our J2EE system crashed last night. It has been running without any problems for months, but suddenly it broke down. The only unsual thing we noticed was one of the backend systems having longer reponse time than usual (a batch job was running)". Have you heard that before? At least I have heard it quite many times the last couple of years. And it is not just a J2EE speciality. Replace J2EE in above with .NET or Spring - it doesn't matter. The problem is, that they are being used to integrate systems (naming it SOA or not), new systems and legacy systems, and they are not realy good at it. The main focus of these standards and platforms is to transfer the object oriented paradigm from stand-alone systems to distributed systems, and doing it without costs for the programmer - as transparently as possible. The tool is the proxy pattern and the remote procedure call. It makes the network and the different servers transparent. It also means that network delay an delays caused by high load on other servers are neglected. And that is the problem. Because these systems are mainly based on call-stack programming. That means, when a request is blocked, while it waits for a reply, it holds a lot of limited resources, memory and especially threads, which is taken away from doing real work. That leads to a less efficient system, with long reponse times and unpatient users causing still more load. Positive feedback and unstability is the electronic terms for this. What users and staff sees is a domino effect, where minor problems in one server propagates to other servers and escalates, so the total system seems having crashed. It has been a wellknown fact for many years that message based systems like MQseries is superior , when it comes to integrating systems, but remote procedure calls still dominates the arena. SOA or not - integrating systems escalates. Tools which are made for that, and are good for it, is those using the label ESB - or Enterprise Service Bus'es. They are message oriented, XML oriented, and will play a major role in the future, leaving a minor role for J2EE and .NET. I realy don't think complexity is the main problem of J2EE relating to SOA - it is more a matter of incapability. It will hit alternatives like .NET and Spring too. When the platform is an ESB, the programming language is not that important any more. It could open the arena for totaly new languages - I think it makes sense to say, that not much new has happened here the last 40 years. Or maybe programming languages have found their optimal form - like the bicycle. regards Hardy Henneberg
  147. +1
    When the platform is an ESB, the programming language is not that important any more. It could open the arena for totaly new languages - I think it makes sense to say, that not much new has happened here the last 40 years. Or maybe programming languages have found their optimal form - like the bicycle.
    There was so much right in this post that I don't know where to start. Having used Tuxedo (similar to MQSeries?) I totally agree with your point about Messaging and RPC. I also agree that the only reason to distribute is to integrate legacy systems. Speaking to a friend about this stuff over a beer last night and we came to the same conclusion you have. Software science stopped sometime in the mid seventies or eighties, and since then what we have had is techno-marketing mascarading as science. I'm learning Lisp and your point about languages reaching an optimal form is a good one. Many of the best programming ideas are there in the archive available to anyone open to taking a look. Paul.
  148. Speaking to a friend about this stuff over a beer last night and we came to the same conclusion you have. Software science stopped sometime in the mid seventies or eighties, and since then what we have had is techno-marketing mascarading as science.
    I think the inventors of Ruby (1993), Haskell (1990), Python (1990) and Erlang (released to the public in 1998) might take issue with you there. As might the software science departments of a considerable number of institutions. Perhaps Edinburgh University's top-rated Computer Science department should rename itself as 'Techno-Marketing'. Perhaps Durham's Department of Computer Science should stop publishing new papers on programming languages and software design, as they are only 'masquerading' as science?
  149. Speaking to a friend about this stuff over a beer last night and we came to the same conclusion you have. Software science stopped sometime in the mid seventies or eighties, and since then what we have had is techno-marketing mascarading as science.


    I think the inventors of Ruby (1993), Haskell (1990), Python (1990) and Erlang (released to the public in 1998) might take issue with you there. As might the software science departments of a considerable number of institutions. Perhaps Edinburgh University's top-rated Computer Science department should rename itself as 'Techno-Marketing'. Perhaps Durham's Department of Computer Science should stop publishing new papers on programming languages and software design, as they are only 'masquerading' as science?
    Hi Steve, Are you being confrontational for the sake of it? I can only speak for Ruby and Python which I know something about, and I'm sure that the creators of both would be the first to admit that they largely repackaged the available science. As for Edinburgh University, I offer my sincerest apologies :^) BTW. I was making reference to the dominant SOA market leaders, J2EE and .NET as mentioned in the post I was responding to (the context for the sentence you chose to quote). Have you got a point of view, ideas or specific experiences of your own to share? If not what is it that you think you are adding to this debate exactly? I will not be as rude as to question your credability as others on this thread have done, but responses like this does seem to strengthen their case :^) Paul.
  150. Speaking to a friend about this stuff over a beer last night and we came to the same conclusion you have. Software science stopped sometime in the mid seventies or eighties, and since then what we have had is techno-marketing mascarading as science.


    I think the inventors of Ruby (1993), Haskell (1990), Python (1990) and Erlang (released to the public in 1998) might take issue with you there. As might the software science departments of a considerable number of institutions. Perhaps Edinburgh University's top-rated Computer Science department should rename itself as 'Techno-Marketing'. Perhaps Durham's Department of Computer Science should stop publishing new papers on programming languages and software design, as they are only 'masquerading' as science?

    Hi Steve,
    Are you being confrontational for the sake of it? I can only speak for Ruby and Python which I know something about, and I'm sure that the creators of both would be the first to admit that they largely repackaged the available science. As for Edinburgh University, I offer my sincerest apologies :^)

    BTW. I was making reference to the dominant SOA market leaders, J2EE and .NET as mentioned in the post I was responding to (the context for the sentence you chose to quote).

    Have you got a point of view, ideas or specific experiences of your own to share?

    If not what is it that you think you are adding to this debate exactly?

    I will not be as rude as to question your credability as others on this thread have done, but responses like this does seem to strengthen their case :^)


    Paul.
    I am making a serious point here, although I admit I was being deliberately confrontational in this case. You often put forward sweeping statements with little evidence as if they were fact, and I find that confrontational, especially when (as in this case) I do have personal experience - I have friends and colleagues who have undertaken academic work into software engineering in the 80s and 90s, and have spent years doing quality research in this field, and would probably not have had a good reaction to your post. You may want to now qualify what you said as referring to JEE and .NET (but even then, to claim that things stopped in the 80s is somewhat extreme), but you have to take responsibility for what you actually posted. What I am trying to add to a debate is to get the focus on facts and evidence, not wildly extrapolated personal experience and opinion. I have this belief that in order to make responsible decisions in IT we have to have facts to hand, and not off-the-shelf opinions (I have seen too many projects fail because of those). I haven't the slightest interest if people consider me to lack credibility, because that isn't the issue. When I put forward personal viewpoints I always word them with care to ensure people realise they are just that - opinions. When I try and argue a point I do my best to back it with objective information. People should be arging based on this kind of information - things should be about whether facts are correct, not about opinions of individuals. However, I am beginning to realise that this is futile - what seems to matter increasingly is preconcieved (and largely entrenched) opinions and politics, and, perhaps naively, I find those irritating, so I shall take a break from TSS (should give me at least a few more minutes of productive working time each day :)
  151. I am making a serious point here, although I admit I was being deliberately confrontational in this case. You often put forward sweeping statements with little evidence as if they were fact
    The sentence you chose to quote is clearly stated as opinion (very few people do hard research over a beer).
    and I find that confrontational, especially when (as in this case) I do have personal experience - I have friends and colleagues who have undertaken academic work into software engineering in the 80s and 90s, and have spent years doing quality research in this field, and would probably not have had a good reaction to your post. You may want to now qualify what you said as referring to JEE and .NET (but even then, to claim that things stopped in the 80s is somewhat extreme), but you have to take responsibility for what you actually posted.
    I do take full responsibility. You chose to quote me out of context. Why I'm not sure, especially when the original context is there for all to see. You've done this on several occasions, which I chose to ignore. You have also done the same to others on this thread who do not share your opinion.
    However, I am beginning to realise that this is futile - what seems to matter increasingly is preconcieved (and largely entrenched) opinions and politics, and, perhaps naively, I find those irritating, so I shall take a break from TSS (should give me at least a few more minutes of productive working time each day :)
    Perhaps it is you that holds the entrenched opinion, which is fine by me. Debate and discussion about qualitative issues (likes, dislikes, personal preferences etc) is valuable in it's own right. Perhaps your irritation stems form your inability to put forward a convincing argument to support your point of view? I'm open to reasoned argument and debate, you choose to offer neither. Paul.
  152. I do take full responsibility. You chose to quote me out of context. Why I'm not sure, especially when the original context is there for all to see. You've done this on several occasions, which I chose to ignore. You have also done the same to others on this thread who do not share your opinion.
    All I have been after is clarity. What you assume is quoting out of context is because I do my best to reply to what is actually posted, not what people assume they have posted, or what I think they might mean.
    Perhaps it is you that holds the entrenched opinion, which is fine by me. Debate and discussion about qualitative issues (likes, dislikes, personal preferences etc) is valuable in it's own right.
    No, I don't think so. The reason is that it is hard to state opinion without having to back up that opinion, and then we require hard facts. It is fair, for example, to say 'I prefer Tomcat' - that is opinion. But (for example, again) to claim 'everyone is moving to Tomcat' is a statement of fact, and needs to be backed up with 'my evidence for this is....' and then one should expect to be challenged.
    Perhaps your irritation stems form your inability to put forward a convincing argument to support your point of view?
    I doubt it - I have had long scientific career in the past, in which the ability to put forward convincing arguments (or at least make a good stab at it) is a key part. You don't get far without it :) It is a hard skill to learn - but who knows? Perhaps the little grey cells have started to decline with age....
    I'm open to reasoned argument and debate, you choose to offer neither.

    Paul.
    Well, I wish to politely disagree. You can't have it both ways - imply you are open to reasoned argument, but then chose to ignore posts. For example, I put forward an honest opinion about the possible safety of certain open source languages (based on actual facts about those languages, and based on historical evidence) because they can change at the whim of a few developers - raising issues of security long term. I think this is a significant matter (and exposes an advantage of Java/JEE), and would have enjoyed more discussion. Having a strong debate can be challenging, and sometimes people react to arguments against their opinions as if they were arguments against them personally. If I have caused offense, I sincerely apologise. I have found our debates useful in the past - you may be interested to know I am actually investigating the use of Ruby for a small website project (Java is not an option on the server) - so you may perhaps not consider me a hopeless case :) But anyway, as I said, this is taking up time - so, if I am not around for a while, good luck with escaping from the clutches of EJBs!
  153. bullshit If you are an enterprise J2EE developer you have never developed an OO app in your life. How dare you blame the call stack. Grow up man! Java apps arent OO!
  154. If you are an enterprise J2EE developer you have never developed an OO app in your life.
    OK. I am a J2EE developer since 2001 and a certified J2EE architect. I thought I developed OO apps since 1987 in Smalltalk, C++, java and ruby - apparently I did not.
    How dare you blame the call stack.

    Don't know, I just did it.
    Grow up man!
    Guess it is too late - I'm 51.
    Java apps arent OO!
    I realy didn't know that :-)