Alexander, In order to answer your question on the "shared object", "subscription" and such you need to explain quite a bit about tasks you need to accomplish. Delivering real-time media is something that is very different from reliable chats from auction sites and from logistics/fulfillment operations. In most cases you would want to create "server" part independently from delivery mechanism and use adapters to register with different services.
There is much more to streaming media then just RTMP - and on the other hand chances are that out of the box adapters will work for "chat" application. Going into verticals will bring a lot of features that might go to protocol level ( to insure regular or serial transactions and multi-phase commits as an example), but would have much more work on the server level till we get into communication portion. Sincerely, Anatole Tartakovsky On Mon, Mar 31, 2008 at 2:08 PM, Alexander Tsoukias <[EMAIL PROTECTED]> wrote: > Thanks for this Anatole made things quite clearer and saved me a lot > of time. > > I own LCDS 2.6, so as in your PS I'd like to know where can i find > these LCDS 2.6 sections you are referring to. > > Also, since you have the knowledge on this, could you help out on this > topic as well? > http://tech.groups.yahoo.com/group/flexcoders/message/108292 > > Thanks so much, > Alexander > > --- In [email protected] <flexcoders%40yahoogroups.com>, "Anatole > Tartakovsky" > > <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > > > > > > > > > >
