Hi Alex, Nader, first of all: Thanks fort he excellent analysis Nader. You are really giving a great outline what one could do!
> > Ok you have me totally depressed and thinking this is near impossible > now :-(. The question is, whether really want to do that all! Let's have a look at the requirements first. Let's assume, we want to build business applications. And let's also assume, that we really want to build enterprise level applications. And finally let's assume, that we would like to build enterprise level applications for the financial industry. And all this should be done with Java. Ok. Now let's have a look at the scalability requirements and the myths how to solve them. The normal way the whole industry is thinking now is, that we "really"!! need distributed facilities - like EJBs or jinni or... - to really serve thousands of concurrent users. Is that true? No! The reality. I'm coaching a "payments" application in a bank. Completely build in Java and JMS. That's it. It is in production since six month. They are serving 15 Millions business transactions on one machine. They have run test in which they have served 50 million business transactions a day. This is all on one machine! Ok - it's a IBM mainframe - but had ported the app on a NCR machine in 14 days - with no performance penalties. If I mean "business transactions" I mean that there are 5 or 10 times more technical database transactions! Aggreed: When they started in 1998 the performance hit between Java and Cobol was 1:20. Today it's 1:1.8! And now IBM had announce an Java Co-Processor for IBM mainframes and stated, that they will overrule COBOL performance now with Java! At the same time I was working for an other bank. They where developing a new architecture for all future developments. They tried to build that on an EJB application server on a IBM mainframe. To get the appserver run, they needed at least 8 GB! Of RAM - to get apps run they stated to need 16 GB of RAM!!. So they installed the appserver with 16 GB of RAM on a 1980 Mips IBM mainframe. Exclusively running for us. Now to the results: After the appserver was started, we had a 10% CPU consumption without any applications running. At the top, with no database access, only stateless SB, we reached about 200 trx/sec. This is not bad. At the low end, we had 15 trx/sec with CMP and 2PC. Technical transactions!! So do we need distribution for scalability? I would say now! Do we need distribution for fault tolerance reasons? This question is a bit more difficult. But to shorten the email a bit: I know COBOL / mainframe applications, which serves 60.000 users on a single machine. Does COBOL support distribution? Does Cobol need that for fault tolerance reasons? No! Why that? Because mainframes today are 100% stateless! This might be not the solution for the Java world - but just to have something to think about. So do we need distribution to achieve fault tolerance? Not necessarily! Do wee need distribution at all? Hm - I'm afraid to say: Yes! There is one point if we want to open up our applications to the outside / not enterprise internal world. For security reasons we have to isolate the webserver in a DMZ - physically decoupled from business applications. But do we really need EJB, Jini, CORBA, ... for that? We should think about that! My conclusion: we have to think about fault tolerance as the main issue. That's it. Than let's switch to application side and solve business semantics - that's the far more appealing part in the business application arena! That's why Merlin rocks - a clear separation of business logic and technical issues is possible by design! Ok Alex - no reason for resignation :-) All the best Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
