Simple Endpoint Test for Asynchronous Unit and Integration Processes

In the creation of open-source RIAs, it can be very difficult to ensure connectivity of endpoints. There are potential snags and edge cases surrounding the following critical points:

• Security clearance of port
• Availability of port resource
• Conflicts between multiple running servers
  
• Properly-declared URI endpoints

As in point three, matters can be complicated when proxy servers, such as lighttpd or nginx are working in conjunction with apache. Most likely, both are open on different IP registers on port 80; apache proxy on localhost, and the lightweight server on the public IP.

An RIA will asynchronously connect via a RemoteObject call on another port. It requires a valid connection. Utilities like netcat can save you from a quagmire of ineffectual random testing.

First, open the port in apache, as it will be the ORM-enabled server. Typically, the port is 8000 or 8080 for arbitrary reasons of convention and familiarity. Make sure your 8000 or 8080 is not tied up with memchache or some other port-requisite ancillary utility. Open up ports.conf and add the port in the configuration script.

TEST THE PORT

Restart the apache server. Using a port utility such as netcat, test port connectivity. One quick way is to use netcat from a command line. Netcat will attempt to connect to any port(s) you specify and report the protocol it encountered:

nc -v -w 2 -z target 20-30

FIREWALLS

Don't forget to modify your security settings to allow the port! Specifically, if you have set up a firewall, iptables requires an entry allowing public connections over the port in question or connections will fail. If they have been changed, be sure to restart the apache server and that the rules have been saved either via command-line or the initializing script, usually /etc/network/interfaces.

Be sure your apache server's NameVirtualHost settings allow the wildcard * and not only localhost connections. This way, requests from your http-alt port will bypass your proxy server altogether. Apache might warn you thus, but it can be ignored:

[Thu Sep 03 16:20:42 2009] [warn] NameVirtualHost *:80 has no VirtualHosts

With these potential obstructions addressed, you should be able to tunnel your way to fame and fortune.

NEXT UP

How to put that port to use in an RIA RemoteObject call.

Beginnings of an RIA ECommerce solution

Another round of tests and some interesting results. I have successfully stubbed the mySQL database into Flex via .Net procedures created by WebORB. Also, I have added fields to the mySQL tables of interest without any unique key violations in the Miva CMS. I had to add primary keys to several tables in the database, but as stated, no adverse affects, meaning the db queries in miva's cms are fairly fast and loose. In this case that is a good thing.

Still working on the details, but so far it seems possible to do the following:

• Use Miva Merchant 5.5 as a backend solution for a rich ecommerce (web) application
• Use Flex 3 as a client frontend with RPC enabled products arriving from Miva
• Add custom fields as needed to elaborate on the data the Miva CMS typically allows

That's a good start. The test verifies an architecture consisting of Miva -> MySQL -> .NET -> Flex on the incoming side.

Now I'm looking into solutions for the Flex -> Google Checkout -> Miva on the shopping cart transaction side. For now, going to checkout will out of necessity pop out of the RIA window and open another. It's a small price to pay, especially considering there are virtually no single-state checkouts anywhere on the web. It hasn't hit the production line yet.

Since Miva is stable with additional fields in its DB but cannot administer the extra fields, my wishlist of useful add-ons now includes a secure Flex-based CRUD-enabled CMS to manage the custom fields added to Miva DB tables. It would be great to be able to post images and data through a form in Flex, and very possible time-permitting. For now, the method is direct DB data injection and FTP posting. Not good for a client admin, but fine for a developer at this point.

And the point is, it works!

SQL & LINQ for n-tier applications

As I've blogged a lot lately, WebORB bridges back end and presentation servers for AMF and DB CRUD functionality. Furthermore, once WebORB is configured properly, it deploys server and client code in an automated fashion, allowing this to happen. If you manage to rig it properly, it binds your data via method calls to the DB.

In developing an n-tier application, it's crucial to plan in advance how the tiers will provide for one another in the overall application chain. Justin J. Moses' blog of March 19th outlines the strength of utilizing SQL with LINQ in such a way. I especially enjoyed his definitions of generalized data transfer strategies as being either safety, hungry, greedy, or thrifty. Well done!

Since his description is more than adequate I won't go into it here, but seeing as it's a likely fit for my current project, I may post some notes later on data across the pipe with RIA.

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.

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.