One last note the objects listed below only account for the logical routing
use case in the systems and not to network inventory and offer analysis.....
William Louth
> -----Original Message-----
> From: Louth, William (Exchange) [Louth, William (Exchange)]
> Sent: Monday, April 17, 2000 5:35 PM
> To: 'A mailing list for Enterprise JavaBeans development'
> Subject: RE: Largest EJB Implementation ?
>
> Hi,
>
> Well I considered it big enough considering that for every day of the year
> (365) we had 400 routing cases and 200 BOrigin Options for each of the 9
> switches. For each routing case we had on average 3.5 branches. For ever
> branch we had 4 program options. Most of the users will be handling
> queries relating to customer (large customer care centers) routings during
> 1 month period. This equates to
>
> 21 x 9 = 180
> 21 x 9 x 400 = 75,600
> 21 x 9 x 200 = 37,800
> 21 x 9 x 400 x 3.5 = 264,600
> 21 x 9 x 400 x 3.5 x 4 = 1,058,400
>
> 1.4 million objects
>
> A bit bigger than your average contact or address book system. If you
> understanding the complexity associated with routing you will see that
> alot of the graph will have to be accessed. Though not on the scale of
> amazon but useful. Would you agree that if you did not have a good
> persistence engine that this would not be possible. My post was to show
> that entity beans can be used for quite large systems. Can it handle
> millions of clients well I recently seen a post by inprise regarding there
> TPC-W bencmark which I believed used some entity beans ...I could be
> wrong.
>
> Thanks for finding it interesting. I am quite proud of what I achieved
> considering at the time ejb 1.1 was just out (June last year) and that I
> went with an alpha product (Kodiak - Inprise Application Server) over the
> current crop of ejb1.0/web app servers. I kept to my belief that a CORBA
> infrastruture would ensure a more scaleable, reliable and better
> performing container and that the vendor choosen would deliver. I was
> proven right.
>
> kind regards,
>
> William Louth
>
> -----Original Message-----
> From: Chris Raber [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 17, 2000 3:53 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Largest EJB Implementation ?
>
> 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".
***********************************************************************
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".
