Sunday, 7 June 2009

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.

5 comments:

  1. Hi Keith,

    Interesting post, thanx. Good to see you're still alive and kicking, it's been a long time.

    Just a quick question "Why would you look at implementing a stand-alone HTTP server as opposed to using Weblogic's HTTP Server?"

    Also, would it not be much more practical to use a JSL client for tuxedo inbound messages and implement a servlet for weblogic inbound messages?

    I implemented this approach successfully at one of the clients I consulted for and would not hesitate to do this again.

    Thanx
    Casper

    ReplyDelete
  2. Hi Casper,

    It's been a while :-) I hope you are keeping well.

    If I was using Weblogic I'd use WTC to communicate between Weblogic and Tuxedo :-) But you make a good point. You could just as easily use the web server in the J2EE/servlet container with a Jolt client instead of using a standalone web server with a workstation client. This also has the advantage of eliminating one extra connection so it is simpler and would probably perform better.

    The reason that I wanted a standalone web server was so that it could run on the same host as Tuxedo, with the J2EE instance on a different host. That way there would be no concerns that a Tuxedo license would be required on the J2EE host.

    Perhaps the best solution is for an embedded and a standalone web server solution to be implemented, both using the same Tuxedo server.

    Thanks for your comments, and good to hear from you.

    - Keith

    ReplyDelete
  3. Hi Keith, I am new to tuxedo. Currently at my company we have an old legacy tuxedo configuration running on a solaris/sun server talking to a tuxedo at another company over a domain link (I guess). We would like to eliminate our tuxedo because of maintenance problems with both the hardware and the software. Is it possible to talk to the remote tuxedo without a tuxedo on our side? I read that a Weblogic Server can do that, is there any other option?

    Kindest regards, Marcin.

    ReplyDelete
  4. If your company just requires a Tuxedo client then you may be able to use Jolt [1] which allows you to write a Java-based client that connects to a Jolt listener (JSL) Tuxedo server that acts as a client on your behalf. You can also have a C/C++ based client using a workstation client connecting to a workstation listener (WSL) [2]. Another alternative is to get SALT [3] installed on the remote Tuxedo domain so that you can make web service calls.

    - Keith

    [1] http://docs.oracle.com/cd/E13203_01/tuxedo/tux100/jdg/dvintro.html
    [2] http://docs.oracle.com/cd/E13161_01/tuxedo/docs10gr3/ws/wsovr.html
    [3] http://docs.oracle.com/cd/E13161_01/salt/docs10gr3/overview/over.html

    ReplyDelete
    Replies
    1. Thanks for your response. Yes, we only need to connect as a client. The reason why originally we bought a Tuxedo was that the other site didn't want to enable anything else than a domain link. I have been informed recently that, fortunately, they will enable Jolt interface.

      - Marcin

      Delete

Labels