OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: AS4 receipts cont'd

 
As discussed last week,  here is some input to the AS4 receipt generation discussion.
 
The main difference of this proposal with the latest WD is that "reception awareness" receipts are handled more granularly and are more consistent with the ebBP structure (unlike the previous WD proposal). The proposal is not complex,  but it is undeniable that a clean sheet approach (with no re-use of ebBP structures but some ad hoc XML) could have resulted in something even simpler.
 
The attached revized XSLT stylesheet implements all this. Also see the stylesheet documentation and a set of example user messages (ending in ".xml") with receipts (ending in ".out.xml").  The XSLT implements receipt generation and could be used in an AS4 MSH, but its purpose in the AS4 appendix is documentation only.   Receipts are supported for the following types of messages:
 
-   Signed messages (using WS-Security) and un-signed messages.
-   Plain SOAP AS4 messages and SOAP-with-attachments AS4 messages.
-   Peer-to-peer AS4 messages and AS4 multi-hop messages.
-   Messages with payloads, an implicit payload (no href value), or even no payloads.
-   Messages with payload in the SOAP body or attached as MIME parts.
 
If the TC agrees with this proposal,  I can propose some updates for the AS4 specification.   Those updates would basically correspond to the XSLT documentation.
 
Two remaining questions:
 
Question 1:  In the MessagePartIdentifier, I am assuming that here the actual identifiers are used,  not prefixed by "cid:" or "mid:".  Is that correct?
 
Question 2:  One defined requirement of "Reception awareness" is:
  • Ability to report an error to the message Producer in case no eb:Receipt has been received for a sent message
 
Code = EBMS:0301, Short Description = MissingReceipt, Severity = Failure, Category = Communication.

I think it is not just an error if no receipt is received, but also if the contents of the receipt does not match what the sender expects (for instance a part is missing, or an unknown part seems to have been added, or a ds:Reference has a bad DigestValue) ?  How about the following:

Code = EBMS:0302, Short Description = InvalidReceipt, Severity = Failure, Category = Communication.

Unfortunately I cannot attend tomorrow's call due to another committment.

 
Pim

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: 06 December 2011 10:09
To: 'Jacques Durand'; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - AS4-profile-v1.0-wd20.odt uploaded

Unfortunately not all changes to previous versions were tracked.
Comments inline.
 
Pim
 
From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Jacques Durand
Sent: 05 December 2011 23:55
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - AS4-profile-v1.0-wd20.odt uploaded

I have uploaded a candidate AS4 spec (AS4-profile-v1.0-wd20.odt) from wd19, that implements most of Pim’s recommendations, remaining from  Sander’s (in wd19).

 

1-     Compression property with value "true" instead of empty string for XML schema compliance.

Did the update that requires the “Compressed” property to have a value  (I believe the Example in 3.1 was the main culprit?). Also it seems we never introduced the “Compressed” property used in the example (so I did).

 

Section 3.1 now requires two properties "Compressed" (fixed value "true") and "CompressionType" (fixed value "application/gzip"), but the example in that section still only has "Compressed".  Having a separate property for the type of Compression seems useful if more than one type is allowed (other compression algorithms have emerged after GZIP that have advantages in some cases, though it's fine if AS4 does not want to use them for interoperability), but if we have just one allowed value,  what does it add? Isn't the "Compressed" property redundant if we specify the "CompressionType" ?
 
 

2-     MIME type value in property for a compressed attachment required instead of recommended.

Done by Sander.

 

3-     Add note that a compressed payload must be in a separate MIME part and not in the SOAP Body

Added a simple note in 3.1.

 

4-   In AS4 5.1.8.(a) and 5.1.8.(b), clarify use of receipts with simple SOAP messages, where the SOAP envelope is not in a part with a content identifier, and has no MIME content ID, so here there can be no part identifier.   

Done by Sander.

 

5.1.8 (b) references message parts using ds:References,  but 5.1.8 (a) now should references the ebMS message ID in a PartInfo ? The MessageId is already referenced in the eb3:RefToMessageId in the MessageInfo of the SignalMessage in both cases, having it as value for MessagePartIdentifier in one case is redundant, is inconsistent with the other non-repudiation use and does not match the semantics of the ebbp:NonRepudiationInformation structure.  
 
BTW what would "should" mean,  are other values allowed, if yes, which ones?
 
The earlier proposal was to use the MIME part identifiers for reception awareness.   This works for all SOAP with attachment messages.  The issue was about plain SOAP messages with any payload in the SOAP body.  Another solution is to require SOAP with attachments for AS4 messages (or at least for the ones that require receipts), after all that worked in ebMS 2.0. 
 
Unfortunately the value of a MessagePartIdentifier is a non-empty string, so it cannot be left unspecified.
 

5-  In AS4 5.1.8.(a) and 5.1.8.(b), note that it is impossible to generate a valid ebBP reception awareness

 

We have to decide what note to be added in 5.1.8 for this.

 

6-  In AS4 5.1.8.(a) and 5.1.8.(b), decide on ebbp:MessagePartIdentifier format for a payload part in SOAP body that is implicitly identified by absence of an "href" attribute as described in ebMS3Core.

 

Should we just require something like a string “soap:body”, for readability? (not done yet)

 

Unfortunately the value of a MessagePartIdentifier is a non-empty string, so it cannot be left unspecified. We could profile AS4 to make the href attribute mandatory, always or for messages that request receipts.
 

7-  Clarify that an identifier of a payload in the SOAP Body is a stored as an attribute value on the SOAP Body element, not on the contained document root (AS4 interop).

 

Not sure I understand this: the soap Body could have several payload parts actually, and the @id attribute is at the root of each one of these (not on the Body element). See example in Appendix C2 of Core V3.

 
There is a problem with that example in the core spec:  the business document is submitted by the Sending application, and it may not have an "id" attribute.   We shouldn't let the sending MSH add an id, as the receiving MSH may not know if it was added by the sending application or by the sending MSH, so it can't remove it. The XML schema of that document may not even allow an "id" attribute, so unless it were removed, the receiving application would consider it an invalid XML document.  
 
When using WS-Security, the identifying attribute is on the SOAP:Body, not on the enclosed XML document.  We don't require WS-Security, but the place to put the attribute should be the same whether we use it or not.
 

 

8-  Discuss the format of the identifier (xml:id or wsu:Id).   

 

It seems to be @id (not @Id) see examples in core V3.

 

9-  Bad references to SOAP 1.1 instead of 1.2.

 

Done by Sander.

 

10-Guidelines on values for mpc (message partition channel) attributes.  Pullrequests do not have ebMS metadata, so a partner that sends documents to multiple partners using Pull mode must assign them to different channels, unless we want to require support for the "selective pulling" feature of Part 2 in ebMS.

 

Here I think it would be better to add as an optional extra feature  (for a Sender), support for sub-channels. We have defined this feature in Part 2 for intermediaries only. We can refer to it as an (optional) extra feature, as it was initially defined for a multi-hop context but can easily be considered in a single hop case here.. See new proposed section 3.5. 

 

We need a way to specify, as a new PMode parameter the "receiver sub-MPC".  This is the MPC that the receiver pulls from. It may be different from the MPC the sender submits it to, but not completely different, it is required to be a sub-channel.  The Sending MSH needs to know how to partition the set of messages submitted to an MPC across various sub-MPCs.  What rules control this partitioning?   We might associate a sub-channel with an XPath _expression_ over the UserMessage header.  Here the partitioning is done at submission time and authorization can be done at a fine-grained sub-channel level.
 
Another option is the selective pulling feature in Part 2.  Basically,  a receiver could pull from a generic MPC and select it using the to:PartyId=<<their ID>>.  Here the selection is done more dynamically, the receiving MSH has more control. But the receiver must be authorized for the MPC, so this is more a feature to give better control to the receiver. 
 

 

 

11-  Support for Two Way MEPs.   This is not needed for EDIINT,  but in essence allowing an MSH to set the value for RefToMessageId adds minimal complexity to an implementation.   It allows AS4 to be used also for SOA-style, request/response interactions.

I think Sander addressed this (just as an option) with a simple note.

 

If we want this, we need to allow them in 2.1.1 and 2.2.1.  I'm in favour of allowing Two Way MEPs.   All it means is that an MSH must be able to set an eb3:RefToMessageId in an outgoing message, which is trivial.  (We require them to set ConversationId already, after all).   I can't think of any interop reasons to leave this out. The main benefit is that AS4 can be used for SOA-style, request/response interactions and not just for batch EDI.   AS4 could replace ebMS 2.0 for all of my customers' applications if it supported this.  

 

The OASIS Energy Interop TC is currently profiling ebMS 3.0 for smart grid, and this issue came up there are well.

 

Including RefToMessageId in responses supports a style of asynchronous programming where the sender registers a callback based on MessageId. It is possible to do this by correlating message payloads,  but it is much more practical and consistent to be able to use a UserMessage element. When the response comes it, the appropriate handler can be called before any payloads are processed.

 

 

IMPORTANT:  regarding support for compression:

-          The question whether light AS4 clients – in particular “minimal” client - should support compression (meaning also attachments, and msg properties) is still controversial in my view: if we want to “certify” very light clients and devices, I’d be in favor of keeping the “minimal client” conformance level low, i.e. not requiring these features. 

There was a question about this in the OASIS Energy Interop TC as well.   They asked if GZIP support is widespread or practical in low-end devices that are in their scope.   A strong advantage of GZIP is that it has a very small memory footprint and is fast (compared to other algorithms that have a better compression ratio).

 

They also asked if we had considered http://www.w3.org/TR/2011/REC-exi-20110310/ as an alternative.

 

-          So my uploaded draft reflects this option (low bar for “minimal client” conformance level). See the conformance Clause: to be discussed.

 

NOTE: a small issue not fixed yet: the ref to V3 Part 2 is using a different acronym in the ref section ([ebMS3ADV]) than in the body of the spec (ebMSP2)

 

Thanks

Jacques

 

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: Friday, November 11, 2011 6:26 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Groups - AS4-Profile-csd04-wd-17.odt uploaded

 

Submitter's message
I've made some updates based on discussion of the issues in the TC. Jacques will produce the next version after the upcoming F2F.

------------

Fixed a bad reference to SOAP 1.1 in section 2.2.1 .

In 3.1 compression, the original MIME type of a compressed payload is required instead of just being recommended; added clarification on use of CharacterSet in compression.

Minor editorial changes and some comments on areas that may need clarification.

-- Mr. Pim van der Eijk

Document Name: AS4-Profile-csd04-wd-17.odt

Description
AS4 profile
Download Latest Revision
Public Download Link

Submitter: Mr. Pim van der Eijk
Group: OASIS ebXML Messaging Services TC
Folder: documents
Date submitted: 2011-11-11 06:25:55
Revision: 12

 

Attachment: Sample_messages_with_receipts.zip
Description: Zip compressed data

Attachment: stylesheetdoc.zip
Description: Zip compressed data

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
    xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl"; exclude-result-prefixes="xd xsi" version="1.0"
    xmlns:S12="http://www.w3.org/2003/05/soap-envelope";
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
    xmlns:wsa="http://www.w3.org/2005/08/addressing";
    xmlns:ebint="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/multihop/200902/";
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
    xmlns:eb3="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/";
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
    xmlns:ebbp="http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0";
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
    <xd:doc scope="stylesheet">
        <xd:desc>
            <xd:p><xd:b>Created on:</xd:b> Dec 13, 2011</xd:p>
            <xd:p><xd:b>Author:</xd:b> pvde</xd:p>
            <xd:p>This XSLT stylesheet is a non-normative part of the OASIS AS4 specification. It
                shows how AS4 messages can be derived from AS4 user messages.</xd:p>
        </xd:desc>
        <xd:param name="messageid">
            <xd:p>The messageid to use on the AS4 receipt signal message</xd:p>
        </xd:param>
        <xd:param name="timestamp">
            <xd:p>The timestamp to set on the AS4 receipt signal message</xd:p>
        </xd:param>
        <xd:param name="start">
            <xd:p>To generate a receipt for a SOAP-with-attachments message, pass the value of the
                    <xd:i>start</xd:i> parameter that contains the MIME Content-Id of MIME part
                containing the SOAP root element.</xd:p>
        </xd:param>
    </xd:doc>

    <xsl:output method="xml" indent="yes"/>

    <xsl:param name="messageid">someuniqueid@receiver.example.com</xsl:param>
    <xsl:param name="timestamp">2011-12-13T19:43:11.735Z</xsl:param>
    <xsl:param name="start">None</xsl:param>


    <xsl:template match="S12:Envelope">
        <S12:Envelope>
            <xsl:apply-templates/>
        </S12:Envelope>
    </xsl:template>

    <xsl:template match="S12:Header">
        <S12:Header>
            <xsl:apply-templates select="eb3:Messaging"/>
        </S12:Header>
    </xsl:template>

    <xd:doc>
        <xd:desc>When generating a receipt for a signed message, the receipt will be signed as well.
            We generate an identifier for the empty SOAP Body of the AS4 receipt for the WS-Security
            module.</xd:desc>
    </xd:doc>
    <xsl:template match="S12:Envelope[S12:Header//ds:Signature]/S12:Body">
        <S12:Body wsu:Id="{generate-id()}"/>
    </xsl:template>

    <xd:doc>
        <xd:desc>The empty body of receipt signal receipt for an unsigned message does not need an
            identifier</xd:desc>
    </xd:doc>
    <xsl:template match="S12:Envelope[not(S12:Header//ds:Signature)]/S12:Body">
        <S12:Body/>
    </xsl:template>

    <xd:doc>
        <xd:desc>There are two templates for <xd:i>eb3:Messaging</xd:i> element. This first template
            is for an AS4 user message that may have been exchanged over a multi-hop network. The
            receipt for such a message has WS-Addressing headers and routing parameter based on the
            user message content as described in ebMS 3 Part 2 and AS4.</xd:desc>
    </xd:doc>
    <xsl:template
        match="eb3:Messaging[
        @S12:role='http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh']">
        <xsl:variable name="mpc">
            <xsl:choose>
                <xsl:when test="descendant::eb3:UserMessage[1]/@mpc">
                    <xsl:value-of select="descendant::eb3:UserMessage[1]/@mpc"/>
                </xsl:when>
                <xsl:otherwise>http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC</xsl:otherwise>
            </xsl:choose>
        </xsl:variable>
        <wsa:To wsu:Id="{concat('_wsato_',generate-id())}"
            S12:role="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh";
            S12:mustUnderstand="true"
            >http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/icloud</wsa:To>
        <wsa:Action wsu:Id="{concat('_wsaaction_',generate-id())}"
            >http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay.receipt</wsa:Action>
        <ebint:RoutingInput wsa:IsReferenceParameter="true"
            id="{concat('_ebroutinginput_',generate-id())}" S12:mustUnderstand="true"
            S12:role="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh";>
            <ebint:UserMessage mpc="{concat($mpc,
                '.receipt')}">
                <eb3:PartyInfo>
                    <eb3:From>
                        <xsl:copy-of select="descendant::eb3:UserMessage[1]//eb3:To/eb3:PartyId"/>
                        <xsl:copy-of select="descendant::eb3:UserMessage[1]//eb3:To/eb3:Role"/>
                    </eb3:From>
                    <eb3:To>
                        <xsl:copy-of select="descendant::eb3:UserMessage[1]//eb3:From/eb3:PartyId"/>
                        <xsl:copy-of select="descendant::eb3:UserMessage[1]//eb3:From/eb3:Role"/>
                    </eb3:To>
                </eb3:PartyInfo>
                <eb3:CollaborationInfo>
                    <xsl:copy-of select="descendant::eb3:UserMessage[1]//eb3:Service"/>
                    <eb3:Action>
                        <xsl:value-of
                            select="concat(descendant::eb3:UserMessage[1]//eb3:Action,
                        '.receipt')"
                        />
                    </eb3:Action>
                    <xsl:copy-of select="descendant::eb3:UserMessage[1]//eb3:ConversationId"/>
                </eb3:CollaborationInfo>
            </ebint:UserMessage>
        </ebint:RoutingInput>
        <eb3:Messaging S12:mustUnderstand="true" id="{concat('_ebmessaging_',generate-id())}">
            <xsl:apply-templates select="descendant-or-self::eb3:UserMessage"/>
        </eb3:Messaging>
    </xsl:template>

    <xd:doc>
        <xd:desc>There are two templates for <xd:i>eb3:Messaging</xd:i> element. This second
            template covers regular point-to-point messages.</xd:desc>
    </xd:doc>
    <xsl:template
        match="eb3:Messaging[not(
        @S12:role='http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh')]">
        <eb3:Messaging S12:mustUnderstand="true" id="{concat('_ebmessaging_',generate-id())}">
            <xsl:apply-templates select="descendant-or-self::eb3:UserMessage"/>
        </eb3:Messaging>
    </xsl:template>

    <xd:doc>
        <xd:desc>
            <xd:p>The AS4 receipt is generated based on <xd:i>eb3:UserMessage</xd:i> content.</xd:p>
            <xd:ul>
                <xd:li>A receipt for a signed AS4 message reference the message parts using
                        <xd:i>ds:Reference</xd:i>s in the WS-Security header of that message</xd:li>
                <xd:li>A receipt for an unsigned AS4 message references the message parts using
                        <xd:i>ebbp:MessagePartIdentifier</xd:i>s for the AS4 message structure
                    corresponding to the <xd:i>eb3:PartInfo</xd:i> elements in the received message. <xd:ul>
                        <xd:li>If the message is a SOAP-with-attachments structure, the MIME
                            part identifier for the root SOAP element is available in the
                                <xd:i>start</xd:i> parameter</xd:li>
                        <xd:li>If the message is a plain SOAP message, the SOAP envelop does not have a
                            separate part identifier. We use the <xd:i>eb3:MessageId</xd:i> as part 
                            identifier.</xd:li>
                    </xd:ul>
                </xd:li>
            </xd:ul>
        </xd:desc>
    </xd:doc>
    <xsl:template match="eb3:UserMessage">
        <eb3:SignalMessage>
            <eb3:MessageInfo>
                <eb3:Timestamp>
                    <xsl:value-of select="$timestamp"/>
                </eb3:Timestamp>
                <eb3:MessageId>
                    <xsl:value-of select="$messageid"/>
                </eb3:MessageId>
                <eb3:RefToMessageId>
                    <xsl:value-of select="descendant::eb3:MessageId"/>
                </eb3:RefToMessageId>
            </eb3:MessageInfo>
            <eb3:Receipt>
                <xsl:choose>
                    <xsl:when test="/S12:Envelope/S12:Header/wsse:Security/ds:Signature">
                        <ebbp:NonRepudiationInformation>
                            <xsl:apply-templates select="//ds:Reference"/>
                        </ebbp:NonRepudiationInformation>
                    </xsl:when>
                    <xsl:otherwise>
                        <ebbp:NonRepudiationInformation>
                            <xsl:choose>
                                <xsl:when test="$start != 'None'">
                                    <ebbp:MessagePartNRInformation>
                                        <ebbp:MessagePartIdentifier>
                                            <xsl:value-of select="$start"/>
                                        </ebbp:MessagePartIdentifier>
                                    </ebbp:MessagePartNRInformation>
                                </xsl:when>
                                <xsl:otherwise>
                                    <ebbp:MessagePartNRInformation>
                                        <ebbp:MessagePartIdentifier>
                                            <xsl:value-of select="descendant::eb3:MessageId"/>
                                        </ebbp:MessagePartIdentifier>
                                    </ebbp:MessagePartNRInformation>
                                </xsl:otherwise>
                            </xsl:choose>
                            <xsl:apply-templates select="//eb3:PartInfo"/>
                        </ebbp:NonRepudiationInformation>
                    </xsl:otherwise>
                </xsl:choose>
            </eb3:Receipt>
        </eb3:SignalMessage>
    </xsl:template>

    <xsl:template match="ds:Reference">
        <ebbp:MessagePartNRInformation>
            <xsl:copy-of select="current()"/>
        </ebbp:MessagePartNRInformation>
    </xsl:template>

    <xd:doc>
        <xd:desc>There are three templates for <xd:i>eb3:PartInfo</xd:i> elements. This first template
            covers MIME parts that are explicitly identified using an <xd:i>href</xd:i>
            attribute</xd:desc>
    </xd:doc>
    <xsl:template match="eb3:PartInfo[starts-with(@href,'cid:')]">
        <ebbp:MessagePartNRInformation>
            <ebbp:MessagePartIdentifier>
                <xsl:value-of select="substring-after(@href,'cid:')"/>
            </ebbp:MessagePartIdentifier>
        </ebbp:MessagePartNRInformation>
    </xsl:template>
    
    <xd:doc>
        <xd:desc>There are three templates for <xd:i>eb3:PartInfo</xd:i> elements. This second template
            covers other parts that are explicitly identified using an <xd:i>href</xd:i>
            attribute</xd:desc>
    </xd:doc>
    <xsl:template match="eb3:PartInfo[not(starts-with(@href,'cid:'))]">
        <ebbp:MessagePartNRInformation>
            <ebbp:MessagePartIdentifier>
                <xsl:value-of select="@href"/>
            </ebbp:MessagePartIdentifier>
        </ebbp:MessagePartNRInformation>
    </xsl:template>
    
    <xd:doc>
        <xd:desc>
            <xd:p>There are three templates for <xd:i>eb3:PartInfo</xd:i> elements. This third
                template covers parts with an omitted <xd:i>href</xd:i> attribute, which implicitly
                references a business document in the SOAP payload. The receipt implicitly reference
                this payload.</xd:p>
        </xd:desc>
    </xd:doc>
    <xsl:template match="eb3:PartInfo[not(@href)]"/>




</xsl:stylesheet>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]