UcompOS SDK Communication Mechanics

I want to spend some time looking a bit deeper under the hood of the UcompOS SDK particularly in terms of how the SDK is configured to enable entities to talk to one another.

Understanding these mechanics can help you understand how to build the best Proxy Components that will promote the richest experiences for your UcompOS Rich Portal Application.

As you’ve read about in my previous blog postings, the Flash Player’s LocalConnection infrastructure is the medium used for inter-entity communication in the UcompOS Rich Productivity Framework.

A slight exception to this is with UcompOS AIR 2.0 applications that take advantage of AIR 2.0′s new ServerSocket class such that messages are sent to the AIR application over a socket versus LocalConnection.

My reasons for using LocalConnection despite its known limitations have to do with the fact that LocalConnection is such a practical lowest common denominator solution and is equally available to all versions of ActionScript.

Limitations of the LocalConnection include the inability to send data packets in greater than 40K chunks. The SDK elegantly works around this limitation by implementing its own incremental transmission and aggregation logic.

For the most part, the messages sent between entities don’t ever come anywhere near 40K but are closer to 1K. In some use cases, larger data chunks may need to be sent over the UcompOS “SDK Tunnel”. For instance, in Educator 2, I am building a whiteboard application and content drawn in the application often needs to be transmitted elsewhere as a ByteArray encoded PNG.

Messages sent back and forth in the UcompOS Continuum via the SDK are placed into an instance of a class called DataPackage. The DataPackage itself will receive a polymorphic construct of type IDataPackageObject as one of its input parameters.

(REMINDER: There is AS3 documentation for the SDK)

Currently, the classes in the SDK that implement IDataPackageObject are CommandObject and EventObject.

With this knowledge we can talk a bit more about the mechanics of data transmission.

As I’ve explained, a UcompOS entity serves both as a server and a client in the context of the UcompOS Continuum.

The “touch points” of a UcompOS entity are the classes SDKClient and SDKServer. SDKClient is of course also the class that is instantiated when a UcompOS application starts up.

The SDKClient‘s send(); method receives a DataPackage as input. In addition to the DataPackage having the polymorphic IDataPackageObject instance embedded, it also has information about the destination entity as well as the origin entity. The send(); method then uses the LocalConnection infrastructure, or an extended Socket class, to send the DataPackage to the remote entity (encoded into a compressed ByteArray).

The SDKServer then serves as the server infrastructure in a UcompOS entity.

The SDKServer‘s server(); method is the method targeted by the SDKClient‘s send(); method.

This method decodes the compressed ByteArray, serializes it into a DataPackage, and then determines what type of IDataPackageObject instance is in it.

It then passes the DataPackage to a polymorphic construct of type IServerHandler.

Right now, as you’d expect, there are two classes in the SDK that implement IServerHandler: CommandObjectHandler and EventObjectHandler.

Communication in the UcompOS RPF is both synchronous and asynchronous.

The transmission of a CommandObject from one entity to another results in the receiving entity generating an EventObject and passing it back to the sending entity in real-time. In that regard it is a synchronous communication process.

From an implementation point of view, the EventObjectHandler class causes the Proxy Component that made the original call in the calling entity to dispatch an event of type SDKEvent and this event object will have a data property that represents the data returned by the method contacted in the target entity.

The API method in the target entity must by strict convention return an item of type Object. This Object can have an eventType property which will be the event type of the SDKEvent dispatched by the calling Proxy Component via the EventObjectHandler class.

Typically in a UcompOS application, one would attach an event listener to a Proxy Component instance for the event type they knew would be returned by the target remote API method.

Thus the model takes on more of an asynchronous flavor even though you are able to take action on the return of data from a target entity in real-time.

There is a way to implement more of a callback type synchronous implementation.

The AbstractProxyComponent‘s call(); method returns a String that is used as the Universally Unique ID of the Transmission. All Proxy Components by strict convention must extend AbstractProxyComponent.

The EventObject that is returned from the target entity has a transactionId property that is the value of the String returned by the call(); method of AbstractProxyComponent.

One can easily facilitate a true callback strategy armed with this knowledge.

About Edward Mansouri
Edward Mansouri is the CEO and Founder of Ucompass.com, Inc., a company focused on building scalable and profitable e-Learning enterprises. His expertise is in building e-Learning software, as well as in building visual frameworks such as the Enrich Content Enrichment System and the newly announced UcompOS Rich Experience Framework. He has been working with Flash since 1998, building Flash applications since 2002, and working with Adobe AIR since its private alpha release in 2006. He authored the site AIRApps.net (later renamed to O2Apps.com) dedicated to providing leadership in building Adobe AIR applications. In 2010, he is building and releasing a new e-Learning platform called Educator 2 which is built entirely upon the UcompOS Rich Experience Framework. Since 1999, over 1,000,000 students have taken courses served with his original e-Learning platform, Educator 1.

Comments are closed.