Re: [ebxmlms-develop] Non-compliance found, and other changes requested

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

Hi Gait,

1. We will be releasing version 0.9.3.0 very soon. The focus of this =
release is conformance. In particular, the first issue has been tackled =
in this release.

2. Yes, you are right that the addError mechanism is having some problem =
right now. In our design, one should do the following steps to add =
multiple Error into ErrorList:

a. Call ebxmlMessage.addErrorList(), this will add the first Error to =
ErrorList
b. Call ebxmlMessage.getErrorList() to get the handle of the ErrorList =
element
c. Call errorList.addError() to add further Error

Unfortunately, currently step(c) is in problem as all addError() methods =
are private. We will modify them to public accessible.

3. We will try to repeat your situation and get back to you soon.

We are excited to know that you are going to participate in =
interoperability test in Europe. We have same test here in Asia. When =
will be the timeframe? If possible, I would suggest you to use the =
latest release 0.9.3.0 for testing, as we are putting a lot of efforts =
in this release to address conformance problem. We are testing our code =
internally and we target to release in one month time approximately.

Thanks for your comment.=20

Regards, -Patrick
--
Patrick Yee
System Architect
Center for E-Commerce Infrastructure Development (CECID)
Dept. of Computer Science and Information Systems
The University of Hong Kong
Tel: (852) 22415674
Fax: (852) 25474611

  ----- Original Message -----=20
  From: Gait Boxman=20
  To: ebx...@li...=20
  Sent: Thursday, December 19, 2002 9:26 PM
  Subject: [ebxmlms-develop] Non-compliance found, and other changes =
requested


  Hi,

  while doing some internal testing in preparation for the =
interoperability tests in Europe (within CEN), I found some issues with =
the MSH.
  First issue is with the Service element, which, according to section =
3.1.4.1 of the ebMS 2 spec must be a URI unless a type attribute is =
present. AFAICT, the MSH does not check this.

  Second is with multiple Errors: The API does not allow for adding =
multiple errors to an ebXML message. The only function to add an Error =
is the addErrorList function, which will add an ErrorList element with =
one Error. I suggest that the ebxmlMessage class is augmented with an =
addError function, which creates the ErrorList when needed. Alternative =
is to allow for the creation of an empty ErrorList, and open up the =
addError in the ErrorList class.

  The third issue is related to DuplicateElimination.
  I set up two Monitors talking to each other. One Monitor repeatedly =
sends a message with a fixed message id and time stamp, and duplicate =
elimination (DE) turned on. However, all messages are received by the =
other Monitor. After adding some additional logging to =
MessageServer.hasReceived, I found that the record for the corresponding =
message is never retrieved from the database. I also noticed that =
hasReceived queries against a set of application context parameters and =
the message id, which I believe to be wrong, at least for DE. For DE, =
checking should be done on the parameters passed in from the message, =
since we want to check for duplication of the message itself.
  Did I miss something in the configuration that might break proper DE =
handling? Could it be that it does not work because I'm looping back on =
the same MSH, and the sending Monitor actually updates the DB in between =
calls?

  thnx,
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  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
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~