Monday, April 23, 2012

When to Use Custom XPath Functions in the SOA Suite

If you want to know how to create custom XPath functions, then have a look for example at Anthony Reynold's Blog entry on the topic. I have little to add to that excellent posting except for how to add parameters, which is done using the <param> tag as in the following example:



And the following simple piece of Java code to get the parameter from the list:

  public static Object compressGuid(IXPathContext iXPathContext, 
                                    List arguments) {
    String guid = (String)(arguments.get(0));
    ...
  }



If you want to know when or why to use custom XPath functions, then read on.

Before I come to some sort of a conclusions, first let's discuss some of the specifics of the mechanism of adding custom XPath functions.


One Function, One Class

First observation is that a custom XPath function is exposed by a class that implements the IXPathFunction interface. This interface enforces implementation of a call() method which executes the XPath function. As there can be only one call() method in the class, it can realize only one function. So if you want to implement more functions you will need to create as many classes as there are functions. To support reuse you can let each of those classes extend an (abstract) super class that will contain the common behavior and (static) reusable attributes.


No Runtime Versioning

A second observation is that the class to implement an XPath function ends up in a jar file that is deployed in the SOA infra structure. A class is not a service, so there can be only one implementation of that class at the same time. If you need to deploy a new version of the XPath function while keeping the previous one, you either need to put it in a different package or give it another name. On top of that you will also have to give the <function> another name (in the example resulting in a compressGuid, and compressGuid2). How ugly do you want it to get? An obvious other aspect is that the XPath function by definition is reusable for everybody that is deploying on the SOA engine on which the jar file is deployed.


No Right-Mouse-Click Deployment

By now you will realize that you cannot simply deploy a new version of the jar file on the server by just right-mouse-clicking it and then choose "deploy", and that this is for a reason. You will have to copy the jar file to a specific folder, run an ant script, and restart the server.


Conclusion

Custom XPath functions is not the silver bullet to do any type of Java embedding in SOA or BPM processes. Especially as a BPM developers you just might have hoped for this as, unlike in BPEL, there is no Java Embedding activity in BPM (also for a good reason you might argue, but that's another blog entry).

You should only create XPath function for specific types of cases, while applying some best practices:

  1. Only use it for XPath functions that clearly fits between all other already available XPath functions. An example is an XPath function I just created (based on the brilliant algorithm of my dear colleague Tonio Voerman), which compresses the 32 character Oracle GUID into 30 characters (because the column in which we have to store it, is only 30 characters long). After all the (existing) oraext:generate-guid() is also an XPath function.
  2. Be sure that the XPath function indeed is an obvious candidate for reuse (our compress-guid() function will be used by every BPM process). Otherwise, other solutions like including a Sprint Context in your composite, probably are better.
  3. Do your utter best to get the proper requirements for the interface, and functionality, to prevent you find yourself in a situation (and trouble) where you have to deploy a new version of the function next to an existing one.
  4. Test the XPath function thoroughly, preferable using some unit-testing framework like JUnit

Unbelievable, this is actually the first time in my life that I manage to post two entries on the same day. Normally I don't even find the time to do two in a week, or even a month for that matter!

4 comments: