4/4 XACML SE used from a BPEL process

Tags: SOA, openesb, integration, BPEL, policy, XACML

This entry will focus on the usage of the XACML from a BPEL standpoint. The idea being illustrated here is the usage of a service engine by communicating with it through the NMR.

So, up until now, we have:

1. Created a Service Engine,
2. Created an open esb module,
3. Created a simple composite application.

These steps are sufficient to use the xacml se, and play with. But how do you use a service engine from another one? Can the xacml SE be called directly? You guessed that the answer is yes! Here's how it can be done.

Step 1. Current State for the Development Environment.

• The XACML SE is installed and running,
• The XACML module (the nbm file) is in your NB6.0 IDE and available for use.

Step 2. Defining the WSDL for the BPEL process.

At the moment, we will just keep it to its simplest expression for this sample. So, we just pass in the xacml request as an authorize request and return the answer in the xacml reponse format. This will allow us to keep the same soap ui test in this step also. In the original WSDL for the XACML service we have as the service description:

We see here that the service internal (to the JBI bus) xpath is XACMLService/endpoint, and that the XACMLAccess partner link type is defined. The following is the modified version of the WSDL for defining the access point for the BP:

We see here that the service internal (to the JBI bus) xpath is BPELWithXACML/endpoint, and that the BPELAccess partner link type has been added.Both partner link type use the same role, as they will provide the same web service API. So all in all, we simply add a new partner link type, and a new point of contact.

Step 3. Defining the BPEL Process Itself.

For now, the BPEL process is a simple pass through. It simple receives a request from the outside, and passes it to the xacml engine. A more complete BPEL would probably have to also call an XSLT engine to take the information it got from the inbound request, extract it, and place it in the XACML format. Not a road we are ready to cross just yet...

So we will have a BP with 4 steps in it and two partners.

So, here is a summary of the flow:

1. The ExternalRequester sends an authorize request to the BPELWithXACML/endpoint.
2. This request is received with the ReceiveAuthorizationRequest activity.
3. The process then does a InternalService.authorize in the InvokeXACML activity.
4. When it receives the answer from the InternalService partner, the process transfers the answer into the return values of the process and
5. Returns it to the ExternalRequester in the Reply2Requester activity.

That all that the process is doing.

Step 4. Building the Composite Application

How does the business process knows how to connect to the xacml service engine? This is part of the composing step of the development process. The picture below is depicting what we want to accomplish. To have an application in which there is two modules, one the BPEL module, and one the XACML Module. We could have used the external service model, and will eventually give it a try. Architecturally speaking, it would make sense to have the authorization SU be decoupled from the applications using them. But for now, having everything under one roof felt good, and in the scope of this sample, it is ok.

Once we did a build of the composite application, we can then take a look at the service assembly:

We see here that the interfaceRole_partnerRole (the internal service), is mapped to the XACML-SERVICE-ENGINE. This information provides partly from the testc2 module. If we would want to change some of the assembly information we could do it here, but this is a very simple assembly so the default is ok.

NOTE: In the names for the endpoints of the links for the BPEL engine, it is a mangle of the myRole/partnerRole attribute on the partnerLink in the BPEL definition. So, in BPELInterfaceRole_myRole, BPELInterfaceRole is the role name you give the BP in the partner interaction, while in interfaceRole_partnerRole, "interfaceRole" is the name of the partner role in the BP definition.

Step 6. Running a Test Through...

I won't post the test behavior here. You can take a look at the simple test, as the behavior is exactly the same. The only difference is the entry point in SOAP UI. In this sample, you need to use http://localhost:18181/BPELWithXACML/endpoint as the entry point for the test.

So, Any Final Thoughts ?

Glad you asked! While this concludes this phase of introducing service engine creation in openesb, there is a lot of work and material already on the subject. What this series of blog entries gave was the end to end development process with the utilities that open esb, netbeans and glassfish provides you with. There probably will be other elements added, like MBean monitoring, a more complex xacml module, and administration interface to the SE, etc... But the main thing is to get started. There is a lot to learn to be comfortable with developing service engines and binding components. But if you follow the code I actually had to do for this 4 parts blog series, you see that is it well below 100 lines for the service engine connection and usage. The wizard do take a lot of the guess work out of the development cycle. Expect your first service engine to take longer to develop than your second one. Mainly because the cost of learning the code that is already built for you, goes with the first service engine. It's like having to add the training period to the development cycle. Real project evaluation should be done with times taken from the second service engine development.

You can go to the open components site for a lot of already existing components there. No need to reinvent the wheel...

Now it's your turn. What service engine do you think would make sense? How can the development process be easier, faster? Let your imagination runs, and go and solve problems!

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