The email you sent was not deliverable as addressed. Please review the address and resubmit if necessary. This message has been sent courtesy of BuyDomains.com - The World's Leader in Domain Registration. BuyDomains offers Web address registration for $16 per year or less from our Website http://www.buydomains.com. This low price includes ALL registrar fees, toll free technical support, forwarding of purchased domains to an existing URL, unlimited email forwarding, and an online control panel to manage your registration details and DNS servers. With BuyDomains at your service you will never need to pay a monopoly $70 for domain registration again! (original mail to [EMAIL PROTECTED]) A Mailing List For Enterprise Javabeans Development <[EMAIL PROTECTED]> writes: >There are 10 messages totalling 486 lines in this issue. > >Topics of the day: > > 1. is there any resource on middleware? (2) > 2. different way of thinking > 3. EJB Object implementation (2) > 4. Alternative to EJB Callbacks > 5. composite primary key mapping in the J2ee > 6. problem with running in jBuilder (2) > 7. composite primary key in J2ee RI > >=========================================================================== >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". > > >---------------------------------------------------------------------- > >Date: Sat, 25 Nov 2000 22:22:34 +0800 >From: que <[EMAIL PROTECTED]> >Subject: is there any resource on middleware? > >Dear All, > Can someone tell me where I can find some resource on middleware, >the incentive (why), the key design rules (how)? > Thanks in advance. > >Best&Regards, > Que > >------------------------------ > >Date: Sat, 25 Nov 2000 09:35:03 -0500 >From: Dave Wolf <[EMAIL PROTECTED]> >Subject: Re: different way of thinking > >Cedric, > >I understand his concern, my point is if this is the pattern you are going >to use, dont use an RMI type especially where there is a large object graph. >Why not use an IDL type, save the painful performance of the serialization, >not change the design pattern and at the same time open your application to >interoperability with non EJB systems if the need ever arises. This of >course assumes you use a container which is properly implementing RMI/IIOP >and not just a proprietary serialization implementation over IIOP, even for >IDL types. > >For instance, in simple tests I show a 25% to 50% performance boost in >marshalling the IDL type of the serialized RMI type. This is FREE >performance, so why not take advantage of it, in those containers which >allow you to take advantage of it? > >The only solution I can see to solve what he wants is to not use value >objects and pass remote references to controllers which wrap the entities. >These would indeed be passed by reference. However, Im not sure this is any >better a pattern in total. > >Dave Wolf >Internet Applications Division >Sybase > > >----- Original Message ----- >From: "Cedric Beust" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, November 24, 2000 11:11 PM >Subject: Re: different way of thinking > > >> > From: A mailing list for Enterprise JavaBeans development >> > [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf >> >> > Why not pass an IDL type. Via RMI/IIOP you would get a serious >performance >> > boost by marshalling the structural type as an IDL type thus avoiding >the >> > overhead of serialization without the added overhead of the RMI call. >> >> Whether you're using standard serialization, proprietary serialization or >IIOP >> doesn't change much to the fact that you're sending the whole state of the >object >> on the wire, which is precisely what the original poster is questioning... >> >> -- >> Cedric >> >> >=========================================================================== >> 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". >> >> > >------------------------------ > >Date: Sat, 25 Nov 2000 09:38:31 -0500 >From: Dave Wolf <[EMAIL PROTECTED]> >Subject: Re: EJB Object implementation > >Picture the EJBObject as an abstract idea rather then a physical >implementation. Its easier to understand, and since each container vendor >can implement it however they want, its more accurate. For instance, an >application server written in Java will implement this very differently then >say one written in C like EAServer to optimize the peformance of this >dispatching. The point to keep in mind is that the EJBObject is the logical >implementation of the servant and acts as a glue to the physical bean >instances. > >Such as an entity bean in contaienrs like EAServer which create multiple >physical instances to represent single EJBObjects, like a row in a database. >The EBJObject I find easier to think about in a logical way rather then how >did that vendor physically implement it. > >Dave Wolf >Internet Applications Division >Sybase > >----- Original Message ----- >From: "Ashutosh" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, November 24, 2000 1:03 AM >Subject: EJB Object implementation > > >> Hello all, >> I am trying to understand the concept of the EJB Object . I >> have the following question. >> I read that the EJBObject whose implementation is provided by >> the container also implements the Remote Interface.The EJB Object holds a >> reference to the Bean class. However, the Bean class provides the >> implementation for the business methods that are declared in the remote >> interface(but it does not "implement" the RI but only extends EntityBean). >> So, can i infer that EJBObject has an empty definition of the >> business methods and through these methods gives a call to the >corresponding >> methods of the bean class whenever the client invokes the method. >> I understand that the container provides the >implementation >> of the ejb object and it could be different across various containers. But >> how does it work i this case??? >> Thanks. >> Regards, >> Ashutosh >> >> >=========================================================================== >> 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". >> >> > >------------------------------ > >Date: Sat, 25 Nov 2000 09:40:30 -0500 >From: Dave Wolf <[EMAIL PROTECTED]> >Subject: Re: Alternative to EJB Callbacks > >Only if it is the server which has the onus of assuring message delivery. >Via a blocking registration pattern where the client spawns a synchronous >thread, you completely avoid the impact on the server in handling the >message delivery. In essence the clients can pull the information in their >own threads and the onus of message delivery is with the interested party, >the client, and not the server. > >Dave Wolf >Internet Applications Division >Sybase > >----- Original Message ----- >From: "William Louth" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, November 22, 2000 10:22 AM >Subject: Re: Alternative to EJB Callbacks > > >> Robert, >> >> The problem with callbacks is that your servers performance is now >affected >> by your clients performance in handling the callback invocation i.e. >> synchronous communication. Typically your client will not be on running on >> the same hardware specification than your appserver though it probably >> doesn't have the same load. Whereas currently it takes 20 seconds to >perform >> the task it could end up alot higher. You need to break this coupling i.e. >> decouple. Some of the ways to do this include using JMS or some event >> service like CosEvents and posting a message/event on the status on the >> operation. You have some flexibility with the implementation of this in >both >> JMS and CosEvents. >> >> Another option off the top of my head could be to use an entity bean to >> handle the communication between session bean and client. In this case the >> client could provide some id to the session bean that would be used to >> create an Progress entity bean that the session bean would write too i.e. >> setData(50,"Current Phase:......") where the first parameter is the >> percentage of the task completed and the the second is the message to >> display. The client would periodically poll for the status of the task >> through some other session bean providing it would the id of the task. The >> polling from the client could be tuned in line with the users feedback >> requirements and possibly customized by him/her. At the end the session >bean >> executing the task would remove the entity bean. The bean could even be >used >> to cancel a long running transaction if at certain phases in the session >> beans execution it check the progress beans status field. The client could >> cancel the operation through a session bean that updates the entity bean >> status falg with something like 'abort' or 'cancel'.There is still >> performance problems since you do need to make the event persistent and >some >> messaging implementations bypass this and offer non-guaranteed delivery >for >> the sake of better performance and throughput. Note you will need to run >the >> update on the progress entity bean with another transaction than the >session >> bean. >> >> I am sure somebody out there has probably implemented something similar, >> much more generic and sophisticated, in beta form but open-sourced. >> >> Having said all of this I think a transaction taking 20 seconds is not >> typical of the usage of Enterprise JavaBeans could you tell us more about >> this. There might be other ways to solve this problem than the above >> mentioned and at the same time reduce the turnaround. With 20 seconds you >> will increase the likelihood of collisions with other transactions. The >> holding onto the database resource can limit your scalability and increase >> the work load for your database server since it will need to use large >> amounts of memory storage to support the transaction requirements. >> >> regards, >> >> William Louth >> Borland/Inprise >> www.inprise.com/appserver >> >> -----Original Message----- >> From: A mailing list for Enterprise JavaBeans development >> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Hargreaves >> Sent: Tuesday, November 21, 2000 8:07 AM >> To: [EMAIL PROTECTED] >> Subject: Alternative to EJB Callbacks >> >> >> Hi all, >> >> We have a requirement in out application where need to continually update >a >> progress bar on the client screen whilst the EJB App Server performs a >task >> (a single remote method call to a stateless session bean) which lasts >about >> 20 secs. The ideal way to do this would be to use a callback method that >> updated the client at regular intervals, say every second, from the >session >> bean. This can be done with standard RMI but our app server has its own >> version RMI that means we can't do this. >> >> What other alternatives are there to callbacks. I've read somewhere you >can >> get similar functionality with EJB2.0 Message Beans and/or JMS, but aren't >> these overkill for a progress bar? >> >> Any help would be greatly appreciated, >> >> Rob Hargreaves >> >> >=========================================================================== >> 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". >> >> > >------------------------------ > >Date: Sat, 25 Nov 2000 22:52:10 +0530 >From: Suresh Ajja <[EMAIL PROTECTED]> >Subject: composite primary key mapping in the J2ee > >Hello everybody, >the IDE is Jbuilder4.0, >I found this error, while runnning the client. >It deployed correctly on Jbuilder, but can't figure out this problem. >TCarBean is the Entity bean, CMP >Client Application. > >" java.lang.ClassCastException: com.inprise.vbroker.rmi.CORBA.ObjectImpl at >sample.TCarTestClient.<init>(TCarTestClient.java:30) at >sample.TCarTestClient.main(TCarTestClient.java:47) " > >help needed, any body pls. > >------------------------------ > >Date: Sat, 25 Nov 2000 22:54:42 +0530 >From: Suresh Ajja <[EMAIL PROTECTED]> >Subject: problem with running in jBuilder > >Ignore Earlier question > >Hello everybody, >the IDE is Jbuilder4.0, >I found this error, while runnning the client. >It deployed correctly on Jbuilder, but can't figure out this problem. >TCarBean is the Entity bean, CMP >Client Application. > >" java.lang.ClassCastException: com.inprise.vbroker.rmi.CORBA.ObjectImpl at >sample.TCarTestClient.<init>(TCarTestClient.java:30) at >sample.TCarTestClient.main(TCarTestClient.java:47) " > >help needed, any body pls. > >------------------------------ > >Date: Sat, 25 Nov 2000 15:53:09 +0100 >From: francis pouatcha <[EMAIL PROTECTED]> >Subject: Re: EJB Object implementation > >Hi, >the EJBObject is part of the container and the ejb-spec define the >behavior of the container without making any assumption it >implementation. The more important for you is not to know how they are >implemented (since it changes from one container to another), but to >know (and make sure) that they do the same work. > >/Francis > >Ashutosh wrote: >> >> Hello all, >> I am trying to understand the concept of the EJB Object . I >> have the following question. >> I read that the EJBObject whose implementation is provided by >> the container also implements the Remote Interface.The EJB Object holds a >> reference to the Bean class. However, the Bean class provides the >> implementation for the business methods that are declared in the remote >> interface(but it does not "implement" the RI but only extends EntityBean). >> So, can i infer that EJBObject has an empty definition of the >> business methods and through these methods gives a call to the corresponding >> methods of the bean class whenever the client invokes the method. >> I understand that the container provides the implementation >> of the ejb object and it could be different across various containers. But >> how does it work i this case??? >> Thanks. >> Regards, >> Ashutosh >> >> =========================================================================== >> 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". > >-- >[EMAIL PROTECTED] > >MATHEMA Software GmbH >N�gelsbachstra�e 25 b >91052 E r l a n g e n >D e u t s c h l a n d >Tel +49(0)9131/8903-0 >Fax +49(0)9131/8903-55 >http://www.mathema.de > >------------------------------ > >Date: Sat, 25 Nov 2000 23:04:50 +0530 >From: Suresh Ajja <[EMAIL PROTECTED]> >Subject: composite primary key in J2ee RI > >I have a table, three CMP fields, >transId(FK), carName(PK), carcode name >TcarPk, is the class which holds these two(transId, carName) fields. >J2ee does not support composite primary key, returned as a class. how do I >go abt in changing the DD, if any other method to accomplish the task of >passing composite keys, needed. >Help needed >Suresh > >------------------------------ > >Date: Sat, 25 Nov 2000 09:14:04 -0800 >From: Jonathan Weedon <[EMAIL PROTECTED]> >Subject: Re: problem with running in jBuilder > >Suresh, > >Please take product specific questions to product specify news groups. >For our product, please go to: > > news://newsgroups.inprise.com/inprise.public.appserver > >That said, I can quickly suggest that you have not use the requisite >call to: > > javax.rmi.PortableRemoteObject.narrow > >to narrow your object reference to the desired type. The PRO.narrow call >is required by the EJB 1.1 specification. > >-jkw > >Suresh Ajja wrote: >> >> Ignore Earlier question >> >> Hello everybody, >> the IDE is Jbuilder4.0, >> I found this error, while runnning the client. >> It deployed correctly on Jbuilder, but can't figure out this problem. >> TCarBean is the Entity bean, CMP >> Client Application. >> >> " java.lang.ClassCastException: com.inprise.vbroker.rmi.CORBA.ObjectImpl at >> sample.TCarTestClient.<init>(TCarTestClient.java:30) at >> sample.TCarTestClient.main(TCarTestClient.java:47) " >> >> help needed, any body pls. >> >> =========================================================================== >> 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". > >------------------------------ > >Date: Tue, 10 Oct 2000 15:41:34 +0530 >From: Bibhash Roy <[EMAIL PROTECTED]> >Subject: Re: is there any resource on middleware? > >www.middleware.com > >-br >----- Original Message ----- >From: que <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Saturday, November 25, 2000 7:52 PM >Subject: is there any resource on middleware? > > >> Dear All, >> Can someone tell me where I can find some resource on middleware, >> the incentive (why), the key design rules (how)? >> Thanks in advance. >> >> Best&Regards, >> Que >> >> >=========================================================================== >> 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". >> >> > >------------------------------ > >End of EJB-INTEREST Digest - 24 Nov 2000 to 25 Nov 2000 (#2000-247) >******************************************************************* =========================================================================== 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".
