The ebMS specification only defines an abstract P-Mode model, the actual P-Mode definition is left up to implementations. This schema defines the XML structure for the representation of a P-Mode as used by the default implementation for maintaining the P-Mode set. In this implementation the P-Mode set consists of all XML documents in a directory. Each XML document represents one P-Mode and must conform to this schema. See the package org.holodeckb2b.pmode.xml for more info on the default implementation of P-Modes.

In version 2.1.0 of the schema the EventHandler and AddActorOrRoleAttribute elements were added. As these are optional elements P-Mode documents constructed using the old version are still valid and result in unchanged processing. Therefore the same namespace is used and only the version has been increased

In version 4.0.0 of the schema the optional PMode/useStrictHeaderValidation attribute was added. It can be use to enable strict validation of the ebMS header

In version 4.0.0 of the schema the structure of the ReceptionAwareness element was changed to enable more flexible configuration of retries. For back-ward compatibility the old fixed intervals can also be used although there use is NOT RECOMMENDED.

In version 5.0.0 of the schema the cardina;ity for Leg has been changed to 1..2 to support Two-Way P-Modes. Also the default values for the key transport algorithms were updated to RSA-OAEP and MGF1 with SHA256

The P-Mode as defined in this schema is based on the structure described in appendix D of the Core Specification. As described in section D.2 one leg may involve two sets of P-Mode parameters if pulling is used as the pull request signal has its own set of parameters. This is reflected in this model by the flow concept. When a leg uses the pull binding it has two flows, one for the pull request and one for the user message.

The P-Mode parameters are used to set values in the ebMS message header and determine how and where to send messages. All parameter values must be known when the message is sent, but it is not necessary to include them all in the P-Mode. This would require a P-Mode for each exchanged message while some messages only differ on specific configuration parameters. Therefor Holodeck B2B allows the P-Mode to define only the common parameters and supply the message specific ones when the message is submitted. It is RECOMMENDED to include at least the initiator or responder of the exchange and information about the user message.

Security settings however can only be specified in the P-Mode. So if security must be applied to the messages governed by this P-Mode the configuration must be included in the Initiator and or Responder elements.

The REQUIRED identifier of this P-Mode. The P-Mode identifier is defined as optional in the ebMS v3 Core Specification and including it in the message header may cause problems in the receiving MSH if it uses no or another id for this P-Mode. Therefor the inclusion of the id in the message header is optional and can be set using the include attribute. When this attribute has value "false" (default value) the P-Mode id will not be included in the message header or used to find the P-Mode when a message is received.

NOTE 1: As the P-Mode id is included in the message as part of the agreement reference, including the P-Mode id requires the specification of an agreement reference either in the P-Mode or when the message is submitted.

NOTE 2: If set to "false" the P-Mode id included in a received message will not be used to determine the P-Mode that handles the message. This is to prevent an unintended match on the identifier set by a sender.

This element describes the message exchange pattern (MEP) this P-Mode uses. These are specified in section 2.2 of the ebMS V3 Core Specification. The MEP must be specified using the URI values given in the specification, see enumeration for allowed values.

NOTE: The current version of Holodeck B2B only allows One-Way MEPs so there is just one value. Because there is only one user message in a One-Way MEP the user message shall not contain a refToMessageId. Holodeck B2B however does allow for a refToMessageId to be included. So using two One-Way P-Modes a Two-Way MEP can be configured in Holodeck B2B.

Describes the transport channel binding for the specified MEP as defined in section 2.2 of the ebMS V3 Core Specification. The enumeration specifies the allowed values. Based on this elements value Holodeck B2B decides how to handle a submitted user message, i.e. actively send it to the receiver (push binding) or wait for the receiver to retrieve the message (pull binding).

NOTE: The current version of Holodeck B2B only allows One-Way MEPs so there is just two values for Push and Pull binding.

This element includes the information on the Initiator of the MEP, i.e. the partner that sends the first ebMS message. Note that this is not always the Sender of the first user message because in the pull scenario the first ebMS message (the pull request) is sent by the partner that will receive the user message. See the Holodeck website and chapter 2 of the ebMS V3 Core Specification for more info.

NOTE: This element is optional in the P-Mode. When not specified the information must be specified when a user message is submitted to Holodeck B2B. Attention should be paid to the fact that the meta-data on submission is expressed in Sender ("From") and Receiver ("To") roles which, as explained above, may not be equal to Initiator and Responder.

Identification of the trading partner. The identification of the partner can consist of the id itself and the identification of the naming scheme to which the id belongs. This naming scheme or domain is specified in the @type attribute.

The ebMS specification requires that the PartyId value MUST be an URI when no @type attribute is specified (see section 5.2.2.4 of ebMS Core Specification).

Note that for one partner multiple PartyIds can be specified. All given PartyIds MUST however identify the same organisation (see also section 5.2.2.3 of ebMS Core Specification).

The business role the partner is acting in.

Note that this is probably different then the role the MSH is playing in the MEP.

The security configuration specific to this trading partner.

This element contains the settings used to create the WS-Security UsernameToken element in messages sent by this trading partner.

This element can occur twice as their can be two WS-Security headers that can contain a UsernameToken element. The target attribute defines in which WS-Security header the username token most be added

This REQUIRED element specified the username to be included in the username token.

This REQUIRED element specified the password to be included in the username token.

NOTE: When the password contains special characters they may need to be encoded to get a well formed XML document!

This OPTIONAL element specifies whether a wsse:Nonce element must be included in the username token.

This OPTIONAL element specifies whether a wsu:Created element must be included in the username token.

This element contains the settings used to create the WS-Security Signature element in messages sent by this trading partner. The settings in this element correspond with the P-Mode parameter group PMode[1].Security.X509.Sign.

NOTE: Signature validation is always performed by Holodeck B2B regardless whether a Signing configuration is given.

This element contains the reference to the certificate in the Java keystore and MUST be used when Holodeck B2B is sending the message for this trading partner. It MUST contain the alias name that is used to store the certificate in the keystore. The OPTIONAL password attribute is used for accessing the private key in a certificate. This is only required when Holodeck B2B has to create the signature.

NOTE: When the password contains special characters they may need to be encoded to get a well formed XML document!

At the moment Holodeck B2B does not support certificate revocation checks! This element will be enabled when support is completed. Indicate whether Holodeck B2B must check whether the certificate used for signing a message is revoked. Applies only to received messages. NOTE 1: When an error occurs during the revocation check the certificate will be treated as invalid resulting in rejection of the complete ebMS message and all message units contained in it. Therefor the revocation check should only be enabled if the PKI infrastructure works correctly. NOTE 2: Setting the revocation check is OPTIONAL. If not set the global setting will be used.

This OPTIONAL element indicates how the certificate must be referenced in the WS-Security header. The options are specified in section 3.2 of the WS-Security X.509 Certificate Token Profile Version 1.1.1 specification.

If not specified Issuer and Serial number method will be used.

This OPTIONAL element indicates whether the complete certificate path must be included in the binary security token that contains the certificate used for signing the message. This setting only applies when Holodeck B2B creates the signature, i.e. is the sender of the signed message. See section 3.1 of the WS-Security X.509 Certificate Token Profile Version 1.1.1 specification for more information on the binary security token types.

By including the certificate path or chain in the binary security token the receiver of message does not need to know the end entity's certificate but can rely on the trust from a certificate authority. This makes certificate management much simpler as only the CA certificates need to be known on the receiving MSH.

Because the certificate path can only be included in a binary security token, this option can only be used when the KeyReferenceMethod is set to BSTReference.

Note that the receiving MSH must also be configured to accept and use a certificate path for validation of the signature. Therefore the default is to only include the end-entity certificate in the WS-Security header.

NOTE: The certificate loaded in the keystore MUST and referenced in KeystoreAlias already contain the complete certificate path, Holodeck B2B will not try to construct the path based on the end-entity certificate!

This OPTIONAL element contains the identifier of the algorithm that should be used for creating the signature. The identifiers are specified in section 6.1 of the XML Signature Syntax and Processing specification version 1.1 (XML-dsig). To ensure interoperability is RECOMMENDED to use an algoritm for which support is required by the XML-dsig specification.

If not specified the RSAwithSHA256 algorithm will be used for creating the signature.

This OPTIONAL element contains the identifier of the algorithm that should be used for creating the message digest. The identifiers are specified in section 6.1 of the XML Signature Syntax and Processing specification version 1.1 (XML-dsig). It is RECOMMENDED to use an algoritm for which support is required by the XML-dsig specification.

If not specified in the P-Mode the SHA256 algorithm will be used for creating the message digest.

This element contains the settings used to create the WS-Security elements for encryption in messages sent to this trading partner. The settings in this element correspond with the P-Mode parameter group PMode[1].Security.X509.Encryption.

This REQUIRED element contains the reference to the certificate in the Java keystore. It MUST contain the alias name that is used to store the certificate in the keystore. The OPTIONAL password attribute is used for accessing the private key in a certificate. This is only required when Holodeck B2B has to decrypt the message.

NOTE: When the password contains special characters they may need to be encoded to get a well formed XML document!

This OPTIONAL element contains the identifier of the algorithm that should be used to encrypt the message content. The identifiers are specified in section 5.1 of theXML Encryption Syntax and Processing Version 1.1 (XML-enc). It is RECOMMENDED to use an algoritm for which support is required by the XML-enc specification.

If not specified the AES128-GCM block encryption algorithm is used for encryption. Note that support for this algorithm is only required in XML-enc version 1.1 and up. Because ebMS V3 and AS4 currently reference only XML-enc version 1 this may cause interoperability issues when an MSH does not support for the newer version.

This OPTIONAL element contains the settings to add the key transport information to the WS-Security header, i.e. to construct the xenc:EncryptedKey element.

NOTE: If this element is included in the P-Mode it SHOULD contain at least one child element.

If not included in the configuration the follwoing defaults will be used for key transport:

• Key Transport Algorithm = RSA-OAEP (including MGF1 with SHA1)
• Message Digest Algorithm = SHA256
• Key Reference Method = Issuer and Serial number

This OPTIONAL element contains the identifier of the algorithm that should be used for key transport. The identifiers are specified in section 5.1 of the XML Encryption Syntax and Processing Version 1.1 (XML-enc). It is RECOMMENDED to use an algoritm for which support is required by the XML-enc specification.

When the RSA-OAEP (including MGF1 with SHA1) algorithm is specified the MGFAlgorithm element MUST NOT be used (as the MGF function is already specified by the transport algorithm).

If not specified (because the parent KeyTransport element is ommitted) the RSA-OAEP algorithm is used for key transport.

This OPTIONAL element contains the identifier of the mask generaton function algorithm that should be used for key transport. The identifiers are specified in section 5.1 of the XML Encryption Syntax and Processing Version 1.1 (XML-enc). It is RECOMMENDED to use an algoritm for which support is required by the XML-enc specification.

When this element is not provided the MGF1 with SHA256 algorithm is used as default.

This OPTIONAL element contains the identifier of the digest algorithm that should be used for key transport. The identifiers are specified in section 5.1 of theXML Encryption Syntax and Processing Version 1.1 (XML-enc). It is RECOMMENDED to use an algoritm for which support is required by the XML-enc specification.

If not specified the SHA256 digest algorithm is used for key transport.

This OPTIONAL element indicates how the certificate must be referenced in the WS-Security header. The options are specified in section 3.2 of the WS-Security X.509 Certificate Token Profile Version 1.1.1 specification.

If not specified Issuer and Serial number method will be used.

This element includes the information on the Responder of the MEP. The information is the same as for Initiator.

This element contains the identification of the business level agreement between the trading partners. This agreement does not define how message should be processed and is therefor optional.

However the P-Mode id is included in the message header as part of the agreement reference and therefor the information is required when the P-Mode id should be included. It is therefor RECOMMENDED to include the agreement info when the include attribute has value "true". If not included in the P-Mode the submission of a user message must contain the agreement info.

The Leg element contains the configuration settings for one leg of the P-Mode, i.e. the exchange of one user message. See section 2 of the ebMS Core Specification for more information on the messaging model and concept of legs.

In the P-Mode model described in the ebMS specification a leg can be identified by number (1 or 2) or label (request or reply). In this implementation the label primarily defines the order of the legs, but if no labels are specified the order of the elements also defines the order of the legs.

.

All child elements are optional because it is not known upfront which information is needed for a specific P-Mode and which information will be provided when a message is submitted. It is however RECOMMENDED to provide the UserMessageFlow element to define which user messages can be exchanged over this leg.

NOTE: As Holodeck B2B currently only supports One-Way MEPs there can be just one Leg element.

In version 2.1.0 the optional EventHandlers child element is added that can be used to configure how so called "message processing events" for message units of this leg should be handled.

The Protocol element contains the configuration for the underlying transport protocol. When Holodeck B2B sends the first message of the leg, the Address element MUST appear and contain the URL of the partner MSH. The other elements are all optional and the specified default values will be used when ommitted.

This element contains the URL where messages must be delivered to.

This element indicates whether the AS4 multi-hop feature as defined in section 4 of the AS4 standard is to be used for message exchanges on this leg. When multi-hop is used the ebMS header of a User Message is targeted to a specific role and response signals will have a specific WS-Addressing header containing routing information.

By default multi-hop is not used and the value for this element is false

This element defines the SOAP version to use when sending messages. The default value is to use SOAP 1.2. It is RECOMMENDED not to change this because this is the required version to use in AS4.

Indicates whether the HTTP "chunked" transfer encoding should be used. See section 3.6 of the HTTP/1.1 protocol [RFC2616] for more details.

When using HTTP compression with the gzip content encoding chunked transfer encoding must be used. Therefore Holodeck B2B will first check whether compression content encoding must be used an ignore the "chunked" setting.

Indicates whether the HTTP "gzip" compression content encoding should be used. See section 3.5 of the HTTP/1.1 protocol [RFC2616] for more details.

As using http compression requires the use of the chunked encoding as well, this element overrides the chunked setting in UseChunking element.

NOTE: Because of a problem in Holodeck B2B with the gzip encoding for HTTP responses this setting should only be used for requests!

This element indicates whether Receipts are used on this leg and contains the configuration for Receipt processing.

The ebMS V3 Core Specification does not specify in detail when and how receipt signals should be used. It only specifies P-Mode parameters for whether the receipt should be send, the reply pattern to use and the address where to sent the receipts to if not sent as a response. The content of the signal are not strictly defined and are left open for further specification in profiles (like AS4). Currently Holodeck B2B will always generate a receipt signal as specified in the AS4 profile (see section 5.1.8 of the profile).

The parameters for Receipt are defined in appendix D of the Core Specification as part of the P-Mode parameter group Security. As they are not directly related to security settings we moved them to a separate "Receipt" group and this element.

The ebMS specification defines the PMode[1].Security.SendReceipt parameter that indicate whether a Receipt should be sent for a user message. This parameter is not directly implemented in this schema but its value derived from the existence of the Receipt element for a leg, i.e. PMode[1].Security.Receipt := boolean(./Receipt).

This element represents the PMode.Security.SendReceipt.ReplyPattern parameter and indicates whether the Receipt signal is to be sent as a callback (value "CALLBACK"), or synchronously in the transport back-channel response (value "RESPONSE"). When set to "CALLBACK" also the sibling To MUST be set if this leg uses Push. When this leg uses Pull the To element MAY be ommitted in which case the Receipt will be piggybacked with the next Pull Request.

This element contains the URL where the Receipt signals should be sent to in case the reply pattern is set to "CALLBACK".

NOTE: This P-Mode parameter is not defined in the ebMS V3 Core Specification but defined in Part 2 (see issue 33 in OASIS TC issue tracker).

This element indicates whether the Producer, i.e. the business application that submitted the user message, should be notified about the reception of the Receipt signal.

Note that the ebMS specifications do not specify a specific parameter for the receipt notification. There is only the parameter PMode[1].ErrorHandling.Report.MissingReceiptNotifyProducer defined in the AS4 Profile to indicate whether the business application should be notified about a missing receipt, but not about receiving one. The NotifyReceiptToBusinessApplication element applies to both situations, receiving or missing an expected receipt. It is not possible to configure these situations separately.

Also note that for detecting a missing receipt an interval to wait for a Receipt has to be specified. This is however part of the AS4 Reception Awareness feature and therefore also part of its configuration.

Like the delivery of user message the notification to the business application is done by a "message deliverer". With this element a specific delivery method can be configured for the notification of Receipts. If this element is absent the default delivery method of the leg will be used for the delivery of the Receipt.

Delivery of messages in Holodeck B2B is done by a message deliver, which is a class implementing the org.holodeckb2b.common.delivery.IMessageDeliverer interface. Because it may not be efficient to create a new instance each time a message must be delivered Holodeck B2B uses a factory class to get a deliverer (see the org.holodeckb2b.common.delivery.IMessageDelivererFactory interface). In this element the name factory class must be specified. To correctly deliver messages to the business application probably the deliverer should be configured. This can be done by specifying the required parameters in the sibling Parameter elements.

This element can be used to configure the message deliverer factory to create a correctly configured message deliver.

The ReceptionAwareness element is used for configuration of the Reception Awareness Feature specified in section 3.2 of the AS4 profile. As this feature depends on the use of Receipts the Receipt element MUST also be included in the P-Mode document when this element is included.

The AS4 profile defines five additional P-Mode parameters for the reception awareness feature. This P-Mode definition however uses less parameters as some of the P-Mode parameters from the spec are combined.

Since version 4.0.0 the configuration of the retries is made more flexible and the interval for each retry can be specified separately.

When no Receipt is received before the last wait interval expires a MissingReceipt error is generated. This error is always logged by Holodeck B2B but whether the business application will be notified depends on the NotifyReceiptToBusinessApplication setting.

This element sets the maximum of times a message should be resend if no Receipt is received using the fixed interval time specified in RetryInterval. If this element is set to "0" no retries will be send and Holodeck B2B will wait the specified interval for the Receipt to arrive before generating a MissingReceipt error.

This element contains the fixed time interval, in seconds, to wait for a Receipt and before resending a User Message.

NOTE: For back-ward compatibility this element is still named RetryInterval.

This element contains the intervals Holodeck B2B has to wait for a Receipt to arrive before resending the User Message or in case no re-sending should take place just the time to wait for a Receipt before generating a MissingReceiptError.

This element MUST be included in case Holodeck B2B should resend User Message and include at least two values. The element is OPTIONAL when resending is not needed in which case Holodeck B2B may generate the MissingReceiptError immmediately after sending the User Message (and processing the response).

The value of this element must be a comma separated list of positive integers. Each integer defines the time in seconds to wait for a Receipt and before a new attempt will be executed to send the message. Note that the total number of send attempt is equal to the number of intervals specified, so the number of retries is one less then the number of intervals.

Part of the reception awareness feature is duplicate detection and elimination. With this element the detection and elimination of duplicates can be enabled. If set to "true" Holodeck B2B will search all received messages in database to check if the message was received (and delivered) before and stop processing the duplicate if it is. There is no further parameterization.

With this element the delivery of received messages is configured. This element MUST be included when Holodeck B2B is the receiver of user messages on this leg.

If Holodeck B2B only sends messages on this leg the element may be ommited. If however the business application should be notified on errors or receipts it may be usefull to define one default delivery method instead of specifying it for errors and receipts separately.

This element configures the processing of the PullRequest and MUST be included at least once when the leg uses pulling.

There should be at most one PullRequestFlow element when Holodeck B2B is the sender of the PullRequest, but when Holodeck B2B acts as the responder to the pull requests the element can be included multiple times to configure the sub-channels that can be pulled. Each instance represents one sub-channel that MUST be identified by the Mpc element. For more information on sub channnels see section 3.5 of the AS4 profile.

The error handling configuration is currently limited to indication whether errors should be reported to the business application as the other settings are not useful in case of a pull request. As a result the error handling configuration only applies to the sender of the PullRequest message.

This REQUIRED element contains the MPC that must be included in the pull request. This can be a sub-channel MPC specific for this pull request. In that case this sub-channel MPC must start with the MPC provided in/for the (to be) pulled user message.

This element defines how errors related to the pull request message exchange should be handled. Currently the configuration for pull request is limited to notifying of errors to the business application as error reporting is fixed to a synchronous response

Defines how the error should be reported to sender of the message in error. The default is to sent the error directly as a response to the received message or when the message in error is pulled to push the error to the sender (using the URL specified in the Protocol/Address element of this leg). When the error should be reported to a specific URL the reply pattern must be set to "CALLBACK" and the URL must be supplied in the ReceiverErrorsTo element. Note that this setting is generally only used when Holodeck B2B acts as in the receiving role.

This element should contain the URL where generated errors for received messages should be sent to in case the reply pattern is CALLBACK. Note that this setting is generally only used when Holodeck B2B acts as in the receiving role.

This element indicates whether a SOAP Fault should be added to ebMS error messages that contain an error with severity FAILURE. By default Holodeck B2B will not add the SOAP Fault, therefor the default value is set to false. NOTE: Even if this element has value true the SOAP Fault may not be added to the message if it contains other message units beside the error signal.

This element indicates whether errors that are generated for error messages should be reported back to the sender of the erroneous error message. Overwrites the global setting configured in the Holodeck B2B Core module.xml. Note that this setting can only be applied when the P-Mode can be detected for the erroneous error.

This element indicates whether errors that are generated for receipt messages should be reported back to the sender of the erroneous receipt message. Overwrites the global setting configured in the Holodeck B2B Core module.xml. Note that this setting can only be applied when the P-Mode can be detected for the erroneous receipt.

This element configures whether errors on user messages exchanged on this leg should be notified to the producer business application. The notification of errors uses the same delivery mechanism as user messages with a message deliver. If the business application should be notified on errors a specific delivery can be specified in the ErrorDelivery element.

The notification of errors uses the same delivery mechanism as user messages with a message deliver. If the business application should be notified on errors for pull request a specific delivery can be specified in this element.

If no specific delivery method is specified the delivery method defined here, the leg's default delivery will be used.

This element specifies how errors on a PullRequest must be reported to the sender of the request. In the current version only direct synchronous reporting is supported so the value of this element is fixed to RESPONSE.

This element configures whether errors on pull request messages exchanged on this leg should be notified to the producer business application. If errors should be delivered to the business applicatio a delivery method shoud be specified either specifically for these errors or more generic on the leg.

The notification of errors uses the same delivery mechanism as user messages with a message deliver. If the business application should be notified on errors for pull request a specific delivery can be specified in this element.

If no specific delivery method is specified the delivery method defined in the ErrorHandling element of the UserMessageFlow will be used, and if that element is not specified as well the leg's default delivery will be used.

This element the security configuration that should be used to authenticate and authorize the pull request message.

This element contains the configuration for the UsernameToken element to include in the WS-Security header targeted at the "ebms" role/actor.

This element contains the configuration for the Signature element to include in the "default" WS-Security header.

This REQUIRED element contains the reference to the certificate in the Java keystore. It MUST contain the alias name that is used to store the certificate in the keystore. The OPTIONAL password attribute is used for accessing the private key in a certificate. This is only required when Holodeck B2B has to create the signature.

NOTE: When the password contains special characters they may need to be encoded to get a well formed XML document!

At the moment Holodeck B2B does not support certificate revocation checks! This element will be enabled when support is completed. Indicate whether Holodeck B2B must check whether the certificate used for signing a message is revoked. Applies only to received messages. NOTE 1: When an error occurs during the revocation check the certificate will be treated as invalid resulting in rejection of the complete ebMS message and all message units contained in it. Therefor the revocation check should only be enabled if the PKI infrastructure works correctly. NOTE 2: Setting the revocation check is OPTIONAL. If not set the global setting will be used.

This OPTIONAL element indicates how the certificate must be referenced in the WS-Security header. The options are specified in section 3.2 of the WS-Security X.509 Certificate Token Profile Version 1.1.1 specification.

If not specified Issuer and Serial number method will be used.

This OPTIONAL element indicates whether the complete certificate path must be included in the binary security token that contains the certificate used for signing the message. This setting only applies when Holodeck B2B creates the signature, i.e. is the sender of the signed message. See section 3.1 of the WS-Security X.509 Certificate Token Profile Version 1.1.1 specification for more information on the binary security token types.

By including the certificate path or chain in the binary security token the receiver of message does not need to know the end entity's certificate but can rely on the trust from a certificate authority. This makes certificate management much simpler as only the CA certificates need to be known on the receiving MSH.

Because the certificate path can only be included in a binary security token, this option can only be used when the KeyReferenceMethod is set to BSTReference.

Note that the receiving MSH must also be configured to accept and use a certificate path for validation of the signature. Therefore the default is to only include the end-entity certificate in the WS-Security header.

NOTE: The certificate loaded in the keystore MUST and referenced in KeystoreAlias already contain the complete certificate path, Holodeck B2B will not try to construct the path based on the end-entity certificate!

This OPTIONAL element contains the identifier of the algorithm that should be used for creating the signature. The identifiers are specified in section 6.1 of the XML Signature Syntax and Processing specification version 1.1 (XML-dsig). To ensure interoperability is RECOMMENDED to use an algoritm for which support is required by the XML-dsig specification.

If not specified the RSAwithSHA256 algorithm will be used for creating the signature.

This OPTIONAL element contains the identifier of the algorithm that should be used for creating the message digest. The identifiers are specified in section 6.1 of the XML Signature Syntax and Processing specification version 1.1 (XML-dsig). It is RECOMMENDED to use an algoritm for which support is required by the XML-dsig specification.

If not specified in the P-Mode the SHA256 algorithm will be used for creating the message digest.

This element configures the processing of user messages exchanged on this leg.

Again all child elements are optional as default values can be used or information can be provided when a user message is submitted.

Contains the business meta data to use in the ebMS header. When acting in the Sending role, the information is used to construct the header. As the information may also be supplied when the message is submitted there are no required elements in the P-Mode. When acting in the Receiving role the information provided here can be used to determine the P-Mode that defines how the message should be processed.

NOTE: Current Holodeck B2B only uses the P-Mode id in the message header to determine the P-Mode.

This element contains the business level operation/activity requested to be executed. It is represented by the eb:Action element in the ebMS header.

This element contains the MPC the user message is exchanged over. It is contained in the mpc attribute of the eb:UserMessage element in the ebMS header.

This element contains the meta-data on the business service that is [supposed] to handle the user message and consist of a service name and optionally type. The information from this element will be used in the eb:Service element in the ebMS header.

This element defines a property to include in the set of MessageProperties.

NOTE: This definition allows to set the type of the property as sepecified in the ebMS V3 Core Specification. Due to an error in the XML Schema published with the ebMS V3 Specification adding the type attribute to a Property element will invalidate the message header! It is therefore RECOMMENDED to use this element only when it is known that the trading partner's MSH can handle this attribute.

This element defines how errors related to the user message exchange should be handled.

This element specifies whether the AS4 Compression Feature should be used. If enabled all payloads contained as attachment to the SOAP message will be compressed using gzip. The compression is not applied to paylaods contained in the SOAP body or on an external location. Although the specification allows implementations not to compress payloads using a file type that is already compressed Holodeck B2B will always compress all attached payloads.

This element defines the custom validations that should be performed for User Messages that are processed in this message flow. Custom validations can be configured for both submitted and received User Messages. The custom validation will be executed when the message is submitted to the Core or before a Receipt is created an the message is delivered to the business application. Whether the message will be further processed, i.e. accepted or delivered, depends on the configuration.

This optional indicator defines whether the validators MUST be executed in order. It is NOT RECOMMENDED to require in order execution as it may slow down the message processing. If in order execution is used it is RECOMMENDED to stop validation as soon as an error is detected.

This optional indicator defines whether the validation of a message unit should stop after a validation error with the specified severity level has been found. By default the validation never stopped and all validators are executed.

This optional indicator defines whether the message unit should be rejected and further messaage processing should stop after a validation error with the specified severity level has been found. If the message is rejected an ebMS Error with ErrorCode EBMS:0004 (Other) will be generated that includes the description of the found errors. By default message will not be rejected because of validation errors.

NOTE: If validation errors occur they will always trigger a ICustomValidationFailedEvent

This element which must occur at least once specifies which validations should be executed for all User Messages processed in this flow.

This element contains the identifier of this validator configuration. This id is used by Holodeck B2B for logging purposes and inclusion in message processing events and may also be used to determine whether it must create and configure a new Factory object.

NOTE: Configurations MUST be uniquely identified as Holodeck B2B will only use the id to check for equivalence.

This element should contain the class name of the factory class that should be used to create actual instances of the validator.