Nested Choice and Sequence Groups

The choice group element allows only one of its children to appear in an instance. One child is an inner group element that references the named group shipAndBill consisting of the element sequence shipTo, billTo, and the second child is a singleUSAddress. Hence, in an instance document, the purchaseOrder element must contain EITHER a shipTo element followed by a billTo element OR a singleUSAddress element. The choice group is followed by the comment and items element declarations, and both the choice group and the element declarations are children of a sequence group. The effect of these various groups is that the address element(s) must be followed by comment and items elements in that order.

<xsd:complexType name="PurchaseOrderType">`
 <xsd:sequence>
  <xsd:choice>
   <xsd:group   ref="shipAndBill"/>
   <xsd:element name="singleUSAddress" type="USAddress"/>
  </xsd:choice>
  <xsd:element ref="comment" minOccurs="0"/>
  <xsd:element name="items"  type="Items"/>
 </xsd:sequence>
 <xsd:attribute name="orderDate" type="xsd:date"/>
</xsd:complexType>

<xsd:group name="shipAndBill">
  <xsd:sequence>
    <xsd:element name="shipTo" type="USAddress"/>
    <xsd:element name="billTo" type="USAddress"/>
  </xsd:sequence>
</xsd:group>

Reference: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

xsd:all

<xsd:all>

• All the elements in the group may appear once or not at all, and they may appear in any order. 
• The all group is limited to the top-level of any content model. 
• The group's children must all be individual elements (no groups - sequence or all)

For example, to allow the child elements of purchaseOrder to appear in any order, we could redefine PurchaseOrderType as:

<xsd:complexType name="PurchaseOrderType">
  <xsd:all>
    <xsd:element name="shipTo" type="USAddress"/>
    <xsd:element name="billTo" type="USAddress"/>
    <xsd:element ref="comment" minOccurs="0"/>
    <xsd:element name="items"  type="Items"/>
  </xsd:all>
  <xsd:attribute name="orderDate" type="xsd:date"/>
</xsd:complexType>

Reference: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/

UDDI Publishing API

Authorization Operations

1. get_authToken - log in to the UDDI registry
• get_authToken (@userId, @cred) :authToken
2. discard_authToken - log out from the UDDI registry
• discard_authToken (authToken) :dispositionReport

Save Operations

1. save_business - add or update one or more businessEntity entries.
• save_business (authInfo, businessEntity+) :businessDetail
2. save_service - add or update one or more businessService entries.
• save_service (authInfo, businessService+) :serviceDetail
3. save_binding - add or update one or more bindingTemplate entries.
• save_binding (authInfo, bindingTemplate+) :bindingDetail
4. save_tModel - add or update one or more tModel entries.
• save_tModel (authInfo, tModel+) :tModelDetail
5. add_publisherAssertions - add one or more publisherAssertion entries.
• add_publisherAssertions (authInfo, publisherAssertion+) :dispositionReport
6. set_publisherAssertions - use to manage all of the tracked relationship assertions associated with an individual publisher account
• set_publisherAssertions (authoInfo, [publisherAssertion]) :publisherAssertions

Delete Operations

1. delete_business - remove one or more business registration
• delete_business (authInfo, businessKey+) :dispositionReport
2. delete_service - remove one or more previously businessService elements from the UDDI registry and from its containing businessEntity parent.
• delete_service (authInfo, serviceKey+) :dispositionReport
3. delete_binding - delete one or more bindingTemplate entries
• delete_binding (authInfo, bindingKey+) :dispositionReport
4. delete_tModel - logically delete one or more tModel structures. Logical deletion hides the deleted tModels from find_tModel result sets but does not physically delete it.
• delete_tModel (authInfo, tModelKey) :dispositionReport
5. delete_publisherAssertions - remove one or more publisherAssertion elements a publisher’s assertion collection.
• delete_publisherAssertions (authInfo, publisherAssertion+) :dispositionReport

Get Operations

1. get_assertionStatusReport - provides administrative support for determining the status of current and outstanding publisherAssertions that involve any of the businessEntity registrations managed by the individual publisher account.
• get_assertionStatusReport (authInfo, completionStatus) :assertionStatusReport
2. get_publisherAssertions - obtain the full set of publisher assertions that is associated with an individual publisher account.
• get_publisherAssertions (authInfo) :publisherAssertions
3. get_registeredInfo - get an abbreviated list of all businessEntity and tModel data that are controlled by the individual associated with the credentials passed.
• get_registeredInfo (authInfo) :registeredInfo

UDDI Inquiry API

Find Operations

1. find_business - Finds matching businessEntity entries.
• find_business([findQualifiers],[name*],[discoveryURLs],[identifierBag],[categoryBag],[tModelBag])
     :businessList{businessInfos}
2. find_service - Finds matching businessService entries.
• find_service([@businessKey],[findQualifiers],[name*],[categoryBag],[tModelBag])
     :serviceList{serviceInfos}
3. find_binding - Finds matching bindingTemplate entries.
• find_binding([findQualifiers], tModelBag) :
     :bindingDetail{bindingTemplate+}
4. find_tModel - Finds matching tModel entries.
• find_tModel([findQualifiers],[name],[identifierBag],[categoryBag])
     :tModelList{tModelInfos}
5. find_relatedBusinesses - Finds matching publisherAssertion entries.
• find_relatedBusiness([findQualifiers],businessKey,[keyedReference])
     :relatedBusinessList {businessKey,relatedBusinessInfos}

Get Operations

1. get_businessDetail - 
• get_businessDetail (businessKey+) : businessEntity
2. get_businessDetailExt - 
• get_businessDetailExt (businessKey+) : businessEntity
3. get_serviceDetail - 
• get_serviceDetail (serviceKey+) : businessService
4. get_bindingDetail - 
• get_bindingDetail (bindingKey+) : bindingTemplate
5. get_tModelDetail - 
• get_tModelDetail (tModelKey+) : tModel

Changes Between SOAP 1.1 and SOAP 1.2

Reference: http://www.w3.org/TR/soap12-part0/#L4697

SOAP Version 1.2 has a number of changes in syntax and provides additional (or clarified) semantics from those described in [SOAP 1.1]. The following is a list of features where the two specifications differ. The purpose of this list is to provide the reader with a quick and easily accessible summary of the differences between the two specifications. The features have been put in categories purely for ease of reference, and in some cases, an item might equally well have been placed in another category.

Document structure

• The SOAP 1.2 specifications have been provided in two parts. [SOAP Part1] provides an abstract Infoset-based definition of the SOAP message structure, a processing model and an underlying protocol binding framework, while [SOAP Part2] provides serialization rules for conveying that infoset as well as a particular HTTP binding.
• SOAP 1.2 will not spell out the acronym.
• SOAP 1.2 has been rewritten in terms of XML infosets, and not as serializations of the form <?xml....?> required by SOAP 1.1.

Additional or changed syntax

• SOAP 1.2 does not permit any element after the body. The SOAP 1.1 schema definition allowed for such a possibility, but the textual description is silent about it.
• SOAP 1.2 does not allow the env:encodingStyle attribute to appear on the SOAP env:Envelope, whereas SOAP 1.1 allows it to appear on any element. SOAP 1.2 specifies specific elements where this attribute may be used.
• SOAP 1.2 defines the new env:NotUnderstood header element for conveying information on a mandatory header block which could not be processed, as indicated by the presence of an env:MustUnderstand fault code. SOAP 1.1 provided the fault code, but no details on its use.
• In the SOAP 1.2 infoset-based description, the env:mustUnderstand attribute in header elements takes the (logical) value "true" or "false", whereas in SOAP 1.1 they are the literal value "1" or "0" respectively.
• SOAP 1.2 provides a new fault code DataEncodingUnknown.
• The various namespaces defined by the two protocols are of course different.
• SOAP 1.2 replaces the attribute env:actor with env:role but with essentially the same semantics.
• SOAP 1.2 defines a new attribute, env:relay, for header blocks to indicate if unprocessed header blocks should be forwarded.
• SOAP 1.2 defines two new roles, "none" and "ultimateReceiver", together with a more detailed processing model on how these behave.
• SOAP 1.2 has removed the "dot" notation for fault codes, which are now simply an XML Qualified Name, where the namespace prefix is the SOAP envelope namespace.
• SOAP 1.2 replaces "client" and "server" fault codes with "Sender" and "Receiver".
• SOAP 1.2 uses the element names env:Code and env:Reason, respectively, for what used to be calledfaultcode and faultstring in SOAP 1.1. SOAP 1.2 also allows multiple env:Text child elements ofenv:Reason qualified by xml:lang to allow multiple language versions of the fault reason.
• SOAP 1.2 provides a hierarchical structure for the mandatory SOAP env:Code sub-element in the env:Faultelement, and introduces two new optional subelements, env:Node and env:Role.
• SOAP 1.2 removes the distinction that was present in SOAP 1.1 between header and body faults as indicated by the presence of the env:Details element in env:Fault. In SOAP 1.2, the presence of the env:Detailselement has no significance as to which part of the fault SOAP message was processed.
• SOAP 1.2 uses XML Base [XML Base] for determining a base URI for relative URI references whereas SOAP 1.1 is silent about the matter.

SOAP HTTP binding

• In the SOAP 1.2 HTTP binding, the SOAPAction HTTP header defined in SOAP 1.1 has been removed, and a new HTTP status code 427 has been sought from IANA for indicating (at the discretion of the HTTP origin server) that its presence is required by the server application. The contents of the former SOAPAction HTTP header are now expressed as a value of an (optional) "action" parameter of the "application/soap+xml" media type that is signaled in the HTTP binding.
• In the SOAP 1.2 HTTP binding, the Content-type header should be "application/soap+xml" instead of "text/xml" as in SOAP 1.1. The IETF registration for this new media type is [RFC 3902].
• SOAP 1.2 provides a finer grained description of use of the various 2xx, 3xx, 4xx HTTP status codes.
• Support of the HTTP extensions framework has been removed from SOAP 1.2.
• SOAP 1.2 provides an additional message exchange pattern which may be used as a part of the HTTP binding that allows the use of HTTP GET for safe and idempotent information retrievals.

RPC

• SOAP 1.2 provides a rpc:result element accessor for RPCs.
• SOAP 1.2 provides several additional fault codes in the RPC namespace.
• SOAP 1.2 offers guidance on a Web-friendly approach to defining RPCs where the procedure's purpose is purely "safe" informational retrieval.

SOAP encodings

• An abstract data model based on a directed edge labeled graph has been formulated for SOAP 1.2. The SOAP 1.2 encodings are dependent on this data model. The SOAP RPC conventions are dependent on this data model, but have no dependencies on the SOAP encoding. Support of the SOAP 1.2 encodings and SOAP 1.2 RPC conventions are optional.
• The syntax for the serialization of an array has been changed in SOAP 1.2 from that in SOAP 1.1.
• The support provided in SOAP 1.1 for partially transmitted and sparse arrays is not available in SOAP 1.2.
• SOAP 1.2 allows the inline (embedded) serialization of multiref values.
• The href attribute in SOAP 1.1 (of type xs:anyURI) is called enc:ref in SOAP 1.2 and is of type IDREF.
• In SOAP 1.2, omitted accessors of compound types are made equal to NILs.
• SOAP 1.2 provides several fault sub-codes for indicating encoding errors.
• Types on nodes are made optional in SOAP 1.2.
• SOAP 1.2 has removed generic compound values from the SOAP Data Model.
• SOAP 1.2 has added an optional attribute enc:nodeType to elements encoded using SOAP encoding that identifies its structure (i.e., a simple value, a struct or an array).

Developing Bottom-Up JAX-WS (Client)

Create a new Java project and copy the Service Endpoint Interface (SEI) Java class file from the server implementation.
Then create the following Client implementation:

package com.jadobo.ws;

import java.net.URL;

import javax.xml.namespace.QName;
import javax.xml.ws.Service;

public class TestMain {

    private static final QName SERVICE_NAME 
        = new QName("http://ws.jadobo.com/", "HelloWorldService");

    public static void main(String args[]) throws Exception {
     
     URL wsdl = new URL("http://localhost:9000/helloWorld?wsdl");
        Service service = Service.create(wsdl, SERVICE_NAME);
        
        HelloWorld hw = service.getPort(HelloWorld.class);
        System.out.println(hw.sayHi("World"));
    }
}

Sample console output after Client execution:

INFO: Dynamically creating request wrapper Class com.jadobo.ws.jaxws.SayHi
INFO: Dynamically creating response wrapper bean Class com.jadobo.ws.jaxws.SayHiResponse
Hello: World

Developing Bottom-Up JAX-WS

General steps in creating bottom-up JAX-WS server, using CXF and Maven, in Java:

1. Create java (maven) project
   - if you are not using Maven, then you have to manually configure to include the required JAR dependencies.
   - see Maven POM file below about required CXF libraries.
2. Define Service Endpoint Interface (SEI)
3. Define SEI Implementation (service layer)
4. Create web service implementation (interaction layer)
5. Deploy/execute

You should be able to see the generated WSDL file after deployment by enter the following URL in your browser:
http://localhost:9000/helloWorld?wsdl

The Service End Point Interface (SEI)

package com.jadobo.ws;

import javax.jws.WebParam;
import javax.jws.WebService;


@WebService
public interface HelloWorld {

    String sayHi(@WebParam(name="text")String text);
    
}

The Service End Point Implementation

package com.jadobo.ws;

import javax.jws.WebService;
@WebService(endpointInterface = "com.jadobo.ws.HelloWorld",
            serviceName = "HelloWorldService",
            portName="HelloWorldPort")
public class HelloWorldImpl implements HelloWorld {

    @Resource private WebServiceContext wsCtxt;

    public String sayHi(String text) {

        System.out.println("sayHi called");
        return "Hello: " + text;
    }
    
}

The Server Implementation

package com.jadobo.ws;

import javax.xml.ws.Endpoint;

public class Server {

    protected Server() throws Exception {
        // START SNIPPET: publish
        System.out.println("Starting Server");
        HelloWorldImpl implementor = new HelloWorldImpl();
        String address = "http://localhost:9000/helloWorld";
        Endpoint.publish(address, implementor);
        // END SNIPPET: publish
    }

    public static void main(String args[]) throws Exception {
        new Server();
        System.out.println("Server ready...");

        Thread.sleep(5 * 60 * 1000);
        System.out.println("Server exiting");
        System.exit(0);
    }
}

The Project's Maven POM

<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.jadobo.ws</groupId>
   <artifactId>bottomup</artifactId>
   <version>0.0.1-SNAPSHOT</version>
  
    <repositories>
        <repository>
            <id>default</id>
            <name>Maven Repository</name>
            <layout>default</layout>
            <url>http://repo1.maven.org/maven2</url>
        </repository>
    </repositories>

    <dependencies>
    
        <!-- CXF Web Service -->
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-core</artifactId>
            <version>2.4.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-api</artifactId>
            <version>2.4.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-frontend-jaxws</artifactId>
            <version>2.4.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-bundle</artifactId>
            <version>2.4.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-common-schemas</artifactId>
            <version>2.3.5</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http-jetty</artifactId>
            <version>2.4.1</version>
        </dependency>
    
    </dependencies>
  
</project>

Message Encryption/Decryption Mechanism

1. Web service invocation 
2. Retrieve client's X.509 certificate and private key 
3. Digitally sign message (e.g SOAP body) using private key 
4. Include client application's X.509 certificate in SOAP header as binary security token. 
5. Encrypt message with symmetrical algorithm using a shared key. 
6. Retrieve public key of the service provider's X.509 certificate 
7. Encrypt shared key with asymmetric algorithm using service provider's public key. 
8. Include encrypted shared key in SOAP header 
9. Include reference to Service Provider's certificate in SOAP header.

1. SP SOAP runtime recieves request
2. Identify Service Provider's X.509 certification from reference in SOAP header
3. Retrieve Service Provider's X.509 certificate and keys
4. Decrypt shared key with asymmetric algorithms using private key of certificate
5. Decrypt message with sysmmetric algorithm using shared key
6. Retrieve sender's X.509 public key from binary security token in SOAP header
7. Validate digital signature of message that also authenticate sender
8. Call web service implmentation
9. Process request

Canonical XML

The canonical form of an XML document is physical representation of the document produced by the method described in this specification. The changes are summarized in the following list:

• The document is encoded in UTF-8
• Line breaks normalized to #xA on input, before parsing
• Attribute values are normalized, as if by a validating processor
• Character and parsed entity references are replaced
• CDATA sections are replaced with their character content
• The XML declaration and document type declaration (DTD) are removed
• Empty elements are converted to start-end tag pairs
• Whitespace outside of the document element and within start and end tags is normalized
• All whitespace in character content is retained (excluding characters removed during line feed normalization)
• Attribute value delimiters are set to quotation marks (double quotes)
• Special characters in attribute values and character content are replaced by character references
• Superfluous namespace declarations are removed from each element
• Default attributes are added to each element
• Lexicographic order is imposed on the namespace declarations and attributes of each element

The term canonical XML refers to XML that is in canonical form. The XML canonicalization method is the algorithm defined by this specification that generates the canonical form of a given XML document or document subset. The term XML canonicalization refers to the process of applying the XML canonicalization method to an XML document or document subset.

source: http://www.w3.org/TR/2001/REC-xml-c14n-20010315

Digital Signature Overview

RFC 2828 defines a digital signature as "a value computed with a cryptographic algorithm and appended to a data object in such a way that any recipient of the data can use the signature to verify the data's origin and integrity."

Within the XML document, if a signature is the parent element, then it is an enveloping signature. If it is the child element, it is an enveloped signature. If it is neither of both, then it is called detached signature.

We will use the following XML document as subject for XML digital signing:

<?xml version="1.0" ?>
<account>
 <number>9876543210</number>
 <type>savings</type>
 <branch>main</branch>
 <name>First M Last</name>
</account>

The resulting signed XML document, which the signature is enveloped, is as follow.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<account>
 <number>9876543210</number>
 <type>savings</type>
 <branch>main</branch>
 <name>First M Last</name>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
 <SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>pc92d1PtOWfWuYcv8KKzI1VomhM=</DigestValue></Reference></SignedInfo>
 <SignatureValue>gQLJpLXZYyay4z3P5so0291bU8hhjlTaKpzOKfKrS87VtuuXwTnATg==</SignatureValue>
 <KeyInfo>
  <KeyValue>
   <DSAKeyValue>
    <P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9jQTxeEu0ImbzRMqzVDZkVG9
     xD7nN1kuFw==</P>
    <Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
    <G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5Bpsy4pNWMOHCBiNU0Nogps
     QW5QvnlMpA==</G>
    <Y>x68Jz5Eb/pO6MuNDwhWmSWrgyNN5mvIAYOrvIqf4JzgCll0HvIOXK8Tf1SxrqiYHqPawsqXE0S53
     5LW709Dzcw==</Y>
   </DSAKeyValue>
  </KeyValue>
 </KeyInfo>
</Signature></account>

Java code for signing XML document
Step1: instantiate the document to be signed

  DocumentBuilderFactory dbf = 
   DocumentBuilderFactory.newInstance();
  dbf.setNamespaceAware(true);
  DocumentBuilder builder = dbf.newDocumentBuilder();
  Document doc = builder.parse(inputStream);

Step2: generate public-private key pair

  KeyPairGenerator kpg = KeyPairGenerator.getInstance("DSA");
  kpg.initialize(512);
  KeyPair kp = kpg.generateKeyPair();

Step3: create signing context

  DOMSignContext dsc = new DOMSignContext(kp.getPrivate(),
    doc.getDocumentElement());

Step4: assemble XML signature

  XMLSignatureFactory fac = 
   XMLSignatureFactory.getInstance("DOM");
  // Step4a: create reference
  Reference ref = fac.newReference("", fac.newDigestMethod(
    DigestMethod.SHA1, null), 
    Collections.singletonList(
     fac.newTransform(Transform.ENVELOPED,
     (TransformParameterSpec) null)), null, null);
  // Step4b: create signed info
  SignedInfo si = fac
   .newSignedInfo(fac.newCanonicalizationMethod(
    CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS,
     (C14NMethodParameterSpec) null), fac
     .newSignatureMethod(SignatureMethod.DSA_SHA1, null),
     Collections.singletonList(ref));
  // Step4c: create optional KeyInfo
  // - contains information that enables the recipient
  // to find the key needed to validate the signature
  KeyInfoFactory kif = fac.getKeyInfoFactory();
  KeyValue kv = kif.newKeyValue(kp.getPublic());
  KeyInfo ki = kif.newKeyInfo(Collections.singletonList(kv));
  // Step4d: create XML signature
  XMLSignature signature = fac.newXMLSignature(si, ki);

Step5: generate XML signature

  signature.sign(dsc); // DOM structure will be updated.

Step6: print signed document

  TransformerFactory tf = TransformerFactory.newInstance();
  Transformer trans = tf.newTransformer();
  trans.transform(new DOMSource(doc), new StreamResult(outputStream));

Validating signed document
Step1: instantiate document that contains signature

  DocumentBuilderFactory dbf = 
   DocumentBuilderFactory.newInstance();
  dbf.setNamespaceAware(true);
  DocumentBuilder builder = dbf.newDocumentBuilder();
  Document doc = builder.parse(inputStream);

Step2: Specify the document to be validated

  NodeList nl = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature");
  if (nl.getLength() == 0) {
   throw new IllegalArgumentException
    ("Signature element not found");
  }

Step3: create validation context

  DOMValidateContext valContext = new DOMValidateContext(
    new KeyValueKeySelector(), nl.item(0));

Step4: Unmarshal XML signature

  XMLSignatureFactory factory = 
   XMLSignatureFactory.getInstance("DOM");
  XMLSignature signature = 
   factory.unmarshalXMLSignature(valContext);

Step5: Validate

  return signature.validate(valContext);

Index: KeySelector class definition

 private static class KeyValueKeySelector 
  extends KeySelector {
  public KeySelectorResult select(KeyInfo keyInfo,
    KeySelector.Purpose purpose, 
    AlgorithmMethod method,
    XMLCryptoContext context) 
  throws KeySelectorException {
   if (keyInfo == null) {
    throw new KeySelectorException("Null KeyInfo object!");
   }
   SignatureMethod sm = (SignatureMethod) method;
   List list = keyInfo.getContent();

   for (int i = 0; i < list.size(); i++) {
    XMLStructure xmlStructure = (XMLStructure) list.get(i);
    if (xmlStructure instanceof KeyValue) {
     PublicKey pk = null;
     try {
      pk = ((KeyValue) xmlStructure).getPublicKey();
     } catch (KeyException ke) {
      throw new KeySelectorException(ke);
     }

     // make sure algorithm is compatible with method
     if (algEquals(sm.getAlgorithm(), pk.getAlgorithm())) {
      return new SimpleKeySelectorResult(pk);
     }
    }
   }
   throw 
    new KeySelectorException("No KeyValue element found!");
  }

  // this should also work for key types other than DSA/RSA
  static boolean algEquals(String algURI, String algName) {
   if (algName.equalsIgnoreCase("DSA")
     && algURI.equalsIgnoreCase(SignatureMethod.DSA_SHA1)) {
    return true;
   } else if (algName.equalsIgnoreCase("RSA")
     && algURI.equalsIgnoreCase(SignatureMethod.RSA_SHA1)) {
    return true;
   } else {
    return false;
   }
  }
 }

 private static class SimpleKeySelectorResult 
      implements KeySelectorResult {
  private PublicKey pk;

  SimpleKeySelectorResult(PublicKey pk) {
   this.pk = pk;
  }

  public Key getKey() {
   return pk;
  }
 }

References:

• http://docs.oracle.com/javase/6/docs/technotes/guides/security/xmldsig/XMLDigitalSignature.html
• http://www.xinotes.org/notes/note/753/
• http://docs.oracle.com/javase/6/docs/technotes/guides/security/xmldsig/XMLDigitalSignature.html