Re: [ebxmlms-develop] Sending/receiving acknowledgements

[Patrick Y. <kc...@ce...>]

MessageIf I use one Request object per recipient, and if I don't want =
the outgoing URL to be included in the messages (e.g. I want to use DUNS =
number as the To/From Party ID), it may be convenient to use the "last =
resort" URL. As such, I don't need to implement any ToURLResolver and =
rely only on the "last resort" one.

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, April 29, 2003 7:23 AM
  Subject: RE: [ebxmlms-develop] Sending/receiving acknowledgements


  I use a single sender process to send all of the messages. =
Theoretically, I think I could use a single Request object to send each =
message (although at the moment, I use a new Request for each message).

  If I use a single Request to send all messages, it doesn't make any =
sense to have a "last resort" URL, because the messages are going to =
different recipients, and there is no sensible default URL. In fact, I =
specifically *don't* want a default in this case: what would that =
default be?

  If I use a new Request for each message, then I'm specifying the =
recipient in the To PartyId. If I get it wrong there, then I'll probably =
get it wrong in the Request as well.

  I can see an argument for leaving the URL in the Request for a one-off =
send, but  how often will that happen?

  PJDM
  --
  Peter Mayne
  Technology Consultant
  Spherion Technology Solutions
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
  T: 61 2 62689727  F: 61 2 62689777=20
    -----Original Message-----
    From: Patrick Yee [mailto:kc...@ce...]=20
    Sent: Monday, 28 April 2003 4:58 PM
    To: ebx...@li...
    Subject: Re: [ebxmlms-develop] Sending/receiving acknowledgements


    That URL is currently used as the last resort. When the Resolver =
installed cannot resolve to a valid URL, the MSH now will by default use =
the URL passed in from Request. So, we may have to think carefully =
before making that optional. What do you think?

    Regards, -Patrick


    Mayne, Peter wrote:

      I'll hold off my next nightly download until then.

      While we're on the subject of ToUrlResolver, it seems that if the =
To PartyId is, or can be resolved to, a legal URL, the message is sent =
to that URL. No great surprise in itself, but it appears to override the =
URL specified in the Request used to send the message.

      The Request constructor requires this URL, so I tried using null, =
but that doesn't work. After fixing the serialisation in =
MessageServiceHandlerConfig (writeObject() and readObject()), a =
NullPointerException gets thrown somewhere in MessageServiceHandler.

      Therefore, I'm passing in new URL(http://1.1.1.1/) in attempt to =
not confuse myself about which URL is being used as the recipient.

      As a low priority, could you consider accepting null for the =
toMshUrl in the Request constructor, to avoid confusion. (Or some other =
non-confusing solution.)

      Thanks.

      PJDM
      --
      Peter Mayne
      Technology Consultant
      Spherion Technology Solutions
      Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
      T: 61 2 62689727  F: 61 2 62689777=20
        -----Original Message-----
        From: Patrick Yee [mailto:kc...@ce...]=20
        Sent: Monday, 28 April 2003 10:46 AM
        To: ebx...@li...
        Subject: Re: [ebxmlms-develop] Sending/receiving =
acknowledgements


        Yes we are working on that also, and we'll keep you informed in =
the mailing list.=20
        -Patrick

        Mayne, Peter wrote:

          Excellent * 2. :-)

          Will you be adding an equivalent ToPublicKeyResolver, for =
signed messages that don't have the certificates included? (See my =
emails last week.)

          PJDM
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,=20
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=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.


  ------------------------------------------------------- This sf.net =
email is sponsored by:ThinkGeek Welcome to geek heaven. =
http://thinkgeek.com/sf _______________________________________________ =
ebxmlms-develop mailing list ebx...@li... =
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop