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.

The UcompOS RPF and Adobe AIR 2.0

One of the more exciting features of the UcompOS Rich Productivity Framework is the ability for UcompOS Applications to exist as Adobe AIR 2.0 applications.

Therefore, the browser-based UcompOS Portal can launch and control these applications which are running on the desktop.  The implications of this are very exciting to me as we can implement a Rich Portal Application that gives us the best of a web application with basically full range of the Desktop to create whatever experience we want or need to.

Further, using the UcompOS SDK, a UcompOS Application can launch a UcompOS AIR application as a sub-application.

Over the next week or so, I’ll publish some tutorials that highlight some of the really cool things you can do with this capability, but clearly the key value-added proposition here is a portal continuum implementation that transcends the browser and extends to the Desktop.

I thought I’d start my AIR-related blogs with a technical discussion of why I have chosen to require any UcompOS AIR Application to be based on AIR 2.0 or greater versus the AIR 1.x versions that are now in production.

The UcompOS AIR SDK in fact will only work when embedded in an AIR Application created with AIR 2.0 or greater.  If you try to instantiate it, for instance, in an AIR 1.5.3 application you’ll get a compile error.

AIR 2.0 is in a state of public beta right now. You can download the runtime or the SDK at the following link:


There are many advancements and new features that have been made in AIR 2.0 but I only really wish to focus on one of them here and that is the one that led me to make the decision I made which is to require at least AIR 2.0.

The capability I am speaking of is the new ServerSocket class.

Perhaps one of the most powerful advancements in Flash technology (in my opinion anyway) came way back in Flash 5 near the turn of the century with the ability for Flash content to make socket connections to a socket endpoint thus ushering in an era of bi-directional socket applications.  This has paved the way for Flash applications to extend to the realm of chat and IM clients, telephony-based applications, etc.

With AIR 2.0, in addition to the application being able to connect to a socket endpoint, it can itself serve as a socket endpoint.

The UcompOS SDK is what makes communication between entities in the UcompOS Continuum possible – specifically the SDKServer and SDKClient classes in the SDK.

Each entity that has the UcompOS SDK implemented – Flash, Flex, AIR, or JavaScript – is equipped to operate both as a server and a client in terms of its ability to receive as well as send commands from / to other entities in a particular UcompOS implementation.

The transmission framework in the SDK is based on the LocalConnection infrastructure of the Flash Player.  I chose to go this route because I was looking for something Lowest Common Denominator and LocalConnection has been around in the Flash Player for a very long time.

This would simplify the ability to use the same SDK in content ranging from ActionScript 1.0 through Flex 4.

When I went to implement my SDK in AIR Applications, I was confronted with some harsh limitations of the LocalConnection.

And I am not even talking about the limitation of being able to send no more than a 40 K chunks of data at a time – that limitation was easily side-stepped.

What I would find is that if you tried to send more than one SDK transmission at a time to an AIR application via the original LocalConnection strategy, the AIR application would cease being able to participate in any further LocalConnection activity until that application would quit and be restarted.  The ability for an AIR application to “queue” inbound LocalConnection requests seems broken and it seems that if a synchronous operation is processing in an AIR application and another LocalConnection request arrives during that time period, there is a total breakdown in the ability for the AIR application to participate in any further LocalConnection activity.

This apparently is a known issue and is said to be the case with any and all Flash-based content – running in the AIR runtime or in the Flash Player in the browser – however I have primarily only been able to observe this for myself with AIR-based content.

Obviously, this is unacceptable.  In an ambitious UcompOS implementation, you may have one AIR application that is being bombarded with requests from dozens of UcompOS Applications simultaneously.

With the limitations of LocalConnection, this would break down the Continuum and the ability for AIR applications to be a part of the Continuum very quickly.

I have engineered an alternative to LocalConnection to use in AIR applications at least for in-bound traffic.

When the UcompOS SDK is instantiated in an AIR 2.0 application, the application binds and listens on two ports – the first two available ports on the computer above port 1024 (though you can explicitly set these port numbers but more on that in another blog entry).

One port is used for validation purposes (as Flash Player socket activity is governed by very strict protocols these days) and the other is used for transmission of actual SDK messages.  Whether it is intentional or not I don’t know, but I never was able to get validation and SDK data transmission activity working on the same port so by strict convention I implemented the need for two ports.

In the SDK, if the destination of SDK activity is an AIR application, it automatically sends the message via a class in the SDK that extends Socket such that any in-bound SDK activity arriving to a UcompOS AIR Application arrives via the new ServerSocket capabilities in AIR 2.0.

Any other activity in the UcompOS Continuum leverages the legacy LocalConnection architecture of the Flash Player.

I have been very impressed by the durability of the ServerSocket architecture I have implemented here.  I have successfully transmitted very large files as ByteArrays from a browser-based UcompOS Flex application to a UcompOS AIR 2.0 application without any issues whatsoever.

LocalConnection is not without its issues however, but the UcompOS SDK has managed to sidestep most all of these issues.

So in summary, the reason I have chosen to require AIR 2.0 for UcompOS AIR Applications exclusively has to do with the introduction of the great new ServerSocket class.  However, make no mistake about it.  The great other new features of AIR 2.0 are definitely game-changers and I encourage you to check them out.

In the near future, I’ll post about UcompOS JavaScript applications and how I have implemented them into the UcompOS RPF.