[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".
explore.gif
***********************************************************************
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.
***********************************************************************
explore.gif