Randy I hope if you dont mind that I only answer one question for now since
I am just heading out the office door at 9.45 pm. I mistakely posted this
directly to dan.
===========================================================
Hi Dan,
I used a stateful session bean when we needed to perform the least cost
routing use case. This task initially requires a massive amount of
computation which can be subsequently cache across the user interactions.
The data was too large to be moved to the client. The user will then
interact with this server model by setting different policies (cost, quality
of service, rerouting, load balancing....) to see the outcome. The changing
of the values requires some parts of the model to be re-evaluated. When this
is done the streamlined results are then sent back to the client. So in
summary when you have a large amount of data but the client requires only a
summary view do the processing on the server let the user interact with it
in a minmialist fashion and then return the results. The benefit of this was
that we did not have to stream the whole model back across the server and we
could update the model relatively quickly after an certain interval (timeout
which can be set by the user) without having to send out some jms for
clients to poll data. Hope this is a bit more helpful.
=====================================================================
I am sure you will have more questions
William Louth
> -----Original Message-----
> From: Randy Stafford [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 18, 2000 9:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Largest EJB Implementation ?
>
> William-
>
> First of all, assuming roll-out in two months, congratulations on
> achieving
> production deployment of a system that is well-received by its users.
> That
> event is rare enough in our prefession, eh?
>
> Next, thanks for sharing the information on your project. I second Dan
> O'Connor's wish to see more of this kind of post on the list. I want to
> make sure I'm understanding this correctly. You have 50 (max) concurrent
> clients times, say, 25 concurrent "transactions" each, with an average
> response time of, say, 3 seconds. Are these read transactions or write
> transactions? Does *each* client thread deal with 100 (separate) entity
> bean instances, or does one client as a whole deal with 100 entity bean
> instances? How many session bean instances are used per client? I'm
> assuming the clients don't begin a new set of transactions immediately
> upon
> getting the responses to the previous ones - what is the average wait time
> per client between transaction sets? Have you computed the average number
> of write transactions per second? Assuming 100 entity beans per client
> and,
> say, 10 session beans per client, it sounds like your container is
> managing
> a maximum of 5500 EJBs concurrently, and it is not clear what the
> transaction volume is.
>
> Like Dan O'Connor I'm also curious as to why you went with stateful
> session
> beans when you had a Swing GUI available to hold onto conversational
> state.
>
> Thanks again, and best regards.
> Randy Stafford
> Senior Architect
> GemStone Professional Services
>
> > -----Original Message-----
> > From: Louth, William (Exchange) [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, April 17, 2000 7: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".
