The AS4 specification defines three basic conformance profiles: ebHandler, Light and Minimal Client. These basic profiles can be extended with the AS4 Multi-Hop Endpoint Conformance Clause to add support for multi-hop messaging. For each profile it is defined which P-Mode parameters must be supported to claim conformance to the profile. The table below lists these P-Mode parameters and shows whether Holodeck B2B supports them. P-Mode parameters are only included in this table if support for a parameter is required by any of the AS4 profiles or if Holodeck B2B offers support for it.
Legend
✓ = required / supported in Holodeck B2B
O = optional
N = not required / not supported in Holodeck B2B
P-Mode parameter | Holodeck B2B | AS4 ebHandler | AS4 Light Client | AS4 Minimal Client |
---|---|---|---|---|
General P-Mode parameters | ||||
PMode.ID | ✓ | ✓ | ✓ | ✓ |
PMode.Agreement | ✓ | ✓ | ✓ | ✓ |
PMode.MEP | One-Way Two-Way asynchronous | One-Way | One-Way | One-Way |
PMode.MEPBinding | One-Way/Push One-Way/Pull both as Initiator and Responder Two-Way using combination of Push and Pull | One-Way/Push One-Way/Pull both as Initiator and Responder | One-Way/Push One-Way/Pull as Initiator | One-Way/Push |
PMode.Initiator.Party | ✓ | ✓ | ✓ | ✓ |
PMode.Initiator.Role | ✓ | ✓ | ✓ | ✓ |
PMode.Initiator.Authorization.username | ✓ | ✓ | ✓ | N |
PMode.Initiator.Authorization.password | ✓ | ✓ | ✓ | N |
PMode.Initiator.Authorization.Digest (*1) | ✓ | - | - | - |
PMode.Initiator.Authorization.Nonce (*1) | ✓ | - | - | - |
PMode.Initiator.Authorization.Created (*1) | ✓ | - | - | - |
PMode.Responder.Party | ✓ | ✓ | ✓ | ✓ |
PMode.Responder.Role | ✓ | ✓ | ✓ | ✓ |
PMode.Responder.Authorization.username | ✓ | ✓ | N | N |
PMode.Responder.Authorization.password | ✓ | ✓ | N | N |
PMode.Responder.Authorization.Digest (*1) | ✓ | - | - | - |
PMode.Responder.Authorization.Nonce (*1) | ✓ | - | - | - |
PMode.Responder.Authorization.Created (*1) | ✓ | - | - | - |
PMode[1].Protocol | ||||
PMode[1].Protocol.Address | http and https (*2) | http and https | http | http |
PMode[1].Protocol.AddActorOrRoleAttribute | ✓ | C (*3) | C (*3) | C (*3) |
PMode[1].Protocol.SOAPVersion | 1.1 and 1.2 | 1.2 | 1.2 | 1.2 |
PMode[1].BusinessInfo | ||||
PMode[1].BusinessInfo.MPC | ✓ | ✓ | ✓ | N |
PMode[1].BusinessInfo.subMPCext | ✓ | O | O | N |
PMode[1].BusinessInfo.Service | ✓ | ✓ | ✓ | ✓ |
PMode[1].BusinessInfo.Action | ✓ | ✓ | ✓ | ✓ |
PMode[1].BusinessInfo.Properties[] | ✓ | ✓ | ✓ | N |
PMode[1].BusinessInfo.PayloadProfile[] | N | O | O | N |
PMode[1].ErrorHandling | ||||
PMode[1].ErrorHandling.Report.SenderErrorsTo | N | N | N | N |
PMode[1].ErrorHandling.Report.ReceiverErrorsTo | ✓ | ✓ | N | N |
PMode[1].ErrorHandling.Report.AsResponse | ✓ | ✓ | ✓ | ✓ |
PMode[1].ErrorHandling.Report.ProcessErrorNotifyConsumer | N | N | N | N |
PMode[1].ErrorHandling.Report.ProcessErrorNotifyProducer | ✓ | ✓ | ✓ | N |
PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer | N | N (*4) | N (*4) | N |
PMode[1].ReceptionAwareness | ||||
PMode[1].ReceptionAwareness | ✓ | ✓ | ✓ | N |
PMode[1].ReceptionAwareness.Retry | ✓ | ✓ | ✓ | N |
PMode[1].ReceptionAwareness.Retry.Parameters | Max. number of retries Interval | ✓ | ✓ | N |
PMode[1].ReceptionAwareness.DuplicateDetection | ✓ | ✓ | ✓ | N |
PMode[1].ReceptionAwareness.DetectDuplicates.Parameters | Fixed, complete message log is checked for duplicates | O | O | N |
PMode[1].Security | ||||
PMode[1].Security.WSSVersion | 1.1.1 | 1.1 | 1.1 | N |
PMode[1].Security.X509.Sign | ✓ | ✓ | ✓ | N |
PMode[1].Security.X509.Signature.Certificate | ✓ | ✓ | ✓ | N |
PMode[1].Security.X509.Signature.HashFunction | ✓ | ✓ | ✓ | N |
PMode[1].Security.X509.Signature.Algorithm | ✓ | ✓ | ✓ | N |
PMode[1].Security. X509.Encryption.Encrypt | ✓ | ✓ | N | N |
PMode[1].Security.X509.Encryption.Certificate | ✓ | ✓ | N | N |
PMode[1].Security.X509.Encryption.Algorithm | ✓ | ✓ | N | N |
PMode[1].Security.X509.Encryption.MinimumStrength | N | N | N | N |
PMode[1].Security.UsernameToken.username | ✓ | ✓ | ✓ | N |
PMode[1].Security.UsernameToken.password | ✓ | ✓ | ✓ | N |
PMode[1].Security.UsernameToken.Digest | ✓ | ✓ | ✓ | N |
PMode[1].Security.UsernameToken.Nonce | ✓ | N | N | N |
PMode[1].Security.UsernameToken.Created | ✓ | ✓ | ✓ | N |
PMode[1].Security.PModeAuthorize | Implicit. Derived from PMode.[Initiator|Responder]. Authorization. | ✓ | ✓ | N |
PMode[1].Security.SendReceipt | ✓ | ✓ | ✓ | N |
PMode[1].Security.SendReceipt.NonRepudiation (*5) | ✓ (*6) | ✓ | ✓ | N |
Pmode[1].Security.SendReceipt.ReplyPattern | ✓ | ✓ | ✓ | N |
Pmode[1].Security.SendReceipt.ReplyTo (*7) | ✓ | ✓ | ✓ | N |
AS4 Compression Feature | ||||
PMode[1].PayloadService.CompressionType | ✓ | ✓ | ✓ | N |
(*1) These parameters are not mentioned in either AS4 Profile and ebMS V3 Core Specification for the UsernameToken included in the WS-Security header targeted to “ebms”.
(*2) https support only as client.
(*3) Support for this parameter is required when the AS4 Multi-Hop Endpoint Conformance Clause is used.
(*4) The AS4 profile version 1.0 erroneously states that support is required for this parameter. See issue 59 on the ebXML Messaging TC’s issue list.
(*5) This parameter is defined in (non-normative) section 5.2.1 of the AS4 profile. See also issue 30 in the issuetracker of the OASIS TC.
(*6) Holodeck B2B supports sending NRR Receipts, but determination of receipt type is currently based on whether the acknowledged user message is signed or not. When signed Holodeck B2B will create a NRR Receipt, otherwise a Reception Awareness Receipt will be created.
(*7) This parameter is defined in (non-normative) section 6.7.1 of ebMS V3 Part 2. Support for this parameter is required if the ReplyPattern value is “callback”. See also issue 33 in the issuetracker of the OASIS TC.