Article: Sun Enterprise Java Application Verification Kit


News: Article: Sun Enterprise Java Application Verification Kit

  1. The Java Verification Program checks enterprise applications to make sure they are compatible with various J2EE-compatible application servers. It also tests the portability of applications from one application server to another.

    This article discusses its Java Application Verification Kit (AVK) for the Enterprise, showing us what the kit contains, and how it works.

    It also dabbles with what J2EE portability means, and how to obtain it.

    Read Suns article: Portability Verification of Applications for the J2EETM Platform

    Will many people jump to have the "Java Verified Enterprise Application" stamped across their app?

    Threaded Messages (18)

  2. Benefits of portability[ Go to top ]

    One of the most important benefits offered by the J2EE platform is application portability. A couple of the benefits of portability include:
    - Development can start early: The development of an enterprise application can start before a J2EE implementation has been chosen. The code should be portable to any J2EE application server, at zero-cost.
    - Freedom of choice: If you decide to switch to a different J2EE application server after several months into production, all existing code should run on the new J2EE application server, again at zero-cost.

    Portability is certainly a bonus of J2EE. We don't want to be locked into a vendor forever. And Sun are doing a service by making tools available to check for spec compliance. (Including the J2EE Reference Implementation verifier, which is quick and simple.)

    However, the text quoted above perpetuates some very harmful myths. The idea that "all existing code should run on the new J2EE application zero-cost" even well into a project is laughable, for example. And I've seen so many unpleasant tradeoffs in projects where choice of app server was deferred out of belief that it doesn't matter. It matters a lot, unless you don't care about performance, clustering capability, operational support, efficiency of data access... In short, if it doesn't matter from the outset of the project what app server you choose, you don't really have an enterprise application. Deferring application server choice is such a "worst practice" I can't believe that Sun are actually promoting it as a valid choice.

    In Expert One-on-One J2EE Design and Development, I take a more pragmatic and realistic look at the benefits and cost of portability.

    What people want is J2EE applications that work, not inferior, inefficient, lowest-common denominator applications. Portability is
    - an insurance against monopoly by a single vendor
    - a business requirement for a minority of applications that need to run on multiple app servers.
    Portability should not be an article of faith that encourages severe tradeoffs in many projects.

  3. Benefits of portability[ Go to top ]


    I absolutely agree on your opionion about the little relevance of protability in projects. Still you might want to look at the portability aspect from the point of view of a J2EE component vendor. Don't you think it is a major aspect then?

  4. Benefits of portability[ Go to top ]

    Agreed, portability is a major issue for J2EE component vendors. However, in my experience the J2EE component market has lived up to expectations, so isn't as large a part of the picture as many imagine. Also, many component vendors find portability too difficult. Most I've come across with will have 1, perhaps 2, servers they support. And they'll usually insist on one backend, such as particular RDBMS.

    Interestingly, portability between web containers is usually straightforward. It's where the EJB tier is concerned that things get messy. So, for example, portability is a reality for JSP custom tag libraries.

  5. Benefits of portability[ Go to top ]

    oops, meant to say "in my experience the J2EE component market HASN'T lived up to expectations"...
  6. wham!!![ Go to top ]

    "...if it doesn't matter from the outset of the project what app server you choose, you don't really have an enterprise application."

    This is the single most savage and outright dismissive indictment of the J2EE platform that I have ever seen, counting all of the incoherent fulminations of the Microsoft partisans.

    I will paraphrase:

    "...if it matters from the outset which vendor you have to lock into, you don't really have a mature platform."

    Avoiding vendor lock-in is enterprise survival, nothing less. If you are locked into a vendor, then you don't own your company any more.
  7. wham!!![ Go to top ]

    No, I don't advocate lock-in, just a bit of realism about the degree to which we need to use vendor-specific features, and the lesson (that I've seen borne out in several projects) that if you defer your app server choice on any but trivial projects it costs big bucks. In my book I advocate lots of ways, such as hiding vendor-specific details behind interfaces, to avoid lock-in, while still leverage useful proprietary features.

    "If you are locked into a vendor, then you don't own your company any more."

    This is paranoia. As I've said I don't advocate "lock-in": just the acceptance that 100% code portability isn't realistic, despite Sun's claims to the contrary. ("Design portability" is possible, however.) I'm guessing that your definition of lock-in would rule out any vendor-specific features at all, such as:
    - read-only entity beans (if you're using entity beans): read-only scenarios will offer shocking performance without this, but it's not part of the spec
    - ORDER BY and other essentials that got left out of EJB QL 2.0 but are implemented by BEA and some other vendors

    Imagine you're implementing an entity bean solution using WLS 7. Do you really think it makes sense to sort a massive collection of entity beans when the app server could do it for you much more efficiently with 0 lines of code? Of course you could use JDBC to do it even more efficiently, but then that would be vendor lock in again, JDBC being applicable only to relational databases.

    Portability is not the be all and end all J2EE. Portability is a nice to have that J2EE allows us to have, within certain limits. The extent to which portability is a reality is one of the major advantages J2EE has over .NET. But essentially J2EE should be measured on how well it solves problems, not how portable solutions are. No one will bother porting a sub-optimal solution.

    I too wish that 100% portabiilty was a reality. But it ain't and far too many people waste a lot of money (and end up with inferior applications) because they're trying to prove otherwise.

  8. please[ Go to top ]

    "I don't advocate lock-in, just a bit of realism"

    Isn't this a too hash prescription?
  9. Benefits of portability[ Go to top ]


    While I tend to agree with many of your posts - I get the feeling that quite a few are deliberately over-critical - and one has to question whether this is really your ~balanced~ view - or whether you are taking a more "controversial stance" to plug your book (EVERY post ;-).

    Insofar as moving ~between~ appservers being zero cost - it obviously isnt. Only the most naive would actually believe this.

    However, to say that exercising the benefits of portability is "worst practice" is also not true.

    We have actually had some experience in moving between appservers - in precisely the scenarios you mention, and it was no big drama - definitely not the deathtrap you portray.

    In one situation we had 3 teams that started development on Orion, JBoss and Jonas respectively (while we worked out which appserver we were eventually going to use). After about 2 months - we moved all development to Weblogic. Obviously there were a couple of hiccups in doing so - but, interestingly, some of these actually exposed bugs in our code (ie it exposed developers' misunderstanding about some aspect of EJB)

    The second was a very large project (that I wasnt involved in at all). They did some very large benchmark tests - the app was a Mainframe replacement. They had originally developed on Weblogic - however, they spent something like 2 man weeks moving 2 Man Years worth of work from Weblogic to Websphere so they could benchmark their app on Websphere.

    In addition to this, we currently have a project (led by a couple of experienced J2EE developers) thats been going for a couple of months now, and they are developing on Orion and they will go to production on Websphere. Admittedly, this application does not make heavy usage of EJB (also, they are using Entity Engine instead of CMP) so the bandwidth in supporting two platforms is not excessive.

    SO, while I wouldnt do it for _entertainment_, its certainly quite possible to move between appservers for many projects. For balance, I would say its quite possible on the proviso that at least one or two people on the development team know more than 1 appserver implementation - and can therefore recognise portable solutions to common little problems.

    Another thing is that Portability is not just about keeping preventing your vendor ripping you off. Its also "implementation insurance". With a small amount of effort during development, you can make sure that should you hit a show-stopping problem with appserverX, you can move to another appserver without too much cost and potentially avoid a disaster (something you will agree is unique to J2EE).

    The other thing I take issue with in you post regards using Appserver features outside the J2EE specification:

    A misconception (often promoted by the likes of Roger Sessions) is that such things as clustering and performance are outside of the spec and therefore to make use of these features would immediately tie you to a particular appserver implemantation.

    We both know that in general this view is largely false - many of the appserver features outside the spec are invisible to the code (take Session state replication for example).
    I am also sure that we both realise there IS an element of truth too. For some more demanding applications, the actual appserver implementation can be quite important (e.g. the level of reliability vs performance impact of a given State Replication implementation may not suite the application).

    |if it doesn't matter from the outset of the project what
    |app server you choose, you don't really have an enterprise

    I am fraid this is rather way off - and from an author of your reputation - its rather damaging for you to say so. To suggest that developing portable applications means that you are developing "inferior, inefficient, lowest-common denominator applications" is not really true at all.

    Having said that: I agree 100% with your utlimate conclusion : "Portability should not be an article of faith that encourages severe tradeoffs in projects"

    In the end, I think we probably agree on most stuff - I am just not keen on what I feel is sometimes unbalanced criticism in your posts - I just think its become far too fashionable to be critical of J2EE lately...

  10. Benefits of portability[ Go to top ]


    I think you have put a rather beautifully. I fully endorse your view. Its true that although 100% portability may not be achievable but still J2EE specs at most of the places are very mature in the sense that moving an application from one appserver to other appserver is not all that a big pain. I have also gone through the same scenarios which you described where developers started using different appservers and the app was moved among application servers. For me, so far J2EE specs have given the kind of portability that I would be looking for. True, there is scope for improvement but still, as I mentioned, moving of apps from one appserver to other appserver has not been a big pain for me.

  11. Benefits of portability[ Go to top ]

    I'm forced to agree with this as well. There are certainly differences in App Servers - performance, configuration, different bugs, supported third party products, etc. And any company doing a truly entperprise effort needs to do due-diligence that selected app server meets their scalability, performance, and other requirements.

    But that said - moving from one app server to another means _most_ of your code doesn't have to change. You may need fixes for different bugs in the new server, some changes to get the same performance/latency/scale-up characteristics, and the rather cruel ramp-up in a total different configuration/administration scheme. But still, most of your code is unchanged. You don't just plug your stuff into a new server and go, but you don't re-write from the ground up either.

    If you want a horror story, compare this to the C++ world (on any platform). J2EE isn't perfectly portable, but it's the best yet I've seen so far. My only real beef is that Sun isn't more candid about the costs of moving between J2EE app servers - if they spelled them out, and showed that they exist but are managable, I think they'd get more credability in the long run.

  12. Benefits of portability[ Go to top ]

    I'm working on a pretty big project that requires different builds on different app-servers. I'm using OJB/Struts/Axis, some other stuff. No entity beans since I'm using ORM. I don't have to make any code changes. Some of the deployment files and JNDI stuff is a little different. So I just made an Ant build for each app-server. Took me about 2 hours to do. I want JRun? I type "ant jrun" I want Orion, it's "ant orion."

    Really hasn't been a problem. Now if we we're using EJB's, or app-server specific features it would be a bit more complex I think.

    -Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  13. Benefits of portability[ Go to top ]

    |Really hasn't been a problem. Now if we we're using EJB's,
    |or app-server specific features it would be a bit more
    |complex I think.

    Thats true - the deeper you get into J2EE, the more effort you require to maintain portability. At best, there are more vendor-specific descriptors (or more xdoclet tags) you have to write.

    However, if you compare like-for-like; moving between OJB and, say, Entity Engine, then perhaps the effort required for CMP portability starts to look very reasonable.

    The point I made earlier about portability giving you "implementation independance" is, I think, often overlooked.

    While you dont have "vendor" lockin by choosing (for example) a particular open-source persistance engine (ie theres no vendor), if its not an implementation of a standard like JDO or CMP, then you are locking yourself into _that_ implementation.
    If, suddenly down the track, you find that it doesnt do what you want - you are kinda stuck, unless you feel like writing that feature yourself (and assuming, of course, that you are actually capable of such a thing).

    Now, before anyone gets excited, I am not advocating that standards compliant software is the only software anyone should ever use - we just need to be conscious of the fact that we are limiting our ability to later change our mind when we do this...

  14. Benefits of portability[ Go to top ]


    First, the bad news: these are my real views. While I'm obviously keen to promote my book, I would never post anything here that didn't reflect my sincere convictions. I may not always be right, but I always mean what I say :-)

    I think you've read a lot more negativity into my post than it contained. To address your points in detail:

    - I don't say that "exercising the benefits of portability" is a worst practice: just that deliberately deferring application server choice because "J2EE is portable," as Sun seem to be advocating in the article, is a worst practice. I've seen it have a major negative impact on several projects, including my current project.
    - I don't imply that trying to port apps is a "death trap". These are your words.
    - You seem to have had a more positive experience regarding portability than many architects. However, what you describe is a long way from the portability at "zero cost" discussed in the Sun article. And it was the "zero cost" fantasy that I objected to.
    - I didn't say that we should lock into app servers or that porting between app servers is impossible: just that it isn't free. Actually the link to the book in this case was because I discuss strategies for avoiding lock in in the book.
    - Completely agree about "implementation insurance". Personally I would have grave reservations committing my business to one vendor, as with .NET. J2EE is unique in this respect and that's great.
    - "if it doesn't matter what app server you choose..." - The full text shows that I don't suggest that developing portable apps is always bad, just that it matters overall to a project which implementation you choose. And I was considering other issues besides developing code, such as operations. For example, you have testers and support personnel who need training early in the project lifecycle. Many of these won't have a deep understanding of J2EE, but will need to know how to do X, Y and Z on the particular server. To do iterative development, you need to be able to support a vertical slice early in the project lifecycle. You also need to get the commercials sorted or they can bite you later. Etc.
    - "It's become far too fashionable to be critical of J2EE lately": I don't particularly care whether what I say is "fashionable" or not. And don't think I can be accused of following fashion. Also, I'm not sure I was being critical of J2EE. I was merely pointing out that the claim of 100% portability is misleading. This still leaves J2EE's portability way ahead of that of its competition.
    - Agree that if you don't use EJB, portability is usually very easy. In fact I was the first person to note that in this thread.

    My main motivation for making the first post was anger, not trying to promote my book. Anger that Sun were pushing the "zero cost" fantasy and actually *advocating* deferring app server choice, which is causing my current project a lot of problems.

    Interestingly, you don't seem bothered by the clear motivation of Sun marketing to push the "zero cost" fantasy.

  15. Benefits of portability[ Go to top ]

    |I think you've read a lot more negativity into my post than
    |it contained

    Maybe. Perhaps I have been influenced by the fact that most of your posts are critical of J2EE (EJB, CMP, etc).

    |Interestingly, you don't seem bothered by the clear
    |motivation of Sun marketing to push the "zero cost"

    Well, it does bother me that they say that. But then again, I also quickly dismiss it as irrelevent because I dont think anyone would actually believe that. (Which is related to my next point)

    |Anger that Sun were pushing the "zero cost" fantasy and
    |actually *advocating* deferring app server choice, which is
    |causing my current project a lot of problems.

    I guess we are all up against different problems in our workplace - which influence what we post. I spend lots of time trying to convince people of the BENEFITS of portability - to a sceptical audience where this is a totally alien concept (MS Land and C++ Land).
    It doesnt help when an author of a J2EE book starts posting stuff like "it doesn't matter from the outset of the project what app server you choose, you don't really have an enterprise application" - suggesting that portability only exists for "toy" applications.

    Like I said, I dont think we have any marked difference of opinion here - I just think that too many people are overly-critical of various aspects of J2EE - (often without any real understanding). Now, everything I have read so far indicates you DO have a good understanding. I just get concerned when someone who is held up as an expert only has bad stuff to say... it gives some (impressionable) people the wrong idea. (Its sad how many people in IT make decisions based on their emotional response to something they have read on the web.)

    | Btw, I'm not sure how I can both be taking
    |a "controversial" stance and be making "fashionable"
    |criticism of J2EE

    :) Do you not think its fashionable to be controversial? Seen the Sun or the Mirror lately? ;-)

    - Nick
  16. Benefits of portability[ Go to top ]

    Perhaps I have been influenced by the fact that most of your posts are critical of J2EE (EJB, CMP, etc).

    Criticism of those aspects of J2EE that I feel need improvement, not J2EE as a platform. I want J2EE to continue to be widely adopted, and I think it's important that its flaws are addressed for that to happen. Improvement can't happen unless problems are honestly acknowledged. Criticism can--and should--be constructive as well as destructive.

    Btw, the first sentence of my book (the introduction, which hasn't been made available online) reads:
    "I believe that J2EE is the best platform available for enterprise software development today."

    I completely agree that J2EE has a very good portability story compared to the alternatives. If the Sun article had stopped at saying that, I would have been happy. My issue was that they scored an own goal by making an unrealistic claim. Unrealistic claims are more harmful than constructive criticism.

  17. Benefits of portability[ Go to top ]

    "Criticism can--and should--be constructive as well as destructive."

    I guess thats where we disagree. While I always welcome honesty and constructive criticism, I am not at all sure what the purpose would be of destructive criticism ?

    "My issue was that they scored an own goal by making an unrealistic claim"

    I agree. However, I would also suggest that making the statements you did (essentially suggesting that portability is a myth) is equally an own goal.

    I can tell you for a fact that its stuff like this that ends up getting quoted by .net evangelists as "proof" of their Java/J2EE counter arguments - just because its quoted by a J2EE author on a J2EE site.

  18. Benefits of portability[ Go to top ]

    Btw, I'm not sure how I can both be taking a "controversial" stance and be making "fashionable" criticism of J2EE.

  19. <quote>
    Overall, the J2EE BluePrints [along with the sample apps] provide best practices and a set of design patterns, which are proven solutions to recurring problems in building portable, robust, and scalable J2EE applications.

    Well, at least they don't mention "performant". :-)