I thought I’d compile a list of differences between coding an Flex .NET remoting solution in FluorineFx and WebORB.
First off, the versioning:
FluorineFx: 1.0.0.13
WebORB (.NET): 3.5
Now, for various features/actions. These are typically in no order:
1. Registering a DLL to work in remoting
both: deploy the DLL in the “bin” folder (alongside “FluorineFx.dll” and “weborb.dll” respectively)
2. Destinations/Channels (in the WEB-INF/flex folder)
WebORB: Uses a “GenericDestination” that is exposed to all classes in all DLLs alongside the
<destination id="GenericDestination">
<properties>
<source>*</source>
</properties>
</destination>
Uses a set of channels including the default AMF channel
<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
<endpoint uri="weborb.aspx" class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling-enabled>false</polling-enabled>
</properties>
</channel-definition>
FluorineFx: Uses the “fluorine” destination that is open to all classes exposed as remoting (see point 3 below).
<destination id="fluorine">
<properties>
<source>*</source>
</properties>
</destination>
Uses a set of channels including the default AMF channel
<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
<endpoint uri="http://{server.name}:{server.port}/{context.root}/Gateway.aspx" class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
</properties>
</channel-definition>
NOTE: Due to a bug in Flex Builder 2 & 3, you must “Clean” your project to register and changes in the WEB-INF xml files.
NOTE: You can see that the “ContextRoot” setting is important in FluorineFx. If you aren’t running off the root domain, but in some other folder / virtual directory, you need to set up the Context Root to match that folder structure. ie. If you’re testing in “http://localhost/TestFolder” then you must set your Context Root in Flex Builder (Project Properties) to be “TestFolder”.
3. Exposing classses/methods from a DLL to Flex.
WebORB: WebORB will expose all namespaces/classes/methods from a destination by default.
This destination, when combined with the “source” property on a remote object, will expose everything inside your DLLs to the web. This can be toggled in the weborb.config file (under security->deploymentMode) to “closed”.
FluorineFx: Only those classes compiled with the [RemotingService] Attribute in C# will be exposed via FluorineFx, and even then only their public methods. NOTE: that class must be using the “FluorineFx” namespace.
4. Using SSL remoting
WebORB: The SSL channel is there by default “my-secure-amf”. If you ran your app from HTTPS, it would work by default as both the normal and the HTTPS channels are defaults. Alternatively (and for best practises), you can set up a destination to use it:
<destination id="MyDestination">
<channels>
<channel ref="my-secure-amf" />
</channels>
<properties>
<source>My.Name.Space.MyServiceClass</source>
</properties>
</destination>
FluorineFx: Doesn’t come bundled with a secure channel, but can do it easily. You just need to add the following to your services-config.xml file
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint uri="https://{server.name}:{server.port}/{context.root}/Gateway.aspx" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
</channel-definition>
Then you can add a destination in remoting-config.xml that uses “my-secure-amf” (see the WebORB solution above).
5. Manage security
WebORB: The WebORB console is fully featured to allow you to setup which services can be exposed to which users. You can limit a namespace, class or method by role, hostname, ip range or single ip (allowing masks). Essentially this just adds security configuration data to weborb.config but it’s handy.
To implement custom authentication and authorisation, you must implement Weborb.Security.IAuthenticationHandler and Weborb.Security.IAuthorizationHandler respectively (and add a reference to this classes in your weborb.config file under the security setting). Then you should be able to use the setCredentials() method on your remote object.
FluorineFx: Uses a similar approach to security, but it’s all done in the remoting-config.xml file instead. You need to manually add the constraints and apply them to destinations.
<destination id="MyService">
<channels>
<channel ref="my-amf" />
</channels>
<properties>
<source>My.Name.Space.MyServiceClass</source>
</properties>
<security>
<security-constraint ref="privileged-users"/>
</security>
</destination>
and then in your services-config.xml file
<security>
<security-constraint>
<auth-method>Custom</auth-method>
<roles>
<role>admin</role>
<role>privilegeduser</role>
</roles>
</security-constraint>
<login-command class="My.Name.Space.MyLoginCommand" server="asp.net"/>
</security>
Like WebORB, you’ll need to define your own authenticator/authoriser. You must implement the FluorineFx.Security.ILoginCommand interface. You then insert it’s name aboce, in the “login-command” setting above.
6. Data Type Mapping
Both: use the [RemoteClass(alias=”…”)] metadata syntax above your Value Objects in ActionScript to ensure the remoting gateway will return your objects as the correct type.
WebORB: Returns a DataTable as an array of objects (associative arrays representing a row). Returns DataSets as an object (associated array of arrays of associated arrays). Can optionally use Attribute [ReturnType(“namespace.actionscriptClassName”)] before your C# method to tell WebORB how to serialise the data in the DataTable (I can’t get this to work though).
FluorineFx: Must be told directly which type of data the DataTable/DataSet will be returning. Otherwise will return DataTables and DataSets in flat array without column associations.
You’ll need to use Attributes above methods in C#: [DataTableType(string remoteClass)] & [DataSetType(string remoteClass).
Justin J. Moses : Blog 
Recent Comments