Using JXTA for Firewall Traversal in Distributed CORBA Applications

Using JXTA for Firewall Traversal in Distributed CORBA
Applications
Ivan Neto∗, Francisco Reverbel
Department of Computer Science, University of São Paulo
Rua do Matão, 1010, São Paulo, SP 05508-090, Brazil
{ivanneto, reverbel}@ime.usp.br
Abstract. JacORB is a free Java ORB that is ETF-compliant, that is, it supports
the substitution of its transport layer in a standard way. JXTA is a peer-to-peer
protocol stack, also implemented as free software, which can traverse firewalls
and NAT gateways. This article describes an extended version of JacORB that
runs GIOP over JXTA. Binding CORBA and JXTA technologies together allows
components of distributed CORBA applications to be deployed in complex network environments, which may contain firewalls or IP address translators.
1. Introduction
Distributed applications based on CORBA [Brose et al., 2001, OMG, 2004a] are quite
common nowadays. CORBA offers many benefits to implementors of distributed systems, including platform and programming language interoperability, location transparency, flexibility and scalability. Even when application programmers do not explicitly use the CORBA programming model, CORBA protocols — the General InterORB Protocol (GIOP) and its TCP/IP specialization, the Internet Inter-ORB Protocol (IIOP) — might still be the underlying mechanism for remote method invocations. This is precisely what happens in the case of Enterprise JavaBean (EJB) components [Sun Microsystems, 2003a], an important part of the Java 2 Enterprise Edition
(J2EE) architecture [Sun Microsystems, 2003b]. GIOP and IIOP are the standard protocols for remote access to EJBs deployed in a J2EE application server. Moreover, some
of the essential services available to EJBs — security, transaction and naming services —
rely on CORBA protocols that run on top of GIOP. Much of the success of EJBs stems
from the fact that the EJB model is simpler than the CORBA programming model, but
still supports CORBA-based applications.
Like most distributed architectures, however, CORBA faces problems in
the presence of network address translation (NAT) [Egevang and Francis, 1994,
Hasenstein, 1997, Srisuresh and Egevang, 2001] or firewalls. Computers behind NAT
gateways usually do not have real IP addresses, but fake IP addresses that are valid only
within a local network. Such computers are not directly reachable from Internet hosts and
therefore they cannot receive IIOP requests from an Internet host. Firewalls are problematic because they may block IIOP requests to objects behind the firewall.
∗
Ivan Neto was partly supported by a fellowship from CNPq, Brazil. Grant number: 55.2028/02-9.
This paper presents a solution to these problems. We propose the use of
JXTA [Gradecki and Gradecki, 2002] — a peer-to-peer (P2P) protocol that can traverse
firewalls and NAT gateways — as the ORB1 transport protocol. Binding CORBA and
JXTA technologies together allows CORBA applications to run across protected LAN
boundaries. Moreover, a JXTA-enhanced ORB may be plugged into a J2EE application
server, as a replacement for the server’s regular ORB. Such an arrangement supports EJB
invocations across firewalls and NAT gateways.
Until very recently, there was no standard way of extending an ORB with a different transport layer. The Object Management Group (OMG) addressed this issue in
the newly adopted Extensible Transport Framework (ETF) specification [OMG, 2004c],
which defines a “transport plug-in” mechanism for extending the ORB so that GIOP runs
over a given (non-TCP/IP) transport layer. ETF support is already present in at least
one CORBA implementation: JacORB [Brose, 1997, JacORB Team, 2004], a Java ORB
available as free software. We have have used JacORB and JXTA to build the firewall
traversal solution shown in Figure 1.
Figure 1: Firewall traversal using JXTA
This paper is organized as follows: Sections 2 and 3 present background material
on JXTA and ETF, Section 4 describes our implementation of GIOP over JXTA, Section 5
presents preliminary results on the performance of JXTA as an ORB transport layer, Section 6 discusses ongoing and future work, Section 7 reviews related work, and Section 8
contains our concluding remarks.
2. JXTA - A peer-to-peer technology
JXTA is a set of open protocol specifications that makes it possible for virtually any kind
of electronic device (from cell phones to PCs) to communicate with other such devices
in a P2P way. If offers independence of programming languages, system platforms, and
1
The ORB is the middleware element that makes CORBA objects remotely accessible. It implements a
language-neutral remote method invocation mechanism.
network protocols. JXTA also supports firewall and gateway traversal, a crucial feature
for P2P networks that spread across various security domains.
The ability of running in very heterogeneous environments makes JXTA an attractive technology for distributed computing. Nowadays there are two bindings (implementations) of JXTA: one in C and other in Java. As JXTA is just a set of specifications,
however, new bindings may be implemented in the future. In our work we have used
the Java binding of JXTA, but the concepts we present here are common to all JXTA
implementations.
To get in the JXTA network you need to create a peer, that is, to start the JXTA
platform. This is done through a call to the JXTA API. As soon as your peer starts, it will
search on the JXTA network a special kind of peer called rendezvous peer. When the new
peer connects to a rendezvous peer, it sends information about itself (address, available
services and resources, etc). The rendezvous peer acts as an aggregator: it knows the
peers that are connected to it and the resources owned by each such peer. Note that
the rendezvous peer only records information about peer resources, but does not actually
owns those resources. Figure 2 shows the organization of a very simple JXTA network.
Figure 2: JXTA network organization – peers connected to rendezvous peers
A single rendezvous peer may have thousands of peers connected to it. An important characteristic of this kind of peer is that one rendezvous peer knows other rendezvous
peers on the JXTA network. This hierarquical organization leads to scalable procedures
for searching and publishing resources in the JXTA network. To access some resource, a
peer asks for the resource to its rendezvous peer. If the contacted rendezvous peer knows
the desired resource, it returns the resource address to the requesting peer. If it does not
know the resource, it will propagate the search request to all rendezvous peers it knows.
If any of these contacted rendezvous peers knows the requested resource, it will answer to
the first rendezvous peer which in turn will respond to the peer that made the request. If
none of these rendezvous peers knows the resource, each one will pass on the request to
all rendezvous peers they know, and so on. It is important to note that the search process
affects only the rendezvous peers, and not every peer. Since each rendezvous peer can
have thousands of peers connected to it, the number of peers involved in a search query
is quite small. When a peer wants to publish some resource, all it has to do is to send
relevant information about the resource to its rendezvous peer.
To understand how JXTA traverses firewalls we need to know another special kind
of peer: the relay peer. A relay peer must be located outside of firewall or NAT boundaries,
in a machine with a real IP address. It serves the purpose of relaying messages to peers
located behind a firewall or NAT gateway. The relay peer usually listens on a port number
that is open on the firewall for outgoing connections. Given the widespread use of the
World Wide Web nowadays, the port 80 is open for outgoing connections on virtually
every firewall.
In JXTA, firewall traversal works in the following way: a peer behind a firewall
or NAT gateway (which will be called inner peer) must know a relay peer. To connect to
another peer on the JXTA network, the inner peer sends a request to its relay. This relay
acts as a proxy, sending and receiving messages on behalf of the inner peer. Since the
relay peer is outside firewall or NAT boundaries, it can freely communicate with other
peers in the JXTA network. A request issued by the inner peer is then propagated to the
JXTA network by the relay peer. The corresponding response is sent back to the relay
peer. (It cannot be sent directly to the inner peer, which is unreachable due to the firewall
or NAT gateway.) So how does the relay peer deliver the response to the inner peer? The
inner peer periodically contacts the relay peer and checks if the response arrived. When
the response arrives, the inner peer pulls it out. Figure 3 illustrates this process.
Figure 3: JXTA firewall traversal
3. The CORBA Extensible Transport Framework
The Extensible Transport Framework specification defines a framework for implementing
new ORB transport layers and plugging such layers into an ORB. It standardizes the way
third parties design and implement a transport layer, based on any chosen protocol. The
new transport layer can be plugged into an ETF-compliant ORB, which will run GIOP on
top of that layer.
ETF specifies four interfaces that must be implemented by a transport plug-in:
• Profile: this interface represents the identity of an endpoint in the chosen transport protocol. The idea is that the object implementing this interface should hold
all addressing information specific to a given transport protocol. For example, in
the case of TCP/IP, the profile would contain an IP address and a port number.
• Connection: this interface represents a connection between two endpoints in a
given transport protocol. It has I/O operations such as reading and writing a stream
of bytes, flushing the stream, and so on.
• Listener: a server-side ORB’s transport plug-in must provide an endpoint to
which clients can connect. Such an endpoint is called a listener, and it must implement this interface. Listeners should be able to answer concurrent connection
requests from multiple clients.
• Factory: this interface is just an occurrence of the abstract factory design pattern [Gamma et al., 1995]. Its role is to provide a convenient way of creating
implementations of the other interfaces.
In addition to the transport plug-in interfaces, ETF defines an interface that must
be implemented by an ETF-compliant ORB:
• Handle: an interface that used by the transport layer to interact with the ORB,
through upcalls.
The transport plug-in writer merely uses the Handle implementation provided by the
ORB. He/she only needs to provide implementations of the four transport plug-in interfaces.
4. GIOP over JXTA
GIOP is an abstract protocol that runs on top of a chosen transport protocol (TCP/IP for
instance) and is used for communication between ORBs. It specifies the communication
syntax and a set of message formats for ORB interoperability over a transport protocol.
GIOP becomes a concrete protocol when it is specialized for a particular transport layer.
The most used specialization of GIOP is IIOP2 , which is nothing more than the GIOP
running over TCP/IP.
In order to implement a concrete specialization of GIOP for a given transport layer
(such as JXTA), all that is needed is to create a transport plug-in for that layer. Extending the ORB with such a plug-in effectively tells the ORB to run GIOP over the given
transport layer. It is interesting to note that, in the case of JacORB, even the default transport layer (TCP/IP) is provided by a transport plugin3 . JacORB uses its default transport
plug-in to run IIOP.
We have therefore provided JXTA-based implementations of the ETF-specified
interfaces Profile, Connection, Listener, and Factory.
We have chosen to provide two implementations of the Connection interface: one
for the client side, the other for the server side. The motivation for this design choice are
the differences between client-side and server-side connections. Here we have followed
the JacORB IIOP implementation, which takes the same approach.
The Profile implementation holds peer addressing information specific to the
JXTA transport. It contains a JXTA ID, which is a string that uniquely identifies a peer.
2
3
All CORBA-compliant ORBs must support IIOP.
This is true for JacORB 2.0 and later releases.
The Profile class also takes care of starting the JXTA platform and getting into the
JXTA network.
The Listener implementation waits for connection requests, in a way similar
to a server-side socket acceptor. Our implementation is multi-threaded, in order to allow
concurrent handling of multiple connection requests. As a connection request is accepted,
some operations are performed on the new connection, which is then passed up to the
GIOP message layer of the ORB, through the Handle interface. The GIOP layer uses the
connection to receive request messages from clients and to send out reply messages back
to those clients.
Finally, our Factory is a realization of the abstract factory design pattern. It
simply creates implementations of the other interfaces.
5. Tests
In our preliminary tests, the performance of GIOP over JXTA was considerably lower
than the IIOP performance. Figure 4 shows the results of some tests performed in the
following environment: the CORBA client was inside a LAN configured with NAT and a
quite permissive firewall; the CORBA server was in an independent network without NAT
or firewall. The client and server used in the tests are both very simple. The server has
two methods: one that returns a random integer, and other that returns a constant string.
The client calls each of these methods ten times and computes the average value of the
roundtrip invocation time. The results in Figure 4 are average values across five client
runs.
Figure 4: GIOP/JXTA x IIOP performance
The usage of GIOP over JXTA increased roundtrip invocation times (with respect
to IIOP) by a factor of about two orders of magnitude. This is not surprising, as JXTA is an
XML-based protocol. Similar results were reported by researchers that compared SOAP
(another XML-based protocol) and IIOP. According to [Elfwing et al., 2002], direct usage
of SOAP resulted in a response time ratio of 400:1 with respect to IIOP.
6. Ongoing and future work
Our current goal is to improve the performance of GIOP over JXTA. We believe that
there is room for significant improvements, but do not expect to reach the same level of
performance of IIOP. One reason for a somewhat lower performance is that JXTA is built
on top of TCP/IP, and hence it is inherently slower than TCP/IP. Another reason is that
JXTA messages are defined in XML, which is much more verbose than a binary message
format. Even so, the results in [Elfwing et al., 2002] for the SOAP protocol encourage us
to pursue similar improvements for JXTA: the authors describe techniques that can reduce
from 400:1 to 7:1 the theoretical response time ratio between SOAP and IIOP.
We also plan to run our JXTA-enhanced version of JacORB into a J2EE
application server and test EJB invocations across firewalls or NAT gateways.
JBoss [Fleury and Reverbel, 2003, Reverbel et al., 2004], a free J2EE application server,
uses JacORB as its ORB engine.
7. Related work
[Griffin, 2002] describes another approach to traverse firewalls, based on bidirectional
GIOP, an standard extension of GIOP. This extension allows CORBA servers and clients
on opposite sides of the firewall to change roles and maintain communication. Bidirectional GIOP, however, requires the initial server node (the host that initially acts in the
role of server) to be reachable from the initial client node (the host that initially acts in the
role of client). GIOP over JXTA does not have such a requirement.
The CORBA Firewall Traversal Specification [OMG, 2004b] is a new OMG standard. It discusses the limitations that firewalls impose to CORBA environments and defines a new component to be included in the IIOP profile. This component, tagged with
TAG FIREWALL PATH, contains routing information for firewall traversal. To the best of
our knowledge, no ORB implementation currently supports the CORBA Firewall Traversal Specification.
8. Conclusion
Our JXTA-based transport plug-in enhances JacORB with the ability of traversing firewalls and NAT gateways. Althought GIOP over JXTA has performance considerably
lower than IIOP, this may not be a major drawback for certain classes of distributed applications. In many cases, given a network environment containing firewalls or NAT gateways, it will certainly be better to have slower communication than no communication at
all. Moreover, we expect that further work should raise the performance of GIOP over
JXTA to the level of SOAP and web services, which are already widely used by many
applications. If this happens, GIOP over JXTA can play a significant role not just in traditional CORBA applications, but also in grid computing scenarios and J2EE deployments
in complex network environments.
References
Brose, G. (1997). JacORB: Implementation and design of a Java ORB. In Proceedings of
DAIS’97, pages 143–154. Chapman & Hall.
Brose, G., Vogel, A., and Duddy, K. (2001). Java Programming with CORBA. John Wiley
& Sons, 3rd edition.
Egevang, K. and Francis, P. (1994). The IP Network Address Translator (NAT).
RFC 1631, IETF. Obsoleted by RFC 3022.
Elfwing, R., Paulsson, U., and Lundberg, L. (2002). Performance of SOAP in Web Service Environment Compared to CORBA. In Proceedings of the Ninth Asia-Pacific
Software Engineering Conference (APSEC’02). IEEE Computer Society.
Fleury, M. and Reverbel, F. (2003). The JBoss Extensible Server. In Middleware 2003
— ACM/IFIP/USENIX International Middleware Conference, volume 2672 of LNCS,
pages 344–373. Springer-Verlag.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns. AddisonWesley, 1st edition.
Gradecki, J. D. and Gradecki, J. (2002). Mastering JXTA: Building Java Peer-to-Peer
Applications. Wiley, 1st edition.
Griffin, R. I. (2002). Firewall Traversal for CORBA Applications Using an Implementation of Bidirectional IIOP in MICO. Technical Report NASA/CR 2002-211979, NASA
Glenn Research Center.
Hasenstein, M. (1997). IP Network Address Translation. Diplomarbeit, Technische Universität Chemnitz, Chemnitz, Germany.
JacORB Team (2004). JacORB 2.2 Programming Guide.
OMG (2004a). Common Object Request Broker Architecture: Core Specification, Version
3.0.3. Object Management Group. OMG document formal/04-03-01.
OMG (2004b). CORBA Firewall Traversal Specification. Object Management Group.
OMG Final Adopted Specification ptc/04-03-01.
OMG (2004c). Extensible Transport Framework. Object Management Group. OMG
Final Adopted Specification ptc/04-03-03.
Reverbel, F., Burke, B., and Fleury, M. (2004). Dynamic Deployment of IIOP-Enabled
Components in the JBoss Server. In Component Deployment: Second International
Working Conference (CD 2004), volume 3083 of LNCS, pages 65–80. Springer-Verlag.
Srisuresh, P. and Egevang, K. (2001). Traditional IP Network Address Translator (Traditional NAT). RFC 3022, IETF.
Sun Microsystems (2003a). Enterprise JavaBeans Specification, Version 2.1.
Sun Microsystems (2003b). Java 2 Platform Enterprise Edition Spec., v1.4.