Anyone know a good JMS mailing list? Sorry if you consider this to be off topic(although I'm sure the two specs will eventually combine). -----Original Message----- From: Louth, William (Exchange) [mailto:[EMAIL PROTECTED]] Sent: 09 March 2000 04:41 To: [EMAIL PROTECTED] Subject: Re: When to Use EJB? (was: Session EJBs vs. JavaObjects) Robert, I thought I had already said enough in my reply to Robs posting. Regarding the consultants view. Do you not agree that we are tainted by the ability of our tools i.e. our designs are in some way reflective of the design and implementation of our ejb container. As a Web Logic designer I would side with the many session bean and large grained (small number) entity bean design to achieve adequate performance and scalability. But with Inprise Application Server 4.0 I believe that my design will not be too far away from the domain design though I do not advocate that all domain objects be modelled as entity, but It is good to have some similarity. Also consider the fact that my persistence issue (bean + container managed ) will also be affected by my choice since currently there is really a big gap between what is offered in some servers in this regard. I have just finished what I would regard to be a technically great ejb project in a large telecommuncations company. The design of this system has won alot of praise for myself from the companies internal development team. The users love the tool (Java Application Client) and are very impressed with the performance. IS Operations are very happy with the management features and the whole systems scalability and performance. The initial project started out with 3 developers, 1 author, I project manager, 1 business analyst. After 2 months I had removed everybody and built the whole network management system myself (architect, developer, graphic designer, technical author) in 4 months while fighting of polictical battles. I do not think I could have achieved this great feat without the superior implementation of IAS and the great support from IAS R&D guys along with my natural design talent. I did not have to change my initial done (in my mind) before the choosing my ejb container....IAS just seem to support everthing I wanted to achieve in such a short time. Now my current client has had a different experience and do you know what they have good designers its just that their energies are not focused on the business logic but trying to get the plumbing to work...they do not have IAS and something similar (CORBA POA based) and when IT Ops get this system they are not going to be happy. my two cents. William > -----Original Message----- > From: Robert Patrick [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, March 08, 2000 2:40 AM > To: [EMAIL PROTECTED] > Subject: Re: When to Use EJB? (was: Session EJBs vs. JavaObjects) > > William, > > As Rob pointed out, this forum is a good place for technical > discussions. Regardless of whose application server you use, a design > that > uses entity beans must be given more thought and care than one designed > strictly with session beans if you want your application to be highly > scalable (the reasons to support this have been discussed extensively in > this list so I won't bother to repeat them). The fact that a BEA > consultant stated that he had never used entity beans has nothing to do > with BEA's position on entity beans; it probably has more to do with the > approach that the particular person uses to achieve his goal of building > highly scalable applications (after all, the diversity of solutions to a > particular problem is what keeps our jobs interesting). > > CORBA was not the silver bullet that solved all the problems related to > building enterprise-scale, distributed object applications (though it made > it easier). While EJB does build upon the CORBA work, it is not a silver > bullet either and you still need to apply good design principals. Entity > beans (and especially CMP EBs) are a great idea and have their place in a > distributed object application. I, personally, have found that too many > people try to use them in places where they are not appropriate just to > simplify the code they need to write (e.g., so they don't have to write > JDBC code and SQL). > > Just my two cents, > Robert > > At 07:34 AM 3/1/00 -0500, you wrote: > >I should point out that we recently had a Web Logic presentation in which > >their consultant informed us that he had never used entity beans and said > >that he thought stateless session beans where the way to go. Our response > >was, we might as well stick to our CORBA servers. > > > >William > > > > > -----Original Message----- > > > From: Louth, William (Exchange) > > > Sent: Wednesday, March 01, 2000 12:06 PM > > > To: 'A mailing list for Enterprise JavaBeans development' > > > Subject: RE: When to Use EJB? (was: Session EJBs vs. JavaObjects) > > > > > > Hi Assaf > > > > > > Tip 1: Care about your craft > > > Why spend your life developing software unless you care about doing it > > > well? > > > > > > Tip 2: Think! About your work > > > Turn off the autopilot and take control. Constantly critique and > appraise > > > your work > > > > > > Tip 9: Crtically analyse what you read and hear > > > Don't be swayed by vendors, media hype, or dogma. Analyse information > in > > > terms of you and your project > > > My View: Some of the advice being given on this list is reflective of > the > > > failings of current offerings from vendors who penetrated this market > > > early and which will be hampered by their existing architecture to > secure > > > any future. The future success of application server vendors depends > on > > > them adopting a more mature foundation i.e. CORBA than there current > RMI > > > implementations. This biased advice can be clearly seen in discussion > > > regarding Session Beans versus Entity Beans and Large Grain and Fine > > > Grain. > > > > > > Tip 11: DRY - Don't Repeat Yourself > > > Every piece of knowledge must have a single unambiguous authoritative > > > representation wihtin a system. > > > > > > The 10% overhead is form test we have conducted comparing Session > Beans + > > > SQL versus Session Beans versus Entity Beans. I can well believe that > you > > > might not believe these figures since nothing out there comes close to > IAS > > > 4.0. > > > > > > Now regarding your lean and mean machine....I cannot see how your JDBC > and > > > SQL code repeated both in a session bean and entity bean is lean and > mean. > > > I think I can turn out an application quicker by just using CMP and > not > > > writing any JDBC calls, not writing any SQL and not duplicating this > > > effort in 2 places. With this I also get tuned writes giving me great > > > performance while still keeping my code clean and to the point ... > > > business stuff. Now I am an advocate of refactoring but I try to only > > > refactor things which I could not have seen at the time. I try not to > > > create refactoring work for myself, this just seems pure laziness. > This > > > brings me ontop my favourite tip and one which I have been praticising > > > since the start of my career: > > > > > > Tip 38: Put abstraction in code, details in metadata > > > Program for the general case, and put the specifics outisde the > compiled > > > code base. > > > > > > I am abit taken back by your response since I have valued your other > > > contributions to this list. But I suspose we cannot always agree on > some > > > points, this being one. > > > > > > Kind regards > > > > > > William > > > > > > PS: I am not advocating that we should try to use entity beans always > for > > > example in some major overnight batching operation would not be ideal, > but > > > I do feel we should really give it more thought than is currently > > > happening. Also regarding performance tuning I believe that we should > put > > > less weight on the coding part and more on the design. To me the > coding > > > part is the icing on the cake but you first have to get the layering > and > > > structure correct. > > > > > > -----Original Message----- > > > From: Assaf Arkin [SMTP:[EMAIL PROTECTED]] > > > Sent: Wednesday, March 01, 2000 2:01 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: When to Use EJB? (was: Session EJBs vs. JavaObjects) > > > > > > The first rule in the pragmatic progammer book is get the damn thing > > > working as best as it can. > > > > > > Reusing code is one way to do it, you get less bugs, easier > > > maintainability, etc. > > > > > > But at the same time, code reuse tends to conflict with performance > > > issues. > > > > > > The J2EE model is filled with such contradictions. Entity beans are > > > simply not optimized compared to what JDBC can offer in terms of > > > performance, especially when it comes down to the GUI side doning a > lot > > > of queries, with only so much updates. > > > > > > And no, the overhead is not 10%. 10% is the overhead of entity beans > on > > > top of JDBC if you wrote the same code using JDBC. But you won't, with > > > JDBC you will write different code which is leaner and meaner, so the > > > overhead is substantially larger. > > > > > > Also, if you cut the EJB server altogether and go directly to JDBC, > the > > > difference is not 10%. > > > > > > arkin > > > > > > > > > > > > "Louth, William (Exchange)" wrote: > > > > > > > > So what your proposing is that we embed the database structure in 2 > > > places. > > > > One in the servlet or servlet/session bean and the other in the > entity > > > bean > > > > persistence descriptor. Is there not some rule in the Pragmatic > > > Programmer > > > > book about not duplicating such things. I have not got the book with > me > > > at > > > > the moment but I am sure its there anyway let common sense prevail > for > > > the > > > > time being. > > > > > > > > I have already posted a summary of a report which showed that using > IAS > > > 4.0 > > > > that the overhead of using session bean talking to CMP entity beans > > > (large > > > > collection) was small, less than 10%. I can trade that 10% against > > > future > > > > maintenance and the all rest that comes with this approach. But I > > > suspose If > > > > you are not using IAS 4.0 you better start writing SQL considering > that > > > > using this method with other servers resulted in a 1800% overhead. > > > > > > > > William Louth > > > > > > > > > -----Original Message----- > > > > > From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]] > > > > > Sent: Sunday, February 27, 2000 12:56 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: When to Use EJB? (was: Session EJBs vs. Java > > > Objects) > > > > > > > > > > Doug has hit the nail on the head. EJB is appropriate for high > volume > > > > > transactional sites like an electronic trading site, but for sites > > > that > > > > > provide > > > > > read-only access to product catalogs or primarly textual material > > > > > (documents, > > > > > articles, etc..) with no transactional requirements, Servlets and > JSP > > > is a > > > > > better option. You should use EJB to handle purchases and > > > transactions on > > > > > these > > > > > types of sites, but not for perusing the content. > > > > > > > > > > -- > > > > > Author of Enterprise JavaBeans > > > > > Published by O'Reilly & Associates > > > > > http://www.EjbNow.com > > > > > > > > > > EJB FAQ > > > > > http://www.jguru.com/faq/EJB > > > > > > > > > > > > > > > "Bechtold, Douglas" wrote: > > > > > > > > > > > I hate to speak for Richard, but I think his point is that for > > > read-only > > > > > > queries that are basically transaction-free that EJB is perhaps > more > > > > > > overhead than is needed. I am working on exactly such a system > > > where we > > > > > are > > > > > > considering using Servlets for queries that are for read-only > > > purposes > > > > > and > > > > > > EJB for updates. If the query is for reading / writing, then > the > > > > > "overhead" > > > > > > that EJB comes with is not an issue because of all of the other > > > benefits > > > > > > that come with EJB. > > > > > > > > > > > > DB > > > > > > > > > > > > -----Original Message----- > > > > > > From: Frank D. Greco [mailto:[EMAIL PROTECTED]] > > > > > > Sent: Thursday, February 24, 2000 9:26 AM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: When to Use EJB? (was: Session EJBs vs. Java Objects) > > > > > > > > > > > > >Ahi Satapathy wrote: > > > > > > >> So when EJB should be used ? what should be the factor one > > > should > > > > > > consider > > > > > > >> before going to implement something with EJB ? If the site > is > > > not > > > > > > >> transactional, has no authorization security needs, and is > read > > > > > only, > > > > > > should > > > > > > >> one go for simple Java Objects and use Servlets with direct > JDBC > > > > > access > > > > > > ?? > > > > > > > > > > > > At 05:13 PM 2/20/00 -0600, Richard Monson-Haefel wrote: > > > > > > >In a word, "maybe". You need an experienced architect > (consult > > > your > > > > > > >physician) to review your system and make a recommendation. > Most > > > > > > >high volume sites (Amazon, eToys, et.) that have a lot of read > > > only > > > > > > > > > > > > High volume as in number of concurrent visitors or > number of > > > > > > transactions? Or high volume as in page throughput or > http > > > (or > > > > > > socket) throughput? > > > > > > > > > > > > >navigation and no transaction needs for the reads, should be > > > > > implemented > > > > > > >with something other then EJB - I like servlets. BUT, the > > > purchasing > > > > > > > > > > > > Theoretically EJB can be used for high-volume sites like > an > > > > > > electronic > > > > > > trading system. Architecturally, as part of an App > Server > > > > > product, > > > > > > EJB > > > > > > should not be fundamentally slower than > > > > > Servlet/JDBC/JavaClasses. > > > > > > The > > > > > > vendor app server product should be able to scale much > > > better > > > > > than a > > > > > > home-grown solution. If the home-grown solution is > > > superior... > > > > > then > > > > > > I > > > > > > want to get in on the IPO... ;) > > > > > > > > > > > > >of goods and services on these sites should be implemented > with > > > EJB > > > > > via > > > > > > Servlets. > > > > > > > > > > > > Actually, are there 'rules of the road' for this stuff? > > > What > > > > > are > > > > > > the > > > > > > heuristics for choosing a AppServer/EJB(et al) over a > > > > > > WebServer/Servlets? > > > > > > > > > > > > Frank G. > > > > > > > > > > +======================================================================+ > > > > > > | Crossroads Technologies Inc, 55 Broad Street, 28th Fl, NYC, NY > > > 10004 | > > > > > > | Dot-com Engineering > > > | > > > > > > | Email: [EMAIL PROTECTED] Web: > > > www.CrossroadsTech.com | > > > > > > | Voice: 212-482-5280 x229 Fax: 212-482-5281 > > > | > > > > > > > > > > +======================================================================+ > > > > > > > > > > > > > > > > > > > > > ========================================================================== > > > > > = > > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include > in > > > the > > > > > body > > > > > > of the message "signoff EJB-INTEREST". For general help, send > email > > > to > > > > > > [EMAIL PROTECTED] and include in the body of the message > "help". > > > > > > > > > > > > > > > > > > > > > ========================================================================== > > > > > = > > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include > in > > > the > > > > > body > > > > > > of the message "signoff EJB-INTEREST". For general help, send > email > > > to > > > > > > [EMAIL PROTECTED] and include in the body of the message > "help". > > > > > > > > > > > > > > ========================================================================== > > > > > = > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in > the > > > > > body > > > > > of the message "signoff EJB-INTEREST". For general help, send > email > > > to > > > > > [EMAIL PROTECTED] and include in the body of the message > "help". > > > > > > > > > *********************************************************************** > > > > Bear Stearns is not responsible for any recommendation, > solicitation, > > > > offer or agreement or any information about any transaction, > customer > > > > account or account activity contained in this communication. > > > > > *********************************************************************** > > > > > > > > > > > > ========================================================================== > > > = > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in > the > > > body > > > > of the message "signoff EJB-INTEREST". For general help, send email > to > > > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > > -- > > > ---------------------------------------------------------------------- > > > Assaf Arkin www.exoffice.com > > > CTO, Exoffice Technologies, Inc. www.exolab.org > > > > > > > ========================================================================== > > > = > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > > > body > > > of the message "signoff EJB-INTEREST". For general help, send email > to > > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > >*********************************************************************** > >Bear Stearns is not responsible for any recommendation, solicitation, > >offer or agreement or any information about any transaction, customer > >account or account activity contained in this communication. > >*********************************************************************** > > > >========================================================================= > == > >To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > >of the message "signoff EJB-INTEREST". For general help, send email to > >[EMAIL PROTECTED] and include in the body of the message "help". > > ========================================================================== > = > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". *********************************************************************** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *********************************************************************** =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". *** This e-mail is intended only for the addressee. This e-mail and any files transmitted with it may contain confidential or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please contact [EMAIL PROTECTED] This e-mail has been scanned by MIMEsweeper. Visit the Prebon Yamane web site at http://www.prebon.com *** =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
