ebxmlms-develop — Development discussions

Re: [ebxmlms-develop] Sun WSDP1.2 without jaxm

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

Ng Chi Yuen [Cyng] probeerde het volgende duidelijk te maken op 
24-6-2003 16:06:

>Hi,
>
>  
>
>>I just read the releasenotes of  WSDP 1.2 and there does not seem to be
>>a  JAXM anymore (neither in j2ee 1.4 draft 3). Not that I realy care for
>>that, but since it is not there anymore, shoudn't we try to remove it
>>from Hermes as well?
>>Can anybody summarize what the open issues are to fully move to axis? I
>>still have limited time, but in a few weeks I could give it a try
>>    
>>
>
>        I note that the name "SAAJ" is still in the description. According
>to my interpretation, since JAXM 1.1.1, those classes under
>javax.xml.soap.* (such as SOAPMessage) are grouped into SAAJ while
>those under javax.xml.messaging.* (such as JAXMServlet, ProviderConnection)
>are so-called JAXM. It seems that SAAJ are used for over 90% of the time
>for composing SOAPMessage (and thus ebMS packaging), implementations
>of ProviderConnection, ReqRespListener for ebMS are seldom met.
>
>        So, it's really a great idea to remove all these kinds of stuff
>(SAAJ and JAXM) from Hermes. 
>
Axis saaj compliant (the api), so i think you mean removing  the sun 
reference-implementation of saaj? Or do you realy want to start using 
the lowlevel axis api of jdom? Personally I wouldn't do that. Just stick 
with saaj and use the axis implementation. (doesn't axis use jdom?)

>In the current 1.0 branch, Http.java has
>already sent a SOAPMessage using direct HTTP (HttpURLConnection) instead
>
Great, on an internal project we currently have thrown all sun http 
classes overboard and use commons-httpclient  from apache. This gives us 
better proxy support (including authentication, even NTLM) because the 
Sun has some issues there, especially with M$ proxies. And 
http-keepalive, which especially on busy connections, leads to 300% 
performance gain.

>of SAAJ's SOAPConnection.call(). Patrick also implemented the file-based
>EbxmlMessage by adding our own PayloadContainer instead of SAAJ's
>AttachmentPart. The remaining work should be on SOAPMessage inside
>EbxmlMessage only. After removing this part, Hermes should be SAAJ and
>JAXM free. SAAJ just rides on DOM4J which then rides on JavaMail's
>MimeMultipart. Personally speaking, I like jdom which works much
>faster and efficient. How about if we introduce jdom into packaging/* ?
>
Doesn't axis use jdom and Sun dom4j?.... I'l have a look So if  the sun 
implementation of saaj is not used anymore we could switch to whatever 
we want.

btw, did you ever have a look at  jxpath.... I you want clean code....e.g.

Address address = null;
Collection locations = vendor.getLocations();
Iterator it = locations.iterator();
while (it.hasNext()){
    Location location = (Location)it.next();
    String zipCode = location.getAddress().getZipCode();
    if (zipCode.equals("90210")){
      address = location.getAddress();
      break;
    }
}


can be written as


    Address address = (Address)JXPathContext.newContext(vendor).

         getValue("locations[address/zipCode='90210']/address");  

    

especially the manipulation of the ebxmlmessage would then be realy 
clean... just learn the xsd


>
>Regards,
>CY
>
>----------------------------------------------------------------------------
>Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
>Technology Officer,
>Centre for E-Commerce Infrastructure Development,
>The University of Hong Kong
>----------------------------------------------------------------------------
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>

Re: [ebxmlms-develop] Sun WSDP1.2 without jaxm

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

Hi,

> I just read the releasenotes of  WSDP 1.2 and there does not seem to be
> a  JAXM anymore (neither in j2ee 1.4 draft 3). Not that I realy care for
> that, but since it is not there anymore, shoudn't we try to remove it
> from Hermes as well?
> Can anybody summarize what the open issues are to fully move to axis? I
> still have limited time, but in a few weeks I could give it a try

        I note that the name "SAAJ" is still in the description. According
to my interpretation, since JAXM 1.1.1, those classes under
javax.xml.soap.* (such as SOAPMessage) are grouped into SAAJ while
those under javax.xml.messaging.* (such as JAXMServlet, ProviderConnection)
are so-called JAXM. It seems that SAAJ are used for over 90% of the time
for composing SOAPMessage (and thus ebMS packaging), implementations
of ProviderConnection, ReqRespListener for ebMS are seldom met.

        So, it's really a great idea to remove all these kinds of stuff
(SAAJ and JAXM) from Hermes. In the current 1.0 branch, Http.java has
already sent a SOAPMessage using direct HTTP (HttpURLConnection) instead
of SAAJ's SOAPConnection.call(). Patrick also implemented the file-based
EbxmlMessage by adding our own PayloadContainer instead of SAAJ's
AttachmentPart. The remaining work should be on SOAPMessage inside
EbxmlMessage only. After removing this part, Hermes should be SAAJ and
JAXM free. SAAJ just rides on DOM4J which then rides on JavaMail's
MimeMultipart. Personally speaking, I like jdom which works much
faster and efficient. How about if we introduce jdom into packaging/* ?

Regards,
CY

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

[ebxmlms-develop] Sun WSDP1.2 without jaxm

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

Hi,

I just read the releasenotes of  WSDP 1.2 and there does not seem to be 
a  JAXM anymore (neither in j2ee 1.4 draft 3). Not that I realy care for 
that, but since it is not there anymore, shoudn't we try to remove it 
from Hermes as well?

Can anybody summarize what the open issues are to fully move to axis? I 
still have limited time, but in a few weeks I could give it a try

Ronald

Re: [ebxmlms-develop] Should Hermes makes dispatching decision?

[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>
Most of the attributes are from CPA. But the current implementation is
a bit confusing.. I should admit. Some attributes are set at Request
object (session wide), some attributes are set at EbxmlMessage (i.e.
per message based). Luckily, there is no attribute being set at
property file (not configurable in run time).. ... <br>
<br>
We should make it consistent in 1.0.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>Message</title>
  <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
  <div><span class="287353201-19062003"><font face="Arial" size="2">How
many of these are attributes of the CPA, and can therefore be
registered statically once, and how many are attributes of the
message, and therefore must be provided with a Request or message?</font></span></div>
  <div><span class="287353201-19062003"></span>&nbsp;</div>
  <div><span class="287353201-19062003"><font face="Arial" size="2">You've
said in another email that our concept is one Request per CPA. Isn't
the recipient URI a static attribute of the CPA?&nbsp;If that's the case,
then the Request doesn't need attributes such as the toMshUrl.</font></span></div>
  <div>&nbsp;</div>
  <div><span class="287353201-19062003"><font face="Arial" size="2">PJDM<br>
  </font></span><font size="2">--<br>
Peter Mayne<br>
Technology Consultant<br>
Spherion Technology Solutions<br>
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602<br>
T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" lang="en-us" dir="ltr"
 align="left"><font face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> Patrick Yee   [<a class="moz-txt-link-freetext" href="mailto:kc...@ce...">mailto:kc...@ce...</a>] <br>
    <b>Sent:</b> Wednesday, 18 June 2003 4:39   PM<br>
    <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a><br>
    <b>Subject:</b> Re:   [ebxmlms-develop] Should Hermes makes
dispatching   decision?<br>
    <br>
    </font></div>
    <blockquote
 cite="mid...@s-..."
 type="cite">
      <div><span class="380443104-18062003"><font face="Arial" size="2">My
mistake, I     didn't mean the question to refer to the application.
What I meant was that     the specification says the MSH must respond
with an error if an unknown     service/action is used, therefore the
MSH must know about the services and     actions for a CPA. Are there
any other parameters that an MSH must know, so     it can&nbsp;accept and
respond to messages   correctly?</font></span></div>
    </blockquote>
    <br>
Off the top of my head, there   are several: <br>
    <br>
1. whether reliable messaging should be used or not, and   the
corresponding parameters<br>
e.g. ackRequested = "always", "never",   "perMessage"<br>
    <br>
2. whether sync reply should be used for ACK, business   message, or
both<br>
    <br>
3. whether digital signature is requred<br>
    <br>
There   may be more, need to read spec for complete list.<br>
    <br>
Regards,   -Patrick<br>
    <br>
------------------------------------------------------- This   SF.Net
email is sponsored by: INetU Attention Web Developers &amp;  
Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers.
We   Manage Them. You Get 10% Monthly Commission! INetU Dedicated
Managed Hosting   <a class="moz-txt-link-freetext" href="http://www.inetu.net/partner/index.php">http://www.inetu.net/partner/index.php</a>  
_______________________________________________ ebxmlms-develop mailing
list   <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>  
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop">https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop</a></blockquote>
  <font size="3" color="BLUE">
  <pre>The information contained in this email and any attachments to it:

(a) may be confidential and if you are not the intended recipient, any interference with, 
use, disclosure or copying of this material is unauthorised and prohibited; and

(b) may contain personal information of the recipient and/or the sender as defined 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


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

Re: [ebxmlms-develop] http header field parsing

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

Hi,

>                     key = connection.getHeaderFieldKey(i);
>                     value = connection.getHeaderFieldKey(i);
>
> the same is assigned to both key and value. Shouldn't the value
> assignment be connection.getHeaderField(i)?

        Thanks, Ronald! Just a typo when composing the codes mechanically.
Fixed in CVS tree.

Regards,
CY

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

[ebxmlms-develop] http header field parsing

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

Hi,

I've seen this part of code in Http.java

                String key = connection.getHeaderFieldKey(1);
                String value = connection.getHeaderFieldKey(1);
                for (int i=2 ; key != null ; i++) {
                    StringTokenizer values = new StringTokenizer(value, 
",");
                    while (values.hasMoreTokens()) {
                        mimeHeaders.addHeader(key, 
values.nextToken().trim());
                    }
                    key = connection.getHeaderFieldKey(i);
                    value = connection.getHeaderFieldKey(i);
                }

the same is assigned to both key and value. Shouldn't the value 
assignment be connection.getHeaderField(i)?

I did'n try it running since my server crashed and my laptop is already 
producing stream....

Ronald

Re: [ebxmlms-develop] UrlResolver questions

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <p><font size="2">Before UrlResolver, the physical recipient of a
message was   taken directly from the ToPartyId.</font> </p>
    <p><font size="2">With UrlResolver, the physical recipient is now
mapped using a   custom hook, with a default provided. However, since
the hook lives on the   server, it could be awkward in ASP usage for
clients to update this   mapping.</font></p>
    <p><font size="2">These two mechanisms were/are necessary because
there is no   way of telling send() what the physical recipient is. If
the client could use   send("<a href="http://" target="_blank">http://</a>...")
(in addition to   existing parameters), then the MSH could store the
URL with the outgoing   message, and no UrlResolver would be required.
The client could then maintain   their own physical recipient database.</font></p>
    <p><font size="2">Is this reasonable?</font></p>
  </blockquote>
</blockquote>
<br>
This resembles the toMshUrl parameter in Request constructor. I agree
that it is more flexible to specify the URL in send() instead of in
constructor. But our concept is one Request per CPA instance deployed
in Hermes. If this assumption holds, then we don't need that
flexibility and thus specifying in constructor is more convenient.
Though, for global sender, this is reasonable.<br>
<br>
Regards, -Patrick<br>
</body>
</html>

Re: [ebxmlms-develop] Should Hermes makes dispatching decision?

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="380443104-18062003"><font face="Arial" size="2">My
mistake, I didn't mean the question to refer to the application. What
I meant was that the specification says the MSH must respond with an
error if an unknown service/action is used, therefore the MSH must
know about the services and actions for a CPA. Are there any other
parameters that an MSH must know, so it can&nbsp;accept and respond to
messages correctly?</font></span></div>
</blockquote>
<br>
Off the top of my head, there are several: <br>
<br>
1. whether reliable messaging should be used or not, and the
corresponding parameters<br>
e.g. ackRequested = "always", "never", "perMessage"<br>
<br>
2. whether sync reply should be used for ACK, business message, or both<br>
<br>
3. whether digital signature is requred<br>
<br>
There may be more, need to read spec for complete list.<br>
<br>
Regards, -Patrick<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] Should Hermes makes dispatching decision?

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="478263901-16062003">Given
that, it's a small leap to supporting different listeners for the
CpaId/service/action combination (rather than just the CpaId).
However, I still think that the current&nbsp;implementation is too
complicated.</span></font></div>
  <div><font face="Arial" size="2"><span class="478263901-16062003"></span></font></div>
</blockquote>
<br>
Now, our discussion shifted to the role of conversation ID. Please see
CY's mail for his usage on conversation ID.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;<font face="Arial" size="2"><span class="478263901-16062003">Have
you identified other parts of the specification that the MSH must know?</span></font></div>
</blockquote>
<br>
According to our understanding, the current 4 parameters of AppContent
is adequate as a key to identify application.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="478263901-16062003">Incidentally
(talking about where mail servers live), our systems people wouldn't
allow the Hermes database to be on the Hermes server in the DMZ, since
it contains&nbsp;corporate data. Instead, it sits on an internal system,
and the MSH accesses it from the DMZ.</span></font></div>
</blockquote>
<br>
In your case, Hermes (in DMZ) make JDBC connections to the DB (on
internal) through the firewall, right? So, how do you ensure the
security of the JDBC call? Sorry for stupid question, I know little on
DMZ/firewall stuff.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] mailto problems

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

We have just added the start element in the MIME header of the outgoing 
mail messages. Please see latest source.  Thanks for your information.

Regards, -Patrick

Jean-Baptiste Gadenne wrote:

> Hi,
> Another trick is to add the optional 'start' attribute in the mime 
> header, as specified in the EbMS specs :
>
> Content-type: multipart/related; boundary="BoundarY"; type="text/xml"; 
> start="<ebx...@ex...>"
>
> but the ContentId of the header and the Payload must be the same value 
> as specified in the start attribute.
> By doing this, Mozilla shows two attachments : one is the header, the 
> other is the payload.
>
> Regards,
> Jean-Baptiste Gadenne
>
>
>
> Ng Chi Yuen [Cyng] wrote:
>
>> Hi,
>>
>>  
>>
>>> We changed the Content-Type from
>>>
>>> "multipart/related" to "multipart/mixed" and it solved the problem !
>>> Do you think that "multipart/mixed" is an acceptable  Content-Type
>>> value for EbXMLMessages ?
>>>   
>>
>>
>>        "multipart/related" is specified in ebMS 2.0 specification
>> for ebXML message, though "multipart/mixed" is commonly used in
>> general MIME multipart mail message.
>>
>> Regards,
>> CY
>>
>> ----------------------------------------------------------------------------
>> Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
>> Technology Officer,
>> Centre for E-Commerce Infrastructure Development,
>> The University of Hong Kong
>> ----------------------------------------------------------------------------
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
>> thread debugger on the planet. Designed with thread debugging features
>> you've never dreamed of, try TotalView 6 free at www.etnus.com.
>> _______________________________________________
>> ebxmlms-develop mailing list
>> ebx...@li...
>> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>
>>  
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

RE: [ebxmlms-develop] Should Hermes makes dispatching decision?

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

Hi,

> Given that, it's a small leap to supporting different listeners for the
> CpaId/service/action combination (rather than just the CpaId). However, I
> still think that the current implementation is too complicated.

> Have you identified other parts of the specification that the MSH must know?

        How to do MessageOrder delivery if no "conversationId" is included
in ApplicationContext?

> Fair enough. Do they really have different listeners at the conversationId
> level? The CpaId/service/action combination seems sufficient.

        Two departments of the same company write two different applications
to receive messages. Thus, these two departments would register two
MessageListener's with the same cpaId but different service and action.
Somehow, the business process is written and governed in such a way that
3 messages are now being sent: (cpaid, 1, s1, a1), (cpaid, 2, s2, a2),
(cpaid, 3, s1, a1). The application with s1 and a1 must wait for
conversationId 2 message to be delivered to application with s2 and a2
before receiving conversationId 3.

        I have been developing some internal stuff on business process
during these months. I simply switch myself to be the user of MSH, the
"son" I ever composed. I don't assume any implementation details in MSH.
When a business process is executed, it is acting on behalf of an
application of a particular cpaId, service and action from CPA with no
choice. The process engine also generates conversationId which is used
to differentiate a particular business process execution instance. I don't
know why MSH Request asks me to supply cpaId, conversationId, service,
action and MessageListenerImpl. Anyway, I have enough information to do so.
From my observation, I just know a particular business process execution
instance can receive exactly what it is supposed to receive from MSH. I also
observe that after receiving the message, that execution instance would
automatically unregister itself to MSH.

        In case the process engine deploys a global MessageListener, all
messages, once they are received, may be buffered, say, on the file system.
Then, the process engine has still to dispatch the messages one by one to
identify which message should be delivered to which process instance at
appropriate time (if MessageOrder semantics). Since I know nothing about
MSH, I would prefer the dispatching duty to be shifted to MSH instead of
my application, if there is choice.

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] Minor fixes

[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>
yoooosh....&nbsp; finally i did them and start to dream of a nice weekend..
:-)<br>
Regards, -Patrick<br>
<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>Message</title>
  <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
  <div><span class="379181903-13062003"><font face="Arial" size="2">Something
to do on a Friday night. Hong Kong can't be nearly&nbsp;as exciting as all
those Jackie Chan movies make it look. :-)</font></span></div>
  <div>&nbsp;</div>
  <div><span class="379181903-13062003"><font face="Arial" size="2">PJDM</font></span></div>
  <div><font size="2">--<br>
Peter Mayne<br>
Technology Consultant<br>
Spherion Technology Solutions<br>
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602<br>
T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" lang="en-us" dir="ltr"
 align="left"><font face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> Patrick Yee   [<a class="moz-txt-link-freetext" href="mailto:kc...@ce...">mailto:kc...@ce...</a>] <br>
    <b>Sent:</b> Friday, 13 June 2003 1:16   PM<br>
    <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a><br>
    <b>Subject:</b> Re:   [ebxmlms-develop] Minor fixes<br>
    <br>
    </font></div>
Yes, thank you. :-)<br>
P.S.   I don't have time to read your mails yet. Hope I can do so
later...   :-(<br>
    <br>
Mayne, Peter wrote:<br>
    <blockquote
 cite="mid...@s-..."
 type="cite">
      <meta content="MS Exchange Server version 5.5.2654.45"
 name="Generator">
      <p><font size="2">In various places, errors are logged without
stack traces.     For instance, in MessageServiceHandler.configure():</font> </p>
      <p><font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     try {</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     certResolver = (CertResolver)
Class.forName(certResolverName).</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     newInstance();</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     }</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     catch (Exception e) {</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     String err =
ErrorMessages.getMessage</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    
(ErrorMessages.ERR_HERMES_INIT_ERROR, e.getMessage());</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     logger.error(err);</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     throw new
InitializationException(err);</font> <br>
      <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;     }</font> </p>
      <p><font size="2">If the CertResolver class can't be
instantiated, all that     shows in the error log is "[10001]
Initialization error - &lt;class     name&gt;". By changing
logger.error(err) to logger.error(err, e), we get a     stack trace
that shows a ClassNotFoundException.</font></p>
      <p><font size="2">There are a few similar to this scattered
around, where I've     had to add the stack trace to figure out what's
going on. Do you mind if I     fix them as I find them?</font></p>
      <p><font size="2">PJDM</font> <br>
      <font size="2">-- </font><br>
      <font size="2">Peter Mayne</font> <br>
      <font size="2">Technology Consultant</font> <br>
      <font size="2">Spherion Technology Solutions</font> <br>
      <font size="2">Level     1, 243 Northbourne Avenue, Lyneham,
ACT, 2602</font> <br>
      <font size="2">T: 61     2 62689727&nbsp; F: 61 2 62689777</font> </p>
      <font color="blue" size="3">
      <pre>The information contained in this email and any attachments to it:

(a) may be confidential and if you are not the intended recipient, any interference with, 
use, disclosure or copying of this material is unauthorised and prohibited; and

(b) may contain personal information of the recipient and/or the sender as defined 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


  </pre>
      </font></blockquote>
-------------------------------------------------------   This SF.NET
email is sponsored by: eBay Great deals on office technology -- on  
eBay now! Click here:
<a class="moz-txt-link-freetext" href="http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5">http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5</a>  
_______________________________________________ ebxmlms-develop mailing
list   <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>  
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop">https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop</a></blockquote>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] Authentication + authorisation

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

I agree with you, both. :-)
Regards, -Patrick


Ronald van Kuijk wrote:

> Which doesn't sit well in any environment ;-)
>
> Ronald
>
> Mayne, Peter tried to make a point on 12-6-2003 4:41:
>
>> Dynamic registration aside, there needs to be an admin level user as 
>> well as a user level user. At the moment, anyone who can send a 
>> message can also send a HALT_TERMINATE command to the MSH, which 
>> doesn't sit well in an ASP environment.
>>
>> 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.
>>
>>
>>  
>>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] CertResolver questions

[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>
<blockquote type="cite"
 cite="mid...@s-..."><span
 class="732103823-11062003">
  <div><font face="Arial" size="2"><span class="732103823-11062003"><font
 color="#0000ff"><font face="Times New Roman" size="3">If the
certificates of all clients will be stored in a centralized place,
e.g. a centralized keystore, it's ok to have a global one. But if the
certificates are to be managed by the applications in a distributed
way, the CertResolver implementation will be different for different
applications.</font><br>
  </font></span></font></div>
  <span class="732103823-11062003">
  <div><span class="732103823-11062003"><font face="Arial" size="2">My
CertResolver implementation would work like this:</font></span></div>
  <div><font face="Arial" size="2">Each ASP client has their own
keystore of trusted certificates. (The keystore can be managed by the
client, or by the ASP on behalf of the client.) Each keystore is
stored on the&nbsp;<span class="732103823-11062003">MSH server</span>. When
a message arrives, the CertResolver looks at the message header,
selects the right&nbsp;keystore<span class="732103823-11062003"> based on
the&nbsp;CpaId</span>, and uses it to get the right certificate.</font></div>
  <div>&nbsp;</div>
  <div><span class="732103823-11062003"><font face="Arial" size="2">Can
you please give an example of why different CertResolver
implementations are required? As far as I can see, this CertResolver
would work in all cases.</font></span></div>
  <div><span class="732103823-11062003">&nbsp;</span></div>
  <div><span class="732103823-11062003"></span><font face="Arial"
 size="2"></font></div>
  </span></span></blockquote>
<br>
Yes, "<span class="732103823-11062003"><font face="Arial" size="2"><span
 class="732103823-11062003"><font color="#0000ff"><font
 face="Times New Roman" size="3">If the certificates of all clients
will be stored in a centralized place, e.g. a centralized keystore,
it's ok to have a global one.<font color="#000000">". Your example
works too with global CertResolver also. :-)<br>
<br>
Example when different CertResolver implementations needed. ASP clients
manages their own keystore. Some may use a key store file to store the
certificates, some may use an LDAP repository, some may use certificate
server, etc. We don't know in general where the ASP client would like
to store the key. Therefore, we propose to build that part as a hook
also.<br>
</font></font></font></span></font></span><br>
Regards, -Patrick<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] Static registration

[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>
It's a good idea to group our discussions into threads of different
topics. :-)<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <p><font size="2" face="Arial">The registration you're talking about
here is not dynamic registration, but updating the static registration.</font> </p>
  <p><font size="2" face="Arial">As I said in the "Authentication +
authorisation" email, there should be a difference between user level
privileges and admin level privileges. Clearly a normal user should not
be allowed to modify the registration database.</font></p>
</blockquote>
Agree.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <p><font size="2" face="Arial">The MSH should have a "load new
registration map" command. Naturally this command is invoked as part of
the MSH startup. There's also nothing stopping an admin level user from
invoking it at any other time after manually editing the registration
map.</font></p>
</blockquote>
You mean: to make a new registration, we have to modify the property
file to update the registration map. And then call the MSH reload
registration map command to get it known. Right? If the registration is
to be done by an upper layer software, I prefer to use the methods you
describe in the following...<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <p><font size="2" face="Arial">Throw in add/delete/list methods for
maintaining the static registration database (only allowed for the
admin user), where the add and delete methods do a "load new
registration map" automatically, and there you are.</font></p>
</blockquote>
Now, MSHConfig table is used to maintain it. In view of both ways of
registration (by editing properties file and calling methods directly),
therefore I suggested to keep on using MSHConfig, i.e. to use DB to
keep it accurate.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <p><font size="2" face="Arial">There are a few checks to be made. For
instance, you're not allowed to delete a CpaId registration if there is
a message pending to be delivered to that CpaId, but nothing
complicated.</font></p>
</blockquote>
<br>
Agree. The current unregistration mechanism has already considered this.<br>
<br>
<br>
Regards, -Patrick<br>
</body>
</html>

Re: [ebxmlms-develop] Authentication + authorisation

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

Which doesn't sit well in any environment ;-)

Ronald

Mayne, Peter tried to make a point on 12-6-2003 4:41:

> Dynamic registration aside, there needs to be an admin level user as 
> well as a user level user. At the moment, anyone who can send a 
> message can also send a HALT_TERMINATE command to the MSH, which 
> doesn't sit well in an ASP environment.
>
> 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] Minor fixes

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Yes, thank you. :-)<br>
P.S. I don't have time to read your mails yet. Hope I can do so
later... :-(<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>Minor fixes</title>
  <p><font size="2">In various places, errors are logged without stack
traces. For instance, in MessageServiceHandler.configure():</font> </p>
  <p><font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try {</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certResolver = (CertResolver)
Class.forName(certResolverName).</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; newInstance();</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; catch (Exception e) {</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String err = ErrorMessages.getMessage</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(ErrorMessages.ERR_HERMES_INIT_ERROR, e.getMessage());</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; logger.error(err);</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new InitializationException(err);</font> <br>
  <font size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</font> </p>
  <p><font size="2">If the CertResolver class can't be instantiated,
all that shows in the error log is "[10001] Initialization error -
&lt;class name&gt;". By changing logger.error(err) to logger.error(err,
e), we get a stack trace that shows a ClassNotFoundException.</font></p>
  <p><font size="2">There are a few similar to this scattered around,
where I've had to add the stack trace to figure out what's going on. Do
you mind if I fix them as I find them?</font></p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>The information contained in this email and any attachments to it:

(a) may be confidential and if you are not the intended recipient, any interference with, 
use, disclosure or copying of this material is unauthorised and prohibited; and

(b) may contain personal information of the recipient and/or the sender as defined 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


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

Re: [ebxmlms-develop] CertResolver questions

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="653165205-11062003"><font face="Arial" size="2">Because
if I only require static registration, there's a whole bunch more
Hermes&nbsp;code I have to look through to figure out how to do it, and
it's not easy at the moment. More code means more complicated, harder
to maintain, and&nbsp;less reliable.</font></span></div>
  <div><span class="653165205-11062003"></span></div>
</blockquote>
<br>
So, will you be more comfortable if there are "Hermes - ASP Mode
Edition" and "Hermes - Standalone Mode Edition"? :-)<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="653165205-11062003">You've
made the listener (potentially) slightly less complicated at the
expense of making Hermes a lot more complicated.</span></font></div>
</blockquote>
To "make the listener (potentially) slightly less complicated" is only
part of the reason. Please note again that not all use cases can be
done with a global listener.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="653165205-11062003">The
listener has to dispatch the message anyway: in my case, it&nbsp;puts&nbsp;all
messages&nbsp;on a JMS queue. Now,&nbsp;suppose I want to put messages on
different queues (for different departments), depending on the
service/action? I can:</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">(a)&nbsp;register
several different listener instances, each with a different
configuration to tell it which queue to put the message on,&nbsp;and get
Hermes to deliver messages to those different instances.</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">(b)&nbsp;register
one listener instance with a single configuration and&nbsp;a decision table
with a single configuration.</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">I'll
go with (b) every time, even given the (a) option. In fact, I do:</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">(c)
register one listener instance that puts all messages on a single&nbsp;JMS
queue; a service on the other end of the queue gets the messages and
does slightly different things depending on the action.</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">If
I did this by registering a different listener for each action,&nbsp;it
would&nbsp;end up being more complicated and harder to manage! :-)</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font><font
 face="Arial" size="2"><span class="653165205-11062003"></span></font> <br>
  </div>
</blockquote>
I understand your (i.e. standalone mode) use case.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="653165205-11062003">My
single listener can be more flexible: what if I want all&nbsp;purchase
orders&nbsp;where FromPartyId="CECID" to be dealt with by our express
orders department?&nbsp;The ApplicationContext can't do that, because it
doesn't look at FromPartyId, whereas&nbsp;a listener can.</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font></div>
</blockquote>
As I said, we have CPPA concepts in our mind when doing the design. We
found that CPA_ID would imply FromPartyID &amp; ToPartyID. So, we don't
use From/To PartyID as the decision keys.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;<font face="Arial" size="2"><span class="653165205-11062003">Most
importantly, I don't think it is Hermes' job to do&nbsp;finer
categorisation. As you've implied above, by allowing&nbsp;the MSH to decide
where to deliver the message to,&nbsp;you're entangling&nbsp;the MSH&nbsp;with&nbsp;the
company's internal&nbsp;business process, and I don't think that's right.
The MSH should just deliver the message, and let the business process
in or behind the&nbsp;listener&nbsp;decide what to do with it (as in (b) or&nbsp;(c)
above). I *really* don't want a piece of software that lives in the
DMZ making business process decisions that should be made internally.</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> <br>
  </div>
</blockquote>
An analogy is email server. A traditional business process may involve
different people from different departments. Sometimes you need to talk
to outside world. And the outside world will send emails to specific
departments during the process. Upon receiving the emails from outside,
the email server has to dispatch the messages to each person's mailbox.
The decision is based on the email address. This is the same as Hermes
to dispatch the messages to each application, basing on the AppContext.<br>
<br>
Hmm, email server is placed in the DMZ, right?<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="653165205-11062003">This
is why&nbsp;I disagree with the idea that it is more reasonable to deliver
messages to applications using the ApplicationContext. Different
service/action handling by different routines *is* reasonable, but the
MSH shouldn't be making that decision.</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">A
company large enough to have different departments and flexible enough
to be using an open source MSH isn't going to have any problems
writing a listener that can do different service/action handling. :-)</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">So,
why don't I just register my clever listener
with&nbsp;ApplicationContext("*","*","*","*"),&nbsp;and forget about the rest?
Because as I said above, this part of Hermes is already too complicated,
and you're considering making it even more complicated (two kinds of
registration, another authorisation scheme), and therefore less
reliable and harder to maintain. That's important in an open source
product. :-)</span></font></div>
  <div><font face="Arial" size="2"><span class="653165205-11062003"></span></font></div>
</blockquote>
I know we may be aiming too high. :-) But at least the ASP mode use
case is possible for small companies as well.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="653165205-11062003">But
you're saying here that the need for a CertResolver depends on the
presence or absence of a certificate in a message, not on an
ApplicationContext,&nbsp;and I agree with that. Therefore, why would
different CertResolvers be needed for different ApplicationContexts?</span></font> <br>
  </div>
</blockquote>
If the certificates of all clients will be stored in a centralized
place, e.g. a centralized keystore, it's ok to have a global one. But
if the certificates are to be managed by the applications in a
distributed way, the CertResolver implementation will be different for
different applications.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] CertResolver questions

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="949484603-11062003"><font face="Arial" size="2">Multiple
email converations at once...</font></span></div>
</blockquote>
<br>
<font color="#009900"><span class="758455402-11062003"><font
 face="Arial" size="2">Why? In single-client mode (as I'm currently
doing), dynamic registration isn't required, and is actually a pain.
In ASP mode, if you allow dynamic registration, you have to come up
with a mechanism to stop the clients registering arbitrary
ApplicationContexts, as you said, and that makes things even more
complicated. I would do away with dynamic registration altogether.</font></span><br>
</font><br>
If you are using single-client mode, static registration is enough,
then why painful? <br>
I still think dynamic registering is more flexible. For example, if we
are going to build a upper layer software on top of Hermes to handle BP
issues, and probably we will be using ebXML CPPA. There may be a
interface to deploy CPA files and it will do registration to Hermes
dynamically. If Hermes only supports static registration, the
deployment of CPA will include automatic modification of the properties
file (and restart Hermes, of course we can make Hermes re-read the
properties file regularly, but is it getting complicated again?). In
this case, I think dynamic registration is better.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font color="#009900"><span class="949484603-11062003"><font
 face="Arial" size="2">To rephrase my response, I think this is adding
far too much complication. To do this, you have to maintain a
server-side database mapping clients to the ApplicationContexts that
they're allowed to use. In other words, you're creating a static
registration database, but you want the clients to dynamically register
as well, and/or you want to invent a new more sophisticated (read
"more complicated") authentication mechanism! Gulp!</font></span></font></div>
</blockquote>
Agree that it is complicated, and I understand your concern. But why
don't we think of a more acceptable mechanism if it is that complicated?<br>
<br>
<span class="758455402-11062003"><font face="Arial" size="2"><font
 color="#009900">How did you come up with registering by
CPA+conversation+service+action?</font><br>
<br>
<big>In early versions of Hermes, ToPartyId has to be always the MSH
endpoint. So we need another key to deliver messages. Anyway, even in
current case, it is more reasonable to dispatch messages to
applications using AppContext, as different service/action handler by
different routines are reasonable. In spec, PartyID is inherited from
CPA, which is generally used to identify an organization. What if (ASP
mode again), a company installed one Hermes, and different departments
are using it and they are responsible for different parts of a business
process? (Thus, they are responsible for different service/action, and
thus different AppContext). In this case, the ToPartyID is probably the
name of the company. I know a single receiver like what you are doing
can always solve the problem, but what are the problems if we can do a
finer categorization in an earlier stage? We can make the application
simpler, at least don't have to dispatch the message, by doing this
kind of registration.<br>
<br>
In view of all these, we think within all the header fields of an ebXML
message, those 4 are the best candidate for dispatching messages. <br>
<br>
</big></font></span><font color="#009900"><span
 class="758455402-11062003"><font><font face="Arial" size="2"><span
 class="758455402-11062003">There isn't a problem (I think) with
sharing CertResolver's certificates amongst clients, so there's no
point making it ApplicationContext-specific.</span></font></font></span></font><br>
<span class="758455402-11062003"><font face="Arial" size="2"><br>
</font></span>It may not be a problem with sharing certificates. But
the incoming messages may be coming from different senders (in ASP
mode, different senders send to different receiving applications,
determined by different AppContext). Different senders may use
different brands of MSH. Some may include a cert in the message, which
do not need a CertResolver. Some may not include a cert in the message,
which need a CertResolver. That's the point to call up different
CertResolver depending on AppContext.<br>
<br>
Regards, -Patrick<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] CertResolver questions

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>Example 3:<br>
Assume in ASP mode, messages from client A will be routed to
application A and messages from client B will be routed to application
B.<br>
Suppose that client A creates a message with FromPartyId set to client
A, sign it using client A's key, and does not attach the certificate
in the message. The message is having AppContext of application B. The
attachment of the message is going to screw up application B When the
message comes to Hermes, Hermes will activate CertResolver and use
client A's certificate as it's determined by FromPartyId. The
verification passes and the message routed to application B as it's
determined by AppContext. If application B is not checking the
FromPartyId and the certificate passing up (as you suggested), it is
doomed.<br>
  <br>
  <span class="589553602-11062003"><font face="Arial" size="2">Do you
mean "message *to* client A will be routed to application A and messages
*to* client B will be routed to application B"?</font></span></div>
  <div><span class="589553602-11062003"></span></div>
</blockquote>
<br>
In your definition, you said you have certificate of client A and
client B in your keystore, right? If client A is application A, why you
need their certificate in your keystore? So I guess you mean client A
is the external sender, who sends a message to Hermes. And Hermes will
deliver the message to the client application, right? To avoid
ambiguity, I named the receiving applications as application A and
application B, instead of client A and client B. So normally, client A
will be sending messages to Hermes, and hoping the messages to be
delivered to application A. Client B will be sending messages to
Hermes, and hoping the messages to be delivered to application B.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;<span class="589553602-11062003"><font face="Arial" size="2">Why
is the attachment of the message going to screw up application
B?&nbsp;(Does "attachment" mean payload or certificate?) Other than that,
this example is what is supposed to happen, isn't it? I'm not sure
what your example is saying.</font></span></div>
  <div><span class="589553602-11062003"></span></div>
</blockquote>
I mean payloads. The payloads generally are business documents. Why the
fake business documents are going to screw up application B is clear.<br>
<br>
My example is saying: if the application is not checking the real
sender and relies only on the routing mechanism of AppContext (which is
likely to happen), it is possible for it to receive a message which
passes signature verification, but the message is from another client
trusted by another application of Hermes.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="589553602-11062003">You
still haven't said what's stopping client B from registering
ApplicationContext("*","*","*","*") and receiving client A's (and
everyone else's) messages.</span></font>&nbsp;</div>
</blockquote>
To recap my answer in the "JMS receiver" mail: we should implement a
more sophisticated authorization mechanism to avoid client B from
registering whatever AppContext he wants, including (*,*,*,*). We may
just allow a specifc client to register only a permitted set of
AppContexts.<br>
<br>
Also, in the current wildcard mechanism, messages (A,B,C,D) will be
routed to (A,B,C,D)&nbsp; even if (*,*,*,*) is also registered. The general
rule is a more specific AppContext is of higher priority than a more
general one.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] JMS receiver

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="691385723-09062003"><font face="Arial" size="2">When
using Hermes in ASP mode, how do you stop client A from registering an
application context to receive client B's messages?</font></span></div>
  <div><span class="691385723-09062003"></span></div>
</blockquote>
<br>
That requires a more sophisticated authorization mechanism to avoid the
clients to register arbitrary AppContext.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;<span class="691385723-09062003"><font face="Arial" size="2">If
I use a ClientMessageListenerImpl, my message sender has to wait until
it receives a response (which could be a long time, depending on the
request parameters) before it can exit. This could be inconvenient.
(In my case, I have a servlet that accepts user input and sends a
message. I don't really want to spin off background threads just to
wait for a status reply when I have a perfectly good listener already
waiting on the server.)</font></span></div>
  <div>&nbsp;</div>
  <div><font face="Arial"><font size="2">I spent much of yesterday
trying to figure out a way of telling the Request to use the existing&nbsp;<span
 class="691385723-09062003">registered </span>MessageListener for th<span
 class="691385723-09062003">e given</span>&nbsp;ApplicationContext, but
Requests, ApplicationContexts, MessageListeners, and message
parameters all appear to be very intertwined and confusing.<span
 class="691385723-09062003"> Any ideas on how to do this?</span></font></font></div>
</blockquote>
<br>
Sigh... I must admit that, there is no clean way, if not none, to
achieve your use case currently. It's time to re-engineer the current
registration mechanism.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><font face="Arial" size="2"><span class="691385723-09062003"><font
 face="Times New Roman" size="3">&gt; Maybe again, a hook should be
used to deal with any customized MessageListener first. But the hook</font></span></font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003"><font
 face="Times New Roman" size="3">&gt;&nbsp;should be per-AppContext. Any
idea?</font><br>
  </span></font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003">Maybe
something like the following in msh.properties.xml:</span></font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="691385723-09062003">
  <div><font face="Arial" size="2"><span class="691385723-09062003">&lt;MessageListeners&gt;</span></font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003">&nbsp;
&lt;ApplicationContext&nbsp;cpaId="A" conversationId="B" service="C"
action="D"&gt;</span></font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003">&nbsp;&nbsp;&nbsp;
&lt;Class name="local.ListenerE" parameter="F"/&gt;&nbsp;</span></font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003">&nbsp;
&lt;/ApplicationContext&gt;</span></font></div>
  </span> </font>
  <div><font face="Arial" size="2"><font face="Arial" size="2"><span
 class="691385723-09062003">&nbsp; &lt;ApplicationContext&nbsp;cpaId="*"
conversationId="*" service="*" action="*"&gt;</span></font></font></div>
  <div><font face="Arial" size="2"><font face="Arial" size="2"><span
 class="691385723-09062003">&nbsp;&nbsp;&nbsp; &lt;Class name="local.ListenerG"
parameter="H"/&gt;&nbsp;</span></font></font></div>
  <div><font face="Arial" size="2"><font face="Arial" size="2"><span
 class="691385723-09062003">&nbsp; &lt;/ApplicationContext&gt;</span></font></font></div>
  <font face="Arial" size="2">&lt;/MessageListeners&gt;</font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="691385723-09062003">When
Hermes starts, it will create an instance of ListenerE using the
default constructor, call init("F"), and serialise that instance for
ApplicationContext("A","B","C","D"). Ditto for ListenerG with the
global ApplicationContext (and for as many others as are specified).</span></font></div>
  <div><font face="Arial" size="2"><span class="691385723-09062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="691385723-09062003">It
is an error not to provide a listener for the global
ApplicationContext. (A&nbsp;ClientMessageListenerImpl with a file URL may
be used, of course.)&nbsp;&nbsp;Any attempt by a client to register a listener
with one of these ApplicationContexts is an error. It must be possible
for a client to specify that one of these MessageListeners be used
when creating a new Request and sending a message, including for
Hermes-generated messages.</span></font></div>
</blockquote>
It's a good idea to have registrations done statically. We will keep
the current dynamic registration mechanism&nbsp; through Request object.
Both static registration through properties file and dynamic
registration through Request object will be recorded in MSHConfig
table, so that Hermes can remember all registrations after restart.<br>
<br>
We still havn't solved the problem for specifying server side
MessageListener through dynamic registration. Or we may have to give
up. The same applies to UrlResolver and CertResolver, which we may need
to get it to be AppContext-wide settings instead of global settings.
When doing dynamic registration, it is impossible to get the hook to
run on server by only specifying a class name by Request object,
without the JAR files being deployed to the Hermes server.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
</body>
</html>

Re: [ebxmlms-develop] CertResolver questions

[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>
<blockquote type="cite"
 cite="mid...@s-...">
  <div><span class="113213506-10062003"><font face="Arial" size="2">The
only thing that truly identifies the sender is the signing
certificate, and Hermes doesn't provide a way of getting that
certificate.</font></span></div>
  <div><span class="113213506-10062003"></span>&nbsp;</div>
  <div><span class="113213506-10062003"><font face="Arial" size="2">Example
1:</font></span></div>
  <div><span class="113213506-10062003"><font face="Arial" size="2">Suppose
I have clients A and B in my keystore, so I can verify their messages.
Suppose client A creates a message, sets the FromPartyId as client B,
signs the message, and sends it. The resolver looks at the FromPartyId
and&nbsp;selects client B's key, which means the message won't verify,
because it was signed by client A.</font></span></div>
  <div><span class="113213506-10062003"></span>&nbsp;</div>
  <div><span class="113213506-10062003"><font face="Arial" size="2">Example
2:</font></span></div>
  <div><span class="113213506-10062003"><font face="Arial" size="2">Suppose
that client A creates another message with the FromPartyId set to
client B, signs it, and sends it with the certificate embedded in the
message. The resolver leaves&nbsp;verification of the message&nbsp;to Hermes,
which will successfully verify the message (because client A's
certificate in the message matches the signature produced by client
A)&nbsp;and passes it on. When I look at the message, I'll think it came
from client B, because that's what the message says, and I know that
Hermes has verified the message. The catch is that I don't know which
certificate was used to verify the message.</font></span></div>
  <div><span class="113213506-10062003"></span></div>
</blockquote>
<br>
Example 3:<br>
Assume in ASP mode, messages from client A will be routed to
application A and messages from client B will be routed to application
B.<br>
Suppose that client A creates a message with FromPartyId set to client
A, sign it using client A's key, and does not attach the certificate in
the message. The message is having AppContext of application B. The
attachment of the message is going to screw up application B When the
message comes to Hermes, Hermes will activate CertResolver and use
client A's certificate as it's determined by FromPartyId. The
verification passes and the message routed to application B as it's
determined by AppContext. If application B is not checking the
FromPartyId and the certificate passing up (as you suggested), it is
doomed.<br>
<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <div>&nbsp;</div>
  <div><span class="113213506-10062003"><font face="Arial" size="2">When
Hermes verifies a message, it must then include the certificate that
was used to verify&nbsp;the message in the EbxmlMessage, so a subsequent
consumer of the message can check that the certificate and the
FromPartyId match. In example 1 above, it doesn't matter so much,
because the resolver has already matched the FromPartyId to a
certificate, but in example 2 (which is Hermes without a certificate
resolver), it is vital.</font></span></div>
  <div><span class="113213506-10062003"></span> <br>
  </div>
</blockquote>
Agree that the certificate has to known to application. We may have to
add the link to the certificate in EbxmlMessage object. Comments?<br>
<br>
Regards, -Patrick<br>
</body>
</html>

Re: [ebxmlms-develop] Hermes as a router

[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>
You mean ebMS multi-hop feature? Hermes currently does not support
multi-hop. So, it always try to accept the message and give it to a
MessageListener.<br>
<br>
The only case for it will send the incoming message to another MSH is
when getClientUrl() of the MessageListener returns another MSH's
endpoint. But this is not related to the multi-hop&nbsp; feature stated in
ebMS spec.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>Hermes as a router</title>
  <p><font size="2">When Hermes receives a message, how does it know
whether to accept the message and give it to a MessageListener, or
route it to another MSH?</font></p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>The information contained in this email and any attachments to it:

(a) may be confidential and if you are not the intended recipient, any interference with, 
use, disclosure or copying of this material is unauthorised and prohibited; and

(b) may contain personal information of the recipient and/or the sender as defined 
under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
collect, hold and use such information and any personal information contained in a 
response to this email, for any reasonable purpose in the ordinary course of 
Spherion's 
business, including forwarding this email internally or disclosing it to a third party. All 
personal information collected by Spherion will be handled in accordance with 
Spherion's Privacy Policy. If you have received this email in error, please notify the 
sender and delete it.

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


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

[ebxmlms-develop] Re-implement EbxmlMessage.writeTo

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

Folks,

Now, whenever serialization of an EbxmlMessage is needed, we call on 
EbxmlMessage.writeTo(), which relies on JAXM implementation of 
SOAPMessage.writeTo(). The JAXM implementation of SOAPMessage.writeTo() 
is a bit silly for it will load all attachments to memory (into byte[]). 
Therefore, the maximum size of message that Hermes can handle is 
unreasonbly small.

We will in the next step re-implement EbxmlMessage.writeTo() to make it 
smarter. Stay tuned.

Regards, -Patrick

Re: [ebxmlms-develop] mailto problems

[Jean-Baptiste G. <jbg...@re...>]

Hi,
Another trick is to add the optional 'start' attribute in the mime 
header, as specified in the EbMS specs :

Content-type: multipart/related; boundary="BoundarY"; type="text/xml"; 
start="<ebx...@ex...>"

but the ContentId of the header and the Payload must be the same value 
as specified in the start attribute.
By doing this, Mozilla shows two attachments : one is the header, the 
other is the payload.

Regards,
Jean-Baptiste Gadenne



Ng Chi Yuen [Cyng] wrote:

>Hi,
>
>  
>
>>We changed the Content-Type from
>>
>>"multipart/related" to "multipart/mixed" and it solved the problem !
>>Do you think that "multipart/mixed" is an acceptable  Content-Type
>>value for EbXMLMessages ?
>>    
>>
>
>        "multipart/related" is specified in ebMS 2.0 specification
>for ebXML message, though "multipart/mixed" is commonly used in
>general MIME multipart mail message.
>
>Regards,
>CY
>
>----------------------------------------------------------------------------
>Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
>Technology Officer,
>Centre for E-Commerce Infrastructure Development,
>The University of Hong Kong
>----------------------------------------------------------------------------
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
>thread debugger on the planet. Designed with thread debugging features
>you've never dreamed of, try TotalView 6 free at www.etnus.com.
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>
>  
>