Query related to Local Business Interface

[Sagar Shroff]

Hello ranchers i have recently started studying for Ejb certificate and as i was reading the specs i am a bit confused with whats been said
on Local Business Interface.

The arguments and results of the methods of the local client view are passed “by reference”.....the Bean Provider must be careful that the state of one enterprise bean is not assigned as the state of another. In general, the references that are passed across invocations of the local client view cannot be used outside of the immediate call chain and must never be stored as part of the state of another enterprise bean.

First of all i am not understanding what does immediate call chain mean in that context . I am assuming its trying to say that when i am calling a local business method , since the parameters i pass are pass by reference the local business method should not pass it to some other business method .
Am i making sense or i have totally got it wrong ?? So incase if i have am right then it basically discourages every one to mainpulate with the business methods parameters , right ??? But now later in spec i came across this

A reference to the no-interface view may be passed as a parameter or return value of any Local business interface or no-interface view method.

So why does this contradicts with what i have said before . I think i have got it wrong some where for sure . Any help on this topic will be really appreciated .

Regards,
Shroff.

[Frits Walraven]

Hi Sagar,

First of all i am not understanding what does immediate call chain mean in that context . I am assuming its trying to say that when i am calling a local business method , since the parameters i pass are pass by reference the local business method should not pass it to some other business method .

Correct. The immediate call chain just means: all methods involved in the call, for instance:
Client -> Session A.methodA, and methodA calls methodB, and methodB calls method C
(methodA, methodB en methodC are in the immediate call chain)

A reference to the no-interface view may be passed as a parameter or return value of any Local business interface or no-interface view method.

This means I can give a reference to myself (a sort of 'this' in a POJO) as a parameter. The reference of an EJB cannot be changed inside a method so there is problem there.

Regards,
Frits

[Sagar Shroff]

This means I can give a reference to myself (a sort of 'this' in a POJO) as a parameter.

You mean that in a local business method i can refer the current localbusinessObject with the help of this and now this reference i can pass it to any other local business method in the immediate call stack ?? right ??

The reference of an EJB cannot be changed inside a method so there is problem there

Dint got this one ? Does it mean that i cannot refer to this like
eg Cat refernce = this ;
If so then why ? What is the problem there as you mentioned above ?

[Frits Walraven]

"this" is not allowed with EJBs

What I mean is :

@Stateless
public class EchoBean {
	
   @Resource
   SessionContext ejbContext;

   @EJB
   AnotherEJB another;
	
   public String echo(String phraseToEcho) {
        // Get a reference to this No interface view 
        EchoBean er = ejbContext.getBusinessObject(EchoBean.class);

        // and pass it to another EJB as a parameter
        another.echoTo(er)

        return phraseToEcho;
   }
}

Regards,
Frits

[Sagar Shroff]

Frits Walraven wrote:

 EchoBean er = ejbContext.getBusinessObject(EchoBean.class);   

Ohkie So basically you cannot pass er reference outside the class , but you do can pass it within the class to any other method ? right ??
and one thing i do not get it why do we always get the reference of the business object using SessionContext like above why cant we simply
do this ->

EchoBean=this;

after all you are in a method which has been invoked by some instance of EchoBean right so why not use the this keyword ??
might be some technical thing which i do not know ??

Regards,
Shroff.

[Frits Walraven]

after all you are in a method which has been invoked by some instance of EchoBean right so why not use the this keyword ??
might be some technical thing which i do not know ??

Yes, you will never interact with an EJB instance directly. You will always interact with a proxy object and this is because the EJB container is adding features to your object like security, transactions and so on.

Watch out that with a No Interface View the getBusinessObject(EchoBean.class) returns a class-type that is the same as the class itself (normally if the EJB has a business interface it would return the interface's class)

This is what the specs say about it:

When interacting with a reference to the no-interface view, the client must not make any assumptions regarding the internal implementation of the reference, such as any instance-specific state that may be present in the reference. Although the reference object is type-compatible with the corresponding bean class type, there is no prescribed relationship between the internal implementation of the reference and the implementation of the bean instance.

Regards,
Frits

[Sagar Shroff]

Frits Walraven wrote:
Watch out that with a No Interface View the getBusinessObject(EchoBean.class) returns a class-type that is the same as the class itself (normally if the EJB has a business interface it would return the interface's class)

Ohkie it does return class type just beacause it does not have an interface right ?

And in this spec i want to confirm one more thing from you ,the spec says

When interacting with a reference to the no-interface view, the client must not make any assumptions regarding the internal implementation of the reference, such as any instance-specific state that may be present in the reference. Although the reference object is type-compatible with the corresponding bean class type, there is no prescribed relationship between the internal implementation of the reference and the implementation of the bean instance.

So does it says that the reference i get to an object (either through dependecy injection or lookup) , that object's type will be same as of class type but the internal implementation will be different ! means that the container might be creating a class at runtime which has a same name as the actual bean class but this class will be like a proxy / stub which will be performing all the networking complexities ! right ??

Regards,
Shroff

Regards,
Frits

[Frits Walraven]

Ohkie it does return class type just beacause it does not have an interface right ?

Correct.

So does it says that the reference i get to an object (either through dependecy injection or lookup) , that object's type will be same as of class type but the internal implementation will be different ! means that the container might be creating a class at runtime which has a same name as the actual bean class but this class will be like a proxy / stub which will be performing all the networking complexities ! right ??

Yes, you are right, it is a sort of stand-in object with more capabilities (transaction, security, concurrency control, naming service etc.).

Regards,
Frits

[Sagar Shroff]

Thanks Frits for solving my doubts

[Sagar Shroff]

Hie Frits as i was again going through this thread i am getting one more doubt related to the term immediate call chain
[quote =Frits Walraven]

@Stateless  
public class EchoBean {  

   @Resource  
   SessionContext ejbContext;  
  
   @EJB  
   AnotherEJB another;  
      
   public String echo(String phraseToEcho) {  
        // Get a reference to this No interface view   
        EchoBean er = ejbContext.getBusinessObject(EchoBean.class);  
  
        // and pass it to another EJB as a parameter  
        another.echoTo(er)  
  
        return phraseToEcho;  
   }  
}

So this is not allowed because echoTo() is not within immediate call chain.
Now lets change the above scenario, lets say echoTo() is a function of EchoBean i.e the same class then would it be allowed ??
Scenerio1
what i want to know is whether this is allowed ?

@Stateless  
public class EchoBean {  
      
   @Resource  
   SessionContext ejbContext;  
  
   public String echo(String phraseToEcho) {  
        // Get a reference to this No interface view   
        EchoBean er = ejbContext.getBusinessObject(EchoBean.class);  
  
        // and pass it to another method of the same class ..is this allowed ??
        echoTo(er)  
  
        return phraseToEcho;  
   }  
}

public void echoTo(EchoBean ref){}...

Also i want to know whether the below scenario2 be allowed ???
Scenrio2
Client invokes function1() of local business interface and function1() -->invokes ( based on certain condition invokes )--> function2().
Now function2() gets a reference

EchoBean er = ejbContext.getBusinessObject(EchoBean.class);

and invokes funcation1(er) back and also passes the er reference.
So since function1() is within the same call chain this scenerio should be allowed right ?? It will be very helpful of you to help me in theses 2 scenario's


Regards,
Shroff

[Frits Walraven]

Hi Sagar,

Those 2 scenarios are allowed. Maybe it is better to show what is not allowed:

@Stateless    
public class EchoBean {    
  
   @Resource    
   SessionContext ejbContext;    
    
   @EJB    
   AnotherEJB another;    
        
   public String echo(String phraseToEcho) {    
        // Get a reference to this No interface view     
        EchoBean er = ejbContext.getBusinessObject(EchoBean.class);    
    
        // and pass it to another EJB as a parameter    
        another.echoTo(er)    
    
        return phraseToEcho;    
   }    
}  

ans this is the code for the AnotherEJB:

@Stateless    
public class AnotherEJB {    

   // variable to save the reference
   private EchoBean echoRef;    
        
   public void echoTo(EchoBean eb) {    
        // only saving the reference 
        echoRef = eb;    
   }    

   public String workOn () {
       // this method is using the saved reference so this is not
       // allowed as it can potentially be used in another call chain
       // (i.e. this method can be called from another client)
       echoRef.echo("No");
   } 
}  

Regards,
Frits