Hi prashant,
This is a pretty original request and probably not many people really tried something like that in practice. I�m no exception though and I cannot give you a straight answer, but if you�d allow me I�d try to explain you my reasons why I believe that you can�t. First of all your EJBs in the cluster A use cluster-aware RMI stubs in order to invoke remotely beans residing in Cluster B. These cluster-aware stubs maintain a list of all available server instances in the cluster B
ant they also implement the load balancing algorithm used for redirecting requests to the next available server instance (in the cluster B). Notice that the beans in cluster A cannot control or predict to which server instance (in the cluster B) they will be sending the next RMI request. From the target beans� perspective they might only have access to information that the RMI protocol provides. Hence they are capable of retrieving input parameters (after demarshalling) and they could retrieve all information regarding the clients request within the boundaries that the RMI protocol provides. And here there is my bet: for performance reasons I believe that RMI protocol doesn�t send any address related information over the network. I guess that RMI is minimizing the network traffic as much as possible. Hence I�m not sure if you can get the ip address of the server sending the request, but I might be wrong though. I guess you have to look into RMI little bit deeper. Even worse, assuming the information is sent over the network, your bean should have access to its own stub in order to get it. I really don't believe that your container vendor will allow you that.
Ultimately you might think about implement an ad-hoc solution, passing the ip address as an input parameter from beans in cluster A to the beans in cluster B, but from a designing perspective this will be against all odds. You can also implement an audit process that logs specific client information (probably using an underlying database) and have the target bean receiving these information, but this might be too complex and will raise performance issues as well. Again these are just my thoughts and I hope that I gave you an idea about the beast you�re wrestling with here :-)
Regards.