Discussions

News: Dan Creswell: Victims Of J2EE Success

  1. Dan Creswell: Victims Of J2EE Success (34 messages)

    Dan Creswell has posted "Victims Of J2EE Success," on the problems caused when J2EE is the dominant standard technology for Java middleware, but the demands of a specific application are different problems than the one J2EE was designed to solve - i.e., an eBay, a MySpace, or a Google. About J2EE programmers, he says:
    ...programmers have their minds warped into the J2EE way of thinking:
    1. There is nothing beyond the database
    2. POJOs focused purely on business logic
    3. This is distributed programming
    4. Ops is someone elses problem
    5. Deploy more or bigger boxes to scale
    Most enterprises can comfortably tolerate systems built this way but what if you're not most enterprises? What if you are an eBay or a MySpace? eBay for example have thrown out almost all of J2EE and built their own libraries to tackle the problems they face around:
    1. Monitoring
    2. Hot Upgrades
    3. Scaling
    Basically once you’re beyond a certain level of challenge the J2EE way of thought and patterns of design don’t work. So where does one find Java programmers that can cope with such a challenge?
    There's more to the post, including a list of some other technologies, but the core point has been made. What happens when you need to draw outside of the lines J2EE provides?

    Threaded Messages (34)

  2. Deployment and Monitoring[ Go to top ]

    I am not sure I follow Dan. Does he believe that deployment and monitoring are the responsibilities of a Java developer? Deployment is any reasonable size corporation will always be done by application management & operations. Deployment: What is currently lacking today in the J2EE space regarding deployment is the ability to allow developers and architects to define deployment models with constraints, and a way of mapping this model to a set of abstract application server configurations which are in turned mapped to virtual/physical processing/hardware units. I worked on a prototype of such a solution back in 2000 when I worked for Borland's Enterprise Business Unit. It was called AppSimulator and the demo was well received by those fortunate to see it. Unfortunately at that time the only products that got money and resources within Borland had the word "JBuilder" in them. Monitoring: Today in the J2EE space there are many vendors providing monitoring and management solutions. It is because of the stability of the specifications and relatively good quality of the underlying implementations that this has been possible. The same cannot be said of competing frameworks, runtimes, and languages. That said I do think that the Java SDK has not offered enough in the way of diagnostics and resource metering. Today developers are forced to (ab)use logging API's for contextual tracing and event monitoring pushing (writing) the stringified data out instead of publishing (announcing) in-flight state and metering that can be pulled on them. "eBay for example have thrown out almost all of J2EE and built their own libraries to tackle the problems they face around: Monitoring...." Does not every developer have a wish to create his very own monitoring solution? It is much more interesting work than enhancing an online auction software and requires very little business knowledge, ;-). regards, William Louth JXInsight Product Architect JInspired "Java EE tuning, testing, tracing and monitoring with JXInsight" http://www.jinspired.com
  3. Re: Deployment and Monitoring[ Go to top ]

    Yes, the big problem with J2EE is that it limits the availability of java programmers with a strong desire to write homegrown versions of bmc patrol and tivoli storage manager =) No, but seriously, there are pretty few big companies who have the luxury of standardising deployment, monitoring, etc for such a limited set of platforms that writing something homegrown is possible or even that *one* platform can dictate the entire environment. The diversity of a normal enterprise it environment usually means standardising on some product, and processes, that supports many platforms, in different stages of life-cycle, and in many different versions. Of course it would be interesting with something that addresses: "What is currently lacking today in the J2EE space regarding deployment is the ability to allow developers and architects to define deployment models with constraints, and a way of mapping this model to a set of abstract application server configurations which are in turned mapped to virtual/physical processing/hardware units." The problem is just that J2EE is a to narrow scope. Such a solution should address things outside J2EE scope as well, like network configurations, database management, server platforms, storage, etc. I suppose that most (successfull) enterprises have a model for this, but that it is mostly process driven with not so good tool support.
  4. Re: Deployment and Monitoring[ Go to top ]

    One could only wish that BMC Patrol, or any other "top-shelf" framework could really address the issue of management of custom J2EE or even plain Java applications. Of course, I'm biased, but I think the focus should be in two areas: 1- drive the Java runtime to expose more information about itself with as little impact to the running environment as possible. JRockit does a good job at this, but it's not standard, and as such it's not present in non-Jrockit setups. We've faced this issue at Hyperic over the last 4 years, and this is what led us to create SIGAR, which is the only way that a cross platform server side Java application can gain safe access to understanding the performance and layout of its underlying operating system and hardware. We open sourced this last year so that people could start looking at how we did it, and incorporating it into their projects. 2- exploit JMX by baking more manageability into the applications. JMX is an enormous advantage that Java has over every other alternative platform (i'm calling you out LAMP/RAILS/etc.). .Net brings something to the table, but of course, it's got other issues. We've seen a lot of success in places where developers build in custom monitoring hooks, custom log hooks, and even custom management operations with JMX which they can easily consume by writing an HQ plugin to go with it. The end result of this is that developers and ops teams don't spend time building out custom monitoring applications (fun as that might be, William!). Instead, they can build manageability into their apps and then use some other solution for it. Naturally, I'd invite everyone to check out HQ for this purpose. This is also one of the reasons we made it open source last year. -javier http://www.hyperic.com
  5. Re: Deployment and Monitoring[ Go to top ]

    One could only wish that BMC Patrol, or any other "top-shelf" framework could really address the issue of management of custom J2EE or even plain Java applications.
    Here we ago again with the "BIG FOUR vs the little guy" song that just keeps playing all day long on the Hyperic radio station. Can you please try to be more specific and at least state what is the frame of reference? Service Management? Performance Management? Incident Management? Problem Management? I am not saying these products are applicable to J2EE (or this discussion) but I would like to see a targeted discussion. In my opinion your two points are much more applicable to service management (constructing logical/physical service models and relating/grouping/aggregating/ them with metric end points) than application performance management. Exposing more of the JVM runtime information is only going to be useful when this can be combined with application execution behavior (meter the resource consumption of execution paths and bill the associated application/component/frameworks). Today JVM have no very little understanding of what the application is doing except for the execution of byte code. The end result of this is that developers and ops teams don't spend time building out custom monitoring applications (fun as that might be, William!). I am now totally confused! In the previous paragraph you castigate developers for using a custom framework that could be using a standard such as JMX or ARM and then you go on to recommend them build a HQ Plug-in. For your information I was recommending that additional API's be incorporated into the JDK/JRE that would allow developers to expose work flow (software execution model) that moves up a level of abstraction that is much more scalable and contextual, enabling various teams (development, testing, operations) to participate in problem analysis. Why should one only look at the software execution model in terms of performance? For the most part I do not think application developers would have to explicitly code to the API's because there are many instrumentation techniques available to support such injection: AOP, Interceptors, Event Listeners. With a service provider interface contract defined and a standard API it would be easy to move from a primitive logger backend to a more comprehensive solution feeding the data to a management console with powerful visualizations. It would be easy to add auditing, runtime inspections, billing, problem diagnostics.... once we had a standard and non-native (JVMTI) interface for developers. Please take a look at our open Probes and Diagnostics API http://www.jinspired.com/products/jxinsight/api/ There are many other similar API's out there (JETM, Jamon, LogBack, X custom tracing solution) looking to collect contextual data related to the execution. regards, William
  6. Re: Deployment and Monitoring[ Go to top ]

    What is currently lacking today in the J2EE space regarding deployment is the ability to allow developers and architects to define deployment models with constraints, and a way of mapping this model to a set of abstract application server configurations which are in turned mapped to virtual/physical processing/hardware units. I worked on a prototype of such a solution back in 2000...
    Ah, so what the world really needs is something you already did seven years ago. That makes sense
    Unfortunately at that time the only products that got money and resources within Borland had the word "JBuilder" in them.
    Hey you're not bitter or anything, are you?
    the Java SDK has not offered enough in the way of diagnostics and resource metering
    This is a joke, right? Modern JVMs offer tons resource monitoring. At any given time, you can find out about every thread and its stack, and everything on the heap, including how long each object on the stack has been around, etc. You can find out about every garbage collection and why it happened. In terms of low level information, what more do you want? Oh, so maybe you want higher-level information for diagnostics? Ok, that's what JMX is for. You can expose anything about your application for monitoring and diagnostics through JMX. I guess the hard part is that you have to pick what higher level things to expose, but what alternative is there to that? Plus if you re-use components like datasources, message queues, web services that are often provided by vendors (that you could alternatively write yourself) then chances are they've already exposed a lot of useful information via JMX. If you really think that you have to log out strings about the state of your application for monitoring... then you are just uninformed.
  7. Re: Deployment and Monitoring[ Go to top ]

    Michael, "Ah, so what the world really needs is something you already did seven years ago. " Yep at the same time I was creating a CEP product called JEEP - Java Enterprise Event Processing. I had also worked on another project called VisiCache - (Visi => VisiBroker). All innovative technologies must wait for the market to catch up. I did not. Please re-read my post before going straight into flame mode with the blinkers on. There is a difference between "metering" and "monitoring". With regard to diagnostics you should check out the following links to understand what I am talking about. Context is important. Diagnostics Tags http://blog.jinspired.com/?p=52 Diagnostics Entries http://blog.jinspired.com/?cat=19 I was talking about much higher levels of abstraction that are much more useful than call frames stacks - contextual work flow stacks & frames!. I said abstractions and not aggregation or grouping which is what you get with JMX. In general JMX is devoid of context and offers little in the way of metering which is not the same as monitoring.
    If you really think that you have to log out strings about the state of your application for monitoring... then you are just uninformed."
    I was talking about those that living on the planet earth. Like it or not this is how most libraries and frameworks publish internal state changes or events - with state that is anemic. regards, William
  8. Re: Deployment and Monitoring[ Go to top ]

    If you really think that you have to log out strings about the state of your application for monitoring... then you are just uninformed."
    William response:
    I was talking about those that living on the planet earth. Like it or not this is how most libraries and frameworks publish internal state changes or events - with state that is anemic.
    William is right, most frameworks print to a log, ...then require 3rd party tool that can parse and analyze the log file for monitoring.. I think people are reading to much into this original post and the author doesn't really understand J2EE, J2EE is just the specification to help u build enterprise systems...not sure why it is stated eBay, google, are not “enterprise”.. ...and stating how eBay threw out there J2EE doesn’t make sense…..i am sure it still has J2EE principles applied in ebay, and google(powered on Jboss farms by the way..).. now and days have light J2EE frameworks that fixes alot of J2EE problems, not to mentioned Terracotta which aims to make clustering easier as well..
  9. Re: Deployment and Monitoring[ Go to top ]

    Why do we find so many monitoring products on the market? Because everyone's requirements are different. Some like it slow and comprehensive for integration analysis, others as lite as possible to run it live in production. Some swear by OpenSource, while others crave for commercial licenses (read: support). If you like resource-conscious and free, you may be interested in MessAdmin, a very lite-weight monitoring utility providing you with detailed insider informations on what's happening in your (black) box. It can display the data either via an integrated webapp or via JMX, and is easily extensible with custom plugins. Feel free to give it a try, and/or play with the online demonstration available at the project's web site. Cédrik ________ MessAdmin, J2EE monitoring made easy
  10. Re: Deployment and Monitoring[ Go to top ]

    There is a difference between "metering" and "monitoring" ... JMX is devoid of context and offers little in the way of metering which is not the same as monitoring.
    Ok, so JMX only provides monitoring, not metering. However, your original post did not mention metering. It was titled "Deployment and Monitoring." So you made a post about monitoring, not metering. I countered with JMX. You seem to agree that JMX provides monitoring, but now you say it doesn't provide metering. I went ahead and read both of the links you provided. Neither of them mention metering either.
    I said abstractions and not aggregation or grouping which is what you get with JMX.
    Actually I don't see any mention of either abstractions or aggregation in your original post. The only "abstraction" you mentioned was configuration abstractions for deployment. Maybe you think I'm flaming you, but I think you're just abusing this forum to plug your own product. The worst part is that you're not even doing a good job of plugging your product. You seem to be trying to create strawman arguments for your product.
    I was talking about those that living on the planet earth.
    I'm not sure what's more funnier. That you would accuse me of flaming you or that your own attempt at flaming was botched with poor grammar. I digress...
    Like it or not this is how most libraries and frameworks publish internal state changes or events - with state that is anemic.
    Maybe that is true, but it is irrelevant to your argument. You said that developers were forced to use logging for publishing application state information. That's just not true. Any developer can use JMX. Even if we revise your original statement to "framework developers are forced to use logging" it's still not true. There is a viable option. Now most applications do a lot of logging. However that's usually a function of log level, so it can be turned down. You can augment this with JMX. Now I will definitely agree that a lot of open source frameworks out there don't do this. In related news, there are many open source frameworks that don't document their code well either. Does that mean there is a flaw in the documentation capabilities of Java?
  11. Re: Deployment and Monitoring[ Go to top ]

    I went ahead and read both of the links you provided. Neither of them mention metering either. Did you managed to read the paragraph (even the first four words) just above the links? Here it is again. "With regard to diagnostics you should check out the following links to understand what I am talking about. Context is important." For "metering" references you might want to read our Probes API and the following links. http://blog.jinspired.com/?cat=21 http://www.jinspired.com/products/jxinsight/index.html#probes
    You seem to be trying to create strawman arguments for your product.
    Wow. The pot calling the kettle black. The strawman had me for minute thinking I was talking to Rickard.
    You said that developers were forced to use logging for publishing application state information. That's just not true. Any developer can use JMX. What kind of state would that be? Have you ever seen a JMX console display a Java object object other than a primitive or primitive wrapper. For the most part you will get a toString representation in the remote management console. Yes I know there are laborious workarounds but I was talking about contextual state related to execution flows - calling thread(s). But please keep on skipping over what I stated. I am not knocking JMX just putting its usage in context We fully support it within our product and have worked around issues that other monitoring solutions run into related to state representation within a console. http://blog.jinspired.com/?p=6 William
  12. Re: Deployment and Monitoring[ Go to top ]

    Arghhhhhh. My typing is getting worse. Can we have an edit feature please? William
  13. Does he believe that deployment and monitoring are the responsibilities of a Java developer? Deployment is any reasonable size corporation will always be done by application management & operations.
    My book "Release It!" talks about these issues (in the chapters "Transparency" and "Adaptation"). Companies lose extraordinary amounts of money by ignoring operational concerns during development. It is IT Operations that will execute deployments and perform the routine monitoring, but it is the job of architects and developers to build software that is deployable and monitorable. For example, a typical J2EE app references static content, such as Javascript and CSS files, that gets served from the web servers (and, hopefully, cached by the CDN). These files frequently change with a new release of the application. Most of the time, the application developers keep the same path names for the new revisions of the files. That means the N and N+1 releases have a conflict---they cannot both be running at the same time, because the each point to the same set of files, but require different revisions of those files. In that situation, you can only deploying a new release by shutting down the world (i.e., "gone fishing") until all the code is rolled across all the servers. For a small-to-medium retailer, this might be acceptable. For a large enterprise with thousands of servers, it certainly is not. It's possible to structure the static assets so that the N and N+1 releases can run concurrently. That lets you roll the code across your server farm without taking downtime. But, it only works if the developers have planned it that way. (E.g., using URLs with release numbers embedded in them.) There's a similar story to be told about monitoring. Yes, the J2EE vendors provide monitoring hooks to tell you what the container is doing, but it's up to the developers and architects to create transparency by exposing what the application is doing. This doesn't mean that the developers are creating their own monitoring system, just opening up their internals for view by the enterprise-wide monitoring system.
  14. static content? pppphhhhhttttt[ Go to top ]

    Having two versions of static content is not a difficult problem to solve. Deploying two revisions of software against the same database, on the other hand is a very hard problem to solve. Especially when table structure changes and significant data migration is involved.
  15. Hard, but solvable[ Go to top ]

    Having two versions of static content is not a difficult problem to solve.

    Deploying two revisions of software against the same database, on the other hand is a very hard problem to solve. Especially when table structure changes and significant data migration is involved.
    That's true, it is a harder problem. Much harder. Still, if you determine that there's value in doing deployments without downtime, then it can be done. When downtime costs $100K or $1M per hour, you're well motivated to spend some extra time developing the "shims" that let you run two versions of the code concurrently even with schema revisions. At the risk of exceeding my "plug" limit for the day, I do talk about databases in my "zero downtime deployment" section of Release It, too. -- Michael T. Nygard http://www.michaelnygard.com/ Release It! Design and Deploy Production-Ready Software
  16. Yes this is understood by most people with some degree of experience in deploying software in production bu I fail to see how this relates to:
    ...programmers have their minds warped into the J2EE way of thinking: 1. There is nothing beyond the database 2. POJOs focused purely on business logic 3. This is distributed programming 4. Ops is someone elses problem 5. Deploy more or bigger boxes to scale
    That is why I stated I did not understand what Dan was really trying to say. Was he b(f)laming J2EE for the daily problems faced by operations when the hand over takes place? The specifications do try to steer developers in the right direction for successful (and manageable) deployments better . Whether the applications configuration and runtime execution behavior is compatible with the specification is another thing. Early last year I actually spent time trying to convince application servers vendors such as JBoss and BEA to consider embedding runtime diagnostics tools within their offerings that would be enhanced by project leads with execution & state pattern definitions that could be attributed to runtime errors and scalability/performance problems. As you can see I did not get very far even though this would have been a win-win for those companies depend on support contracts. regards, William
  17. Most of you seem to be missing the point. This isn't limited to logging. You could monitor Sandra Bullock's tuckus FROM SPACE with JMX if you had enough time. I think the point of the blog post is centered on the mindset of most developers given the most common environments they would be working in. It's not rare to interview someone and mention something like Tomcat, just for them to counter with, "Oh, I've only used WebSphere." These developers usually have no concern for their code's affects on production machines, coding outside of entity beans, or _maybe_ SLSBs for the business tier interface if you're lucky. Of course, WORA and blahblah "don't think about garbage collection because Java is maaaagic!" Essentially, it's ignorance and complacency in the workforce. That's fine. We need people to sweep floors and bus tables, too. Where does this damage begin? Sales and marketing. Who uses WebSphere but a bunch of managers who are more familiar with Microsoft Project than their own children? A lot of this is mandated, and only for business ignorance reasons. "That's what 123-Sprockets [dot com] uses! Switch tomorrow!" Why use all of that expensive and limited server software when you're just hosting a shopping cart or trying to smoosh something inappropriate into it? Some companies still resist Spring for smaller projects! Anyway, this is an endless and tired argument about the obvious. Developers, generally, are stupid, ignorant, and lazy creatures who only got a degree to make a buck and survive until they die... like most people. If the business side changed, or acknowledged that salespeople almost never have the right solution for them, life would be grand. ... or I totally missed the point. :)
  18. Re: Deployment and Monitoring[ Go to top ]

    ... or I totally missed the point. :)
    Seem to be spot on to me.
  19. Re: Deployment and Monitoring[ Go to top ]

    ... or I totally missed the point. :)


    Seem to be spot on to me.
    Do explain.
  20. [in a whisper voice:] means I agree with you. meaning you didn't miss the point. http://dictionary.reference.com/browse/spot%20on
  21. Most of you seem to be missing the point. This isn't limited to logging. You could monitor Sandra Bullock's tuckus FROM SPACE with JMX if you had enough time.

    I think the point of the blog post is centered on the mindset of most developers given the most common environments they would be working in. It's not rare to interview someone and mention something like Tomcat, just for them to counter with, "Oh, I've only used WebSphere."

    These developers usually have no concern for their code's affects on production machines, coding outside of entity beans, or _maybe_ SLSBs for the business tier interface if you're lucky. Of course, WORA and blahblah "don't think about garbage collection because Java is maaaagic!" Essentially, it's ignorance and complacency in the workforce. That's fine. We need people to sweep floors and bus tables, too.

    Where does this damage begin? Sales and marketing. Who uses WebSphere but a bunch of managers who are more familiar with Microsoft Project than their own children? A lot of this is mandated, and only for business ignorance reasons. "That's what 123-Sprockets [dot com] uses! Switch tomorrow!" Why use all of that expensive and limited server software when you're just hosting a shopping cart or trying to smoosh something inappropriate into it? Some companies still resist Spring for smaller projects!

    Anyway, this is an endless and tired argument about the obvious. Developers, generally, are stupid, ignorant, and lazy creatures who only got a degree to make a buck and survive until they die... like most people. If the business side changed, or acknowledged that salespeople almost never have the right solution for them, life would be grand.

    ... or I totally missed the point. :)
    :) You didn't miss the point but there are some other dimensions, at least for me. One of them is purely selfish: "how do I go about finding people who aren't of this nature" because that's the kind of person I need to hire for Betfair. Second: The Java programming masses might be dismantling their own market value. It's often wondered why RoR get's traction with claims of "it's not enterprise" etc. This could also be down to fixed, lazy mindsets. Third: Language, platform and API are largely irrelevant. Architectural awareness and an engineering approach are the things that underpin good work and allow you to build a solid career across technology trends. Fourth: It seems that "networked'ness" of systems is going to increase substantially, introducing new challenges that are entirely about architectural understanding. These kinds of challanges can't be easily solved by the container approach which hides the very details one must address. If one wished to learn about this stuff, perhaps Java is not the place to be? Fifth: It might well be a tired argument but it might also still be valid - bad commentary on our progress maybe? Thanks for seeing where I was going and pushing me further down some (for me anyways) unexplored reasoning paths. Dan.
  22. Especially MySpace, which is running on ColdFusion and decided to move to .NET, seems to be the greatest victim.
  23. Especially MySpace, which is running on ColdFusion and decided to move to .NET, seems to be the greatest victim.
    Yeah, I should've been smarter about the references I picked. I was using MySpace as an example of something that doesn't fit within the conventional enterprise type demands envelope rather than as a tech example. I appreciate they aren't a Java house and should've clarified that one.
  24. Monitoring, hot-upgrading (deployment?) and scaling are non-functional requirements that have nothing to do with J2EE spec. Some J2EE vendors are bound to be better at it then others, but there is no fundamental reason why a J2EE server couldn't implement any non-functional requirement one can think of.
  25. Monitoring, hot-upgrading (deployment?) and scaling are non-functional requirements that have nothing to do with J2EE spec. Some J2EE vendors are bound to be better at it then others, but there is no fundamental reason why a J2EE server couldn't implement any non-functional requirement one can think of.
    Not quite because some non-functionals have to be addressed in your architecture. J2EE confines you to a certain set of architectural approaches which address certain ranges of those non-functionals. But it you are outside those ranges, no amount of fiddling under the covers in the server helps because it's an architectural issue not server implementation issue.
  26. Monitoring, hot-upgrading (deployment?) and scaling are non-functional requirements that have nothing to do with J2EE spec. Some J2EE vendors are bound to be better at it then others, but there is no fundamental reason why a J2EE server couldn't implement any non-functional requirement one can think of.


    Not quite because some non-functionals have to be addressed in your architecture. J2EE confines you to a certain set of architectural approaches which address certain ranges of those non-functionals. But it you are outside those ranges, no amount of fiddling under the covers in the server helps because it's an architectural issue not server implementation issue.
    Yes, every architecture has it's boundaries. But I don't see these boundaries constraining any of the points you mentioned. Do you have an example?
  27. Gee, couldn't you also argue that these "J2EE victims" and J2EE itself are victims of COBOL's success? J2EE addresses a very important problem space - the one that most of the corporate operational systems live in. It does not attempt to address every computing or IT domain. Why is that a problem? J2EE doesn't fly aircraft or manage my car very well. How well does J2EE work as an OLAP tool? I probably wouldn't use it to implement SCADA, though I might connect SCADA to back end services implemented with J2EE. J2EE isn't real real-time either. Horrors! This reminds me of the debates here that claim Java sucks or has failed because its not as slick a tool as Ruby or some such for quickly creating a web frontend. There are lots of different kinds of programmers using lots of different kinds of tools to solve lots of different kinds of problems. I doubt that the majority of programmers in the world are doing J2EE or even Java. This is not a problem. Get acquainted with the other tools in the box.
  28. Gee, couldn't you also argue that these "J2EE victims" and J2EE itself are victims of COBOL's success? J2EE addresses a very important problem space - the one that most of the corporate operational systems live in. It does not attempt to address every computing or IT domain. Why is that a problem? J2EE doesn't fly aircraft or manage my car very well. How well does J2EE work as an OLAP tool? I probably wouldn't use it to implement SCADA, though I might connect SCADA to back end services implemented with J2EE. J2EE isn't real real-time either. Horrors!

    This reminds me of the debates here that claim Java sucks or has failed because its not as slick a tool as Ruby or some such for quickly creating a web frontend.

    There are lots of different kinds of programmers using lots of different kinds of tools to solve lots of different kinds of problems. I doubt that the majority of programmers in the world are doing J2EE or even Java. This is not a problem. Get acquainted with the other tools in the box.
    Hmmm, so either you didn't read the original post, or you didn't understand what I meant which could be cos I wrote it so badly. My blog posting is about the issues of finding Java people who can do server-side but haven't been heavily indoctrinated into the J2EE mindset such that they can think outside of that particular box when it's necessary. I finish by asking the question, should I actually look for Java people at all or should I scatter the net more widely outside of Java land and accept the lag whilst they learn Java?
  29. Dan, Actually I did read the blog, but maybe it was my post that was so poorly written. It has always been true that most programmers have sought and promoted mainstream (J2EE, COBOL/CICS, etc.) skills. There have also always been problems outside the mainstream that these skills alone could not address. But, I've always known programmers who specialize in the skills and tools necessary to address those domains. In many cases I don't share their skills or knowledge, so we seek them out and hire them. There are companies - Lockheed Martin, for instance - that create a lot of systems for which J2EE is completely unsuitable, such as the Space Shuttle, fighter plane avionics, weapon systems, etc. The guys working on these system do a brilliant job, but how many know SOA? So, your complaint seems to me to be that ordinary programmers with mainstream skills are not well equipped to solve the more esoteric and demanding problems. No offense, but duh! The problem is not J2EE. The problem, if there is one is people. You know, about half of them are below average ! ;)Most people aren't seeking adventure and new experiences. Many don't even bother to stay current. Few have read a book in their profession since college. Those where come here are among the exceptions. So it's no surprise that the ordinary programmer, Java or otherwise tends to gravitate to what they think will keep them employed instead of seeking out what may be a more challenging, more lucrative and more risky niche.
  30. I think Dan still does not understand what an Enterprise Architect do. One of the task of an architect is to include the monitoring, scalability, failover, hot deployment ...etc in the architecture. Java developers shall develop according to the architecture and provide hooks in their application to support the manageability. Well, some people love to talk about what they don't understand....
  31. He might know a little more than you think. I remember him from the sun jini mailing lists. Wasn't he one of the core developers on that technology? ....(disclaimer: I've built some pretty large "enterprise architectures" using jini / javaspaces to solve similar problems that j2ee attempts to address and so may be biased towards agreeing with him to support my own decisions.. ;) )
    I think Dan still does not understand what an Enterprise Architect do.
    One of the task of an architect is to include the monitoring, scalability, failover, hot deployment ...etc in the architecture.
    Java developers shall develop according to the architecture and provide hooks in their application to support the manageability.
    Well, some people love to talk about what they don't understand....
  32. Not Invented at Sun Microsystems[ Go to top ]

    I would like to point out some things.. 1, Some solutions make it into J2ee and some do not: Made into J2ee spec: -JMX, Jboss Still outside the spec: -OSGi ..and quite frankly both JMX and OSGi have their role to play in java solutions. Now lets take a look at some past approaches... JBoss before 2006 just went by j2ee spec and nothing beyond..I may be wrong about the date and I am sure red hat employees can correct me on this..:) Apache Geronimo decided to go beyond the j2ee spec with Spring IoC resulting ina a less complex configuration and etc Now go through the typical configuration of an j2ee app both on JBoss and Apache Geronimo and you will start to love Geronimo and hate JBoss.. The community has come up with solutions to particular J2ee problems... And with new stuff coming in forms of Grails, Seam, OpenSails(POJO rails) and etc it would seem that the authors debate points might be somewhat muted in certain cases... Not everything in java is invented at Sun or at jcp.org
  33. I would like to point out some things..

    1, Some solutions make it into J2ee and some do not:

    Made into J2ee spec:
    -JMX, Jboss
    Still outside the spec:
    -OSGi

    ..and quite frankly both JMX and OSGi have their role to play in java solutions.

    Now lets take a look at some past approaches...

    JBoss before 2006 just went by j2ee spec and nothing beyond..I may be wrong about the date and I am sure red hat employees can correct me on this..:)


    Apache Geronimo decided to go beyond the j2ee spec with Spring IoC resulting ina a less complex configuration and etc


    Now go through the typical configuration of an j2ee app both on JBoss and Apache Geronimo and you will start to love Geronimo and hate JBoss..

    The community has come up with solutions to particular J2ee problems...

    And with new stuff coming in forms of Grails, Seam, OpenSails(POJO rails) and etc it would seem that the authors debate points might be somewhat muted in certain cases...


    Not everything in java is invented at Sun or at jcp.org
    My debate points aren't about the technology but the way in which people think as the result of exposure. Sure Spring has made your life a little easier but has it really changed the way you think or do you still use n-tier, databases, transactions, clusters where nothing is allowed to fail etc? i.e. The detailed work might be different but the overall way you build systems (architecture/high-level design _not_ code) is the same. And the underlying motivation of the blog entry is that I'm looking for developers who don't think the J2EE (and it's successors) way and don't tell me that this or that technology is the antidote. I'm looking for developers who solve the problems of monitoring, deployment, scaling, separation of concerns etc at design level not technology level. And I'm wondering if I'm the only one seeking such a developer and if I'm not, how others are going about finding these developers.
  34. While the authors raise this important issue, we must understand that eBay and Google apps are not "enterprise apps" ; they are self-hosted consumer oriented apps. These apps have very different requirements than those addressed by J2EE. Most of the J2EE are actually focusing on flexible customization, configurations and integrations. That's why we have all these arcane XML configuration files around. On the other hand, eBay and Google are installed on their own servers. There is not too much need to worry about supporting dozens of different databases or middleware. And in case, they don't need to worry about adhere to dozens of complex integration "standards." The needs for customization is very little. They just need to focus on scaling their apps to tens of millions of users and requests per day, way beyond the imagination of any enterprise can possible need. J2EE is created by tools vendors and their friends (system integrator) pretty much for the enterprise application outsourcing market.
  35. While the authors raise this important issue, we must understand that eBay and Google apps are not "enterprise apps" ; they are self-hosted consumer oriented apps. These apps have very different requirements than those addressed by J2EE.

    Most of the J2EE are actually focusing on flexible customization, configurations and integrations. That's why we have all these arcane XML configuration files around.

    On the other hand, eBay and Google are installed on their own servers. There is not too much need to worry about supporting dozens of different databases or middleware. And in case, they don't need to worry about adhere to dozens of complex integration "standards." The needs for customization is very little. They just need to focus on scaling their apps to tens of millions of users and requests per day, way beyond the imagination of any enterprise can possible need.

    J2EE is created by tools vendors and their friends (system integrator) pretty much for the enterprise application outsourcing market.
    Agreed for the most part though I'd push back a little on the "not enterprise apps" statements. There is integration to do between systems at the back end and all the more so once you start offering external API's for developers. Betfair is a fine example of such a situation and we'd love to have fewer integrations to worry about but we expect the number to grow. Dan.