Multiple AMF Django apps share a common gateway

A while back I wrote about a library called django-flashpolicies for providing a flexible remoting environment. Essentially, it frees up the root of your django project for whatever content you like while providing a crossdomain policy file there for remoting applications.

That is still one way to go, but as an advance on that, have a look at the Django-amf-gateway library.

The PyAMF team offers info on it as a way to structure a django project such that you can heap on all the apps you want and allow them to share a common http gateway. By simplifying gateway addresses on the server side django-amf-gateway simplifies resource management on the client side.

Works great in applicable cases.

Proxy Debuggers and Flex NetConnection Debugger

With AS2, setting up a NetConnection between a Flash Player and a server running Flash Remoting could be streamlined using the Flex NetConnection Debugger. It was included with Flex 1.0 ca. 2005 and only required two short steps to enable. Many developers included it in their remoting utilities shortlist.

Now that we're living in a CS4 age, the playing field has changed. All the functionality of the NetConnection Debugger has been integrated into the Flash library. This means that instead of launching separate apps for debugging, you can simply mock up a routine using calls to available library components.

Good enough, but if you prefer a dedicated debugging app, NetConnection Debugger is out, and some other options are in its place.

Midnight Coders App Puncher

Much has been said about Midnight Coders' contributions to RIA development. Their middleware tier is arguably the best muscle around and can be a real time-saver. I'm speaking of WebORB, but particular to debugging, have a look at another of their products, the RIA App Puncher.

Charles Web Debugging Proxy

Link to Charles.

ServiceCapture

Link to ServiceCapture.

Putting available ports to use with AMF

In a previous post, see a detailed a procedure to choose and make available a tcp/alt port on a web server to avail the use of asynchronous data services. That post leads to this one, in which AMF calls are made over the available port.

To start, here is a method to test the port for an http response using netcat, via stearns.org:

echo -e "GET http://yoursite.com HTTP/1.0\n\n" | nc yoursite.com 80 | less

...or using the alternate available port...

echo -e "GET http://yoursite.com HTTP/1.0\n\n" | nc yoursite.com 8080 | less

This is a good example of using netcat as a client to get a response from an http service.

Analogous to this is the stated goal of this post, establishing connectivity between a lightweight client and an AMF service. Does that service by definition reside on an HTTP gateway? What type of gateway is the service? That remains to be answered.

For now, note that there is a starting example available from pyamf.com that allows you to test a connection to a third-party HTTP gateway. Titled PyAMF AMF Client, it works in the following manner to establish a simple methodology.

1. In SSH, launch a python command line
2. Load the modules in pyamf to initiate a test
3. Request the remote service and look for a successful response

Here, copied from the pyamf.com example, is the applicable sequence

from pyamf.remoting.client import RemotingService

client = RemotingService('http://demo.pyamf.org/gateway/recordset')
service = client.getService('service')

print service.getLanguages()

...which should directly result in the following response from pyamf.com

<pyamf.amf0.recordset><pyamf.amf0.recordset></pyamf.amf0.recordset></pyamf.amf0.recordset>

Why does this work as it should? Some of the reasons why it works

pyamf.remoting.client.RemotingService (see API)

We instantiated the class RemotingService, the instance call of which includes a parametric reference to an available gateway. Once you provide a valid gateway address, you have established a client for AMF calls.

getService method

The method parameter is the name of a service, in this case the service defined at http://demo.pyamf.org/gateway/recordset/. Try browsing to this address and you will see

400 Bad Request

To access this PyAMF gateway you must use POST requests (GET received)

The gateway provides information that it is a PyAMF gateway and only accepts POST requests. If you use netcat to contact the gateway...

echo -e "GET http://demo.pyamf.org/gateway/recordset HTTP/1.0\n\n" | nc demo.pyamf.org 80 | less

...you will get a similar response. If you netcat a POST to the gateway, you will get this...

HTTP/1.1 500 Internal Server Error
Date: Wed, 09 Sep 2009 15:21:18 GMT
Server: Apache/2.0.55 (Ubuntu) DAV/2 SVN/1.5.6 mod_python/3.3.1 Python/2.5.4 mod_wsgi/2.4 PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a mod_perl/2.0.2 Perl/v5.8.7
Content-Length: 534
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
info@pyamf.org and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>

This is a longer response, but not a successful response. The question remains, how can a request to the server result in a service initiation? Let's look at some other possibilities.

WebORB Synopsis Pt. 1

WebORB by themidnightcoders, aka Dallas-based Mark Pillar and company, is a software application designed to facilitate and ease RIA remoting. Over its livespan, WebORB has grown to its current ambitious version (3.6) to become a sophisticated multi-tool of sorts, providing a broad range of services for a pastiche of server types.

How does a product such as WebORB come to be? Weborb is in fact one among a stable of solutions (amfphp, swx, BlazeDS, RubyAMF, LiveCylceDS et al) initiated to bridge the expanse between server side and client side in rich applications. The options in this lineup range from Open source and free to commercial and costly, from single protocol to advanced suite. WebORB among them could be said to toss the biggest lasso.

WebORB marries server technologies .NET, PHP, Rails and Java to presentation server clients Flex, Flash, AJAX and Silverlight. It allows the server side to do what it does best - provide a data bank and administration, while allowing the client to benefit from a live data source. There's a lot more on offer than simple connectivity, however.

WebORB can be deployed in modular fashion to an existing web application. Once integrated, it includes a proprietary console GUI to demo its many capabilities. As is explained in the console, WebORB offers three broad categories of connection services:

1. Remoting (AMF3)
2. Data Management (WDMF)
3. Real-time Messaging

Among these, it is fitting to begin with remoting, as remoting was the initial goal of applications like WebORB. In its maturity as a service, invocation of remoting is bidirectional, fully interoperable, reflexive and essentially transparent. In addition to basic transfer of assets, WebORB remoting includes class mapping, secure channels of invocation, tree control with remote data, server-side exception handling, logins and security, and supports ARP, an open source framework for Flash and Flex initially authored by Aral Balkan.

WebORB effectively encapsulates the full capabilities of Flex Remoting, and in so doing, it lays bare the limitations of Remoting. Namely, that shuttling large serialized datatypes between environments is crude. It results in a loss of organizational nuance, such as hierarchies, relationships, dependencies. Put another way, the schema is not transferred with the data, and thus the sorting abilities that are the inherent value of a data system are lost. Data Management can be viewed as a means of addressing this limitation.

Data Management, aka WebORB Data Management for Flex or WDMF, is a means of preserving the relationships surrounding remote data between server and client sides. In a nutshell, WebORB imports table relationships directly from the server database and utilizes its own innovative analytical methods to create all the necessary interoperability through scripts it generates for both sides. In this way, WebORB enables explicit relationships to exist through a generative act of surrogation. In short, it analyzes, it marries, it step back into the shadows. Not bad, Midnightcoders, not bad. An invaluable utility and a tremendous time saver, Data Management also includes full CRUD, enabling the rich client to act as CMS if desired.

Real-time Messaging is another facet of WebORB to be explored later. Feel free to visit themidnightcoders site to learn more.

Adios for now.

httphandlers and asp.net

HTTPHANDLERS

They're a critical link in remoting, such as between a .Net application and a Flex presentation server. They can also be customized for other uses, such as dispatching synchronous or asynchronous data. Once you break the seal on httphandlers, you will likely discover they are profound in their utility.

This example demonstrates how to use HttpHandler technology using Asp.Net2.0 and C#.NET

This tutorial only uses the default namespace. The System namespace contains the EventHandler.

HttpHandler is a class that implements the IHttpHandler and IHttpAsyncHandler interfaces. This section describes how to create and register HttpHandler and provides examples of a synchronous handler, an asynchronous handler, and a handler factory.

First, you need to create a classlibrary HttpHandlerDLLVB. The code as follows:

using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.Web.SessionState;

namespace HttpHandlerDLL
{
public class MyHttpHander : IHttpHandler,IReadOnlySessionState
{
public bool IsReusable
{
get { return true; }
}

public void ProcessRequest(HttpContext context)
{
context.Response.Write("<h1><b>HttpHandler Test</b></h1>");
context.Session["Test"] = "Invoke a session in HttpHandler.";
context.Response.Write(context.Session["Test"]+"<br>");
context.Response.Write("<a href='HttpHandlerCsharp.aspx'><b>return</b></a>");
}
}
}

Then create a website project and reference classlibrary HttpHandlerDLLVB.dll.

At last configure your web.config as follows.

<httpHandlers>
<add verb="*" path="ViewHttpHandler.aspx" type="HttpHandlerDLLVB.HttpHandlerDLLVB.MyHttpHandlerVB,HttpHandlerDLLVB"/>
</httpHandlers>

The front end HttpHandlerVB.aspx page looks something like this:

<a href="ViewHttpHandler.aspx">Test HttpHandler</a></p>
</div>

The flow for the code behind page is as follows.

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{

}
}

Deploying WebORB for .NET

To deploy WebORB into an existing ASP.NET application, follow the steps below:

1. Copy the following files/folders from the default Weborb installation directory to the corresponding folders in the target virtual directory:

/weborb.config
/bin/weborb.dll
/bin/MySql.Data.dll
/bin/Mono.Security.dll
/bin/Npgsql.dll
/diagnostics.aspx
/WEB-INF
/weborb.js (required only for the AJAX clients)

2. Add the following XML configuration to web.config in the target virtual directory:

<configuration>
<system.web>
  <httpHandlers>
    <add verb="*" path="weborb.aspx" type="Weborb.ORBHttpHandler"/>
    <add verb="*" path="codegen.aspx" type= "Weborb.Management.CodeGen.CodegeneratorHttpHandler"/>
  </httpHandlers>
</system.web>
</configuration>

(Thanks to formatmysourcecode.blogspot.com for code formatting)


3. (Optional) To deploy console, example and code generator, copy the following folders with all files and subdirectories:

/weborbconsole.html
/console
/examples
/weborbassets
/all mdb files from the root

4. (Optional) Create /logs folder as the place where WebORB stores its log files

5. Grant Write permission to the user account ASP.NET uses for the following files and directories:

/weborb.config (required only if making configuration changes from the console)
/logs (required only if logging is enabled)
/weborbassets/codegen (required only if codegen is used in the console)
/weborbassets/uploads
/*.mdb (required only if writing data back on the server in some examples)

Additional steps may be required to configure logging and code generation features when deploying WebORB into another application. Generally the user account used by ASP.NET needs to have Write permission to the following files and folders:

/weborb.config
/logs
/weborbassets/codegen

Please direct any questions or comments to http://groups.yahoo.com/group/flashorb/.

Original document.