ebxmlms-develop — Development discussions

Re: [ebxmlms-develop] Digital signature interoperability

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

Just checked REC-xml-c14n-20010315.
running the c14n transform will take care of attribute reordering, from the
spec:
(1.1)
The canonical form of an XML document is physical representation of the
document produced by the method described in this specification. The changes
are summarized in the following list:

  a.. The document is encoded in UTF-8
  b.. Line breaks normalized to #xA on input, before parsing
  c.. Attribute values are normalized, as if by a validating processor
  d.. Character and parsed entity references are replaced
  e.. CDATA sections are replaced with their character content
  f.. The XML declaration and document type declaration (DTD) are removed
  g.. Empty elements are converted to start-end tag pairs
  h.. Whitespace outside of the document element and within start and end
tags is normalized
  i.. All whitespace in character content is retained (excluding characters
removed during line feed normalization)
  j.. Attribute value delimiters are set to quotation marks (double quotes)
  k.. Special characters in attribute values and character content are
replaced by character references
  l.. Superfluous namespace declarations are removed from each element
  m.. Default attributes are added to each element
  n.. Lexicographic order is imposed on the namespace declarations and
attributes of each element
....
2.2 Document Order
Although an XPath node-set is defined to be unordered, the XPath 1.0
Recommendation [XPath] defines the term document order to be the order in
which the first character of the XML representation of each node occurs in
the XML representation of the document after expansion of general entities,
except for namespace and attribute nodes whose document order is
application-dependent.

The XML canonicalization method processes a node-set by imposing the
following additional document order rules on the namespace and attribute
nodes of each element:

  a.. An element's namespace and attribute nodes have a document order
position greater than the element but less than any child node of the
element.
  b.. Namespace nodes have a lesser document order position than attribute
nodes.
  c.. An element's namespace nodes are sorted lexicographically by local
name (the default namespace node, if one exists, has no local name and is
therefore lexicographically least).
  d.. An element's attribute nodes are sorted lexicographically with
namespace URI as the primary key and local name as the secondary key (an
empty namespace URI is lexicographically least).
Lexicographic comparison, which orders strings from least to greatest
alphabetically, is based on the UCS codepoint values, which is equivalent to
lexicographic ordering based on UTF-8.

c14n-20010315 will reorder the attributes and NS declarations to lex. order
prior to digest generation. This rules out order problems...

----- Original Message ----- 
From: "Ng Chi Yuen" <cy...@cs...>
To: <ebx...@li...>
Sent: Tuesday, July 15, 2003 8:33 AM
Subject: Re: [ebxmlms-develop] Digital signature interoperability


> Hi,
>
> > I wrote a small standalone Java utility that does signature verification
> > just like Hermes (with the Apache xmlsec classes), and it predicatably
> > verifies Hermes messages but not Tibco messages.
>
>          Digital signature has been a problem for a very long time since
> Hermes was developed. Some observations had also been discussed in this
list
> before. We, including Gait Boxman, have been working on this problem again
> and tracing the xmlsec source codes recently.
>
>          Up to now, what I can say is that Hermes should have already
> followed the signing and verification mechanism as bundled in the xmlsec
> examples. For signing, *given* xmlsec is correct, Hermes should produce a
> correct and predictable message since an EbxmlMessage is just serialized
to
> obtain the bytes and fed into xmlsec for signing.
>
>          For verification, the situation may be more complicated. The key
> point of my finding is: when a message byte stream is received, it is
parsed
> to become EbxmlMessage object. However, in this process, JAXM re-orders
the
> namespace declaration! That is to say, EbxmlMessage.writeTo() would give
you
> a message different from that of the received bytes. There is uncertainty
if
> such re-ordering breaks the signature. We may have to feed the original
> bytes into xmlsec. Given xmlsec handles correctly the namespaces (no
matter
> for what SOAP prefix), it should finally validate the message.
>
> > How has Hermes performed in interoperability tests when it comes to
> > digital signatures? What can we do to assist Tibco in sorting this out?
>
>          Digital signature has not yet undergone interoperability test in
> ebXML Asia. In order to figure out the problem, is possible for Tibco to
do
> the signature step-by-step such that the intermediate signing output can
be
> recorded? We are facing the problem which DS implementation can be
"trusted"
> in the sense that it is proved to be correct. You may now have to trace,
say
> the transformed output and then the canonicalized output manually, in
order
> to figure the problem.
>
> 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 sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] Digital signature interoperability

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

Hi,

> I wrote a small standalone Java utility that does signature verification 
> just like Hermes (with the Apache xmlsec classes), and it predicatably 
> verifies Hermes messages but not Tibco messages.

         Digital signature has been a problem for a very long time since 
Hermes was developed. Some observations had also been discussed in this list 
before. We, including Gait Boxman, have been working on this problem again 
and tracing the xmlsec source codes recently.

         Up to now, what I can say is that Hermes should have already 
followed the signing and verification mechanism as bundled in the xmlsec 
examples. For signing, *given* xmlsec is correct, Hermes should produce a 
correct and predictable message since an EbxmlMessage is just serialized to 
obtain the bytes and fed into xmlsec for signing.

         For verification, the situation may be more complicated. The key 
point of my finding is: when a message byte stream is received, it is parsed 
to become EbxmlMessage object. However, in this process, JAXM re-orders the 
namespace declaration! That is to say, EbxmlMessage.writeTo() would give you 
a message different from that of the received bytes. There is uncertainty if 
such re-ordering breaks the signature. We may have to feed the original 
bytes into xmlsec. Given xmlsec handles correctly the namespaces (no matter 
for what SOAP prefix), it should finally validate the message.

> How has Hermes performed in interoperability tests when it comes to 
> digital signatures? What can we do to assist Tibco in sorting this out?

         Digital signature has not yet undergone interoperability test in 
ebXML Asia. In order to figure out the problem, is possible for Tibco to do 
the signature step-by-step such that the intermediate signing output can be 
recorded? We are facing the problem which DS implementation can be "trusted" 
in the sense that it is proved to be correct. You may now have to trace, say 
the transformed output and then the canonicalized output manually, in order 
to figure the problem.

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] LDAPToURLresolverImpl.java

[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">
Agreed with Peter. I think this case is similar to JSSE. Although those
classes can be found in JDK1.4, we include jsse.jar in lib directory to
make Hermes to be compiled under JDK 1.3.<br>
<br>
So another option now is to include the JNDI class library
(downloadable from java.sun.com) to lib directory and make the
LDAPToURLresolverImpl.java to hk.hku.cecid.phoenix.message.handler
package.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
<br>
Ronald van Kuijk wrote:<br>
<blockquote type="cite"
 cite="mid...@po...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>RE: [ebxmlms-develop] LDAPToURLresolverImpl.java</title>
  <meta content="MSHTML 5.50.4916.2300" name="GENERATOR">
  <div><span class="497370510-14072003"><font face="Arial"
 color="#0000ff" size="2">JNDI is part of the 1.4 JDK. It's not
standard for 1.3, although several servlet engines (Tomcat, Jetty) have
versions that also contain the jndi libraries, so you could use 1.3
with those versions as wel</font></span></div>
  <div>&nbsp;</div>
  <div><span class="497370510-14072003"><font face="Arial"
 color="#0000ff" size="2">Ronald</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> Mayne, Peter [<a class="moz-txt-link-freetext" href="mailto:Pet...@ap...">mailto:Pet...@ap...</a>]<br>
    <b>Verzonden:</b> maandag 14 juli 2003 2:12<br>
    <b>Aan:</b> '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>'<br>
    <b>Onderwerp:</b> RE: [ebxmlms-develop] LDAPToURLresolverImpl.java<br>
    <br>
    </font></div>
    <p><font size="2">Is JNDI part of standard Java? Could I compile it
without an LDAP implementation?</font> </p>
    <p><font size="2">If not, it would probably be better as a contrib
package?</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>
    <p><font size="2">&gt; -----Original Message-----</font> <br>
    <font size="2">&gt; From: Ronald van Kuijk [<a
 href="mailto:rv...@ab...">mailto:rv...@ab...</a>] </font><br>
    <font size="2">&gt; Sent: Monday, 14 July 2003 6:30 AM</font> <br>
    <font size="2">&gt; To: ebxmlms</font> <br>
    <font size="2">&gt; Subject: [ebxmlms-develop]
LDAPToURLresolverImpl.java</font> <br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; Hi all,</font> <br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; Im writing a LDAPToURLresolverImpl class that
can get the URL </font><br>
    <font size="2">&gt; to send a </font><br>
    <font size="2">&gt; message to from an ldap server. Should I put
this class in the </font><br>
    <font size="2">&gt; hk.hku.cecid.phoenix.message.handler package or
is it more </font><br>
    <font size="2">&gt; something for </font><br>
    <font size="2">&gt; in the transport package? Or should it even be
in my own package </font><br>
    <font size="2">&gt; (net.vankuijk.message.handler/transport) and
put it in a </font><br>
    <font size="2">&gt; contrib part of </font><br>
    <font size="2">&gt; Hermes?</font> <br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; Ronald</font> <br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt;
-------------------------------------------------------</font> <br>
    <font size="2">&gt; This SF.Net email sponsored by: Parasoft</font>
    <br>
    <font size="2">&gt; Error proof Web apps, automate testing &amp;
more.</font> <br>
    <font size="2">&gt; Download &amp; eval WebKing and get a free book.</font>
    <br>
    <font size="2">&gt; <a class="moz-txt-link-abbreviated" href="http://www.parasoft.com/bulletproofapps1">www.parasoft.com/bulletproofapps1</a></font> <br>
    <font size="2">&gt; _______________________________________________</font>
    <br>
    <font size="2">&gt; ebxmlms-develop mailing list</font> <br>
    <font size="2">&gt; <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a></font> <br>
    <font size="2">&gt; <a target="_blank"
 href="https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop">https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop</a></font>
    <br>
    <font size="2">&gt; </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>
</body>
</html>

RE: [ebxmlms-develop] LDAPToURLresolverImpl.java

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

JNDI is part of the 1.4 JDK. It's not standard for 1.3, although several
servlet engines (Tomcat, Jetty) have versions that also contain the jndi
libraries, so you could use 1.3 with those versions as wel
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: maandag 14 juli 2003 2:12
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] LDAPToURLresolverImpl.java



Is JNDI part of standard Java? Could I compile it without an LDAP
implementation? 

If not, it would probably be better as a contrib package? 

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, 14 July 2003 6:30 AM 
> To: ebxmlms 
> Subject: [ebxmlms-develop] LDAPToURLresolverImpl.java 
> 
> 
> Hi all, 
> 
> Im writing a LDAPToURLresolverImpl class that can get the URL 
> to send a 
> message to from an ldap server. Should I put this class in the 
> hk.hku.cecid.phoenix.message.handler package or is it more 
> something for 
> in the transport package? Or should it even be in my own package 
> (net.vankuijk.message.handler/transport) and put it in a 
> contrib part of 
> Hermes? 
> 
> Ronald 
> 
> 
> 
> 
> ------------------------------------------------------- 
> This SF.Net email sponsored by: Parasoft 
> Error proof Web apps, automate testing & more. 
> Download & eval WebKing and get a free book. 
> www.parasoft.com/bulletproofapps1 
> _______________________________________________ 
> 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] channels, classes, jndi etc.

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

While I was working on a small example of looking up connectors for 
channels (shouldn't we standardize on a name for these?) together with 
their configuration, it really started to look like I was implementing 
sessionbeans. I started from 
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html#Adding%20Custom%20Resource%20Factories 
and then had to add some other functionality. Eventually the list was

- Looking-up components by their JNDI name
- writing some config mechanism these components could use (deployment 
descriptors)
- having it work with transactions
- limiting the amount of simultaneous use (to prevent the 
application/backend to become overloaded)
- .....

At that moment I stopped, took a good night sleep and came up with the 
following.

I think that Hermes should support two different approaches:
- Lightweight, just running on a servlet engine
- Running on a j2ee server (more complex in some parts, simpeler in others)

The reason I bring this up again, becomes clear by the following table 
which contains current and future functionality:

Feature                     Hermes              Tomcat *1      Jetty 
Plus *2     j2ee
ConnectionPool, with jndi   No, Proprietary     standard       standard 
         standard
Transactions                Proprietary         standard *3    standard 
*3       standard *3
authent. / author.          Proprietary         jaas           jaas     
         jaas
Monitoring (jmx?)           No                  yes *4         yes *5   
         yes
                            (curr. proprietary)
Clustering                  No                  No (t yet *6)  No       
         standard
JavaMail                    Yes,(other config)  yes            yes       
        yes
JCA *7                      n/a                 No             No       
         Yes

*1 : http://jakarta.apache.org/tomcat/
*2 : http://jetty.mortbay.com/jetty/plus/
*3 : JTA
*4 : Tomcat 4.1 and newer
*5: http://jetty.mortbay.com/jetty/jmx/index.html
*6: http://www.onjava.com/pub/a/onjava/2002/07/17/tomcluster.html
*7: Java Connector Architecture, for furture integration with SAP, 
Siebel, JDEdwards, PeopleSoft, Oracle, DBs, CICS, IMS, MQSeries

With this table, I do not, not at all, want to shed a negative light on 
Hermes. The opposite, I'd like it to be what it currently is, a great 
and stable ebXML MSH. All the other functionality, like connectionpools, 
transaction managers etc, which do work without a problem, should be 
build by those people that have that as their core (opensource-) business.

Whatever the difference will be between the 'lightweight' and 'j2ee' 
versions, providing the hooks to choose either path is needed the most. 
The step from using the build-in jta,jdbc, etc functionality of a 
servlet engine to using a j2ee-server is small.

Any comment?

Highest Regards

Ronald

Ronald van Kuijk wrote:

> While developing the small example with JNDI, some questions came to 
> mind. What I was doing looked alot like implementing what can be done 
> with session-beans in a j2ee server.
>
> Without thinking of ejb's, the questions this raises for me are:
>
>    * How dynamic should new classes (file/url/jms/....) be loaded.
>          o  Should they be deployed expanded e.g. in a expanded
>            deployed msh.war directory?
>          o Is a restart acceptible?
>    * Where and how should they be pre-configured (url, username,
>      password, certificate etc).
>    * Does each AppContext has it's own set of maximum of 3 'channel
>      connectors'  (message, error, notify) or should the be shared
>      between AppContexts?
>    * Where is the dynamic configuration persisted (if at all?) in
>      relation to the AppContext (JNDI?, Database?)
>    * Should there be a limit in maximum connections to the receiving
>      application?    * etc...
>
> please comment..
>
> Regards,
>
> Ronald
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

[ebxmlms-develop] LDAPToURLresolverImpl.java

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

Hi all,

Im writing a LDAPToURLresolverImpl class that can get the URL to send a 
message to from an ldap server. Should I put this class in the 
hk.hku.cecid.phoenix.message.handler package or is it more something for 
in the transport package? Or should it even be in my own package 
(net.vankuijk.message.handler/transport) and put it in a contrib part of 
Hermes?

Ronald

[ebxmlms-develop] channels, classes, jndi etc.

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

While developing the small example with JNDI, some questions came to 
mind. What I was doing looked alot like implementing what can be done 
with session-beans in a j2ee server.

Without thinking of ejb's, the questions this raises for me are:

    * How dynamic should new classes (file/url/jms/....) be loaded.
          o  Should they be deployed expanded e.g. in a expanded
            deployed msh.war directory?
          o Is a restart acceptible?
    * Where and how should they be pre-configured (url, username,
      password, certificate etc).
    * Does each AppContext has it's own set of maximum of 3 'channel
      connectors'  (message, error, notify) or should the be shared
      between AppContexts?
    * Where is the dynamic configuration persisted (if at all?) in
      relation to the AppContext (JNDI?, Database?)
    * Should there be a limit in maximum connections to the receiving
      application? 
    * etc...

please comment..

Regards,

Ronald

Re: [ebxmlms-develop] Hermes 1.0 my remarks

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

+1

Patrick Yee wrote:

> Agreed. In fact, it is easy to add a thin layer on top of Hermes to 
> provide CPA parsing. That layer can take in a CPA file and supply the 
> parameters parsed to Hermes. IMHO, this gives the greatest flexibility.
>  
> Cheers, -Patrick
>  
>
>     That is not to say we shouldn't support CPA's altogether. The
>     Request and EbxmlMessage interfaces should allow for proper
>     configuration from a CPA by a client that knows how to read a CPA
>     and can set up the corresponding Requests and EbxmlMessage
>     instances, but I see no need to force that upon the server in any
>     way at this moment.
>      
>

Re: [ebxmlms-develop] Hermes 1.0 my remarks

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

Agreed. In fact, it is easy to add a thin layer on top of Hermes to =
provide CPA parsing. That layer can take in a CPA file and supply the =
parameters parsed to Hermes. IMHO, this gives the greatest flexibility.

Cheers, -Patrick

  That is not to say we shouldn't support CPA's altogether. The Request =
and EbxmlMessage interfaces should allow for proper configuration from a =
CPA by a client that knows how to read a CPA and can set up the =
corresponding Requests and EbxmlMessage instances, but I see no need to =
force that upon the server in any way at this moment.

Re: [ebxmlms-develop] Hermes 1.0 my remarks

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

After the troubles I've seen with CPA driven MSH's during the European =
interop tests, I'd definitely prefer to separate the CPA handling from =
the MSH. One reason is that CPA's cover more than just the MSH. Another =
is that during the tests, we've found that Hermes configuration was a =
lot more simple than the partners that could only configure through =
CPA's. Wildcard ApplicationContext parameters on a Request are extremely =
useful, but you wouldn't be allowed to use them when directly driving =
your config from a CPA. This was a real advantage for us, and I don't =
want to give that up.
That is not to say we shouldn't support CPA's altogether. The Request =
and EbxmlMessage interfaces should allow for proper configuration from a =
CPA by a client that knows how to read a CPA and can set up the =
corresponding Requests and EbxmlMessage instances, but I see no need to =
force that upon the server in any way at this moment.

Regarding automatic CPA negotiation, there have been some examples both =
during the ebxml project days and after that, but given all the =
possibilities there are, I can't see how a program would be able to =
automatically match any pair of conceptually compatible CPP's (meaning a =
pair that could actually support a trading relationship) in the best =
possible way, if it could match them at all. Of course, it's not a big =
deal when the CPP's are a perfect match already, the problem is when =
actual negotiation needs to take place, an area that I've yet to see =
being succesfully demonstrated.

--Gait.
  ----- Original Message -----=20
  From: Patrick Yee=20
  To: ebx...@li...=20
  Sent: Thursday, July 10, 2003 12:43 PM
  Subject: Re: [ebxmlms-develop] Hermes 1.0 my remarks


  Negotiation of CPA out of CPPs? Is the CPPA spec making clear enough =
for that? Anyway, we think Hermes should not touch on CPA file.

  Regards, -Patrick



      Do you, or anybody else , know of libraries that can generate the =
values of elements in an ebxml envelop based on a cpa  (or better yet, 2 =
cpp's) ?

  ------------------------------------------------------- This SF.Net =
email sponsored by: Parasoft Error proof Web apps, automate testing & =
more. Download & eval WebKing and get a free book. =
www.parasoft.com/bulletproofapps =
_______________________________________________ ebxmlms-develop mailing =
list ebx...@li... =
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] Hermes 1.0: sync reply

[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">
<br>
<blockquote type="cite"
 cite="mid...@po...">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
    <div><span class="316481109-10072003"><font face="Arial"
 color="#0000ff" size="2">The AppContext? Should'n it be a reference to
this specific message? </font></span></div>
  </blockquote>
</blockquote>
<br>
Yes, you are right. :-)<br>
<br>
<br>
<blockquote type="cite"
 cite="mid...@po...">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
    <div><span class="316481109-10072003"><font face="Arial"
 color="#0000ff" size="2">I agree. Isn't the&nbsp;there a SyncReply</font>&nbsp;<font
 face="Arial" color="#0000ff" size="2">timeout in the CPA&nbsp;&nbsp;e.g.
8.4.14.10:</font></span></div>
    <div><br>
    <span class="316481109-10072003"><font face="Arial" color="#0000ff"
 size="2">8.4.14.10 timeToPerform attribute</font></span></div>
  </blockquote>
  <div align="left"><font face="Arial"><font color="#0000ff"><font
 size="2">The <b><i>timeToPerform </i></b></font></font></font><font
 face="Arial" color="#0000ff" size="2">attribute is of type duration
[XMLSCHEMA-2]. It specifies the time period,</font></div>
  <div align="left"><font face="Arial"><font color="#0000ff"><font
 size="2">starting from the initiation of the <b><i>RequestingBusinessActivity</i></b></font></font></font><font
 face="Arial" color="#0000ff" size="2">, within which the initiator of
the</font></div>
  <div align="left"><font face="Arial" color="#0000ff" size="2">transaction
MUST have received the response, i.e., the business document associated
with the</font></div>
  <div align="left"><font face="Arial" color="#0000ff" size="2">RespondingBusinessActivity.</font></div>
  <div align="left"><font face="Arial"><font color="#0000ff"><font
 size="2">NOTE: The <b><i>timeToPerform </i></b></font></font></font><font
 face="Arial"><font color="#0000ff"><font size="2">attribute associated
with a <b><i>BinaryCollaboration </i></b></font></font></font><font
 face="Arial" color="#0000ff" size="2">in BPSS is</font></div>
  <div align="left"><font face="Arial" color="#0000ff" size="2">currently
not modeled in this specification. Therefore, it cannot be overridden.
In other</font></div>
  <div align="left"><font face="Arial" color="#0000ff" size="2">words,
the value specified at the BPSS level MUST be used.</font></div>
  <div align="left"><font face="Arial"><font color="#0000ff"><font
 size="2">When synchronous reply mode is in use (see Section 8.4.23.1),
the <b><i>TimeToPerform </i></b></font></font></font><font
 face="Arial" color="#0000ff" size="2">value</font></div>
  <div align="left"><font face="Arial" color="#0000ff" size="2">SHOULD
be used as the connection timeout.</font></div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
    <div><font face="Arial"><font color="#0000ff"><font size="2">&nbsp;<br>
    <span class="316481109-10072003"><br>
Again, it seems the MSH should have knowledge of the CPA.&nbsp;</span></font></font></font><br>
    </div>
  </blockquote>
</blockquote>
<br>
Having timeout is fine. We can just feed this CPA paramter to Hermes.
But other than timeout, Hermes has to determine whether the message
going through is a signal or a response, and this is the hardest part.<br>
<br>
Cheers, -Patrick<br>
<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] Hermes 1.0 my remarks

[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">
Negotiation of CPA out of CPPs? Is the CPPA spec making clear enough
for that? Anyway, we think Hermes should not touch on CPA file.<br>
<br>
Regards, -Patrick<br>
<br>
<blockquote type="cite"
 cite="mid...@po...">
  <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div>&nbsp;</div>
    <div><span class="034015223-09072003"><font face="Arial"><font
 face="Times New Roman" color="#0000ff" size="2"><span
 class="693592700-10072003">Do you, or anybody else , know of libraries
that can generate&nbsp;the values of&nbsp;elements in an&nbsp;ebxml envelop based on a
cpa&nbsp; (or better yet, 2 cpp's) ?</span></font></font></span></div>
    <div>&nbsp;</div>
  </blockquote>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] Hermes 1.0: CPA

[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">
<br>
<blockquote type="cite"
 cite="mid...@po...">
  <div><span class="839050200-10072003"><font face="Arial"
 color="#0000ff" size="2">It says the 'messaging service layer'. It
never says the 'sending msh' sould prevent sending messages that do not
conform to the cpa, although this seems good practice to me. Otoh it
only states "Any violation of the ground rules result in an error
condition, which is&nbsp;<font size="2"><font color="#0000ff"><font
 face="Arial">reported using the appropriate means.</font></font></font>".</font></span></div>
  <div>&nbsp;</div>
</blockquote>
The point is now: should the sending MSH checks the message to be sent
is compliant to CPA or not. Obviously this depends on whether the
sending MSH knows about the CPA (or its parameters) or not. My original
thinking is not for that... to simplify the registration process. <br>
<br>
Of course, I agree that adding those checkings make Hermes clearer. So,
if this is agreeable, we need to add the interface for client
application to specify CPA parameter in the sending object. Each
message sending through that sending object will got checked againist
the parameter.<br>
<br>
What do you think?<br>
<br>
<blockquote type="cite"
 cite="mid...@po..."><font
 face="Times New Roman"></font><span class="839050200-10072003">
  <div align="left"><font face="Times New Roman">&nbsp;</font><span
 class="839050200-10072003"><font face="Times New Roman"><font
 face="Arial" color="#0000ff" size="2">maybe we should have an
onError(), onNotify() as wel in the url/file/jms/... providers&nbsp;e.g. for
reporting back the things Patrick summed up (acks etc) but also
asynchronous reporting of 'your message does not comply with this cpa'
and other stuff. The onMessage, onError etc, could all go over
different channels, but I'm not for that. Different url's (but all
url's)&nbsp;or different&nbsp;directories (but al directories) seems ok to me&nbsp; <br>
  </font></font></span></div>
  </span></blockquote>
<br>
To make it more generic, we propose to allow applications to register
(i.e. subscribe) to different channels for receiving those things. All
channels should provide a onMessage() method.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] Hermes 1.0: CPA

[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">
We want to keep Hermes to be parameter driven, instead of CPA file
driven. <br>
<br>
In other words, we assume there is an external module which parse the
CPA file, all necessary CPA parameters should be fed to Hermes as
parameters. <br>
<br>
For sending, we have 2 kinds of parameters: set on SOAP message, and
not set on SOAP message. Therefore, we propose to set those parameters
on the EbxmlMessage object and also the send() method. CpaResolver is
not desirable as we don't want to touch on CPA file. What do you think?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
pykoon wrote:<br>
<blockquote type="cite" cite="mid...@ce...">Dear all,<br>
Please note in the CPA Specification, the AckRequested,
DuplicateElimination
value can be defined as "perMessage", which the user should have to
specify
whether it needs AckRequested and DuplicateElimination. Therefore they
should
know about it if such CPA occurs.<br>
  <br>
Regards,<br>
Bob Koon<br>
  <br>
Mayne, Peter wrote:<br>
  <blockquote type="cite"
 cite="mid:5E9...@s-...">
    <title>Message</title>
    <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
    <div><span class="034015223-09072003"><font face="Arial" size="2">That's
why it requires more thought. :-) AckRequested, DuplicateElimination
are
physically specified in the SOAPMessage, but RetryInterval, Retries
aren't.</font></span></div>
    <div>&nbsp;</div>
    <div><span class="034015223-09072003"><font face="Arial" size="2">My
current
model has a central Sender process that is the funnel point for
outgoing
messages. A client that wants to send a message creates its payload,
and&nbsp;tells
the Sender (via JMS) "send message type X, using CPA Y, with this
payload
Z". The clients have no concept of an EbxmlMessage object,
or&nbsp;AckRequested,
or RetryInterval, etc. And why should they, since all that belongs in
the CPA.</font></span></div>
    <div>&nbsp;</div>
    <div><span class="034015223-09072003"><font face="Arial" size="2">PJDM</font></span></div>
<!-- Converted from text/plain format -->
    <p><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></p>
    <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> Ronald van Kuijk [<a class="moz-txt-link-freetext"
 href="mailto:rv...@ab...">mailto:rv...@ab...</a>] <br>
      <b>Sent:</b> Thursday, 10 July 2003 9:47 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] Hermes 1.0 my remarks<br>
      <br>
      </font></div>
      <div><font face="Arial" color="#0000ff" size="2">
      <div><span class="361055900-09072003"><font face="Arial"><font
 color="#0000ff"><font size="2"><span class="607403323-09072003">Correct
me if i'm wrong, but aren't RetryInterval, Retries etc as much
part of the message as SyncReply? And aren't AckRequested,
DuplicateElimination
not also defined in the CPA (E.5.2.2), just as role, service, action
etc....</span></font></font></font></span></div>
      <div>&nbsp;</div>
      <div><span class="361055900-09072003"><font face="Arial"><font
 color="#0000ff"><font size="2"><span class="607403323-09072003">This
make the 'this is CPA, this is Message' discussion not clearer.</span></font></font></font></span></div>
      <div>&nbsp;</div>
      <div><span class="361055900-09072003"><font face="Arial"><font
 color="#0000ff"><font size="2"><span class="607403323-09072003">I
agree that the sending MSH should (or must? ;-)) have knowledge of the
CPA.&nbsp;I'll&nbsp;look into&nbsp;what&nbsp;the ebXML TA says about this? (<a
 href="http://www.ebxml.org/specs/ebTA.pdf">
http://www.ebxml.org/specs/ebTA.pdf</a>
)</span></font></font></font></span></div>
      <div>&nbsp;</div>
      <div><span class="361055900-09072003"><font face="Arial"><font
 color="#0000ff"><font size="2"><span class="607403323-09072003">Ronald</span></font></font></font></span></div>
      </font></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> Mayne, Peter [<a class="moz-txt-link-freetext"
 href="mailto:Pet...@ap...">mailto:Pet...@ap...</a>]<br>
        <b>Verzonden:</b> donderdag 10 juli 2003 1:17<br>
        <b>Aan:</b> '<a class="moz-txt-link-abbreviated"
 href="mailto:ebx...@li...">ebx...@li...</a>'<br>
        <b>Onderwerp:</b> RE: [ebxmlms-develop] Hermes 1.0 my remarks<br>
        <br>
        </font></div>
        <div><span class="361055900-09072003"><span
 class="525021223-09072003"><font face="Arial" size="2">I said:</font></span></span></div>
        <div>&nbsp;</div>
        <div><span class="361055900-09072003"><font face="Arial"><font
 color="#0000ff"><font size="2">I think parameters should be carefully
classified. Those that are part
of a message (AckRequested, DuplicateElimination, etc) should be set
in the EbxmlMessage. Those that are part of the CPA (retries, retry
interval, etc), and are *not* part of the message, or of an individual
send(), should *not* be set in the message or as send()
parameters.&nbsp;Instead,
they should be provided by the CpaResolver.<br>
        </font></font></font></span></div>
        <div><span class="525021223-09072003"><font face="Arial"
 size="2">This
requires some more thought. For instance, even though syncReply is part
of the message, it is specified in the CPA, so a client shouldn't have
to set it.</font></span></div>
        <div>&nbsp;</div>
        <div><span class="525021223-09072003"><font face="Arial"
 size="2">Furthermore,
the spec says "<font face="Arial" size="2">This element MUST NOT be
used to override the value of </font><b><i><font
 face="Arial,BoldItalic" size="2">
syncReplyMode </font></i></b><font face="Arial" size="2">in the CPA</font><b><i><font
 face="Arial,BoldItalic" size="2">
. </font></i></b><font face="Arial" size="2">If the value of </font><b><i><font
 face="Arial,BoldItalic" size="2">
syncReplyMode </font></i></b><font face="Arial" size="2">is </font><b><i><font
 face="Arial,BoldItalic" size="2">
none </font></i></b><font face="Arial" size="2">and a </font><b><i><font
 face="Arial,BoldItalic" size="2">
SyncReply </font></i></b><font face="Arial" size="2">element is
present,
the </font><i><font face="Arial,Italic" size="2">Receiving MSH </font></i><font
 face="Arial" size="2">
should issue an error </font><font face="Arial" size="2">with </font><b><i><font
 face="Arial,BoldItalic" size="2">
errorCode </font></i></b><font face="Arial" size="2">of </font><b><i><font
 face="Arial,BoldItalic" size="2">
Inconsistent </font></i></b><font face="Arial" size="2">and a </font><b><i><font
 face="Arial,BoldItalic" size="2">
severity </font></i></b><font face="Arial" size="2">of </font><b><i><font
 face="Arial,BoldItalic" size="2">
Error</font></i></b></font></span><span class="525021223-09072003"><font
 face="Arial" size="2">
."</font></span></div>
        <div>&nbsp;</div>
        <div><span class="525021223-09072003"><font face="Arial"
 size="2">To
check incoming messages, the MSH must have access to the CPA.
Therefore,
it makes sense that the MSH should have access to the CPA to build
outgoing
messages as well.</font></span></div>
        <div>&nbsp;</div>
        <div><span class="525021223-09072003"><font face="Arial"
 size="2">PJDM</font></span></div>
<!-- Converted from text/plain format -->
        <div><font face="Arial" 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>
        <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>
  <br>
</blockquote>
</body>
</html>

RE: [ebxmlms-develop] Hermes 1.0: sync reply

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

I agree it is diffucult (and don't appologize for your English... mine
is probably even worse ;-))

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: donderdag 10 juli 2003 11:09
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0: sync reply


Agreed to implement sync reply. It's a bit complicated. Let me try to
explain the difficulties here... (please bear with my poor English)..

When Hermes is the sending out message, it normally will wait for the
HTTP response code. In case of the response message coming from the same
HTTP connection, Hermes can now handle it.

When Hermes is receiving messages, by the current implementation, it
will close the HTTP connection after all data from the message has been
read. So, to implement sync reply, we should keep that connection in
memory without closing it. To be precise, there will be a mapping of
AppContext and HTTP connection kept in memory. 
[Ronald van Kuijk] 
The AppContext? Should'n it be a reference to this specific message? 
 
 Whenever the application command to send out a message, that mapping is
being looked up to see any opened HTTP connection ready to use. If there
is one, Hermes should use that HTTP connection to send out the message.
If not found, Hermes should open a new connection.

Here is the difficult part: when should we close that connection? Oh
yes, that should be controlled by a CPA parameter: syncReplyMode. The
possible values are mshSignalsOnly, signalsOnly, responseOnly,
signalsAndResponse, none. 

Easy for mshSignalsOnly. Since those ACKs are generated by Hermes, after
those ACKs has been sent, Hermes can then close the connection.

For signalsOnly, responseOnly and signalsAndResponse, Hermes has no idea
about when to close the connection. The reason is Hermes does not know
the message being sent is actually a signal or a response.

Our conclusion is, it is hard to manage the keep alive connection if
Hermes doesn't know about the business process.
[Ronald van Kuijk] 
I agree. Isn't the there a SyncReply timeout in the CPA  e.g. 8.4.14.10:


8.4.14.10 timeToPerform attribute

The timeToPerform attribute is of type duration [XMLSCHEMA-2]. It
specifies the time period,
starting from the initiation of the RequestingBusinessActivity, within
which the initiator of the
transaction MUST have received the response, i.e., the business document
associated with the
RespondingBusinessActivity.
NOTE: The timeToPerform attribute associated with a BinaryCollaboration
in BPSS is
currently not modeled in this specification. Therefore, it cannot be
overridden. In other
words, the value specified at the BPSS level MUST be used.
When synchronous reply mode is in use (see Section 8.4.23.1), the
TimeToPerform value
SHOULD be used as the connection timeout.

 

Again, it seems the MSH should have knowledge of the CPA. 

Any comments?
[Ronald van Kuijk] 
hth 

Cheers, -Patrick



Ronald van Kuijk wrote:


Yes, but can the response come from an application or only acks/errors .
The last is currently the case or am I wrong?
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [ mailto:Pet...@ap...
<mailto:Pet...@ap...> ]
Verzonden: donderdag 10 juli 2003 0:36
Aan: ' ebx...@li...
<mailto:ebx...@li...> '
Onderwerp: RE: [ebxmlms-develop] Hermes 1.0: sync reply



If I send a message over HTTP with SyncReply set, Hermes will send a
response back using the same HTTP connection. Is this what you mean, or
am I confused?

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: Wednesday, 9 July 2003 7:14 PM 
> To: ' ebx...@li...
<mailto:ebx...@li...> ' 
> Subject: RE: [ebxmlms-develop] Hermes 1.0: sync reply 
> 
> 
> I didn't really look into this, but afaik SyncReply is not 
> implemented. 
> To be able to use hermes in a web-service (RPC?) like fashion, I think

> we should implement this (in a plugable way) as wel. 
> 
> Ronald 
> 
> > -----Oorspronkelijk bericht----- 
> > Van: Patrick Yee [ mailto:kc...@ce...
<mailto:kc...@ce...> ] 
> > Verzonden: dinsdag 8 juli 2003 10:32 
> > Aan: ebx...@li...
<mailto:ebx...@li...>  
> > Onderwerp: [ebxmlms-develop] Hermes 1.0 
> > 
> > 
> > Dear all, 
> > 
> > I drafted a document, which describe the area we may need to 
> > re-engineer 
> > and the features we want to have in the 1.0 version. Please comment.

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

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.





    

------------------------------------------------------- This SF.Net
email sponsored by: Parasoft Error proof Web apps, automate testing &
more. Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv=3D"Content-Type" content=3D"text/html;charset=3DUTF-8"=
>
  <title></title>
</head>
<body text=3D"#000000" bgcolor=3D"#ffffff">
Thanks for your effort ... yes, if we have an example, it is easier for
us to evaluate the mechanism. <br>
Cheers, -Patrick<br>
<br>
<br>
Ronald van Kuijk wrote:<br>
<blockquote type=3D"cite"
 cite=3D"mid...@po...">
  <meta http-equiv=3D"Content-Type" content=3D"text/html; ">
  <title></title>
  <meta content=3D"MSHTML 5.50.4916.2300" name=3D"GENERATOR">
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">not only lookup the url, but find the
corresponding class as well. But I agree, if it becomes to complicated
don't use it. Therefor i'll try to create a small example over the
weekend.</font></span></div>
  <div>=C2=A0</div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Should it be able to run in a servlet engin=
e?
Good question. Answer could be yes, but otoh if additional freatures
that are already part of j2ee are 'rebuild'</font></span></div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">- queue's</font></span></div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">- transactions</font></span></div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">- connection pools</font></span></div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">- ...</font></span></div>
  <div>=C2=A0</div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">If it is done with hooks, both could be use=
d,
the hermes-custom-build transactions/pools or those that are already in
a j2ee server. I don't know. </font></span><span
 class=3D"301411608-10072003"><font face=3D"Arial" color=3D"#0000ff" size=
=3D"2">Even
tomcat already supports connectionpools, and to some extend
transactions.</font></span></div>
  <div>=C2=A0</div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">I'll try to draw up a picture as well and p=
ut
in on the wiki site. I'll try to summarize these discussions as wel
(busy weekend)</font></span></div>
  <div>=C2=A0</div>
  <div><span class=3D"301411608-10072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Ronald</font></span></div>
  <div><font face=3D"Tahoma"><br>
  <font size=3D"2">-----Oorspronkelijk bericht-----<br>
  <b>Van:</b> Patrick Yee [<a class=3D"moz-txt-link-freetext" href=3D"mai=
lto:kc...@ce...">mailto:kc...@ce...</a>]<br>
  <b>Verzonden:</b> donderdag 10 juli 2003 10:03<br>
  <b>Aan:</b> <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:ebxmlm=
s-d...@li...">ebx...@li...</a=
><br>
  <b>Onderwerp:</b> Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)<br>
  <br>
  </font></font></div>
  <blockquote
 style=3D"border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margi=
n-left: 5px;">On
the second thought... are we sure to introduce JNDI lookup even we just
want to lookup a HTTP URL? Using JNDI to lookup JMS location makes
sense, this is a common practice as far as I know. But, is it too heavy
to introduce a JNDI provider if the role of the JNDI is just to lookup
a simple URL?<br>
    <br>
One of the "features" of Hermes is that it can run on a simple servlet
engine. Is it desirable to keep that feature?<br>
    <br>
Cheers, -Patrick<br>
    <br>
    <br>
Ronald van Kuijk wrote:<br>
    <blockquote
 cite=3D"mid...@po..."
 type=3D"cite">
      <meta content=3D"MSHTML 5.50.4916.2300" name=3D"GENERATOR">
      <style></style>
      <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Great, but the file and url providers could
be implemented in the same way. </font></span></div>
      <div>=C2=A0</div>
      <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Use a jndi lookup to find a 'server-side
delivery provider' which knows how and where to read it's own
properties.=C2=A0The url is a property of this provider, just like the jm=
s
server, factory, username's, passwords, certificates=C2=A0etc. (in any mi=
x).
Dynamic registration could follow the same lines.</font></span></div>
      <div>=C2=A0</div>
      <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">URL and File are just=C2=A0pre-packaged cus=
tom
delivery options</font></span></div>
      <div>=C2=A0</div>
      <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Ronald</font></span></div>
      <div>=C2=A0</div>
      <div>=C2=A0</div>
      <div>=C2=A0</div>
      <blockquote dir=3D"ltr"
 style=3D"border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margi=
n-left: 5px; margin-right: 0px;">
        <div class=3D"OutlookMessageHeader" dir=3D"ltr" align=3D"left"><f=
ont
 face=3D"Tahoma" size=3D"2">-----Oorspronkelijk bericht-----<br>
        <b>Van:</b> Patrick Yee [<a class=3D"moz-txt-link-freetext"
 href=3D"mailto:kc...@ce...">mailto:kc...@ce...</a>]<br>
        <b>Verzonden:</b> woensdag 9 juli 2003 15:07<br>
        <b>Aan:</b> <a class=3D"moz-txt-link-abbreviated"
 href=3D"mailto:ebx...@li...">ebxmlms-develop@li=
sts.sourceforge.net</a><br>
        <b>Onderwerp:</b> Re: [ebxmlms-develop] Hermes 1.0 (JMS
delivery)<br>
        <br>
        </font></div>
        <div><font face=3D"Arial" size=3D"2">Agreed with JNDI contexts.
That's why I propose to use a Properties object. My proposal is: we
provide hook for a client to specify which server side delivery hook to
be used. To specify, the client specify the class name of the hook,
together with a Properties object for configuration like JNDI contexts.
Hermes can then initialize the class using the Properties object in
server side. When an incoming message arrives, the onMessage() method
of that class will be called to delivery the message.</font></div>
        <div>=C2=A0</div>
        <div><font face=3D"Arial" size=3D"2">This proposal is what I call=
ed
"customized server side delivery".</font></div>
        <div>=C2=A0</div>
        <div><font face=3D"Arial" size=3D"2">Regards, -Patrick</font></di=
v>
        <div>=C2=A0</div>
        <blockquote dir=3D"ltr"
 style=3D"border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; paddin=
g-left: 5px; margin-left: 5px; margin-right: 0px;">
          <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;">-----
Original Message ----- </div>
          <div
 style=3D"background: rgb(228, 228, 228) none repeat scroll 0% 50%; -moz-=
background-clip: initial; -moz-background-inline-policy: initial; -moz-ba=
ckground-origin: initial; font-family: arial; font-style: normal; font-va=
riant: normal; font-weight: normal; font-size: 10pt; line-height: normal;=
 font-stretch: normal; font-size-adjust: none;"><b>From:</b>
          <a title=3D"rv...@ab..." href=3D"mailto:rv...@ab...">Rona=
ld
van Kuijk</a> </div>
          <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;"><b>To:</b>
          <a title=3D"ebx...@li..."
 href=3D"mailto:%27e...@li...%27">'ebxmlms-dev=
el...@li...'</a>
          </div>
          <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;"><b>Sent:</b>
Wednesday, July 09, 2003 07:00 PM</div>
          <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;"><b>Subject:</b>
RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)</div>
          <div><br>
          </div>
          <div><span class=3D"328575010-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">don't use url's but an alternative method
(jndi contexts?)=C2=A0The can be used for filesystem etc. as well.</font>=
</span></div>
          <div>=C2=A0</div>
          <div><span class=3D"328575010-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">A client registers which jndi name has to b=
e
used by the server to lookup the component for delivery.</font></span></d=
iv>
          <div>=C2=A0</div>
          <div><span class=3D"328575010-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Ronald</font></span></div>
          <blockquote
 style=3D"border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margi=
n-left: 5px;">
            <div class=3D"OutlookMessageHeader" dir=3D"ltr" align=3D"left=
"><font
 face=3D"Tahoma" size=3D"2">-----Oorspronkelijk bericht-----<br>
            <b>Van:</b> Patrick Yee [<a class=3D"moz-txt-link-freetext"
 href=3D"mailto:kc...@ce...">mailto:kc...@ce...</a>]<br>
            <b>Verzonden:</b> woensdag 9 juli 2003 12:30<br>
            <b>Aan:</b> <a
 href=3D"mailto:ebx...@li...">ebxmlms-develop@li=
sts.sourceforge.net</a><br>
            <b>Onderwerp:</b> Re: [ebxmlms-develop] Hermes 1.0 (JMS
delivery)<br>
            <br>
            </font></div>
How to specify the JMS destination in the form of a URL, if the single
server-side mode only provides an interface for specifying a URL?<br>
Regards, -Patrick<br>
            <br>
            <br>
Mayne, Peter wrote:<br>
            <blockquote
 cite=3D"mid...@s-...=
m.au"
 type=3D"cite">
              <meta content=3D"MSHTML 6.00.2800.1141" name=3D"GENERATOR">
              <div><font size=3D"2"><font color=3D"#0000ff"><span
 class=3D"361055900-09072003"><font face=3D"Arial" color=3D"#000000" size=
=3D"2">(Server
side delivery mode)</font></span></font></font></div>
              <div>=C2=A0</div>
              <div><font size=3D"2"><font color=3D"#0000ff"><font
 face=3D"Arial">- Shouldn't all (server side ones) implement the same
interface<span class=3D"361055900-09072003"> </span></font></font><font
 face=3D"Arial"><font color=3D"#0000ff">(onMessage()?) and File and URL
just be some de</font><font color=3D"#0000ff">fault included<span
 class=3D"361055900-09072003"> </span></font></font></font><font
 face=3D"Arial" color=3D"#0000ff" size=3D"2">implementations? (Isn't this
also a 'hook'?)</font></div>
              <div>=C2=A0</div>
              <div><span class=3D"361055900-09072003"><font face=3D"Arial=
"
 size=3D"2">I was thinking exactly the same thing. :-) There should be
only one server-side=C2=A0mode, with a trusted repository and URL redirec=
t
provided as implementations of that mode. If "customised mode" isn't
good enough to implement trusted repository or URL redirect, then it
probably isn't good enough for much else either.</font></span></div>
              <font color=3D"#0000ff" size=3D"2"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">
              <p align=3D"left">I'd vote for a jms implementation to and
volunteer to implement one</p>
              </font></font>
              <div><font face=3D"Arial" size=3D"2"><span
 class=3D"361055900-09072003">I've done a JMS implementation, which is
what sparked some of the discussion about delivery modes. However,
including it with Hermes may be problematic: since JMS isn't part of
the standard JRE, it would not be possible to build Hermes unless you
had a JMS implementation. Maybe we could have a "contributions" library.<=
/span></font></div>
              <div>=C2=A0</div>
            </blockquote>
------------------------------------------------------- This SF.Net
email sponsored by: Parasoft Error proof Web apps, automate testing
&amp; more. Download &amp; eval WebKing and get a free book. <a
 class=3D"moz-txt-link-abbreviated"
 href=3D"http://www.parasoft.com/bulletproofapps">www.parasoft.com/bullet=
proofapps</a>
_______________________________________________ ebxmlms-develop mailing
list <a class=3D"moz-txt-link-abbreviated"
 href=3D"mailto:ebx...@li...">ebxmlms-develop@li=
sts.sourceforge.net</a>
            <a class=3D"moz-txt-link-freetext"
 href=3D"https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop">ht=
tps://lists.sourceforge.net/lists/listinfo/ebxmlms-develop</a></blockquot=
e>
        </blockquote>
      </blockquote>
    </blockquote>
------------------------------------------------------- This SF.Net
email sponsored by: Parasoft Error proof Web apps, automate testing
&amp; more. Download &amp; eval WebKing and get a free book.
<a class=3D"moz-txt-link-abbreviated" href=3D"http://www.parasoft.com/bul=
letproofapps">www.parasoft.com/bulletproofapps</a>
_______________________________________________ ebxmlms-develop mailing
list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:ebxmlms-develop=
@lists.sourceforge.net">ebx...@li...</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.sourceforge.net/=
lists/listinfo/ebxmlms-develop">https://lists.sourceforge.net/lists/listi=
nfo/ebxmlms-develop</a></blockquote>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] Hermes 1.0: sync reply

[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">
Agreed to implement sync reply. It's a bit complicated. Let me try to
explain the difficulties here... (please bear with my poor English)..<br>
<br>
When Hermes is the sending out message, it normally will wait for the
HTTP response code. In case of the response message coming from the
same HTTP connection, Hermes can now handle it.<br>
<br>
When Hermes is receiving messages, by the current implementation, it
will close the HTTP connection after all data from the message has been
read. So, to implement sync reply, we should keep that connection in
memory without closing it. To be precise, there will be a mapping of
AppContext and HTTP connection kept in memory. Whenever the application
command to send out a message, that mapping is being looked up to see
any opened HTTP connection ready to use. If there is one, Hermes should
use that HTTP connection to send out the message. If not found, Hermes
should open a new connection.<br>
<br>
Here is the difficult part: when should we close that connection? Oh
yes, that should be controlled by a CPA parameter: syncReplyMode. The
possible values are mshSignalsOnly, signalsOnly, responseOnly,
signalsAndResponse, none. <br>
<br>
Easy for mshSignalsOnly. Since those ACKs are generated by Hermes,
after those ACKs has been sent, Hermes can then close the connection.<br>
<br>
For signalsOnly, responseOnly and signalsAndResponse, Hermes has no
idea about when to close the connection. The reason is Hermes does not
know the message being sent is actually a signal or a response.<br>
<br>
Our conclusion is, it is hard to manage the keep alive connection if
Hermes doesn't know about the business process.<br>
<br>
Any comments?<br>
<br>
Cheers, -Patrick<br>
<br>
<br>
<br>
Ronald van Kuijk wrote:<br>
<blockquote type="cite"
 cite="mid...@po...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>RE: [ebxmlms-develop] Hermes 1.0: sync reply</title>
  <meta content="MSHTML 5.50.4916.2300" name="GENERATOR">
  <div><span class="417445422-09072003"><font face="Arial"
 color="#0000ff" size="2">Yes, but can the response come from an
application or only acks/errors . The last is currently the case or am
I wrong?</font></span></div>
  <div>&nbsp;</div>
  <div><span class="417445422-09072003"><font face="Arial"
 color="#0000ff" size="2">Ronald</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> Mayne, Peter [<a class="moz-txt-link-freetext" href="mailto:Pet...@ap...">mailto:Pet...@ap...</a>]<br>
    <b>Verzonden:</b> donderdag 10 juli 2003 0:36<br>
    <b>Aan:</b> '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>'<br>
    <b>Onderwerp:</b> RE: [ebxmlms-develop] Hermes 1.0: sync reply<br>
    <br>
    </font></div>
    <p><font size="2">If I send a message over HTTP with SyncReply set,
Hermes will send a response back using the same HTTP connection. Is
this what you mean, or am I confused?</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>
    <p><font size="2">&gt; -----Original Message-----</font> <br>
    <font size="2">&gt; From: Ronald van Kuijk [<a
 href="mailto:rv...@ab...">mailto:rv...@ab...</a>] </font><br>
    <font size="2">&gt; Sent: Wednesday, 9 July 2003 7:14 PM</font> <br>
    <font size="2">&gt; To: '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>'</font>
    <br>
    <font size="2">&gt; Subject: RE: [ebxmlms-develop] Hermes 1.0: sync
reply</font> <br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; I didn't really look into this, but afaik
SyncReply is not </font><br>
    <font size="2">&gt; implemented.</font> <br>
    <font size="2">&gt; To be able to use hermes in a web-service
(RPC?) like fashion, I think</font> <br>
    <font size="2">&gt; we should implement this (in a plugable way) as
wel.</font> <br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; Ronald</font> <br>
    <font size="2">&gt; </font><br>
    <font size="2">&gt; &gt; -----Oorspronkelijk bericht-----</font> <br>
    <font size="2">&gt; &gt; Van: Patrick Yee [<a
 href="mailto:kc...@ce...">mailto:kc...@ce...</a>]</font>
    <br>
    <font size="2">&gt; &gt; Verzonden: dinsdag 8 juli 2003 10:32</font>
    <br>
    <font size="2">&gt; &gt; Aan: <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a></font>
    <br>
    <font size="2">&gt; &gt; Onderwerp: [ebxmlms-develop] Hermes 1.0</font>
    <br>
    <font size="2">&gt; &gt; </font><br>
    <font size="2">&gt; &gt; </font><br>
    <font size="2">&gt; &gt; Dear all,</font> <br>
    <font size="2">&gt; &gt; </font><br>
    <font size="2">&gt; &gt; I drafted a document, which describe the
area we may need to </font><br>
    <font size="2">&gt; &gt; re-engineer </font><br>
    <font size="2">&gt; &gt; and the features we want to have in the
1.0 version. Please comment.</font> <br>
    <font size="2">&gt; &gt; </font><br>
    <font size="2">&gt; &gt; Regards, -Patrick</font> <br>
    <font size="2">&gt; &gt; </font><br>
    <font size="2">&gt; </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>
</body>
</html>

RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

not only lookup the url, but find the corresponding class as well. But I
agree, if it becomes to complicated don't use it. Therefor i'll try to
create a small example over the weekend.
 
Should it be able to run in a servlet engine? Good question. Answer
could be yes, but otoh if additional freatures that are already part of
j2ee are 'rebuild'
- queue's
- transactions
- connection pools
- ...
 
If it is done with hooks, both could be used, the hermes-custom-build
transactions/pools or those that are already in a j2ee server. I don't
know. Even tomcat already supports connectionpools, and to some extend
transactions.
 
I'll try to draw up a picture as well and put in on the wiki site. I'll
try to summarize these discussions as wel (busy weekend)
 
Ronald

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: donderdag 10 juli 2003 10:03
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)



On the second thought... are we sure to introduce JNDI lookup even we
just want to lookup a HTTP URL? Using JNDI to lookup JMS location makes
sense, this is a common practice as far as I know. But, is it too heavy
to introduce a JNDI provider if the role of the JNDI is just to lookup a
simple URL?

One of the "features" of Hermes is that it can run on a simple servlet
engine. Is it desirable to keep that feature?

Cheers, -Patrick


Ronald van Kuijk wrote:


Great, but the file and url providers could be implemented in the same
way. 
 
Use a jndi lookup to find a 'server-side delivery provider' which knows
how and where to read it's own properties. The url is a property of this
provider, just like the jms server, factory, username's, passwords,
certificates etc. (in any mix). Dynamic registration could follow the
same lines.
 
URL and File are just pre-packaged custom delivery options
 
Ronald
 
 
 

-----Oorspronkelijk bericht-----
Van: Patrick Yee [ mailto:kc...@ce... <mailto:kc...@ce...>
]
Verzonden: woensdag 9 juli 2003 15:07
Aan: ebx...@li...
<mailto:ebx...@li...> 
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)


Agreed with JNDI contexts. That's why I propose to use a Properties
object. My proposal is: we provide hook for a client to specify which
server side delivery hook to be used. To specify, the client specify the
class name of the hook, together with a Properties object for
configuration like JNDI contexts. Hermes can then initialize the class
using the Properties object in server side. When an incoming message
arrives, the onMessage() method of that class will be called to delivery
the message.
 
This proposal is what I called "customized server side delivery".
 
Regards, -Patrick
 

----- Original Message ----- 
From: Ronald van  <mailto:rv...@ab...> Kuijk 
To: 'ebx...@li...'
<mailto:%27e...@li...%27>  
Sent: Wednesday, July 09, 2003 07:00 PM
Subject: RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

don't use url's but an alternative method (jndi contexts?) The can be
used for filesystem etc. as well.
 
A client registers which jndi name has to be used by the server to
lookup the component for delivery.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Patrick Yee [ mailto:kc...@ce... <mailto:kc...@ce...>
]
Verzonden: woensdag 9 juli 2003 12:30
Aan: ebx...@li...
<mailto:ebx...@li...> 
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)


How to specify the JMS destination in the form of a URL, if the single
server-side mode only provides an interface for specifying a URL?
Regards, -Patrick


Mayne, Peter wrote:


(Server side delivery mode)
 
- Shouldn't all (server side ones) implement the same interface
(onMessage()?) and File and URL just be some default included
implementations? (Isn't this also a 'hook'?)
 
I was thinking exactly the same thing. :-) There should be only one
server-side mode, with a trusted repository and URL redirect provided as
implementations of that mode. If "customised mode" isn't good enough to
implement trusted repository or URL redirect, then it probably isn't
good enough for much else either.
I'd vote for a jms implementation to and volunteer to implement one

I've done a JMS implementation, which is what sparked some of the
discussion about delivery modes. However, including it with Hermes may
be problematic: since JMS isn't part of the standard JRE, it would not
be possible to build Hermes unless you had a JMS implementation. Maybe
we could have a "contributions" library.
 

------------------------------------------------------- This SF.Net
email sponsored by: Parasoft Error proof Web apps, automate testing &
more. Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
<http://www.parasoft.com/bulletproofapps>
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
<mailto:ebx...@li...>
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
<https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop> 

------------------------------------------------------- This SF.Net
email sponsored by: Parasoft Error proof Web apps, automate testing &
more. Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] Hermes 1.0: sync reply

[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">
You message is well signed. -Patrick<br>
<br>
<br>
<blockquote type="cite"
 cite="mid...@po...">
  <div>&nbsp;<span class="712110723-09072003"><font face="Arial"
 color="#0000ff" size="2">btw. does anybody have a problem with my
messages beiing digitally-signed</font></span></div>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv=3D"Content-Type" content=3D"text/html;charset=3DUTF-8"=
>
  <title></title>
</head>
<body text=3D"#000000" bgcolor=3D"#ffffff">
On the second thought... are we sure to introduce JNDI lookup even we
just want to lookup a HTTP URL? Using JNDI to lookup JMS location makes
sense, this is a common practice as far as I know. But, is it too heavy
to introduce a JNDI provider if the role of the JNDI is just to lookup
a simple URL?<br>
<br>
One of the "features" of Hermes is that it can run on a simple servlet
engine. Is it desirable to keep that feature?<br>
<br>
Cheers, -Patrick<br>
<br>
<br>
Ronald van Kuijk wrote:<br>
<blockquote type=3D"cite"
 cite=3D"mid...@po...">
  <meta http-equiv=3D"Content-Type" content=3D"text/html; ">
  <title></title>
  <meta content=3D"MSHTML 5.50.4916.2300" name=3D"GENERATOR">
  <style></style>
  <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Great, but the file and url providers could
be implemented in the same way. </font></span></div>
  <div>=C2=A0</div>
  <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Use a jndi lookup to find a 'server-side
delivery provider' which knows how and where to read it's own
properties.=C2=A0The url is a property of this provider, just like the jm=
s
server, factory, username's, passwords, certificates=C2=A0etc. (in any mi=
x).
Dynamic registration could follow the same lines.</font></span></div>
  <div>=C2=A0</div>
  <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">URL and File are just=C2=A0pre-packaged cus=
tom
delivery options</font></span></div>
  <div>=C2=A0</div>
  <div><span class=3D"381441121-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Ronald</font></span></div>
  <div>=C2=A0</div>
  <div>=C2=A0</div>
  <div>=C2=A0</div>
  <blockquote dir=3D"ltr"
 style=3D"border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margi=
n-left: 5px; margin-right: 0px;">
    <div class=3D"OutlookMessageHeader" dir=3D"ltr" align=3D"left"><font
 face=3D"Tahoma" size=3D"2">-----Oorspronkelijk bericht-----<br>
    <b>Van:</b> Patrick Yee [<a class=3D"moz-txt-link-freetext" href=3D"m=
ailto:kc...@ce...">mailto:kc...@ce...</a>]<br>
    <b>Verzonden:</b> woensdag 9 juli 2003 15:07<br>
    <b>Aan:</b> <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:ebxm=
lms...@li...">ebx...@li...<=
/a><br>
    <b>Onderwerp:</b> Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)<br>
    <br>
    </font></div>
    <div><font face=3D"Arial" size=3D"2">Agreed with JNDI contexts. That'=
s
why I propose to use a Properties object. My proposal is: we provide
hook for a client to specify which server side delivery hook to be
used. To specify, the client specify the class name of the hook,
together with a Properties object for configuration like JNDI contexts.
Hermes can then initialize the class using the Properties object in
server side. When an incoming message arrives, the onMessage() method
of that class will be called to delivery the message.</font></div>
    <div>=C2=A0</div>
    <div><font face=3D"Arial" size=3D"2">This proposal is what I called
"customized server side delivery".</font></div>
    <div>=C2=A0</div>
    <div><font face=3D"Arial" size=3D"2">Regards, -Patrick</font></div>
    <div>=C2=A0</div>
    <blockquote dir=3D"ltr"
 style=3D"border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; paddin=
g-left: 5px; margin-left: 5px; margin-right: 0px;">
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;">-----
Original Message ----- </div>
      <div
 style=3D"background: rgb(228, 228, 228) none repeat scroll 0%; -moz-back=
ground-clip: initial; -moz-background-inline-policy: initial; -moz-backgr=
ound-origin: initial; font-family: arial; font-style: normal; font-varian=
t: normal; font-weight: normal; font-size: 10pt; line-height: normal; fon=
t-stretch: normal; font-size-adjust: none;"><b>From:</b>
      <a title=3D"rv...@ab..." href=3D"mailto:rv...@ab...">Ronald v=
an
Kuijk</a> </div>
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;"><b>To:</b>
      <a title=3D"ebx...@li..."
 href=3D"mailto:%27e...@li...%27">'ebxmlms-dev=
el...@li...'</a>
      </div>
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;"><b>Sent:</b>
Wednesday, July 09, 2003 07:00 PM</div>
      <div
 style=3D"font-family: arial; font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 10pt; line-height: normal; font-stretch: n=
ormal; font-size-adjust: none;"><b>Subject:</b>
RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)</div>
      <div><br>
      </div>
      <div><span class=3D"328575010-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">don't use url's but an alternative method
(jndi contexts?)=C2=A0The can be used for filesystem etc. as well.</font>=
</span></div>
      <div>=C2=A0</div>
      <div><span class=3D"328575010-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">A client registers which jndi name has to b=
e
used by the server to lookup the component for delivery.</font></span></d=
iv>
      <div>=C2=A0</div>
      <div><span class=3D"328575010-09072003"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">Ronald</font></span></div>
      <blockquote
 style=3D"border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margi=
n-left: 5px;">
        <div class=3D"OutlookMessageHeader" dir=3D"ltr" align=3D"left"><f=
ont
 face=3D"Tahoma" size=3D"2">-----Oorspronkelijk bericht-----<br>
        <b>Van:</b> Patrick Yee [<a class=3D"moz-txt-link-freetext" href=3D=
"mailto:kc...@ce...">mailto:kc...@ce...</a>]<br>
        <b>Verzonden:</b> woensdag 9 juli 2003 12:30<br>
        <b>Aan:</b> <a
 href=3D"mailto:ebx...@li...">ebxmlms-develop@li=
sts.sourceforge.net</a><br>
        <b>Onderwerp:</b> Re: [ebxmlms-develop] Hermes 1.0 (JMS
delivery)<br>
        <br>
        </font></div>
How to specify the JMS destination in the form of a URL, if the single
server-side mode only provides an interface for specifying a URL?<br>
Regards, -Patrick<br>
        <br>
        <br>
Mayne, Peter wrote:<br>
        <blockquote type=3D"cite"
 cite=3D"mid...@s-...=
m.au">
          <meta content=3D"MSHTML 6.00.2800.1141" name=3D"GENERATOR">
          <div><font size=3D"2"><font color=3D"#0000ff"><span
 class=3D"361055900-09072003"><font face=3D"Arial" color=3D"#000000" size=
=3D"2">(Server
side delivery mode)</font></span></font></font></div>
          <div>=C2=A0</div>
          <div><font size=3D"2"><font color=3D"#0000ff"><font face=3D"Ari=
al">-
Shouldn't all (server side ones) implement the same interface<span
 class=3D"361055900-09072003"> </span></font></font><font face=3D"Arial">=
<font
 color=3D"#0000ff">(onMessage()?) and File and URL just be some de</font>=
<font
 color=3D"#0000ff">fault included<span class=3D"361055900-09072003"> </sp=
an></font></font></font><font
 face=3D"Arial" color=3D"#0000ff" size=3D"2">implementations? (Isn't this
also a 'hook'?)</font></div>
          <div>=C2=A0</div>
          <div><span class=3D"361055900-09072003"><font face=3D"Arial"
 size=3D"2">I was thinking exactly the same thing. :-) There should be
only one server-side=C2=A0mode, with a trusted repository and URL redirec=
t
provided as implementations of that mode. If "customised mode" isn't
good enough to implement trusted repository or URL redirect, then it
probably isn't good enough for much else either.</font></span></div>
          <font color=3D"#0000ff" size=3D"2"><font face=3D"Arial"
 color=3D"#0000ff" size=3D"2">
          <p align=3D"left">I'd vote for a jms implementation to and
volunteer to implement one</p>
          </font></font>
          <div><font face=3D"Arial" size=3D"2"><span
 class=3D"361055900-09072003">I've done a JMS implementation, which is
what sparked some of the discussion about delivery modes. However,
including it with Hermes may be problematic: since JMS isn't part of
the standard JRE, it would not be possible to build Hermes unless you
had a JMS implementation. Maybe we could have a "contributions" library.<=
/span></font></div>
          <div>=C2=A0</div>
        </blockquote>
------------------------------------------------------- This SF.Net
email sponsored by: Parasoft Error proof Web apps, automate testing
&amp; more. Download &amp; eval WebKing and get a free book.
<a class=3D"moz-txt-link-abbreviated" href=3D"http://www.parasoft.com/bul=
letproofapps">www.parasoft.com/bulletproofapps</a>
_______________________________________________ ebxmlms-develop mailing
list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:ebxmlms-develop=
@lists.sourceforge.net">ebx...@li...</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.sourceforge.net/=
lists/listinfo/ebxmlms-develop">https://lists.sourceforge.net/lists/listi=
nfo/ebxmlms-develop</a></blockquote>
    </blockquote>
  </blockquote>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] Hermes 1.0 my remarks

[pykoon <py...@ce...>]

Dear all,
Please note in the CPA Specification, the AckRequested, 
DuplicateElimination value can be defined as "perMessage", which the 
user should have to specify whether it needs AckRequested and 
DuplicateElimination. Therefore they should know about it if such CPA 
occurs.

Regards,
Bob Koon

Mayne, Peter wrote:

> That's why it requires more thought. :-) AckRequested, 
> DuplicateElimination are physically specified in the SOAPMessage, but 
> RetryInterval, Retries aren't.
>
>  
>
> My current model has a central Sender process that is the funnel point 
> for outgoing messages. A client that wants to send a message creates 
> its payload, and tells the Sender (via JMS) "send message type X, 
> using CPA Y, with this payload Z". The clients have no concept of an 
> EbxmlMessage object, or AckRequested, or RetryInterval, etc. And why 
> should they, since all that belongs in the CPA.
>
>  
>
> PJDM
>
> --
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
>
>     -----Original Message-----
>     From: Ronald van Kuijk [mailto:rv...@ab...]
>     Sent: Thursday, 10 July 2003 9:47 AM
>     To: 'ebx...@li...'
>     Subject: RE: [ebxmlms-develop] Hermes 1.0 my remarks
>
>     Correct me if i'm wrong, but aren't RetryInterval, Retries etc as
>     much part of the message as SyncReply? And aren't AckRequested,
>     DuplicateElimination not also defined in the CPA (E.5.2.2), just
>     as role, service, action etc....
>
>      
>
>     This make the 'this is CPA, this is Message' discussion not clearer.
>
>      
>
>     I agree that the sending MSH should (or must? ;-)) have knowledge
>     of the CPA. I'll look into what the ebXML TA says about this? (
>     http://www.ebxml.org/specs/ebTA.pdf )
>
>      
>
>     Ronald
>
>         -----Oorspronkelijk bericht-----
>         Van: Mayne, Peter [mailto:Pet...@ap...]
>         Verzonden: donderdag 10 juli 2003 1:17
>         Aan: 'ebx...@li...'
>         Onderwerp: RE: [ebxmlms-develop] Hermes 1.0 my remarks
>
>         I said:
>
>          
>
>         I think parameters should be carefully classified. Those that
>         are part of a message (AckRequested, DuplicateElimination,
>         etc) should be set in the EbxmlMessage. Those that are part of
>         the CPA (retries, retry interval, etc), and are *not* part of
>         the message, or of an individual send(), should *not* be set
>         in the message or as send() parameters. Instead, they should
>         be provided by the CpaResolver.
>
>         This requires some more thought. For instance, even though
>         syncReply is part of the message, it is specified in the CPA,
>         so a client shouldn't have to set it.
>
>          
>
>         Furthermore, the spec says "This element MUST NOT be used to
>         override the value of syncReplyMode in the CPA . If the value
>         of syncReplyMode is none and a SyncReply element is present,
>         the Receiving MSH should issue an error with errorCode of
>         Inconsistent and a severity of Error ."
>
>          
>
>         To check incoming messages, the MSH must have access to the
>         CPA. Therefore, it makes sense that the MSH should have access
>         to the CPA to build outgoing messages as well.
>
>          
>
>         PJDM
>
>         --
>         Peter Mayne
>         Technology Consultant
>         Spherion Technology Solutions
>         Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
>         T: 61 2 62689727  F: 61 2 62689777
>
>The information contained in this email and any attachments to it:
>
>(a) may be confidential and if you are not the intended recipient, any interference with, 
>use, disclosure or copying of this material is unauthorised and prohibited; and
>
>(b) may contain personal information of the recipient and/or the sender as defined 
>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>collect, hold and use such information and any personal information contained in a 
>response to this email, for any reasonable purpose in the ordinary course of 
>Spherion's 
>business, including forwarding this email internally or disclosing it to a third party. All 
>personal information collected by Spherion will be handled in accordance with 
>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>sender and delete it.
>
>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>this email and any attachments without first entering into a contractual agreement with 
>Spherion. You further agree not to divulge any information contained in this document 
>to any person(s) or entities without the express permission of Spherion.
>
>

RE: [ebxmlms-develop] Hermes 1.0 my remarks

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

 

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


That's why it requires more thought. :-) AckRequested,
DuplicateElimination are physically specified in the SOAPMessage, but
RetryInterval, Retries aren't.
 
[Ronald van Kuijk]
Sorry I partly misunderstood you.(its late here, 02:35 AM, sleep is
taking over) You are right.
 
My current model has a central Sender process that is the funnel point
for outgoing messages. A client that wants to send a message creates its
payload, and tells the Sender (via JMS) "send message type X, using CPA
Y, with this payload Z". The clients have no concept of an EbxmlMessage
object, or AckRequested, or RetryInterval, etc. And why should they,
since all that belongs in the CPA.
[Ronald van Kuijk]
Yes that is the way it should work. Then a requirement for Hermes 2.0
could be the last 2 line of 8.5.3 of the ebTA spec:
 
    The ebXML Messaging Service SHALL help facilitate the Interface to
an ebXML Registry. 
 
with my addition: Including cpa negotiation.
 
Do you, or anybody else , know of libraries that can generate the values
of elements in an ebxml envelop based on a cpa  (or better yet, 2 cpp's)
?
 
Ronald
 
PJDM

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

-----Original Message-----
From: Ronald van Kuijk [mailto:rv...@ab...] 
Sent: Thursday, 10 July 2003 9:47 AM
To: 'ebx...@li...'
Subject: RE: [ebxmlms-develop] Hermes 1.0 my remarks



Correct me if i'm wrong, but aren't RetryInterval, Retries etc as much
part of the message as SyncReply? And aren't AckRequested,
DuplicateElimination not also defined in the CPA (E.5.2.2), just as
role, service, action etc....
 
This make the 'this is CPA, this is Message' discussion not clearer.
 
I agree that the sending MSH should (or must? ;-)) have knowledge of the
CPA. I'll look into what the ebXML TA says about this? (
http://www.ebxml.org/specs/ebTA.pdf
<http://www.ebxml.org/specs/ebTA.pdf> )
 
Ronald

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


I said:
 
I think parameters should be carefully classified. Those that are part
of a message (AckRequested, DuplicateElimination, etc) should be set in
the EbxmlMessage. Those that are part of the CPA (retries, retry
interval, etc), and are *not* part of the message, or of an individual
send(), should *not* be set in the message or as send() parameters.
Instead, they should be provided by the CpaResolver.

This requires some more thought. For instance, even though syncReply is
part of the message, it is specified in the CPA, so a client shouldn't
have to set it.
 
Furthermore, the spec says "This element MUST NOT be used to override
the value of syncReplyMode in the CPA. If the value of syncReplyMode is
none and a SyncReply element is present, the Receiving MSH should issue
an error with errorCode of Inconsistent and a severity of Error."
 
To check incoming messages, the MSH must have access to the CPA.
Therefore, it makes sense that the MSH should have access to the CPA to
build outgoing messages as well.
 
PJDM
--
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727  F: 61 2 62689777

The information contained in this email and any attachments to it:



(a) may be confidential and if you are not the intended recipient, any
interference with, 

use, disclosure or copying of this material is unauthorised and
prohibited; and



(b) may contain personal information of the recipient and/or the sender
as defined 

under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to 

collect, hold and use such information and any personal information
contained in a 

response to this email, for any reasonable purpose in the ordinary
course of 

Spherion's 

business, including forwarding this email internally or disclosing it to
a third party. All 

personal information collected by Spherion will be handled in accordance
with 

Spherion's Privacy Policy. If you have received this email in error,
please notify the 

sender and delete it.



(c) you agree not to employ or arrange employment for any candidate(s)
supplied in 

this email and any attachments without first entering into a contractual
agreement with 

Spherion. You further agree not to divulge any information contained in
this document 

to any person(s) or entities without the express permission of Spherion.

RE: [ebxmlms-develop] Hermes 1.0 my remarks

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

>From the ebTA docs:
 
8.5.2
 
The ebXML Messaging Service Layer enforces the "rules of engagement" as
defined by 
two Trading Partners in a Collaboration Protocol Agreement (including,
but not limited 
to security and Business Process functions related to Message delivery).
The
Collaboration Protocol Agreement defines the acceptable behavior by
which each 
Trading Partner agrees to abide. The definition of these ground rules
can take many 
forms including formal Collaboration Protocol Agreements, interactive
agreements 
established at the time a business transaction occurs (e.g. buying a
book online), or other 
forms of agreement. There are Messaging Service Layer functions that
enforce these
ground rules. Any violation of the ground rules result in an error
condition, which is 
reported using the appropriate means.
 
It says the 'messaging service layer'. It never says the 'sending msh'
sould prevent sending messages that do not conform to the cpa, although
this seems good practice to me. Otoh it only states "Any violation of
the ground rules result in an error condition, which is reported using
the appropriate means.".
 
In 8.5.3 they state
 
The ebXML Messaging Service provides ebXML with an abstract Interface
whose functions, at an abstract level, include:
· Send – send an ebXML Message – values for the parameters are derived
from the ebXML Message Headers.
· Receive – indicates willingness to receive an ebXML Message.
· Notify – provides notification of expected and unexpected events.
· Inquire – provides a method of querying the status of the particular
ebXML Message interchange.
 
The ebXML Messaging Service SHALL interface with internal systems
including:
· Routing of received Messages to internal systems
· Error notification
 
maybe we should have an onError(), onNotify() as wel in the
url/file/jms/... providers e.g. for reporting back the things Patrick
summed up (acks etc) but also asynchronous reporting of 'your message
does not comply with this cpa' and other stuff. The onMessage, onError
etc, could all go over different channels, but I'm not for that.
Different url's (but all url's) or different directories (but al
directories) seems ok to me  
 

-----Oorspronkelijk bericht-----
Van: Ronald van Kuijk [mailto:rv...@ab...]
Verzonden: donderdag 10 juli 2003 1:47
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Hermes 1.0 my remarks
 


Correct me if i'm wrong, but aren't RetryInterval, Retries etc as much
part of the message as SyncReply? And aren't AckRequested,
DuplicateElimination not also defined in the CPA (E.5.2.2), just as
role, service, action etc....
 
This make the 'this is CPA, this is Message' discussion not clearer.
 
I agree that the sending MSH should (or must? ;-)) have knowledge of the
CPA. I'll look into what the ebXML TA says about this? (
http://www.ebxml.org/specs/ebTA.pdf
<http://www.ebxml.org/specs/ebTA.pdf> )
 
Ronald

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


I said:
 
I think parameters should be carefully classified. Those that are part
of a message (AckRequested, DuplicateElimination, etc) should be set in
the EbxmlMessage. Those that are part of the CPA (retries, retry
interval, etc), and are *not* part of the message, or of an individual
send(), should *not* be set in the message or as send() parameters.
Instead, they should be provided by the CpaResolver.

This requires some more thought. For instance, even though syncReply is
part of the message, it is specified in the CPA, so a client shouldn't
have to set it.
 
Furthermore, the spec says "This element MUST NOT be used to override
the value of syncReplyMode in the CPA. If the value of syncReplyMode is
none and a SyncReply element is present, the Receiving MSH should issue
an error with errorCode of Inconsistent and a severity of Error."
 
To check incoming messages, the MSH must have access to the CPA.
Therefore, it makes sense that the MSH should have access to the CPA to
build outgoing messages as well.
 
PJDM
--
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727  F: 61 2 62689777

The information contained in this email and any attachments to it:



(a) may be confidential and if you are not the intended recipient, any
interference with, 

use, disclosure or copying of this material is unauthorised and
prohibited; and



(b) may contain personal information of the recipient and/or the sender
as defined 

under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to 

collect, hold and use such information and any personal information
contained in a 

response to this email, for any reasonable purpose in the ordinary
course of 

Spherion's 

business, including forwarding this email internally or disclosing it to
a third party. All 

personal information collected by Spherion will be handled in accordance
with 

Spherion's Privacy Policy. If you have received this email in error,
please notify the 

sender and delete it.



(c) you agree not to employ or arrange employment for any candidate(s)
supplied in 

this email and any attachments without first entering into a contractual
agreement with 

Spherion. You further agree not to divulge any information contained in
this document 

to any person(s) or entities without the express permission of Spherion.

RE: [ebxmlms-develop] Hermes 1.0 my remarks

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

Correct me if i'm wrong, but aren't RetryInterval, Retries etc as much
part of the message as SyncReply? And aren't AckRequested,
DuplicateElimination not also defined in the CPA (E.5.2.2), just as
role, service, action etc....
 
This make the 'this is CPA, this is Message' discussion not clearer.
 
I agree that the sending MSH should (or must? ;-)) have knowledge of the
CPA. I'll look into what the ebXML TA says about this? (
http://www.ebxml.org/specs/ebTA.pdf
<http://www.ebxml.org/specs/ebTA.pdf> )
 
Ronald

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


I said:
 
I think parameters should be carefully classified. Those that are part
of a message (AckRequested, DuplicateElimination, etc) should be set in
the EbxmlMessage. Those that are part of the CPA (retries, retry
interval, etc), and are *not* part of the message, or of an individual
send(), should *not* be set in the message or as send() parameters.
Instead, they should be provided by the CpaResolver.

This requires some more thought. For instance, even though syncReply is
part of the message, it is specified in the CPA, so a client shouldn't
have to set it.
 
Furthermore, the spec says "This element MUST NOT be used to override
the value of syncReplyMode in the CPA. If the value of syncReplyMode is
none and a SyncReply element is present, the Receiving MSH should issue
an error with errorCode of Inconsistent and a severity of Error."
 
To check incoming messages, the MSH must have access to the CPA.
Therefore, it makes sense that the MSH should have access to the CPA to
build outgoing messages as well.
 
PJDM
--
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727  F: 61 2 62689777

The information contained in this email and any attachments to it:



(a) may be confidential and if you are not the intended recipient, any
interference with, 

use, disclosure or copying of this material is unauthorised and
prohibited; and



(b) may contain personal information of the recipient and/or the sender
as defined 

under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to 

collect, hold and use such information and any personal information
contained in a 

response to this email, for any reasonable purpose in the ordinary
course of 

Spherion's 

business, including forwarding this email internally or disclosing it to
a third party. All 

personal information collected by Spherion will be handled in accordance
with 

Spherion's Privacy Policy. If you have received this email in error,
please notify the 

sender and delete it.



(c) you agree not to employ or arrange employment for any candidate(s)
supplied in 

this email and any attachments without first entering into a contractual
agreement with 

Spherion. You further agree not to divulge any information contained in
this document 

to any person(s) or entities without the express permission of Spherion.

RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

I'll try to cook-up a small example over the weekend. 
- a base class
- onMessage()
- two or three implementations (file, url, and jms)
- each with their properties (url for url/file, queue/factory for jms
etc.)
- looking them up through jndi
 
jndi is the mechanism to lookup components in a j2ee environment, where
components can be remote or local. But also ldap connection factories
can be configured and looked up through jndi.
 
to be continued.

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: donderdag 10 juli 2003 1:02
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)



That's why I keep saying that the destination should be a URI, not a
URL. Since every URL is a URI, you're not losing the ability to specify
http: and file: URLs, and you also get jms: and anything else you want
to add in the future.

Having said that, and not having worked with JNDI contexts in the form
we're discussing here, I can't comment on whether URIs or JNDI is
easier. How would a JNDI context be configured?

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: Patrick Yee [ mailto:kc...@ce...
<mailto:kc...@ce...> ] 
Sent: Wednesday, 9 July 2003 8:30 PM 
To: ebx...@li... 
Subject: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery) 


How to specify the JMS destination in the form of a URL, if the single
server-side mode only provides an interface for specifying a URL?

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, 

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.