Hi Yogaraj,

Even i agree with Bimalesh that the lookup can be done through RMI and it=
 has a security issue.
Here are certain things you need to keep in mind to implement the same.

1. JNDI uses initial context to lookup for the binded names for lookup. S=
o you need to provide the Initial Context. which i am not sure how to pas=
s.
2. When you call  Naming.looup() to lookup for a object from RMI registry=
, you pass the protocol as RMI and port no. is the default port of RMI re=
gistry. In this case your port no. will change to the port no. of your JN=
DI sever.

Advantages you have if you use JNDI instead of RMI.

1) You can bind different beans with same name in different context like =
you can place files with same name in different directories which you can=
not do with RMI.

2) Security. JNDI is preety secure as the implementations are specific fo=
r a product.

Note: Don't worry about JTA and other stuff as they are no where linked t=
o JNDI. the only thing is inside the bean if you are using JTA object and=
 the JTA object is binded to the JNDI you can lookup using RMI as well.

I hope this will be of some help to you.

Thanks,
Ankul

Ashwani Kalra wrote:

> Hi,
>
> In RMI  core steps that server and clients do  are for eg.
>
> Server
>
> Calculator c = new CalculatorImpl();
> Naming.rebind("rmi://localhost:1099/CalculatorService", c);  //binding to
> naming sevice
>
> Client
> Calculator c = (Calculator)Naming.lookup
> ("rmi://localhost/CalculatorService"); // looking up the object by name
>
> >Both EJBObject and EJBHome extends from java.rmi.Remote interface.
> >Therefore, it should be at least, theoretically possible to export and
> bind any such objects (e.g. EJB objects),
> >Which implement these interfaces into RMI Registry and do a subsequent
> lookup. EJBs are built
> >around RMI-IIOP. However, there could be some problems in using RMI
> instead of JNDI as...
>
> Yeah it may be possible. But then after binding , I will be using simple
> plain rmi , not ejb. Since ejb is based on rmi itself. Forget iiop as of
> now. So whats the use here. JNDI is just a wrapper around naming service(it
> can be as simple as rmi registry). I asked Weblogig guys, If I am not wrong
> , they have rmi-registry as naming service.
>
> >1) Calls through JDK's default RMI Registry are unsecured, you might have
> to right your own
> >Custom socket factory for secured implementation or look for some
> alternative RMI Registry providers.
>
> When you move to rmi, you loose all the features provided by app server
> like security,fault tolerance etc
> This now has to be taken care by developer now.
>
> >4)Extending Rajesh's point, you can have a RMI wrapper over EJB layer, but
> then it introduces extra layer,
> >more complexity, more proxy objects, more remote calls...which may not do
> any good...
>
> How it will be possible ? Can core rmi interact with ejb(which itself is
> based on rmi)
>
> So my question is  Is it still possible to lookup ejb through rmi?
>
> Please correct me if I am wrong
>
> Ashwani
>
>                     Bimalesh Jha
>                     <[EMAIL PROTECTED]        To:     [EMAIL PROTECTED]
>                     RO.COM>                  cc:     (bcc: ashwani.kalra/Polaris)
>                     Sent by: A               Subject:     Re: EJB through RMI!
>                     mailing list for
>                     Enterprise
>                     JavaBeans
>                     development
>                     <[EMAIL PROTECTED]
>                     A.SUN.COM>
>
>                     03/28/2003 12:53
>                     PM
>                     Please respond to
>                     Bimalesh Jha
>
> Yogaraj,
>
> Both EJBObject and EJBHome extends from java.rmi.Remote interface.
> Therefore, it should be at least, theoretically possible to export and bind
> any such objects (e.g. EJB objects),
> Which implement these interfaces into RMI Registry and do a subsequent
> lookup. EJBs are built
> around RMI-IIOP. However, there could be some problems in using RMI instead
> of JNDI as...
> 1) Calls through JDK's default RMI Registry are unsecured, you might have
> to right your own
> Custom socket factory for secured implementation or look for some
> alternative RMI Registry providers.
> 2)Almost all J2EE app servers are designed and geared to use JNDI
> infrastructure, as such, you might
> need to carefully investigate further about efficiency of EJBs in appserver
> runtime w.r.t
> factory for EJBs, instance pooling and instance swapping..., if you have
> RMI registry instead of JNDI.
> 3)If need be, pls. also check how would you involve JTA through pure RMI
> lookups...
> 4)Extending Rajesh's point, you can have a RMI wrapper over EJB layer, but
> then it introduces extra layer,
> more complexity, more proxy objects, more remote calls...which may not do
> any good...
>
> Is there any special reqmt. for your client preferring RMI over JNDI?
>
> Ideas welcome.
>
> Regds,
> BJ
>
> -----Original Message-----
> From: Jayaprakasam, Yogaraj (Cognizant) [mailto:[EMAIL PROTECTED]
>
> Sent: Friday, March 28, 2003 11:53 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB through RMI!
>
> Hello Rajesh,
> Thank you very much for your reply.
> Actually I never worked much on RMI before.
> Since my client is so keen on using RMI look am just wondering would extra
> benefit would he get by using RMI look up. I understand the simplicity and
> the advantages of using JNDI lookup. But I am just wondering, is there any
> advantage using RMI look up over JNDI.
>
> And also If the client is so keen on RMI look up. Is there a way to do it?
>
> Thank you for your time.
> Regards
> Yogaraj
>
> -----Original Message-----
> From: Rajesh S R [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 28, 2003 11:30 AM
> To: Jayaprakasam, Yogaraj (Cognizant)
> Subject: RE: EJB through RMI!
>
> Hello Yograj,
>
> U can access the EJB home only thru JNDI lookup.
> I couldnt get why u r not directly looking up the EJB's thru JNDI from the
> client. If the problem is of exposing ur architecture use FrontControllers.
>
> The method u've told have some drawbacks.
> 1) It's addition of one unwanted layering. U access the EJB thru
> JNDI lookup from RMI Server. U cannot get rid of the JNDI access. U can
> have the handle only after having the home reference.  The handles r
> essentially used to have the reference to the home over a period of time.
> 2)  The usage of Handles have some problems. Handles can do nothing as its
> own. If the business methods have to be executed, home reference has to be
> reconstructed before trying it. Both these will affect the performance.
>
> For ur case, i cannot see the need of RMI lookup from the reqmnts. u'v
> given.
>
> JNDI - always preferred for its simplicity. The underlying impl is provided
> by
> the appln. server provider. JNDI to lookup  a vast array of services using
> a simple API.  RMI lookup - only for lookup of RMI services.  Refer the
> specs or online tutorials for more details.
>
> Hope its clear.
>
> Best regards,
> Rajesh
>
> -----Original Message-----
> From: Jayaprakasam, Yogaraj (Cognizant) [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2003 9:47 PM
> To: [EMAIL PROTECTED]
> Subject: EJB through RMI!
>
> Dear Friends,
> i have a java thick client (Swing client) to call an ejb sessionbean but
> lookup should not be through JNDI it had to be acomplished thru rmi, We
> would like to have rmi on the server and have the stub of the rmi on = the
> client side which will get the ejbhome handle to the client. Is it
> possible? How can I achieve this?=20
>
> And also, i would like to know the pros & cons of JNDI and RMI lookup. =
> Because our client demand is to lookup through RMI, it would be nice if = I
> can get the pros & Cons, to enable me to discuss with the client. I =
> believe that the bunch of experts here can surely help me in this.
>
> Thanks in Advance
>
> Regards
> Yogaraj
>
> DISCLAIMER: Information contained and transmitted by this E-MAIL is
> proprietary to Mascot Systems Limited and is intended for use only by the
> individual or entity to which it is addressed, and may contain information
> that is privileged, confidential or exempt from disclosure under applicable
> law. If this is a forwarded message, the content of this E-MAIL may not
> have been sent with the authority of the Company. If you are not the
> intended recipient, an agent of the intended recipient or a person
> responsible for delivering the information to the named recipient, you are
> notified that any use, distribution, transmission, printing, copying or
> dissemination of this information in any way or in any manner is strictly
> prohibited. If you have received this communication in error, please delete
> this mail & notify us immediately at [EMAIL PROTECTED] Before
> opening attachments, please scan for viruses.
>
> ==========================================================================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".
>
>   ------------------------------------------------------------------------
>                                Name: InterScan_Disclaimer.txt
>    InterScan_Disclaimer.txt    Type: Plain Text (text/plain)
>                            Encoding: 7bit

===========================================================================
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".

Reply via email to