AAA and AIR Web Service: integration notes

Paola Grosso - Uva AIR
Mar 15 2005
BasVanOudenaarde -UvA AIR
June 3 2005

The following are the notes relative to the integration of the AAA Toolkit and the AIR Web Service.
The AIR Web Service in its current form provides monitoring and managing web service interfaces to the network elements located in the UvA LightHouse.
The integration with AAA allows control on the users that can access the service, expecially when it comes to the managing part.

A new version of this web service is coming up, and we have some notes in ResourceBrokerProject... but this is another story.
The current working version of the Web Service is described in a WSDL file:
http://vangogh0.uva.netherlight.nl/AIRWebServices/NetherLight-WS-rpcstyle.wsdl∞

Integration steps

The procedure that any generic Web Service should go through to be able to integrate with our AAA are:

1. Bean creation
2. Bean deployment
3. Request schema definition
4. Policy definition
5. Message test
6. Client code

We will explain in detail what we did for each one.
Note that for simplicity we will call $HEAD the root directory of development (in our case $HEAD is /home/oudenaar).
Also to make this more readable we will focus on just one specific operation supported by the AIR WSDL file and will show how to integrate this.
<operation name="getDnsName">
<input message="tns:dnsNameRequest"/>
<output message="tns:dnsNameResponse"/>


The final result can be viewed at:
http://pizza2.uva.netherlight.nl:9080/AIR∞

1. Bean creation

I created for this service an ASM that defines the methods that are available for the Web Service.
There are three files:

This is because of the J2EE framework, we need to develop a Bean (Session Bean) to deal with our business (this case invoking the WebService operation). The AIRHome.java is needed to create this Bean in the container. The AIR.java expresses the remote interface, which is called thru the EJBHome object to talk with Bean.
We are using java reflection from our RBE to find the right bean and method with arguments. The select on the arguments with reflection the arguments needed to Objects. In case of primitives value in the business methods we need a special Reflection call which we make public.

2. Bean deployment

To deploy a new bean or changes to an existing bean, you need to run:

• ant
• deploytool (shipped with the SUN appserver)

in the directory $HEAD/AAA_tk/AAA/ejb

The deploytool offers a graphical interface that allows to install the ASMs and deploy them (will not go into details on how to do this).

3. Request schema definition

The request sent to the AAA server need to be defined in a schema.
In our case we wrote a .xsd document:
$HEAD/AIRService/resrc/AIRService.xsd
and we have copied it into the /var/www/html directory (why we did this is not clear to me)
The .xsd document will define the elements present in a request to the AAA server.
This is needed to write the policy and also to write the code to create request from a AAA client such as a web form.

For a non trivial web service, such as the AIR web service, the schema needs to indicate which input fields are associated with each possible operation supported.
This should be elaborated a little better, and I leave this to Bas or Fred. The first implementation of AAA dealt with a simple Web Service (the Magic 8Ball) that had one operation with no input variables, while the AIR service has multiple operation each one with one or more input fields.

4. Policy definition

This goes beyond the scope of this notes. In particular we do not want to focus on the syntax required to build a AAA policy.
Suffice to say that the policy reside in the directory:
$HEAD/AAA_tk/PolicyMng
... and that the one that controls access to the AIR Web Service is called AIRService.policy

Once the policy has been written we need to do the following commands to deploy:

• rm *.spo (to remove the old corresponding .spo file: what is an spo file? I see that is a Java serialization data, version 5 file)
• genPolicy AIRService (it invokes a script that I believe compiles the policy and produces the new .spo file)
• java DBmngr AIRService 3 (code #3 removes the policy from the database)
• java DBmngr AIRService 1 (code #1 installs the new policy in the database)

5. XML message test

We can test directly the deployment simply using an XML message sent to the AAA server.
We need to build a .xml file that contains the correct message.
In our case we have a file called AAA_AIRService.xml located in directory:
$HEAD/AAA_tk/AAA_msging/AAA_AIRService.xml
The file looks like:
To try out the message against the AAA server just run:
ant run -Dport=8080 -Dhost=pizza2.uva.netherlight.nl -Dxml-file=AAA_AIRService.xml
where port and host and xml-file are related to the AAA server location

6. Client code

The client code does not need to be on the same machine where the AAA server runs.
In our case we have chosen to deploy the client portal on the machine called trafficlight:
http://trafficlight.uva.netherlight.nl:8080/AIR∞

On this machine we have a directory ~tomcat/AIRService/portal, that contains the client code.
In the subdirectory src we have two java classes:

• AIRServlet.java
• AIRAAARequest.java

These files need to be modified to correctly parse the inputs coming from a web form and to properly craft the message (following the schema previously defined) sent to AAA. We also need to modify the jsp file located in ~tomcat/AIRService/portal/web to display the correct web interface.

In general you will need to:

Not sure if we need to go into more detail on the modification that need to be done in this step.

Problems/fixes

We have encountered a problem relative to the use of xsd:int in the schema describing the service.
We had to add the following two jar files to the Jakarta:
<jakarta>/common/endorsed
directory
to avoid runtime errors for unrecognized symbols.