Ideas for a Tuxedo adapter

For enterprises that have legacy BEA Tuxedo systems, one of the main benefits you get from using BEA Weblogic (or now Oracle Weblogic?) as a J2EE product is the Weblogic Tuxedo Connector (WTC). WTC allows the J2EE container to connect to a Tuxedo domain in the same way that a normal Tuxedo domain does. You create domain gateways, can import and export services, apply ACLs, set domain passwords etc. This functionality is not available from any of the other J2EE vendors (eg. JBoss) as far as I can see which puts them at a significant disadvantage when bidding for business with these enterprise customers. (I am talking from personal experience here.)

This state of affairs surprises me though because it should be relatively straight-forward to make a simple bi-directional HTTP-based gateway. (The company I work for created a really simple unidirectional gateway for each direction which is even easier but rather clunky IMO.)

For calls from external applications to Tuxedo I'd have an HTTP server that is a Tuxedo client, and for calls going from Tuxedo to an external application a Tuxedo server than is an HTTP client. Then I'd create a simple XML representation of an FML32 buffer (which I did in a past life and I'm sure could pretty easily reproduce). Ideally this HTTP and Tuxedo functionality would be built into a single Tuxedo server binary that could just be deployed in a Tuxedo domain, but separate components could work okay as long as they were really easy to set up.

For the HTTP server I'd probably start with one of the webservers from acme.com - maybe a stripped down version of thttpd - or DJB's publicfile.

For HTTP clients there is libcurl or ACME's http_post or DJB's http@.

The Tuxedo client could either use the native API (if it is embedded in the Tuxedo server) or the workstation API (if it is in an external process), in which case it would connect to a workstation handler instead. The service called would be determined by looking at the incoming XML message and converting the rest of the message into an FML32 buffer.

The Tuxedo server should be configured to advertise any number of Tuxedo services and then create an XML message with the XML32 buffer contents and the service name. It should be possible to call a different URL based on what service is called.

For security there could either be none if the server is listening on localhost, or SRP or a pre-shared secret for a secure connection. If the applications are internal and no third-party verification is necessary I'd avoid using SSL - the password files used by SRP are much easier to manage than regularly expiring SSL certificates.