Gartner: Application Server or Application Platform Suite?


News: Gartner: Application Server or Application Platform Suite?

  1. ZDNet has an excellent excerpt from recent Gartner research on the topic of of buying into an application platform suite (all the productivity products and 'enterprise editions' vendors build and bundle around their application servers). The writeup articulates well the factors pushing the growing trends towards developing with APS's in addition to, or instead of appservers.

    Check out Application Server or Application Platform Suite?.

    What do you guys think about this? Although today most of us code to the J2EE standards, one trend I've noticed (which is lightly touched upon but related to this article) is the growing trend towards application-level programming models/platforms that are built on top of J2EE. Vendors are building this in response to the growing complexity of J2EE and also as a differentiator.

    At lowest level (low in terms of closest-to-j2ee itself), this manifests itself as open source frameworks that abstract J2EE complexity, at the highest level we see this happening with things like Weblogic Workshop, Coldfusion MX, and propietary integration suites that deploy onto J2EE appservers (or generate J2EE code).

    Will we even be coding to J2EE in 4 years or will we (in an ironic twist of fate) be coding to vendor specific application-level programming API's that happen to be built on top of J2EE?

    Threaded Messages (15)

  2. Personally, I am not found of the APS idea. As the article indicates at the end, the one-stop-shopping is as much (if not more) a sales tool than a technology tool. When a vendor says you can buy your app server, content management solution, and e-commerce server right here, it is about grabbing customers, not about providing the best end-to-end solution.

    From a buyers perspective, I think many purchasers buy into the "cost savings benefit" that APS appear to offer. I say "appear" because these solutions often turn out to be less of a bargain than they first appeared. I have seen APS solutions that are piece-mealed together, where maybe part of the package is solid, while others parts are half-baked -cooked just long enough to get out the store and into the sales portfolio.

    I prefer the best-of-breed approach. Settle on a good app server as your base and plug in (or roll your own) solutions on top. More often than not, there is a good third party solution out there you can plug in to the rest of you apps fairly easily, be it through open Java APIs, web services, what ever. I think the days of vendor lock-in in the J2EE space are still far off. And one more thing about choosing your app server - don't be afraid of the little guys (Resin, Tomcat, etc). If all you are doing is servlet/JSP - these should be just fine. There is too much WL/WAS overkill going on out there.

    Finally, the article also says "Best-of-breed offers minimal integration between the component parts and requires advanced technical skills on the part of the project developers". So what! Don't you want to spend your money on talented people, not expensive software. These are the people who are going to be solving your big issues, not the commercial support people - I know this from experience, as I sure a lot of others do, too :-)

    My $.02

  3. I think if a company could get away with paying for expensive software and paying fewer extremely highly-skilled workers they would. Microsoft has proven this time and time again with their networking solutions. It's not as nice as a Unix solution, but your people don't have to be super-Unix gurus.

    I think the APS idea will work in larger corporations who are able to create the necessary division of labor. A handful of J2EE admins, a slew of JSP/Bean developers and a budget that can handle 20 production J2EE servers.

    For instance, WebLogic's Portal solution might be a good solution for larger companies that are able to put this in place and actually need a highly integrated stack. I don't think small/medium-sized businesses writing web-based applications will need more than Tomcat.
  4. APS and Standards?[ Go to top ]

    With increasing number of components in the "APS" the issue is fast becoming that standards for these components are not appearing fast enough to ensure that a developer can "swap out" components of the APS for another vendor.

    Increasingly the vendor's are "locking in" customers through the stack. One of the big benefits of J2EE and Java was choice, this approach undermines that benefit.

    The APS is not all bad, it does simplify things.
  5. It depends. It depends on whether companies want to pay for dedicated, proprietary J2EE++ admins, similar to Oracle DBAs. Because that is what it will take to make sure these stacks run smoothly. You can't teach everyone in your organization the entire stack as well as have them develop.

    I think people will be backing off of the full J2EE/EJB solution, and using Tomcat and lighter servers. The large vendors are depending on you to

    1) Use their EJBs.
    2) Develop your JSPs on top of their EJBs.
    3) When their too-generic frameworks run incredibly slow on the production server, buy more production licenses from the vendor

    As Java Server Faces matures, there will be an option for people to develop using vendor tools, but be able to deploy using standard processes and servers.

  6. In my view, the J2EE approach has always been standards compliance and mix-n-match application usage. You get lots of control and can buy as much or as little as you want. Microsoft always pushes the "Everything you could ever want in one SETUP.EXE" approach, that is about simplicity of selection at the cost of getting complete vendor lock-in.

    So, if BEA or somebody suggested to buy their "platform", I would say that MS is years ahead of them, and that they are making a big mistake. The "platform" is J2EE, and I agree with the first poster that these "platforms" are mostly about revenue generation and not about appropriate solutions. Can we say "stack creep"?

    Add to that that many of these so-called integrated platforms are the result of acquisitions or other hastily prepared products, and the alleged seamless integration is not so seamless.

    As far as APIs "built on top of J2EE", that pretty much eliminates the big advantage of J2EE as a standard. I mean, every Windows program is "built on the open standard of Intel assembler code", but that's hardly a selling point.

    The whole "J2EE Application Platform" approach is just a way for the various vendors to differentiate themselves on things other than what's important: performance, support, and ease-of-development.

    So, it loses on both ends: PHBs will just as soon go with MS, if they are worried about end-to-end integrated uber-packages, and developers will be squeamish having to use technologies that are overkill or inappropriate to the problems at hand.
  7. As everyone has pointed out to some degree, all that is driving this is the urge to re-verticalize and lock customers in.

    But there's another point as well. "Will we be coding to EJB in 4 years...?" No, we won't: but only because the endless process of inventing "higher" layers of abstraction is not likely to run out of fuel. The same cycle keeps repeating over and over again, because complexity in software is like crude oil in your back yard. No matter how much you pave over it, it will still keep bubbling back to the surface.

    Every time we say, "Wow! This-or-that new abstraction layer means I don't have to count sand any more! It frees me up to concentrate on what's really important!", then within two years "what's really important" turns back into "counting sand" when the NEXT higher level of abstraction is discovered.

    I have a hunch that this is because we haven't yet discovered the right things to do with complexity. It is still like the air bubble under the bumper sticker: all we can do is move it around, or break it up into smaller bubbles. We don't know how to drain the bubbles.

    EJBs are great compared to CORBA, which was great compared to RMI or RPC, which was great compared to whatever proprietary hack any of us worked with before that, which was great compared to the lesser hack the preceded it, etc. etc. etc.

    But I still don't want to write EJBs, because most of what I am doing is taking my requirements and turning them into wallpaper for a container, and that's not a good use of my time. I shouldn't have to care about containers--ANY containers, be they J2EE APSs, or plain J2EE appservers, or the COM infrastructure, or the .NET infrastructure. When someone says MY container is better than YOUR container, I don't want to hear it. Tell me I don't have to care about either one of your d!mned containers any more, and THEN I will perk up and listen.

    Progress is progress but there seems not to be a light at the end of this tunnel. I think we are going to have to exit the tunnel at right angles to make REAL progress.
  8. Ultimately, I like the idea of vendors developing tools. I don't mind if they want to bundle them with app servers. I don't want to see them tied.

    Oracle and TopLink for instance - I don't mind that you can get TopLink with Oracle 9iAS, but I'm happy to see that I can get TopLink either way.

    Do they want to leverage the sales of one against the others? Absolutely. Do I blame them? No. But when it comes down to a tool that's only available on one application server, that's vendor lock-in, and gets annoying really quickly.
  9. IMHO, it is true that future of application servers is tightly coupled with EAI. People who have developed applications on top of J2EE specification want them talk to each other.
    It is also true that the same people want to watch their applications running and provide QOS to their customers.
    What is wrong is to answer those needs with proprietary stuff.
    Future of applications server is in standards.

    Only standards could provide the time to technology to become mature.

    If you haven't time, take some proprietary solution, keeping in mind that you will throw it away in a couple of month. If your goal is to keep your applications, EAI, portal (...) for a while, then avoid using proprietary solutions (even internal)

    This future is under construction with specs like JMX, WebServices, JavaFaces, JSTL...

  10. Providing different tools with Application server is good. If that goes to extent of vendor lock-in then there will be no difference between microsoft and J2EE vendors.
  11. The following trends / tendencies will result in eventual MASS adoption of far-reaching platforms(aka nervana!)....

    1. Many areas of IT have not been "standardized" yet. J2EE primarily addresses API's and component models for developing distributed OLTP and Reporting/Query Applications. Analytical, ERP, EAI, B2B, and Business Process Management/Optimization applications are all un/under-standardized. Platforms will advance this trend.

    2. While EJB/J2EE can be used across many application-types it is not efficient from a development standpoint. Until Applications can "think on their own" advances will continue to be made in developer productivity -primarily through Runtime frameworks that support higher level abstractions and more dynamic behavior. -NOT CODE GENERATION.

    3. Murphy's and Moore's Law will always make sure Features, Flexibility and Robustness are more important than performance.

    4. Economies of scale are maximized by complete standardization -even when they are only defacto, vendor standards.

  12. Hi Matt,

    > advances will continue to be made in developer productivity
    > -primarily through Runtime frameworks that support higher level
    > abstractions and more dynamic behavior.
    I don't understand what's wrong with code generation. You agree that it's all about increasing productivity, while continuing to work with open standards, right? Well, what's wrong with generating code using an MDA tool that allows you to edit/exchange the transformation process itself? You can also standardize transformation processes instead of APIs, not?

    Could you give an example of what you mean with a runtime framework and on which aspects it is better than a framework that statically translates abstract concepts into lower level ones?

  13. <quote>
    Could you give an example of what you mean with a runtime framework and on which aspects it is better than a framework that statically translates abstract concepts into lower level ones?

    The main problem with tool-based code generation is that all decisions are made at generation-time. this means it is not possible to optimize at deploy-time or run-time. Also, Generated code is usually supported and maintained by the customer and not by the vendor. This defeats a key advantage of buying a product -less code to support.

    The superiority of runtime frameworks (even those with generation and compilation steps) vs. development-time code generation is pretty clear if you look at successful "abstractions":
    OS's don't generate assembler based on application code.
    JVM's don't generate C code based on the Java.
    The JSP model requires the generation of Servlets but this process is done entirely by the runtime -not the designtime tools.

    As for runtime generation, it is not ideal either but much better than designtime. Another example, The weblogic workshop framework, does a good job of providing a very powerful level of abstraction but limited code generation.

    does this help?

  14. does this help?

    Yes, thanks a lot for the insights.

    I've thought about the limitations of runtime frameworks. I believe that runtime frameworks tend to keep you within one platform. If we use the term platform for an "enterprise platform" (like J2EE, .NET, CORBA) here, we do see runtime frameworks for the web- layer and application layer within J2EE (eg. resp. Stuts and WL Workshop's framework), but no runtime frameworks that are "platform independent". It was in fact the purpose of both the CORBA and J2EE platforms to be "platform independent", but history has proven that it is next to impossbile for enterprises to standardize on only one such platform, moreover enterprises need to interoperate with other enterprises' platforms. (Last sentence was based on Richard Soley's document on MDA :)

    On the other hand, you can use an MDA tool that allows you to specify a "platform independent" model (be it for the web or application tier) and generate the skeleton code for any platform. Another thing that MDA tools aim to do is generate the integration code between different platforms, something I think is not the purpose of today's runtime frameworks. This approach is indeed a bit like a JVM that would generate C code from the Java...

    So what would a "platform independent" runtime framework look like? Is it something in the web services corner? Anybody any ideas? I think a concrete example would be that both Microsoft and the J2EE appserver vendors would build an EDOC interpreter on top of their platforms... however somehow I get the feeling this screws the MDA idea as in this case MDA would be "the next best thing" whereas the original idea was to put the emphasis on the pluggability of the mappings between component models, NOT on a new component model. Anybody out there with another idea on the goals of MDA/code generation/runtime frameworks/transformation extracters/...?

    Kind regards,
  15. I believe that runtime frameworks tend to keep you within one platform if we use the term platform for an "enterprise platform" (like J2EE, .NET, CORBA) here.

    I do not want to generalize "tend to keep you within one platform" to the lower level of OS platforms as we've got the JVM here. J2EE wanted to the the same for application servers and as I said we could build an EDOC VM layer on top of it, but I think this story has no end. That's why I think the code generation approach from MDA tools I described above is more robust: you can plug the transformation mechanism for new platform requirements... although you could also adapt the EDOC VM for new platform requirements, but doen't seem to be the way industry is moving.

    Another thing that I am looking at in my research are the layers above EDOC...

    Kind regards,
  16. Code Generation vs Dynamic Framework[ Go to top ]


    I totally agree with a lot of what you wrote, especially about the inefficiency of code generation. To some extent I would push this to the run-time level where automatic code generation is more hidden, but still often brittle and inflexible.

    I have some bias on this topic given my background. I am one of the founders of the Open For Business Project. We started out two years ago with a code generator that used and XML entity descriptor file and generated all sorts of handy things include Entity EJBs, XML config files for containers, simple JSPs that could be used as a starting point for apps, and so forth.

    When we got the code generator and initial data model in place we had over a million lines of generated code. This was a nightmare. It was a LOT faster than maintaining the EJBs and corresponding config files by hand, but still tedious and slow to generate, compile, and deploy.

    So, some enlightenment struck and we moved to a totally dynamic run-time library based on JDBC and JTA that doesn't use Entity EJBs at all. We call it the Entity Engine.

    It started with the same XML files (based on some of the EJB config files) that we used for code generation and we added the idea of a GenericValue object and an API for querying, inserting, updating, removing, local caching, etc, etc. We have also introduced ideas similar to database views for even more flexibility and that also adds the ability to do things like joins, grouping, summary functions, etc.

    Changes to entities/tables require minimal modifications and no rebuilding. You just change the entity model XML file, and then go directly to the step of working on your application logic.

    Yes, we lose the ability to have a compiler watch our backs, but that has proved to be well worth it given that this approach is less error-prone and so much less work.

    All of this, including many other related framework pieces are available as open source code (MIT license) in the Open For Business Project (see, or

    After experience with hand creating Entity Beans, using a code generator to create entity beans, and now using the Entity Engine for more dynamic database interaction I would never turn back. You can even use it in the same transaction as Entity EJB based code because it uses JTA transaction management.

    We also have other pieces that have helped a LOT with efficiency and modularity, like a service based architecture for logical components that are inside the application, as well as components that are in other applications or on other machines. We call this the Service Engine, and we have a WfMC/OMG compliant Workflow Engine that makes heavy use of its facilities to provide management of automated and manual tasks.

    I agree that vendor application frameworks that are not standards based can really end up biting you back, but that doesn't mean that open source alternatives are not viable options.

    We don't have a J2EE application server or other components to sell (heck, we don't sell what we do have...). That frees us up architecturally because we are not trying to justify what we are asking you to spend on our EJB container, especially the cost and complexity of the CMP Entity EJB part of the container. I doubt many J2EE app server vendors would adopt the use of a dynamic database interaction API for this reason, in addition to all of the reasons about being non-standard, poo-pooed by Sun architecture ideals, etc.

    In the REAL world on the other hand, it is hard to justify architectures that require more time to deal with than it takes to design what you will be building.

    So, once again, I liked your points and I wanted to let you know that we have very successfully been able to put those ideas into action.

    -David Jones