ebxmlms-develop — Development discussions

[ebxmlms-develop] Re: SOAPException: unable to internalize message (invalid content type: text/html)

[Gait B. <gai...@ti...>]

Hi Jason,

 this is the message I used to get from SAAJ on HTTP responses before I
plugged an extra try catch block. Reason for the error: SAAJ was built for
synchronous HTTP messaging and expects a SOAP message (with content type
text/xml) coming back on the HTTP Response when sending something out. But
since ebXML defaults to async messaging, you can not rely on a SOAP message
coming back on any but the 500 response. In fact, any 2xx response must be
accepted as a successful send (unless you force sync acks). To fix it, you
actually need to patch SAAJ, see the copy of that message below.

Kind Regards, Gait.

-- my original posted fix -------
Hi,

I've observed the same problem while doing some tests against other
receivers. In my case, the other party was responding with a 200 OK message,
and a nice HTML document telling me my message was well received. Very
friendly, but not what the Sun JAXM implementation was expecting. According
to the specs, the response is valid unless you're running synchronous
communications. In fact, any 2XX response is fine when using async
responses. So I ended up patching JAXM to catch the error on the response
message.
Get JAXM 1.1 from SUN, and change line 333 of
jaxm1.1-scsl\jaxm-ri\src\com\sun\xml\messaging\saaj\client\p2p\HttpSoapConne
ction.java to look like:

   try {
             response = messageFactory.createMessage(headers, in);
   } catch (SOAPException ex) {
    if( responseCode== HttpURLConnection.HTTP_INTERNAL_ERROR ) {
     throw ex;
    }
    response = null;
   }

then rebuild jaxm, and copy the patched saaj-ri.jar into your ebxmlms. That
should do the trick.
Of course, this will also catch the error while doing synchronous
communications, which is probably not what we want.
As an aside, be aware that the createMessage call will print a stack trace
before the error is caught, so don't worry if you still get the error trace
in the tomcat console.

--Gait.

----------

 ----- Original Message ----- 
 From: "Jason van Zyl" <ja...@ze...>
 To: <ebx...@li...>
 Sent: Tuesday, May 06, 2003 7:26 PM
 Subject: [ebxmlms-develop] SOAPException: unable to internalize message
 (invalid content type: text/html)


 > Hi,
 >
 > I see some mention of this being fixed and I tried the latest nightly
 > download and I'm getting the error. CVS has been dead all day from where
 > I am. Has this issue been resolved?
 >
 > Maybe it is something I have to look for in my setup, I'm using Jetty
 > not Tomcat.
 >
 > -- 
 > jvz.
 >
> > Jason van Zyl
> > ja...@ze...
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> >   -- Jacques Ellul, The Technological Society
> >
> >
> >
> > -------------------------------------------------------
> > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> > The only event dedicated to issues related to Linux enterprise solutions
> > www.enterpriselinuxforum.com
> >
> > _______________________________________________
> > ebxmlms-develop mailing list
> > ebx...@li...
> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

RE: [ebxmlms-develop] SOAPException: unable to internalize messag e (invalid content type: text/html)

[Jason v. Z. <ja...@ze...>]

On Tue, 2003-05-06 at 18:50, Mayne, Peter wrote:
> From bitter experience, this is a generic exception that is thrown
> whenever it gets the chance, even if the content type is in fact
> text/html. For instance, if the server can't be reached, it must be an
> invalid content type.
> 
> Another reason to throw out the Sun rubbish and use AXIS instead.

Indeed.

Is there any indication anywhere as to what the real error is or is
there a little spot I can stick in an e.printStackTrace() to actually
see if it's a configuration error.

Where is the test suite? Even just seeing the test suite would be
greatly helpful in trying to track down problems and to help apply send
patches and know that they will work in an environment other than my
own.

> 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: Jason van Zyl [mailto:ja...@ze...] 
> > Sent: Wednesday, 7 May 2003 3:26 AM
> > To: ebx...@li...
> > Subject: [ebxmlms-develop] SOAPException: unable to 
> > internalize message (invalid content type: text/html)
> > 
> > 
> > Hi,
> > 
> > I see some mention of this being fixed and I tried the latest
> nightly
> > download and I'm getting the error. CVS has been dead all day 
> > from where
> > I am. Has this issue been resolved? 
> > 
> > Maybe it is something I have to look for in my setup, I'm using
> Jetty
> > not Tomcat.
> > 
> > -- 
> > jvz.
> > 
> > Jason van Zyl
> > ja...@ze...
> > http://tambora.zenplex.org
> > 
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >   
> >   -- Jacques Ellul, The Technological Society
> > 
> > 
> > 
> > -------------------------------------------------------
> > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
> Clara
> > The only event dedicated to issues related to Linux 
> > enterprise solutions
> > www.enterpriselinuxforum.com
> > 
> > _______________________________________________
> > ebxmlms-develop mailing list
> > ebx...@li...
> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
> > 
> 
> 
> 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.
-- 
jvz.

Jason van Zyl
ja...@ze...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

[ebxmlms-develop] SOAPException: unable to internalize message (invalid content type: text/html)

[Jason v. Z. <ja...@ze...>]

Hi,

I see some mention of this being fixed and I tried the latest nightly
download and I'm getting the error. CVS has been dead all day from where
I am. Has this issue been resolved? 

Maybe it is something I have to look for in my setup, I'm using Jetty
not Tomcat.

-- 
jvz.

Jason van Zyl
ja...@ze...
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society

Re: [ebxmlms-develop] troubles with signed acks (still)

[Gait B. <gai...@ti...>]

Hi NG,

I would still strongly propose to pass the message to xmlsec as a string,
simply to avoid issues with JAXM and dom4j. In fact, for received messages I
believe it's the only way. both JAXM and Axis do 'something' that renders
the received message different from the one passed to xmlsec. For
verification, you must pass in the received data as is to have any chance of
succesful verification. It's not a big deal to plug in a call to
getContent() and rewrapping xml sec to support string based verification,
and will solve at least that part of the problem.
But even for outgoing messages, I'd still propose to first render the
message and then pass it on to xmlsec for signing. If not, you need to be
sure that whatever is passed to xmlsec is identical to what's sent out on
the wire, otherwise the hash will mismatch and verification is bound to fail
again.

just my EUR 0.02.

--Gait.

----- Original Message ----- 
From: "Ng Chi Yuen [Cyng]" <cy...@cs...>
To: <ebx...@li...>
Sent: Monday, May 05, 2003 5:47 AM
Subject: RE: [ebxmlms-develop] troubles with signed acks (still)


> Hello,
>
> > > one issue is with the soap namespace prefix. I've nailed this down to
the
> > > fact that hermes passes the doc to xmlsec as a DOM tree, rather than
as a
> > > string. When passing this to xmlsec, reserialization uses SAAJ, which
> > > hardcodes 'soap-env' as the prefix, while the others use SOAP. this
> > > causes a digest mismatch. I've solved this (for now) by swapping to
SOAP
> > > as the prefix in SAAJ and Hermes, but we need to change this so that
the
> > > actual streamed data is passed to XMLSignature in xmlsec.
>
> > Our business partner's incoming messages are not being validated, and
I'm
> > wondering if it's because they use "SOAP-ENV" as a prefix. I'll try
> > hacking Hermes to use "SOAP-ENV" as well.
>
>
>         Let me summarize the findings on xmlsec, JAXM and Axis so far.
>
> JAXM with xmlsec:
>     - Hermes sends signed message : the signed message should be correct
>       *if* xmlsec's algorithms such as digest, canonicalization are
>       implemented correctly, i.e., it should be verified by non-Hermes
>       MSH. The reasons why I say so are that: (1) JAXM uses "soap-env" as
>       the SOAP envelope prefix no matter what is set in
>       NAMESPACE_PREFIX_SOAP_ENVELOPE. After the transformation from JAXM
>       tree (dom4j) to DOM tree, every element nodes and text nodes should
>       be preserved (I ever examined) such that xmlsec should sign the
>       correct message as I also followed exactly the signing example.
>       (2) After signing, Signature element from DOM tree is re-inserted
back
>       to JAXM tree. I examined the serialization of JAXM tree should look
>       the same as the DOM tree after canonicalization. So I expect the
signed
>       message can be verified by non-Hermes MSH.
>
>     - Hermes receives signed message : If the received signed message is
>       generated by Hermes, that's ok for sure. Otherwise, problems happen.
>       If the signed message, say, has "SOAP-ENV" as envelope prefix, JAXM
>       always represents this as "soap-env" internally. No matter the JAXM
>       tree is transformed or printed out as String, the message changes to
>       use "soap-env" prefix so that verification must fail. Currently, I
>       have no idea to patch anything at all. The conclusion seems to be
that
>       JAXM with xmlsec fails to verify non-Hermes messages.
>
> Axis with xmlsec:
>     - Hermes sends signed message : everything is preserved after
>       transformation from Axis tree to DOM, and after re-insertion of
>       Signature from DOM to Axis tree, i.e., the siging process should be
>       correct. However, when the message is serialized by calling
writeTo()
>       finally, the Axis tree is beautified by adding extra "\n" and spaces
>       which obviously voids the signature. Currently, I don't know how to
>       disable the Axis setPretty() function. I ever asked in Axis mailing
>       list and it seems that some tricky ways of calling
org.apache.xxx.xxx
>       should be called to control the formatting but my feeling is that
this
>       will be very implementation dependent and one is not calling the
>       standard JAXM interface. (I ever find other bugs in Axis that I will
have
>       to report soon.) Another idea is to serialize the unsigned the
message
>       first as String and then sign this String. Hopefully, after signing,
>       the serialization stream may look identical before signing. I
haven't
>       tested this but this is quite hacked as well in my personal view.
>
>     - Hermes receives signed message : For non-Hermes signed message, the
>       Axis tree preserves all namepsace prefixes no matter for SOAP
envelope
>       or Signature, i.e., it seems ok for you to use "SOAP-ENV" or "dsig".
>       I use your dumped sample and certificate to test. Sigh.... digest
>       verification for URI="" and URI="xxx" is ok while the signature
values
>       fails. I don't know why yet.
>
>
>         You see. Really "good" enough to use and investigate these kinds
of
> libraries. I am very sorry that this causes problems to your testing or
> productions cases. But the way is really hard. Currently, I just focus on
> Axis and I just hope one solution works first.
>
> Regards,
> CY
>
> --------------------------------------------------------------------------
--
> Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
> Technology Officer,
> Centre for E-Commerce Infrastructure Development,
> The University of Hong Kong
> --------------------------------------------------------------------------
--
>
>
>
> -------------------------------------------------------
> 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

RE: [ebxmlms-develop] troubles with signed acks (still)

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

I second this. JAXM originally was a 'soap-api' and a messaging-api  but the
soap-api was split of as saaj and the remaining messaging api has little
value. At least that is hat is what we've seen in small projects.
 
Ronald
 
p.s. sorry i haven't looked into AXIS/JAXM more,  but I've been real busy on
internal projects

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: maandag 5 mei 2003 6:56
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] troubles with signed acks (still)



>         You see. Really "good" enough to use and investigate these kinds
of 
> libraries. I am very sorry that this causes problems to your testing or 
> productions cases. But the way is really hard. Currently, I just focus on 
> Axis and I just hope one solution works first. 

If you forget about JAXM and just concentrate on AXIS and get it to work,
that's fine by me. :-) The Sun classes have other problems that AXIS
hopefully fixes.

Did you see the response from Thomas Sandholm? 

> We had the same problem with digital signatures so I added a call to
SOAPBody called disableFormatting(). > That did it for us.

> /Thomas 

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.

RE: [ebxmlms-develop] troubles with signed acks (still)

[Ng C. Y. [Cyng] <cy...@cs...>]

Hello,

> > one issue is with the soap namespace prefix. I've nailed this down to the
> > fact that hermes passes the doc to xmlsec as a DOM tree, rather than as a
> > string. When passing this to xmlsec, reserialization uses SAAJ, which
> > hardcodes 'soap-env' as the prefix, while the others use SOAP. this
> > causes a digest mismatch. I've solved this (for now) by swapping to SOAP
> > as the prefix in SAAJ and Hermes, but we need to change this so that the
> > actual streamed data is passed to XMLSignature in xmlsec.

> Our business partner's incoming messages are not being validated, and I'm
> wondering if it's because they use "SOAP-ENV" as a prefix. I'll try
> hacking Hermes to use "SOAP-ENV" as well.


        Let me summarize the findings on xmlsec, JAXM and Axis so far.

JAXM with xmlsec:
    - Hermes sends signed message : the signed message should be correct
      *if* xmlsec's algorithms such as digest, canonicalization are
      implemented correctly, i.e., it should be verified by non-Hermes
      MSH. The reasons why I say so are that: (1) JAXM uses "soap-env" as
      the SOAP envelope prefix no matter what is set in
      NAMESPACE_PREFIX_SOAP_ENVELOPE. After the transformation from JAXM
      tree (dom4j) to DOM tree, every element nodes and text nodes should
      be preserved (I ever examined) such that xmlsec should sign the
      correct message as I also followed exactly the signing example.
      (2) After signing, Signature element from DOM tree is re-inserted back
      to JAXM tree. I examined the serialization of JAXM tree should look
      the same as the DOM tree after canonicalization. So I expect the signed
      message can be verified by non-Hermes MSH.

    - Hermes receives signed message : If the received signed message is
      generated by Hermes, that's ok for sure. Otherwise, problems happen.
      If the signed message, say, has "SOAP-ENV" as envelope prefix, JAXM
      always represents this as "soap-env" internally. No matter the JAXM
      tree is transformed or printed out as String, the message changes to
      use "soap-env" prefix so that verification must fail. Currently, I
      have no idea to patch anything at all. The conclusion seems to be that
      JAXM with xmlsec fails to verify non-Hermes messages.

Axis with xmlsec:
    - Hermes sends signed message : everything is preserved after
      transformation from Axis tree to DOM, and after re-insertion of
      Signature from DOM to Axis tree, i.e., the siging process should be
      correct. However, when the message is serialized by calling writeTo()
      finally, the Axis tree is beautified by adding extra "\n" and spaces
      which obviously voids the signature. Currently, I don't know how to
      disable the Axis setPretty() function. I ever asked in Axis mailing
      list and it seems that some tricky ways of calling org.apache.xxx.xxx
      should be called to control the formatting but my feeling is that this
      will be very implementation dependent and one is not calling the
      standard JAXM interface. (I ever find other bugs in Axis that I will have
      to report soon.) Another idea is to serialize the unsigned the message
      first as String and then sign this String. Hopefully, after signing,
      the serialization stream may look identical before signing. I haven't
      tested this but this is quite hacked as well in my personal view.

    - Hermes receives signed message : For non-Hermes signed message, the
      Axis tree preserves all namepsace prefixes no matter for SOAP envelope
      or Signature, i.e., it seems ok for you to use "SOAP-ENV" or "dsig".
      I use your dumped sample and certificate to test. Sigh.... digest
      verification for URI="" and URI="xxx" is ok while the signature values
      fails. I don't know why yet.


        You see. Really "good" enough to use and investigate these kinds of
libraries. I am very sorry that this causes problems to your testing or
productions cases. But the way is really hard. Currently, I just focus on
Axis and I just hope one solution works first.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] Sending/receiving acknowledgements

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

MessageIn this case, maybe we can make it possible to pass in "null" as =
toMSHURL. -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 30, 2003 6:53 AM
  Subject: RE: [ebxmlms-develop] Sending/receiving acknowledgements


  I don't have a problem with that at all. However, I should have the =
option of not providing a URL to the Request, because in many cases it =
is redundant and confusing.

  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: Tuesday, 29 April 2003 7:50 PM
    To: ebx...@li...
    Subject: Re: [ebxmlms-develop] Sending/receiving acknowledgements


    If 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
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.

Re: [ebxmlms-develop] Sending/receiving acknowledgements

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

MessageI mean the programming model of Hermes is somehow biased to CPA. =
We will probably have different CPA, i.e. different sets of parameters, =
per trade partner. The programming model tends to mandate one Request =
per CPA. In other words, we probably don't have a CPA which drives a =
"global, universal" receiver.

The routing mechanism is not rely on synchronous/asynchronous nature. =
Instead, it's the nature of the status response. When there are many =
applications sharing the MSH server, the status response message is =
meaningful *only* to the sender application. So, we try to route the =
response to the sender only.

Regards, -Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 30, 2003 7:37 AM
  Subject: RE: [ebxmlms-develop] Sending/receiving acknowledgements


  Sorry, I don't understand this.

  The backend shouldn't care if a message is received synchronously or =
asynchronously. Why shouldn't synchronous messages be routed in the same =
way that asynchronous messages are?

  What do you mean by "separated receiver programs per trade partner"?

  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: Tuesday, 29 April 2003 8:09 PM
    To: ebx...@li...
    Subject: Re: [ebxmlms-develop] Sending/receiving acknowledgements


    Unfortunately, the status response message will not go through the =
message routing mechanism. When we view it using CPA perspective, it is =
more common to have separated receiver programs per trade partner.

    Regards, -Patrick

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


      <quote>=20
      2. We have done the flowing the ACK to message listener long time =
ago.. :-) To use it, please turn on the "PositiveAcknowledgment" option =
in msh.properties.xml. When turned on and upon receiving the MSH-level =
ACK, Hermes will generate a StatusResponse message to message listener, =
with the RefToMessageID pointing to the referenced message. Prophetic =
feature, huh? ;-)

      </quote>=20

      I would never have figured this out from the comment in =
msh.properties.xml.=20

      I set this to true, and send a message using Loopback, and it =
works, but the StatusResponse message is being received by Loopback =
(which is using ApplicationContext("_","_","_","_")), instead of my =
Listener (ApplicationContext("*","*","*","*")).

      PJDM=20
      --=20
      Peter Mayne=20
      Technology Consultant=20
      Spherion Technology Solutions=20
      Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
      T: 61 2 62689727  F: 61 2 62689777=20

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.

Re: [ebxmlms-develop] Sending/receiving acknowledgements

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

RE: [ebxmlms-develop] Sending/receiving acknowledgementsUnfortunately, =
the status response message will not go through the message routing =
mechanism. When we view it using CPA perspective, it is more common to =
have separated receiver programs per trade partner.

Regards, -Patrick

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


  <quote>=20
  2. We have done the flowing the ACK to message listener long time =
ago.. :-) To use it, please turn on the "PositiveAcknowledgment" option =
in msh.properties.xml. When turned on and upon receiving the MSH-level =
ACK, Hermes will generate a StatusResponse message to message listener, =
with the RefToMessageID pointing to the referenced message. Prophetic =
feature, huh? ;-)

  </quote>=20

  I would never have figured this out from the comment in =
msh.properties.xml.=20

  I set this to true, and send a message using Loopback, and it works, =
but the StatusResponse message is being received by Loopback (which is =
using ApplicationContext("_","_","_","_")), instead of my Listener =
(ApplicationContext("*","*","*","*")).

  PJDM=20
  --=20
  Peter Mayne=20
  Technology Consultant=20
  Spherion Technology Solutions=20
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
  T: 61 2 62689727  F: 61 2 62689777=20

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.

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

Re: [ebxmlms-develop] bug alert

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

Hi Gait,

Thanks for reporting. We have added the change to the CVS source tree.

Regards, -Patrick
  ----- Original Message -----=20
  From: Gait Boxman=20
  To: ebx...@li...=20
  Sent: Monday, April 28, 2003 7:42 PM
  Subject: [ebxmlms-develop] bug alert


  Hi team,=20

  rest assured, only a small one :-)

  while preparing for the interop demo for XML Europe, we ran into a bug =
with error messages.
  It turns out the Action is not set properly on the error message in =
the validation exception, which must be MessageError according to =
section 4.2.4.3. from ebMS 2. See below for the diff on the fix.

  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  RCS file: =
/cvsroot/ebxmlms/ebxmlms/src/hk/hku/cecid/phoenix/message/packaging/valid=
ation/EbxmlValidationException.java,v

  retrieving revision 1.10

  diff -r1.10 EbxmlValidationException.java

  143a144,150

  > /**

  > * Error action reserved for standalone errors described in ebXML =
Message=20

  > * Service Specification [ebMSS 4.2.4.3].

  > */

  > public static final String ERROR_ACTION =3D

  > "MessageError";

  >=20

  216c223

  < SERVICE, errorCode, messageId, timeStamp);

  ---

  > SERVICE, ERROR_ACTION, messageId, timeStamp);

  *****CVS exited normally with code 1*****



  regards, Gait.

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Gait Boxman
  Manager Advanced Technology & Standards
  TIE Product Development BV
  Amsterdam, The Netherlands
  Tel: +31 20 658 9091  Fax: +31 20 658 9945
  E-mail: gai...@ti...  WWW: www.TIEglobal.com
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ebxmlms-develop] bug alert

[Gait B. <gai...@ti...>]

Hi team,=20

rest assured, only a small one :-)

while preparing for the interop demo for XML Europe, we ran into a bug =
with error messages.
It turns out the Action is not set properly on the error message in the =
validation exception, which must be MessageError according to section =
4.2.4.3. from ebMS 2. See below for the diff on the fix.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RCS file: =
/cvsroot/ebxmlms/ebxmlms/src/hk/hku/cecid/phoenix/message/packaging/valid=
ation/EbxmlValidationException.java,v

retrieving revision 1.10

diff -r1.10 EbxmlValidationException.java

143a144,150

> /**

> * Error action reserved for standalone errors described in ebXML =
Message=20

> * Service Specification [ebMSS 4.2.4.3].

> */

> public static final String ERROR_ACTION =3D

> "MessageError";

>=20

216c223

< SERVICE, errorCode, messageId, timeStamp);

---

> SERVICE, ERROR_ACTION, messageId, timeStamp);

*****CVS exited normally with code 1*****



regards, Gait.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gait Boxman
Manager Advanced Technology & Standards
TIE Product Development BV
Amsterdam, The Netherlands
Tel: +31 20 658 9091  Fax: +31 20 658 9945
E-mail: gai...@ti...  WWW: www.TIEglobal.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: [ebxmlms-develop] Sending/receiving acknowledgements

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
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?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>Message</title>
  <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
  <div><span class="782365603-28042003"><font face="Arial" size="2">I'll
hold off my next nightly download until then.</font></span></div>
  <div><span class="782365603-28042003"></span>&nbsp;</div>
  <div><span class="782365603-28042003"><font face="Arial" size="2">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.</font></span></div>
  <div><span class="782365603-28042003"></span>&nbsp;</div>
  <div><span class="782365603-28042003"><font face="Arial" size="2">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.</font></span></div>
  <div><span class="782365603-28042003"></span>&nbsp;</div>
  <div><span class="782365603-28042003"><font face="Arial" size="2">Therefore,
I'm passing in new URL(</font><a href="http://1.1.1.1/"><font
 face="Arial" color="#000000" size="2">http://1.1.1.1/</font></a><font
 face="Arial" size="2">)&nbsp;</font></span><span class="782365603-28042003"><font
 face="Arial" size="2">in attempt to not confuse myself about which URL
is being used as the recipient.</font></span></div>
  <div><span class="782365603-28042003"></span>&nbsp;</div>
  <div><span class="782365603-28042003"><font face="Arial" size="2">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.)</font></span></div>
  <div><span class="782365603-28042003"></span>&nbsp;</div>
  <div><span class="782365603-28042003"><font face="Arial" size="2">Thanks.</font></span></div>
  <div>&nbsp;</div>
  <div><span class="782365603-28042003"><font face="Arial" size="2">PJDM<br>
  </font></span><font size="2">--<br>
Peter Mayne<br>
Technology Consultant<br>
Spherion Technology Solutions<br>
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602<br>
T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" lang="en-us" dir="ltr"
 align="left"><font face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> Patrick Yee   [<a class="moz-txt-link-freetext" href="mailto:kc...@ce...">mailto:kc...@ce...</a>] <br>
    <b>Sent:</b> Monday, 28 April 2003 10:46   AM<br>
    <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a><br>
    <b>Subject:</b> Re:   [ebxmlms-develop] Sending/receiving
acknowledgements<br>
    <br>
    </font></div>
Yes   we are working on that also, and we'll keep you informed in the
mailing list. <br>
-Patrick<br>
    <br>
Mayne, Peter wrote:<br>
    <blockquote
 cite="mid...@s-..."
 type="cite">
      <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
      <style></style>
      <div><span class="049581523-27042003"><font face="Arial" size="2">Excellent&nbsp;*
2. :-)</font></span></div>
      <div>&nbsp;</div>
      <div><span class="049581523-27042003"><font face="Arial" size="2">Will
you be     adding an equivalent ToPublicKeyResolver, for signed
messages that don't     have the certificates included? (See my emails
last     week.)</font></span></div>
      <div><span class="049581523-27042003"></span>&nbsp;</div>
      <div><span class="049581523-27042003"><font face="Arial" size="2">PJDM</font></span></div>
    </blockquote>
  </blockquote>
  <font size="3" color="BLUE">
  <pre>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.


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] Sending/receiving acknowledgements

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Yes we are working on that also, and we'll keep you informed in the
mailing list. <br>
-Patrick<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>Message</title>
  <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
  <style></style>
  <div><span class="049581523-27042003"><font face="Arial" size="2">Excellent&nbsp;*
2. :-)</font></span></div>
  <div>&nbsp;</div>
  <div><span class="049581523-27042003"><font face="Arial" size="2">Will
you be adding an equivalent ToPublicKeyResolver, for signed messages
that don't have the certificates included? (See my emails last week.)</font></span></div>
  <div><span class="049581523-27042003"></span>&nbsp;</div>
  <div><span class="049581523-27042003"><font face="Arial" size="2">PJDM</font></span></div>
  <div><span class="049581523-27042003"></span><font size="2">--<br>
Peter Mayne<br>
Technology Consultant<br>
Spherion Technology Solutions<br>
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602<br>
T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </div>
  <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" lang="en-us" dir="ltr"
 align="left"><font face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> Patrick Yee   [<a class="moz-txt-link-freetext" href="mailto:kc...@ce...">mailto:kc...@ce...</a>] <br>
    <b>Sent:</b> Thursday, 24 April 2003 8:28   PM<br>
    <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a><br>
    <b>Subject:</b> Re:   [ebxmlms-develop] Sending/receiving
acknowledgements<br>
    <br>
    </font></div>
    <div><font size="2">Sorry for our late response.. you know, we
hardly can find a   break to breath recently.. :-(</font></div>
    <div>&nbsp;</div>
    <div><font size="2">1. We have added the ToUrlResolver interface
(similar to   Peter's suggestion) in the nightly build. We also added
an implementation   ToUrlResolverImpl. This implementation looks for
URL from the ToPartyID. Of   course, you can make your own
implementation (to look up LDAP, etc.) and   install&nbsp;the resolver&nbsp;in
the msh.properties.xml. (Yes, this is a   server-wide setting..., any
objection?)</font></div>
    <div>&nbsp;</div>
    <div><font size="2">2. We have done the flowing the ACK to message
listener long   time ago.. :-) To use it, please turn on the
"PositiveAcknowledgment" option   in msh.properties.xml. When turned
on and upon receiving the MSH-level ACK,   Hermes will generate a
StatusResponse message to message listener, with the   RefToMessageID
pointing to the referenced message. Prophetic feature, huh?   ;-)</font></div>
    <div>&nbsp;</div>
    <div><font size="2">Regards, -Patrick</font></div>
    <div>&nbsp;</div>
    <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">-----
Original Message ----- </div>
      <div
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-inline-policy: initial; -moz-background-origin: initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>From:</b> <a
 title="Pet...@ap..."
 href="mailto:Pet...@ap...">Mayne, Peter</a> </div>
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>To:</b> <a
 title="ebx...@li..."
 href="mailto:%27e...@li...%27">'ebx...@li...'</a> </div>
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Sent:</b>
Tuesday, April 22, 2003 1:00     PM</div>
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Subject:</b>
[ebxmlms-develop] Sending/receiving acknowledgements</div>
      <div><br>
      </div>
      <p><font size="2">A two part question on acknowledgements.</font> </p>
      <p><font size="2">First, I'd like to check some logic.</font> </p>
      <p><font size="2">The party ids of our messages are not of the
form</font> </p>
      <p><font size="2"><a class="moz-txt-link-rfc2396E" href="eb:From">&lt;eb:From&gt;</a></font> <br>
      <font size="2">&nbsp;     <a class="moz-txt-link-rfc2396E" href="eb:PartyId">&lt;eb:PartyId&gt;</a><a href="http://from/msh/"
 target="_blank">http://from/msh/</a>&lt;/<a class="moz-txt-link-freetext" href="eb:PartyId">eb:PartyId</a>&gt; </font><br>
      <font size="2">&lt;/<a class="moz-txt-link-freetext" href="eb:From">eb:From</a>&gt;</font> </p>
      <p><font size="2">Instead, they look like this:</font> </p>
      <p><font size="2"><a class="moz-txt-link-rfc2396E" href="eb:From">&lt;eb:From&gt;</a></font> <br>
      <font size="2">&nbsp;     &lt;<a class="moz-txt-link-freetext" href="eb:PartyId">eb:PartyId</a>
<a class="moz-txt-link-freetext" href="eb:type=">eb:type=</a>"ABN"&gt;123456789&lt;/<a class="moz-txt-link-freetext" href="eb:PartyId">eb:PartyId</a>&gt; </font><br>
      <font size="2">&nbsp; <a class="moz-txt-link-rfc2396E" href="eb:Role">&lt;eb:Role&gt;</a>Buyer&lt;/<a class="moz-txt-link-freetext" href="eb:Role">eb:Role</a>&gt; </font><br>
      <font size="2">&lt;/<a class="moz-txt-link-freetext" href="eb:From">eb:From</a>&gt;</font> </p>
      <p><font size="2">Normally, this doesn't seem to matter. However,
when an     acknowledgement is requested, MessageProcessor attempts to
build the URL of     the message recipient from the From PartyId. In
our case, this is doomed to     failure, and the acknowledgement
message is sent to the local Hermes     instead.</font></p>
      <p><font size="2">Is this correct? If so, I'll have to add some
more code to     resolve a destination URL from a partyid, and fix
MessageProcessor to use     it.</font></p>
      <p><font size="2">Second question: when an acknowledgement
message is     received, Hermes appears to swallow it, and doesn't
send it on to my     listener. How can I tell if an acknowledgement
has arrived?</font></p>
      <p><font size="2">Thanks.</font> </p>
      <p><font size="2">PJDM</font> <br>
      <font size="2">-- </font><br>
      <font size="2">Peter Mayne</font> <br>
      <font size="2">Technology Consultant</font> <br>
      <font size="2">Spherion Technology Solutions</font> <br>
      <font size="2">Level     1, 243 Northbourne Avenue, Lyneham,
ACT, 2602</font> <br>
      <font size="2">T: 61     2 62689727&nbsp; F: 61 2 62689777</font> </p>
      <font color="blue" size="3">
      <pre>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.


      </pre>
      </font></blockquote>
  </blockquote>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] Sending/receiving acknowledgements

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

Sending/receiving acknowledgementsSorry for our late response.. you =
know, we hardly can find a break to breath recently.. :-(

1. We have added the ToUrlResolver interface (similar to Peter's =
suggestion) in the nightly build. We also added an implementation =
ToUrlResolverImpl. This implementation looks for URL from the ToPartyID. =
Of course, you can make your own implementation (to look up LDAP, etc.) =
and install the resolver in the msh.properties.xml. (Yes, this is a =
server-wide setting..., any objection?)

2. We have done the flowing the ACK to message listener long time ago.. =
:-) To use it, please turn on the "PositiveAcknowledgment" option in =
msh.properties.xml. When turned on and upon receiving the MSH-level ACK, =
Hermes will generate a StatusResponse message to message listener, with =
the RefToMessageID pointing to the referenced message. Prophetic =
feature, huh? ;-)

Regards, -Patrick

  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, April 22, 2003 1:00 PM
  Subject: [ebxmlms-develop] Sending/receiving acknowledgements


  A two part question on acknowledgements.=20

  First, I'd like to check some logic.=20

  The party ids of our messages are not of the form=20

  <eb:From>=20
    <eb:PartyId>http://from/msh/</eb:PartyId>=20
  </eb:From>=20

  Instead, they look like this:=20

  <eb:From>=20
    <eb:PartyId eb:type=3D"ABN">123456789</eb:PartyId>=20
    <eb:Role>Buyer</eb:Role>=20
  </eb:From>=20

  Normally, this doesn't seem to matter. However, when an =
acknowledgement is requested, MessageProcessor attempts to build the URL =
of the message recipient from the From PartyId. In our case, this is =
doomed to failure, and the acknowledgement message is sent to the local =
Hermes instead.

  Is this correct? If so, I'll have to add some more code to resolve a =
destination URL from a partyid, and fix MessageProcessor to use it.

  Second question: when an acknowledgement message is received, Hermes =
appears to swallow it, and doesn't send it on to my listener. How can I =
tell if an acknowledgement has arrived?

  Thanks.=20

  PJDM=20
  --=20
  Peter Mayne=20
  Technology Consultant=20
  Spherion Technology Solutions=20
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
  T: 61 2 62689727  F: 61 2 62689777=20

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.

Re: [ebxmlms-develop] Sending/receiving acknowledgements

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

MessageTotally agree that the application is not standardized (yet). :-)
So, the "PositiveAcknowledgment" feature is in the =
"subjected-to-change-without-notice" state. Please bear with us.. ;-)

Regards, -Patrick

  ----- Original Message -----=20
  From: Ronald van Kuijk=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, April 23, 2003 4:32 PM
  Subject: RE: [ebxmlms-develop] Sending/receiving acknowledgements


  You are right that an MSH may notify the application and I agree that =
it would be a nice feature. But since the interface to an application is =
not standardized (yet) and that a server MAY implement it, I have more =
faith in an acknowledgement on the businessprocess layer in addition to =
receiving a payment in a few days/weeks/months later (if at all =
regarding the current state of the economy ;-) )

  Ronald

  -----Oorspronkelijk bericht-----
  Van: Mayne, Peter [mailto:Pet...@ap...]
  Verzonden: woensdag 23 april 2003 2:10
  Aan: 'ebx...@li...'
  Onderwerp: RE: [ebxmlms-develop] Sending/receiving acknowledgements


    Regarding the acknowledgement, it is only a messaging layer =
acknowledgement for reliable messaging (afaik). If you need the =
application behind the listener to receive an acknowledgement, it should =
be an ack on a different level (other ebxml layer, or even not ebxml at =
all), not a messaging layer ack.

    Yes, but it would still be nice for the person that initiated the =
message to know it has arrived.


    In our case, someone here sends an invoice to a partner. The =
business acknowledgement of that invoice is a payment some days/weeks =
later. However, it would be convenient for the person who sent the =
invoice to get an acknowledgement (usually within a few minutes) that =
the message has been received. If things are broken (the Internet is =
down, the partner is off the air, our Hermes server is not sending =
messages), then the lack of a fast acknowledgement is a good indication =
that things need to be fixed.

    The ebXML spec says "Upon receipt of an end-to-end Acknowledgment =
Message, the From Party MSH MAY notify the application of successful =
delivery for the referenced message." Notification would be good, =
because then we can decide to ignore acknowledgements, rather than =
Hermes not telling us about them.

    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
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.

RE: [ebxmlms-develop] SyncReply not happening

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> Never mind, I figured it out. You have to make the right Request. Or to
> put it another way, you have to ask nicely. :-)

        Please don't mind. I'm focusing on Axis, xmlsec and other internal
development affairs these days. You figured it out so quickly before my
email. :-)


> I'm sending messages to Hermes with AckRequested and SyncReply
> enabled, but all I get back on the HTTP connection is

> An MSH acknowledgement is being sent, but it is sent as a separate
> message, rather than back down the same HTTP connection.

> Do I have to do something to enable sync replies in Hermes, or is
> something else going on?

        Our idea is that one is to use those public static constants in
Request such as SYNC_REPLY_MODE_NONE, SYNC_REPLY_MODE_MSH_SIGNALS_ONLY, etc.
when specifying the syncReply level. However, it is noted we currently
only support NONE and MSH_SIGNALS_ONLY as we still meet some ambiguity or
implementation difficulties in supporting other modes. MessageServiceHandler
will handle these two modes in dispatchMessage().

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

RE: [ebxmlms-develop] Sending/receiving acknowledgements

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

You are right that an MSH may notify the application and I agree that it
would be a nice feature. But since the interface to an application is not
standardized (yet) and that a server MAY implement it, I have more faith in
an acknowledgement on the businessprocess layer in addition to receiving a
payment in a few days/weeks/months later (if at all regarding the current
state of the economy ;-) )
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: woensdag 23 april 2003 2:10
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Sending/receiving acknowledgements




Regarding the acknowledgement, it is only a messaging layer acknowledgement
for reliable messaging (afaik). If you need the application behind the
listener to receive an acknowledgement, it should be an ack on a different
level (other ebxml layer, or even not ebxml at all), not a messaging layer
ack.
 
Yes, but it would still be nice for the person that initiated the message to
know it has arrived.
 
 
In our case, someone here sends an invoice to a partner. The business
acknowledgement of that invoice is a payment some days/weeks later. However,
it would be convenient for the person who sent the invoice to get an
acknowledgement (usually within a few minutes) that the message has been
received. If things are broken (the Internet is down, the partner is off the
air, our Hermes server is not sending messages), then the lack of a fast
acknowledgement is a good indication that things need to be fixed.
 
The ebXML spec says "Upon receipt of an end-to-end Acknowledgment Message,
the From Party MSH MAY notify the application of successful delivery for the
referenced message." Notification would be good, because then we can decide
to ignore acknowledgements, rather than Hermes not telling us about them.
 
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.

RE: [ebxmlms-develop] Digital signature namespace showstopper pro blem

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

This extensive checking is also a problem for migrating to axis, but it's
more the URI check than the prefix check. Isn't just checking the uri and
not the namespace a little dangerous? An element can have a namespace
prefix, but not a uri e.g. when it is nested in a parent element that hase
the namespace declaration.
 
Also when adding your own extensions to an ebxml envelop (which hermes
nicely supports) the namespace check seems important if an nested element
with a name that also exists in ebxml is added, but with a different
namespace.
 
e.g. 
 
<myns:From xmlns:myns="......">
   <myns:PartyId>.....</myns:PartyId>
</myns:From>
 
PartyId should not need to have a namespace declaration (that is one of the
differences between axis and sun. Sun always adds them, axis looks at the
nesting and prefix)
 
So the above example is what axis does, using the sun implementation it
would look like
 
<myns:From xmlns:myns="......">
   <myns:PartyId xmlns:myns=".....">.....</myns:PartyId>
</myns:From>
 
At least that's one of the differences I've seen when trying to use axis in
hermes Besides a little overkill depending on the presence of an namespace
declaration (in hermes) breaks compatibility (correct me if i'm wrong, I
could have missed something)
 

 -----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: dinsdag 22 april 2003 4:48
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Digital signature namespace showstopper pro
blem



> One issue is that 
> JAXM interface 
> somehow requires prefix in some methods such as addChildElement(Name), 
> SOAPEnvelope.createName(), getChildElements(Name), etc. The 

For adding/creating, there shouldn't be a problem, because you can use any
prefix you like. For getChildElements(), my fix avoids the prefix
altogether, which is what should be happening.

JAXM seems to use org.dom4j.QName internally, at least in some places. For
example: 

    public Iterator getChildElements(Name name) { 
        return elementIterator((QName) name); 
    } 

QName has the following implementation of equals(): 

    public boolean equals(Object object) { 
        if (object instanceof QName) { 
            QName qname = (QName)object; 
            if (qname.uri != null) { 
                return uri == qname.uri && localpart == qname.localpart; 
            } 
            else if (uri == null) { 
                return rawname == qname.rawname; 
            } 
            // fall through and return not equal 
        } 
        return false; 
    } // equals(Object):boolean 

This is the equivalent of my fix, which ignores the prefix altogether. 

So, you can probably keep using "ds" for your prefix when creating messages,
but error messages like "no <ds:Signature> found" will have to go. :-)

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: Ng Chi Yuen [Cyng] [ mailto:cy...@cs...
<mailto:cy...@cs...> ] 
> Sent: Tuesday, 22 April 2003 12:27 PM 
> To: 'ebx...@li...' 
> Subject: RE: [ebxmlms-develop] Digital signature namespace 
> showstopper pro blem 
> 
> 
> Hi, 
> 
> > >         Ideally speaking, a library should not care about 
> what prefix an 
> > > XML file is using because everything depends on the 
> binding of prefix to 
> > > a particular namespace URI, i.e., only namespace URI is important. 
> 
> > The code fragment above explicitly checks for the prefix, 
> which we really 
> > don't want to do. If we comment out the obvious part: 
> 
> >             if 
> (childName.getLocalName().equals(name.getLocalName()) && 
> > //              childName.getPrefix().equals(name.getPrefix()) && 
> >                 childName.getURI().equals(name.getURI())) { 
> >                 childElements.add(child); 
> >                 continue; 
> >             } 
> 
> > then we're no longer including the prefix in the check, and 
> things work 
> > as they should. I don't have a comprehensive test suite to 
> check other 
> > consequences of this change, and technically, anything that uses the 
> > hard-coded value of NAMESPACE_PREFIX_DS is still incorrect, 
> but with this 
> > change, messages that use "dsig" for a namespace prefix are 
> being parsed 
> > correctly. 
> 
>         Thanks, Peter. I have also been thinking about how to avoid 
> considering namespace prefix these days. One issue is that 
> JAXM interface 
> somehow requires prefix in some methods such as addChildElement(Name), 
> SOAPEnvelope.createName(), getChildElements(Name), etc. The 
> above commented 
> checking is valid but I have to carefully think about the impact. The 
> idea up to this moment in my mind may be NAMESPACE_PREFIX_DS 
> is dynamically 
> constructed if an InputStream of message is read. The 
> solution is coming 
> soon. 
> 
> Regards, 
> CY 
> 
> -------------------------------------------------------------- 
> -------------- 
> Ng Chi Yuen, CY.       cy...@ce...       
> http://www.cecid.hku.hk/ <http://www.cecid.hku.hk/>  
> Technology Officer, 
> Centre for 
> E-Commerce Infrastructure Development, 
> The University of Hong Kong 
> -------------------------------------------------------------- 
> -------------- 
> 
> 
> 
> ------------------------------------------------------- 
> This sf.net email is sponsored by:ThinkGeek 
> Welcome to geek heaven. 
> http://thinkgeek.com/sf <http://thinkgeek.com/sf>  
> _______________________________________________ 
> ebxmlms-develop mailing list 
> ebx...@li... 
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
<https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop>  
> 


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.

RE: [ebxmlms-develop] Sending/receiving acknowledgements

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

Hi,
 
In our current implementation (not freebxml and not fully ebxml compliant)
we use an central ldap server to do a lookup for the host and type
(smtp/http/...) where a message for a certain PartyId and corresponding type
should be delivered. This could be skipped if the value of the PartyId is a
URI. But I agree, one way or another, it should work for other values than
"http://...."
 
Regarding the acknowledgement, it is only a messaging layer acknowledgement
for reliable messaging (afaik). If you need the application behind the
listener to receive an acknowledgement, it should be an ack on a different
level (other ebxml layer, or even not ebxml at all), not a messaging layer
ack.
 
Ronald
 
 

 -----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: dinsdag 22 april 2003 7:00
Aan: 'ebx...@li...'
Onderwerp: [ebxmlms-develop] Sending/receiving acknowledgements



A two part question on acknowledgements. 

First, I'd like to check some logic. 

The party ids of our messages are not of the form 

<eb:From> 
  <eb:PartyId> http://from/msh/ <http://from/msh/> </eb:PartyId> 
</eb:From> 

Instead, they look like this: 

<eb:From> 
  <eb:PartyId eb:type="ABN">123456789</eb:PartyId> 
  <eb:Role>Buyer</eb:Role> 
</eb:From> 

Normally, this doesn't seem to matter. However, when an acknowledgement is
requested, MessageProcessor attempts to build the URL of the message
recipient from the From PartyId. In our case, this is doomed to failure, and
the acknowledgement message is sent to the local Hermes instead.

Is this correct? If so, I'll have to add some more code to resolve a
destination URL from a partyid, and fix MessageProcessor to use it.

Second question: when an acknowledgement message is received, Hermes appears
to swallow it, and doesn't send it on to my listener. How can I tell if an
acknowledgement has arrived?

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 


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.

RE: [ebxmlms-develop] Digital signature namespace showstopper pro blem

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> >         Ideally speaking, a library should not care about what prefix an
> > XML file is using because everything depends on the binding of prefix to
> > a particular namespace URI, i.e., only namespace URI is important.

> The code fragment above explicitly checks for the prefix, which we really
> don't want to do. If we comment out the obvious part:

>             if (childName.getLocalName().equals(name.getLocalName()) &&
> //              childName.getPrefix().equals(name.getPrefix()) &&
>                 childName.getURI().equals(name.getURI())) {
>                 childElements.add(child);
>                 continue;
>             }

> then we're no longer including the prefix in the check, and things work
> as they should. I don't have a comprehensive test suite to check other
> consequences of this change, and technically, anything that uses the
> hard-coded value of NAMESPACE_PREFIX_DS is still incorrect, but with this
> change, messages that use "dsig" for a namespace prefix are being parsed
> correctly.

        Thanks, Peter. I have also been thinking about how to avoid
considering namespace prefix these days. One issue is that JAXM interface
somehow requires prefix in some methods such as addChildElement(Name),
SOAPEnvelope.createName(), getChildElements(Name), etc. The above commented
checking is valid but I have to carefully think about the impact. The
idea up to this moment in my mind may be NAMESPACE_PREFIX_DS is dynamically
constructed if an InputStream of message is read. The solution is coming
soon.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] Digital signature namespace showstopper problem

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> Their SOAP message starts

> <SOAP-ENV:Envelope
>     xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>     xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
> ....

> (Note the "dsig" namespace used here for the XML Digital Signature
> namespace.)

> Hermes produces this:

> <soap-env:Envelope
>     xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> ....

> (No declaration at all for the XML Digital Signature namespace.) (There's
> another obvious difference: "SOAP-ENV" vs "soap-env", but we'll skip that
> for now. :-)

        I have been investigating XML Signature problems these days. It
really causes much headache to me as nothing works smooth for xmlsec 1.0.4
and 1.0.5D2.

        My observation from the different experiments in using 1.0.5D2
is so long to be concluded and typed here.

        What I can say up to this moment is that I have followed exactly
the "CreateSignature" example as bundled in xmlsec to sign a message and
it works. However, the signed message is a DOM element that I have to
insert whole tree back into JAXM and send it out. I have checked the sent
message's signature which looks the same as the DOM tree. But, once it
is verified, I get the exception of:

        The prefix "ds" for element "ds:SignedInfo" is not bound.

        Ideally speaking, a library should not care about what prefix an
XML file is using because everything depends on the binding of prefix to
a particular namespace URI, i.e., only namespace URI is important.


> If I feed their message into Hermes, I get the response:
> Exception:
> hk.hku.cecid.phoenix.message.packaging.validation.SOAPValidationException
> Message: Client: <ds:SignedInfo> is not found in <ds:Signature>!

        However, this problem is due to the fact that when unmarshalling
a SOAPElement, JAXM cannot find <dsig:SignedInfo> even though the correct
namespace URI is already supplied.

> However, things still don't work, because Hermes then says "Verification
> of signature failed - no PublicKey found".
> Is there any way of telling Hermes to use a
> separate certificate to verify the SignatureValue?

        Currently, Hermes assumes that the signed message must supply
the X509Certificate in order to verify. There is no way to tell which
certificate to use. I think this involves certificate or public key
management that we will consider in the later Hermes version.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

Re: [ebxmlms-develop] Better security logging?

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Yes. We have improved logging, especially in verification part in the
nightly builds.<br>
-Patrick<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>Better security logging?</title>
  <p><font size="2">Do current nightly builds have better security
logging?</font> </p>
  <p><font size="2">I have a Hermes server on sysA, and a client on
sysB.</font> </p>
  <p><font size="2">If I run my Loopback program on sysA to send a
signed message, everything works fine.</font> </p>
  <p><font size="2">If I run the exact same Loopback program on sysB to
send a signed message, I get "Security Checks Failed".</font> </p>
  <p><font size="2">I'm using the same keystore on both systems.</font> </p>
  <p><font size="2">The process of slogging through and figuring out
what is different between the two systems would be a lot easier if the
logging here was more verbose. :-)</font></p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>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.


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] signed acknowledgments

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Thanks for your contribution. We have added the patch to the latest CVS
source tree. -Patrick<br>
<br>
Gait Boxman wrote:<br>
<blockquote type="cite" cite="mid000e01c2fce8$e27beda0$9900a8c0@gaitlap">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
  <style></style>
  <div><font face="Arial" size="2">I don't set the envelope when doing
verification. But if you don't set it, it gets automatically set to
'dsa-sha1' since that is the default.</font></div>
  <div><font face="Arial" size="2">See diffs below to enable the
key-alg loading from the properties file.</font></div>
  <div><font size="2">
  <p>diff -r1.148 MessageServiceHandler.java</p>
  <p>727a728,729</p>
  </font><font color="#0000ff" size="2">
  <p>&gt; private static String keyAlg = null;</p>
  <p>&gt; </p>
  </font><font size="2">
  <p>822a825</p>
  </font><font color="#0000ff" size="2">
  <p>&gt; keyAlg = prop.get(Constants.PROPERTY_MSH_KEY_ALGORITHM);</p>
  </font><font size="2">
  <p>824c827,831</p>
  </font><font color="#ff0000" size="2">
  <p>&lt; if (keystorePath.equals("")) {</p>
  </font><font size="2">
  <p>---</p>
  </font><font color="#0000ff" size="2">
  <p>&gt; if (keyAlg.equals("")) {</p>
  <p>&gt; keyAlg = null;</p>
  <p>&gt; }</p>
  <p>&gt; </p>
  <p>&gt; if (keystorePath.equals("")) {</p>
  </font><font size="2">
  <p>2425c2432,2433</p>
  </font><font color="#ff0000" size="2">
  <p>&lt; ackMessage.sign(keystoreAlias,
keystorePassword.toCharArray(),</p>
  </font><font size="2">
  <p>---</p>
  </font><font color="#0000ff" size="2">
  <p>&gt; if( keyAlg == null ) {</p>
  <p>&gt; ackMessage.sign(keystoreAlias,
keystorePassword.toCharArray(),</p>
  </font><font size="2">
  <p>2426a2435,2439</p>
  </font><font color="#0000ff" size="2">
  <p>&gt; }</p>
  <p>&gt; else {</p>
  <p>&gt; ackMessage.sign(keystoreAlias, keystorePassword.toCharArray(),</p>
  <p>&gt; keystore, keyAlg);</p>
  <p>&gt; }</p>
  <p>&nbsp;</p>
  <font size="2">
  <p>diff -r1.20 Constants.java</p>
  <p>196a197,202</p>
  </font><font color="#0000ff" size="2">
  <p>&gt; /**</p>
  <p>&gt; * Path to get key algorithm in configuration file</p>
  <p>&gt; */</p>
  <p>&gt; public static final String PROPERTY_MSH_KEY_ALGORITHM =</p>
  <p>&gt; "MSH/DigitalSignature/AckSign/Key/Algorithm";</p>
  <p>&gt; </p>
  </font></font></div>
  <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">&nbsp;</div>
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">-----
Original Message ----- </div>
    <div
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-inline-policy: initial; -moz-background-origin: initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>From:</b> <a
 title="kc...@ce..." href="mailto:kc...@ce...">Patrick Yee</a> </div>
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>To:</b> <a
 title="ebx...@li..."
 href="mailto:ebx...@li...">ebx...@li...</a> </div>
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Sent:</b>
Monday, April 07, 2003 10:41   AM</div>
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Subject:</b>
Re: [ebxmlms-develop] signed   acknowledgments</div>
    <div><br>
    </div>
    <div><font face="Tahoma" size="2">Yes, you can pass "dsa-sha1" or
"rsa-sha1" as   the algorithm parameter to the ebxmlMessage.sign()
function. And we missed   this option when signing acks. Adding a
property to trigger this behavious   sounds good.</font></div>
    <div>&nbsp;</div>
    <div><font face="Tahoma" size="2">Gait, for the verification, there
is no need to   set the algorithm. According to JavaDoc of the XML
security   library</font></div>
    <div><font face="Tahoma" size="2"><a
 href="http://nagoya.apache.org/gump/javadoc/xml-security/build/doc/html/api/org/apache/xml/security/signature/XMLSignature.html">http://nagoya.apache.org/gump/javadoc/xml-security/build/doc/html/api/org/apache/xml/security/signature/XMLSignature.html</a></font></div>
    <div>&nbsp;</div>
    <div><font face="Tahoma" size="2">We can omit the SignatureMethod
parameter when   constructing the XMLSignature object. Since we omit
that parameter, so setting   any value in envelope will have no effect.</font></div>
    <div>&nbsp;</div>
    <div><font face="Tahoma" size="2">BTW, how do you set the envelope
when doing   verification?</font></div>
    <div>&nbsp;</div>
    <div><font face="Tahoma" size="2">Regards, -Patrick</font></div>
    <div>&nbsp;</div>
    <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">-----
Original Message ----- </div>
      <div
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-inline-policy: initial; -moz-background-origin: initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>From:</b> <a
 title="gai...@ti..." href="mailto:gai...@ti...">Gait Boxman</a> </div>
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>To:</b> <a
 title="ebx...@li..."
 href="mailto:ebx...@li...">ebx...@li...</a> </div>
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Sent:</b>
Friday, April 04, 2003 6:45     PM</div>
      <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Subject:</b>
Re: [ebxmlms-develop] signed     acknowledgments</div>
      <div><br>
      </div>
      <div><font face="Arial" size="2">Actually, with a bit of hacking
I got it to     work (I think). BC is used from apache...xml/security,
where the jce classes     are dynamically loaded from an Australian
ftp site to bypass US export     regulations. The trick was to pass
in&nbsp;the 'rsa-sha1'&nbsp;algorithm     parameter to the ebxmlMessage.sign
function. For acks, I added a property to     trigger this behaviour (
for signed messages, you can do it from the client     directly).
Funny thing is that verification occurs with the envelope set to    
dsa-sha1 :-), and still works fine. I guess that's because that
information     sits inside the <a class="moz-txt-link-freetext" href="ds:Signature">ds:Signature</a>, which is never signed
itself, and is not used     for the verification itself. I don't think
I got it quite right, yet, bit it     seems to work on the loopback...</font></div>
      <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
        <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">-----
Original Message ----- </div>
        <div
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-inline-policy: initial; -moz-background-origin: initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>From:</b> <a
 title="rv...@ab..." href="mailto:rv...@ab...">Ronald van Kuijk</a> </div>
        <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>To:</b> <a
 title="ebx...@li..."
 href="mailto:%27e...@li...%27">'ebx...@li...'</a> </div>
        <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Sent:</b>
Friday, April 04, 2003 10:50       AM</div>
        <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Subject:</b>
RE: [ebxmlms-develop] signed       acknowledgments</div>
        <div><br>
        </div>
        <div><span class="413225408-04042003"><font face="Arial"
 color="#0000ff" size="2">from what i've seen the bouncycastle
libraries are used in the       signature process. The rsa algorithms
are probably not included due to       licensing restrictions.</font></span></div>
        <div><span class="413225408-04042003"></span>&nbsp;</div>
        <div><span class="413225408-04042003"><font face="Arial"
 color="#0000ff" size="2">But thats just a wild guess</font></span></div>
        <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
          <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Oorspronkelijk bericht-----<br>
          <b>Van:</b> Gait Boxman         [<a class="moz-txt-link-freetext" href="mailto:gai...@ti...">mailto:gai...@ti...</a>]<br>
          <b>Verzonden:</b> vrijdag 4 april 2003         9:27<br>
          <b>Aan:</b> <a
 href="mailto:ebx...@li...">ebx...@li...</a><br>
          <b>Onderwerp:</b> Re: [ebxmlms-develop] signed acknowledgments<br>
          <br>
          </font></div>
          <div><font face="Arial" size="2">One more question: is the
limitation to DSA         signatures local to my machine (i.e. a setup
problem on my part), a         limitation from Hermes, or a limitation
from XMLDsig?</font></div>
          <div><font face="Arial" size="2">I seem to remember we were
able to use RSA         in the earlier days,&nbsp;and&nbsp;they&nbsp;certainly work
for         SSL...&nbsp;</font></div>
          <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
            <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;">-----
Original Message ----- </div>
            <div
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-inline-policy: initial; -moz-background-origin: initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>From:</b> <a
 title="gai...@ti..." href="mailto:gai...@ti...">Gait     
Boxman</a> </div>
            <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>To:</b> <a
 title="ebx...@li..."
 href="mailto:ebx...@li...">ebx...@li...</a> </div>
            <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Sent:</b>
Monday, March 31, 2003 1:56           PM</div>
            <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-stretch: normal; font-size-adjust: none;"><b>Subject:</b>
[ebxmlms-develop] signed           acknowledgments</div>
            <div><br>
            </div>
            <div><font face="Arial" size="2">Hi team, </font></div>
            <div>&nbsp;</div>
            <div><font face="Arial" size="2">per ebMS2, when signed
acknowledgments           are requested, the acknowledgment must
contain the digests of the           original (signed or unsigned)
message. AFAICT, this is currently not           implemented. Is there
an easy way to add it? I've tracked down signing           as far as
the Apache XML security libs, but I was hoping of an easier          
and faster way to add the digests than going through three levels of  
API's...</font></div>
            <div>&nbsp;</div>
            <div><font face="Arial" size="2">thnx, Gait.</font></div>
            <div>&nbsp;</div>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
  </blockquote>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] troubles with signed acks (still)

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi Gait,

        First of all, I would like to know whether you are using xmlsec
1.0.4 (check-out from Hermes distribution) or 1.05D2 (as downloaded from
Apache).

> one issue is with the soap namespace prefix. I've nailed this down to the
> fact that hermes passes the doc to xmlsec as a DOM tree, rather than as a
> string. When passing this to xmlsec, reserialization uses SAAJ, which
> hardcodes 'soap-env' as the prefix, while the others use SOAP. this
> causes a digest mismatch. I've solved this (for now) by swapping to SOAP
> as the prefix in SAAJ and Hermes, but we need to change this so that the
> actual streamed data is passed to XMLSignature in xmlsec.

        I wonder why there is a digest mismatch if xmlsec 1.0.4 is used.
We are also using 1.0.4 to do signing and the message can be verified
once it is received by MSH.

        Can you elaborate your situation? Do you mean "soap-env" which
is hardcoded in SAAJ causes the problem? Or "SOAP" is hardcoded in xmlsec
that causes the problem?


> Another is, which is still open is that the SOAP namespace declarations,
> which occur originally on the SOAP:envelope are moved to the SOAP:Header
> and SOAP:Body elements during C14N. I haven't managed to find or fix that
> yet. Any ideas are welcome...

        I have no idea on this now. What is the impact of such a
declaration move? Would it void the signature or digest?


> One more thing, which may be related, is a nullpointer exception that's
> thrown during C14N of an ack from Sun, which has the ds:Reference
> elements for the original message. One of those happens to be
> <ds:Reference xmlns:ds="....." URI="">. C14N throws an exception in
> org\apache\xml\security\c14n\helper\NonNSAttrCompare.java.
> This happens inside the C14N during the sorting of the attributes.
> Tracing revealed that namespace URI and localname resolve to null for
> both attribs, and the exception occurs as the compare is deferred to an
> equals call of the localnames.


        I have also been investigating this problem. This occurs in
xmlsec 1.0.5D2 but not 1.0.4. I compare the source trees of 1.0.5D2 and
1.0.4. I find that 1.0.4 somehow comments the sortAttributes() method
in org.apache.xml.security.c14n.helper.C14nHelper.java which calls
the comparator in NonNSAttrCompare.java. But in 1.0.5D2, sortAttributes()
is resumed to work such that for those attributes such as
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature",
the getLocalName() would be null when it is retrieved from
org.w3c.dom.Attr. I wonder if this a bug in 1.0.5D2.

        Now, the current situation for signed acknowledgment is as follows.
I have modified packaging (not commited yet) to add <ds:Reference> in
Acknowledgment.java. However, such a message cannot be signed even
with xmlsec 1.0.4 because of other exceptions thrown. I am still
investigating the reason but it's really troublesome.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------