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: J2EE considered harmful
Hi Jeff I share your oppinions on EJB. Whenever I ask developers why they are using EJB the common answer I get from people is 'well I get transactions for free'. When most of the time they don't do 2 phase commit with their database anyways. And all that extra work just to get 'acceptable' performance from EJB. Jeez this stuff is meant to help us not hinder us. I agree that EJB has shoved too many things together in one 'server side component' framework. Perhaps working from core specs is better and just choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias is to use 'local' object technologies such as Java Beans, Servlets, JDBC, JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP or whatnot) when distribution is required. I try to avoid RMI if truth be told. It seems so 80s ;-) I'm still not convinced at all that EJBs are even worth considering when when building web applications - why should be business logic be remote in a web-centric world? Why not deploy the business logic with the web application and save all those costly synchronous RMI calls. You can have seperation of concerns without making things remote. You only have to look at MS's PetShop to see how simple and fast to develop web applications could be while still seperating business logic, persistence and presentation - or how slow and painful they can be if you follow the EJB path. I do think a simple open source alternative to EJB would be a good thing. Already Jakarta has most of the bits almost in place, tying them all together would be cool. FWIW you might want to keep an eye on the AltRMI project at Jakarta Commons which hopes to make RMI and the Remote stuff much easier. James - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 8:38 PM Subject: RE: J2EE considered harmful Amusingly enough, I've been considering writing an article with this exact same title. I've implemented two medium-sized systems using EJBs (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've been haunting the ejb-interest list for more than a year. I was never ecstatic about the technology, but now I'm starting to feel downright disillusioned with it. This is not coming from someone stumbling around with the technology. The first thing I did was read Richard Monson-Haefel's book cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only implementation. I've got most of the 2.0 spec memorized. I have no trouble writing the deployment descriptors by hand. The problem is, even after more than a year of this, I still find that writing software using EJBs is a steady progress of fighting the technology to make it do what you want. It shouldn't be like this. Having to write three or four different classes, plus an elaborate deployment descriptor for each object slows things down a bit. Tools like xdoclet help, but it's still a complicated and painful process to refactor anything. Basic software design patterns are agonizing or impossible to implement. Observable? Time to learn JMS and Message-Driven Beans. Singleton? Not in the framework... you have to set up an external RMI server. Presistance in the EJBland is a disappointment. Even with EJB 2.0, entity beans are not remotely mature. There is no support for relationship attributes or automatically generated primary keys. The query language is constrictive, offering no support for ordering, aggregation functions, or retrieving data which spans more than a single class. After 20+ years of research and advancement in RDBMS technology, this is a colossal step backwards, and the consequence is that entity beans radically underperform systems with more direct database access. I find that I must constantly sidestep the container with direct JDBC in order to meet performance or feature requirements, and it sounds like this is a common problem. Overall, my feeling is that Sun tried to cram too many disparate technologies into a single API. EJB! It's a distributed object model, transaction model, security model, persistence model, component model, message queue, desert topping, and floor wax all rolled into one! Some of it makes sense, but some of it (especially persistence) doesn't. I'm surprised that people can build large applications with EJB. My guess is that it's probably very effective for one particular class of problem - ecommerce apps. I'm sure it's no accident that all the examples in the spec are Order, LineItem, etc. Unfortunately, this doesn't help me, or any of the rest of the people who are working on applications that are actually interesting. And my guess is that since ecommerce is 90% of the market for expensive app servers, Sun doesn't really care. Ok, enough whining. What to do about it? I really like the idea of an Apache community building a truly free competitor to J2EE. I don't like being tied
RE: J2EE considered harmful
From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]] Are you just talking about creating a new language, or what? What is your idea? I cannot tell. That's a good question, and ultimately one which would be determined by the constraints of the technology. Prototyping would probably involve using an existing language and platform, and maybe we would ultimately discover that it is possible to build a system like this on top of a JVM (or CLR). My suspicion is that it is not, and may be undesirable for legal reasons anyways. The later part of my diatribe was a hastily phrased way of approaching this subject: Unless you want to go back to the dark ages of C++, the future is shaping up to look like a choice between writing for the Sun platform or the Microsoft platform. This does not make me comfortable, especially considering that Sun's approach to Java so far has been *wholly* anathema to the principals of Open Source. At least Microsoft has submitted C# and the CLI to ECMA. Quoth Jon: *WAKE UP PEOPLE* I am tantalized by the idea of a third choice: the Apache platform. I propose a discussion of just what that might be. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: J2EE considered harmful
On Fri, 2002-02-01 at 04:14, James Strachan wrote: Hi Jeff I share your oppinions on EJB. Whenever I ask developers why they are using EJB the common answer I get from people is 'well I get transactions for free'. When most of the time they don't do 2 phase commit with their database anyways. And all that extra work just to get 'acceptable' performance from EJB. Jeez this stuff is meant to help us not hinder us. I agree that EJB has shoved too many things together in one 'server side component' framework. Perhaps working from core specs is better and just choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias is to use 'local' object technologies such as Java Beans, Servlets, JDBC, JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP or whatnot) when distribution is required. I try to avoid RMI if truth be told. It seems so 80s ;-) I'm still not convinced at all that EJBs are even worth considering when when building web applications - why should be business logic be remote in a web-centric world? Why not deploy the business logic with the web I agree with everything but this. For scalability you should have the option but should not always use it. If your application will grow it is good to have a middle tier that can be moved and load balanced. With Entity beans of course this is less possible. application and save all those costly synchronous RMI calls. You can have seperation of concerns without making things remote. You only have to look at MS's PetShop to see how simple and fast to develop web applications could be while still seperating business logic, persistence and presentation - or how slow and painful they can be if you follow the EJB path. I do think a simple open source alternative to EJB would be a good thing. Already Jakarta has most of the bits almost in place, tying them all together would be cool. +1 FWIW you might want to keep an eye on the AltRMI project at Jakarta Commons which hopes to make RMI and the Remote stuff much easier. James - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 8:38 PM Subject: RE: J2EE considered harmful Amusingly enough, I've been considering writing an article with this exact same title. I've implemented two medium-sized systems using EJBs (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've been haunting the ejb-interest list for more than a year. I was never ecstatic about the technology, but now I'm starting to feel downright disillusioned with it. This is not coming from someone stumbling around with the technology. The first thing I did was read Richard Monson-Haefel's book cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only implementation. I've got most of the 2.0 spec memorized. I have no trouble writing the deployment descriptors by hand. The problem is, even after more than a year of this, I still find that writing software using EJBs is a steady progress of fighting the technology to make it do what you want. It shouldn't be like this. Having to write three or four different classes, plus an elaborate deployment descriptor for each object slows things down a bit. Tools like xdoclet help, but it's still a complicated and painful process to refactor anything. Basic software design patterns are agonizing or impossible to implement. Observable? Time to learn JMS and Message-Driven Beans. Singleton? Not in the framework... you have to set up an external RMI server. Presistance in the EJBland is a disappointment. Even with EJB 2.0, entity beans are not remotely mature. There is no support for relationship attributes or automatically generated primary keys. The query language is constrictive, offering no support for ordering, aggregation functions, or retrieving data which spans more than a single class. After 20+ years of research and advancement in RDBMS technology, this is a colossal step backwards, and the consequence is that entity beans radically underperform systems with more direct database access. I find that I must constantly sidestep the container with direct JDBC in order to meet performance or feature requirements, and it sounds like this is a common problem. Overall, my feeling is that Sun tried to cram too many disparate technologies into a single API. EJB! It's a distributed object model, transaction model, security model, persistence model, component model, message queue, desert topping, and floor wax all rolled into one! Some of it makes sense, but some of it (especially persistence) doesn't. I'm surprised that people can build large applications with EJB. My guess is that it's probably very effective for one particular class of problem - ecommerce apps. I'm sure it's no accident that all the examples in the spec are Order, LineItem
RE: J2EE considered harmful
This is getting interesting and we have e lot of pieces for this kind of puzzle around Apache. Why must standards be ruled just by the BigCo's??? De facto standards happen when a product is really good. This reminds me how the then tiny dog Borland turned Turbo Pascal into the de facto standard Pascal language in a couple of years. All Pascal language related products wanted to be compatible with it and not with whatever was the standard Pascal. All the big dogs had to run away. Have fun, Paulo Gaspar -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:54 PM To: Jakarta General List Subject: RE: J2EE considered harmful From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]] Are you just talking about creating a new language, or what? What is your idea? I cannot tell. That's a good question, and ultimately one which would be determined by the constraints of the technology. Prototyping would probably involve using an existing language and platform, and maybe we would ultimately discover that it is possible to build a system like this on top of a JVM (or CLR). My suspicion is that it is not, and may be undesirable for legal reasons anyways. The later part of my diatribe was a hastily phrased way of approaching this subject: Unless you want to go back to the dark ages of C++, the future is shaping up to look like a choice between writing for the Sun platform or the Microsoft platform. This does not make me comfortable, especially considering that Sun's approach to Java so far has been *wholly* anathema to the principals of Open Source. At least Microsoft has submitted C# and the CLI to ECMA. Quoth Jon: *WAKE UP PEOPLE* I am tantalized by the idea of a third choice: the Apache platform. I propose a discussion of just what that might be. Jeff Schnitzer [EMAIL PROTECTED] -- 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: J2EE considered harmful
of the Sun/Microsoft duopoly. (Yeah, yeah, there will always be people who enjoy working on nonvirtual machines, but they're crazy :-) I'm not completely sure I followed this. I was cool up until the above line. Are you suggesting just a replacement for J2EE or Java itself. I'm fairly satisfied with Java as a language except for Sun's upcoming half-assed implementation of Java Generics, but not the J2EE stuff. On Thu, 2002-01-31 at 15:38, Jeff Schnitzer wrote: Amusingly enough, I've been considering writing an article with this exact same title. I've implemented two medium-sized systems using EJBs (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've been haunting the ejb-interest list for more than a year. I was never ecstatic about the technology, but now I'm starting to feel downright disillusioned with it. This is not coming from someone stumbling around with the technology. The first thing I did was read Richard Monson-Haefel's book cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only implementation. I've got most of the 2.0 spec memorized. I have no trouble writing the deployment descriptors by hand. The problem is, even after more than a year of this, I still find that writing software using EJBs is a steady progress of fighting the technology to make it do what you want. It shouldn't be like this. Having to write three or four different classes, plus an elaborate deployment descriptor for each object slows things down a bit. Tools like xdoclet help, but it's still a complicated and painful process to refactor anything. Basic software design patterns are agonizing or impossible to implement. Observable? Time to learn JMS and Message-Driven Beans. Singleton? Not in the framework... you have to set up an external RMI server. Presistance in the EJBland is a disappointment. Even with EJB 2.0, entity beans are not remotely mature. There is no support for relationship attributes or automatically generated primary keys. The query language is constrictive, offering no support for ordering, aggregation functions, or retrieving data which spans more than a single class. After 20+ years of research and advancement in RDBMS technology, this is a colossal step backwards, and the consequence is that entity beans radically underperform systems with more direct database access. I find that I must constantly sidestep the container with direct JDBC in order to meet performance or feature requirements, and it sounds like this is a common problem. Overall, my feeling is that Sun tried to cram too many disparate technologies into a single API. EJB! It's a distributed object model, transaction model, security model, persistence model, component model, message queue, desert topping, and floor wax all rolled into one! Some of it makes sense, but some of it (especially persistence) doesn't. I'm surprised that people can build large applications with EJB. My guess is that it's probably very effective for one particular class of problem - ecommerce apps. I'm sure it's no accident that all the examples in the spec are Order, LineItem, etc. Unfortunately, this doesn't help me, or any of the rest of the people who are working on applications that are actually interesting. And my guess is that since ecommerce is 90% of the market for expensive app servers, Sun doesn't really care. Ok, enough whining. What to do about it? I really like the idea of an Apache community building a truly free competitor to J2EE. I don't like being tied to technologies owned by a single company, so I'm already pretty nervous by the stranglehold that Sun has on Java and (especially) J2EE. But it's not enough to build a marginal improvement over the existing system, even with Apache's mindshare. Besides, who wants to copy a mediocre idea? :-) I've been giving a lot of thought to distributed object models lately. I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a lot of the same. Since networks are getting so fast these days, I'm starting to really wonder what it would be like to have a model in which: * All objects are inherently remotable. * Objects transparently migrate for efficiency. I can think of many interesting, fairly revolutionary consequences of such a system and I'd love to discuss them. Ultimately, if such a system ever made it out of research and into prototype, it could challenge both Java and .NET, and possibly stave off the coming hegemony of the Sun/Microsoft duopoly. (Yeah, yeah, there will always be people who enjoy working on nonvirtual machines, but they're crazy :-) Does anyone think some variant of this idea to be worth pursuing? Or is everyone wedded to the idea of working on the proprietary Sun platform known as Java? Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands,
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: J2EE considered harmful
On Fri, 2002-02-01 at 08:27, Paulo Gaspar wrote: This is getting interesting and we have e lot of pieces for this kind of puzzle around Apache. Why must standards be ruled just by the BigCo's??? De facto standards happen when a product is really good. This reminds me how the then tiny dog Borland turned Turbo Pascal into the de facto standard Pascal language in a couple of years. All Pascal language related products wanted to be compatible with it and not with whatever was the standard Pascal. All the big dogs had to run away. +1 Have fun, Paulo Gaspar -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:54 PM To: Jakarta General List Subject: RE: J2EE considered harmful From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]] Are you just talking about creating a new language, or what? What is your idea? I cannot tell. That's a good question, and ultimately one which would be determined by the constraints of the technology. Prototyping would probably involve using an existing language and platform, and maybe we would ultimately discover that it is possible to build a system like this on top of a JVM (or CLR). My suspicion is that it is not, and may be undesirable for legal reasons anyways. The later part of my diatribe was a hastily phrased way of approaching this subject: Unless you want to go back to the dark ages of C++, the future is shaping up to look like a choice between writing for the Sun platform or the Microsoft platform. This does not make me comfortable, especially considering that Sun's approach to Java so far has been *wholly* anathema to the principals of Open Source. At least Microsoft has submitted C# and the CLI to ECMA. Quoth Jon: *WAKE UP PEOPLE* I am tantalized by the idea of a third choice: the Apache platform. I propose a discussion of just what that might be. Jeff Schnitzer [EMAIL PROTECTED] -- 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: J2EE considered harmful
Hey Andrew Insteresting thread ;-) - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] On Fri, 2002-02-01 at 04:14, James Strachan wrote: Hi Jeff I share your oppinions on EJB. Whenever I ask developers why they are using EJB the common answer I get from people is 'well I get transactions for free'. When most of the time they don't do 2 phase commit with their database anyways. And all that extra work just to get 'acceptable' performance from EJB. Jeez this stuff is meant to help us not hinder us. I agree that EJB has shoved too many things together in one 'server side component' framework. Perhaps working from core specs is better and just choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias is to use 'local' object technologies such as Java Beans, Servlets, JDBC, JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP or whatnot) when distribution is required. I try to avoid RMI if truth be told. It seems so 80s ;-) I'm still not convinced at all that EJBs are even worth considering when when building web applications - why should be business logic be remote in a web-centric world? Why not deploy the business logic with the web I agree with everything but this. For scalability you should have the option but should not always use it. Agreed. Though I've 2 points to make. #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. Most business logic in most web applications is pretty minimal in terms of computation and is often mostly database intensive so moving this code to another process doesn't usually buy much in terms of scalability - if anything its the reverse thats true - what with all that EJB distributed garbage collection connection based protocol stuff that needs to be done scalability (and usually always performance) can go down. If your application will grow it is good to have a middle tier that can be moved and load balanced. With Entity beans of course this is less possible. (And stateful session beans ;-). I think this is true of traditional GUIs, say a Swing client front end, a middle tier server (say server side beans aka EJBs) and a database. I don't think this is true of web applications as they are quite different things - a servlet engine is not a 'GUI' client. Servlet engines are a stable, performant and very scalable application servers in their own right. Get a hardware load balancer and a farm of servlet engines and your *way* scalable. Arguing for the need for another, remote CORBA component-centric application server based on mostly connection-based protocols, RMI, stubs and distributed garbage collection to make your web-application more scalable seems, well, strange. In my experience web applications scale best when you have a big server farm of servlet engines which are load balanced. A database at the back and hopefully some kind of read only caching going on to take as much load off the poor database as you can. Then you can distribute parts of your web application into different server farms, get load balancing, shuffle things around as load changes etc. Then pick the web technologies of your choice, Struts, JSP, Velocity, Turbine etc. Away you go. I still don't see the 'scalability' argument as in any way advocating that EJBs are actually useful for web applications. In fact this idea that EJBs are required to build scalable web applications is plain false - probably marketing hype spread by the EJB vendors. James _ 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
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: J2EE considered harmful
Hi Jeff, -Mensaje original- De: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] [...] I've been giving a lot of thought to distributed object models lately. I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a lot of the same. Since networks are getting so fast these days, I'm starting to really wonder what it would be like to have a model in which: * All objects are inherently remotable. * Objects transparently migrate for efficiency. Welcome to the wonderful world of Mobile Agents. They suck. In our experience, the security concerns far outweigh the advantages of mobility. Anyways, that migration is only efficient in conditions of: - limited processing power. Instead of making computations on a PDA, you shift the agent to your server, perform the computations and then return with the results. This sci-fi scenario is a bit absurd, since you can just call a service that performs the same computations. - limited bandwidth. You shift the agent to the machine that is nearer to e.g. the database, so as to minimize communications. A good design already takes care of this problem, and nowadays, bandwidth is much cheaper than it used to be. I can think of many interesting, fairly revolutionary consequences of such a system and I'd love to discuss them. Ultimately, if such a system ever made it out of research and into prototype, it could challenge both Java and .NET, and possibly stave off the coming hegemony of the Sun/Microsoft duopoly. (Yeah, yeah, there will always be people who enjoy working on nonvirtual machines, but they're crazy :-) You can just check out JADE, it's a nice LGPL platform for mobile agents that can be programmed in JESS or Java. IMHO, not worth the trouble. Does anyone think some variant of this idea to be worth pursuing? Or is everyone wedded to the idea of working on the proprietary Sun platform known as Java? It's not 'with me or against me'. We can dislike J2EE, but not necessarily be keen on building a J2EE replacement. Un saludo, Alex.
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: J2EE considered harmful
You know, since Apache is a member of the J2SE group at Apache, it would make a lot of sense for us to develop a resource page regarding J2SE scalability. I'd be very happy to start and maintain such a page here, as I do for Struts. http://husted.com/struts/resources.htm If anyone has some starter links, send them along, and I'll get going. More importantly, we should also not hesitate to pubish our own orignal material, such as case studies, if anyone here wants to pass one along :-) Personally, like James, I think all the tools are already there, and much easier to deploy that bothering with EJBs. The vendor slove to say you get this-and-that for free, but the hidden costs are staggering, and in the end, it's obvious that you lose much more than you gain. Two steps forward, six steps back. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ James Strachan wrote: Agreed. Though I've 2 points to make. #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. Most business logic in most web applications is pretty minimal in terms of computation and is often mostly database intensive so moving this code to another process doesn't usually buy much in terms of scalability - if anything its the reverse thats true - what with all that EJB distributed garbage collection connection based protocol stuff that needs to be done scalability (and usually always performance) can go down. If your application will grow it is good to have a middle tier that can be moved and load balanced. With Entity beans of course this is less possible. (And stateful session beans ;-). I think this is true of traditional GUIs, say a Swing client front end, a middle tier server (say server side beans aka EJBs) and a database. I don't think this is true of web applications as they are quite different things - a servlet engine is not a 'GUI' client. Servlet engines are a stable, performant and very scalable application servers in their own right. Get a hardware load balancer and a farm of servlet engines and your *way* scalable. Arguing for the need for another, remote CORBA component-centric application server based on mostly connection-based protocols, RMI, stubs and distributed garbage collection to make your web-application more scalable seems, well, strange. In my experience web applications scale best when you have a big server farm of servlet engines which are load balanced. A database at the back and hopefully some kind of read only caching going on to take as much load off the poor database as you can. Then you can distribute parts of your web application into different server farms, get load balancing, shuffle things around as load changes etc. Then pick the web technologies of your choice, Struts, JSP, Velocity, Turbine etc. Away you go. I still don't see the 'scalability' argument as in any way advocating that EJBs are actually useful for web applications. In fact this idea that EJBs are required to build scalable web applications is plain false - probably marketing hype spread by the EJB vendors. James _ 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] -- 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: J2EE considered harmful
From: Andrew C. Oliver [EMAIL PROTECTED] #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. True, I don't like the Servlet approach. I tend to admire clean code and a Servlet approach makes this less likely (assuming the team is more than 1 guy and you have differing skill levels on the team). There are many ways to work with HTTP, servlets is just one. There are many others even just at Jakarta. JSP, Velocity, Struts, Turbine, Avalon, Cocoon etc. Incidentally having worked with various 'distributed models' such as CORBA and EJB I find Servlets the cleanest and best designed applicaiton server solution so far by quite some margin. There's a great open source implementation of the spec (Tomcat 4) and look at all the diversity in layers added on top to improve developer productivity. JMS is not appropriate for a number of areas. Like what? In truth I've not yet learned enough about SOAP to speak intelligently about it All I'll say is I think SOAP has a much better future than EJBs. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I'm not into XP, but often the scalability concern happens over night. There should be some framework in place for making it possible to do this somewhat suddenly. There should be a strategy yes. Though this doesn't advocate EJBs. (Though I don't think you are advocating them). I'd say you have about a weeks warning on most systems on just how much you need to scale up after deployment. Systems are make it or break it. You can apply techniques to make this more predictive, but a lot of this happens outside my area of control most of the time. (Political, socio-economic and chaos theory are involved which often result in unpredictable community size, and you must plan to be way off no matter how careful or disciplined your approach) Agreed. Scalability needs to be thought about seriously. I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. I'm more into a scalable version of the RUP. In my opinion XP is a hack of a methodology (the RUP actually covers most of its issues). XP also suffers from the misconception that programming is the most important activity in software development (I would argue requirements gathering as the most important activity in software development...programming is easy, figuring out WHAT to program is hard This is not to say I'm not into an iterative approach to this, only that I think XP is lacking. At least it admits its own lack of scalability.) One day I'll start a project to create a methodology that merges the disciplined approach to software that I admire with the opensource principles and approaches that I think are necessary for effective teamwork. (minus the flamewars ;-) ). Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just That is irrelevant to the issue. Not really but maybe I'm not expressing it properly. Using EJBs wastes *alot* of valuable developer time when they could be doing something more useful like adding new features, making things more scalable or making things more performant. I would like to see an adequate distributed system (which it looks like there are at least 2 in the works within or slightly external to our community), and EJB does not fit the definition. Agreed. because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. That doesn't mean you plug your fingers in your ears and say na na na scalability I'll refactor later. Agreed. I find a balanced approach between planing for the future and refactoring later works best. We do need an adequate distributed object system for some situations. Agreed - but like I said, they are pretty easy to do with HTTP, SOAP, JMS etc. It doesn't *have* to be EJB. That was my main point. Too many developers start building a web application and *start* with the EJB parts - rather than building the actual web application then seeing where EJB, JMS, SOAP or HTTP servers might help to distribute some of the load. I think this is true of traditional GUIs, say a Swing client front end, a
Re: Re: J2EE considered harmful
On Fri, 1 Feb 2002 18:35:55 - James Strachan [EMAIL PROTECTED] wrote. From: Andrew C. Oliver [EMAIL PROTECTED] #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. True, I don't like the Servlet approach. I tend to admire clean code and a Servlet approach makes this less likely (assuming the team is more than 1 guy and you have differing skill levels on the team). There are many ways to work with HTTP, servlets is just one. There are many others even just at Jakarta. JSP, Velocity, Struts, Turbine, Avalon, Cocoon etc. Of these I've used JSP, Struts and Cocoon. There are a few contributions I need to make to the other technologies documentation-wise before I'm ready/able to use them. From what I know of Velocity, Turbine, Avalon, they look very promising and I plan to use them in the future. Incidentally having worked with various 'distributed models' such as CORBA and EJB I find Servlets the cleanest and best designed applicaiton server solution so far by quite some margin. There's a great open source implementation of the spec (Tomcat 4) and look at all the diversity in layers added on top to improve developer productivity. JMS is not appropriate for a number of areas. Like what? UI, guaranteed failure situations. In truth I've not yet learned enough about SOAP to speak intelligently about it All I'll say is I think SOAP has a much better future than EJBs. From what I've read I'd tend to agree, though it looks...bulky. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I'm not into XP, but often the scalability concern happens over night. There should be some framework in place for making it possible to do this somewhat suddenly. There should be a strategy yes. Though this doesn't advocate EJBs. (Though I don't think you are advocating them). +1 I'd say you have about a weeks warning on most systems on just how much you need to scale up after deployment. Systems are make it or break it. You can apply techniques to make this more predictive, but a lot of this happens outside my area of control most of the time. (Political, socio-economic and chaos theory are involved which often result in unpredictable community size, and you must plan to be way off no matter how careful or disciplined your approach) Agreed. Scalability needs to be thought about seriously. I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. I'm more into a scalable version of the RUP. In my opinion XP is a hack of a methodology (the RUP actually covers most of its issues). XP also suffers from the misconception that programming is the most important activity in software development (I would argue requirements gathering as the most important activity in software development...programming is easy, figuring out WHAT to program is hard This is not to say I'm not into an iterative approach to this, only that I think XP is lacking. At least it admits its own lack of scalability.) One day I'll start a project to create a methodology that merges the disciplined approach to software that I admire with the opensource principles and approaches that I think are necessary for effective teamwork. (minus the flamewars ;-) ). Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just That is irrelevant to the issue. Not really but maybe I'm not expressing it properly. Using EJBs wastes *alot* of valuable developer time when they could be doing something more useful like adding new features, making things more scalable or making things more performant. +1! Like I said: EJB sucks. We need something better, not *similar* but in the same...space. A few postings to this list have indicated such things are in the works. I'll be studying them once I achieve a lower level of cycle utilization. I would like to see an adequate distributed system (which it looks like there are at least 2 in the works within or slightly external to our community), and EJB does not fit the definition. Agreed. because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. That doesn't
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: J2EE considered harmful (was [Fwd: cvscommit: jakarta-site2/xdocs index.xml])
I agree quite a lot with Andrew. In fact, I agree enough that I stopped using EJBs around the middle of last year because they are SUCH a pain to build and maintain, and because the performance sucks and there's nothing you can do about it, even if you pay the high premiums for advanced application servers. So, since there aren't really many alternatives I decided to make one as part of my open source project Open For Business (www.ofbiz.org or sf.net/projects/ofbiz). It's called the Entity Engine. The main idea behind it is: have an XML file that describes you data layout, and then handle generic persistence functionality through a single class. The GenericValue object works just like a value object in the EJB design patterns context but is Generic so you don't have to create one for every database table or combination of tables. It also handles View Entities to combine tables and a few other nice features such as JTA transaction support. The upside of it (which I was chasing) is that it is easy to change the data structure and have it update the database and the run-time data layout enforcement as well as immediately making new columns and such immediately available in the GenericValue objects. So, when you want to change something in the data layout, wham, it's done and you can move on to your application functionality. I don't know if it will ever become a standard and replace EJBs, but talk about this kind of tool has been going around for a while, and here is one implementation of those ideas that is being used in commercial deployments and is available open source. Even if it doesn't replace EJBs for everyone, it certainly has for me, and has saved me hundreds of hours and hundreds of thousands of lines of generated EJB code (no, I haven't written it by hand in a while, way too much work for stupid persistence code). Later, -David Jones -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: J2EE considered harmful
From: acoliver [EMAIL PROTECTED] On Fri, 1 Feb 2002 18:35:55 - James Strachan [EMAIL PROTECTED] wrote. JMS is not appropriate for a number of areas. Like what? UI, guaranteed failure situations. I don't follow. JMS/MOM is one of the only solutions where clients and servers work in a connectionless way - clients and servers don't need to be running at the same time. The system can handle failures gracefully, with persistent messages, retry, reconciliation, load balancing, fault tolerance etc. In truth I've not yet learned enough about SOAP to speak intelligently about it All I'll say is I think SOAP has a much better future than EJBs. From what I've read I'd tend to agree, though it looks...bulky. Agreed - though its a universal messaging format that can pass across all transports; which is kinda handy. So whether http/email/news/MOM is used you can connect anything to anything across diverse transports. I was just emphasizing that web applications are scalable - just add more boxes - and often they require quite modest hardware. EJB systems on the other hand can often need huge machines just to make quite simple systems. Agreed. I have fully stated: EJB sucks. However it would be nice to have something there where you can isolate your database resources into a pool of *servers* such as with any transaction processing system (going back to even DCE crap -- which did suck too, but served a purpose) Totally agree. I think adding TP type abilities to web/MOM/SOAP would be cool. So it looks like we basically agree. ;-) We're very verbose guys ;-) +10 ;-) James _ 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: J2EE considered harmful
From: James Strachan [mailto:[EMAIL PROTECTED]] (*) One thing I've noticed with SOAP is that developers from the different camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The web/MOM guys tend to think of SOAP as a universal message format so the same structured message can pass across many transports http/email/news/MOM to connect anything to anything in a language, platform and transport neutral way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its CORBA but using XML rather than IIOP and go off building stubs/proxies/IDL compilers etc just like with EJB/CORBA. I don't think web/MOM/SOAP and CORBA/EJB are comparable technologies. The former are communication protocols, and the latter are (primarily) programming APIs. To emphasize this point, in the .NET universe, the remote invocation protocols are pluggable... you can write to their distributed object model API and use SOAP, DCE-RPC, IIOP, JRMP, SMTP, or just about anything else you can dream up. For that matter, there is no reason why you couldn't create an EJB container which used HTTP/SOAP as the transport protocol. I would compare EJB to the programming API for your SOAP or MOM implementation. Theoretically EJB (or any distributed object model) provides a high-level abstraction so you don't need to fuss with the complexity of all the protocols and mechanisms underneath. Of course, the tradeoff is flexibility and performance. The problem with EJB, IMHO, is that it has merely replaced the complexity of the underlying system with the even greater complexity of the EJB system, and still significantly inhibits your ability to write well-performing applications. 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
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: J2EE considered harmful (was [Fwd: cvs commit: jakarta-site2/xdocs index.xml])
I've been lurking on this list for several years, and not speaking about things I'm not contributing to. But Andy's comment here about EJB J2EE goes right to the point, and triggers my passion ... As an architect, I've been in 5 projects in the last 2.5 years where EJBs were on the table, and in every case but one there have been overwhelming reasons to avoid getting involved with that kind of technology. And in the remaining case, it was already live when I came on board but thankfully the designer had not used Entity Beans, which made it almost tolerable. In the last project (a major customer-care callcenter app), they had used Entity Beans, and Websphere, and there were 500 EJBs, and 4700 distinct application classes. It took 2 days of continuous processing just to 'deploy' the beans, and I was called in when they found they couldn't meet adequate performance. Related, of course to the modelling of the database through Entity Beans. I won't go into the details, but believe me there were big problems in just about every area I looked at, not least developer productivity with the toolsets. My advice was unreservedly to junk both EJB and Websphere, since any competent designer could implement a solution with about a tenth of the complexity involved, and with no need for these opaque tools that you can't control. 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. The Pointy Haired Management are influenced by other views of the marketplace, of course, but they don't really make any sense if you can see where technology like this is likely to end up in the longer term. (i.e. replaced by something better). The rest of J2EE ? Well, Servlets is great, JSP is just about OK, (but of course you really wanted a templating engine). And among the rest of the APIs, there seem to be some that are OK, but an awful lot of it is pretty mediocre. Overall, it is Java *not* living up to its early promise. In summary, after a couple of years wondering 'Why am I the only person to see this ?' it's a relief to see Andy's post. I also remember seeing Jon's comment 'WAKE UP PEOPLE' a few weeks back (before Outlook trashed my mailbase) and though I think he is commenting on Sun's military strategy rather than the technicalities of EJB (am I right there ?) I do think that we need a much more public protest about the weakness of the technologies on offer - too many companies are forcing developers down the J2EE path. DotNet doesn't have to be the winner from such a protest, either. There are much better ways to do things, and at present customised solutions win hands-down on every count except 'common culture'. I know this is not much Jakarta related (unless Jakarta can take on J2EE directly ?), but it does seem a very important issue in the context of server-side Java. How much support exists for this point of view ? Does anyone have pointers for areas where rational discontent is brewing in a less 'humble' form ? - Tim - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 31 January 2002 01:58 Subject: Re: [Fwd: cvs commit: jakarta-site2/xdocs index.xml] On Wed, 2002-01-30 at 19:54, Jon Scott Stevens wrote: on 2002.1.30 4:15 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: My only issue and I guess this is directed more at you Jon, is it doesn't give me a clear idea about what we want. Can you give me a good idea and I'll be glad to submit a patch to that effect. It just seems like we should be asking for something and being specific. -Andy That is a very good point. However, privately, Sun knows exactly what we want. There is still some stuff that goes on behind the scenes around here that unfortunately isn't exposed. Needless to say, discussions about opening some of that up (including posting what we want to the public site) are going on now. For starters: I think the J2EE stuff should be under at least the same license as the rest of the JDK. Personally I'm having a hard time getting particularly in uproar as I think the central core of J2EE - Enterprise Java Beans is such a poor standard, that I'm not particularly upset that its not *free*. I should not say these things publicly, as I still have to work in these things, but in truth EJB and particularly Entity beans is a less that elegant kludge. In truth J2EE is kind of a scam. It claims to be aiming for compatibility and universality but the truth is the vendors play too big of a role in it. They want to have lots of room for proprietary extensions. Its market one thing but actually sell another. I'd rather see someone come up with an opensource standard
[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.
Re: J2EE considered harmful (was [Fwd: cvs commit: jakarta-site2/xdocs index.xml])
Andrew C. Oliver wrote: To be fair, WebSphere is probably more troublesome then the other containers (at least thats been my experience with it). I do think there is a time and place for RPC. I however think better support for location independence is required. (snip) I would suggest gaining experience with other containers (BEA and jBoss for starters, you can download a trial of the former and the latter is opensource) so that you can discriminate the problems that are exist in WebSphere from those in EJBs as a whole. Not because you want to just do not-ejb but so that you don't repeat the same mistakes. I have implemented a system using Container Managed EntityBeans that worked fairly well. I used Jonas (it was some time ago). It was smaller than the original poster example (about 20 entity classes, tens of thousands of instances). I spent a lot of time getting the entity design right. From the original description, it looks like the problems in the quoted project came from bad system design, more than from EJB technology as such. Comments on my experience: - The location and engine independence was a true marvel. I was developing with postgres/linux and deploying under MSSQLServer/NT with the same source code. Only small diffs in configuration needed. - Performance was not good, but scalability was. - Leaving transaction and persistence management to the container proved good at the end. - My main issue in the development were related with using JSP for the interface (JSP sucks (c) Jon :) ) So, while I agree with political/licensing issues being of concern, I would not disqualify EJB as a whole from a technological point of view. YMMV. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: J2EE considered harmful (was [Fwd: cvs commit: jakarta-site2/xdocs index.xml])
snip I have implemented a system using Container Managed EntityBeans that worked fairly well. I used Jonas (it was some time ago). It was smaller than the original poster example (about 20 entity classes, tens of thousands of instances). I spent a lot of time getting the entity design right. From the original description, it looks like the problems in the quoted project came from bad system design, more than from EJB technology as such. Comments on my experience: - The location and engine independence was a true marvel. I was developing with postgres/linux and deploying under MSSQLServer/NT with the same source code. Only small diffs in configuration needed. - Performance was not good, but scalability was. - Leaving transaction and persistence management to the container proved good at the end. - My main issue in the development were related with using JSP for the interface (JSP sucks (c) Jon :) ) So, while I agree with political/licensing issues being of concern, I would not disqualify EJB as a whole from a technological point of view. YMMV. My experience with Distributed Object Systems goes back to early CORBA and DCOM. I've seen about as many failures in just about every distributed system, regardless of technology flavour. EJB is just the latest, and as seems usual in our industry, lots of people are coming in, treating it as green field development, and are making the same mistakes. Mostly, they ignore that the choice of making a system distributed is fundamental. You can not take an Object Model and arbitrarily cleave it and produce a good Distributed Object Model. The worst case of this I ever saw was a system that had String as a CORBA object. EJB also brings to the table all of the problems of the Object/Relational impedance mismatch. It's an empirical fact at this point that rows in a table are bad objects. They're data, and have no behavior. Turning them into objects with container managed persistence doesn't make them good objects. Objects are composed out of many rows spanning several tables. That's hard to do with CMP. Just my $0.02. 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: J2EE considered harmful
At 12:36 PM 1/31/2002 -0500, Steve Downey wrote: EJB also brings to the table all of the problems of the Object/Relational impedance mismatch. It's an empirical fact at this point that rows in a table are bad objects. They're data, and have no behavior. Turning them into objects with container managed persistence doesn't make them good objects. Objects are composed out of many rows spanning several tables. That's hard to do with CMP. Just my $0.02. Well, if EJB (or others) are doing it wrong, it doesn't mean that Object Relational approach is bad. I agree that objects mapped straight to the rows one to one are not of much use by themselves. But they provide something that you will need to build your less fine grained objects, namely *persistence transparency*. By the same token you can say that any objects that use Java Bean pattern are useless, since all they have is get and set methods. But well, some people may like to concatenate SQL strings every time they want to get some data written or read to/from the database. The keyword here is productivity. ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik http://objectstyle.org list email: andrus-jk at objectstyle dot org personal email: andrus at objectstyle dot org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: J2EE considered harmful
*persistence transparency* = *waste of efficiency* There are no good systems that solve that yet. It only works for very simple schemas. Besides, (1) Not using that kind of layer does NOT mean that you have to concatenate Strings; (2) The use of Javabeans is abused. For (1) I use SQL generators for the most common operations and SQL templates - defined in an XML file - for the others. Having SQL defined outside the Java code often saves a lot of time and avoids the concatenation mess. For (2)... just go to the jakarta-commons mail archives and check the discussions about the DynaBeans stuff. Have fun, Paulo Gaspar -Original Message- From: Andrus Adamchik [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 8:43 PM To: [EMAIL PROTECTED] Subject: RE: J2EE considered harmful ... Well, if EJB (or others) are doing it wrong, it doesn't mean that Object Relational approach is bad. I agree that objects mapped straight to the rows one to one are not of much use by themselves. But they provide something that you will need to build your less fine grained objects, namely *persistence transparency*. By the same token you can say that any objects that use Java Bean pattern are useless, since all they have is get and set methods. But well, some people may like to concatenate SQL strings every time they want to get some data written or read to/from the database. The keyword here is productivity. ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik http://objectstyle.org list email: andrus-jk at objectstyle dot org personal email: andrus at objectstyle dot org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: J2EE considered harmful
A bit more of OT inline: =;o) -Original Message- From: Andrus Adamchik [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:50 PM To: Jakarta General List Subject: RE: J2EE considered harmful At 09:11 PM 1/31/2002 +0100, Paulo Gaspar wrote: (1) Not using that kind of layer does NOT mean that you have to concatenate Strings; Yes, am pretty sure there are ways to make life easier with SQL, sorry for bad comparison. No reason to be sorry. The traditional approach you pointed is a PITA. I am just mentioning alternatives. See, despite all of the skepticism about O/R mechanisms, I believe in this approach for one reason - I used a good O/R tool for major development for about 4 years now. I am talking about WebObjects. I believe this was the first application server out there (I think before even the term was coined). Now it lives in a relative obscurity since NeXT (the inventor of it) was bought by Apple, and Apple has no reputation for enterprise solutions. I always read good thinking about WebObjects. I am really getting curious about it. The bottom line here is that developer productivity goes up significantly. Code produced is incomparably easier to understand and maintain. And performance price is not that big (definitely not comparable to the impact EJB would make). UAU! Good performance too? I did read a lot about its productivity but nothing about performance. (2) The use of Javabeans is abused. Totally agree. Still does not make this pattern bad. One use is a transport mechanism for data between the application parts. Clean and easy to understand. Yes, but I think javabeans should be reserved for complex business logic where it shines on the clean easy aspects. For data transport a lot can be automated in Java using approaches like the Dynabeans. I mean, code like this: bean1.field1 = someOtherSource.getObject(field1); bean1.field2 = someOtherSource.getObject(field2); ... bean1.field47 = someOtherSource.getObject(field47); is really dumb and painful. Sorry for an OT post, this J2EE licensing discussion got a bit off hand. A lot of interesting discussions go on OT all the time. =;o) ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik http://objectstyle.org list email: andrus-jk at objectstyle dot org personal email: andrus at objectstyle dot org Have fun, Paulo Gaspar -- 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]
RE: J2EE considered harmful
Amusingly enough, I've been considering writing an article with this exact same title. I've implemented two medium-sized systems using EJBs (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've been haunting the ejb-interest list for more than a year. I was never ecstatic about the technology, but now I'm starting to feel downright disillusioned with it. This is not coming from someone stumbling around with the technology. The first thing I did was read Richard Monson-Haefel's book cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only implementation. I've got most of the 2.0 spec memorized. I have no trouble writing the deployment descriptors by hand. The problem is, even after more than a year of this, I still find that writing software using EJBs is a steady progress of fighting the technology to make it do what you want. It shouldn't be like this. Having to write three or four different classes, plus an elaborate deployment descriptor for each object slows things down a bit. Tools like xdoclet help, but it's still a complicated and painful process to refactor anything. Basic software design patterns are agonizing or impossible to implement. Observable? Time to learn JMS and Message-Driven Beans. Singleton? Not in the framework... you have to set up an external RMI server. Presistance in the EJBland is a disappointment. Even with EJB 2.0, entity beans are not remotely mature. There is no support for relationship attributes or automatically generated primary keys. The query language is constrictive, offering no support for ordering, aggregation functions, or retrieving data which spans more than a single class. After 20+ years of research and advancement in RDBMS technology, this is a colossal step backwards, and the consequence is that entity beans radically underperform systems with more direct database access. I find that I must constantly sidestep the container with direct JDBC in order to meet performance or feature requirements, and it sounds like this is a common problem. Overall, my feeling is that Sun tried to cram too many disparate technologies into a single API. EJB! It's a distributed object model, transaction model, security model, persistence model, component model, message queue, desert topping, and floor wax all rolled into one! Some of it makes sense, but some of it (especially persistence) doesn't. I'm surprised that people can build large applications with EJB. My guess is that it's probably very effective for one particular class of problem - ecommerce apps. I'm sure it's no accident that all the examples in the spec are Order, LineItem, etc. Unfortunately, this doesn't help me, or any of the rest of the people who are working on applications that are actually interesting. And my guess is that since ecommerce is 90% of the market for expensive app servers, Sun doesn't really care. Ok, enough whining. What to do about it? I really like the idea of an Apache community building a truly free competitor to J2EE. I don't like being tied to technologies owned by a single company, so I'm already pretty nervous by the stranglehold that Sun has on Java and (especially) J2EE. But it's not enough to build a marginal improvement over the existing system, even with Apache's mindshare. Besides, who wants to copy a mediocre idea? :-) I've been giving a lot of thought to distributed object models lately. I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a lot of the same. Since networks are getting so fast these days, I'm starting to really wonder what it would be like to have a model in which: * All objects are inherently remotable. * Objects transparently migrate for efficiency. I can think of many interesting, fairly revolutionary consequences of such a system and I'd love to discuss them. Ultimately, if such a system ever made it out of research and into prototype, it could challenge both Java and .NET, and possibly stave off the coming hegemony of the Sun/Microsoft duopoly. (Yeah, yeah, there will always be people who enjoy working on nonvirtual machines, but they're crazy :-) Does anyone think some variant of this idea to be worth pursuing? Or is everyone wedded to the idea of working on the proprietary Sun platform known as Java? Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: J2EE considered harmful
Are you just talking about creating a new language, or what? What is your idea? I cannot tell. At 12:38 PM 1/31/02 -0800, you wrote: Amusingly enough, I've been considering writing an article with this exact same title. I've implemented two medium-sized systems using EJBs (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've been haunting the ejb-interest list for more than a year. I was never ecstatic about the technology, but now I'm starting to feel downright disillusioned with it. Ok, enough whining. What to do about it? I really like the idea of an Apache community building a truly free competitor to J2EE. I don't like being tied to technologies owned by a single company, so I'm already pretty nervous by the stranglehold that Sun has on Java and (especially) J2EE. But it's not enough to build a marginal improvement over the existing system, even with Apache's mindshare. Besides, who wants to copy a mediocre idea? :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
