The documentation project aims at documenting AMF0, AMF3, Remoting envelopes and FDS features. It is intended for developers of Remoting implementations, proxies, and such.
Remoting is an RPC implementation that uses AMF as a means of encoding data. Remoting messages are sent from the Flash player using HTTP POST (or using RTMP protocol). They may be identified by:
AMF uses a certain number of basic types. Remoting uses these types to define its Remoting envelope, which consists of headers followed by bodies. The headers and bodies each have a field containing the actual data, including a datatype code.
The datatype code can range from 0×00 to 0×10 for AMF0. 0×11 is also part of the AMF0 spec, and it indicates that the decoder should be aware that the following data is encoded in AMF3.
If one supports the decoding and encoding of Remoting envelopes, then one does not automatically have a working Remoting implementation. Once a message is decoded, one must look at the target of each body (or if it is the null string, then at the inner source and operation keys). A typical target is:
com.mypackage.MyClazz.myMethod
A Remoting implementation then has to split this string to determine the package, class, and method components. Then it may use the target language’s conventions for mapping the package and class name to an actual file and class. The Remoting implementation should then include the class in question, and determine whether the method to be called can in fact be called, depending on security settings, attributes of the method (public, private), and associated metadata. Language which have such capabilities should use reflection to determine whether to call a method or not.
Once the method has been called and the result retrieved, it can be sent back to the client. AMF0 and AMF3 use the same return envelopes, however if the request was generated by Flex 2 RemoteObject, then the request uses a different envelope which can be detected by looking for the null string in the target. Then the envelopes specific to RemoteObject should be used for the return.
Remoting implementations should bubble up errors from services to the client, for debugging purposes. In the languages that support this feature, each method call should be surrounded by a try..catch statement.
Remoting implementations should strive to map objects as naturally as possible to and from Flash. In particular, anything that looks like a record set should be sent as a RecordSet in AMF0 mode or as an ArrayCollection in AMF3 mode.
AMF0 and AMF3 reference handling involves keeping an object stack, while AMF3 also has an additional string stack. These stacks should always be reset per header and per body.
Remoting implementations may choose to support Remoting headers. Supporting the TraceHeader is important, as it allows developers to basically do the equivalent of the trace function over the wire. Roles and authentication may also be implemented, although many argue that Remoting’s authentication methodology is anemic and would suggest that developers roll out their own.
Remoting is a big part of Flex data access services. The three main areas that make up Flex Data Services platform are RPC services, Data Management Service, and Message Service.
RPC Services cover:
Data Management
Messaging
A few new AMF messages have been created to handle the FDS features. The most common is the DataMessage command roughly two dozen operations types.
The MessageBroker class routes messages to endpoints based on the content type of those messages, and routes decoded messages to services based on message type. The broker also has a means of calling back into the endpoints in order to push messages back through them.
The three main message types are RemotingService, DataService and MessageService.
Although RTMP is defaulted by the FDS server configuration you can use HTTP polling for some of the FDS related functionality. The first steps for the Universal Remoting group will be to identify the DataMessage and other related message objects and the available operation types.