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
 |
The design objectives of XSOAP 1.1 are as follows:
-
To implement an RMI system in C++ and Java that conforms to SUN's Java
RMI API.
-
Provide access to Directory services based on RMI registry and LDAP.
-
Architect a XSOAP server to function as a web-service if needed.
-
Automate the generation of stubs and skeletons from XML-Schema based specification
of interfaces.
-
Enable multiple object serialization mechanisms in XSOAP-Java and recursive
serialization in XSOAP-C++.
-
Use the dynamic proxy classes provided as part of Java 1.3 to reuse the
same stub and skeleton for every remote object.
-
Support exceptions across C++ and Java platforms in an seamless manner.
-
Interoperate with existing SOAP based frameworks like .NET and Apache SOAP.
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