[ XSOAP ]

XSOAP Toolkit Overview

Introduction

XSOAP (previously known as SoapRMI) is a RMI system based on SOAP that is implemented both in Java and C++ that allows to create and access web services. It has a simple and elegant RMI API that is not limited to Java RMI  but is interoperable with Apache SOAP and hopefully any other SOAP 1.1 implementation.

XSOAP-Java is using dynamic proxies and does not require stub compiler to generate stubs or skeletons It adds to SOAP a simple remote reference ie. binding of endpoint URL and interface type. And it has support for multiple transports, custom soap serialization styles, XML-Java mappings, using naming services such JNDI/LDAP (tested with OpenLDAP) to act as RMI Registry (and it has its own implementation of RMI Registry as well), access to web services directly without need to use naming service and a lot of other features.

Design Overview


Figure 1: SoapRMI 1.1 Java Architecture
\begin{figure}\begin{center}\epsfig{file=soaprmi11_java.eps, width=8cm}\end{center}\end{figure}

The design objectives of XSOAP 1.1 are as follows:

Figure 1 shows the architecture of  XSOAP 1.1 Java framework. It is designed in a modular fashion to enable the possibility of plugging in different implementations of various modules at a later date. The UnicastRemoteObject is used by objects to export themselves as remote objects. Every client and server has access to a soap-services module. This module encapsulates all the services like SOAP serialization and deserialization that any object in the RMI system may need. A serialized object is dispatched using a dynamic-stub to the HTTP connection layer. Since we use HTTP as the network protocol, each call has to be prepended with an HTTP header. On the receiving end, an HTTP embedded-server daemon waits for requests. Every request is directed to the dynamic-skeleton. The same dynamic stub and dynamic skeleton is used for every call of every remote object. Each XSOAP call and its parameters are associated with namespaces. The soap-encoding/Mapping layer maps the namespaces to known interfaces and types in the system. 

Our paper (available at XGWS main page) on XSOAP gives much more detailed overvioew of XSOAP and design decision that we have made.

Security Overview

In the system, we have some distinct requirements for security. The requirements can be classified as follows. At the lowest level we need transport layer security including both client and server authentication. Next we need authorization and, when these issues are resolved for a specific connection, we must consider delegation of authority.

Transport Layer Security (TLS via SSL) takes care of basic authentication of server and client. It is essential for the client to know that it is talking to the right server. A similar identification process may be needed for the server to trust the client. SSL/TLS is the most pervasive underlying protocol.

The design of the authentication API takes care that it is modular such that different security providers can be plugged in. The UnicastRemoteObject is replaced by a SecureUnicastRemoteObject interface on the server side. The SecureSoapServices module in turn tries to initialize the system with a given list of security providers. On establishment of a connection, the server and client go through an SSL handshake and authenticate the server and if required the client also. The exchange of data on this connection is now encrypted.

We use the Grid Security Infrastructure (GSI) to provide Public Key Infrastructure. The use of Java CoG kit that uses IAIK's SSL as the underlying protocol provides the authentication. The underlying implementation can be easily replaced by a similar system like Sun's Java security infrastructure. XSOAP/Java uses Java CoG kit to process the Globus user proxy certificates and then to manage secure connections with the server. The default mode of XSOAP using Globus grid proxies is as a personal web service, i.e. when a web service is started using a CoG Java provider it accepts only connections that uses the same user proxy for the client authentication.

The higher level of security would be the authorization of the client. Authorization means only certain types of clients may be given different rights to the services.

There is also a need for a service to access another service to satisfy the user's requests. The user may decide to delegate his credentials to the server that can be in turn used by the service to access other services on behalf of the user. To provide this functionality we are using GSI delegation capability.

XSOAP Interoperability tests

One of the most important features of web services is its interoperability between different web services implementation which is further facilitated by the use of XML. We would be happy to provide a testbed to cross-test with other similar implementations.

Currently XSOAP has been tested with LBL pyGlobus and LBL GSI Apache SOAP (that is based on Apache Soap 2.x).

Related Work

XML Pull Parser

XML Pull Parser 2 (XPP2) was designed for and it should be optimal for applications that require fast and small XML parser such as SOAP implementations - for more detail see XML Pull Parser Page

XEVENTS

Take a look on our system system

Links

XSOAP API

XSOAP FAQ

JSSE

Globus GSI

XCAT Tutorial

Common Component Architecture Forum

Extreme Lab


[ IU CS ] [ Extreme! Computing ] [ XGWS ] [ XSOAP ]
Lavanya Ramakrishnan and Aleksander Andrzej Slominski
Last modified: $Id: index.html,v 1.2 2002/03/24 17:57:43 aslom Exp $