Question

I am very new to remoting in flex. I am using flex 4.5 and talking to a web application built by someone else on the team using AMF. They have used Zend_AMF to serialize and unserialize the data.

One of the main issues I am facing at the moment is that I will need to talk to a lot of services (about 60 or so).

From examples on remoting I have seen online and from adobe, it seems that I need to define a remoting object for EACH service:

<mx:RemoteObject id="testservice" fault="testservice_faultHandler(event)" showBusyCursor="true" destination="account"/>

With so many services, I think I might have to define about 60 of those, which I don’t think is very elegant.

At the same time, I have been playing with Pinta to test out the AMF endpoint. Pinta seems to be able to allow one to define an arbitary amount of services, methods and parameters without any of these limitations. Digging through the source, I find that they have actually drilled down deep into the remoting and are handling a lot of low level stuff.

So, the question is, is there a way to approach this problem without having to define loads or remoteobjects and without having to go down too deep and start having to handling low level remoting events ourselves?

Cheers

Answer 1

It seems unusual for an application to require that many RemoteObjects. I’ve worked on extremely large applications, and we typically end up with no more than ~6-10 RemoteObject declarations.

Although you don’t give a lot of specifics in your post about the variations of RemoteObjects, I suspect you may be confusing RemoteObject with Operation.

You typically declare a RemoteObject instance for every end-point in your application. However, that endpoint can (and normally does) expose many different methods to be invoked. Each of these server-side methods gets results in a client-side Operation.

You can explicitly declare these if you wish, however the RemoteObject builds Operations for you if you don’t declare them:

 var remoteObject:RemoteObject;
 // creates an operation for the saveAccount RPC call, and invokes it, 
 // returning the AsyncToken
 var token:AsyncToken = remoteObject.saveAccount(account); 
 token.addResponder(this); 
  //... etc

If you’re interacting with a single server layer, you can often get away with a single RemoteObject, pointing to a single destination on the API, which exposes many methods. This is approach is often referred to as an API Façade, and can be very useful, if backed with a solid dependency injection discipline on the API.

Another common approach is to segregate your API methods by logical business area, eg., AccountService, ShoppingCartService, etc. This has the benefit of being able to mix & match protocols between services (eg., AccountService may run over HTTPS).

How you choose to split up these RemoteObjects is up to you. However, 60 in a single applications sounds a bit suspect to me.