RE: [ebxmlms-develop] Hermes 1.0 my remarks

[Ronald v. K. <rv...@ab...>]

 

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: donderdag 10 juli 2003 2:00
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Hermes 1.0 my remarks


That's why it requires more thought. :-) AckRequested,
DuplicateElimination are physically specified in the SOAPMessage, but
RetryInterval, Retries aren't.
 
[Ronald van Kuijk]
Sorry I partly misunderstood you.(its late here, 02:35 AM, sleep is
taking over) You are right.
 
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.
[Ronald van Kuijk]
Yes that is the way it should work. Then a requirement for Hermes 2.0
could be the last 2 line of 8.5.3 of the ebTA spec:
 
    The ebXML Messaging Service SHALL help facilitate the Interface to
an ebXML Registry. 
 
with my addition: Including cpa negotiation.
 
Do you, or anybody else , know of libraries that can generate the values
of elements in an ebxml envelop based on a cpa  (or better yet, 2 cpp's)
?
 
Ronald
 
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
<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.