1. Developing SOA Applications with Oracle SOA Suite
  2. Advanced Topics
  3. Managing Large Documents and Large Numbers of Instances
  4. Best Practices for Handling Large Documents
  5. Use Cases for Handling Large Documents
  6. Sending and Receiving MTOM-Optimized Messages to SOA Composite Applications
  7. Scenarios for Storing SwA and MTOM-Optimized Attachments to the Database

Scenarios for Storing SwA and MTOM-Optimized Attachments to the Database

When a SOA composite application with a BPEL process receives an MTOM-optimized SOAP message, the attachment contents of each of the MTOM-optimized elements (the ones with an <xop href="">) are stored in the dehydration store. Similarly, when receiving a SOAP message with attachments (SwA) message with one or more attachments, each attachment is stored in the dehydration store. These attachments can then be passed around by reference using an href attribute that identifies them in the database. In fact, all of the text content of these attachment elements is removed and replaced by this href attribute. For MTOM-optimized messages, the same value of the incoming href attribute from the <xop> element is reused. Similarly, for SwA, the href attributes of the attachment elements are reused.

The attachments are stored in the dehydration store when the message is delivered to the BPEL process service engine. (when the incoming message is saved into the DLV_MESSAGE table). Therefore, it is applicable only for one-way and asynchronous BPEL processes with bpel.config.oneWayDeliveryPolicy set to async.persist (the default value) in the composite.xml file.

Attachments are not persisted in the following use cases:

  • If the SOAP message was received by a synchronous BPEL process or a one-way/asynchronous BPEL process with bpel.config.oneWayDeliveryPolicy set to sync or async.cache.

  • Contents of all elements within the SOAP request with inline binary content are not persisted, but passed as-is. (That is, they do not have a child element <xop:Include>, but do have a base64 encoded string as a child.) An MTOM-optimized message can be a mix of one or more elements that have inline base64 data, and one or more elements that are XOP-packaged, at any level.

Note:

Even if the service binding component is MTOM-enabled, it does not automatically indicate that the service receives MTOM-optimized messages. The calling service/application must send MTOM-optimized messages over the wire to ensure the message is received. MTOM-enabled bindings can also receive ordinary non-MTOM messages. Therefore, when it receives one, the SOAP requests arriving into the service can have nonoptimized inline binary data elements that are not be persisted into the database.

Even though the content of the MTOM-optimized elements or SwA attachments have their value replaced by an href attribute at runtime, their design-time WSDLs still remain unaltered. You do not see these changes in Oracle JDeveloper. Their element type definitions do not change from hexBinary, base64Binary, and so on to that of an empty content with an href attribute.

However, this is transparent to you. For instance, when you use an assign activity to copy across their content, the href values are copied over at runtime. Similarly, when invoking an outbound reference such as a web service or an adapter, Oracle SOA Suite automatically resolves the href attribute to the actual data and executes the invocation.