In this post I tried to explain how Remoting service in BlazeDS works. Obviously I cannot explain each and every line of the code; I tried my best to cover all. I explained how each component of the Remoting service are invoked sequentially to invoke the method on the Java class and return the values.
I took remoting-config.xml file as the starting point to explain how each component is tied.
Recalling how to create Remoting destinations
In order to invoke methods on a Java class, we declare destination for that class in the remoting-config.xml file. From the Flex application we use the RemoteObject and invoke methods on the class by mapping it to the id of the destination declared.
How do they work and who are they?
<service id=”remoting-service” class=”flex.messaging.services.RemotingService”>
This will be the root node of the remoting-config.xml. Observe that “class” attribute is set to “flex.messaging.services.RemotingService”. This means the destinations under this “service” node will be handled by the “flex.messaging.services.RemotingService” class. When a destination gets a request, RemotingService will invoke the appropriate adapter for the destination to get the result.
<adapter-definition id=”java-object” class=”flex.messaging.services.remoting.adapters.JavaAdapter” default=”true”/>
This is how we declare adapters for this service. Each destination will have an adapter. You can see that the “default” attribute is set to “true”. This means that if a destination declaration doesn’t specify an adapter, then the default adapter will be used.
In our normal remoting JavaAdapter class is the adapter. JavaAdapter is responsible for invoking method on object and return the result. JavaAdapter also checks if the method invocation is allowed. JavaAdapter will depend on the JavaFactory class to get the object instance on which the method should be invoked.
This is how we declare a Remoting destination. This destination has its “source” set to “flex.samples.EmployeeService” and “scope” set to “application”.
JavaFactory will use the value of the “source” element to decide which type of object to instantiate and the value of the “scope” element to decide in which scope of the web application the created instance should be stored or look for the instance already created.
JavaFactory is responsible for returning the object instance. In this case JavaFactory is responsible for returning the instance of the “flex.samples.EmployeeService”. If the “scope” is set to application/session then the JavaFactory will check if there is already an instance in the scope and return that. If the object is not available then it is instantiated and stored in appropriate scope.
Wait a second we did not declare a “factory” in the destination. Yes, we did not declare “factory” because JavaFactory is the default factory used by the JavaAdapter.
RemotingService will invoke the JavaAdapter. JavaAdapter will do necessary checks and invoke JavaFactory. JavaFactory will return the instance based on the “source” and “scope” element values. JavaAdapter will now invoke the method on the instance using Java Reflection API and return the result. RemotingService will return the same. MessageBroker will take it from here.
That’s it, each component work so well to allow us to remotely invoke methods on the Java classes.