WebSphere WebSphere Application Server Network Deployment, Version 6.0.x Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Mapping of SDO data graphs for Web services messages

This topic describes the layouts for the different parts of Web services messages

Overall Web service message layout

The Info node is the top of the graph for all Web services messages. It has these properties and associated types:

Property name Property type Property description
operationName java.lang.String Identifies the WSDL operation the message is associated with. If the data access service cannot identify the message this field may be null. See Identifying Web services messages
messageName java.lang.String Identifies the WSDL message this message is associated with. If the data access service cannot identify the message this field may be null. See Identifying Web services messages
messageType java.lang.String Identifies WebService type of message instance. The field can have the values input, output, fault, ambiguous. If the data access service cannot identify the message this field may be null. See Identifying Web services messages
headers java.util.List of data objects. Contains a list of header entry data objects. Each SOAP header in the message results in a header entry in this list. See Message header layout
attachments java.util.List of data objects. Contains a list of attachment entry data objects. In SOAP messages with attachments, each MIME part in the message (except the MIME part containing the SOAP envelope) is mapped to an entry in this list. See Message attachment layout
body commonj.sdo.DataObject A nested data object, which represents the body of the SOAP Envelope. See Message body layout

In addition to the format string, the message is described by the three metadata fields, operationName, messageName, and messageType. The payload of the message is split across the three other sections: headers, attachments and the body. These follow a section on the identification of messages.

Identifying Web services messages

Processing of messages depend on whether or not they have WSDL definitions. The minimum amount of information required for processing without WSDL is "SOAP:" The minimum amount of information required for processing with WSDL is: "SOAP:location,namespace,service,port". If the format string does not include all five of these fields, the SOAP data access service will attempt to process the message without WSDL.

  • Processing messages without WSDL definitions: If the format string does not include full WSDL information, the SOAP data access service processes the message without attempting to match the message against definitions in WSDL. As a result, operationName and messageName are set to null, and the messageType field is only set when processing a fault message.
  • Processing messages with WSDL definitions: If the format string includes <WSDL location>,<Service namespace>,<Service name>, and <Port name> then the SOAP and Beans data access services process the message using the WSDL definitions of the service.
    Note: SOAP message processing will fail after supplying all the required WSDL information,
    • if the SOAP data access service fails to locate the WSDL
    • if the WSDL fails to corroborate the message.

When the SOAP data access service processes a SOAP request or reply message, it tries to match it against the message definitions in the WSDL. Normally there is unique match, and the operationName, messageName, and messageType are filled in appropriately. If there is more than one possible match the data access service picks a message definition, and fills in the operationName and messageName. In this case the messageType is set to ambiguous.

When processing fault messages, identification is slightly different. In all cases the messageType will be set to fault. If the message matches a unique fault definition in the WSDL then the operationName and messageName properties will also be set.

Message header layout

The list of headers can have two types of entry, depending on whether the header is based on part of the message or not.

The first type is used to handle headers that are not parts of the message:
  • either not modeled in WSDL,
  • or modeled in WSDL but not based on a part of the message.
For a model of this header, see Header entry

The second type of entry is used when the SOAP binding for the message has bound a part of the body into a MIME attachment. (This occurs when you use a <MIME:content> element to bind a part of the message to an attachment.) For consistent mediation programming, all of the body data is stored in the body node in the graph. In place of the normal attachment entry a bound attachment entry is placed into the attachments list. The bound attachment entry contains the MIME meta-data for the attachment, and for completeness also contains the name of the message part that contains the data taken from this attachment. This allows mediations designed to process attachments to locate the data in the body part of the graph. For a model of this attachment see Bound header entry.

Header entry

Property name Property type Property description
mustUnderstand java.lang.Boolean Carries the value from the mustUnderstand attribute on the SOAP header, if present.
actor java.lang.String Carries the value from the actor attribute on the SOAP header, if present.
any commonj.sdo.Sequence Container for the contents of the SOAP Header.

Bound header entry

Property name Property type Property description
mustUnderstand java.lang.Boolean Carries the value from the mustUnderstand attribute on the SOAP header, if present.
actor java.lang.String Carries the value from the actor attribute on the SOAP header, if present.
messagePart java.lang.String Contains the name of the message part which carries the data from this message header.

Message attachment layout

Message attachments are handled in a similar way to headers, and instances of them populate the attachments list in the Info node.

There are two types of attachment entry to handle MIME attachments. The first is for general attachments: see Attachment entry

The second type of attachment entry includes <MIME:content> elements that bind a part of the body into a MIME attachment. If you are programming a mediation, you need to know how to locate the data within the graph. For consistent mediation programming, the attachment data is placed in the message body, referred to by the part name in the header entry, which includes the other MIME metadata. For a model of this attachment, see Bound attachment entry.

Attachment entry

Property name Property type Property description
contentType java.lang.String Carries the contentType from the MIME part that is represented by the attachment entry.
contentTransferEncoding java.lang.String Carries the contentTransferEncoding from the MIME part that is represented by the attachment entry.
contentId java.lang.String Carries the contentId from the MIME part that is represented by the attachment entry.
data byte[] Carries the content of the MIME element, as a byte array.

Bound attachment entry

Property name Property type Property description
contentType java.lang.String Carries the contentType from the MIME part that is represented by the attachment entry.
contentTransferEncoding java.lang.String Carries the contentTransferEncoding from the MIME part that is represented by the attachment entry.
contentId java.lang.String Carries the contentId from the MIME part that is represented by the attachment entry.
messagePart java.lang.String Contains the name of the message part which carries the data from this attachment.

Message body layout

The layout of the data object in the body is defined by the service's WSDL. The type of the data object is derived from the message definition in the WSDL. The data object will have one property for each part in the message definition. The layout of each message part follows the convention for mapping XML Schema into SDO, see Web Services code example for more information.

Web services fault message

If the message is a fault message, the messageType field (in the Info node of the graph) will be set to "fault", and the message body will have the following properties:

Property name Property type Property description
faultcode javax.xml.namespace.QName Carries the faultcode value from the SOAP Fault element
faultstring java.lang.String Carries the faultstring value from the SOAP Fault element
faultactor java.lang.String Carries the faultactor value from the SOAP Fault element
detail commonj.sdo.DataObject Carries the content within the detail child of the SOAP Fault Element
Note: As the detail element definition uses element and attribute wildcards, the content of the detail data object will contain a Sequence. See Web Services code example for more information.
Related tasks
Including SOAP header schemas in the SDO repository

Reference topic

Terms of Use | Feedback

Last updated: 15 Mar 2007
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc\ref\rjy1111.html

© Copyright IBM Corporation 2004, 2007. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)