WSRR: WS-I validator and loading WSDL files

To WebSphere Service Registry and Repository (WSRR) practitioners, I’d like to recommend this excellent developerWorks article explaining how to leverage WS-I compliance validator that is part of that software. Among the things you will learn: how to make this validator enforce arbitrary restrictions expressed in Schematron.

Just one thing to keep in mind: this article was written for WSRR 6.2 and you will not be able to reproduce the scenario in this article with default settings of WSRR 6.3 (original or with Fixpack 1). This is because MAKE_GOVERNABLE event will not fire for WSDL documents containing endpoint definitions in default setup. I recommend that you replace MAKE_GOVERNABLE with CREATE event in sample code – then it will work.

Here’s how the story unfolds. When you load a service document (a WSDL document or a SCA module) into WSRR, a complex sequence of actions is taken by the software behind the scene. WSDL document is validated. The document is parsed and concepts relevant to WSRR are identified. Those include service, port, binding, operation, message and endpoint definitions, XML schema elements and types. All these objects are linked together. As these objects are created, configurable modifier kicks in to enable governance and initiate appropriate lifecycle. Once one item in a collection of linked objects has governance enabled, all other linked items are pointed to the same governance record. From that point on, they are governed together: it is not possible to enable governance separately for any other item in the linked collection.

Configurable modifier named “Triggers” contains the following fragment:

<!-- Mapping to push the relevant items through the Service Endpoint Lifecycle -->
<model-type model-uri=""/>
<model-type model-uri=""/>
<model-type model-uri=""/>
<model-type model-uri=""/>
<configuration name="InitiateEndpointLifecycle"/>

And configurable modifier named “InitiateEndpointLifecycle” includes this:

<?xml version="1.0" encoding="UTF-8"?>

<action-configuration xmlns=""
xsi:schemaLocation=" Actions.xsd">

<!-- Transition the selected object into the SLA Lifecycle -->
<make-governable-action uri=""/>


These 2 modifiers are both enabled in Governance Enablement profile. Putting all this together, if a SOAP Service Endpoint is found in WSDL document, a SOAPServiceEndpoint object will be created and endpoint lifecycle will be initiated. WSDL document itself will be linked to the governance record of the SOAP Endpoint. It will not be possible to enable governance on the WSDL document separately.

Indeed, when a sample WSDL is loaded, we see exactly this effect. When I click on newly loaded WSDL document and proceed to the Governance tab, I see the following:

Governance Tab of WSDL document

Governance Tab of WSDL document

If I click on the “Root governance record” link, it takes me to the SOAP Service Endpoint:

SOAP Endpoint governance tab

SOAP Endpoint governance tab