William,
This is certainly very interesting, but hardly large scale. There may have
been a lot of activity, but the working set of objects must be pretty
constant so that EB caching gave you good performance. In a big system
(1000+ users), the overlap of objects across sessions would probably not be
so great, and server resources would be at a higher premium. At the great
dimensions of scale, you get pushed toward more stateless architecture. Old
wisdom, but it still holds...
-Chris.
> -----Original Message-----
> From: Louth, William (Exchange) [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 17, 2000 9:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Largest EJB Implementation ?
>
> [Randy Stafford] How about instead asking the question of whether
> there is a scalable, working, real-life implementation which uses *all*
> types of EJBs? What is "proper" use of EJB, anyway? I concur with you
> that
> entity beans are of dubious value in many scenarios, and that both entity
> beans and stateful session beans inhibit scalability. But, take the good
> and leave the bad.
>
> [Tom Udo] I'm wondering whether the use of Entity Beans is really only
> useful
> if you end up re-accessing the data a number of times.
>
> The last project I worked on used both session (stateful and stateless)
> and
> entity beans. The project's ( CORE - Cost Optimized Routing Environment)
> goal was to build a voice network management system which would allow a
> telecommunication to perform least cost routing on a 24 hour basis across
> 10
> main switching elements. This system was a replicate of the real world
> (ericsson switches) and allowed for users to see the exact steps through a
> our network a call would make. The steps could be viewed at a physical
> level
> (switches, trunk, port, compression devices) or logical (routing case,
> branch, program option, route...). Anybody coming from the
> telecommunications background will know that the amount of processing and
> objects involved in configuring a *whole* network to send calls from an
> acces point to some interconnect in line with policies relating to cost,
> quality... knows that how complex and computational intensive this is.
> Along
> with least cost routing we had optimal cost routing. You could view least
> cost routing as hotspot trying to improve a bad design and optimal cost
> routing as trying to build the perfect program and then running it with
> hotspot. I (solely) built this system in under 6 months (4 months
> development). I have been informed that a similar product took more than
> 12
> months with 4-6 persons. When I left the project (CORE ONE) the company
> was
> preparing to roll out the final release within 2 months.
>
> Though the user base is quite small (less than 50) the transaction load
> was
> quite intensive since we *heavily* mutlithreaded the client. The client
> was
> capable of executing 20-30 transactions simultaneously each of which would
> most likely access 100+ entity beans. When we deployed the system into
> production I had a big fight we IT Ops because the spec on the machine was
> low. They countered by saying OK lest stress test her and if she gives we
> give you more memory. Well we hit this server with ever user executing
> 20-30
> simultaneous transactions. They response times were between 2-4 seconds.
> This to me is a fast client. Comments coming back from the developer
> community within this large telecom included "I cannot believe Java could
> be
> this fast"...."This client just flows". The numbers of entity bean classes
> was 50+ if I can remember. We used alot of session beans both stateful and
> stateless.
>
> OK how did I achieve the impossible (well not so documented)?
>
> 1. Design - Design Patterns relating to distributed computing, human
> computer interaction, meta-programming, database design and Enterprise
> Java
> Beans. Designing for the user - usually meeting this gaol leads to a more
> efficient system.....
>
> 2. Develop - writing less code and letting the container do its stuff.
> This
> results in better quality and faster code since I can be more focused.
> Implementations of the design in the most efficient way and utilizing the
> great tool selection.....
>
> 3. Tools - JBuilder for writing code faster, profilers for writing faster
> code. Inprise Application Server 4.0 was designed for reducing the
> overhead
> associated with entity beans. Inprise has many features geared towards
> reduing the over head associated with persistence and method
> innovocations.
> Please visit their web site for further details....
>
> I could go on but I have not got the time ....but for those who want to
> see
> I attach a gif of the desktop that was delivered. This shows the users
> conceptual view of our entity beans in a explorer like tool. The
> conceptual
> view was pretty close to the entity beans model. For those who have
> listened
> to my going ons about the ugly user interface designs coming out of Web
> Logic I hope you see that I practice what I preach. The user interface,
> graphic design documentations, architecture, entity beans + session beans
> and database design was all done by one person - me. Who said that the
> days
> of one person building a product was over....with the right tools and
> language its still possible though there is a price to pay...my girlfriend
> was nearly leaving me.
>
> I have just finished an article for Java Report discussing the building of
> this system which should be printed in time for either Java One (Javasoft
> -
> San Francisco) or ICON 2000 ( Inprise - San Diego). See you there.
>
> kind regards,
>
> William Louth
> Inspired Consultany Limited
>
> <<explore.gif>>
>
> > -----Original Message-----
> > From: Tom Udo [SMTP:[EMAIL PROTECTED]]
> > Sent: Saturday, April 15, 2000 11:47 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Largest EJB Implementation ?
> >
> > This is getting real interesting.
> >
> > I'm wondering whether the use of Entity Beans is really only useful
> > if you end up re-accessing the data a number of times. Chris's
> > description reminds me of the old CICS style programming ie.
> > program is loaded, accesses database and performs lookup and
> > updates and then unloaded (with no sense of session state other
> > than a thing called a commarea which is a couple of K).
> >
> > If we think in terms of business 'components' we would
> > split all the business methods and then string them into sequences
> > which then form a business function. Typically these business methods
> > might
> > re-read the same data 'things' over and over (since each method is
> > independent of each other and hence needs to 're-establish' state).
> > In this case, if we weren't using data 'objects' but rather raw SQL
> > calls, we would have the overhead of re-issuing SQL calls against
> > the same rows in the table. I would have thought that data objects
> > would optimise this type of access since the first accesses would
> > result in the loading of the data into memory and then all
> > subsequent 'getters'/'setter' ('select'/'update')
> > would access the loaded data, thus saving the re-read/re-update
> > problem in non object architectures.
> >
> > If people aren't getting performance out of entity beans, could it be
> > because the overheads of getting the data only once are putting a
> > performance overhead that's not required ? If the business function
> > keeps going back to the entity data I would have thought that there
> > would be a performance gain (which would be higher the more re-use
> > of the data there is).
> >
> > Anamitra, I need to get my confidence back to since entity beans would
> > be a key to the usefullness of this architecture in scalable apps :-)
> >
> >
> > Any comments people ?
> >
> > -
> >
> > On Fri, 14 Apr 2000 11:38:02 -0700, Chris Raber <[EMAIL PROTECTED]>
> > wrote:
> >
> > >Ana,
> > >
> > >Your analaysis is correct. I don't know of an application of this
> > scale
> > >using Entity Beans. That doesn't mean there isn't one, I just don't
> > know
> > >about it! I am not sure how they handle session state in this
> > application,
> > >but I think they store sessions in the database, and key them by a
> > session
> > >id stored in a cookie or hidden field.
> > >
> > >However, I don't think that only using Session Beans mean that EJB
> > isn't
> > >providing value. The container is still managin transactions and
> > security.
> > >Plus the server/container is providing load balancing, redundancy etc.
> > You
> > >have to do more work to each these things using straight CORBA or RMI.
> > In
> > >the case of GemStone/J we have additional services of interest too
> > >(persistent cache...).
> > >
> > >IMHO, for systems doing transaction processing, EJB makes sense,
> > whether
> > >Entity Beans or not.
> > >
> > >Regards,
> > >
> > >-Chris.
> > >
> > >> -----Original Message-----
> > >> From: Bhattacharyya, Ana [SMTP:[EMAIL PROTECTED]]
> > >> Sent: Friday, April 14, 2000 1:28 PM
> > >> To: [EMAIL PROTECTED]
> > >> Subject: Re: Largest EJB Implementation ?
> > >>
> > >> Hi Chris
> > >> It seems to me that their usage of stateless session beans has given
> > them
> > >> a
> > >> such performance --- I really doubt whether they would have got such
> > >> scaleability if they needed to use stateful session beans/entity
> > beans.
> > >> Does
> > >> it point to the fact that their requirements were pretty simple or
> > they
> > >> did
> > >> some designs like maintaining sessions in the web server and not in
> > the
> > >> ejb
> > >> server??
> > >> I really dont get what value add I am getting from using EJBs if I
> > dont go
> > >> for entit beans or stateful session beans. AFAIK it is not a good
> > design
> > >> to
> > >> make the clients session aware --- and thats precisely why stateful
> > >> session
> > >> beans came into being. But then people say it is too slow and go
> > back to
> > >> 1> Either storing the session info in HttpSession in the servlets
> > engine
> > >> OR
> > >> 2> Storing session info in a hastable like data structure in the ejb
> > >> server
> > >> side -- something like a dependent object to the ejbeans.
> > >> ie back to square one!
> > >>
> > >> And also to me the benefit of using Entity beans comes only when I
> > go for
> > >> CMP aproach --- but then also performance issues come and people say
> > CMP
> > >> is
> > >> not developed!!
> > >> So the result is use stateless session beans --- and my question is
> > why
> > >> dont
> > >> I use simple RMI or CORBA to design my objects???
> > >>
> > >> Is there any example of a scalable, working real life implementation
> > which
> > >> use EJBs propely?? --- By properly I mean to say the implementation
> > uses
> > >> session beans (both stateless and stateful) to represent their
> > business
> > >> process and entity beans to represent business logic and business
> > data.
> > >> I need this to get back my confidence :)
> > >> cheers
> > >> Anamitra
> > >>
> > >> -----Original Message-----
> > >> From: Chris Raber [mailto:[EMAIL PROTECTED]]
> > >> Sent: Friday, April 14, 2000 1:09 PM
> > >> To: [EMAIL PROTECTED]
> > >> Subject: Re: Largest EJB Implementation ?
> > >>
> > >>
> > >> I don't have tons of data, but here are a few data points:
> > >>
> > >> - NetScape WEB servers
> > >> - Stateless Session Beans
> > >> - Oracle database
> > >> - 15 million hits per week
> > >> - 140,000 users
> > >> - 150,000 shipments per day
> > >>
> > >> Take this with a grain of salt, I am copying it from a mktg
> > presentation
> > >> on
> > >> this account. It gives us an idea of the scale of the thing though.
> > It's
> > >> pretty darn big.
> > >>
> > >> They run on Sun hardware. Not sure what models, but I believe they
> > are
> > >> mid-range servers.
> > >>
> > >> -Chris.
> > >>
> > >> > -----Original Message-----
> > >> > From: Jago, Robert [SMTP:[EMAIL PROTECTED]]
> > >> > Sent: Friday, April 14, 2000 10:53 AM
> > >> > To: [EMAIL PROTECTED]
> > >> > Subject: Re: Largest EJB Implementation ?
> > >> >
> > >> > Hello Chris.
> > >> >
> > >> > Do there exist actual numbers of performance, throughput,
> > peak
> > >> > load
> > >> > numbers for this?
> > >> > Not to mention infrastructure?
> > >> >
> > >> > Rob Jago
> > >> > Programmer/Designer
> > >> > Ottawa
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Chris Raber [mailto:[EMAIL PROTECTED]]
> > >> > Sent: April 14, 2000 10:28 AM
> > >> > To: [EMAIL PROTECTED]
> > >> > Subject: Re: Largest EJB Implementation ?
> > >> >
> > >> >
> > >> > <vendor>
> > >> > Ingram Micro's auction site is built on EJB (GemStone).
> > >> >
> > >> > It does zillions of hits per time unit bla bla bla... And the hits
> > do go
> > >> > through beans!
> > >> > </vendor>
> > >> >
> > >> > -Chris.
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Eddie Fung [SMTP:[EMAIL PROTECTED]]
> > >> > > Sent: Thursday, April 13, 2000 6:27 PM
> > >> > > To: [EMAIL PROTECTED]
> > >> > > Subject: Largest EJB Implementation ?
> > >> > >
> > >> > > Anyone know what the largest production EJB implementation is
> > out
> > >> there
> > >> > > (subject to non disclosure agreements of course) ?
> > >> > >
> > >> > > 'Largest' in terms of a mix of :
> > >> > > - transaction volume
> > >> > > - complexity (EJB side, not servlet/client side) ie. 'depth of
> > logic'
> > >> > > - database volumes
> > >> > >
> > >> > > I'm not interested in apps that have a million hits/minute with
> > very
> > >> > > little EJB (or at least simple) activity. That's high TP but not
> > >> 'deep'.
> > >> > >
> > >> > > When you read the literature and the J2EE Blueprint it is always
> > very
> > >> > > simplistic and I was interested in the current state of affairs
> > - EJB
> > >> > > still being 'bleeding' edge so to speak.
> > >> > >
> > >> > > thanks,
> > >> > >
> > >> > > Eddie
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> ==========================================================================
> > >> > > =
> > >> > > 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".
> > >>
> > >>
> >
> ==========================================================================
> > >> =
> > >> 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".
> >
> >
> ==========================================================================
> > =
> > 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". <<
> File: explore.gif >> << File: ATT32830.txt >>
===========================================================================
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".
