ebxmlms-develop — Development discussions

Re: [ebxmlms-develop] CPP/A integration

[Marcus W. <mar...@ho...>]

Thanks for your quick reply. =3DD

=20

Is seems those parameters are message driven by the "FromParty" (MSH =
stub for Hermes implementation), right?=20

=20

Actually I'm now looking at the relationship between CPP/A and ebMS spec =
(for details, please view Appendix F of CPP/A).  In CPP/A, those =
parameters can be the following values.

1.      duplicateElimination               =3D[ always |  never |  =
perMessage]   =20

2.      ackRequested                          =3D[ always |  never |  =
perMessage]   =20

3.      messageOrderSemantics        =3D[ always |  never |  perMessage] =
 =20

4.      isNonRepudiationRequired   =3D [ Guaranteed |  NotGuaranteed]  =20

=20

"ToParty MSH" needs to validate the incoming message if the first three =
parameters in CPA are set to "always=A1=A8 or =A1=A7never=A1=A8.  Can we =
set something like that in the application context of the "ToParty =
Hermes" so that it can check against the incoming message?

=20

Marcus Wong

  ----- Original Message -----=20
  From: Gait Boxman=20
  To: ebx...@li...=20
  Sent: Tuesday, January 13, 2004 3:50 PM
  Subject: Re: [ebxmlms-develop] CPP/A integration


  Hi Marcus,

  Just a first reply, others might jump in with more detail :-)

  Hermes is based on ebXML Messaging Specification 2.0, we don't =
directly integrate with CPP/A, but the properties you mention are =
actually in ebMS as well.
  Let's see:
  1. duplicateElimination - yes, you can set the duplicateElimination =
flag in the message you send to tell the other MSH to eliminate =
duplicates, and Hermes listens for it.
  2. ackRequested - yes, another property you can set, and Hermes =
listens for it.
  3. message ordering is supported within a given application context =
(cpa,conversation)
  4. isNonRepReq'd - you can request the ack to be signed, which will =
give NRR, messages can also be sent signed.

  Actually, hermes uses the toMSHUrl property for the endpoint, and the =
applicationcontext for delivery to a listener of the received message. =
In the samples,the toMSHUrl may be the same as the toPartyId..
  toPartyId has to be a URI unless you specify a type (per ebMS2). =
Unfortunately, there is no authorative code list for the type parameter, =
but "DUNS" might work well for you. In the code where you add the =
toPartyID, simply add the type string as an extra parameter to your =
call.

  For asynchronous replies, I believe Hermes currently relies on (one =
of) the fromPartyId(s) of the original message to hold the MSH URL to =
send the reply to. Work is on the way to remove this dependency..
    ----- Original Message -----=20
    From: Marcus Wong=20
    To: ebx...@li...=20
    Sent: Tuesday, January 13, 2004 8:16 AM
    Subject: [ebxmlms-develop] CPP/A integration




    Dear all,=20

    =20

    I=A1=A6m new to Hermes.  I=A1=A6ve some questions about CPP/A =
integration.

    From the release note 0931, it shows that Hermes supporting =
syncReplyMode (mshSignalOnly and none), how about the following =
attributes in CPP/A?

    =20

    1.      duplicateElimination=20

    2.      ackRequested

    3.      messageOrderSemantics

    4.      isNonRepudiationRequired

    =20

    =20

    Also, how to define the end point of the message?  I found that =
Hermes is using the first toParty value when posting the ebxml to =
another MSH.  Can we set the toParty value as a logical name (e.g. DUNS =
number) instead of an URL?

    =20

    =20

    =20

    Regards,

    Marcus Wong =20

Re: [ebxmlms-develop] CPP/A integration

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

Hi Marcus,

Just a first reply, others might jump in with more detail :-)

Hermes is based on ebXML Messaging Specification 2.0, we don't directly =
integrate with CPP/A, but the properties you mention are actually in =
ebMS as well.
Let's see:
1. duplicateElimination - yes, you can set the duplicateElimination flag =
in the message you send to tell the other MSH to eliminate duplicates, =
and Hermes listens for it.
2. ackRequested - yes, another property you can set, and Hermes listens =
for it.
3. message ordering is supported within a given application context =
(cpa,conversation)
4. isNonRepReq'd - you can request the ack to be signed, which will give =
NRR, messages can also be sent signed.

Actually, hermes uses the toMSHUrl property for the endpoint, and the =
applicationcontext for delivery to a listener of the received message. =
In the samples,the toMSHUrl may be the same as the toPartyId..
toPartyId has to be a URI unless you specify a type (per ebMS2). =
Unfortunately, there is no authorative code list for the type parameter, =
but "DUNS" might work well for you. In the code where you add the =
toPartyID, simply add the type string as an extra parameter to your =
call.

For asynchronous replies, I believe Hermes currently relies on (one of) =
the fromPartyId(s) of the original message to hold the MSH URL to send =
the reply to. Work is on the way to remove this dependency..
  ----- Original Message -----=20
  From: Marcus Wong=20
  To: ebx...@li...=20
  Sent: Tuesday, January 13, 2004 8:16 AM
  Subject: [ebxmlms-develop] CPP/A integration




  Dear all,

  =20

  I=A1=A6m new to Hermes.  I=A1=A6ve some questions about CPP/A =
integration.

  From the release note 0931, it shows that Hermes supporting =
syncReplyMode (mshSignalOnly and none), how about the following =
attributes in CPP/A?

  =20

  1.      duplicateElimination=20

  2.      ackRequested

  3.      messageOrderSemantics

  4.      isNonRepudiationRequired

  =20

  =20

  Also, how to define the end point of the message?  I found that Hermes =
is using the first toParty value when posting the ebxml to another MSH.  =
Can we set the toParty value as a logical name (e.g. DUNS number) =
instead of an URL?

  =20

  =20

  =20

  Regards,

  Marcus Wong =20

[ebxmlms-develop] CPP/A integration

[Marcus W. <mar...@ho...>]

Dear all,

=20

I=A1=A6m new to Hermes.  I=A1=A6ve some questions about CPP/A =
integration.

From the release note 0931, it shows that Hermes supporting =
syncReplyMode (mshSignalOnly and none), how about the following =
attributes in CPP/A?

=20

1.      duplicateElimination=20

2.      ackRequested

3.      messageOrderSemantics

4.      isNonRepudiationRequired

=20

=20

Also, how to define the end point of the message?  I found that Hermes =
is using the first toParty value when posting the ebxml to another MSH.  =
Can we set the toParty value as a logical name (e.g. DUNS number) =
instead of an URL?

=20

=20

=20

Regards,

Marcus Wong =20

Re: [ebxmlms-develop] JMSMessageListener contrib?

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

Mayne, Peter wrote:

> Sounds good, but I would strongly advise using Tapestry instead of Struts.
>  


:-) I currently have no time to start learning tapestry, nor do I have 
any other projects where I need this (we have other projets with struts 
however). Let me start out by using struts and try to find points where 
we could split some of the main servlet. Then, when I got a small 
working example, maybe tapestry could come in after that

(funny, they struts and tapestry are both apache projects)

Ronald

> PJDM
> --
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
>
>     -----Original Message-----
>     *From:* Ronald van Kuijk [mailto:rv...@ab...]
>     *Sent:* Monday, 12 January 2004 8:49 PM
>     *To:* 'ebx...@li...'
>     *Subject:* RE: [ebxmlms-develop] JMSMessageListener contrib?
>
>     Thanks Peter, saves me a lot of time comming to the same conclusion.
>      
>     In addition to this, I'm looking into creating a web based
>     monitoring/management functionality for Hermes based on struts and
>     even a web base test-client. Currently the management things are
>     realy tightly integrated with the messaging servlet. Splitting
>     management functionality into another url (/msh-console?) and even
>     splitting of the management functionality completely would
>     probably make it easier to have some general serverside message
>     processing.
>      
>     Anyone interested in this? I volunteer to refactor this part, but
>     since it is also related closely with the persistency layer, maybe
>     I should wait until that as landed fully.
>      
>     Ronald
>
>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] JMSMessageListener contrib?

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

Thanks Peter, saves me a lot of time comming to the same conclusion.
 
In addition to this, I'm looking into creating a web based
monitoring/management functionality for Hermes based on struts and even
a web base test-client. Currently the management things are realy
tightly integrated with the messaging servlet. Splitting management
functionality into another url (/msh-console?) and even splitting of the
management functionality completely would probably make it easier to
have some general serverside message processing. 
 
Anyone interested in this? I volunteer to refactor this part, but since
it is also related closely with the persistency layer, maybe I should
wait until that as landed fully.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: zondag 11 januari 2004 23:14
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] JMSMessageListener contrib?



Ronald is correct: I'm still using an HTTP listener which just passes
the message to JMS. 

I did go some way to using JMS directly, but the current implementation
isn't completely broken, so I didn't completely fix it. :-)

I would also like to see a more generic listener in Hermes. 

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

> -----Original Message----- 
> From: Ronald van Kuijk [ mailto:rv...@ab... <mailto:rv...@ab...>
] 
> Sent: Monday, 12 January 2004 12:24 AM 
> To: ebx...@li... 
> Subject: Re: [ebxmlms-develop] JMSMessageListener contrib? 
> 
> 
> Peter mentioned in previous messages about the JMS listerner 
> that there 
> still is http-tunneling involved in his implementation. 
> Looking at the 
> code of the MessageListener and the Request implementation, I 
> see that 
> this tunneling is the only 'easy' option. I'm thinking 
> however about a 
> more direct delivery of messages through JMS. To achieve 
> this, a lot of 
> the servlet implementation has to change. Since I've read that some 
> redesign things are going on (like a separate persistence layer, and 
> some monitoring/controling redesign), is there a change that 
> there will 
> be changes in the way messages can be delivered? 
> 
> Ronald 
> 
> Ronald van Kuijk wrote: 
> 
> > Hi all, 
> > 
> > Several months ago, there was a discussion about a JMSReceiver with 
> > uri/url issue. Especially Peter Mayne was working on this and had a 
> > working implementation for this. 
> > 
> > I'm currently working on an application that will be running within 
> > the same applicationserver as Hermes. I therefor like to 
> have a more 
> > closely integrated method for sending and receiving messages. I was 
> > thinking of a jms queue between the stub and hermes instead 
> of http. 
> > Is there already some code to start with, or extend? Maybe 
> a kind of 
> > contrib thing? Where I can also my LDAPURLResolver, and upcomming 
> > LDAPCertResolver. 
> > 
> > Ronald 
> > 
> > 
> > ------------------------------------------------------- 
> > This SF.net email is sponsored by: Perforce Software. 
> > Perforce is the Fast Software Configuration Management 
> System offering 
> > advanced branching capabilities and atomic changes on 50+ platforms.

> > Free Eval! http://www.perforce.com/perforce/loadprog.html
<http://www.perforce.com/perforce/loadprog.html>  
> > _______________________________________________ 
> > ebxmlms-develop mailing list 
> > ebx...@li... 
> > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
<https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop>  
> 
> 
> 
> 
> ------------------------------------------------------- 
> This SF.net email is sponsored by: Perforce Software. 
> Perforce is the Fast Software Configuration Management System offering

> advanced branching capabilities and atomic changes on 50+ platforms. 
> Free Eval! http://www.perforce.com/perforce/loadprog.html
<http://www.perforce.com/perforce/loadprog.html>  
> _______________________________________________ 
> 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] JMSMessageListener contrib?

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

Peter mentioned in previous messages about the JMS listerner that there 
still is http-tunneling involved in his implementation. Looking at the 
code of the MessageListener and the Request implementation, I see that 
this tunneling is the only 'easy' option. I'm thinking however about a 
more direct delivery of messages through JMS. To achieve this, a lot of 
the servlet implementation has to change. Since I've read that some 
redesign things are going on (like a separate persistence layer, and 
some monitoring/controling redesign), is there a change that there will 
be changes in the way messages can be delivered?

Ronald

Ronald van Kuijk wrote:

> Hi all,
>
> Several months ago, there was a discussion about a JMSReceiver with 
> uri/url issue. Especially Peter Mayne was working on this and had a 
> working implementation for this.
>
> I'm currently working on an application that will be running within 
> the same applicationserver as Hermes. I therefor like to have a more 
> closely integrated method for sending and receiving messages. I was 
> thinking of a jms queue between the stub and hermes instead of http. 
> Is there already some code to start with, or extend? Maybe a kind of 
> contrib thing? Where I can also my LDAPURLResolver, and upcomming 
> LDAPCertResolver.
>
> Ronald
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

[ebxmlms-develop] JMSMessageListener contrib?

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

Hi all,

Several months ago, there was a discussion about a JMSReceiver with 
uri/url issue. Especially Peter Mayne was working on this and had a 
working implementation for this.

I'm currently working on an application that will be running within the 
same applicationserver as Hermes. I therefor like to have a more closely 
integrated method for sending and receiving messages. I was thinking of 
a jms queue between the stub and hermes instead of http. Is there 
already some code to start with, or extend? Maybe a kind of contrib 
thing? Where I can also my LDAPURLResolver, and upcomming LDAPCertResolver.

Ronald

Re: [ebxmlms-develop] Enhancement request - determining message s igner

[Bob K. <py...@ce...>]

Dear Peter,

Your presumption exactly what I implemented, sorry that I didn't mention 
it clearly.

Regards,
Bob Koon

Mayne, Peter wrote:

> From: Bob Koon
> > 3) It will be hard to decide the behaviour if both CertResolver and 
> Trust store is set, since there may be case
> > that the cert cannot be gotten from the key info of the message.
>
> This is the case with messages we receive: the certificate is not 
> included in the KeyInfo.
>
> > The current implementation is that the CertResolver is used to 
> verify the signature, and then the trust store
> > is used to verify the cert path of the certificate from the 
> CertResolver.
>
> I presume you mean "the certificate returned by the CertResolver is 
> used to verify the signature".
>
> Why are you verifying the path of the certificate from CertResolver? 
> If my CertResolver is returning a certificate, then presumably that 
> certificate doesn't need to be further verified against the trust 
> store. I presume it's because by the time path is verified, you don't 
> know (or care) if the certificate came from the message or the 
> CertResolver, which is fine.
>
> 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] Enhancement request - determining message signer

[Bob K. <py...@ce...>]

Dear Peter,
In fact I have just changed the code on Hermes regarding the 
verification behaviour on EbxmlMessage last week:

1) If the user try the message with non-Null CertResolver, Hermes will 
probably consider the EbxmlMessage must able be verified by 
CertResolver. Therefore, if there is any error on verification using the 
certificates on CertResolver (e.g. the certificates returned by the 
CertResolver is null), it will throw Exception.

2) If the CertResolver is null, the trust store and message's key info 
is the last line on verification signature. If there is error on verify 
the signature using certificate on KeyInfo or the certificate path, it 
will throw Exception.

3) It will be hard to decide the behaviour if both CertResolver and 
Trust store is set, since there may be case that the cert cannot be 
gotten from the key info of the message. The current implementation is 
that the CertResolver is used to verify the signature, and then the 
trust store is used to verify the cert path of the certificate from the 
CertResolver. It may not be the best behaviour, and you can suggest the 
logic it should be.

The EbxmlMessage.isAuthenic() may be okay for the server side 
programming, but it may be quite strange for the packaging in client 
side. In fact I cannot see the difference between isAuthenic() and verify().

Regards,
Bob Koon

Mayne, Peter wrote:

> These are just off the top of my head, but we have to start somewhere. 
> I've catered for my narrow needs. :-)
>  
> 1) Signature
>  
> We need to ensure that a message has been signed by the right entity. 
> (Enforcing the use of CertResolver in the MSH to catch tricky messages 
> might avoid this, but it is still good to see the information.)
>  
> There should be something like a getSigner() method on EbxmlMessage 
> that provides easy access to the <ds:KeyInfo> contents 
> (http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo). This may return a 
> separate class instance which provides KeyInfo access methods.
>  
> There seem to be two different paths, depending on whether the 
> <ds:KeyInfo> has been included in the message header or not. If it 
> has, then it should be sufficient to just return the data. Someone can 
> then look at it and decide if the data is correct.
>  
> If there is no <ds:KeyInfo> data, then there would have to be a 
> fallback to CertResolver on the client side. It should be sufficient 
> to return the certificate that CertResolver returns, which can then be 
> looked at by a person.
>  
> 2) Verification
>  
> We need to ensure at any stage that a message is valid, especially six 
> months after the message has been delivered and the client tries to 
> repudiate it.
>  
> There should be something like an isAuthentic() method on EbxmlMessage 
> that verifies that the message is correcty signed. There should 
> possibly be a parameter that allows the signature to be determined as 
> above (look for <KeyInfo>, fall back to CertResolver), or explicitly 
> force the use of CertResolver only, so the decision about which 
> certificate to use is made based on our CertResolver, rather than 
> relying on a certificate in the message. (Or even do both, comparing 
> the certificate in the message with the certificate from CertResolver 
> to make sure the other end isn't playing tricks.)
>  
> The isAuthentic() method could be boolean. Alternatively, it could 
> throw an exception depending on what is wrong with the message 
> (digests don't match, unexpected certificate, etc). The exception 
> would be useful to try and track why the message isn't authentic.
>  
> (Checking last year's messages with certificates that have since 
> expired might be tricky, but I suspect it's up to CertResolver to find 
> the right certificate. :-)
>  
> I'm not attached to the method names, so feel free to think of 
> something better.
>  
> 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] Enhancement request - determining message signer

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

Hi,

two remarks... inline

Mayne, Peter wrote:

> These are just off the top of my head, but we have to start somewhere. 
> I've catered for my narrow needs. :-)
>  
> 1) Signature
>  
> We need to ensure that a message has been signed by the right entity. 
> (Enforcing the use of CertResolver in the MSH to catch tricky messages 
> might avoid this, but it is still good to see the information.)
>  
> There should be something like a getSigner() method on EbxmlMessage 
> that provides easy access to the <ds:KeyInfo> contents 
> (http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo). This may return a 
> separate class instance which provides KeyInfo access methods.
>  
> There seem to be two different paths, depending on whether the 
> <ds:KeyInfo> has been included in the message header or not. If it 
> has, then it should be sufficient to just return the data. Someone can 
> then look at it and decide if the data is correct.
>  
> If there is no <ds:KeyInfo> data, then there would have to be a 
> fallback to CertResolver on the client side. It should be sufficient 
> to return the certificate that CertResolver returns, which can then be 
> looked at by a person.
>  
> 2) Verification
>  
> We need to ensure at any stage that a message is valid, especially six 
> months after the message has been delivered and the client tries to 
> repudiate it.
>  
> There should be something like an isAuthentic() method on EbxmlMessage 
> that verifies that the message is correcty signed. There should 
> possibly be a parameter that allows the signature to be determined as 
> above (look for <KeyInfo>, fall back to CertResolver), or explicitly 
> force the use of CertResolver only, so the decision about which 
> certificate to use is made based on our CertResolver, rather than 
> relying on a certificate in the message. (Or even do both, comparing 
> the certificate in the message with the certificate from CertResolver 
> to make sure the other end isn't playing tricks.)

I think you should always do both to ensure the certificate that is used 
is not revoked

>  
> The isAuthentic() method could be boolean. Alternatively, it could 
> throw an exception depending on what is wrong with the message 
> (digests don't match, unexpected certificate, etc). The exception 
> would be useful to try and track why the message isn't authentic.
>  
> (Checking last year's messages with certificates that have since 
> expired might be tricky, but I suspect it's up to CertResolver to find 
> the right certificate. :-)

That is why renewing a certificate that has expired should be done while 
keeping the same public/private keypair. You should then be able to 
verify the old signature  with the new certificate. If renewing a 
certificate is the same as getting a completely new one (with new keys) 
it's another story.

>  
> I'm not attached to the method names, so feel free to think of 
> something better.
>  
> 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] ebXML ping code ? ( was connecting to hermes MSH from a Perl MSH )

[Aaron T. <te...@dr...>]

On Wed, 17 Dec 2003, Patrick Yee wrote:
> You can download some development guide of Hermes at www.freebxml.org.
> Inside the guide you can find some description about the architecture of
> Hermes.

great, thanks.

about 20 minutes after posting I tried RunMonitor.sh and it was very handy
indeed.

unfortunately I know get an error when attempting to send MIME messages to
the hermes MSH (from my perl code) - I will write a proper post on the
problem once I have had a little longer to check my own code isn't at
fault.

cheers,

A.


-- 
Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant
AutoDia --- Automatic UML and HTML Specifications from Perl, C++
and Any Datasource with a Handler.     http://droogs.org/autodia

Re: [ebxmlms-develop] Enhancement request - determining message signer

[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 text="#000000" bgcolor="#ffffff">
Peter,<br>
<br>
Your worry is very true. Thank you for pointing this out. How do you
expect to fix that? I mean, what are the methods to be added, in your
opinion?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta content="text/html; " http-equiv="Content-Type">
  <meta content="MS Exchange Server version 5.5.2654.45"
 name="Generator">
  <title>Enhancement request - determining message signer</title>
  <p><font size="2">I'd like to request an enhancement to Hermes in the
message signing area.</font>
  </p>
  <p><font size="2">Currently, after a message has arrived, it is easy
to tell if a message is signed or not, but it isn't as easy to tell who
signed it.</font></p>
  <p><font size="2">For instance, suppose I have two business partners,
A and B. A creates a message (a million dollar purchase order, for
example) that looks like it comes from B, signs it, and sends it.
Hermes accepts it, because the message is correctly signed. I look at
the message, see that it appears to come from B, and since it is
signed, assume that it does in fact come from B, and therefore invoice
B for a million dollars.</font></p>
  <p><font size="2">Since there is no obvious way of telling that it
was not B who signed the message, I have incorrectly assumed that the
message came from, and was signed by, B.</font></p>
  <p><font size="2">An obvious adjunct to this is being able to easily
validate any given signed message. It would be good if the Hermes
client library provided a convenient API to validate the signature of a
message. If I need to do that at the moment (because one of my partners
is trying to repudiate a message), I have to do it manually using the
excellent CECID verifier, rather than just asking Hermes to validate
the message using its existing validation facilities.</font></p>
  <p><font size="2">If I'm missing something, and I can already do
these things, please let me know.</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>
<!--[object_id=#ap.spherion.com#]-->
  <p align="left"><font size="1" color="#0000ff" face="Tahoma">The
information contained in this email and any attachments to it:</font></p>
  <p align="left"><font size="1" color="#0000ff" face="Tahoma">(a) may
be confidential and if you are not the intended recipient, any
interference with, <br>
use, disclosure or copying of this material is unauthorised and
prohibited; and</font></p>
  <p align="left"><font size="1" color="#0000ff" face="Tahoma">(b) may
contain personal information of the recipient and/or the sender as
defined <br>
under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to <br>
collect, hold and use such information and any personal information
contained in a <br>
response to this email, for any reasonable purpose in the ordinary
course of <br>
Spherion's <br>
business, including forwarding this email internally or disclosing it
to a third party. All <br>
personal information collected by Spherion will be handled in
accordance with <br>
Spherion's Privacy Policy. If you have received this email in error,
please notify the <br>
sender and delete it.</font></p>
  <p align="left"><font size="1" color="#0000ff" face="Tahoma">(c) you
agree not to employ or arrange employment for any candidate(s) supplied
in <br>
this email and any attachments without first entering into a
contractual agreement with <br>
Spherion. You further agree not to divulge any information contained in
this document <br>
to any person(s) or entities without the express permission of Spherion.</font></p>
</blockquote>
<br>
</body>
</html>

Re: [ebxmlms-develop] ebXML ping code ? ( was connecting to hermes MSH from a Perl MSH )

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

Hello Aaron,

You can download some development guide of Hermes at www.freebxml.org. 
Inside the guide you can find some description about the architecture of 
Hermes.

Regards, -Patrick


>also - is there any documentation (UML, etc) for Hermes beyond the javadoc
>?
>
>  
>

Re: [ebxmlms-develop] Signed sync acks not being verified correct ly by Hermes

[<mo...@wa...>]

Mayne, Peter wrote:
>  > From: Olivier Moïses
>  > We resolve the this by patching the code.
> 
> How did you patch it?
> 
> PJDM
> -- 
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
> 
Hi Peter,

Sorry for the delay of this answer.
We patch the MessageServiceHandler.dispatchMessage method. Unfortunatly, 
we worked on an older version of ebxmlms, so line numbers are useless.
this method can be divided in numerous blocks, one is regarding the 
acknowledgment processing  (it's begin by  'if (acknowledgment != null)'
In this place you ca put the acknowledgment verification.
If you want, I can send you the more code.

Regards,

Olivier

[ebxmlms-develop] ebXML ping code ? ( was connecting to hermes MSH from a Perl MSH )

[Aaron T. <te...@dr...>]

Thanks for the quick (and helpful response) - I have had some success
sending a ping from my perl MSH to my hermes MSH and got a nice pong
response.

Now I am looking to do the opposite. Looking through the archives (which
disappeared for a couple of days, while sourcforge threw errors) I can
see that there has been some Java ping code floating on the list but the
archive has stripped out the handy attachments.

Hopefully be able to get a nice conversation going between my perl code
and your java code pretty soon.

also - is there any documentation (UML, etc) for Hermes beyond the javadoc
?

Thanks for the good work and the helpful info,

A.


-- 
Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant
AutoDia --- Automatic UML and HTML Specifications from Perl, C++
and Any Datasource with a Handler.     http://droogs.org/autodia

Re: [ebxmlms-develop] Signed sync acks not being verified correctly by Hermes

[<om...@no...>]

Mayne, Peter wrote:

> We have signed messages being successfully passed back and forth betwee=
n=20
> us and our business partner (using Hermes from a CVS export this mornin=
g).
>=20
> They can send us a signed message, and our signed sync ack is sent and=20
> received successfully.
>=20
> However, if we send them a signed message, their signed sync ack is not=
=20
> verified, due to the calculated digest being different to the unverifie=
d=20
> digest.
>=20
> If I add some debugging code to write the bad message to a file, and us=
e=20
> the signature tool to verify it, it verifies correctly.
>=20
> Does anyone have any idea why a signed syn ack might not verify=20
> correctly in Hermes, but verify correctly with the signature tool?
>=20
> (This leads to another feature request. Can an option be added to Herme=
s=20
> so that bad messages are written to a "bad messages" directory, so we=20
> can investigate them, rather than being thrown away, which makes proble=
m=20
> solving a bit difficult.)
>=20
> Thanks.
>=20
> PJDM
> --=20
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
>=20
Peter,

I think I saw the same some weeks ago. For me, this current version=20
does'nt verify acknowledge signature and original sended message=20
signature, as explained in ebxml.org "Message Service Specification 2.0"=20
6.3.2.5 lines 1560 to 1563.
Actually, this is the only one variation to the normative document, I met.
We resolve the this by patching the code.


Regards,

Olivier Mo=EFses

Re: [ebxmlms-develop] Signed sync acks not being verified correctly by Hermes

[Bob K. <py...@ce...>]

My comment inline....

Mayne, Peter wrote:

> We have signed messages being successfully passed back and forth 
> between us and our business partner (using Hermes from a CVS export 
> this morning).
>
> They can send us a signed message, and our signed sync ack is sent and 
> received successfully.
>
> However, if we send them a signed message, their signed sync ack is 
> not verified, due to the calculated digest being different to the 
> unverified digest.
>
> If I add some debugging code to write the bad message to a file, and 
> use the signature tool to verify it, it verifies correctly.
>
> Does anyone have any idea why a signed syn ack might not verify 
> correctly in Hermes, but verify correctly with the signature tool?
>
Haven't seen such situation before... that means that there may be bug 
on Hermes.... anyway If it is possilble, you can send me the message, 
the key (I know it may be trouble to you) and I can have a try. By the 
way I will have a look on those code.

> (This leads to another feature request. Can an option be added to 
> Hermes so that bad messages are written to a "bad messages" directory, 
> so we can investigate them, rather than being thrown away, which makes 
> problem solving a bit difficult.)
>
In fact I am doing some work on Persistence hook on Hermes, therefore I 
will also take it as consideration.

> 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] Unused imports, and use of com.sun.net.ssl

[Bob K. <py...@ce...>]

Dear Peter,

In fact I just tried to use some tool to remove those unused import, and 
also convert those wildcard import to non-wildcard one. However, I 
haven't changed all of them yet. Thanks for providing us information to 
resolve those classes, so I may change it later. (In fact there are too 
many places to change for wildcard imports...)

For the com.sun.net.ssl problem, it is more troublesome. The reason to 
write the SSL support is due to some test cases requirement when testing 
with partners, and you are right that we still want to include 1.3 JVMs. 
The problem is more complicated because the application server may also 
use JSSE library, which may affect the JSSE loading on Hermes too. 
Therefore, we choose to use 1.3 because at least 1.3 JSSE is both 
supported on 1.3 and 1.4.

Regards,
Bob Koon

Mayne, Peter wrote:

> I noticed you were cleaning up unused imports. I've just fetched the 
> latest CVS, so I thought you'd like to know what Eclipse is showing as 
> never used (as well as a non-static reference to a static field). :-)
>
> Severity        Description     Resource        In Folder       
> Location        Creation Time
>         The import 
> hk.hku.cecid.phoenix.message.packaging.MessageHeader is never used   
> MessageServiceHandler.java      
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/message/handler        line 
> 78 December 11, 2003 10:26:04 AM
>
>         The import 
> hk.hku.cecid.phoenix.message.packaging.SignatureReference is never 
> used      MessageServiceHandler.java      
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/message/handler        line 
> 82 December 11, 2003 10:26:04 AM
>
>         The import hk.hku.cecid.phoenix.message.packaging.ErrorList is 
> never used       SignalMessageGenerator.java     
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/message/handler        line 
> 71 December 11, 2003 10:26:03 AM
>
>         The static field ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS 
> should be accessed directly      MessageBox.java 
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/message/monitor        line 
> 118        December 11, 2003 10:26:03 AM
>
>         The import java.net.MalformedURLException is never used 
> Http.java       
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/message/transport      line 
> 88 December 11, 2003 10:26:03 AM
>
>         The import java.security.Provider is never used 
> Http.java       
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/message/transport      line 
> 89 December 11, 2003 10:26:03 AM
>
>         The import java.security.Security is never used 
> Http.java       
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/message/transport      line 
> 90 December 11, 2003 10:26:03 AM
>
>         The import org.w3c.dom.Node is never used       
> ApacheXMLDSigner.java   
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/pki    line 90 December 11, 
> 2003 10:26:01 AM
>
>         The import java.io.IOException is never used    
> KeyStoreKeyManager.java 
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/pki    line 70 December 11, 
> 2003 10:26:01 AM
>
>         The import java.util.Enumeration is never used  
> KeyStoreKeyManager.java 
> ebxmlms/WEB-INF/src/hk/hku/cecid/phoenix/pki    line 75 December 11, 
> 2003 10:26:01 AM
>
> I also notice that you're using some com.sun.net.ssl classes, which 
> are undocumented and unsupported, as well as not existing in non-SUN 
> JVMs. This is presumably because you're still including 1.3 JVMs, 
> rather than biting the bullet and using 1.4?
>
> 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.
>
>
>  
>

[ebxmlms-develop] connecting to hermes MSH from a Perl MSH

[Aaron T. <te...@dr...>]

hi,

I am writing a perl ebXML MSH and attempting to send ebXML messages with
it to a test Hermes MSH I have running.

when I send :

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xlink="http://www.w3c.org/1999/xlink/namespace"
xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"><SOAP-ENV:Header><eb:MessageHeader
eb:id=".." SOAP-ENV:mustUnderstand="1"
xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
eb:version="2"><eb:From><eb:PartyId>sample</eb:PartyId></eb:From><eb:To><eb:PartyId>sample</eb:PartyId></eb:To><eb:CPAId>CPA_2002</eb:CPAId><eb:ConversationId>Item_No_128</eb:ConversationId><eb:Service>http://www.cecid.hku.hk/ebxml/service</eb:Service><eb:Action>Order</eb:Action><eb:MessageData><eb:MessageId>12</eb:MessageId><eb:Timestamp>2003-12-10T14:39:19</eb:Timestamp><eb:RefToMessageID
xsi:null="1"/></eb:MessageData><eb:DuplicateElimination
xsi:null="1"/></eb:MessageHeader></SOAP-ENV:Header><SOAP-ENV:Body><eb:Manifest
eb:id="Manifest" SOAP-ENV:mustUnderstand="1"
xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
eb:version="2.0"><eb:Reference eb:id="pay01"
xlink:role="http://regrep.org/gci/purchaseOrder"
xlink:href="cid:payload-d"><eb:Description xml:lang="en-US">Purchase Order
for 100,000 widgets</eb:Description><eb:Schema eb:version="2.0"
eb:location="http://regrep.org/gci/purchaseOrder/po.xsd"
xsi:null="1"/></eb:Reference><c-gensym21
xsi:null="1"/></eb:Manifest></SOAP-ENV:Body></SOAP-ENV:Envelope>

This is a close copy of the example provided in the Technical Architecture
document, so I was surprised by a SOAP error.

The server responded with :

<faultcode>Client</faultcode>

<faultstring>[10503] Cannot internalize SOAP object Exception:
hk.hku.cecid.phoenix.message.packaging.validation.SOAPValidationException
Message: MustUnderstand: SOAP Element &lt;eb:MessageHeader&gt; has the
attribute mustUnderstand = "1" but it cannot be recognized.</faultstring>

I was wondering if there was some negotiation I was failing to send to
'set up' a connection.

any pointers would be much appreciated.

cheers,

A.

-- 
Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant
AutoDia --- Automatic UML and HTML Specifications from Perl, C++
and Any Datasource with a Handler.     http://droogs.org/autodia

Re: [ebxmlms-develop] Utilities for digests, verifying, etc

[Bob K. <py...@ce...>]

Dear Peter Mayne,

I don't know whether you have downloaded the newest version, and the 
newest version should be on following URL:

http://www.cecid.hku.hk/Resources/signatureTool_24SEP03.zip

I am sorry if my documentation is not clear enough, and I think the 
easiest way to start up is to read the "readme.txt" in the zip package. 
In most of the time, you should call verifySignature to verify the 
signature and generate outputs (like those expected digest value, 
canonicalize message form), on the output directory.

You can run the sample described on "readme.txt", which you can know 
more on the output file generated on the standard output. For any 
question, feel free to ask.

Regards,
Bob Koon


Mayne, Peter wrote:

> Earlier this year, you guys developed some utilities that would 
> generate XML digests for ebXML nessages, verify signatures, etc.
>
> Unfortunately, they're arcane enough and lacking sufficient 
> documentation/comments that I can't figure out how to use them without 
> spending too much time on them.
>
> Do you have some quick start docs (for example, to produce digests or 
> verify signatures for an ebXML message with attachments in MIME 
> format, run these commands), or newer versions with more obvious user 
> interfaces?
>
> 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] Unregister problem

[Jack K. <jk...@ce...>]

Hi Ng,

Thanks for replying.  The String[0] was displayed by the Eclipse =
Debugger.  Probably means there is 1 element in the array, but the =
content is an empty string.  Yes, it did not return a valid pending =
message id. =20

Just tried the scenario described earlier few more time just now, but =
could not reproduce the same behavior. =20
returnPendingMessage are returning valid messageIDs.

From what you described, it seems the earlier problem happened after =
failing all retries since getPendingMessage returns empty string array.  =
But somehow unregister() claims that there is still message pending, as =
can be seen from the earlier log.  The only thing I can think of that =
might cause problem earlier was when I received the String[] from =
getPendingMessage(), I passed that directly into =
mshReq.deletePendingMessages(...) even tho it was empty.  Didn't do =
empty String[] check at that time.  Unfortunately I can not go back to =
the db to see if ack message is marked SENT_FAILED.  Will be on the =
lookout the next time. =20

Thanks,
Jack

-----Original Message-----
From: Ng Chi Yuen [mailto:cy...@cs...]
Sent: Thursday, November 20, 2003 6:12 PM
To: ebx...@li...
Subject: Re: [ebxmlms-develop] Unregister problem


Hi,

> Ran into problem unregister a context due to a pending ack message =
that could not be sent.
>=20
> Problems:
> 	1) getPendingmessage() returns String[0]??  Is this correct?  Should =
it return a String[] of messageIds
> 		in this case should it be =
20031120-193806082-CPA-2002.http://www.cecid.hku.hk/ebxml/service.Order.1=
@10.100.8.65
> 	2) unregister() failed due to pending messages.

         I would like to know what you mean by "String[0]". Does it mean =
it=20
returns no pending message id?

> Workaround:  (Sort-of)
> 	I used deletePendingMessages(...) with this messageID =
20031120-193806082-CPA-2002.http://www.cecid.hku.hk/ebxml/service.Order.1=
@10.100.8.65.  It caused RequestException.  However, executing =
unregister() the next time around, it deleted the context.

         The behaviour of getPendingMessage() is like this: if the =
sending=20
ack fails BUT it is still retrying, a sending thread still exists and=20
getPendingMessage() would return its message id. However, if the sending =
ack=20
fails for all retry, getPendingMessage() would return nothing because =
that=20
ack message is marked SENT_FAILED in DB. Then, unregister() should be=20
successful and should not report there is still pending message.

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: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
ebxmlms-develop mailing list
ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] Unregister problem

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

Hi,

> Ran into problem unregister a context due to a pending ack message that could not be sent.
> 
> Problems:
> 	1) getPendingmessage() returns String[0]??  Is this correct?  Should it return a String[] of messageIds
> 		in this case should it be 20031120-193806082-CPA-2002.http://www.cecid.hku.hk/ebxml/service.Order.1@10.100.8.65
> 	2) unregister() failed due to pending messages.

         I would like to know what you mean by "String[0]". Does it mean it 
returns no pending message id?

> Workaround:  (Sort-of)
> 	I used deletePendingMessages(...) with this messageID 20031120-193806082-CPA-2002.http://www.cecid.hku.hk/ebxml/service.Order.1@10.100.8.65.  It caused RequestException.  However, executing unregister() the next time around, it deleted the context.

         The behaviour of getPendingMessage() is like this: if the sending 
ack fails BUT it is still retrying, a sending thread still exists and 
getPendingMessage() would return its message id. However, if the sending ack 
fails for all retry, getPendingMessage() would return nothing because that 
ack message is marked SENT_FAILED in DB. Then, unregister() should be 
successful and should not report there is still pending message.

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

[ebxmlms-develop] Unregister problem

[Jack K. <jk...@ce...>]

Hi,

Ran into problem unregister a context due to a pending ack message that =
could not be sent.

Problems:
	1) getPendingmessage() returns String[0]??  Is this correct?  Should it =
return a String[] of messageIds
		in this case should it be =
20031120-193806082-CPA-2002.http://www.cecid.hku.hk/ebxml/service.Order.1=
@10.100.8.65
	2) unregister() failed due to pending messages.

Workaround:  (Sort-of)
	I used deletePendingMessages(...) with this messageID =
20031120-193806082-CPA-2002.http://www.cecid.hku.hk/ebxml/service.Order.1=
@10.100.8.65.  It caused RequestException.  However, executing =
unregister() the next time around, it deleted the context.

Versions:
	Java =3D j2sdk1.4.1_05
	Tomcat =3D 4.1.24
	MSH version =3D 0.9.3.1
	MySQL =3D 3.23.49-nt

Steps to reproduce:
ApplicationContext (ac)
	CPAID=3D"CPA-2002"
	ConversationID=3D"123456789"
	Service=3D"http://ww.cecid.hku.hk/ebxml/service"
	Action=3D"Order"

Supplier:  Request(ac, new URL("http://www.bad-unreachable-url.com"), =
this, "http");   //Supplier registered a context with an unreachable URL
Buyer:     message.addAckRequested(false);		  			    //Buyer sends a =
message to Supplier requesting unsigned Ack
Supplier:  Received good buyer ebxml message but can not send ack due to =
bad url, now delivery of ack is in pending state.

Supplier:  Try to unregister.  deletePendingMessages(....), then =
unregister().
	   getPendingMessages() returns String[0]

Here is the log file:
2003-11-20 12:26:17,458 INFO  [Thread-10]: Process command: Register MSH =
Configu
ration (1)
2003-11-20 12:26:17,458 INFO  [Thread-10]: Received request for =
registering msh
config
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> =
MessageServiceHandler.register
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> =
MessageServiceHandlerConnectionFactory.MessageServiceHandlerConnectionFac=
tory
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D =
MessageServiceHandlerConnectionFactory.MessageServiceHandlerConnectionFac=
tory
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> =
MessageServiceHandlerConnectionFactory.createConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> =
MessageServiceHandlerConnection.MessageServiceHandlerConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D =
MessageServiceHandlerConnection.MessageServiceHandlerConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D =
MessageServiceHandlerConnectionFactory.createConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> MessageServer.store
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> =
DbConnectionPool.getConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D =
DbConnectionPool.getConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: update MSHConfig
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D MessageServer.store
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> Transaction.commit =
(txID: #134)
2003-11-20 12:26:17,458 DEBUG [Thread-10]: =3D> =
DbConnectionPool.freeConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D =
DbConnectionPool.freeConnection
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D Transaction.commit
2003-11-20 12:26:17,458 DEBUG [Thread-10]: <=3D =
MessageServiceHandler.register
2003-11-20 12:26:17,488 INFO  [Thread-10]: Process command: Get the list =
of pending messages (43)
2003-11-20 12:26:17,488 INFO  [Thread-10]: Received request for getting =
pendingmessages
2003-11-20 12:26:17,488 DEBUG [Thread-10]: =3D> =
MessageServiceHandler.getPendingMessages
2003-11-20 12:26:17,498 DEBUG [Thread-10]: <=3D =
MessageServiceHandler.getPendingMessages
2003-11-20 12:26:17,498 DEBUG [Thread-10]: =3D> =
MessageServiceHandler.sendDocumentResponse
2003-11-20 12:26:17,498 DEBUG [Thread-10]: <=3D =
MessageServiceHandler.sendDocumentResponse
2003-11-20 12:26:17,588 INFO  [Thread-10]: Process command: Delete =
messages (37)

2003-11-20 12:26:17,588 INFO  [Thread-10]: Received requeset for =
deleting pending messages
2003-11-20 12:26:17,588 DEBUG [Thread-10]: =3D> =
MessageServiceHandler.deletePendingMessages
2003-11-20 12:26:17,598 DEBUG [Thread-10]: <=3D =
MessageServiceHandler.deletePendingMessages
2003-11-20 12:26:17,598 DEBUG [Thread-10]: =3D> =
MessageServiceHandler.sendDocumentResponse
2003-11-20 12:26:17,598 DEBUG [Thread-10]: <=3D =
MessageServiceHandler.sendDocumentResponse
2003-11-20 12:26:17,618 INFO  [Thread-10]: Process command: Register MSH =
Configuration (1)
2003-11-20 12:26:17,618 INFO  [Thread-10]: Received request for =
unregistering msh config
2003-11-20 12:26:17,618 DEBUG [Thread-10]: =3D> =
MessageServiceHandler.unregister
2003-11-20 12:26:17,618 DEBUG [Thread-10]: =3D> =
MessageServer.getUndeliveredMessages
2003-11-20 12:26:17,618 DEBUG [Thread-10]: =3D> =
DbConnectionPool.getConnection
2003-11-20 12:26:17,618 DEBUG [Thread-10]: <=3D =
DbConnectionPool.getConnection
2003-11-20 12:26:17,618 DEBUG [Thread-10]: <=3D =
MessageServer.getUndeliveredMessages
2003-11-20 12:26:17,618 WARN  [Thread-10]: [10011] Registration failed - =
unregistration failed: pending messages to be delivered
2003-11-20 12:26:17,618 DEBUG [Thread-10]: =3D> Transaction.commit =
(txID: #135)
2003-11-20 12:26:17,618 DEBUG [Thread-10]: =3D> =
DbConnectionPool.freeConnection
2003-11-20 12:26:17,618 DEBUG [Thread-10]: <=3D =
DbConnectionPool.freeConnection
2003-11-20 12:26:17,618 DEBUG [Thread-10]: <=3D Transaction.commit
2003-11-20 12:26:17,628 DEBUG [Thread-10]: <=3D =
MessageServiceHandler.unregister
2003-11-20 12:26:17,648 INFO  [Thread-12]: Process command: Get message =
(32)
2003-11-20 12:26:17,648 DEBUG [Thread-12]: =3D> =
MessageServiceHandler.getMessage
2003-11-20 12:26:17,648 DEBUG [Thread-12]: =3D> =
MessageServiceHandler.getNextUndeliveredMessage
2003-11-20 12:26:17,648 DEBUG [Thread-12]: =3D> =
MessageServer.getUndeliveredMessages
2003-11-20 12:26:17,648 DEBUG [Thread-12]: =3D> =
DbConnectionPool.getConnection
2003-11-20 12:26:17,648 DEBUG [Thread-12]: <=3D =
DbConnectionPool.getConnection
2003-11-20 12:26:17,658 DEBUG [Thread-12]: <=3D =
MessageServer.getUndeliveredMessages
2003-11-20 12:26:17,658 DEBUG [Thread-12]: =3D> =
MessageServer.setFileDeliveryStatus
2003-11-20 12:26:17,658 DEBUG [Thread-12]: <=3D =
MessageServer.setFileDeliveryStatus
2003-11-20 12:26:17,658 DEBUG [Thread-12]: =3D> =
MessageServer.getMessageFromFile
2003-11-20 12:26:17,698 DEBUG [Thread-12]: <=3D =
MessageServer.getMessageFromFile
2003-11-20 12:26:17,698 DEBUG [Thread-12]: <=3D =
MessageServiceHandler.getNextUndeliveredMessage with messageId: =
20031120-193806082-CPA-2002.http://www.cecid.hku.hk/ebxml/service.Order.1=
@10.100.8.65
2003-11-20 12:26:17,698 DEBUG [Thread-12]: =3D> Transaction.commit =
(txID: #136)
2003-11-20 12:26:17,698 DEBUG [Thread-12]: =3D> =
DbConnectionPool.freeConnection
2003-11-20 12:26:17,698 DEBUG [Thread-12]: <=3D =
DbConnectionPool.freeConnection
2003-11-20 12:26:17,698 DEBUG [Thread-12]: <=3D Transaction.commit
2003-11-20 12:26:17,708 DEBUG [Thread-12]: <=3D =
MessageServiceHandler.getMessage

Re: [ebxmlms-develop] Hermes bug tracking?

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

Hi Ganga,
Please send emails to here. Thanks.
Regards, -Patrick

----- Original Message ----- 
From: "Ganga Sah" <gan...@ya...>
To: <ebx...@li...>
Sent: Tuesday, November 04, 2003 7:11 AM
Subject: [ebxmlms-develop] Hermes bug tracking?


> I wanted to file few issues/bugs in Hermes, which I
> see during interop testing of Hermes with non-Hermes
> ebXML server. I don't see any bugs under bug tracker,
> so I am not sure I should enter bug here or just send
> email on this.
> Please let me know.
> thx
> ganga
> 
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
> 

[ebxmlms-develop] RE: [ebxmlms-general] Hermes bug report

[Tripathi, A. (GXS) <Aji...@gx...>]

Mea culpa ... the bug was in my loopback client. I've verified the other
code to be correct.

-----Original Message-----
From: Tripathi, Ajit (GXS) [mailto:Aji...@gx...]
Sent: Friday, November 07, 2003 3:15 PM
To: 'ebx...@li...';
'ebx...@li...'
Subject: [ebxmlms-general] Hermes bug report



Bob, Patrick,

I traced hermes a little bit more. 

This is what I am getting in the messages ... does it make sense?  I think
type and value of partyID elements are interchanged!!!!! Please confirm.

<eb:From><eb:PartyId
eb:type="Sample">fromPartyId</eb:PartyId></eb:From><eb:To><eb:PartyId
eb:type="Sampola">toPartyId</eb:PartyId></eb:To>

regards,

Ajit