WebSphere Integration Developer: a correction on Filter inputs in XML Transformations

When developing XML Transform in WebSphere Integration Developer (WID), you provide conditions on either “Condition” or “Filter Inputs” tabs of the transform properties. Condition tab usage is straightforward: you enter an XPath expression that is evaluated at runtime to a true or false. Filter Inputs, however, plays a trick on you. Help text above the tab indicates that you should enter a condition and the transform would apply to the input elements for which the condition evaluates to true.

But if you enter a condition that evaluates to boolean, a runtime error results, claiming this:

Can not convert #BOOLEAN to a NodeList!

This is your clue that help prompt and documentation are incorrect and you need to enter an XPath that evaluates to the list of nodes for which you want the transform to apply, and not the condition. Quick inspection of the generated XSLT conforms this finding: the value you enter into “Filter Inputs” is inserted directly into the select attribute of xsl:for-each element, e.g. if you enter Filter Inputs expression "$Status[Lev:Level='Error' or Lev:Level='Warn']", XSLT will contain this:

<xsl:for-each select="$Status[Lev:Level='Error' or Lev:Level='Warn']">
<xsl:copy-of select="."/>


Security for WESB services: WSRR as a good-governance alternative to LDAP groups

Quite frequently, access to Enterprise Services is secured based on individual user, but on requesting application (department, organization, org unit, etc). If one or another application in your company consumes an Enterprise Service, you may not be particularly interested in the identity of individual user behind a screen who clicked a button on an internal Web page, resulting in Web application making a call to mainframe behind the scenes. Knowing that the call came from a known internal application may be enough. In fact, often times there will be no individual user at all: the service call may be coming from a batch or unattended process.

If your Enterprise Service is hosted on WebSphere Enterprise Service Bus (WESB), how do you configure security (authentication/authorization) for this scenario? One obvious option is to leverage standard security mechanisms of WESB, which are effectively J2EE based. Create an ID for each requester application in your enterprise LDAP and use standard role-based access control to authorize access. Normally, you will create an LDAP group for each services access role and assign application IDs to those LDAP groups. This approach is simple and familiar to enterprises. But I can see one shortcoming: governance is often difficult to establish.

Defining access policies for enterprise services is responsibility of Enterprise Architects. But it is difficult to do this using LDAP. In a typical enterprise, processes for governing LDAP security changes are geared toward end user access. Roles, personnel involved, tools, ticket approval systems – everything is set up to deal with end user accounts. Enterprise architects are not involved in this process and would not be comfortable with security tools, because individual account maintenance is not their responsibility. Looking at the problem from the other side, security administrators may not even want to give Enterprise Architects access to account data that is required to effectively govern service account roles.

One possible solution to the governance dilemma is to use a true service governance tool, such as WebSphere Service Registry and Repository (WSRR). WSRR comes with a prebuilt governance templates in “Governance Enablement Profile”, including definition of SLA. If you establish an SLA between each service consumer application (department, etc) and consumed service. Then, in WESB (or WPS), you can insert “SLA Check” mediation primitive before actual invocation of a service. SLA Check primitive is new to WID/WESB/WPS version 7.0. It is very simple: it consults configured WSRR instance to determine whether there an SLA for particular service exists (for a particular user and in a particular context) and returns a simple yes or no. Now your service access is under control of WSRR, which Enterprise Architects understand and (hopefully) use daily. Service access is governed by the same tool as all other aspects of the service.

Problem solved? Unfortunately, WSRR solution has several shortcomings of its own:

  • LDAP-driven security is declarative, but WSRR-driven requires SLA Check primitive to be inserted (is programmatic)
  • Out of the box SLA lifecycle is quite evolved and requires several document types to complete. It is likely too complex for a simple task of service authorization
  • Establishing an SLA for every consumer-service pair is a lot of work.

All in all, I would recommend using SLA Check for service authorization if you highly value service governance, are unsatisfied with LDAP governance tools and process and prepared for the task of creating a massive number of SLAs. Otherwise, LDAP role-based security is still a more reasonable choice.

Java2 security and IBM WebSphere adapters

Don’t you love Java2 security? When enabled, it limits what your Java programs can do – by program, not by user ID. You would have to give code specific permissions to read/write files, access sockets, etc. Sounds great, doesn’t it? Well, it does not, at least in the world of enterprise and Web software where I live. In all my years in consulting going from one company to another I’ve seen only one place that used Java2 security. All others decided that it is more hassle then benefit.

And here’s another strike against it: when Java2 security is enabled in WebSphere Enterprise Service Bus (ESB) in a clustered environment, WebSphere adapter for CICS ECI does not work properly. You could see ClassNotFound exceptions when accessing the adapter. IBM support resolved the issue right away: just turn off Java2 security.