TheServerSide Announces Portability Relaunch on Oracle, HP, BEA

Discussions

News: TheServerSide Announces Portability Relaunch on Oracle, HP, BEA

  1. TheServerSide is excited to announce that we intend to re-launch the site to run concurrently across J2EE 1.3 servers from Oracle, HP, and BEA. This cluster of servers will concurrently run the TheServerSide's J2EE infrastructure, with the same J2EE binaries deployed on each server in the cluster.

    This feat will represent a true display of J2EE portability in action, illustrating not only deployment time but run-time portability. Lets see Microsoft try to do the same thing!

    The timeframe for this launch is Q2, and more J2EE Servers will likely be added to the mix. The site will be upgraded from the current single machine running Weblogic to a hardware load-balanced cluster with three machines (each running one vendors server).

    Users browsing the site will be dynamically routed to different vendors servers as they click around the site, and will be able to graphically see which vendors server is running the current instance they have browsed to.

    More information on this will be coming in the subsequent months, for now, feel free to gossip about this at Java One. :)

    Threaded Messages (68)

  2. Glad to hear it, can't wait! =)
    Any plans for trying WebSphere ;)

    TK.
  3. great. is it possible to test the speed of different j2ee servers in this way?
  4. Good idea! As customers always ask for performance. In doing so, we can use this as a reference to show our customers.
  5. don't think you ca do that because u are not gonna which server is it gonna hit if you go via load balancer. If you know the specific IP address of the machine you wanna hit then probly you can do that.
  6. Sri,

    Sri: "don't think you ca do that because u are not gonna which server is it gonna hit if you go via load balancer. If you know the specific IP address of the machine you wanna hit then probly you can do that."

    That's called sticky load balancing. You need that if there is a data locality problem. (With Coherence, we support both sticky and non-sticky transparently.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  7. Happy to hear that.

    Guys, I have 2 or 3 simple questions regarding this "proposed" architecture ('cause I went through the hassle already... and want to see different views):

    How will you keep the user's session? Or will you forget about session management and stick to plain cookies only?
    If users are "sticky" to the 1st server they visit, will the HW load balancer perform the stickiness? If there is no server stickiness, then I guess you would to use either: some cookie based approach or rely on statefull EJBs.
    If the later is used, what about replication AND fault tolerance?
    Guys, seems like you are buying a big headache, but would be challenging. Could you brief us in your thoughts?

    Thanks a lot,

    Vanderlei



  8. I too would like to know how transparent session level failover will be achieved or is the whole user interation going to be stateless, ie. no use of HttpSessions or Stateful Session Beans? Or is some other method of tracking user state going to be employed?
  9. Regarding the session failover, if the site will keep using Resin as the web-container, than you already have quite a solid HTTP session management (including load-balacing and session failover provided). You can than build the application logic in a stateless manner. I guess Resin will be kept as front-end engine. I might be wrong, but that's what I would like to see :-))
  10. Perhaps Sessions are sticky using Layer 5 switch anyways? So once a session is created for a user on some app server node, future requests always go to that server.

    If I'm wrong, then I'm not sure if how one "clusters" multiple application servers the way I understand clustering works. Clustering is handled in a platform specific way, which brings me to my question - Why does not J2EE specify how application nodes should be clustered? Or does it, and I'm simply ignorant?
  11. Hi Vanderlei,
     
      We will start tracking sessions using cookies at first, and as our needs grow past our current simple use cases, we will use database session state.

      We will not be using a sticky load balancer, as we do not want people selectively only surfing say the 'BEA' box or the oracle box. We need to protect ourselves from potential malicious DOS attacks on particular vendors servers or users at home doing their own performance benchmarking.

      Yes, this initiative is indeed a lot of work.

    Floyd
  12. Hai ,

            Looks like there is going to be a lot of activity on this thread when the porting of the server is completed. It would definitly be a true test of faith on the J2EE arch.

    Bye
    Thomas
  13. This is truly a good step to show. I will wait to see WebServices deployed on different app servers.
    Can somebody tell me when will that be??
  14. What is the approx cost of TheServerSide.hardwareSetup and how many pageviews you serve daily? Just wondering efficiency of another J2EE setup..
  15. It would be good to see JBoss and Orion in the mix, they are both low cost too.

    -Pete
  16. No, don't use JBoss, is too slow !!!!!!!!!!!!!!!

    Orion, is good.
  17. Very cool. Another strategy is to run different app servers on different days of the week. That way you can also utilize shared cache products that do not work between different app servers. It's also easier to debug problems, because you always know on which platform they occurred. And the user can even assess which of the 3 systems performs best (although you should be able to arrange it so that they perform identically.) Also, you don't have a load-balancing problem, because each system has its own - this is another example of a proprietary component.) And there is a bonus feature! If you use three different sets of hardware you can do geographic failover as well!

    Summary:
    - No barrier to proprietary solutions, cache or load-balancing
    - Easier debugging
    - Geographic failover

    But I admit that running different app servers at the same time sounds a lot more fun :)

    Guglielmo
  18. Will the new infrastructure and architecture be 'Open'
    to the public or theserverside.com users?

    Regards,

    TK.
  19. It would be good to see Sybase EAServer 4.1 in the mix ! It's our production app server ...
  20. Are you planning to include JBoss in the list of App servers.
  21. This is a very interesting idea.

    Are you using XDoclet to generate deployment descriptors for all the different vendors?

    Aslak
  22. Great News, TSS.

    Hopefully, that should put to rest the false propaganda spread by some people (we know, who) about J2EE not being really portable across server implementations.

    Good luck
  23. I will attempt to answer many of the questions in this thread:

    Clustering
     - we are using a hardware, non-sticky load balancer
     - none of the servers will maintain state (cookie + DB state will be used

    Caching
     - we are looking at using OS Cache to provide JSP level caching

    Cost and Page Views
     - currently we serve well over 1.5 million pageviews per month
     - the costs of the cluster are present, but the participating vendors are helping us offset the cost

    XDoclet
     - yes we are using XDoclet to generate all the platform specific stuff


    Dino, yes this does not represent any real world use case, we are doing this as a portability showcase and of course as a publicity stunt. :)
  24. Ah ha, see Floyd, you need to use the word "cluster" with extreme caution! This proposal is really a hybrid farm of stateless servers, not a hybrid "cluster". Such a thing cannot possibly exist, at least not with the current J2EE specs, because the spec does not provide a common framework for software clustering, failover, replication etc...

    But regardless, the showcase is cool. And if the LB does simple roundrobining for each request, then we as browsers to TSS can tell exactly which server is fastest and which is slowest by the response of each click! Hence I would further suggest that you keep the "This Site Is Powered by XXXX" banner in the lower left corner, this banner of course rotating with each click! ;-)

    Gene
  25. Gene,

    In the case of a web browser as a client, I do not think you can conclude which server performs faster just by a click. Too many other factors come into play - primarily the backbone (network) you are using, its current load & bandwidth coupled with the number of hops between you and the TSS server - before your browser actually renders anything on screen. (Most requests are serviced in the milliseconds range on the server side, but could take a lotta seconds before you see content on your browser).

    -krish

  26. Fair enough. Then why don't we have an actual performance counter in my proposed banner. Hence this alternating banner should say "This site is powered by XXX. And your specific request took YYY milliseconds!"

    Hopefully you can sense my sarcasm in my posts. I am well aware of the vendor flame wars that take place on these hallow grounds, and I was just offering a solution to end this bitter, though entertaining, conflict!

    Gene
  27. Gene,

    Hehe, I'd agree with you - but again too many factors come into play here. With web users randomly (more or less ;) clicking links, the possibility for benchmark times to be skewed still exists.

    Of course, a better way to test scalability & loads would be to run the same benchmark (that is, simulate similar loads across servers in the same environment - hardware, OS, JDKs, database, JDBC drivers etc; say ECperf or WebBench simulating load). But if I am not mistaken, the entire purpose of this science project (to use Dino Chiesa's term and which I partially agree with) is to showcase and document portability myths (or woes or whatever) across AppServers and not performance.

    -krish
  28. Gene,

    Just forgot to add: I doubt any of the vendors who have signed up initially to participate in this exercise would permit such a statistics gathering. (If you look at ECperf results for instance, none of the currently published results are based on existing versions of products - that is, versions that have "been around the block" for the last year; they're all based on betas/pre-releases etc. I'm off on a tangent here, but what does that say for all the systems in production that are using say a 3.x version of vendor A or 5.x or 6.x of vendor B? Free upgrades anyone? Kudos to Pramati though)

    -krish

    PS: I agree, it would be nice to have a little banner or something similar to tell you the request processing took "xxx milliseconds" or whatever, but I doubt we'd see that in the near/immediate future.

    Disclaimer: Views expressed are my own and not those of Borland ;)
  29. Gene: "Ah ha, see Floyd, you need to use the word "cluster" with extreme caution! This proposal is really a hybrid farm of stateless servers, not a hybrid "cluster". Such a thing cannot possibly exist, at least not with the current J2EE specs, because the spec does not provide a common framework for software clustering, failover, replication etc..."

    With Servlet 2.3 you can provide these failover for the web container by using filters and request wrappers etc. to supplement the container functionality, and you can use Coherence or JavaGroups to do the clustering ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  30. Floyd,

    May I ask the reason of your choice: why Oracle, HP and WebLogic ?

    Also, I understand the technical challenge and this sounds quite fun however is the point just having 3 app servers running the same application for scalability and availability (without fail over as far as I can tell) for the sake of doing it or is there any deeper intent ? This does not look like any real life situation to me. Or did I miss anything ?

                    Yann
  31. Wow.. lots of questions.. ok, I'll do my best to answer.

    First, you are right, this is not a real-life situation. Rather it is a portability showcase.

    As far as why Oracle, HP, and Weblogic -- those are our starting servers. We tried to get IBM in for this initial launch, too but it took a little longer than expected to work it out with them, so we expect for IBM to get involved very shortly. We will be adding more servers as time goes on.

    I'll let the TSS dev team answer the more technical questions about state management.

    As far as whether the architecture is open: Our plan is to give the code away at some point, we are still debating how to achieve that, and the timing to do that, internally.

    Is it possible to test the speed of J2EE servers: Yes, we could use TheServerSide as a performance benchmark similar to ECPerf, although we don't currently have any plans to do so right now, because if we did, then we would be inundated with requests from the J2EE vendors to tune their application servers and make them run faster.

    Hope that helps. I am really excited about this and I am looking forward to seeing this happen in the coming weeks.

    -Ed
  32. Thanks for your response Ed.

    TK.
  33. Ed,

    This is a very nice initiative that will be in the spotlight for sure. It would be interesting at a later point that you publish a report that describes the portability issues you will have met, bugs, complexity, speed to port, etc (do you have the right to do it ?). I guess that is where real added value is, in addition to being a proof of concept.

    If you plan to also benchmark those application servers as well as give the code away, why don't you have experts from the application server companies tune TSS ? I understand that some of those guys might be reluctant to do so but that would be a step towards objectivity although I feel I'm being a bit naive there :). Many of us would consider this quite unbiased, well, at least easier to use than ECPerf results (and hell, ECPerf is only about certified platforms and so far only accounts BEA, IBM and Borland). And finally, it would be a way to relieve us from this gasping suspense: is Oracle iAS 3 times or 4 times faster than the fastest of its competitors ? :)

                    Yann
  34. Those are some good ideas Yann. We'll consider those for the future.

    -Ed
  35. So long as TSS doesn't care about session failover, they can run a load balancer, and makes sure that for the duration of a session all requests go to a single machine. Tell the LB that you want to stop accepting new sessions for Machine X, wait until all sessions have timed out, and then you can Upgrade Machine X.

    If only Database stuff were that easy.

    Good Luck. I, too, would like to see JBoss in the Mix.
  36. Please add WebSphere to this cluster
  37. I've read the posts here before, so let me follow site etiquette by declaring up front: I work for Microsoft.

    This effort is a Science Project, a side-show. Technically interesting, but practically speaking, useless.

    What company in their right mind would ever pursue such a deployment architecture? None that have to pay for their sw or hw.

    The J2EE loyalists go on about portability, and vendor-neutrality, but I don't get where the business value comes in. EVEN IF you make the effort to achieve this in applications (I think there was a thread on tss recently covering "how to write portable apps"), even if you manage to avoid all vendor-specific optimizations (pass-by-value EJBs, the various web services implementations, etc.), what have you got? You've got an app that will run, not so well, on any one of 3 or 4 different very expensive app servers.

    Ahhh, I can hear you saying - but The portability, the thing Microsoft doesn't deliver, that is the trump card, you see, because once you deploy a portable app on an expensive app server, you then have the ability to go and purchase ANOTHER expensive J2EE server, deploy your app there, and you will again get similarly poor performance.

    The analogy would be to buy a database and NOT USE the database-specific features. (avoid using @@identity in MS SQL Server, or avoid using stored procedures in your Oracle db). Or maybe buy a car, and NEVER use the roof rack, because that would entail "vendor commitment" - not all cars have roof racks. It's a waste of time, effort, and money.

    Makes no business sense. Am I missing something?

    The other piece of the proposition is "platform neutrality" - so I can run my app on Solaris as well as HPUX, but keeping the same app server. But in neither case does the app really exploit the OS - on the contrary, the app and app server are designed to hide the OS completely. Hence - no exploitation of OS/390 Sysplex, or Solaris partitioning, or HPUX management, any other OS-specific feature. It wouldn't be PORTABLE ! So basically I exchange commitment to the OS platform, for commitment to the app server platform. I am still committed, just at a different level.

    The benefits of these things are all ephemeral - they seem to dissipate when you look closely.

    What companies want and need is INTEROP. They already have a heterogeneous IT architecture, and they have to move forward on new projects. These new projects should connect to their existing systems - CICS, Oracle, SAP, custom apps, Reports, data warehouses, EJBs, and yes (shudder!), desktops.

    That's business value. That's why XML Web services is so interesting, to virtually everybody in the industry. That's why the Java Connector Architecture gets interest.


    Portability of skills? yes, I can see that. J2EE has value here.
    Portability of apps? I don't get it.
    Running same app on 3 diff servers? science project.

    But anyway, Have fun with your project!


    -Dino

  38. <quote>
    Portability of skills? yes, I can see that. J2EE has value here.
    Portability of apps? I don't get it.
    Running same app on 3 diff servers? science project.
    </quote>

    Portability of apps is very interesting to app vendors. If you develop and market J2EE based forum software, rather than run a forum, it is good to know that it can run on whatever compliant appserver the customer has chosen.

    Running the app on different servers is not a normal situation though, unless you also run a training and consultancy business and want to show that your skills are not appserver specific ;-)
  39. With such flame bait how can one resist ?

    >>What company in their right mind would ever pursue such a deployment architecture? None that have to pay for their sw or hw.

    Yes this is an intellectual exercise. No one said a company would do it.

    >>You've got an app that will run, not so well, on any one of 3 or 4 different very expensive app servers.

    Ever heard of vendor lockin ? :-) If M$ is the only game in town, what option do companies have if say M$ decided to double or triple the licensing fee ? Oracle got themselves in a bind because they changed their licencing policy so they lost market share to competitors. Of course it is a heck of a lot harder to change O/S than it is databases since it ties EVERYTHING together..

    >>Makes no business sense. Am I missing something?

    Yeah, bigtime. Business sense says if I am unhappy with a product or service I go somewhere else. Kinda hard if you are tied to the O/S and platform.

    >>So basically I exchange commitment to the OS platform, for commitment to the app server platform. I am still committed, just at a different level.

    Yeah .... committed to choice..

    >>Portability of apps? I don't get it.

    Clearly you don't work for an enterprise application vendor.


  40. Dino,

    I think you're right in some points. .NET is a great approach of Microsoft to be more competetive with J2EE.

    >What company in their right mind would ever pursue such a >deployment architecture? None that have to pay for their >sw or hw.

    I know from a project of a big bank in Germany who choosed two different app servers on two different OS. They said, that they have some service which don't need the quality of service than other services. For example the JSPs that show you some stock information and analyst statements are not so important than a money transfer from one account to another. So they put the less important stuff on a Linux cluster with Tomcat and JBoss (sticky sessions) and the more important stuff on WebSphere on OS/390 (sysplex in Goal-mode...and you don't have to care about it...isn't it great?). It works fine and they safe millions of dollars per year because the Linux environment is so cheap.

    NO, microsoft environment can achieve the quality of service of an OS/390 environment (or COMPAQ NONSTOP Himalaya) and NO Microsoft environment can be as cheap as the mentioned Linux environment. So this is the real power of J2EE and this is what I call flexibility. I can't imagine a productive environment for banks or insurance companies, where you have to reboot your machines every week...there are S/390 which run for 20years without rebooting...

    So thank you TSS for your study of integrating different kind of app-servers. It would be great if you give us the code, so everybody can use it in their projects to give the customers a environment from which they can benefit.

    Mirko
  41. The analogy would be to buy a database and NOT USE the database-specific features.


    Dino

    This may not be obvious to someone who works for a vendor, especially Microsoft, but lots of people for many years have tried *very hard* not to use vendor specific extensions. And if they use them, to do so in an isolated and replaceable way.

    Vendor lock-in is a huge practical problem for customers as it prevents them shopping around for the best price, service, etc. And your arguement that its OK to be locked into the lowest priced vendor, i.e. Microsoft - even if were true and its not - is a very hard sell to many people.

    Nice to see Microsoft embracing Java and portability on mobile devices. Although I'm curious to know what is about mobile devices that suddenly makes portability such a great idea! It wouldn't have anything to do with existing market share by any chance?
  42. This effort is a Science Project, a side-show.


    It is technically interesting but has nothing to do with "science", you know.

    >What company in their right mind would ever pursue
    >such deployment architecture?

    Well, that's not the point of the exercise at all. And yes, there is great business value in the ability to switch from one vendor to another at a relatively low cost, should it become necessary. I know quite a few companies that are doing just that.

    >You've got an app that will run, not so well,
    >on any one of 3 or 4 different very expensive app servers.

    I think you are quite wrong about the "not so well" part. This TSS initiative should be a great showcase and will help people in figuring out all the practical difficulties that remain.

    Since you restate "expensive app server" so many times, do you have an idea of what HP-AS 8.0 costs ? Or Orion ? Or Pramati ? Or JBoss ?

    >The analogy would be to buy a database and
    >NOT USE the database-specific features.

    You don't seem to understand the J2EE deployment model. Have a look e.g. at EJB 2.0 CMP with, say, WebLogic. Check out how WebLogic-specific deployment parameters are defined, notably for tuning performance. Your analogy quicky falls apart, doesn't it ? You could make a more convincing point if you realized where some of the real difficulties are: e.g. in the applications stack atop J2EE - such as portal frameworks - where a lot of work remains to be done. And also in not tying the design of an application to the particular strenghts of a specific release of a specific J2EE product while getting adequate performance/throughput at acceptable cost. Still a black art today but software architecture is not supposed to be a wizard-based task as far as I know.

    >Makes no business sense. Am I missing something?

    Either you are missing a lot or you are deliberately misrepresenting J2EE.

    >What companies want and need is INTEROP.

    They *also* want that obviously, but it's a different question. If companies do not care much about standards and portability as you assume, how do you explain J2EE's market share in the entreprise space ? Solely by technical superiority over MS products ?

    >Portability of apps? I don't get it.

    Rest assured that the market will show you why this matters in many companies and why blindly rushing to .Net, however good it may actually turn out to be, is not always desirable to their CIOs/CTOs.
  43. Dino,

    Evangelists have a tendency to distort reality to make their church look more attractive (no pun intended signore Chiesa). That's part of the game and that would be hypocrit to say that Microsoft are the only ones doing this. It's all about marketing: companies need zealots like you to make marketing BS look real. And you do what you're paid for on TSS.

    The fact is that this portability issue is intended to be an alternative to vendor lock-in. Write once run everywhere. And that works damned well for pure Java applications. Would you disagree with that ? This portability is somehow limited for J2EE because J2EE is a specification. Vendors implement it and add their proprietary features wherever they can. The fact that they implement the same specifications does not mean that there is no competition. Remember what Microsoft and Netscape did to the HTML and EcmaScript... Noone has ever claimed that you would drag and drop your EAR file from vendor 1 to vendor 2, there is some extra work to do. However, code that belongs to the domain covered by the specifications will be easily portable. Now, with respect to performance and scalability, which you seem to question, what evidence have you got to back what you're saying ? You're only spreading MS marketing concepts as far as I can see: J2EE = expensive, portability = lie, Java = slow, in the same spirit of the http://www.objectwatch.com/FinalJ2EEandDotNet.doc report you reviewed for Roger Session (Ed Roman's former MS counterpart - http://www.objectwatch.com/eddebate.htm). This "useless" experiment as you call it is exactly the kind of thing that the J2EE community needs: it's called a proof of concept. But I'm sure many J2EE companies are touting the merits of portability in order to sell proprietary features and that's called marketing. As I said in an earlier post, I'd rather play the game on the non-monopolistic side but that's my choice.

    With respect to interoperability, J2EE is fine: IIOP, JDBC, JCA, XML, JMS, web services. Don't worry about it.

    In short, my opinion is that people don't buy J2EE just because it is portable, but despite your stereotyped opinion, it is probably still far easier to move an application between J2EE application servers than between MS and non-MS.

                    Yann
  44. Seriously, though. I'm no zealot - I'm trying to understand. Vendor independence, to me, is a mistake. A flawed goal. It would mean NOT taking advantage of some of the coolest things in the IT universe. It means avoiding
      BEA Cajun,
      IBM os390 sysplex,
      Websphere Data Access Beans,
      Visual Age for Java,
      Oracle Portal Server,

    All of these things are vendor-specific. By avoiding everything vendor specific, you have basically condemned yourself to building everything. Which is fine if labor is free, but it doesn't seem to make sense in a business setting.


    <yann>
    but despite your stereotyped opinion, it is probably still far easier to move an application between J2EE application servers than between MS and non-MS.
    </yann>

    I never stated the opinion you attribute to me; in fact I believe what you say. But I'm trying to understand the benefit.

    <Guglielmo>
    the value is the industry as a whole as opposed to a company specifically.
    </Guglielmo>

    I think the core benefit of portability is something like the benefit of a labor union - you get power in unity. The success of the app server vendors 3 yrs ago depended upon banding together. Otherwise you would get NetD, Kiva, Cold Fusion, Blue Martini, ATG Dynamo, and a hundred other different, interesting and useful products, none of which would ever reach critical mass. So some degree of portability was definitely a benefit to the vendors themselves. They aligned on a technology base.

    Portability also benefits the programmers - because now a WebLogic guy can go work on a Websphere project with less re-training. and jRun, Orion, JBoss, etc. So portable skills is valuable from that perspective.

    But moving apps from one vendor to another is just an odd thing. It makes sense for an ISV (the build-to-sell scenario, as someone noted), but seems like you give up too much to get this. For build-to-run scenarios, it's a promise that's held out but doesn't make sense for the vast majority of cases - seems to me.

    <eddie>
    Business sense says if I am unhappy with a product or service I go somewhere else. Kinda hard if you are tied to the O/S and platform.
    </eddie>

    The best approach is to establish partnerships with strategic vendors. If IT is important to a company, they will do that, and make sure the partnership works. Certainly choice is important, but keeping the window of opportunity of exercising the choice "always open" means you give up too much. Most companies I've seen re-evaluate their technology investments on an upgrade cycle. Not, "let's port it this weekend."

    <Alain>
    I think you are quite wrong about the "not so well" part.
    </Alain>

    You're right - I am jumping to conclusions when in fact the performance and benchmark data is simply not available. It's still too hard to compare.

    <Yann>
    In short, my opinion is that people don't buy J2EE just because it is portable...
    </Yann>

    I believe that.

    <Aaron>
    I was indirectly involved in another project that was forced to move to a different app server (from jrun to weblogic) because it was the only one supported by a certain content management system.
    </Aaron>

    This somehow seems flawed, the lack of portability (a CMS system requiring a specific server) doesn't argue for the value of portability, to me. This is precisely what I am talking about. If you want something more than just JSP/servlet/EJB, if you want content mgmt and portal and other nifty bits, then you gotta commit.

    Yes, everything commoditizes eventually, and Jakarta has a good portal (good enough?) and maybe good content mgmt one day. But for today, you gotta commit.

    Philisophical question - is it the male-dominated culture that makes IT people unwilling to commit?

    in earnest,
    -Dino

  45. Dino, you pose a very important question: what's the business value of portability? I think the answer requires some historical context.

    Certainly it's a mistake to believe in portability "no matter the cost". There's a vocal faction of the J2EE community that believes J2EE applications should be written to be 100% portable, with no proprietary features. This is an impractical approach and adds little business value.

    I would also note that there's an equally vocal faction that understands that there are phases of innovation: vendors come out with proprietary innovations, and they are eventually rolled into the specifications through the community process. This approach has worked over the past 5 years spectacularily: innovations such as JSP, tag libraries, and more advanced EJB container managed persistence specification have all been the result of this.

    The Sun party line is that proprietary extensions exist, are healthy, so long as the popular ones get rolled into the standard. This is based on a quote from Sun's Rich Green on news.com's special report on JavaOne: the "greatest hits" get rolled into the spec.

    So, we must ask, why a community process at all? Why application portability? This is a purely economic concept: vendor lock-in. Most vendors (not just Microsoft) at some point or another gets it into their head that they can make more money by raising the switching costs in moving to a different vendor. This is, in effect, Microsoft's entire business model -- people don't switch from Windows because the switching costs are too high.

    The popularity of J2EE is directly attributable to thousands of CIOs being fed up with vendor lock-in. They got caught in it with IBM, and then with Microsoft. They've had enough. Open interfaces with competition on inplementation has been the mantra of IT departments since the 1980's, and now J2EE is delivering on that promise.

    J2EE offers a lot of side benefits: standard skill set, a means of raising the "water level" of vendors thus ensuring a minimal level of innovation, and a means for smaller vendors to actually compete against the big guns. (BEA was small just 5 years ago). But minimizing the switching costs of enterprise software servers was the primary goal, even before J2EE, when EJB first came out.

    Microsoft themselves have done this with ODBC, by providing database portability in ensuring a common SQL-92 dialect as "always supported" by a compliant ODBC driver, yet allowing proprietary SQL to exist.

    All J2EE does is promote good software engineering principles: create abstrations to isolate the proprietary aspects of your system. You can disagree with the quality of abstractions that Sun & the JCP has chosen for J2EE, (i.e. some aren't JSP fans, some aren't EJB fans) but the concept of using abstraction is undeniably important.

     If a technical domain isn't specified yet, then it's up to your architects to perform that abstraction. This is always the case with database physical design, tuning, application server tuning, and object/relational mapping. The best of these tools allow full power to do the specific tweaking while keeping these settings distinctly seperate from the portable portion (i.e. business logic) of your application.

    Microsoft is trying to change the conversation of IT managers -- trying to change their focus. By decreasing the costs of interoperability, they're trying to make vendor lock-in palatable again.
    With .NET, there's a common standard library and CLR, lots of XML interop, but most of the high-value tools like ADO.NET, ASP.NET, and the XML web services libraries are completely closed. Microsoft is effectively trying to suggest that the value of .NET is that "sure, you'll be with us forever, but you'll be able to talk to everyone else while you're with us". Will companies by into this? It will be interesting to see. Some certainly will, and it will take years to determine if the economic benefit of this solution is a win/win for IT shops and Microsoft. I'm skeptical, but open to the possibility.


  46. Lock-in or Choice? You decide.[ Go to top ]



    Portability: Why?

    In the end it is all about choice. J2EE is a set of standards - the vendors compete on *implementation*. J2EE has become a *vendor independant*, enterprise application platform suitable for the most noddy applications and the most mission critical.


    The corporate world is full of change. Committing to a strategy that limits your choice is limiting your capability to change. For most businesses, this is a death sentence. THAT is why decision makers are choosing J2EE. Vendors and corporate relationships ("committments") will come and go - but the options are always open.


    In the end it can be summarised like this:
    .NET is a product, however J2EE is a whole marketplace.


  47. <quote>
    Philisophical question - is it the male-dominated culture that makes IT people unwilling to commit?
    </quote>

    LOL.

    I guess a similar observation would be: if you pick .NET, the fact that you can get divorced won't get you far since your wife is the only woman on Earth :-)

    --
    Cedric
  48. <Cedric>If you pick .NET, the fact that you can get divorced won't get you far since your wife is the only woman on Earth :-)
    </Cedric>

    Good one! May I use it when talking to my customers? ;-))

    Dino,

    Portability = freedom of choice. I may not need to migrate today, but as most americans feel - freedom (of choice, of speech, etc.) is the most important thing because... (here goes long list of reasons). Many years ago people has died over freedom (still do in some places). I think J2EE vs. .NET fight is surely in different realm, but it has many similarities.
  49. Dino

    'All of these things are vendor-specific. By avoiding everything vendor specific, you have basically condemned yourself to building everything. Which is fine if labor is free, but it doesn't seem to make sense in a business setting. '

    You raise an important point, but draw the wrong conclusion.

    There are 2 kinds of dependancies on third party software. Talking specifically about J2EE application servers.

    1. App server vendor specific extensions. If I use a J2EE vendor's app servers extension, then my application will not run on another vendor's application server.

    2. App server vendor non-specific extensions. E.g. I buy a component from a third party that runs on all compliant J2EE app servers.

    Its interesting that type 1. dependancies are primarily due to marketing and licensing restrictions. In addition, the vendor has a strong disincentive to making their extension portable even when its technical possible.

    You are right, that buying anything that doesn't expose a standard API makes you dependant on the vendor. However, you would be well advised not to buy anything that can not be ported for licensing reasons. This effectively includes all vendor-specific extensions from major app server vendors.

    The lesson is - if you want the option of app server portability then buy your extensions from third parties, who have an interest in ensuring their extensions are app server portable (or use open source).

    As an aside, its interesting the major app server vendors are rushing headlong to add as many extensions as they can, while it is in the purchaser's interests to avoid extensions from the app server vendors because they are not portable. I'll avoid a discussion on the importance of portability, except to say that I find it hard to envisage distributed internet applications, without some degree of dynamic portability. I think this will play out in ways most people don't anticipate.
  50. Real World Scenario for Dino[ Go to top ]

    Dino,

    I think you are taking the idea of this project way too literally. Yes, this project is not real-world, it is an intellectual exercise. But it does have real world implications.

    Take my company for example. We are a small startup. We couldn't afford WebSphere or WebLogic or anything like that so what we got JRUN (yeah I know, open source stuff is great but our investors think otherwise). JRun is not the most robust thing in the world, but it gets the job done.

    In the future however I know that we will probably move from JRun to something more robust. And also from Oracle to SQL server maybe. So when I am coding I try to avoid things that are vendor specific.

    That doesn't mean I don't use stored procedures! On the contrary, when it means a non-negligible performace increase, we will use something platform or vendor specific.

    This is the real world and it's all about compromise. That means finding the right balance between perfectly neutral code and perfectly tuned code.

    The great thing is that the compromise is not bad at all in J2EE! We use have found use for very little that ties us in to any specific vendor.

    And that's just on the software side! Let's talk about hardware. The funny, dare I say ironic, thing is, all this neutrality that Sun has pioneered might actually in our case mean $$$ for y'all at Microsoft! We originally got Sun hardware with Solaris because of the stability. Now that everyone here feels more confident in Windows as a server platform (except for IIS which is still perceived as insecure) we might actually drop in a couple of windows boxes along side our Sun boxes for application servers. And we might even switch to SQL Server.

    Another great thing is that we can (and do!)all develop here on cheap windows boxes and deploy to our fancy schmancy Sun boxes.

    Does this help you see the relevance of platform neutrality in the real world?

    Bobby
  51. "The J2EE loyalists go on about portability, and vendor-neutrality, but I don't get where the business value comes in."

    I think that's a great question. I think the answer is that you don't see the business value because the value is the industry as a whole as opposed to a company specifically. The value of J2EE is that it's a platform in which IT managers can have confidence because it's vendor agnostic.

    So it may not provide a "competitive advantage", or even lower development costs, but it does provide a long-term platform. How are you going to put a price on that?

    Guglielmo
  52. Makes no business sense. Am I missing something?


    Let me give a couple of examples where this made good business sense.

    A previous project that I was on started out on a low-end app server. When the need for a more heavy duty infrastructure was perceived, we were able to migrate to another J2EE app server (iplanet) with very little cost. If we had used vendor-specific features, this wouldn't have been possible. That's good business sense.

    I was indirectly involved in another project that was forced to move to a different app server (from jrun to weblogic) because it was the only one supported by a certain content management system. The existing J2EE-based components were able to be moved at much less of a cost than if they had used vendor-specific features. That's good business sense.

    There are also many non-technical (political, financial) reasons why you might have to migrate to a different app server. Like it or not, most of us have any number of people with the power to make us do stupid things. Minimizing the cost associated with these types of changes makes good sense.
  53. "The J2EE loyalists go on about portability, and vendor-neutrality, but I don't get where the business value comes in."

    In a real-world, companies and businesses constantly changing partners or consumed by others, that's where portability comes in.

    Let say today I partnered my business to X company or any other company (except for your company). I can easily port my application to them. Is it not a business value?

    what do you think?

    thanks,
    nicky
  54. All I know is that my company's software would have never been sold to customers if there wasn't a possibility to install it on different app servers, databases, and OSes. We have installed the same software on Solaris/Oracle, Linux/Oracle, Linux/SAPDB, SCO/Informix, etc. combinations and the customers always wanted to keep their OS of choice and their DBMS of choice.

    Now how do I do that with Visual Studio? First I use ODBC, then I use DAO, then I use OLE DB, then I use ADO, then I use MFC, then I use Windows Forms, then I use yet another version of VB incompatible to the previous one. Developing software in MS environment is a lot harder than using only commoditized software. And you get that strange feeling that somebody is fooling around with you.

    greetings,
    Branko
  55. Let me start by declaring the following then: I am an independent consultant, but I've invested a plentitud of time learning and using the J2EE platform.

    I must say that I do agree with all that you are saying. Portability is basically just a marketing hype. The FUD hammer used while marketing to beat at Microsoft. Being a Microsoft employee you must be very familiar with marketing hypes and FUD marketing by now, Microsoft practically invented the term. And seeing where Microsoft ended up (ie. practically world dominance) you can't blame others for using the same tactics. Oh yeah, IBM used the same tactics way before Microsoft but back then the game was about cranking away a couple of multi 100k dollar machines a year. While nowadays it's about being the fundamentals of virtually every business in the industrialized world.

    Even the "knowledge portability" isn't really 100% either. All appservers are having their twists that you need to accomodate for. Especially during development. How do you install, deploy. What can you script, what can't you etc. How does it lock, how does it work with that and that database/middleware. Besides this is a business case of _us_, the consultants, the system integrators, the solution providers. Not the end-user.

    And, yeah, the business case for the end-user is interop. But the real thing here is (sorry) EAI. Web services being one tool, JCA being another. I don't see web services being able to be used for any real enterprise eai situations in the near-by future though, there's so many things missing from the infrastructure: security, transaction consistency, etc. etc. Being based on an infrastructure that already has proven itself to have this, JCA is in a much better position to do actual enterprise level intergration. Uh, yeah, EAI. Web services is still very much an empty marketing hype.

    No, the real reason on why we use J2EE is the following: It's nicer.

    I don't even try to be objective here. This is a fuzzy subjective feeling I have that is the real reason behind why I and so many more business and people have chosen J2EE above Microsoft. We can of course try to (any very much need to) rationalize this choice in many ways: Its better designed. It has a lot of open source support. Its based on a community process (even though flawed). Its better documented. Its main founder has a big beard and nice personality. Its based on proven technology. Its name makes me think about coffee and a very nice island in the Indonesian archipelago.

    I bet you somebody who has chosen Microsoft has similar reasons. You do have better looking dialogs and icons, I have to give that to you.

    I'm glad there's still a choice. I really do hope there will always be one.
  56. avoid using @@identity in MS SQL Server, or avoid using stored procedures in your Oracle db


    Well, I don't think you should use theese features as well. Why would one use a vendor specifik feature when there is a SQL-standard?

    /Fredrik
  57. At the end of the day it's what choice customer has got in their hand. They have the money so they have the right to choose, before their options were limited pratically NONE, but now they have a lot of options and that is why they are happy with J2EE.

    Nothing is perfect in this world, but as long as freedom is a perfect thing and people have got the options to be free or lock-in, everybody will go 100% will go with freedom.

    Cheers
  58. "This effort is a Science Project, a side-show. Technically interesting, but practically speaking, useless."

    Wrong. What this proves is that there are a million other developers out there that can pick up where any team member leaves off, regardless of company’s’ IT background. What I really like about J2EE technology is versatile to your IT infrastructure.

    In addition, web application are a growing market (Jira, http://www.atlassian.com/beta/jira/ for example), and the ability to deploy these products on any app server using the J2EE framework is critical to their development platform.

    "What company in their right mind would ever pursue such a deployment architecture? None that have to pay for their sw or hw."

    True.

    "The analogy would be to buy a database and NOT USE the database-specific features."

    Not always true. Many companies are pushing these business rules to the application layer. It is easier to maintain an application when business logic is centralized in one location.

    "These new projects should connect to their existing systems - CICS, Oracle, SAP, custom apps, Reports, data warehouses, EJBs, and yes (shudder!), desktops."

    Partially true. I've been working as a 3+N tier web-application developer for over four years now and I'm seeing a trend where business application are being moved from thick clients (VB/Win32/Whatver) to thin clients (html). It is easier for a company to deploy one application update to a web server that it is to push the software to X desktops.

    The perfect example would be Qwest wireless. If you walk into any one of their stores, when you sign up for a new cellular phone everything is filled out over the web, even the activation of the phones ID with their cellular network!

    In addition web-applications better fit a subscription licensing model and offer a higher level centralized security.

    Let me say it again, more and more companies will move in this direction over time.

    "That's business value. That's why XML Web services is so interesting, to virtually everybody in the industry. That's why the Java Connector Architecture gets interest."

    Yes and no. Web services are a caveat at this point. Web services will really take a roll on desktop for license verification, system tray even based applications, etc.

    I also still see many businesses using a rational database with transactions over web services for several years.

    For those companies that haven’t moved to J2EE or .NET (beta still &#61514;), moving right into web services isn’t the correct move most of the time. They will need to move their business logic away from the db and into a software layer first (not always easy). Then, after they’ve worked their way up the hill, turn around and offer web services, no way. Their budget will have been spent just getting to the point where they have the infrastructure to support web services.
  59. <quote>
    The analogy would be to buy a database and NOT USE the database-specific features. (avoid using @@identity in MS SQL Server, or avoid using stored procedures in your Oracle db).
    </quote>

    OK Dino !!! Microsoft is good huh? Sending people like you to talk about their standards (and fears). You say Microsoft doen't care about portability and that the whole Java Write Once Run Anywhere paradign is just a hype.
    Sooo, PLEASE, explain us the following pharagraph taken from your beloved MSDN Magazine, Vol 17 No 1, page 116 (last January):

    <BODY>
    <subtitle> No Cursos in ADO.Net </subtitle>
    There is no cursor support in ADO.Net. Cursors are a database-specific technology and thus are tied to features of a particular database such as SQL Server or Oracle....
    </BODY>

    You guys make me laugh...

    Vanderlei Silva

  60. Hi There,
    Since the portability of J2EE has been attacked, I will give a real-world example. I used to work for a company that was a tight deadline to deliver an Enterprise Asset Mangagement solution (EAM), the client gave us full freedom on platform of deployment, tools, and solution, as long it solved their business problem. We chose a Microsoft solution, right from SQL Server 2000, ASP, ADO, and the whole Microsoft family. I must say I was impressed, as much as they teach us in school loose coupling is best, the tight coupling in the Microsoft solution helped us meet the very tight schedule. The solution was delivered and deployed, the client is happy, and of course they made us happy by paying up.

    Now comes in Client B. He is much bigger, has much bigger infrastructure (Sun/IBM enterprise servers). He refuses anything Microsoft. Why? Well my friend, when it comes to business, people buy from people they trust, and for truly large enterprise application development, most companies just don't trust microsoft. So we had to replicate a years work on Microsoft onto J2EE and deliver that. It is necessary for me to point out, that now that the company has sold more J2EE solutions than Microsoft, with only appserver specific customization needed.

    I guess my point is that, for those of us in the consulting business, we don't have the luxury of brand loyalty, our expertise and solutions are dictated by client needs. The prevelant opinion in the business world towards technology is that normal isn't normal anymore. Technology is changing very rapidly right from the desktop to the palmtop and the only way businesses can keep up with the latest and maintain their value proposition is to support open standards, and open source, portable, customizable software. J2EE, and Java technologies in general, tag-teamed with Linux provides that base and that's why IBM and others is giving so much java softare for free, and spending $1B on linux.
    TJ
  61. "What company in their right mind would ever pursue such a deployment architecture? None that have to pay for their sw or hw."

    Yes, we would. Imagine your system should be ultimately fault tolerant. This is true for many companies but surely for Police, banks and so on. Just think of the fact unforseen software situations might cause the system to crash on a certain appserver or on a certain OS platform but not on all others. I have seen it happen before. If something goes wrong with either one the other ones will still work. It costs a lot of extra money but it brings the necessary certainty. Before we did the same thing with databases. Think about the implication: if you rely heavily on the Microsoft implementation both switches will be utterly impossible. We could not live with that.

    Hans van Buuren
    Senior Systems Architect
  62. Question:

    Will this be on one hardware platform, or three different ones? What about OS?
  63. Hi,

    It is realy good to know that we can do like this in run time( Production time) as a Developer i'm very much happy to think in this plain. but i have some doubts.

    what is the configuration of Web Server Level like
    (Load balancer..we call in BEA weblogic we can have iPlanet HTTP Server too similar what are the HTTP server you have used here)

    pls let me know more detail about the Web Server layer detail too) i asume that EJB layer is clusterd with diffretn Server and about Web server layer i did;t get how u have done.

    VISWANATHA G.B
    viswagb
    =======
  64. J2EE has many other advantages over other platforms other than portability. J2EE addresses issues like integration (runtime, making use of existing investments), persistence, coordinating transactions between different legacy systems and new applications.

    Portability is very important for companies developing products that they can sell to any client to host. For example, building a commerce shopping cart application that can be reused by Amazon, Borders, a Pet Store, or any Commerce shop. Company X has developed a J2EE application that can be deployed on WebSphere (which customer A uses), WebLogic (which customer B uses), and JBoss (Which company C uses).

    I am currently working on a project for an automotive company that will deploy a parts ordering system to different subsideries, some use WebSphere, other use WebLogic. The application successfully works in both.
  65. As an add on, take a look at projects like struts. Struts can be deployed on virtually any App Server unchanged. Appliation frameworks that can be reused to incorporate design patterns. Log4J can be deployed and encorporated with any JMS Server to create asyn. logging.
  66. FWIW

    I have resigned from my position as the Chief Architect of TheServerSide.com, so this relaunch may take slightly longer than initially advertised.

    Any questions regarding this through this forum or otherwise will be respectfully ignored.

    /Rickard
  67. I listened a lot of enhancement on new J2EE platform, but I want to know, when we can get true cross platform distributed computing in J2EE world, without using any vendor(BEA, IBM) specific API or classes? That's to say, I want to begin a local transaction from my Websphere JSP, and call some EJB functions on remote Weblogic server, then call some EJB functions on local Websphere server, then commit my transaction.
    Even more, this transaction can be got from a CORBA client. I think it is a very important feature but J2EE standard has no clear definitions and throw this duty to vendors, it makes me very disappointed.

    Regards
    wu xz
  68. Something fishy here...[ Go to top ]

    Why isn't IBM WebSphere part of the mix and HP is? WebSphere along with WebLogic is the most used application server. It makes no sense that you wouldn't be deploying to WebSphere. I have to think there is something more going on here. Is WebSphere not up to the task? IBM tends to give WebSphere away with its hardware. I feel this is why they are gaining market share. If WebSphere is so great then show us! You should also use JBoss. IMO you should be using WebLogic, WebSphere and JBoss.
  69. Something fishy here...[ Go to top ]

    Get IBM and JBoss to push for inclusion ... this doesn't seem to be an effort at exclusion!

    Peace,

    Cameron Purdy
    Tangosol, Inc.