I disagree that compression is a "quick and dirty" solution. Obviously it depends on the particular requirements fo the application, but in many situations it is highly appropriate. If the requirement is for large amounts of data (obviuously "large" is releative here) and especially where the application developer has no control over the speed of the connection (e.g the internet), compression can be an excellent solution.
Compression/decompression essentially moves the performance problem from being outside the developers control (i.e. network throughput) to inside the developers control (overhead of compressing/decompressing). When the problem is in the latter domain, it can be adressed through the familiar means of scaling an enterprise application. Of course, as Juan pointed out, it is important to be sure that your application really does require this approach. Richard Martin On Tuesday 16 April 2002 07:02 am, Juan Pablo Lorandi wrote: > Ok, now the compression does make sense. > > Still, I would suggest you focus on a better way to communicate than > compression/decompression (the quick and dirty solution); perhaps a Web > Service; something that loads information on the client JIT and > minimizes round trips will provide much better performance than the > compression/decompression, as it will add a lot of latency to network > trips, BOTH ways. > > I can't remember any bibliography on the subject that applies directly > to J2EE (but I can remember a lot of MS DNA/.NET papers on the subject). > Take a look around at www.theserverside.com (I hope it's still there... > I've been out of circulation for 6 months or so...), hopefully you will > find more on the subject. > > HTH, > > Juan Pablo Lorandi > Chief Software Architect > Code Foundry Ltd. > [EMAIL PROTECTED] > > Barberstown, Straffan, Co. Kildare, Ireland. > Tel: +353-1-6012050 Fax: +353-1-6012051 > Mobile: +353-86-2157900 > www.codefoundry.com > > > -----Original Message----- > > From: SAMINATHAN [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 16, 2002 5:31 AM > > To: Juan Pablo Lorandi > > Subject: Re: Compression API in EJB > > > > > > Am sorry for not telling about my client. > > It is not web client.It is a swing client with JTable. > > It is stand alone application. > > > > We have web and palm client also but that not a problem.The > > major work is going to be done by Swing client. > > > > It is never going to cross more than 1 MB. > > > > Thanks and Regards > > Saminathan. > > > > > > ----- Original Message ----- > > From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]> > > To: "'SAMINATHAN'" <[EMAIL PROTECTED]> > > Sent: Tuesday, April 16, 2002 9:59 AM > > Subject: RE: Compression API in EJB > > > > > OK, by the look of your web site, seems like it could be heavy... > > > > > > How heavy? Say, 10 MB per record or so? Or are they MANY SMALL > > > records? > > > > > > Just curious, > > > > > > Juan Pablo Lorandi > > > Chief Software Architect > > > Code Foundry Ltd. > > > [EMAIL PROTECTED] > > > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > > Mobile: +353-86-2157900 > > > www.codefoundry.com > > > > > > > -----Original Message----- > > > > From: A mailing list for Enterprise JavaBeans development > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of SAMINATHAN > > > > Sent: Tuesday, April 16, 2002 5:01 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Compression API in EJB > > > > > > > > > > > > The data here is very heavy.And we are using EJB1.1. > > > > > > > > And our SLSB is a facade. > > > > > > > > Thanks and Regards > > > > Saminathan. > > > > > > > > ----- Original Message ----- > > > > From: "David Jones" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Monday, April 15, 2002 10:21 PM > > > > Subject: Re: Compression API in EJB > > > > > > > > > Hi, > > > > > > > > > > Reading through this thread I am also unsure why you > > > > > are compressing/uncompressing your data. In your > > > > > example the data is used to populate a form. It is therefore > > > > > unlikely that we are talking about a lot of data here (or am I > > > > > wrong?). Also I imagine your client and app server have a good > > > > > connection between them. > > > > > > > > > > If therefore the approach is to limit the amount of > > > > > data sent over the wire I would suggest looking at the > > > > > > > > classic Session > > > > > > > > > Facade pattern and EJB local interfaces as better solutions. > > > > > > > > > > David > > > > > > > > > > --- Juan Pablo Lorandi <[EMAIL PROTECTED]> wrote: > > > > > > Why compress anything? What does it accomplish? > > > > > > > > > > > > How is it an object stream? Do you mean an > > > > > > java.io.ObjectOutputStream ? If that's the case, just > > > > > > > > make sure the > > > > > > > > > > stream goes into a holder that is > > > > > > either Serializable or a primitive (for instance use > > > > > > java.io.ByteArrayOutputStream, then extract the byte array). > > > > > > Check the java docs for implications and > > > > > > considerations about it > > > > > > (interface is java.io.Serializable). Also check out > > > > > > the RMI > > > > > > documentation. > > > > > > > > > > > > By all means comment on why you want to compress an > > > > entity, and > > > > > > > > then decompress it on the client (which, I'm presuming, > > > > > > will benefit from a > > > > > > superb network connection to the App Server). Based > > > > > > on data I have, I > > > > > > think it'll negatively impact on performance. The > > > > > > rationale behind the > > > > > > design choice has me intrigued. > > > > > > > > > > > > Also, I'm posting this directly to EJB-INTEREST as I > > > > think the > > > > > > > > other post didn't make it to the list. > > > > > > > > > > > > > > > > > > > > > > > > Juan Pablo Lorandi > > > > > > Chief Software Architect > > > > > > Code Foundry Ltd. > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > > > > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > > > > > Mobile: +353-86-2157900 > > > > > > www.codefoundry.com <http://www.codefoundry.com/> > > > > > > > > > > > > -----Original Message----- > > > > > > From: SAMINATHAN > > > > > > [mailto:[EMAIL PROTECTED]] > > > > > > Sent: Monday, April 15, 2002 2:42 PM > > > > > > To: Juan Pablo Lorandi > > > > > > Subject: Re: Compression API in EJB > > > > > > > > > > > > > > > > > > Ok Sir, Let me explain further > > > > > > > > > > > > My client never has an access directly to the DAO.It > > > > should go > > > > > > > > thru minimum my SLSB. > > > > > > > > > > > > When i loading a form with the user requested > > > > > > record,i just need to get > > > > > > the data from ejbLoad(). > > > > > > Since it is bean managed am providing the value > > > > > > object to my ejbLoad() > > > > > > from my DAO. > > > > > > > > > > > > (My value object will contain collection of > > > > ect( > > > > > > basically it is > > > > > > > > > > parent -- child )) > > > > > > > > > > > > What i wanted to do is compress my value object and pass thru > > > > > > the bean layer. > > > > > > > > > > > > This i can only do on the form load, cause there is > > > > > > no business logic > > > > > > or operation involved in that. > > > > > > > > > > > > But in other case my beans are going to use my value > > > > object in > > > > > > > > that i don't want to do any jugglery. > > > > > > > > > > > > Now i have one question sir, i compressed my object > > > > > > now it has become a > > > > > > object stream , > > > > > > do i need to send my object as a stream? > > > > > > > > > > > > bye > > > > > > saminathan > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: Juan <mailto:[EMAIL PROTECTED]> Pablo Lorandi > > > > > > To: 'SAMINATHAN' > > > > > > <mailto:[EMAIL PROTECTED]> > > > > > > Sent: Monday, April 15, 2002 6:52 PM > > > > > > Subject: RE: Compression API in EJB > > > > > > > > > > > > Yes, it's YOUR data. Even if you're using CMP EBs, > > > > > > you can still > > > > > > compress your data, assuming you also decompress it > > > > accordingly. > > > > > > > > BUT, > > > > > > > > > > > > 1) You will lose search capabilities in the > > > > > > Persistance layer (a SQL > > > > > > query won't support compression) > > > > > > 2) Performance gains depend on the network (latency, > > > > bandwidth, > > > > > > > > availability) between the different parts of your > > > > application. > > > > > > > > On most applications this isn't generally true. Performance > > > > > > gains are simply the > > > > > > difference between compression/decompression time > > > > > > vs. network conditions > > > > and round-trips. It's impossible to even guess the > > > > > > > > scenario from the > > > > > > data you provide. > > > > > > 3) Your diagram seems to implicate the client has > > > > direct access > > > > > > > > to the DAO, thru the use of value objects. Why the EJBs > > > > > > then? > > > > > > > > > > > > Perhaps if you could explain more.... > > > > > > > > > > > > > > > > > > Juan Pablo Lorandi > > > > > > Chief Software Architect > > > > > > Code Foundry Ltd. > > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > Barberstown, Straffan, Co. Kildare, Ireland. > > > > > > Tel: +353-1-6012050 Fax: +353-1-6012051 > > > > > > Mobile: +353-86-2157900 > > > > > > www.codefoundry.com <http://www.codefoundry.com/> > > > > > > > > > > > > -----Original Message----- > > > > > > From: A mailing list for Enterprise JavaBeans development > > > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of > > > > > > SAMINATHAN > > > > > > Sent: Monday, April 15, 2002 10:36 AM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: Compression API in EJB > > > > > > > > > > > > > > > > > > Hi all > > > > > > > > > > > > I would like to know whether compression of > > > > > > object in EJB is allowed > > > > > > or not.Though am not directly going to use inside > > > > > > the bean. > > > > > > > > > > > > For example i have the follwoing architecture > > > > > > > > > > > > Client -----> SLSB -----> EB -----DAO -----DB > > > > > > > > > > > > |--------------------->VALUE OBJECT > > > > > > > > > > > > on Form load my ejbSelect will return me the value > > > > > > > > object.Since in > > > > > > > > > > my case it is a BMP my DAO's select method > > > > > > will return me the value object and i want to > > > > > > compress that before > > > > > > sending to entity --- Session and in the client > > > > > > code i will decompress > > > > > > and use it.Note am not doing any compression in my > > > > > > bean. > > > > > > > > > > > > And by doing this , will my performance and > > > > > > response time improve? > > > > > > > > > > > > Is there any known or unknown implication there in > > > > > > this? > > > > > > > > > > > > Thanks and Regards > > > > > > Saminathan. > > > > > > > > > > ===== > > > > > David J. Jones, <[EMAIL PROTECTED]>, > > > > > Virgin Mobile USA, > > > > > 8th Floor, > > > > > 22 Fourth Street, > > > > > San Francisco, > > > > > CA, 94103, Work: 415 932 5470. > > > > > USA. Fax: 415 358 4999. > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Yahoo! Tax Center - online filing with TurboTax > > > > > http://taxes.yahoo.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". > > > > > > > > ============================================================== > > > > ============= > > > > 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". ============================================================================== This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. All information is the view of the individual and not necessarily the company. If you are not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication and its attachments is strictly prohibited. If you have received this email in error please notify: [EMAIL PROTECTED] ============================================================================== =========================================================================== 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".
