The real question is - does it move you in the right direction.
Architecturally, (long) RemoteObject call is a one-way-at-a-time road with
typical congestions including latency, inability to detect lost
packages/dups/out of sequence. RTMP is usually 2 pairs of 2-way sockets
(Publishing and Subscriptions), using "acknowledgements" on each side rather
then responses. "Blocking" model of request/response over non-blocking IO
model of RTMP will most likely put a lot of pressure on the resource
consumption and performance. By using Publisher/Subscriber objects as higher
level tunnels you can solve much more of typical problems of RIA apps.To add
by-directional (pull and push) "RemoteObject" functionality to the RTMP you
have to start with endpoints - basically keeping track of
messageId/CorrelationIds as standard functionality of RemoteObject with
standard timeouts will not suffice. Deciding if you want code distributed
between endpoint and adapter is really up to you - but keeping endpoints
unchanged is not really an option, and then you have to decide on number of
places to maintain the code.
As far as adding remoting destinations - it is trivial from messaging as
well - you can get implementation from BlazeDS
sources
C:\blazeds-source\modules\remoting\src\java\flex\messaging\services\remoting\adapters\JavaAdapter).
It would go like this (optimization removed for brevity):
public Object invoke(Message message) {
RemotingDestination remotingDestination =
(RemotingDestination)getDestination();
RemotingMessage remotingMessage = (RemotingMessage)message;
FactoryInstance factoryInstance =
remotingDestination.getFactoryInstance();
// We don't allow the client to specify the source for
// Java based services.
String className = factoryInstance.getSource();
remotingMessage.setSource(className);
String methodName = remotingMessage.getOperation();
List parameters = remotingMessage.getParameters();
Object result = null;
try
{
// Test that the target method may be invoked based upon
include/exclude method settings.
if (includeMethods != null)
{
RemotingMethod method =
(RemotingMethod)includeMethods.get(methodName);
if (method == null)
MethodMatcher.methodNotFound(methodName, null, new
Match(null));
// Check method-level security constraint, if defined.
SecurityConstraint constraint = method.getSecurityConstraint
();
if (constraint != null)
getDestination().getService().getMessageBroker().getLoginManager().checkConstraint(constraint);
}
else if ((excludeMethods != null) && excludeMethods.containsKey
(methodName))
MethodMatcher.methodNotFound(methodName, null, new
Match(null));
// Lookup and invoke.
Object instance = createInstance(
factoryInstance.getInstanceClass());
if (instance == null)
{
MessageException me = new MessageException("Null instance
returned from: " + factoryInstance);
me.setCode("Server.Processing");
throw me;
}
Class c = instance.getClass();
MethodMatcher methodMatcher =
remotingDestination.getMethodMatcher();
Method method = methodMatcher.getMethod(c, methodName,
parameters);
result = method.invoke(instance, parameters.toArray());
As soon as you have result, you wrap it into message, apply correlationId
from the messages original request - and you are done.
Regards,
Anatole Tartakovsky
Farata Systems
PS. If you are just looking for RemoteObject request/response long
transaction support), look into BlazeDS/LCDS 2.6 sections for long
httprequest - that solution might work well for some applications
On Mon, Mar 31, 2008 at 12:58 PM, Alexander Tsoukias <[EMAIL PROTECTED]>
wrote:
> I am trying to find out if there is a way to do same logic as when
> using RemoteObject with coldfusion, but instead of using (http
> polling) AMF to use the RTMP protocol.
>
> In my logic, i would just create a new destination in
> remoting-config.xml and add a channel ie: my-rtmp.
>
> Would this work? If not, can this be at all done?
>
> Thanks,
> Alexander
>
>
>
