Re: [ebxmlms-develop] Hermes 1.0 my remarks

[pykoon <py...@ce...>]

Dear all,
Please note in the CPA Specification, the AckRequested, 
DuplicateElimination value can be defined as "perMessage", which the 
user should have to specify whether it needs AckRequested and 
DuplicateElimination. Therefore they should know about it if such CPA 
occurs.

Regards,
Bob Koon

Mayne, Peter wrote:

> That's why it requires more thought. :-) AckRequested, 
> DuplicateElimination are physically specified in the SOAPMessage, but 
> RetryInterval, Retries aren't.
>
>  
>
> My current model has a central Sender process that is the funnel point 
> for outgoing messages. A client that wants to send a message creates 
> its payload, and tells the Sender (via JMS) "send message type X, 
> using CPA Y, with this payload Z". The clients have no concept of an 
> EbxmlMessage object, or AckRequested, or RetryInterval, etc. And why 
> should they, since all that belongs in the CPA.
>
>  
>
> PJDM
>
> --
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
>
>     -----Original Message-----
>     From: Ronald van Kuijk [mailto:rv...@ab...]
>     Sent: Thursday, 10 July 2003 9:47 AM
>     To: 'ebx...@li...'
>     Subject: RE: [ebxmlms-develop] Hermes 1.0 my remarks
>
>     Correct me if i'm wrong, but aren't RetryInterval, Retries etc as
>     much part of the message as SyncReply? And aren't AckRequested,
>     DuplicateElimination not also defined in the CPA (E.5.2.2), just
>     as role, service, action etc....
>
>      
>
>     This make the 'this is CPA, this is Message' discussion not clearer.
>
>      
>
>     I agree that the sending MSH should (or must? ;-)) have knowledge
>     of the CPA. I'll look into what the ebXML TA says about this? (
>     http://www.ebxml.org/specs/ebTA.pdf )
>
>      
>
>     Ronald
>
>         -----Oorspronkelijk bericht-----
>         Van: Mayne, Peter [mailto:Pet...@ap...]
>         Verzonden: donderdag 10 juli 2003 1:17
>         Aan: 'ebx...@li...'
>         Onderwerp: RE: [ebxmlms-develop] Hermes 1.0 my remarks
>
>         I said:
>
>          
>
>         I think parameters should be carefully classified. Those that
>         are part of a message (AckRequested, DuplicateElimination,
>         etc) should be set in the EbxmlMessage. Those that are part of
>         the CPA (retries, retry interval, etc), and are *not* part of
>         the message, or of an individual send(), should *not* be set
>         in the message or as send() parameters. Instead, they should
>         be provided by the CpaResolver.
>
>         This requires some more thought. For instance, even though
>         syncReply is part of the message, it is specified in the CPA,
>         so a client shouldn't have to set it.
>
>          
>
>         Furthermore, the spec says "This element MUST NOT be used to
>         override the value of syncReplyMode in the CPA . If the value
>         of syncReplyMode is none and a SyncReply element is present,
>         the Receiving MSH should issue an error with errorCode of
>         Inconsistent and a severity of Error ."
>
>          
>
>         To check incoming messages, the MSH must have access to the
>         CPA. Therefore, it makes sense that the MSH should have access
>         to the CPA to build outgoing messages as well.
>
>          
>
>         PJDM
>
>         --
>         Peter Mayne
>         Technology Consultant
>         Spherion Technology Solutions
>         Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
>         T: 61 2 62689727  F: 61 2 62689777
>
>The information contained in this email and any attachments to it:
>
>(a) may be confidential and if you are not the intended recipient, any interference with, 
>use, disclosure or copying of this material is unauthorised and prohibited; and
>
>(b) may contain personal information of the recipient and/or the sender as defined 
>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>collect, hold and use such information and any personal information contained in a 
>response to this email, for any reasonable purpose in the ordinary course of 
>Spherion's 
>business, including forwarding this email internally or disclosing it to a third party. All 
>personal information collected by Spherion will be handled in accordance with 
>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>sender and delete it.
>
>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>this email and any attachments without first entering into a contractual agreement with 
>Spherion. You further agree not to divulge any information contained in this document 
>to any person(s) or entities without the express permission of Spherion.
>
>