Discussions

News: New Article: High-Performance Alternatives to J2EE

  1. J2EE gained great prevalence as a design pattern in the early part of this decade. To a great extent its popularity coincided with an increase in Web applications. As the successor to C++, it also found use in non-Web apps that could be heavy on general processing, calculations, and transactions. But its use there has been somewhat limited because of requirements for very fast complex transaction processing. Read the Article

    Threaded Messages (23)

  2. Next..[ Go to top ]

    My guess is that D, is a likely. I think it's more likely than Python or Ruby or Php or Mono.
  3. J2EE [...] As the successor to C++
    J2EE a successor of C++? If you'd possess a more logical brain, you would likely solve your problem without finding an alternative to J2EE.
  4. Huh?[ Go to top ]

    Did the summary pass through a reality distortion field? My mind's sense of self-preservation prevents me from RTFA, so somebody enlighten me.
  5. More accurate article summary[ Go to top ]

    Grids are becoming more popular.
  6. J2EE gained great prevalence as a design pattern in the early part of this decade. To a great extent its popularity coincided with an increase in Web applications. As the successor to C++, it also found use in non-Web apps that could be heavy on general processing, calculations, and transactions. But its use there has been somewhat limited because of requirements for very fast complex transaction processing.
    XTP systems don't always need "fast" processing. What they need is to be able to handle very large numbers of concurrent transactions, with the ability to scale the system as the load increases. This is the ideal case for commodity hardware-based grids if the load is partitionable, which fortunately applies to most applications. The result of being able to scale as necessary is that the typical transaction does tend to be fast, but the inverse isn't true: making the system faster wouldn't necessarily help it to scale significantly. From a "queue theory" point of view, most systems that are slow under load aren't by their nature slow systems, but rather are systems that cannot scale sufficiently. One of the fundamental goals of XTP is to help customers architect and build systems that scale in a predictable manner, thus avoiding this problem. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  7. There are quite some improvements needed in JEE (including adding OSGi support), but the reference article does not point out the real achievements of JEE and the shortcomings.
    A typical design means you establish an EJB object which talks to the EJB's stateless session bean which in turn talks to another EJB object which talks to a stateful or entity bean, for example,"
    There is nothing in JEE that requires N level of (pseudo-remote) EJB calls. If you want to insert 10.00 rows per second into your database, you might want to use JDBC directly and not Entity Beans. However, I agree that there is a problem with JEE _education_ and _training_, were patterns are pushed too much without explaining in which context they should be used and not used. This also points to a valid JEE problem: The smallest deployment unit is an EJB, so inter-component-communication (component = deployment unit) is always (as written in the article) via remote calls. That severly limits the way application can be splitted into components. Therefore: JEE should support OSGi! (towards the JEE app developer, not only internal in the container, as done today). BTW: It is unclear to me how grid computing would help with this problem.
    So each time you are going through different layers, and if those are truly distributed in a clustered environment you have serialization and other things [with which to deal].
    Agreed, especially for truly distributed. But what is the alternative? Distribution without serialisation? Distribution without security checks for incoming messages or calls? Distribution without carrying the user and internationalisation context form one node to the next? As written just recently here: use distribution only when its needed. That applies to EJB, too. I would claim that JEE is suffcient for 90% of the cases. I might agree that there is a space for low-latency containers. However, missing performance (in transactions per second) can be catched by scaling horizontal and vertical, and that is one point where JEE delivers: Follow the JEE rules and your app scales. Most CORBA applications and most JSE applications that I have seen failed on scalability. As also virtualisaition was mentioned: Yes, there is an interesting overlap, but IMHO not as indicated in the article. The overlap is not with the JEE standard, but with the existing JEE app servers: If I can easily copy a VM by copying files, how does that integrate with the app servers? I would expect that JEE app server management consoles get much simpler with virtualisation in place. * Stefan Vaillant
  8. Scalability of JEE/EJB[ Go to top ]

    Most CORBA applications and most JSE applications that I have seen failed on scalability.
    I think that scalability is primary a design issue. What you need is a design that suits your domain. The technology you use comes second. In fact I have seen many JEE applications that don't scale well.
  9. This also points to a valid JEE problem: The smallest deployment unit is an EJB, so inter-component-communication (component = deployment unit) is always (as written in the article) via remote calls. That severly limits the way application can be splitted into components.
    This is why JEE in particular and tier-based architectures in general are inherently unscalable beyond a certain small number of machines. To enable scalability across hundreds to thousands of nodes, it is necessary to co-locate the business logic, data, and associated messaging for an end-to-end instance of a use case in a single, lightweight container (aka a processing unit). This approach scales nearly linearly across a broad range of hardware resources because each processing unit is independent. Naturally this requires careful partitioning of the solution.
    So each time you are going through different layers, and if those are truly distributed in a clustered environment
    >you have serialization and other things [with which to deal].
    Agreed, especially for truly distributed. But what is the alternative? Distribution without serialisation? Distribution without security checks for incoming messages or calls? Distribution without carrying the user and internationalisation context form one node to the next?
    In a grid environment, the solution is to minimize or eliminate inter-component calls. The focus should be on improving end-to-end performance, scalability, and resiliency, of a business use case. Dealing with each tier individually allows only for limited optimizations. Encapsulating the use case and making it the unit of scalability has the added benefit of making it the unit of failover as well. Instead of having different recovery mechanisms for each tier or component, the grid system can simply start another processing unit, typically configured as a hot backup.
    However, missing performance (in transactions per second) can be catched by scaling horizontal and vertical, and that is one point where JEE delivers: Follow the JEE rules and your app scales. Most CORBA applications and most JSE applications that I have seen failed on scalability.
    I agree with the last sentence, but I haven't seen JEE scale well beyond eight boxes collaborating together. Running more application server instances is, of course, possible, but requires additional components to route and schedule work units. This is equivalent to building a grid with very heavyweight nodes and significantly more complexity than a compute grid normally requires. Patrick May GigaSpaces Technologies Inc.
  10. I agree with the last sentence, but I haven't seen JEE scale well beyond eight boxes collaborating together.
    This begs the question. Why would all those boxes be "collaborating together"? Unless of course someone tried to use the platform as a grid computing platform. Java EE architectures is designed for traditional business applications were corporate data is pulled for traditional transactional data repositories (database, messaging). Developers have a hard enough time today getting their systems to be transactional correct and that is with simple client-server-resource access paths. How would anyone comprehend/test/manage such a beast? I doubt there is a sufficient number of developers on the market that could implement complex distributed algorithms. You can scale the runtime with grid computing but can you scale the minds that need to manage it. Kind regards, William
  11. My answer is usually this: if you know how to write multi-threaded code – you already know how to write applications for grid (at least for GridGain that is). Skill set is not much different and many algorithmic ideas are the same. There are caveats here and there – but overall this is pretty similar. As far as JEE I think grids and JEE are perfectly co-existing. Just remove EJBs from the picture and in most cases you get a perfect host for a grid node. We have plenty (I would sat majority) of the customers running GridGain within JBoss or Glassfish or Tomcat. JEE container acts as sort of “operating system” that provides all necessary services to applications and GridGain is just another add-on to it. I think we again over generalizing and throwing JEE out while it has perfect place and time to be. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  12. Hi Nikita, When I hear "collaboration" mention in the context of distributed architectures (the grid) I am not thinking of just task provisioning, deployment, and execution but more so co-ordination & control which are usually formed out of base primitives offered by grid computing products such as GridGain. The current grid products are enablers but one still needs to understand how to match grid capabilities with possible solution designs that solve business problems or meet business needs - logical design and physical awareness. By the way what is so bad about Java EE EJB? When a grid is transactional aware it does help with the programming model and every other lightweight container today is offering similar component types anway. Kind regards, William
  13. Hi William, Nothing wrong with EJB3 (I actually like them quite a lot). It's just that in a grid environment it is usually hard to them because of the container's management... But I think we overall are on the same page here. Best, Nikita. GridGain - Grid Computing Made Simple
  14. Java EE architectures is designed for traditional business applications were corporate data is pulled for traditional transactional data repositories (database, messaging). Developers have a hard enough time today getting their systems to be transactional correct and that is with simple client-server-resource access paths. How would anyone comprehend/test/manage such a beast?
    William i think that your touching the right point. So far only few tried to address the question: How do you apply the concept and idea from distributed computing to mainstream transactional systems? Another point that i found interesting on that regard is that in many cases the discussion was centered around API i.e. how do we change our API's to use those new concepts. I've been spending large part of my time in the past year trying to address this questions and basically came with set of suggestions of how to apply the concepts from distributed computing to mainstream applications without exposing *major* API change. The last post on this matter is Moving to Extreme Transactions Processing using Lean methodology The general idea is that we can apply most of the changes into the underlying middleware implementations and not to our applications code by reimplementing the way our messaging and data layers works as well as how we invoke our services (Session beans). For example we can use Remoting to abstract our client application from the fact that it interacts with groups of servers and not a central one - this knowledge will be kept within the remoting proxy not our client code. We can do the same to our JMS Queue i.e. we will send messages to the queue is the same way we do today but the underlying implementation will use a partitioned queue to ensure scalability. Obviously abstracting the data tier is more challenging and quite often would require some level of changes to our code but things like JPA abstraction as well as declarative transactions etc helps to minimize the scope of changes in that tier. So to make a long story short i think that the challenge is to bring the concept and values of grid/distributed computing methodologies into mainstream JEE applications more then it is to bring those applications to the grid. There are enough *real life* references today that illustrates how this can be done. HTH Nati S. GigaSpaces
  15. Patrick -
    This is why JEE in particular and tier-based architectures in general are inherently unscalable beyond a certain small number of machines. To enable scalability across hundreds to thousands of nodes, it is necessary to co-locate the business logic, data, and associated messaging for an end-to-end instance of a use case in a single, lightweight container (aka a processing unit).
    Just for kicks, could you explain in technical detail why a tiered architecture is "inherently unscalable"? Having replaced several "space based architectures" in the past year because they didn't scale, I'd be glad to discuss the pros and cons of various approaches. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  16. I think the are a lot of misconceptions here. JavaEE is just a programming model for deploying units of business logic in a cluster. It does scale. I can make a JVM with a JavaEE application deployed and scale it as far as the implementation allows. Path length concerns about EJBs are becoming less relevant now as even with Spring based containers, the Spring path length is also a concern as it's doing many of the same tasks at the vendors JavaEE containers but it hasn't been through specjapp a billion times so it usually is slower than the vendor containers doing the same thing and I'm not starting a flame war here, Spring is going to get faster so it's a point in time statement. But, as programmers want managed components even for POJO applications, this path length will stay, it's not going away. So, given there is nothing inherently unscalable about JavaEE why doesn't it scale for ever? Well, shared resources like databases and message queues and the vendor infrastructure hosting the JavaEE applications. But, that has nothing to do with JavaEE, this is the nature of the shared resources/infrastructure. If you used JavaEE with a Coherence/ObjectGrid/Giga what ever then so long as the backend can scale, so will JavaEE as longs on the JavaEE implementations infrastructure also scales and even then, multiple cells etc can be used to scale out. It's possible to use a single ObjectGrid embedded in multiple ND cells and thus scale out effectively until ObjectGrid won't scale anymore which is a lot of servers. So for me, this drum has been banged on enough. I don't think it's interesting anymore. Plug in a scalable backend and there is no reason JavaEE doesn't scale with the backend.
  17. A New Kind of TSS Interview...[ Go to top ]


    Just for kicks, could you explain in technical detail why a tiered architecture is "inherently unscalable"?

    Having replaced several "space based architectures" in the past year because they didn't scale, I'd be glad to discuss the pros and cons of various approaches.

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java and .NET
    Try this one on for size... How about a new kind of interview format where two or more competitors go at it in a technical debate. The goal is to have a rigorous discussion over a specific topic of which the participants are recognized experts. So, how about it? Oracle vs. GigaSpaces: Space-Based Architecture in Practice. Hmmm?
  18. Having worked with server-side Java since the late 90's - before it was all codified under the JEE umbrella - the one consistent thing I've seen is this: 1) JEE adapts to trends in the industry. 2) The initial version usually has serious performance / scalability issues and one or two severe funcational flaws. 3) The developer community rallies around the technology with work-arounds, which get codified into a point release. 4) By version 1.2 - it's not half bad. Most Recent Example - JSF. N-N: If Grid computing takes off, a future JEE version will overlay it in a way that still takes advantage of the portability and elegance of a container-based architecture. Just my .02. GJB
  19. The overall gist of the article is: grids are getting popular and EJB are generally bad. I mean literally that’s all it says. It would be revealing like 5-6 years ago but it reads fairly outdated today. No offence to the author or TSS editor, but I personally dislike the over-generalized wide-brush strokes of someone’s brain tapestry. My biased opinion, Nikita Ivanov. GridGain – Grid Computing Made Simple
  20. mutually exlcusive[ Go to top ]

    agree with Nikita, does this article have a single sentence of relevance or significance to the burgeoning debate on what to do with "grids"...big deal, u can scale, am i missing something that has not been assumed for some time now, and was not pre-set in to the constructs of the JEE platform?.... i am just tapping my fingers waiting for some anti-EJB person to come on here and declare that the future is devoid of programming techniques that have been assumed by the Java community, have been implemented by the Java customer base, and have achieved the vaunted goal of 'legacy' status... IMO, the banal efforts to promote an anti-EJB bias, as propagated by the Spring diehards has left a dearth of serious analysis of where to take the thousands of customers who have invested in JEE: rip-and-replace with the Spring Framework is what we hear, they are "funded" and are the "de-facto standard"... de jour technologies are fun, exciting, and important, but are not the sole contributor to moving forward with next-gen implementations, standards are what Dilbert bosses and wise developers bet on, making a mockery and a distinction of EJB and non-EJB apps is simply the most myopic and biased incarnation of an effort to discredit the decade-long effort to unseat, or at least complement, the MSFT hegemony of programmer practices.... a serious analysis would begin to move beyond religion and take in to consideration how politics of change do not move that much...revolutions happen, but evolutions develop, i'll bet on the latter...
  21. Re: mutually exlcusive[ Go to top ]

    IMO, the banal efforts to promote an anti-EJB bias, as propagated by the Spring diehards has left a dearth of serious analysis of where to take the thousands of customers who have invested in JEE: rip-and-replace with the Spring Framework is what we hear, they are "funded" and are the "de-facto standard"...
    Very well said indeeed! Looks like spring is finally over and summer (of JEE/EJB3) is here...Hey where is my Guice ;)
  22. Re: mutually exlcusive[ Go to top ]

    I totally agree. It is a relief to occasionally hear sense being spoken above the babble of the Spring zealots. I've been using Spring on a recent, and protracted, contract and it can be painful to use. I certainly can see where Spring has a useful function complementing Servlet/JEE apps, but when the zealots get involved and use it to *replace* JEE, then it can get messy. Overall, it really proved no easier than J2EE in the amount of xml that needs to be shoveled about, never mind JEE. And Spring's use of unchecked exceptions? The Horror! That's added weeks of expensive debugging work for me alone. We went the Spring/Pojo route and have spent a LOT of time inventing our own failover & caching strategies that would have been automatically available had we used EJBs and the buit in replication features of app servers, including the good old EntityBeans (and I never thought I would say that!). We wrote a lot of concurrent code (which I really enjoyed, but was hard hard work) to handle a very asynchronous design that would have been a no-brainer using JMS and MDBs. I can see how the Spring/Pojo approach is much easier in a simple standalone web app, but when creating a mission critical app with failover and high availability requirements, pojos just don't cut it. There are so many tricky little edge conditions that you can't anticipate until late on that you end up having to make compromises. The funniest thing of all has been watching the project evolve its own OSGI/Spring based app server; painful, refactor-heavy, and time consuming. A waste of valuable resources IMHO. Not going the JEE route from the outset has quadrupled the duration of the project and inflicted an expensive, specialized maintenance toll for the future of the product. A project highlight was when a lead architect was giving a presentation about the benefits Spring had brought to the project. These included no J2EE and no Tomcat, totally missing the fact that we were running a SOAP stack via Servlets via Jetty. We just don't use EJBs, that's the only real difference. This was from an otherwise outstanding and experienced Java developer. It just highlighted the amount of confusion and misinformation being stirred up by the anti-JEE stakeholders. They seem to conflate JEE with EJBs. Anyway, I have a wheel that needs re-inventing...
  23. This happened before[ Go to top ]

    The developments from Corba, EJB to grid reminds me of an early period of my carreer. As I read about grid, cloud, space etc.. I recognize architecture elements I saw before. I saw them 20-30 years ago in the design of telephone exchanges. The biggest challenge for these exchanges was how to respond to every end user event (off hook, dial, etc..) without delay, and without loosing track of the state for every involved component (line, trunk, switch, etc..). The solution at that time was objects communicating via asynchronous messages, which drove finite state automatons modeling these resources from state to state, and carrying out some task (switch this on, remember that) at each such state transition. With the development in electronics these architectures moved from a single central computer to hundreds of processors (every line card was one). The software moved along and we had distributed message delivery mechanisms and distributed database like mechanisms. Configuration was the big thing; it decided what logic and data was to be loaded up to each embedded computer on the electronic cards of the exchange. There were also external synchronous systems these exchanges were hooked to. These icluded systems for billing, statistics, reconfiguration, monitoring as well as systems used to develop, test, and debug the exchange software. Todays web browsers, financial client GUI's are the equivalents of those days black phones. Todays servers are the equivalents of those days CPU cards, line cards, operator desk interface cards. The messages exchanged will be different in size and vocabulary variation but essentially the same. The data kept in each processor will be different in magnitude and complexity but will meet the same architectural needs and follow similar patterns. We have now a larger set of synchronous systems to interface to, but then some interface standards as well. We will also meet similar development, testing and debugging challenges. Anybody else with a similar deja vu? Any lessons already remembered?
  24. Quotes[ Go to top ]

    Nice article about quotes...