Overview
From my experience with XI, I had long known that the JCo RFC Provider service (which is configured using Visual Administrator) plays a major part in communications from the ABAP to the Java stack. As you can see below (taken from an XI system), in this service you can configure a number of RFC connections to the ABAP stack. More formally, the service registers a number of Program IDs in the WAS gateway. In the ABAP stack, you then define RFC destinations referencing the same Program IDs. The net effect of this is that when an RFC is executed in the ABAP stack with this destination, the call is transfered (via RFC and JCo) to the JCo RFC Provider service.
The AI_RUNTIME... entry in the JCo RFC Provider 
The corresponding RFC destination in SM59 
XI standard code which uses the destination when calling XI's mapping runtime 
Under the hood
So far, so good. But how does the JCo RFC Provider know which code to execute in the Java server? After all, there is no configuration to tell it for instance that when function SMPP_CALL_JAVA_RUNTIME3 is called, the request should be forwarded to a class called com.sap.aii.ibrun.sbeans.mapping.MappingServiceImpl. What happens is this:
The JCo RFC Provider looks at the function metadata and determines the name of the function being called. It then looks up this name in the Java Naming and Directory Interface (JNDI) and expects to find an session bean registered with this name under the rfcaccess context. The bean must implement the method:
void execute(JCO.Function function).
This method is called by the JCo RFC Provider, passing in the JCO.Function it received from the ABAP server.
The JNDI Registry entry for rfcaccessejb/SMPP_CALL_JAVA_RUNTIME3
In most cases it's as simple as that. However, the service also maintains a map of function names to JNDI names so that a function may be named differently in ABAP and in JNDI. More on that in a later blog...
