Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

Artifact content validation in WebSphere Service Registry and Repository

Xin Peng Liu (xinpengl@cn.ibm.com), Software Engineer, IBM, Software Group
Photo of in Peng Liu
Xin Peng Liu is a Staff Software Engineer at the SOA Design Center in the IBM China Software Development Lab. He concentrates on SOA policy and governance, and his interests include J2EE, SOA, MDA/MDD, AOP, and the semantic Web. He is currently doing design and development work related to an SOA policy toolkit.
Xi Ning Wang (wangxn@cn.ibm.com), Software Engineer, IBM
Photo of Xi Ning Wang
Xi Ning Wang is a software engineer in China in the Service-oriented Architecture (SOA) Design Center. He is on the SOA Advanced Technologies team within the IBM Software Group, where he develops SOA technology development. Currently, he focuses on the areas of Web services, modeling- and policy-related technologies.
James Mark Williams (JamesW@uk.ibm.com), Software Engineer, IBM
Photo of James Williams
James Williams is a Software Engineer on the WebSphere Service Registry and Repository functional verification team at at the IBM Hursley Software Lab in the UK. Previously he worked in the test group for WebSphere Voice Response.
Liang Xue (xueliang@cn.ibm.com), Staff Software Engineer, IBM
Photo of Liang Xue
Liang Xue is a Staff Software Engineer at the SOA Design Center in the IBM China Software Development Lab. She concentrates on SOA governance related topics, including SOA policy and SOA metadata management. She received a Ph.D in 2006.

Summary:  This article uses an an example to show you how to configure and customize the WebSphere Service Registry and Repository content validator, and how to enforce recommended practices on WSDL content.

Date:  13 May 2009
Level:  Intermediate
Also available in:   Spanish

Activity:  5951 views
Comments:  

Introduction

IBM® WebSphere® Service Registry and Repository V6.2 provides several methods of artifact validation, and validation can take place on the metadata associated with an artifact as well as on the content of the artifact. Content validation was added in WebSphere Service Registry and Repository V6.2, to verify WSDL and XSD compliance with the WS-I Basic Profile 1.1 specification. WebSphere Service Registry and Repository provides three main validation methods:

  • You can create a plug-in to perform validation via the WebSphere Service Registry and Repository system programming interface. For validation during create, delete, or update operations, you need to write a Java class that implements the ServiceRegistryValidator interface. For validation during governance operations such as transition, validation, make governable, and remove governance, you need to create Java classes to implement the ServiceRegistryGovernanceValidator and ServiceRegistryGovernanceValidator2 interfaces.
  • You can use the governance policy validator framework for validation. You can restrict operations (create, update, delete, transition, validate, make_governable, and remove_governance) based on the metadata (properties, relationships, and classifications) attached to the artifact in question. You specify these policy rules using WS-Policy format files, which contain governance policy domain assertions. You can extend these assertions by writing an additional Java class that implements the ServiceRegistryGovernancePolicyPlugin interface, which is invoked via a PluginAssertion element.
  • For WSDL content validation, you can use the WS-I validator supplied with WebSphere Service Registry and Repository V6.2. This method uses the Governance Policy Validator framework method as well as a rules file (supplied as a document content policy configuration item) to validate WSDL content. This validator checks that a WSDL conforms to the WS-I Basic Profile 1.1 specification, and can inform users of violations either via a text report or an exception.

This article focuses on the configuration and customization of WSDL content validation and on how to define your own WS-I validation rule set.

A fictional Online Retail Company (ORC) is used to demonstrate how the WSDL content validator can be modified to accommodate different requirements. The article shows you how to remove rules that are of no interest to the customer, how to change the severity of any violations (error or warning), how to configure custom warning messages (requires WebSphere Service Registry and Repository V6.2.0.2 or later) , and how to enforce recommended practices with a custom rule. The following steps will be performed to demonstrate WS-I configuration and customization:

  1. Configure WS-I validator
  2. Customize WS-I validator
  3. Enable the new WS-I configuration rule set
  4. Demonstrate the capabilities of the customized WS-I validator

Following these steps is a section on defining your own WS-I validation rule set.

Configuring the WS-I validator

Configuring the WS-I validator requires two steps:

  1. Enable the governance policy validator. Navigate to the Configuration perspective, expand the Active configuration menu, expand the Plug-ins sub-menu, and select Validation Properties. Click the ValidationProperties link to view the validation properties content. For both the validators and the governanceValidators entries, you need to add com.ibm.sr.governance.validator.GovernancePolicyValidator to each value as show in Figure 1. If you already have existing values for these keys that you want to keep, then append the new value at the end of the line separated by a comma:

    Figure 1. Validation properties
    Figure 1. Validation properties

  2. Load a WS-I validator policy file. Its format is described in the WebSphere Service Registry and Repository V6.2 information center. An example is shown below. Load this file as a governance policy validator configuration item named WS-I Policy.

Validator policy file
<wsp:Policy wsu:Id="uuid:governanceProfileId" Name="GovernanceProfilePolicy"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-
1.0.xsd"
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    xmlns:wsrrgp="http://www.ibm.com.policy/GovernancePolicyDomain">

  <wsrrgp:ValidatorPolicy wsrrgp:name="plugin_wsi_validation_policy2">
    <wsp:Policy>
      <wsrrgp:ContentApplicabilityFilter wsrrgp:targetXPath="/WSRR/WSDLDocument"/>
      <wsrrgp:WSRROperationFilter>
        <wsrrgp:WSRROperation>MAKE_GOVERNABLE</wsrrgp:WSRROperation>
      </wsrrgp:WSRROperationFilter>
      <wsrrgp:EntityAssertionPolicy wsrrgp:name="plugin_wsi_status_confirm">
        <wsp:Policy Name="plugin_wsi_status_policy_confirm">
          <wsrrgp:PluginAssertion wsrrgp:name="Invoking WS-I Compliance Validation"
              wsrrgp:class="com.ibm.sr.policy.wsi.WSIComplianceValidator"
              wsrrgp:options="rules=WSIBasicProfile11;report=true">
          </wsrrgp:PluginAssertion>
        </wsp:Policy>
      </wsrrgp:EntityAssertionPolicy>
    </wsp:Policy>
  </wsrrgp:ValidatorPolicy>
</wsp:Policy>

The ContentApplicabilityFilter element defines an XPath target of WSDLDocument and the WSRROperation element defines an action of make_governable. The results is that WS-I compliance validation is used on all WSDL documents entering a governance lifecycle.

Within the wsrrgp:options element there is a report option, which specifies whether you want WS-I validation to be enforced (report=false), or you do not require enforcement and would just like to be informed of rule violations (report=true).

Customizing the WS-I validator

An example of WS-I validator customization is described below for ORC. The company offers an online system to provide a variety of services for its customers, including the capability for them to select multiple items in the online store and submit them in a group. ORC uses WebSphere Service Registry and Repository to manage their services. WS-I validation is triggered when the company loads the Web service metadata, including WSDL files, into WebSphere Service Registry and Repository.

The administrator examined the technical implementation of the online retail system and found that an extended array type is used to support data exchange in the ordering service. In the WS-I Basic Profile 1.1, three entries (R2110, R2111, and R2112) are declared to describe the interoperability of arrays. Table 1 shows the information for each of those three rules. WS-I Basic Profile 1.1 says that the array extension is not allowed for compliance. However, ORC has only one platform and the Web service ensures correct data exchange. There is no need to modify the WSDL files to restrict array usage, but the administrator still requires the WSDL documents to be validated against the remaining Basic Profile rules. Therefore, these three array checking rules should be removed when the Web service metadata is being loaded into WebSphere Service Registry and Repository. Listing 1 shows the corresponding validation rules which you should remove from the Document Content Policies for WS-I validation:


Table 1. Detailed description of array checking rules
NameDescription
R2110In a DESCRIPTION, declarations MUST NOT extend or restrict the soapenc:Array type.
R2111In a DESCRIPTION, declarations MUST NOT use wsdl:arrayType attribute in the type declaration.
R2112In a DESCRIPTION, elements SHOULD NOT be named using the convention ArrayOf.

Listing 1. Array checking rules in document content policies
<rule context="...">
<let name="importedDocName" value="..."/>
<report id="R2110" test="...">
  RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|WSI_BP_11_R2110|<name path="..."/>
  \<value-of select="..."/>|ERROR|<value-of  select="..."/>
</report>
<report id="R2111" test="...">
  RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|WSI_BP_11_R2111|<name path="..."/>
  \<value-ofselect="..."/>|ERROR|<value-of select="..."/>
</report>
<report id="R2112" test="...">
  RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|WSI_BP_11_R2112|<value-of select=
  "..."/>|ERROR|<value-of select="..."/>
</report>
</rule>

In WebSphere Service Registry and Repository, the document content policies for WS-I validation are in the Configuration perspective. To see the rules for WSIBasicProfile11, select Active Configuration Profile => Plug-ins => Document Content Policies. Then, click the file of WSIBasicProfile11, and the content of the configuration item is displayed, as shown in Figure 2. The highlighted part shows the rule concerning R2110, R2111, and R2112:


Figure 2. Content of WS-I validation rules file; WSIBasicProfile11
Figure 2

Click Download document and rename the saved file to WSIBasicProfile11V2.xml. Then remove the rule segment described in Listing 1 from WSIBasicProfile11V2.xml. This file will eventually be loaded back into WebSphere Service Registry and Repository and be used as the new rule set for the ORC, based on their particular requirements. ORC also provides an inventory management service that you can use to calculate the inventory status of various items. To meet redundancy and load balancing requirements, ORC deploys several inventory calculation services in different locations. All of these services use one inventory calculation interface. During the Web service implementation, the use of the import element allows the separation of the service interface and the specific end-point implementation. The import element has been put into different areas of the importing WSDL document and the namespace uses a relative URI based on the organization's structure. This violates the R2022 and R2803 rules in the BP 1.1 profile. Table 2 shows these two rules:


Table 2. Detailed description of array checking rules
NameDescription
R2022When they appear in a DESCRIPTION, wsdl:import elements MUST precede all other elements from the WSDL namespace except wsdl:documentation.
R2803In a DESCRIPTION, the namespace attribute of the wsdl:import MUST NOT be a relative URI.

ORC can identify the imported element wherever the import element has been placed. Also, the relative URI reference is unique and can be identified by the retail system. Therefore, ORC would like to use WARNING messages to identify the severity of the rule violation and it would like to use a customized message for clarification. These warnings and messages can be used if the WSDL file is reused by a third party.

Listing 2 below shows the required modifications in bold: the record reports for R022 and R2803 have been changed from ERROR to WARNING. R2803's warning message is replaced as "namespace: {0} is a relative URI." In this situation the violating namespace will be treated as a part of the warning message. For example, the warning message will be "namespace: example.ibm.com/InventoryCalculationInterface is a relative URI" if the violating namespace is "example.ibm.com/InventoryCalculationInterface." WebSphere Service Registry and Repository V6.2.0.2 or later is needed to customize the returned message. These changes need to be made to the WSIBasicProfile11V2.xml file for them to be enforced later.


Listing 2. Updated rules on R2022 and R2803
<rule
context="pmfn:deref(/ctx:Context/ctx:DocumentList/ctx:Document[@role='role0'])
/wsdl:import">
<report id="R2022" test="not(( count( preceding-sibling::* ) = 0 ) or ( count
( preceding-sibling::* ) = count( preceding-sibling::*/self::wsdl:documentation )+count
( preceding-sibling::*/self::wsdl:import ) ))">
RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|WSI_BP_11_R2022|<value-of 
select="@namespace"/>|WARNING|^
</report>
<report id="R2803" test="not(strext:abs_uri(@namespace))">
RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|namespace: {0} is a relative URI|
<value-of select="@namespace"/>|WARNING|^
</report>
</rule>

Enabling the new WS-I configuration rule set

To meet the ORC's validator requirements, the original WS-I validation rules expressed in a rules file have now been changed and need to be loaded. To preserve the built-in WS-I validation rules, a new Document Content Policy entry should be created. From the Web UI:

  • Choose the Configuration perspective, then select Active Configuration Profile => Plug-ins => Document Content Policies from the left-hand navigation tree.
  • Click Load Document Content Policy:

Figure 3. Creation of a new entry for Document Content Policy
Figure 3

Select WSIBasicProfile11V2.xml (which you saved in the "STEP 2 -- WS-I Customization" section) as the new document content policy file to be uploaded, and provide the item name WSIBasicProfile11V2, as shown in Figure 4 below. Click OK.


Figure 4. Uploading of customized WS-I validation rule file
Figure 4

If successful, you will see the following view with a new entry named WSIBasicProfile11V2:


Figure 5. Updated Document Content Policy Listing View
Figure 5

To enable the newly uploaded WSIBasicProfile11V2 rule set, the governance policy for the WS-I validator must be updated: in the Configuration perspective, select Active Configuration Profile => Plug-ins => Governance Policies from the left-hand navigation tree. Click to open the governance policy file for the WS-I validator that was loaded in the "WS-I Validator configuration" section:


Figure 6. Governance policy view for document validator
Figure 6

In the content editor, make the modification as marked in bold in Listing 3, then click OK. The value of the rules name-value pair WSIBasicProfile11V2 must match the name of the Document Content Policy entry loaded above.


Listing 3 Updated governance policy for WS-I validator referencing the customized WS-I rules
<?xml version="1.0" encoding="UTF-8"?> 
<wsp:Policy ... > 
... 
      <wsrrgp:EntityAssertionPolicy wsrrgp:name="plugin_wsi_status_check"> 
        <wsp:Policy Name="plugin_wsi_status_policy_check"> 
          <wsrrgp:PluginAssertion wsrrgp:name="Invoking WS-I Compliance Validation" 
              wsrrgp:class="com.ibm.sr.policy.wsi.WSIComplianceValidator" 
              wsrrgp:options="rules=WSIBasicProfile11V2;report=true"> 
          </wsrrgp:PluginAssertion> 
        </wsp:Policy> 
      </wsrrgp:EntityAssertionPolicy> 
...  
</wsp:Policy>

Now the customized WS-I validator is ready for use.

Demonstrating the capabilities of the customized WS-I validator

The business scenario described in the "WS-I Customization" section will be used to verify the correctness of the customized WS-I validator configuration. Three WSDL documents from the downloadable zip file will be used:

OrderingService.wsdl

This file acts as the WSDL description of the ordering service used by ORC. In this WSDL document, an array type is used to describe an item list for the customer's order, as shown in Listing 4:


Listing 4 WSDL description for order service used by the Retail Company
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions... >
 <wsdl:types>
  <xsd:schema .../>
   <xsd:complexType name="ItemArray2Type">
    <xsd:complexContent>
     <xsd:restriction base="soapenc:Array">
      <xsd:sequence>
       <xsd:element maxOccurs="unbounded" minOccurs="0" name="x" type="xsd:integer"/>
      </xsd:sequence>
      <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="tns:ItemArray2Type[]"/>
     </xsd:restriction>
    </xsd:complexContent>
   </xsd:complexType>
    <xsd:element name="order">
     <xsd:complexType>
      <xsd:sequence>
       <xsd:element name="itemID" type="tns:ItemArray2Type"/>
      </xsd:sequence>
     </xsd:complexType>
    </xsd:element>
    ... 
  </wsdl:types>
   ... 
</wsdl:definitions>

InventoryCalculationInterface.wsdl

This file acts together with the service WSDL as the description of the inventory calculation service used by ORC. InventoryCalculationInterface.wsdl describes the interface of the service, and InventoryCalculationService.wsdl provides an HTTP binding and service port for the actual Web service endpoint. InventoryCalculationService.wsdl declares its wsdl:import element after the wsdl:service element, and it uses a relative namespace example.ibm.com/InventoryCalculationInterface, as shown in Listing 5:

InventoryCalculationService.wsdl


Listing 5. WSDL description for inventory calculation service used by ORC
<wsdl:definitions ... >
  <wsdl:binding ... >
    ... 
  </wsdl:binding>
  <wsdl:service ... >
    ... 
  </wsdl:service>
  <wsdl:import location="InventoryCalculationInterface.wsdl" 
      namespace="example.ibm.com/InventoryCalculationInterface"/>
</wsdl:definitions>

The WSDL documents should be loaded into WebSphere Service Registry and Repository before enabling the customized rule set, and the Governance Policy file should be set to trigger on the MAKE_GOVERNABLE action with the report option set to true. To invoke the WS-I validation:

  • Browse to Administrator or User perspective in the Web UI.
  • Select OrderingService.wsdl or InventoryCalculationService.wsdl from WSDL documents list, and click Governance.
  • Click Govern to govern the WSDL structure.
  • On the Details" page, click the document link under _WSIComplianceReport to open the generated WS-I validation report.
  • Click the Content tab to see the WS-I messages generated during the governance operation.

Figure 7 provides the WS-I validation messages for OrderingService.wsdl and shows that there are no WS-I validation errors reported for the original R2110/R2111 rules:


Figure 7 WS-I validation report for OrderingService.wsdl
Figure 7

Figure 8 provides the WS-I validation messages for InventoryCalculationService.wsdl and shows that there are two WS-I validation warnings (as opposed to errors) reported for the R2022 and R2803 assertions. The report message for R2803 is now a user customized one: example.ibm.com/InventoryCalculationInterface is a relative URI.


Figure 8 WS-I validation report for InventoryCalculationService.wsdl
Figure 8

Defining a new WS-I validation rule set

To demonstrate how to define a new WS-I validation rule set, use the context of WSDL versioning and generate a rule set to enforce this practice.

Background: Recommended practice for WSDL versioning

Versioning is a common problem in the design of distributed systems, and Web services are no exception. Generally speaking, major-minor versioning is used to accommodate two levels of change:

  1. Major change is a large update that creates an incompatibility with existing deployments. Major changes are typically large-scale revisions of the product, with significant new features and bug fixes.
  2. Minor change, a change to second and subsequent digits, is an update that is backwards compatible with existing deployments of the software that share the same major version. Minor revisions typically contain a number of small new features, bug fixes, and issue resolutions that do not break compatibility.

The major and minor release numbers are typically embedded in the software packing, using a format such as "<product> <major>.<minor>", such as WebSphere Application Server V6.0, V6.1, or V7.0. In the context of WSDL versioning, major-minor versioning can be used to distinguish between changes to a service contract that maintains backwards on-the-wire compatibility with existing service consumers, and those that break this compatibility and force a rewrite of service consuming code. There are many recommended practices for WSDL versioning:

  • Place the major version number in the WSDL target namespace.
  • Place the major-minor version in the portType, binding, and service name.
  • Add a new operation to a WSDL contract, using a major minor number.
  • Create a new service for each version of a portType and related binding.
  • Start the binding name with the specified portType name and end it with the binding type, such as SOAPBinding.

Listing 6 demonstrates the above examples in a WSDL document, MonolithicStockQuoteService_v1.wsdl, which you can download at the end of the article.


Listing 6. WSDL sample document for demonstration
<?xml version="1.0"?>
<wsdl:definitions name="MonolithicStockQuoteService_v1.wsdl"
  targetNamespace="http://tonawanda.sr.ibm.com/MonolithicStockQuoteService_v1" ...  >
... 
<wsdl:portType name="MonolithicStockQuotePortType_v1_0">
 <wsdl:operation name="GetLastTradePrice">
  <wsdl:input message="tns:GetLastTradePriceInput" />
  <wsdl:output message="tns:GetLastTradePriceOutput" />
 </wsdl:operation>
</wsdl:portType>
<wsdl:portType name="MonolithicStockQuotePortType_v1_1">
 <wsdl:operation name="GetLastTradePrice">
  <wsdl:input message="tns:GetLastTradePriceInput" />
  <wsdl:output message="tns:GetLastTradePriceOutput" />
 </wsdl:operation>
  <!-- Append new operation from version 1.1 -->
 <wsdl:operation name="PurchaseTrade">
  <wsdl:input message="tns:GetLastTradePriceInput" />
  <wsdl:output message="tns:GetLastTradePriceOutput" />
 </wsdl:operation>
</wsdl:portType>
<wsdl:binding name="MonolithicStockQuotePortType_v1_0_SOAPBinding"
 type="tns:MonolithicStockQuotePortType_v1_0">
 <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
 <wsdl:operation name="GetLastTradePrice">
  <soap:operation soapAction="http://tonawanda.sr.ibm.com/StockQuote/GetLastTradePrice"/>
  <wsdl:input>            
   <soap:body use="literal"/>
  </wsdl:input>
  <wsdl:output>
   <soap:body use="literal"/>
  </wsdl:output>
 </wsdl:operation>
</wsdl:binding>
<wsdl:binding name="MonolithicStockQuotePortType_v1_1_SOAPBinding"
 type="tns:MonolithicStockQuotePortType_v1_1">
 <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
 <wsdl:operation name="GetLastTradePrice">
  <soap:operation soapAction="http://tonawanda.sr.ibm.com/StockQuote/GetLastTradePrice"/>
  <wsdl:input>            
   <soap:body use="literal"/>
  </wsdl:input>
   <wsdl:output>
    <soap:body use="literal"/>
  </wsdl:output>
 </wsdl:operation>
</wsdl:binding>
<wsdl:service name="MonolithicPolicyStockQuoteService_v1_0">
 <wsdl:documentation>My first service</wsdl:documentation>
  <wsdl:port name="RMStockQuotePort" 
   binding="tns:MonolithicStockQuotePortType_v1_0_SOAPBinding">
    <soap:address location="http://tonawanda.sr.ibm.com/RMPolicyStockQuote"/>
  </wsdl:port>
 </wsdl:service>
<wsdl:service name="MonolithicPolicyStockQuoteService_v1_1">
 <wsdl:port name="X509StockQuotePort" 
  binding="tns:MonolithicStockQuotePortType_v1_1_SOAPBinding">
  <soap:address location="http://tonawanda.sr.ibm.com/X509PolicyStockQuote"/>
 </wsdl:port>
 </wsdl:service>
</wsdl:definitions>

Defining the rule set for recommended practice enforcement

The rule sets defining the required validation are written using a form of the Schematron language. As a language for rule-based validations, Schematron provides a comprehensive solution for validating XML instance documents. Schematron is an XML structure validation language for making assertions about the presence or absence of patterns in trees, and it relies on query languages (normally XPATH) to express its rules. Schematron provides solutions for cross-field, cardinality, and algorithmic constraints that are not supported by the current version of XML Schema. The language became an ISO Standard in 2006 (ISO/IEC 19757-3 - DSDL). Listing 7 expresses the first two constraints described above in a Schematron-based rule set for validation:


Listing 7. Rules for customized constraints from recommended practice
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://purl.oclc.org/dsdl/schematron"> 
	<title>WS-I Basic Profile 1.1 Assertion Rules</title> 
	<ns uri="http://schemas.xmlsoap.org/wsdl/" prefix="wsdl"/> 
	<pattern name="WSDL Versioning Rules"> 
	  <!--place the major version number in the WSDL target namespace -->
		<rule
			context="self::node()[@targetNamespace]">
			<report id="customize-01" test="not(number(substring-after
                        (@targetNamespace,'_v')))">
				RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|
				The major version number should be placed in the WSDL 
				target namespace (<value-of select="@targetNamespace"/>).
				|^|WARNING|^
			</report>
		</rule>
<!-- place the major-minor version in the portType, binding, and service name; -->
		<rule
			context="//wsdl:portType">
			<report id="customize-02" test="not(contains(substring-after
			(@name,'_v'),'_'))">
				RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|
				The major-minor version number should be placed in the 
                                portType name(<value-of select="@name"/>).|^|ERROR|^
			</report>
		</rule>
		<rule
			context="//wsdl:binding">
			<report id="customize-03" test="not(contains(substring-after
			(@name,'_v'),'_'))">
				RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|
				The major-minor version number should be placed in the 
				binding name(<value-of select="@name"/>).|^|ERROR|^
			</report>
		</rule>
		<rule
			context="//wsdl:service">
			<report id="customize-04" test="not(contains(substring-after
			(@name,'_v'),'_'))">
				RECORD_REPORT{http://com.ibm.cn/soa/standard/example}|
				The major-minor version number should be placed in the 
				service name(<value-of select="@name"/>).|^|ERROR|^
			</report>
		</rule>
	</pattern> 
</schema>

Enable the customized rule set from Listing 7

Open the WebUI and switch to the Configuration perspective. Browse to Active Configuration Profile => Plug-ins => Document Content Policies in the left-hand navigation tree. Load the rule set document BestPracticeSample.sch, which you can download below. Specify BestPracticeSample as the Document Content Policy configuration item name:


Figure 9. Upload customized Document Content Policy
Figure 9

Browse to Active Configuration Profile => Plug-ins => Governance Policies, then load the governance policy sample document Gov+Policy+Sample.xml, which you can download below. Specify Invoking Customized Best Practice Compliance Validation Check as the Content Policy configuration item name as shown in Figure 10. The applied rule is the BestPracticeSample (see wsrrgp:options="rules=BestPracticeSample;report=false">).


Figure 10. Customized governance policy
Figure 10

Switch to the Administrator perspective and load the sample WSDL document Invalid.wsdl, which you can download below. When you try to publish it into WebSphere Service Registry and Repository, you will get this error message:


Figure 11. Error message report
Figure 11

Switch to the Configuration perspective, browse to Active Configuration Profile => Plug-ins => Governance Policies, and open the Invoking Customized Best Practice Compliance Validation Check policy file. Then change the wsrrgp:options attribute as shown in Listing 8. The applied rule is still the BestPracticeSample and now report is set to true:


Listing 8. Modified new governance policy
<?xml version="1.0" encoding="UTF-8"?> 
<wsp:Policy wsu:Id="uuid:governanceProfileId" Name="GovernanceProfilePolicy" 
  xmlns:wsu=
  "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:wsrrgp="http://www.ibm.com.policy/GovernancePolicyDomain"> 
  <wsrrgp:ValidatorPolicy wsrrgp:name="plugin_bestpractice_validation_policy"> 
    <wsp:Policy> 
      <wsrrgp:ContentApplicabilityFilter wsrrgp:targetXPath="/WSRR/WSDLDocument"/> 
      <wsrrgp:WSRROperationFilter> 
        <wsrrgp:WSRROperation>CREATE</wsrrgp:WSRROperation>
		  <wsrrgp:WSRROperation>MAKE_GOVERNABLE</wsrrgp:WSRROperation>
        <wsrrgp:WSRROperation>TRANSITION</wsrrgp:WSRROperation> 
      </wsrrgp:WSRROperationFilter> 
      <wsrrgp:EntityAssertionPolicy wsrrgp:name="plugin_bestpractice_status_check"> 
        <wsp:Policy Name="plugin_bestpractice_status_policy_check"> 
          <wsrrgp:PluginAssertion wsrrgp:name="Customized Best Practice Compliance" 
              wsrrgp:class="com.ibm.sr.policy.wsi.WSIComplianceValidator" 
              wsrrgp:options="rules=BestPracticeSample;report=true"> 
          </wsrrgp:PluginAssertion> 
        </wsp:Policy> 
      </wsrrgp:EntityAssertionPolicy> 
    </wsp:Policy> 
  </wsrrgp:ValidatorPolicy>  
</wsp:Policy>

Switch to the Administrator perspective, load the sample WSDL document; Invalid2.wsdl, which you can download below. This WSDL document will be published successfully, but an error message will be generated and can be viewed by following the _WSICompliance relationship. The content of this report will be similar to the one in Figure 12:


Figure 12. New error message report
Figure 12

Conclusion

The supplied WS-I Basic Profile 1.1 validator in WebSphere Service Registry and Repository is a useful tool to ensure that content is compliant with the WS-I Basic Profile 1.1 specification. The validation framework lets you customize the default rules, their severity, and their messages. You can also use the framework to write your own validation rule sets to enforce recommended practice or naming conventions for WSDL content.



Download

DescriptionNameSizeDownload method
Code samplesamples.zip11 KBHTTP

Information about download methods


Resources

About the authors

Photo of in Peng Liu

Xin Peng Liu is a Staff Software Engineer at the SOA Design Center in the IBM China Software Development Lab. He concentrates on SOA policy and governance, and his interests include J2EE, SOA, MDA/MDD, AOP, and the semantic Web. He is currently doing design and development work related to an SOA policy toolkit.

Photo of Xi Ning Wang

Xi Ning Wang is a software engineer in China in the Service-oriented Architecture (SOA) Design Center. He is on the SOA Advanced Technologies team within the IBM Software Group, where he develops SOA technology development. Currently, he focuses on the areas of Web services, modeling- and policy-related technologies.

Photo of James Williams

James Williams is a Software Engineer on the WebSphere Service Registry and Repository functional verification team at at the IBM Hursley Software Lab in the UK. Previously he worked in the test group for WebSphere Voice Response.

Photo of Liang Xue

Liang Xue is a Staff Software Engineer at the SOA Design Center in the IBM China Software Development Lab. She concentrates on SOA governance related topics, including SOA policy and SOA metadata management. She received a Ph.D in 2006.

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


Rate this article

Comments

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and Web services
ArticleID=389458
ArticleTitle=Artifact content validation in WebSphere Service Registry and Repository
publish-date=05132009
author1-email=xinpengl@cn.ibm.com
author1-email-cc=clarkega@us.ibm.com
author2-email=wangxn@cn.ibm.com
author2-email-cc=clarkega@us.ibm.com
author3-email=JamesW@uk.ibm.com
author3-email-cc=
author4-email=xueliang@cn.ibm.com
author4-email-cc=