Application Data Feature

Overview

Implements application data feature behavior within context of a SOAP binding and generates type specific message module instances as an artifact of message processing. Contains 'application data' transmitted 'out-of-band', i.e. outside of the normal data channel, e.g. soap:Body. For example, to access 'application data received by a runtime engine requires the following code. Please see the policy reference page for additional requirements regarding policy configuration and 'application data.'

...
  public void spi_receiveAction(EndpointReference epr, ActionContext requestContext) {
  
      // retrieve the type specific message module instance
      ApplicationDataModule adm = requestContext.getMessageModule(ApplicationDataModule.class);
      
      // retrieve a set which contains only elements of type {http://foo}bar
      Set<ApplicationData> ads = adm.getApplicationData().get(new QName("http://foo", "bar"));
      
      // we're only expecting a single instance. note that ApplicationData extends Element
      Element myApplicationData = ads.iterator().next();
        
  }
...

For example to send 'application data' to a partner application which is transmitted 'out-of-band' would require the following code. 

...

    // assuming we have retrieved a partner specific EndpointReference instance,
    // create a request action instance
    EndpointActionReference ear = epr.getEndpointActionReference(PARTNER_REQUEST_ACTION);
    ActionContext partnerRequest = ((RequestActionReference)ear).createAction();
    
    // retrieve the runtime message instance (which extends the Document interface) and
    // use it as a factory to create the 'application data'
    Message partnerRequestMessage = partnerRequest.getMessage();
    ApplicationData ad = partnerRequestMessage.createApplicationData("http://foo", "foo:bar");
    ad.appendChild(partnerRequestMessage.createTextNode("data"));
    ad.setMustUnderstand(true);
    
    // retrieve the application data module which is required by the spec to exist on
    // every action instance and add the newly created data to it
    partnerRequest.getMessageModule(ApplicationDataModule.class).addApplicationData(ad);
    
    // create a hypothetical payload and add to message
    Content payload = partnerRequestMessage.createContent(PARTNER_TNS, "request");
    payload.appendChild(partnerRequestMessage.createTextNode("red"));
    partnerRequestMessage.setContent(payload);
    
    // now we send the action to the modeled partner
    epr.sendAction(partnerRequest);
    
...

Defining this Feature as a Dependency

This feature is typically defined as a dependency by binding extensions only, i.e. you wouldn't define it as a dependency within your component deployments. If you're developing a binding that uses the application data feature, paste the following element into the dependencies section of your deployment's POM, making sure to populate the version tag with the desired version (check repository for the latest available version). Note that if the feature is optional, i.e. if it's not absolutely required by your extension, set optional to 'true'.

<dependency>
  <groupId>org.bluestemsoftware.open.eoa.ext.feature.ws.ad.soap</groupId>
  <artifactId>ws-appdata-soap</artifactId>
  <version>VERSION</version>
  <scope>runtime</scope>
  <type>eoa-feature</type>
  <optional>false</optional>
</dependency>

Enabling this Feature Provider

If no provider is specified when feature is enabled and more than one implementation exists, an arbitrary implementation is selected by the alakai server. Enabling this specific provider requires the following entry within your server.xml file:

<feature type="org.bluestemsoftware.specification.eoa.ext.feature.ws.appdata.soap.ApplicationDataFeature">
  <provider impl="org.bluestemsoftware.open.eoa.ext.feature.ws.ad.soap.WSADFeatureImpl"/>
</feature>

Features Required by this Provider

The following features must be explicitly enabled to use this provider:

  None

Optional Features Used by this Provider

This feature will employ the following optional features if they are enabled:

  None

Configuration Schema

The monolithic portion of this feature is not configurable. Its modules, however, are enabled/constrained via policy.