HTTP Transport

The HTTP transport layer conveniently adds support for receiving remote method invocations over the internet. It opens the door to rich-client interfaces that can from now on use an object-oriented approach to communicating with servers over the WAN, something that is usually implemented with XML. Of course, this does not invalidate XML for such use, but provides an alternative if clients are in Java, and if getting up and running fast is a must.

Ubik's HTTP Tranport layer is implemented on top of the Simple HTTP server.

Usage

The HttpTransportProvider can be used when wishing to export objects over HTTP using an underlying stand-alone HTTP server. In this case, you do not embed Ubik in a servlet, but rather use it as you would normally - to the exception that you must register the appropriate transport provider with the Hub.

Server-Side

The code below (again taken from Ubik's examples) demonstrates how a remote object is exported over HTTP:

public class HttpFoo {
  public static void main(String[] args) {
    try {
      TransportManager.registerProvider(
        new HttpTransportProvider());

      Properties props = new Properties();
      props.setProperty(Consts.TRANSPORT_TYPE, 
                        HttpConsts.DEFAULT_HTTP_TRANSPORT_TYPE);
      props.setProperty(HttpConsts.HTTP_PORT_KEY, "8080");
      Hub.exportObject(new UbikFoo(), props);

      while (true) {
        Thread.sleep(100000);
      }
    } catch (Throwable t) {
      t.printStackTrace();
    }
  }
}

See the HttpConsts interface for the constants that are used in the code.

Note that in the above example, the URL of the server is not specified; the URL that is used then is of the format http://local_ip_address:port/ubik. The port is in this case expected through a property (as shown in the code above); if not specified, the underlying HTTP server will be listening on the default port: 8080. The URL will eventually be used by stubs on the client-side; if this is not what you want (because your server might be behind a firewall/load-balancer, and stubs in this case cannot connect to your server directly), you can specify the URL to which stubs will connect:

// Do not forget the trailing "/ubik" path
  // when using Ubik HTTP in standalone (not in a
  // servlet container)
  props.setProperty(HttpConsts.SERVER_URL_KEY, 
                    "http://www.somedomain.com/ubik");

Note that the above feature really makes sense only if your HTTP-remoted object hides behind some proxy, and that all clients are expected to originate from beyond such a proxy.

If you wish that the path to which the exported object corresponds be mapped to something else then "/ubik" (the default), and that you are not using the URL substitution scheme - explained previously, then you can specify a different path:

props.setProperty(HttpConsts.PATH_KEY, "/somePath");

Client-Side

The client corresponding to the above server would look like this:

public class HttpFooClient {
  public static void main(String[] args) {
    try {
      TransportManager.registerProvider(new HttpTransportProvider());

      Foo foo = (Foo) Hub.connect(new HttpAddress(Uri.parse(
              "http://localhost:8080/ubik")));
      System.out.println(foo.getBar().getMsg());
    } catch (Throwable t) {
      t.printStackTrace();
    }
  }
}