Re: [OT] RE: J2EE considered harmful
Hi Alex, You ask why I think it's important to distinguish between the characteristics of a remote call and a local one. One of the nicest things on this topic I found is a paper from Sun themselves - http://research.sun.com/technical-reports/1994/sml1_tr-94-29.pdf From the date, I would think that Sun were in the initial stages of thinking about how to do remote calls in java, and RMI was probably in the gestation stage (anyone knowing the dates of all that better, please correct me !). And I imagine that this paper, which is about the characteristics of distributed computing, and which makes a case for *not* trying to make remote calls transparent, was on the losing side of the argument. My suspicion is that it was marketing thinking that actually pushed the remote model to where it is today. It's a while since I read the paper, and I remember feeling it didn't go quite far enough: my own thoughts are that when you ask a remote machine to do something, you don't necessarily want to suspend your thread till it completes, and when the remote machine responds, it doesn't necessarily want to have completed all the work involved in your request, nor does it want to be restricted to responding just once, or with only a single value. And it might want to queue your request up if it's busy. And if it doesn't have the resources it needs to do what you asked, it might want to tell you about different situations in different ways, without wanting to throw an Exception. Sort of subtler than a local call. If you wanted that kind of subtlety locally, you'd at least be able to widen the interface with some shared memory/shared object communication or even cheap additional calls. Remotely, every communication is expensive. Having the ability for free-running intelligent applications to communicate by sending messages was always a simple and powerful technique in many of the inter-machine situations I've programmed (long before the WWW or CORBA or RMI was around), and RPC feels like a completely unjustified restriction. And I'd suspect the OMG as the hidden source of a lot of the twisted thinking that forced it on us ... a dream, that many bought into, that 'Objects' were the answer to everything, and a theory that the only thing you can do to an object is invoke it, and another theory that the object inside a program is the same as an object in another continent, and they should all look the same and etcetera etcetera. Well, everything's an object, isn't it ? Kiss my object ! - Tim - Original Message - From: Fernandez Martinez, Alejandro [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Sent: 31 January 2002 12:49 Subject: [OT] RE: J2EE considered harmful Hi Tim. I agree with your point of view, we've been trying to avoid EJBs as much as possible. But there's one thing I don't understand. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Yes, EJB is a complete bodge of a design, and RPC invocation techniques would only be acceptable if they were completely transparent, instead of requiring you to do so much plumbing yourself. But personally, I think RPC is entirely overrated, and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Why is it a mistake? I think a remote proxy is a great way to make remote calls, shielding the developer from the complexity of it all. The recent discussion about AltRMI has shown that there's a lot of interest in using proxies, but it was Sun's implementation (the Remote* stuff) that was flawed. Un saludo, Alex. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
Hi Tim! This is good news indeed: someone took the time to actually read a message and respond to it, instead of sending 100's of nonsensical one-liners ;) Answer inline. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Hi Alex, You ask why I think it's important to distinguish between the characteristics of a remote call and a local one. One of the nicest things on this topic I found is a paper from Sun themselves - http://research.sun.com/technical-reports/1994/sml1_tr-94-29.pdf Having just browsed over the document, it seems a bit (quite logically) out of date. Nowadays, if you are running a web application, your users are used to big delays and latencies, and so putting up with a few more milliseconds will not bother them. From the date, I would think that Sun were in the initial stages of thinking about how to do remote calls in java, and RMI was probably in the gestation stage (anyone knowing the dates of all that better, please correct me !). And I imagine that this paper, which is about the characteristics of distributed computing, and which makes a case for *not* trying to make remote calls transparent, was on the losing side of the argument. My suspicion is that it was marketing thinking that actually pushed the remote model to where it is today. As a matter of fact, NeXT had been doing remote proxies for a few years: NeXT Computer, Inc. NeXTSTEP Object-Oriented Programming and the Objective C Language, Release 3. Reading, Mass: Addison-Wesley, 1993. The remote model was moving at full speed at the time. It's a while since I read the paper, and I remember feeling it didn't go quite far enough: my own thoughts are that when you ask a remote machine to do something, you don't necessarily want to suspend your thread till it completes, and when the remote machine responds, it doesn't necessarily want to have completed all the work involved in your request, nor does it want to be restricted to responding just once, or with only a single value. And it might want to queue your request up if it's busy. And if it doesn't have the resources it needs to do what you asked, it might want to tell you about different situations in different ways, without wanting to throw an Exception. Sort of subtler than a local call. Most of this can be done if you use asynchronous messaging wisely, and do synchronous calls only when necessary -- appropriate. You can either expect just one result or a number of them; and you may require an answer immediately or not. The mechanics of remote communication might be something like this: 1 immediate answer: sync 1 delayed answer: async n immediate answers: async n delayed answers: async Of course, asynchronous messaging introduces a host of new problems, but they should be easier to deal with than having to code remote calls by hand. If you wanted that kind of subtlety locally, you'd at least be able to widen the interface with some shared memory/shared object communication or even cheap additional calls. Remotely, every communication is expensive. My book says: first make it work, then make it easy, finally make it cheap. Having the ability for free-running intelligent applications to communicate by sending messages was always a simple and powerful technique in many of the inter-machine situations I've programmed (long before the WWW or CORBA or RMI was around), and RPC feels like a completely unjustified restriction. I take it that by RPC you mean the request-response thing? And I'd suspect the OMG as the hidden source of a lot of the twisted thinking that forced it on us ... a dream, that many bought into, that 'Objects' were the answer to everything, and a theory that the only thing you can do to an object is invoke it, and another theory that the object inside a program is the same as an object in another continent, and they should all look the same and etcetera etcetera. On the surface, they all look like reasonable ideas. Well, everything's an object, isn't it ? Kiss my object ! I seem to detect some hostility in this last part :) - Tim Un saludo, Alex.
Re: [OT] RE: J2EE considered harmful
I agree Jeff; though for such a smart container to work in an elegant way I'd prefer to develop the beans in a non-distributed manner and the smart container do the rest - distributing what it thinks makes sense - along the EOB / AltRMI lines. Not code to a server side componet API like EJB. Though it seems EJB is going along the 'assume everythings remote and we'll try optimise when things are local'. So maybe there's some sense in that. James - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] From: Steve Downey [mailto:[EMAIL PROTECTED]] Most objects don't work if they are made distributed without careful consideration. I wonder if that has to be the case. Right now, our distributed object containers are blissfully stupid. We (humans) can point at any individual class or interface and say remote thyself! but that's as far as it goes. The container just does what we programmers tell it to. Just like me, a hypothetical smart container could make some pretty educated guesses about where and when a set of existing objects should be remoted. Furthermore, it could automatically learn, over time, not only where the best boundaries are, but what are the best situations to perform the remoting/migration. Instead of deciding which classes should be remote, a smart container could decide which *objects* should be remote. And it could learn the answers by watching object behavior over time. Of course, architecture would still have a big effect on performance - but it does already, even in a single-machine environment. We don't hand-optimize our assembly anymore, and suspect that eventually we won't be hand-optimizing our distributed systems, either. JADE and Mobile Agents are not quite what I have in mind. The agent concept is very thread-centric, whereas this idea is object-centric. It sounds like EOB and AltRMI are closer to the mark. I'm going to have to take a long look, and maybe try to restart this discussion on one of their mailing lists :-) Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
So what if you need to move an object that is defined as local to be load balanced across machines? I think you're wrong on that one. If you have to define it as local you loose scalability by definition unless you accept the hardware vendor's edition of scalability (buy an E1 instead and junk your old machine ;-) ). On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote: I do not think so. Handling in a proper way situations that are specific to a remote call does not mean that the architecture of the app must be less scalable. Have fun, Paulo -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 7:03 AM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful Albeit at the expense of scalability On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote: I think that the key bit is: and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Your app will always be more robust if you do NOT ignore the specific issues of a remote call. Have fun, Paulo Gaspar -Original Message- From: Fernandez Martinez, Alejandro [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:50 PM To: 'Jakarta General List' Subject: [OT] RE: J2EE considered harmful Hi Tim. I agree with your point of view, we've been trying to avoid EJBs as much as possible. But there's one thing I don't understand. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Yes, EJB is a complete bodge of a design, and RPC invocation techniques would only be acceptable if they were completely transparent, instead of requiring you to do so much plumbing yourself. But personally, I think RPC is entirely overrated, and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Why is it a mistake? I think a remote proxy is a great way to make remote calls, shielding the developer from the complexity of it all. The recent discussion about AltRMI has shown that there's a lot of interest in using proxies, but it was Sun's implementation (the Remote* stuff) that was flawed. Un saludo, Alex. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
Paul already talked about a couple ways of tuning the use of remote calls without having to do it on a case by case basis. However, the thumb rule is that: - Either you build the system to be scalable (which might make it a bit less efficient when having it working in a single machine when compared to a non scalable system); - Or you use some transparency mechanism and you tend to loose robustness/control when compared to a system that is aware of possible communications issues and tries to handle them. Some communications issues can be recovered from and some not. And sometimes the decision to try to recover or not depends on the kind of operation you are performing. And I also agree with Paul that the RemoteException is NOT a bit help. Do you believe on magic bullets that work everywhere? We keep trying to get as close to having them as possible but... Have fun, Paulo Gaspar -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 2:19 PM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful So what if you need to move an object that is defined as local to be load balanced across machines? I think you're wrong on that one. If you have to define it as local you loose scalability by definition unless you accept the hardware vendor's edition of scalability (buy an E1 instead and junk your old machine ;-) ). On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote: I do not think so. Handling in a proper way situations that are specific to a remote call does not mean that the architecture of the app must be less scalable. Have fun, Paulo -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 7:03 AM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful Albeit at the expense of scalability On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote: I think that the key bit is: and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Your app will always be more robust if you do NOT ignore the specific issues of a remote call. Have fun, Paulo Gaspar -Original Message- From: Fernandez Martinez, Alejandro [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:50 PM To: 'Jakarta General List' Subject: [OT] RE: J2EE considered harmful Hi Tim. I agree with your point of view, we've been trying to avoid EJBs as much as possible. But there's one thing I don't understand. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Yes, EJB is a complete bodge of a design, and RPC invocation techniques would only be acceptable if they were completely transparent, instead of requiring you to do so much plumbing yourself. But personally, I think RPC is entirely overrated, and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Why is it a mistake? I think a remote proxy is a great way to make remote calls, shielding the developer from the complexity of it all. The recent discussion about AltRMI has shown that there's a lot of interest in using proxies, but it was Sun's implementation (the Remote* stuff) that was flawed. Un saludo, Alex. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
On Fri, 2002-02-01 at 08:59, Paulo Gaspar wrote: Paul already talked about a couple ways of tuning the use of remote calls without having to do it on a case by case basis. I'll reread the archive after I finish my coffee ;-) However, the thumb rule is that: - Either you build the system to be scalable (which might make it a bit less efficient when having it working in a single machine when compared to a non scalable system); true. There are *how much* issue though. I mean the 400-500 times slower rule of CMP Entity beans would go into the area of being ridiculous. Sun is still a year and a half behind. A year and a half ago when hardware was dirt cheap and programmers were expensive perhaps this would have made more sense. But even then...bandwidth wasn't Always build some scalability. You'll either fail or succeed. This means you'll either have too few users or too many. If your system can't take it then there is a self correcting mechanism in place (users all get ticked and go back to whatever they did before you came along). So you always need some scalability. Always plan to refactor of course, and good design can protect you from some issues (facades for areas that will likely be implemented otherwise later), but the system must be inherently scalable. (This doesn't mean you need a CTM for your low volume 1 megabyte website, but you get the picture) - Or you use some transparency mechanism and you tend to loose robustness/control when compared to a system that is aware of possible communications issues and tries to handle them. I still think there is a way to at least make this *configurable*. Some communications issues can be recovered from and some not. And sometimes the decision to try to recover or not depends on the kind of operation you are performing. And I also agree with Paul that the RemoteException is NOT a bit help. That of course had nothing to do with my issue. Do you believe on magic bullets that work everywhere? No but I do believe that location transparency is a good thing. We keep trying to get as close to having them as possible but... Have fun, Paulo Gaspar -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 2:19 PM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful So what if you need to move an object that is defined as local to be load balanced across machines? I think you're wrong on that one. If you have to define it as local you loose scalability by definition unless you accept the hardware vendor's edition of scalability (buy an E1 instead and junk your old machine ;-) ). On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote: I do not think so. Handling in a proper way situations that are specific to a remote call does not mean that the architecture of the app must be less scalable. Have fun, Paulo -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 7:03 AM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful Albeit at the expense of scalability On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote: I think that the key bit is: and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Your app will always be more robust if you do NOT ignore the specific issues of a remote call. Have fun, Paulo Gaspar -Original Message- From: Fernandez Martinez, Alejandro [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:50 PM To: 'Jakarta General List' Subject: [OT] RE: J2EE considered harmful Hi Tim. I agree with your point of view, we've been trying to avoid EJBs as much as possible. But there's one thing I don't understand. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Yes, EJB is a complete bodge of a design, and RPC invocation techniques would only be acceptable if they were completely transparent, instead of requiring you to do so much plumbing yourself. But personally, I think RPC is entirely overrated, and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Why is it a mistake? I think a remote proxy is a great way to make remote calls, shielding the developer from the complexity of it all. The recent discussion about AltRMI has shown that there's a lot of interest in using proxies, but it was Sun's implementation (the Remote* stuff) that was flawed. Un saludo, Alex. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED
Re: [OT] RE: J2EE considered harmful
Those are both search engines with non-critical data update issues. You do need an example with more business-logic oriented type functionality. I could mock something like those up with Lucene just with a few routers and pushing the indicies to the mirrored systems. This doesn't answer the enterprise system question. Secondly we need examples on a more moderate basis. (sorry, if that sounds critical, I don't mean to be, I think you're heading the discussion the right direction, I just don't think those examples do that) On a more personal note. Funny story: My wife went to high/grade school with the Google guy. Small world eh? -Andy On Fri, 2002-02-01 at 08:57, Ted Husted wrote: Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
yahoo.com goes way beyond a search engine: Email, address books, auctions, classified ads, file storage, calendars and shared calendars, personalized portals for like 27 different sub applications, the list goes on. Yahoo is delivering a vast number of dynamic applications to an incredible number of users, with excellent performance and reliabity. If there a success story in IT, this is it. I picked yahoo.com and google.com as two different examples of high traffic Web sites that are delivering scalability. I only mentioned google.com since it is ~blazingly fast~, and represents a very different best-of-breed right now. Andrew C. Oliver wrote: Those are both search engines with non-critical data update issues. You do need an example with more business-logic oriented type functionality. I could mock something like those up with Lucene just with a few routers and pushing the indicies to the mirrored systems. This doesn't answer the enterprise system question. Secondly we need examples on a more moderate basis. (sorry, if that sounds critical, I don't mean to be, I think you're heading the discussion the right direction, I just don't think those examples do that) On a more personal note. Funny story: My wife went to high/grade school with the Google guy. Small world eh? -Andy On Fri, 2002-02-01 at 08:57, Ted Husted wrote: Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
On Fri, 2002-02-01 at 10:46, Ted Husted wrote: yahoo.com goes way beyond a search engine: Email, address books, auctions, classified ads, file storage, calendars and shared calendars, personalized portals for like 27 different sub applications, the list goes on. Yahoo is delivering a vast number of dynamic applications to an incredible number of users, with excellent performance and reliabity. If there a success story in IT, this is it. True, but it isn't particularly transactional in nature as far as the other features, more of a publishing type app. Sure the email, but that even has isolated data interaction.. Am I making sense? I picked yahoo.com and google.com as two different examples of high traffic Web sites that are delivering scalability. I only mentioned google.com since it is ~blazingly fast~, and represents a very different best-of-breed right now. Andrew C. Oliver wrote: Those are both search engines with non-critical data update issues. You do need an example with more business-logic oriented type functionality. I could mock something like those up with Lucene just with a few routers and pushing the indicies to the mirrored systems. This doesn't answer the enterprise system question. Secondly we need examples on a more moderate basis. (sorry, if that sounds critical, I don't mean to be, I think you're heading the discussion the right direction, I just don't think those examples do that) On a more personal note. Funny story: My wife went to high/grade school with the Google guy. Small world eh? -Andy On Fri, 2002-02-01 at 08:57, Ted Husted wrote: Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
As far as I can remember Google has started out in a small shed using just personal computers. No big mainframes, serverfarms or whatever. Just a proprietary server platform. What the status is right now, I don't now... alef -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, 01 February 2002 16:46 To: Jakarta General List Subject: Re: [OT] RE: J2EE considered harmful yahoo.com goes way beyond a search engine: Email, address books, auctions, classified ads, file storage, calendars and shared calendars, personalized portals for like 27 different sub applications, the list goes on. Yahoo is delivering a vast number of dynamic applications to an incredible number of users, with excellent performance and reliabity. If there a success story in IT, this is it. I picked yahoo.com and google.com as two different examples of high traffic Web sites that are delivering scalability. I only mentioned google.com since it is ~blazingly fast~, and represents a very different best-of-breed right now. Andrew C. Oliver wrote: Those are both search engines with non-critical data update issues. You do need an example with more business-logic oriented type functionality. I could mock something like those up with Lucene just with a few routers and pushing the indicies to the mirrored systems. This doesn't answer the enterprise system question. Secondly we need examples on a more moderate basis. (sorry, if that sounds critical, I don't mean to be, I think you're heading the discussion the right direction, I just don't think those examples do that) On a more personal note. Funny story: My wife went to high/grade school with the Google guy. Small world eh? -Andy On Fri, 2002-02-01 at 08:57, Ted Husted wrote: Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
On Fri, 2002-02-01 at 11:07, Ted Husted wrote: Andrew C. Oliver wrote: On Fri, 2002-02-01 at 10:46, Ted Husted wrote: yahoo.com goes way beyond a search engine: Email, address books, auctions, classified ads, file storage, calendars and shared calendars, personalized portals for like 27 different sub applications, the list goes on. Yahoo is delivering a vast number of dynamic applications to an incredible number of users, with excellent performance and reliabity. If there a success story in IT, this is it. True, but it isn't particularly transactional in nature as far as the other features, more of a publishing type app. Sure the email, but that even has isolated data interaction.. Am I making sense? You need to consider that they are doing *everything*, including a very complicated type of ecommerce through the auctions. That's the stunning part. It's not just one banana, it's the whole bunch. Ahh, you know, you're right. (I use all those things but forget they are there since they don't break often ;-)...come to think of it yahoo is a great example) -Andy -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
(too bad I'll be boycotting Yahoo soon because they use pop-up ads which I consider SOoo unprofessional) On Fri, 2002-02-01 at 11:00, Andrew C. Oliver wrote: On Fri, 2002-02-01 at 11:07, Ted Husted wrote: Andrew C. Oliver wrote: On Fri, 2002-02-01 at 10:46, Ted Husted wrote: yahoo.com goes way beyond a search engine: Email, address books, auctions, classified ads, file storage, calendars and shared calendars, personalized portals for like 27 different sub applications, the list goes on. Yahoo is delivering a vast number of dynamic applications to an incredible number of users, with excellent performance and reliabity. If there a success story in IT, this is it. True, but it isn't particularly transactional in nature as far as the other features, more of a publishing type app. Sure the email, but that even has isolated data interaction.. Am I making sense? You need to consider that they are doing *everything*, including a very complicated type of ecommerce through the auctions. That's the stunning part. It's not just one banana, it's the whole bunch. Ahh, you know, you're right. (I use all those things but forget they are there since they don't break often ;-)...come to think of it yahoo is a great example) -Andy -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
If you are _very_ lucky, the object is coarse grained enough, and has loose enough performance requirements, that the rest of the system can tolerate that calls to it will take 100 to 1000 times longer. I've never seen any system that lucky. Most objects don't work if they are made distributed without careful consideration. -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 8:19 AM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful So what if you need to move an object that is defined as local to be load balanced across machines? I think you're wrong on that one. If you have to define it as local you loose scalability by definition unless you accept the hardware vendor's edition of scalability (buy an E1 instead and junk your old machine ;-) ). On Fri, 2002-02-01 at 08:06, Paulo Gaspar wrote: I do not think so. Handling in a proper way situations that are specific to a remote call does not mean that the architecture of the app must be less scalable. Have fun, Paulo -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 7:03 AM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful Albeit at the expense of scalability On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote: I think that the key bit is: and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Your app will always be more robust if you do NOT ignore the specific issues of a remote call. Have fun, Paulo Gaspar -Original Message- From: Fernandez Martinez, Alejandro [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:50 PM To: 'Jakarta General List' Subject: [OT] RE: J2EE considered harmful Hi Tim. I agree with your point of view, we've been trying to avoid EJBs as much as possible. But there's one thing I don't understand. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Yes, EJB is a complete bodge of a design, and RPC invocation techniques would only be acceptable if they were completely transparent, instead of requiring you to do so much plumbing yourself. But personally, I think RPC is entirely overrated, and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Why is it a mistake? I think a remote proxy is a great way to make remote calls, shielding the developer from the complexity of it all. The recent discussion about AltRMI has shown that there's a lot of interest in using proxies, but it was Sun's implementation (the Remote* stuff) that was flawed. Un saludo, Alex. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
A 10,000 node linux cluster. http://www.google.com/press/highlights.html -Original Message- From: Alef Arendsen [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 10:58 AM To: Jakarta General List Subject: RE: [OT] RE: J2EE considered harmful As far as I can remember Google has started out in a small shed using just personal computers. No big mainframes, serverfarms or whatever. Just a proprietary server platform. What the status is right now, I don't now... alef -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, 01 February 2002 16:46 To: Jakarta General List Subject: Re: [OT] RE: J2EE considered harmful yahoo.com goes way beyond a search engine: Email, address books, auctions, classified ads, file storage, calendars and shared calendars, personalized portals for like 27 different sub applications, the list goes on. Yahoo is delivering a vast number of dynamic applications to an incredible number of users, with excellent performance and reliabity. If there a success story in IT, this is it. I picked yahoo.com and google.com as two different examples of high traffic Web sites that are delivering scalability. I only mentioned google.com since it is ~blazingly fast~, and represents a very different best-of-breed right now. Andrew C. Oliver wrote: Those are both search engines with non-critical data update issues. You do need an example with more business-logic oriented type functionality. I could mock something like those up with Lucene just with a few routers and pushing the indicies to the mirrored systems. This doesn't answer the enterprise system question. Secondly we need examples on a more moderate basis. (sorry, if that sounds critical, I don't mean to be, I think you're heading the discussion the right direction, I just don't think those examples do that) On a more personal note. Funny story: My wife went to high/grade school with the Google guy. Small world eh? -Andy On Fri, 2002-02-01 at 08:57, Ted Husted wrote: Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
On 2/1/02 8:57 AM, Ted Husted [EMAIL PROTECTED] wrote: Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Give them a C/C++ compiler? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Lots and lots of computers? Again, how can we package that approach in a way that it accessible to other developers? I think that the two cases are different (Yahoo and Google), and I think (I don't know as I don't work for Google or Yahoo) it comes down to engineering the solution to the problem, and then using existing tools that fit *your* design solution, and building the parts you can't buy. It appears to me that the App server approach is the opposite - here is your solution, can you bend the problem to fit? (Like a joke we used to have : Unix, of course. Now what was the question?) I am working on a rather large-ish, very complicated project that we are going to implement in Java. There are many J2EE technologies that we will take advantage of such as JMS, JNDI, JTA, etc but the whole container approach doesn't have any relevance other than we may be forced to run it to get some of the services as an app client. Dunno. This does bring up an interesting question : could EJBs possibly work for Yahoo? (I bet not...) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
From: Steve Downey [mailto:[EMAIL PROTECTED]] Most objects don't work if they are made distributed without careful consideration. I wonder if that has to be the case. Right now, our distributed object containers are blissfully stupid. We (humans) can point at any individual class or interface and say remote thyself! but that's as far as it goes. The container just does what we programmers tell it to. Just like me, a hypothetical smart container could make some pretty educated guesses about where and when a set of existing objects should be remoted. Furthermore, it could automatically learn, over time, not only where the best boundaries are, but what are the best situations to perform the remoting/migration. Instead of deciding which classes should be remote, a smart container could decide which *objects* should be remote. And it could learn the answers by watching object behavior over time. Of course, architecture would still have a big effect on performance - but it does already, even in a single-machine environment. We don't hand-optimize our assembly anymore, and suspect that eventually we won't be hand-optimizing our distributed systems, either. JADE and Mobile Agents are not quite what I have in mind. The agent concept is very thread-centric, whereas this idea is object-centric. It sounds like EOB and AltRMI are closer to the mark. I'm going to have to take a long look, and maybe try to restart this discussion on one of their mailing lists :-) Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: J2EE considered harmful
Albeit at the expense of scalability On Thu, 2002-01-31 at 09:51, Paulo Gaspar wrote: I think that the key bit is: and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Your app will always be more robust if you do NOT ignore the specific issues of a remote call. Have fun, Paulo Gaspar -Original Message- From: Fernandez Martinez, Alejandro [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 1:50 PM To: 'Jakarta General List' Subject: [OT] RE: J2EE considered harmful Hi Tim. I agree with your point of view, we've been trying to avoid EJBs as much as possible. But there's one thing I don't understand. -Mensaje original- De: Tim Hyde [mailto:[EMAIL PROTECTED]] Yes, EJB is a complete bodge of a design, and RPC invocation techniques would only be acceptable if they were completely transparent, instead of requiring you to do so much plumbing yourself. But personally, I think RPC is entirely overrated, and it is a mistake to try to program as though a remote call had the same characteristics as a local one. Why is it a mistake? I think a remote proxy is a great way to make remote calls, shielding the developer from the complexity of it all. The recent discussion about AltRMI has shown that there's a lot of interest in using proxies, but it was Sun's implementation (the Remote* stuff) that was flawed. Un saludo, Alex. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
