Flex Messaging and MSMQ

WebORB Enterprise is here...ladies and gentlemen, be sure to fasten your seatbelts! The focal point of the Beta 1 release is the support for Flex Messaging and integration with MSMQ. Enterprise Edition lets Flex clients to use the mx.messaging.* API (Producer and Consumer) to communicate with one another or with Windows server applications. WebORB maps MSMQ queues to the messaging destinations defined in the standard Flex configuration file - messaging-config.xml. Flex Producer becomes an MSMQ publisher, while Consumer is a queue subscriber. Messages sent with the Producer.send method automatically delivered into a queue corresponding to the messaging destination the producer is created with. Likewise, when a consumer subscribes to a destination, WebORB connects to the queue on the Consumer's behalf and pushes messages arriving on the queue to the client.

This architecture yields endless opportunities. First off, MSMQ is available as a part of almost every Windows operating system, so there is no extra cost associated with MSMQ. The messaging system is very powerful and comes with a ton of features: intelligent routing, store and forward, distributed queues, transactions are just to name a few. The way WebORB integrates with MSMQ makes it a very flexible solution. A Flex destination is mapped onto a queue. The queue can be local or remote, public or private. No custom server-side code is needed in order to handle Flex-to-MSMQ communication - WebORB completely automates it. Since MSMQ APIs are available natively to all Windows and .NET applications, it is very easy to connect Flex clients with native apps. Just imagine an Excel spreadsheet auto-updating when Flex counterpart makes a change in the dataset, or how about a browser based performance counter showing the state of your computer remotely over the Internet?

The possibilities are truly endless, we're just scratching the surface here..

WebORB 3.0 is released (now with Flex Messaging)

A week ago I pre-announced WebORB 3.0 release and today marks another huge step in the product's history. WebORB 3.0 is out! It took countless number of some hard core coding sessions, five beta, two RC releases and now WebORB Professional is in production.

What makes this release particularly special is the inclusion of the Beta1 of the Enterprise Edition into the build. The Enterprise Edition is architected on top of WebORB Professional. In fact, from the distribution perspective it is the same build that includes both products, but a license key can control which features are enabled (without a license key all features are available).

Below is a list of all the changes/additions in the 3.0 release. Now that the release is out, I plan to spend a lot more time blogging, writing articles, creating new examples and updating the website with some interesting product-related content:

• Flex Messaging integration (support for mx.messaging.Producer and mx.messaging.Consumer)
• MSMQ integration for Flex messaging clients
• Support for remote SharedObject API
• RTMP streaming support
• New cascading multi-level security enforcement implementation
• Code-level security configuration panel (See the Services\Security tabs in the management console)
• Server configuration panels (Class mappings, Service aliases, Service factories, Abstract class mappings, Custom serializers - See the "Configuration" tab in the management console)
• Fixed Cairngorm 2.1 code generation template (the new template does not use old, deprecated calls)
• Added serializer for IEnumerator types

Reloadable Reloaded: Auto-Reload WebORB on Rails Service Classes

One of the pain points that developers have experienced when building solutions with WebORB on Rails is the need to restart the server after changes have been made to the service class. In the old days people just expected that code updates would require server restarts. In the modern world of server-side programming we live in today however, this is a significant nuisance. This is especially true when building rails apps, because it automatically reloads controllers, models etc. when in development mode so developers expect their services to be reloaded too!

Rails does this by a combination of a couple features. First it provides a module named Reloadable that you can include in your non-active record/controller classes to tell Rails... "Hey can you reload this when I'm in development mode?" I've know about this for a while, but by including "include 'Reloadable'" in my service classes I still wasn't getting any reload love. It turns out that I needed to add a few lines of code to WebORB to bring this feature to life. First you have to set:

Dependencies.mechanism = :load

This is the key condition to executing the reload bits within Rails. Secondly, I needed to change the way WebORB on Rails loads classes. Previously it did this simply by calling the require method on the file path. Now however it uses the rails dynamic require_or_load method.

This feature is only enabled in development mode, as it incurs a performance penalty to reload classes; it was interesting to find out that instead of any kind of file listener on classes that should be reloaded, Rails simply reloads everything that is "reloadable" on every request when in development mode.

The net/net of this is: If you want your service classes to automatically reload in development mode add this line of code to just inside your service class:

include Reloadable

Or, if you get tired of including Reloadable in each class, create a base service class the uses the Reloadable::Subclasses module and have all your services extend it:

class BaseService
include Reloadable::Subclasses
end

Now you can stop wasting that extra 10 to 15 seconds everytime you make a change!! This will make you a more productive programmer. Productive programmers are happy programers. So by using WebORB you will be happy! :-)

WebORB 3.0 - What's Next (Flex Messaging, RTMP for .NET)

We will be releasing WebORB 3.0 Professional Edition into production next week. We're adding a few more configuration panels to the console, so it will be even easier to make any configuration changes in the final release.

Around the same time we'll be releasing the first Beta of the long-awaited Enterprise Edition. In addition to all the features available in the Professional Edition, the product includes a powerful platform enabling a new generation of highly dynamic, real-time messaging products. Here's a little preview of the features to be available in Beta 1:

• Flex Messaging - backend support for MXML Consumer and Producer elements/APIs
• Integration with MSMQ. Flex Messaging destinations can be configured to integrate with MSMQ queues. Any message sent by a Flex Producer to a destination is put onto the corresponding MSMQ queue. Likewise Flex Consumers automatically receive any messages from the queue the subscribe to (through a destination)
• Messages can be sent not only by Flex clients, but native applications too. A windows application can put a message onto a queue, and WebORB will deliver it to all registered Flex consumers
• Remote SharedObject support. WebORB Enterprise provides a runtime environment for Remote SharedObjects. Flex and Flash applications can easily exchange information in real-time through dynamically constructed shared objects. In addition to client-side support, any server-side .NET class (or application) can register to receive/publish data from/to shared objects
• Video streaming - WebORB Enterprise provides a mechanism enabling audio and Flash video streaming. FLV files deployed with weborb can be easily streamed to any Flex/Flash client.
• Client-to-client streaming. A Flex/Flash client with a camera and/or microphone can easily publish a stream to the server so it can be rebroadcast to any other connected client. Alternatively, the stream can be recorded on the server for a later playback.
• Standalone and hosted execution modes. All the features listed above are available either by hosting the product in IIS or executing it as a independent standalone process. It is important to note that the standalone mode also support basic Remoting invocations over the RTMP channel, so an HTTP server is not required.
  

Stay tuned for more announcements.

Mixing HTML and Flex using IFrame

One of the core elements of the new WebORB console is the TabNavigator component providing access to various product subsystems. Some tabs display nothing but a pure HTML content (introduction, getting started and documentation). The approach behind integrating Flex and HTML is quite simple. We borrowed the example created by Christophe Conraets and made some changes so it would work with Flex 2. Below is an example of the component in action followed by an overview of how it works:



The approach is very simple: the HTML page hosting a Flex application contains an IFrame and some JavaScript functions responsible for positioning the internal frame and configuring it to load html content. All the Flex-to-IFrame communication is encapsulated in a MXML component which extends Canvas (see IFrame.mxml). When a the component is set to become visible, it uses the ExternalInterface API to call on the JavaScript function to position the IFrame exactly on top of the component and load corresponding content. When the component is hidden, it calls a JS function to hide IFrame. In the example above, the same IFrame is used to render HTML for each tab.

You can browse and download the source for the example here.
The HTML page with the added JavaScript is available here.

The HTML file contains the following modifications:

1. moveIFrame, setIFrameContent, hideIFrame and showIFrame functions.
   
2. "wmode","opaque" parameters in the AC_FL_RunContent call. (If these parameters are not added, the html frame is not rendered properly.).
3. iframe declaration at the bottom of the file

I am sure there are a lot of things can be done to improve the usefulness and the performance of the component. If you come up with something interesting, please let me know.

WebORB for .NET 3.0 Release Candidate 2

One week later after we released RC1, there is a new update addressing all the reported bugs. We pushed Release Candidate 2 out tonight with the following fixes/improvements:

• Fixed code generation for the ARP framework for AS2
• Added code generation for the ARP framework for AS3
• Fixed Cairngorm code generation template
• Added code generation support for generics
• Added support to visualize array return value in TestDrive
• Client code for the value object classes not explicitly exposed by remote methods is now generated
• Added console configuration modules for WebORB Logging and Client/Server class mapping (see the Configuration panel)
• Added WebORB diagnostics utility (see the Troubleshooting tab)
• Fixed installer to use internationalized version of the "NETWORK SERVICE" user identity
• Fixed licensing to allow 3.0 and previous versions to coexist on the same machine
• Fixed deployment bug preventing web.config of the target application from being properly updated.

My favorite feature is the diagnostics page. Some users reported difficulty porting WebORB to their own application and in most cases it was a configuration problem. That led us to create the new diagnostics utility. The concept is very simple, connect to a dynamic script running out of the weborb assembly, and it checks if all the required settings and permissions are in place. It is very easy to run the diagnostics:

When you deploy WebORB into your application, copy diagnostics. aspx from the root folder of the default weborb installation (notice it is /weborb30 in rc2) to the root folder of your application. Once the file is there, point your browser to it:

http://localhost/[app-name]/diagnostics.aspx

Alternatively, if you already registered weborb.aspx as an http handler, you can run the diagnostics without copying diagnostics. aspx as shown below:

http://localhost/[app-name]/weborb.aspx?diagnostics