3/4 - XACML JBI Deployment Module Creation

Tags: soa, openesb, integration, enterprise bus, xacml

Service Unit Creation

Once the Service Engine has been created (check here for this step), we can now move onto creating the Service Units. The service unit is the configuration that is proper to an application (a composite application). The information you put in there is at a minimum the jbi.xml file. But it can (and should in most cases), include configuration information, particularization to the application. For us, this will include the policy file, the WSDL file and the XSD for the XACML format.

Service Unit Structure

The Service Unit sits over the Service Engine. You could see the SE as the container, and the SU the configuration/data that makes the SE active. Without the SU, the SE should just sit idle. I say should because there are probably cases where a specialized SE could be doing some work.

The JBI File

The JBI file for the SU mainly provides the information about the connectivity (consumers/producers) of the SU. While the jbi.xml file can be extended to include some other information, this is not what we have done here.

The XACML Information

The XACML specific information is basically composed of four files:

• xacmlmap.properties, this maps service/operation from the WSDL to the specific policy file.
• <xacmlpolicy>.xml, this is the policy file to be used. While we distribute this in a file format, nothing would prevent someone to change the filereader to use an ldap connection instead... But in this case, the ldap information should either be added to the jbi.xml file, or in the xacmlmap.property file.
• The XSD file describing the XACML request format. Regardless of the specific operation implemented by the SU, the XACML request but have this format to be processed.
• Finally, the WSDL for the SE is also provided. This allows the user to change the high level service/interface/operations, but at the same time, includes the XSD file for the XACML format.

The JBI Deployment Plugin Wizard

The JBI deployment plugin (JBI DP) is what you use to create the JBI Modules. For some documentation on what the JBI deployment plugin does, take a look here. This would never been seen by the xacml users. Using this, you create the tool that will allow the users to create the SUs. Once this wizard has been created, the XACML module can be distributed as a Netbeans Module, an NMB file. See here for more information on this. There is fair amount of packages and classes being generated. This allows for very sophisticated modules, but are not using all the facilities here. The only thing we do is to place a copy of all the files stated above here, so when a user create a new SU, he gets a copy of the default files. The image below shows the structure the JBI DP generates.

In this, there is a single code change we need to do. This is the one that moves the files from the NMB into the user's space, for him to modify it.

In SEPluginProjectWizardIterator.createProjectSpecificArtifacts()

• In here, we see that the jbi.xml file is copied from the resources/jbi.xml right at the start.
• Then, we see that 4 artifacts are placed in the suArtifacts array. This will be also copied into the artifact list that the user is creating.

En la Casa...

Casa is the Composite Application Service Assembly. You can find information about it in the online help of the netbeans installation. This is where you can change the defaults of the application's interconnection. This can only be done once you did a "build" of the composite application. But at this time, there is not much to do here... In the phase where we integrate with the BPEL SE, we will have more to say on this subject.

Testing the Deployment

To test the deployment, you need to get the plugin installed. The recommendation the IDE is doing when you want to test the plugin is to do it in a "install/reload target environment" that is not your development IDE. While this is a sound advice, some version of the NB 6.0 won't work with the JBI version that is within the OpenESB distribution. So you may have to install the same NB version twice... One development and one target. Sound recommendation, especially since this is the default behavior...

So, you deploy the plug in in some environment, and you're ready to test the whole thing....

Testing the SE, SU and Service Assembly

We're now ready to fire up the SE. For this, we need to create a test application, which in JBI's case will be a composite application. But first things first.

• We have the SE deployed and up and running,
• We now need the SU

Creating the SU....

For this, we will create a new project, that is of type <SOA, sun-xacml-engine JBI Module>

In here, we see the list of files that we specified in the createProjectSpecificArtifacts() method. Now the step would be to change the WSDL and/or the policy file. The important part is to make sure that the xacmlmap.properties namespaces don't clash with anything.

Now creating the SA...

The act of creating the service assembly is to put the configuration of the service engine in collaboration with other configuration. Per the JBI spec, if we only deploy the SU for an engine, its interface becomes available through the web services interface. We will use this feature.

So, in the composite application "ca12" we deployed a unique JBI Module, which is the testc2 module. If we build the application project and take a look at the casa editor we get:

We see that the SOAP port is not connected to the service engine (the name is different because I changed name within the development cycle). The flow over the soap port gives us the same qualified end point as the service engine. We can now deploy this into the JBI Bus... In the following picture, you see the state of the service engine up and running, and the service assembly also available. This is a good point to turn on the logs for the service engine if you wish to do so.

Deploy and Testing with SOAP UI...

If you right click on the ca12 project, you'll the usual contextual menu. But on top of the usual items, there is also a SOAPUI option now (new for me at least...) When selecting it, it looks like this:

You can see that from the binding part of the menu, you get into elements that are specific to your WSDL. How cool is that?? When selecting this element, the SOAP UI usual interface shows up. For us, using it we will put in a sample request and get a response. I created this xml schema to make life easier.

Sample Request:

Sample Response:

Not very user friendly I must admit. But then, this SE is not to be called directly (at least not in my use cases), but from within a BPEL SE. And, you've guest it, this is the next step in this series of blog entries...

Enjoy!

Posted at 01:00PM Dec 05, 2007 by sergeblais in OpenESB  |  Comments[0]