a flavour of web services

Fri, Jul 1, 2005

During the Guanxi SP development I did a bit of reading up on web services, as it’s a distributed application, with the Engine residing anywhere you want on the ‘net with Guards deployed and sanctioned by the Engine to protect resources in different domains. The security of such a setup is another matter but Guards are sanctioned via a handshake with the Engine when a Shibboleth session is initiated. If the Engine doesn’t match the Guard to correct metadata it will refuse to communicate further with the Guard and will disable it until it’s problem is sorted.

Anyway, to do all this takes web services and I got a taste of the web services on offer. Bit like cakes really.

  • JAX-RPC. This is the "hardest" web service to deploy and use. It's a pain. I use Axis to provide this service. Using RPC you expose methods in your class to the outside world and Axis handles the SOAP messages to and from the methods. You can use static stubs and skeletons to implement the remote side of things but that means if the service you're accessing changes, you have to recompile all your stubs and skeletons. I didn't want to go there for a relatively small app like the Guanxi SP, so I chose Dynamic Interface Invocation (DII) which is much easier but makes your method code a bit esoteric as it's full of JAX-RPC specific calls. You just tell Axis where and what you want to call and it does it. You can also set up a client side handler if you want. I wanted to as I needed WS-CallBack functionality.
  • SOAP POSTing via SAAJ. This is quite a convenient way to bounce SOAP messages around your distributed application. The Guanxi SP does this as the Engine receives a SOAP message from the IdP's AA containing all the attributes and it just passes this directly to the Guard's Attribute Consumer (AC) "service". The AC "service" is a web service but it's not JAX-RPC. It's a servlet that knows how to handle SOAP messages in it's doPost method. That's all. The problem with this is SAAJ is synchronous. It expects a reply and it expects that reply to be a SOAP message. However, JAX-RPC replies with a SOAP message too. It's just that you don't see it as Axis does the SOAP to Object mappings for you. Then again, even though it is SOAP, it's Document-Wrapped so it's easy to interpret if you have the schema, which I do, so it's easy!
  • REST. This is the third type of web service that the Guanxi SP uses. Again, it's just a servlet that knows how to handle parameters it gets via it's doGet method. The Guanxi SP makes use of REST when it gets the SOAP reply from the Guard's AC. It extracts a session handle from the SOAP message and sends it on to the Guard's decision making engine via a REST call, i.e. a Response redirect.

We can combine the whole lot into one Servlet:

3 layer web service servlet

The Servlet’s init() method sets up the environment in which the service will work, the doPost method handles raw SOAP calls from, say, a SAAJ engine, the doGet method handles REST calls and finally, you can have a load of non servlet methods that you expose via JAX-RPC and Axis.

A simple example could be a Virtual File System’s facade. The Servlet could manage access to the filesystem. A desktop client could be developed to upload files using SAAJ/SOAP and attachments (handled by doPost). A user could just browse the filesystem through their browser (handled by doGet) and low level software agents could negotiate access and up/download files direct to the filesystem via the JAX-RPC methods. All three types of service interface have access to the same filesystem environment.

comments powered by Disqus