ebxmlms-develop — Development discussions

Re: [ebxmlms-develop] JMS URI proposal

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

Mayne, Peter wrote:

> Yes, I'm using a Hashtable as you've described, and reading the 
> properties from a properties file. See how ignorant I am? :-)
>
:-) Happens to me all the time on various subjects

> Aah yes, using javax.naming.Context is using JNDI, but it seems to be 
> a fairly primitive use. After all, I'm explicitly providing a context 
> factory to the Context, so I don't see any difference between the 
> questions in your first paragraph and your second paragraph.
>
It is 'primitive use' but sufficient in many situations. The main 
difference is indeed the fact that you are providing your own context 
factory.

> I can't see the mapping between a jms: URI and the use of the 
> Hashtable, but again, that's just my ignorance. If it works, who am I 
> to complain? :-)
>
All the properties you put in the hashtable could be put in a jms: URI 
and the server will internally parse that and put it in a hashtable etc....

I've seen that apache has a fairly complete implementation of this in 
axis, complete with full url protocol handlers. I'll see if that is in 
some way usable instead of duplicating all the work the've done. 
Especially since in to other projects i'm working on 
(http://chiba.sf.net and http://www.jbpm.org) I run into the same challenge.

http://cvs.apache.org/viewcvs.cgi/ws-axis/java/src/org/apache/axis/components/jms/
http://cvs.apache.org/viewcvs.cgi/ws-axis/java/src/org/apache/axis/transport/jms/

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, 29 January 2004 8:50 AM
> > To: ebx...@li...
> > Subject: RE: [ebxmlms-develop] JMS URI proposal
> >
> >
> > You mean you use JMS from within a servlet engine without
> > using JNDI? Do
> > you explicitely provide a connectionfactory class, etc?
> >
> > By context and provider url, you mean the java.naming.factory.initial
> > and  java.naming.provider.url property? Or something with a
> > hashtable,
> > properties like
> >
> >     Hashtable properties = new Hashtable();
> >     properties.put(Context.INITIAL_CONTEXT_FACTORY, 
> > "<initial-context-factory-class>");
> >     properties.put(Context.PROVIDER_URL, "<provider-url>");
> >     Context context = new InitialContext(properties);
> >
> > or something like this in a propety file.
> >
> > In these cases, you *are* using JNDI.
>
>The information contained in this email and any attachments to it:
>
>(a) may be confidential and if you are not the intended recipient, any interference with, 
>use, disclosure or copying of this material is unauthorised and prohibited; and
>
>(b) may contain personal information of the recipient and/or the sender as defined 
>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>collect, hold and use such information and any personal information contained in a 
>response to this email, for any reasonable purpose in the ordinary course of 
>Spherion's 
>business, including forwarding this email internally or disclosing it to a third party. All 
>personal information collected by Spherion will be handled in accordance with 
>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>sender and delete it.
>
>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>this email and any attachments without first entering into a contractual agreement with 
>Spherion. You further agree not to divulge any information contained in this document 
>to any person(s) or entities without the express permission of Spherion.
>
>
>  
>

[ebxmlms-develop] JMSMonitor issues

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

Hi all,

I currently have a JMSMonitor implemented like the MailMonitor is 
implemented. It is an innerclass with all the same halt, resume, 
shutdown methods. The difference (currently) is that it requires a 
Command object. To have the Command object available in the 'client' 
(which is not in the same package) so it can generate the command and 
put it in the JMSQueue, I had to make the Command class and the 
Command(Serializable content, EbxmlMessage ebxmlMessage) constructor 
public. I do not see this as a security issue, since instantiating a 
command object does not mean it will be processed. The security should 
be on the JMSQueue if needed just like it is on the doPost. Any objections?

It works like a charm and fast as well. The disadvantage of  the current 
implementation is that it is /in/ MessageServiceHandler, which means it 
cannot be compiled just for a servlet engine. There are two solutions to 
this problem that spring to mind, both which at least require it to 
become an external class, but that's the simple part and follow some 
interface
The relatively simple solution is to reserve a element in the config 
file e.g. externalMonitor which takes a classname as value.

e.g.
  <externalMonitors>
     
<externalMonitor>net.vankuijk.messaging.ebxml.JMSMonitor</externalMonitor>
     
<externalMonitor>any.domain.package.AnExternalMonitorImpl</externalMonitor>
  </externalMonitors>

There can be some generic mechanism in the MessageServiceHandler to 
create instances of all externalMonitors on startup. Each 
externalMonitorImpl should take care of it's own properties. The thing 
is that I cannot think of any other implementations, so it could be even 
a full configuration in the general config file

<!--uncomment the next segment if you want a JMSMonitor -->
    <JMSMonitor>
        <ClassName>net.vankuijk.messaging.ebxml.JMSMonitor</ClassName>
        <JNDIFactoryName>QueueFactory</JNDIFactoryName>
        <JNDIQueueName>queue/JMSMonitor</JNDIQueueName>
       <ReceiveTimeout>5000</ReceiveTimeout>
    </JMSMonitor>

Please, comment on this. Next things to work on :
- Accept a message in plaintext (textmesssage in JMS) as well as an 
objectmessage with a command in it.
- Implement the return way, so messages received from external MSH's can 
be delivered in a JMS queue

Ronald

Re: [ebxmlms-develop] JMSMessageListener contrib?

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

It is generic and I definately like to contribute it. I'll draw up a 
short summary  of changes I made to several files in hermes and why. 
Many changes are not final, just changes to get things working. Maybe 
you guys (galls?) have different ideas about how it should be done. 
Maybe I did some real "stupid" things, but don't hesitate to mention 
that (or 'fix' them ;-) )

Ok... here I go.

There are two main issues to get a fully implemented web-gui. The first 
is that generating a command is only possible from within the same 
package as the command class. This could be the Request class, but that 
is fully http oriented. The second issue is that sending/issueing 
command is only possinblr from within the MessageServiceHandler class 
itself or via the servlet.

Regarding the generation of commands I could have started adapting the 
Request class to make it less http oriented and usable directly in the 
server. Since this class does a lot more than just generating commands 
and almost all the methods contained something like

    /**
     * Gets the isHalted attribute of the Request object
     *
     * @return The isHalted value
     * @exception RequestException Description of the Exception
     */
    public boolean getIsHalted() throws RequestException {
        final Command command =
                new Command(CommandConstants.QUERY_MSH_STATUS, null);
        final HttpURLConnection connection = sendCommand(command);
        Map result = expectMapResponse(connection, "Cannot get MSH Status");
        String s = (String) result.get(Constants.QUERY_RESULT_MSH_STATUS);
        if (s == null) {
            throw new RequestException(
                    "Cannot get MSH status; Invalid response from MSH");
        } else {
            boolean b = Boolean.valueOf(s).booleanValue();
            return b;
        }
    }

with the HttpURLConnection, I was not comfortable adapting it, so 
started cutting/pasting methods to a new MessageServiceHandlerControl 
class and this method became

    public boolean isHalted()
            throws MessageServiceHandlerException, RequestException{
         
        Command mshCommand = new 
Command(CommandConstants.QUERY_MSH_STATUS, null);
        CommandResult cr = messageServiceHandler.processCommand(mshCommand);
         
        Map result = cr.getResultMap();    
//expectMapResponse(connection, "Cannot get MSH Status");
        String s = (String) result.get(Constants.QUERY_RESULT_MSH_STATUS);
        if (s == null) {
            throw new RequestException(
                    "Cannot get MSH status");
        } else {
            boolean b = Boolean.valueOf(s).booleanValue();
            return b;
        }
    }

The CommandResult object was created to contain a boolean status, a Map 
and a Document, depending on the type of command and what it returns. I 
currently only 'converted' 4 commands, since I just wanted to see what I 
would run in to. If the Request class could be made generic in one way 
or another, or refactor it and split it into two classes that's fine by 
me. Duplicating things is not the way to go (although cloning me is one 
thing my boss would not mind ;-) )

To be able to use the processCommand I refactored it to not require a 
response object. The response of the processCommand now is a 
CommandResult object mentioned before. In the doPost, the CommandResult 
is parsed and the correct type of response is send back. The only 3 
commands that (currently) still need the response object are put in a 
separate method processMessageCommand. After this, the processCommand 
can be used in other ways as well, either directly from another class 
(the new MessageServiceHandlerControl which is accessed from the 
web-gui) or the JMSMonitor, which only accepts sendMessage commands, 
nothing else. The MessageServiceHandlerControl can by default not get 
access MessageServiceHandler, so I added

        final MessageServiceHandlerControl messageServiceHandlerControl 
= MessageServiceHandlerControl.getInstance();
        messageServiceHandlerControl.setMessageServiceHandler(this);

to the MessageServiceHandler.

Again, the attached code is pre-alpha and should, in combination with 
the explanation above,  just be used to 'get the idea'

Attached are:

MessageServiceHandler.java
MessageServiceHandlerControl.java
Command.java
CommandResult.java

Exceptionhandling should be better, security should be taken into 
account more, etc....etc...etc...

The webapp is in an even earlier stage, so I'll not attach that (yet)

Best,

Ronald


Patrick Yee wrote:

> Just curious. :-)
> If you think the web based gui is generic, please contribute it.. :-)
> Regards, -Patrick
>  
>
>     ----- Original Message -----
>     *From:* Ronald van Kuijk <mailto:rv...@ab...>
>     *To:* 'ebx...@li...'
>     <mailto:%27e...@li...%27>
>     *Sent:* Tuesday, January 20, 2004 5:29 PM
>     *Subject:* RE: [ebxmlms-develop] JMSMessageListener contrib?
>
>     Yes, but commands in the web based gui go to the processCommand
>     method. (Which is in the servlet). I do not (necessarily) want the
>     JMS listener to be able to stop, start, etc the server. Just a
>     sending and receiving messages. Why do you ask this? Should I take
>     some things into accout?
>      
>     Ronald
>
>         -----Oorspronkelijk bericht-----
>         *Van:* Patrick Yee [mailto:kc...@ce...]
>         *Verzonden:* dinsdag 20 januari 2004 10:20
>         *Aan:* ebx...@li...
>         *Onderwerp:* Re: [ebxmlms-develop] JMSMessageListener contrib?
>
>         Ronard,
>
>         Thanks. I have one question. It seems to me that you want to
>         create different types of listeners (jms, http, etc.). After
>         making that, your plan is to rely on those listeners to build
>         a web based gui without sending commands through msh servlet.
>         Am I right?
>
>         Regards, -Patrick
>
>
>         Ronald van Kuijk wrote:
>
>>         Patrick,
>>          
>>         I've been looking into the MessageServiceHandler code last
>>         night to look into issues for making it possible to have a
>>         web based gui without tunnelling command's through the msh
>>         servlet. I've seen that the response object is used many
>>         layers deep and started refactoring some parts of the
>>         MessageServiceHandler to make it possible to give the
>>         commands in another way. This is almost working, without
>>         changing much of the code, regarding functionality. Al the
>>         refactoring took place mainly in the processCommand method.
>>         I've taken out the necessity for the response object in this
>>         method and created one additional method for those commands
>>         that currently realy need the response object (getMessage,
>>         getMessageByID etc...) So besides the processCommand and
>>         ProcessMessage, there now is a processMessageCommand method.
>>          
>>         Once this is done (at least for myself, but if you are
>>         interested, I'm happy to contribute it), I think it would be
>>         possible to spend some time to see whether we can really
>>         start implementing the jms:// kind of uri's, or maybe don't
>>         do it based on the uri, but create different listeners types
>>         (JMSListerner, HTTPListener, FileListener, etc...) each with
>>         their own type of config (including static appContext
>>         configurations?)
>>          
>>         Great btw, to see the persistence layer be made configurable,
>>         i've seen some things were checked in. Is the api stable
>>         enough to start working on a database persistence layer for
>>         the messages?
>>          
>>         Ronald
>>
>
>         ------------------------------------------------------- The
>         SF.Net email is sponsored by EclipseCon 2004 Premiere
>         Conference on Open Tools Development and Integration See the
>         breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>         http://www.eclipsecon.org/osdn
>         _______________________________________________
>         ebxmlms-develop mailing list
>         ebx...@li...
>         https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

RE: [ebxmlms-develop] JMS URI proposal

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

You mean you use JMS from within a servlet engine without using JNDI? Do 
you explicitely provide a connectionfactory class, etc?

By context and provider url, you mean the java.naming.factory.initial 
and  java.naming.provider.url property? Or something with a hashtable, 
properties like

    Hashtable properties = new Hashtable();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,  
"<initial-context-factory-class>");
    properties.put(Context.PROVIDER_URL, "<provider-url>");
    Context context = new InitialContext(properties);

or something like this in a propety file.

In these cases, you *are* using JNDI.

If it is nothing like this, could you give an example for the 
parameters/property file you use.

Ronald


    -----Oorspronkelijk bericht-----
    *Van:* Mayne, Peter [mailto:Pet...@ap...]
    *Verzonden:* woensdag 28 januari 2004 3:39
    *Aan:* 'ebx...@li...'
    *Onderwerp:* RE: [ebxmlms-develop] JMS URI proposal

    I've managed to get by so far without using JNDI, so I have no idea
    how to configure a JNDI provider to specify these things. You'd have
    to document it carefully.

    In my properties files I specify context factory, provider URL,
    queue connection factory, and queue name. I don't know how you get
    by without specifying the provider specific things in the URI.

    Given that its easy to dedicate a queue to Hermes, I don't see any
    need for other parameters. I assume sensible defaults such as
    persistent messages.

    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: Wednesday, 28 January 2004 11:52 AM
     > To: Ebxmlms-Develop (E-mail)
     > Subject: [ebxmlms-develop] JMS URI proposal
     >
     >
     > All,
     >
     > For the return-path of messages to be delivered in a JMS Queue,
    there
     > has been a discussion of a jms: uri. Whether a uri is right or
    wrong,
     > hermes uses it internally. There are several options (see
     > http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3
    <http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3>)
     >
     > I'm in favour of using the JNDI based one, without the
     > provider specific
     > things, so
     >
     > jms:///queue?connectionFactory=<conn-factory-jndi-name>&destin
     > ation=<dest-jndi-name>
     >
     > Meaning, it's a queue (not a topic) with a connectionFactory that is
     > fetched by looking it up in the default initialcontext by the
    name of
     > <conn-factory-jndi-name>. The queue is also looked-up in the jndi
    tree
     > by the name of <dest-jndi-name>.
     >
     > Does anybody have other ideas or see the need for using additional
     > properties like delivermode, priority etc..?
     >
     > Best,
     >
     > Ronald
     >
     >
     > -------------------------------------------------------
     > The SF.Net email is sponsored by EclipseCon 2004
     > Premiere Conference on Open Tools Development and Integration
     > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
     > http://www.eclipsecon.org/osdn
     > _______________________________________________
     > ebxmlms-develop mailing list
     > ebx...@li...
     > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
     >

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

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

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

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


  

Re: [ebxmlms-develop] JMSMessageListener contrib?

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

Just curious. :-)
If you think the web based gui is generic, please contribute it.. :-)
Regards, -Patrick

  ----- Original Message -----=20
  From: Ronald van Kuijk=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, January 20, 2004 5:29 PM
  Subject: RE: [ebxmlms-develop] JMSMessageListener contrib?


  Yes, but commands in the web based gui go to the processCommand =
method. (Which is in the servlet). I do not (necessarily) want the JMS =
listener to be able to stop, start, etc the server. Just a sending and =
receiving messages. Why do you ask this? Should I take some things into =
accout?

  Ronald
    -----Oorspronkelijk bericht-----
    Van: Patrick Yee [mailto:kc...@ce...]
    Verzonden: dinsdag 20 januari 2004 10:20
    Aan: ebx...@li...
    Onderwerp: Re: [ebxmlms-develop] JMSMessageListener contrib?


    Ronard,

    Thanks. I have one question. It seems to me that you want to create =
different types of listeners (jms, http, etc.). After making that, your =
plan is to rely on those listeners to build a web based gui without =
sending commands through msh servlet. Am I right?

    Regards, -Patrick


    Ronald van Kuijk wrote:

      Patrick,

      I've been looking into the MessageServiceHandler code last night =
to look into issues for making it possible to have a web based gui =
without tunnelling command's through the msh servlet. I've seen that the =
response object is used many layers deep and started refactoring some =
parts of the MessageServiceHandler to make it possible to give the =
commands in another way. This is almost working, without changing much =
of the code, regarding functionality. Al the refactoring took place =
mainly in the processCommand method. I've taken out the necessity for =
the response object in this method and created one additional method for =
those commands that currently realy need the response object =
(getMessage, getMessageByID etc...) So besides the processCommand and =
ProcessMessage, there now is a processMessageCommand method.

      Once this is done (at least for myself, but if you are interested, =
I'm happy to contribute it), I think it would be possible to spend some =
time to see whether we can really start implementing the jms:// kind of =
uri's, or maybe don't do it based on the uri, but create different =
listeners types (JMSListerner, HTTPListener, FileListener, etc...) each =
with their own type of config (including static appContext =
configurations?)

      Great btw, to see the persistence layer be made configurable, i've =
seen some things were checked in. Is the api stable enough to start =
working on a database persistence layer for the messages?

      Ronald



    ------------------------------------------------------- The SF.Net =
email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools =
Development and Integration See the breadth of Eclipse activity. =
February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn =
_______________________________________________ ebxmlms-develop mailing =
list ebx...@li... =
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

[ebxmlms-develop] JMS URI proposal

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

All,

For the return-path of messages to be delivered in a JMS Queue, there
has been a discussion of a jms: uri. Whether a uri is right or wrong,
hermes uses it internally. There are several options (see
http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3)

I'm in favour of using the JNDI based one, without the provider specific
things, so

jms:///queue?connectionFactory=<conn-factory-jndi-name>&destination=<dest-jndi-name>

Meaning, it's a queue (not a topic) with a connectionFactory that is
fetched by looking it up in the default initialcontext by the name of
<conn-factory-jndi-name>. The queue is also looked-up in the jndi tree
by the name of <dest-jndi-name>.

Does anybody have other ideas or see the need for using additional
properties like delivermode, priority etc..?

Best,

Ronald

[ebxmlms-develop] JMS URI proposal

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

All,
 
For the return-path of messages to be delivered in a JMS Queue, there 
has been a discussion of a jms: uri. Whether a uri is right or wrong, 
hermes uses it internally. There are several options (see 
http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3)
 
I'm in favour of using the JNDI based one, without the provider specific 
things, so

jms:///queue?connectionFactory=<conn-factory-jndi-name>&destination=<dest-jndi-name>

Meaning, it's a queue (not a topic) with a connectionFactory that is 
fetched by looking it up in the default initialcontext by the name of 
<conn-factory-jndi-name>. The queue is also looked-up in the jndi tree 
by the name of <dest-jndi-name>.

Does anybody have other ideas or see the need for using additional 
properties like delivermode, priority etc..?

Best,

Ronald

RE: [ebxmlms-develop] Serverside JMS 'listener'

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

Now with a proxy in front so it runs on port 80 
 
http://ronald.vankuijk.net/ebxmlweb
<http://ronald.vankuijk.net/ebxmlweb> 
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: dinsdag 20 januari 2004 1:39
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Serverside JMS 'listener'



> Have a look at http://ronald.vankuijk.net:8080/ebxmlweb/
<http://ronald.vankuijk.net:8080/ebxmlweb/>  

Unfortunately, we aren't allowed to look at non-port-80 HTTP sites. :-) 

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] Serverside JMS 'listener'

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

hmmm... i forgot to put the server background, so when I quit it
stopped. It's running now, but with a proxy in front so it runs on port
80
 
http://ronald.vankuijk.net/ebxmlweb
<http://ronald.vankuijk.net/ebxmlweb> 
 
Ronald

-----Oorspronkelijk bericht-----
Van: Bob Koon [mailto:py...@ce...]
Verzonden: dinsdag 20 januari 2004 5:11
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] Serverside JMS 'listener'


Connection Failed when I access it using my web browser. Strange.

Regards,
Bob Koon

Mayne, Peter wrote:


> Have a look at http://ronald.vankuijk.net:8080/ebxmlweb/
<http://ronald.vankuijk.net:8080/ebxmlweb/>  

Unfortunately, we aren't allowed to look at non-port-80 HTTP sites. :-) 

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] JMSMessageListener contrib?

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

Yes, but commands in the web based gui go to the processCommand method.
(Which is in the servlet). I do not (necessarily) want the JMS listener
to be able to stop, start, etc the server. Just a sending and receiving
messages. Why do you ask this? Should I take some things into accout?
 
Ronald

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: dinsdag 20 januari 2004 10:20
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] JMSMessageListener contrib?


Ronard,

Thanks. I have one question. It seems to me that you want to create
different types of listeners (jms, http, etc.). After making that, your
plan is to rely on those listeners to build a web based gui without
sending commands through msh servlet. Am I right?

Regards, -Patrick


Ronald van Kuijk wrote:


Patrick,
 
I've been looking into the MessageServiceHandler code last night to look
into issues for making it possible to have a web based gui without
tunnelling command's through the msh servlet. I've seen that the
response object is used many layers deep and started refactoring some
parts of the MessageServiceHandler to make it possible to give the
commands in another way. This is almost working, without changing much
of the code, regarding functionality. Al the refactoring took place
mainly in the processCommand method. I've taken out the necessity for
the response object in this method and created one additional method for
those commands that currently realy need the response object
(getMessage, getMessageByID etc...) So besides the processCommand and
ProcessMessage, there now is a processMessageCommand method.
 
Once this is done (at least for myself, but if you are interested, I'm
happy to contribute it), I think it would be possible to spend some time
to see whether we can really start implementing the jms:// kind of
uri's, or maybe don't do it based on the uri, but create different
listeners types (JMSListerner, HTTPListener, FileListener, etc...) each
with their own type of config (including static appContext
configurations?)
 
Great btw, to see the persistence layer be made configurable, i've seen
some things were checked in. Is the api stable enough to start working
on a database persistence layer for the messages?
 
Ronald




------------------------------------------------------- The SF.Net email
is sponsored by EclipseCon 2004 Premiere Conference on Open Tools
Development and Integration See the breadth of Eclipse activity.
February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] JMSMessageListener contrib?

[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">
Ronard,<br>
<br>
Thanks. I have one question. It seems to me that you want to create
different types of listeners (jms, http, etc.). After making that, your
plan is to rely on those listeners to build a web based gui without
sending commands through msh servlet. Am I right?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Ronald van Kuijk wrote:<br>
<blockquote type="cite"
 cite="mid...@ab...">
  <meta content="text/html; " http-equiv="Content-Type">
  <title></title>
  <meta name="GENERATOR" content="MSHTML 6.00.2800.1276">
  <div><span class="137593210-14012004"><font size="2" color="#0000ff"
 face="Arial">Patrick,</font></span></div>
  <div><span class="137593210-14012004"></span>&nbsp;</div>
  <div><span class="137593210-14012004"><font size="2" color="#0000ff"
 face="Arial">I've been looking into the MessageServiceHandler code
last night to look into issues for making it possible to have a web
based gui without tunnelling command's through the msh servlet. I've
seen that the response object is used many layers deep and started
refactoring some parts of the MessageServiceHandler to make it possible
to give the commands in another way. This is almost working, without
changing much of the code, regarding functionality. Al the refactoring
took place mainly in the processCommand method. I've taken out the
necessity for the response object in this method and created one
additional method for those commands that currently realy need the
response object (getMessage, getMessageByID etc...) So besides the
processCommand and ProcessMessage, there now is a processMessageCommand
method.</font></span></div>
  <div><span class="137593210-14012004"></span>&nbsp;</div>
  <div><span class="137593210-14012004"><font size="2" color="#0000ff"
 face="Arial">Once this is done (at least for myself, but if you are
interested, I'm happy to contribute it), I think it would be possible
to spend some time to see whether we can really start implementing the
jms:// kind of uri's, or maybe don't do it based on the uri, but create
different listeners types (JMSListerner, HTTPListener, FileListener,
etc...) each with their own type of config&nbsp;(including static appContext
configurations?)</font></span></div>
  <div><span class="137593210-14012004"></span>&nbsp;</div>
  <div><span class="137593210-14012004"><font size="2" color="#0000ff"
 face="Arial">Great btw, to see the persistence layer be made
configurable, i've seen some things were checked in. Is the api stable
enough to start working on a database persistence layer for the
messages?</font></span></div>
  <div><span class="137593210-14012004"></span>&nbsp;</div>
  <div><span class="137593210-14012004"><font size="2" color="#0000ff"
 face="Arial">Ronald</font></span></div>
  <div><span class="137593210-14012004"></span> <br>
  </div>
</blockquote>
<br>
</body>
</html>

Re: [ebxmlms-develop] Serverside JMS 'listener'

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

Connection Failed when I access it using my web browser. Strange.

Regards,
Bob Koon

Mayne, Peter wrote:

> > Have a look at http://ronald.vankuijk.net:8080/ebxmlweb/
>
> Unfortunately, we aren't allowed to look at non-port-80 HTTP sites. :-)
>
> 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] Serverside JMS 'listener'

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

You are extremely right. There is a byte[] option as well, i'll try 
implementing both, thanks for the code.

The thing is that I currently have a thread running (just like the 
mailmonitor) that reads command objects from a queue, command objects 
like the ones that are generated by the Request class. Since they 
already contain a ebxmlmessage in the command object (generated by the 
client), it is the easiest way to process a call like this (just forward 
the object to 'processCommand()'. But it is not to difficult to do some 
checking if the JMSMessage is of type byte[], use your code and then 
deliver it to some method to process it.

The mayor thing was refactoring processCommand (still needs some work) 
so it does not need a response object all the way down (4 levels deep). 
The web-interface for monitoring/configuring hermes is going fast now. 
Have a look at http://ronald.vankuijk.net:8080/ebxmlweb/

Ronald

Mayne, Peter wrote:

> My current (nearly) production setup serialises an object called 
> IncomingMessage into a JMS ObjectMessage. (I use the IncomingMessage 
> object because there are one or two other pieces of data I wanted to 
> carry around, which with hindsight I could probably do without.)
>
> Essentially, this object is just a wrapper around a byte[] which 
> contains the serialised EbxmlMessage, so the JMS recipient 
> (theoretically) gets the same bytes that came in on the wire to 
> Hermes. The bytes are produced by EbxmlMessage.writeTo(), and fairly 
> easily turned back into a SOAPMessage (see below).
>
> If I was starting again, I would just use a bare byte[] rather than 
> wrapping a Java object around a byte[].
>
> Using a Java object is no good for non-Java JMS recipients, as you say.
>
> Text format is no good: binary attachments will get messed up.
>
> I'd say stick with a bare byte[], since that is what the message comes 
> in as, and it's very little more work than using a Java object.
>
> A method for turning a byte[] back into a SOAPMessage (where 
> messageBytes is the byte[] containing the serialised EbxmlMessage):
>
>     public SOAPMessage getMessage() throws IOException, SOAPException
>     {
>         MimeHeaders headers = new MimeHeaders();
>         ByteArrayInputStream messageStream = new 
> ByteArrayInputStream(messageBytes);
>        
>         // Does this SOAPMessage have a MIME boundary?
>         //
>         String s = null;
>         InputStreamReader inputStreamReader = new 
> InputStreamReader(messageStream, "UTF-8");
>         BufferedReader reader = new BufferedReader(inputStreamReader);
>         s = reader.readLine();
>         while(s!=null && !(s.startsWith("--")))
>         {
>             s = reader.readLine();
>         }
>
>         // If there isn't a MIME boundary, then this is a straight XML 
> SOAPMessage.
>         // Otherwise, this is a MIME multipart message (with 
> attachments).
>         //
>         String contentType;
>         if(s==null)
>         {
>             contentType = "text/xml";
>         }
>         else
>         {
>             contentType = "multipart/related; type=\"text/xml\"; 
> boundary=" + "\"" + s.substring("--".length()) + "\";charset=\"utf-8\"";
>
>         }
>         headers.setHeader("Content-Type", contentType);
>
>         messageStream.reset();       
>         MessageFactory messageFactory = MessageFactory.newInstance();
>         SOAPMessage message = messageFactory.createMessage(headers, 
> messageStream);
>        
>         return message;
>     }
>
> 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: Tuesday, 20 January 2004 10:38 AM
> > To: ebx...@li...
> > Subject: Re: [ebxmlms-develop] Serverside JMS 'listener'
> >
> >
> > One additional question about the JMSListener is the type of
> > the message
> > it receives. There are two options.
> > - An object (native java), easier to implement and probably a
> > lot faster
> > than the next option
> > - Text format, provides the possibility to have other clients
> > (c, c++)
> > to connect to a JMS server
> >
> > My first implementation will be using serialized objects (in a
> > 'command'), generated by the client (Request class).
> >
> > Any objections?
> >
> > Ronald
>
>The information contained in this email and any attachments to it:
>
>(a) may be confidential and if you are not the intended recipient, any interference with, 
>use, disclosure or copying of this material is unauthorised and prohibited; and
>
>(b) may contain personal information of the recipient and/or the sender as defined 
>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>collect, hold and use such information and any personal information contained in a 
>response to this email, for any reasonable purpose in the ordinary course of 
>Spherion's 
>business, including forwarding this email internally or disclosing it to a third party. All 
>personal information collected by Spherion will be handled in accordance with 
>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>sender and delete it.
>
>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>this email and any attachments without first entering into a contractual agreement with 
>Spherion. You further agree not to divulge any information contained in this document 
>to any person(s) or entities without the express permission of Spherion.
>
>
>  
>

Re: [ebxmlms-develop] Serverside JMS 'listener'

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

One additional question about the JMSListener is the type of the message 
it receives. There are two options.
- An object (native java), easier to implement and probably a lot faster 
than the next option
- Text format, provides the possibility to have other clients (c, c++) 
to connect to a JMS server

My first implementation will be using serialized objects (in a 
'command'), generated by the client (Request class).

Any objections?

Ronald

Ronald van Kuijk wrote:

> First of all sorry for the bad english in my previous message, it was 
> 02:15 AM when I wrote this, and Heineken is not the best thing to keep 
> you concentrated ;-)
> Now in some more detail
>
> The configuration should be possible in two ways
> - a static one for a hermes version that runs in a servlet engine with 
> a remote jms server. The queuename and factory should be configurable
> - a j2ee compliant one where JNDI is used to get to the right queues
> Any objections?
>
> Another issue is the kind of processing that wil be done, There can be 
> single message processing, just like the mail monitor, or parallel 
> like the http monitor. (monitor is the word you use for this right?) 
> Since in my situation high-speed processing will be required, parallel 
> processing will ultimately be the soultion. Initially I'd like to 
> focus on single message processing to get the whole thing working. 
> Parallel processing brings all kinds of other issues regarding 
> reliable jms delivery (acknowledgements) in relation to sessions.
>
> Ronald
>
> Ronald van Kuijk wrote:
>
>> Hi all,
>>
>> Besides the http and smtp listeners (monitors?) I almost have a jms 
>> monitor working.  The issue that remains is how it should be configured.
>> - It should at least work with multiple providers so different 
>> JMSServers can be used.
>> - I think it should support some kind of authentication (but it can 
>> only be configured on JMSServer, not on hermes)
>> - Queue name should be configurable
>> - Acknowledgements on jms level per message?
>> - JNDI based queue/factory lookup should be supported
>> - ....
>>
>> I'm not working on the sending part yet. Should be an extension in 
>> the request object?
>>
>> Ronald
>>

Re: [ebxmlms-develop] Serverside JMS 'listener'

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

First of all sorry for the bad english in my previous message, it was 
02:15 AM when I wrote this, and Heineken is not the best thing to keep 
you concentrated ;-)
Now in some more detail

The configuration should be possible in two ways
- a static one for a hermes version that runs in a servlet engine with a 
remote jms server. The queuename and factory should be configurable
- a j2ee compliant one where JNDI is used to get to the right queues
Any objections?

Another issue is the kind of processing that wil be done, There can be 
single message processing, just like the mail monitor, or parallel like 
the http monitor. (monitor is the word you use for this right?) Since in 
my situation high-speed processing will be required, parallel processing 
will ultimately be the soultion. Initially I'd like to focus on single 
message processing to get the whole thing working. Parallel processing 
brings all kinds of other issues regarding reliable jms delivery 
(acknowledgements) in relation to sessions.

Ronald

Ronald van Kuijk wrote:

> Hi all,
>
> Besides the http and smtp listeners (monitors?) I almost have a jms 
> monitor working.  The issue that remains is how it should be configured.
> - It should at least work with multiple providers so different 
> JMSServers can be used.
> - I think it should support some kind of authentication (but it can 
> only be configured on JMSServer, not on hermes)
> - Queue name should be configurable
> - Acknowledgements on jms level per message?
> - JNDI based queue/factory lookup should be supported
> - ....
>
> I'm not working on the sending part yet. Should be an extension in the 
> request object?
>
> Ronald
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

[ebxmlms-develop] Serverside JMS 'listener'

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

Hi all,

Besides the http and smtp listeners (monitors?) I almost have a jms 
monitor working.  The issue that remains is how it should be configured.
- It should at least work with multiple providers so different 
JMSServers can be used.
- I think it should support some kind of authentication (but it can only 
be configured on JMSServer, not on hermes)
- Queue name should be configurable
- Acknowledgements on jms level per message?
- JNDI based queue/factory lookup should be supported
- ....

I'm not working on the sending part yet. Should be an extension in the 
request object?

Ronald

RE: [ebxmlms-develop] Completion on Customize Persistence Part

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

Congratulations Bob, thanks for all this work. I'll start looking into
it this weekend

Ronald

> -----Oorspronkelijk bericht-----
> Van: Bob Koon [mailto:py...@ce...]
> Verzonden: vrijdag 16 januari 2004 8:56
> Aan: ebx...@li...
> Onderwerp: [ebxmlms-develop] Completion on Customize Persistence Part
> 
> 
> Dear all,
> 
> I am glad to tell you all that I have just finished the customize 
> persistence layer part, including the support on archive, backup and 
> restore. Some comments (very little) are added on 
> msh.properties.xml on 
> how to set up the customize PersistenceHandler, so you can 
> refer to it 
> as a starting point. For developers, you can have a look on 
> PersistenceHandler, BackupablePersistenceHandler and 
> ArchivablePersistenceHandler.
> 
> I have written some test cases for this part and also do some rough 
> testing by myself (quite rough, since it is difficult to test out all 
> Hermes features by myself). Therefore, if you have any 
> suggestions for 
> the Persistence API, find any bugs on this part or any 
> questions, feel 
> free to mail to this mailing list.
> 
> I will start doing a feature to change the mechanism on Request such 
> that registration will not be needed if a user just want to send a 
> message. Some designs will be done within a few days, and any 
> suggestions are welcomed.
> 
> Regards,
> Bob Koon
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
> 

[ebxmlms-develop] Completion on Customize Persistence Part

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

Dear all,

I am glad to tell you all that I have just finished the customize 
persistence layer part, including the support on archive, backup and 
restore. Some comments (very little) are added on msh.properties.xml on 
how to set up the customize PersistenceHandler, so you can refer to it 
as a starting point. For developers, you can have a look on 
PersistenceHandler, BackupablePersistenceHandler and 
ArchivablePersistenceHandler.

I have written some test cases for this part and also do some rough 
testing by myself (quite rough, since it is difficult to test out all 
Hermes features by myself). Therefore, if you have any suggestions for 
the Persistence API, find any bugs on this part or any questions, feel 
free to mail to this mailing list.

I will start doing a feature to change the mechanism on Request such 
that registration will not be needed if a user just want to send a 
message. Some designs will be done within a few days, and any 
suggestions are welcomed.

Regards,
Bob Koon

Re: [ebxmlms-develop] JMSMessageListener contrib?

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

Dear Ronald,

The Persistence Layer API is quite stable enough, except two issues. One 
issue is that I have only done a rough testing on it and fixed some bugs 
before commit, so a more complete testing may be needed. Another issue 
is that the export, backup and restore function are not supported on the 
current API. Therefore, I will write two more interfaces, called 
BackupablePersistenceHandler and ArchivablePersistenceHandler which 
extends PersistenceHandler to support backup, restore and archive. The 
API will be committed today but the logic change will be committed 
later, and I will do more documentation on how to specify those 
Persistence Handler on msh.properties.xml later.

Thanks for your effort on participating the Hermes development.

Regards,
Bob Koon

Ronald van Kuijk wrote:

> Patrick,
>  
> I've been looking into the MessageServiceHandler code last night to 
> look into issues for making it possible to have a web based gui 
> without tunnelling command's through the msh servlet. I've seen that 
> the response object is used many layers deep and started refactoring 
> some parts of the MessageServiceHandler to make it possible to give 
> the commands in another way. This is almost working, without changing 
> much of the code, regarding functionality. Al the refactoring took 
> place mainly in the processCommand method. I've taken out the 
> necessity for the response object in this method and created one 
> additional method for those commands that currently realy need the 
> response object (getMessage, getMessageByID etc...) So besides the 
> processCommand and ProcessMessage, there now is a 
> processMessageCommand method.
>  
> Once this is done (at least for myself, but if you are interested, I'm 
> happy to contribute it), I think it would be possible to spend some 
> time to see whether we can really start implementing the jms:// kind 
> of uri's, or maybe don't do it based on the uri, but create different 
> listeners types (JMSListerner, HTTPListener, FileListener, etc...) 
> each with their own type of config (including static appContext 
> configurations?)
>  
> Great btw, to see the persistence layer be made configurable, i've 
> seen some things were checked in. Is the api stable enough to start 
> working on a database persistence layer for the messages?
>  
> Ronald
>  
>  
>  
> -----Oorspronkelijk bericht-----
> Van: Patrick Yee [mailto:kc...@ce...]
> Verzonden: woensdag 14 januari 2004 10:44
> Aan: ebx...@li...
> Onderwerp: Re: [ebxmlms-develop] JMSMessageListener contrib?
>
>     Peter and Ronald,
>
>     Do you think it is possible to base the generic listener on the
>     JMS one done by Peter? If so, I would like to invite Peter to
>     coordinate with Ronald on this. I guess the work flow is as
>     follows: we need to align the design first, and then make the code
>     done and then finally post it to the CVS. What do you think?
>
>     Regards, -Patrick
>
>
>     Mayne, Peter wrote:
>
>>     Ronald is correct: I'm still using an HTTP listener which just
>>     passes the message to JMS.
>>
>>     I did go some way to using JMS directly, but the current
>>     implementation isn't completely broken, so I didn't completely
>>     fix it. :-)
>>
>>     I would also like to see a more generic listener in Hermes.
>>
>>     PJDM
>>     -- 
>>     Peter Mayne
>>     Technology Consultant
>>     Spherion Technology Solutions
>>     Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
>>     T: 61 2 62689727  F: 61 2 62689777
>>
>>     > -----Original Message-----
>>     > From: Ronald van Kuijk [mailto:rv...@ab...]
>>     > Sent: Monday, 12 January 2004 12:24 AM
>>     > To: ebx...@li...
>>     > Subject: Re: [ebxmlms-develop] JMSMessageListener contrib?
>>     >
>>     >
>>     > Peter mentioned in previous messages about the JMS listerner
>>     > that there
>>     > still is http-tunneling involved in his implementation.
>>     > Looking at the
>>     > code of the MessageListener and the Request implementation, I
>>     > see that
>>     > this tunneling is the only 'easy' option. I'm thinking
>>     > however about a
>>     > more direct delivery of messages through JMS. To achieve
>>     > this, a lot of
>>     > the servlet implementation has to change. Since I've read that
>>     some
>>     > redesign things are going on (like a separate persistence
>>     layer, and
>>     > some monitoring/controling redesign), is there a change that
>>     > there will
>>     > be changes in the way messages can be delivered?
>>     >
>>     > Ronald
>>     >
>>     > Ronald van Kuijk wrote:
>>     >
>>     > > Hi all,
>>     > >
>>     > > Several months ago, there was a discussion about a
>>     JMSReceiver with
>>     > > uri/url issue. Especially Peter Mayne was working on this and
>>     had a
>>     > > working implementation for this.
>>     > >
>>     > > I'm currently working on an application that will be running
>>     within
>>     > > the same applicationserver as Hermes. I therefor like to
>>     > have a more
>>     > > closely integrated method for sending and receiving messages.
>>     I was
>>     > > thinking of a jms queue between the stub and hermes instead
>>     > of http.
>>     > > Is there already some code to start with, or extend? Maybe
>>     > a kind of
>>     > > contrib thing? Where I can also my LDAPURLResolver, and
>>     upcomming
>>     > > LDAPCertResolver.
>>     > >
>>     > > Ronald
>>     > >
>>     > >
>>     > > -------------------------------------------------------
>>     > > This SF.net email is sponsored by: Perforce Software.
>>     > > Perforce is the Fast Software Configuration Management
>>     > System offering
>>     > > advanced branching capabilities and atomic changes on 50+
>>     platforms.
>>     > > Free Eval! http://www.perforce.com/perforce/loadprog.html
>>     > > _______________________________________________
>>     > > ebxmlms-develop mailing list
>>     > > ebx...@li...
>>     > > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>     >
>>     >
>>     >
>>     >
>>     > -------------------------------------------------------
>>     > This SF.net email is sponsored by: Perforce Software.
>>     > Perforce is the Fast Software Configuration Management System
>>     offering
>>     > advanced branching capabilities and atomic changes on 50+
>>     platforms.
>>     > Free Eval! http://www.perforce.com/perforce/loadprog.html
>>     > _______________________________________________
>>     > ebxmlms-develop mailing list
>>     > ebx...@li...
>>     > https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>     >
>>
>>The information contained in this email and any attachments to it:
>>
>>(a) may be confidential and if you are not the intended recipient, any interference with, 
>>use, disclosure or copying of this material is unauthorised and prohibited; and
>>
>>(b) may contain personal information of the recipient and/or the sender as defined 
>>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>>collect, hold and use such information and any personal information contained in a 
>>response to this email, for any reasonable purpose in the ordinary course of 
>>Spherion's 
>>business, including forwarding this email internally or disclosing it to a third party. All 
>>personal information collected by Spherion will be handled in accordance with 
>>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>>sender and delete it.
>>
>>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>>this email and any attachments without first entering into a contractual agreement with 
>>Spherion. You further agree not to divulge any information contained in this document 
>>to any person(s) or entities without the express permission of Spherion.
>>
>>
>>  
>>
>
>     ------------------------------------------------------- This
>     SF.net email is sponsored by: Perforce Software. Perforce is the
>     Fast Software Configuration Management System offering advanced
>     branching capabilities and atomic changes on 50+ platforms. Free
>     Eval! http://www.perforce.com/perforce/loadprog.html
>     _______________________________________________ ebxmlms-develop
>     mailing list ebx...@li...
>     https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>

RE: [ebxmlms-develop] JMSMessageListener contrib?

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

Patrick,
 
I've been looking into the MessageServiceHandler code last night to look
into issues for making it possible to have a web based gui without
tunnelling command's through the msh servlet. I've seen that the
response object is used many layers deep and started refactoring some
parts of the MessageServiceHandler to make it possible to give the
commands in another way. This is almost working, without changing much
of the code, regarding functionality. Al the refactoring took place
mainly in the processCommand method. I've taken out the necessity for
the response object in this method and created one additional method for
those commands that currently realy need the response object
(getMessage, getMessageByID etc...) So besides the processCommand and
ProcessMessage, there now is a processMessageCommand method.
 
Once this is done (at least for myself, but if you are interested, I'm
happy to contribute it), I think it would be possible to spend some time
to see whether we can really start implementing the jms:// kind of
uri's, or maybe don't do it based on the uri, but create different
listeners types (JMSListerner, HTTPListener, FileListener, etc...) each
with their own type of config (including static appContext
configurations?)
 
Great btw, to see the persistence layer be made configurable, i've seen
some things were checked in. Is the api stable enough to start working
on a database persistence layer for the messages?
 
Ronald
 
 
 
-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: woensdag 14 januari 2004 10:44
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] JMSMessageListener contrib?



Peter and Ronald,

Do you think it is possible to base the generic listener on the JMS one
done by Peter? If so, I would like to invite Peter to coordinate with
Ronald on this. I guess the work flow is as follows: we need to align
the design first, and then make the code done and then finally post it
to the CVS. What do you think?

Regards, -Patrick


Mayne, Peter wrote:


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

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

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

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

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

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

> advanced branching capabilities and atomic changes on 50+ platforms. 
> Free Eval! http://www.perforce.com/perforce/loadprog.html
<http://www.perforce.com/perforce/loadprog.html>  
> _______________________________________________ 
> ebxmlms-develop mailing list 
> ebx...@li...
<mailto: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.





  


------------------------------------------------------- This SF.net
email is sponsored by: Perforce Software. Perforce is the Fast Software
Configuration Management System offering advanced branching capabilities
and atomic changes on 50+ platforms. Free Eval!
http://www.perforce.com/perforce/loadprog.html
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

RE: [ebxmlms-develop] JMSMessageListener contrib?

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

No problem, I'll mail it later this evening (around 2100 CET)

> -----Oorspronkelijk bericht-----
> Van: Patrick Yee [mailto:kc...@ce...]
> Verzonden: woensdag 14 januari 2004 10:40
> Aan: ebx...@li...
> Onderwerp: Re: [ebxmlms-develop] JMSMessageListener contrib?
> 
> 
> Ronald,
> 
> Thanks for your contribution. I suggest you can email your patches to 
> us. And then we can manage to post it to the source 
> repository. I guess 
> this is the best way for the time being, to avoid conflicts. 
> What do you 
> think?
> 
> Regards, -Patrick
> 
> 
> Ronald van Kuijk wrote:
> 
> > Hi all,
> >
> > Several months ago, there was a discussion about a JMSReceiver with 
> > uri/url issue. Especially Peter Mayne was working on this and had a 
> > working implementation for this.
> >
> > I'm currently working on an application that will be running within 
> > the same applicationserver as Hermes. I therefor like to 
> have a more 
> > closely integrated method for sending and receiving messages. I was 
> > thinking of a jms queue between the stub and hermes instead 
> of http. 
> > Is there already some code to start with, or extend? Maybe 
> a kind of 
> > contrib thing? Where I can also my LDAPURLResolver, and upcomming 
> > LDAPCertResolver.
> >
> > Ronald
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> ebxmlms-develop mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
> 

Re: [ebxmlms-develop] JMSMessageListener contrib?

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Peter and Ronald,<br>
<br>
Do you think it is possible to base the generic listener on the JMS one
done by Peter? If so, I would like to invite Peter to coordinate with
Ronald on this. I guess the work flow is as follows: we need to align
the design first, and then make the code done and then finally post it
to the CVS. What do you think?<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta content="text/html; " http-equiv="Content-Type">
  <meta content="MS Exchange Server version 5.5.2654.45"
 name="Generator">
  <title>RE: [ebxmlms-develop] JMSMessageListener contrib?</title>
  <p><font size="2">Ronald is correct: I'm still using an HTTP listener
which just passes the message to JMS.</font>
  </p>
  <p><font size="2">I did go some way to using JMS directly, but the
current implementation isn't completely broken, so I didn't completely
fix it. :-)</font></p>
  <p><font size="2">I would also like to see a more generic listener in
Hermes.</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, 12 January 2004 12:24 AM</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] JMSMessageListener
contrib?</font>
  <br>
  <font size="2">&gt; </font>
  <br>
  <font size="2">&gt; </font>
  <br>
  <font size="2">&gt; Peter mentioned in previous messages about the
JMS listerner </font>
  <br>
  <font size="2">&gt; that there </font>
  <br>
  <font size="2">&gt; still is http-tunneling involved in his
implementation. </font>
  <br>
  <font size="2">&gt; Looking at the </font>
  <br>
  <font size="2">&gt; code of the MessageListener and the Request
implementation, I </font>
  <br>
  <font size="2">&gt; see that </font>
  <br>
  <font size="2">&gt; this tunneling is the only 'easy' option. I'm
thinking </font>
  <br>
  <font size="2">&gt; however about a </font>
  <br>
  <font size="2">&gt; more direct delivery of messages through JMS. To
achieve </font>
  <br>
  <font size="2">&gt; this, a lot of </font>
  <br>
  <font size="2">&gt; the servlet implementation has to change. Since
I've read that some </font>
  <br>
  <font size="2">&gt; redesign things are going on (like a separate
persistence layer, and </font>
  <br>
  <font size="2">&gt; some monitoring/controling redesign), is there a
change that </font>
  <br>
  <font size="2">&gt; there will </font>
  <br>
  <font size="2">&gt; be changes in the way messages can be delivered?</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; Ronald van Kuijk wrote:</font>
  <br>
  <font size="2">&gt; </font>
  <br>
  <font size="2">&gt; &gt; Hi all,</font>
  <br>
  <font size="2">&gt; &gt;</font>
  <br>
  <font size="2">&gt; &gt; Several months ago, there was a discussion
about a JMSReceiver with </font>
  <br>
  <font size="2">&gt; &gt; uri/url issue. Especially Peter Mayne was
working on this and had a </font>
  <br>
  <font size="2">&gt; &gt; working implementation for this.</font>
  <br>
  <font size="2">&gt; &gt;</font>
  <br>
  <font size="2">&gt; &gt; I'm currently working on an application that
will be running within </font>
  <br>
  <font size="2">&gt; &gt; the same applicationserver as Hermes. I
therefor like to </font>
  <br>
  <font size="2">&gt; have a more </font>
  <br>
  <font size="2">&gt; &gt; closely integrated method for sending and
receiving messages. I was </font>
  <br>
  <font size="2">&gt; &gt; thinking of a jms queue between the stub and
hermes instead </font>
  <br>
  <font size="2">&gt; of http. </font>
  <br>
  <font size="2">&gt; &gt; Is there already some code to start with, or
extend? Maybe </font>
  <br>
  <font size="2">&gt; a kind of </font>
  <br>
  <font size="2">&gt; &gt; contrib thing? Where I can also my
LDAPURLResolver, and upcomming </font>
  <br>
  <font size="2">&gt; &gt; LDAPCertResolver.</font>
  <br>
  <font size="2">&gt; &gt;</font>
  <br>
  <font size="2">&gt; &gt; Ronald</font>
  <br>
  <font size="2">&gt; &gt;</font>
  <br>
  <font size="2">&gt; &gt;</font>
  <br>
  <font size="2">&gt; &gt;
-------------------------------------------------------</font>
  <br>
  <font size="2">&gt; &gt; This SF.net email is sponsored by: Perforce
Software.</font>
  <br>
  <font size="2">&gt; &gt; Perforce is the Fast Software Configuration
Management </font>
  <br>
  <font size="2">&gt; System offering</font>
  <br>
  <font size="2">&gt; &gt; advanced branching capabilities and atomic
changes on 50+ platforms.</font>
  <br>
  <font size="2">&gt; &gt; Free Eval! <a target="_blank"
 href="http://www.perforce.com/perforce/loadprog.html">http://www.perforce.com/perforce/loadprog.html</a></font>
  <br>
  <font size="2">&gt; &gt;
_______________________________________________</font>
  <br>
  <font size="2">&gt; &gt; ebxmlms-develop mailing list</font>
  <br>
  <font size="2">&gt; &gt; <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a></font>
  <br>
  <font size="2">&gt; &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>
  <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 is sponsored by: Perforce
Software.</font>
  <br>
  <font size="2">&gt; Perforce is the Fast Software Configuration
Management System offering</font>
  <br>
  <font size="2">&gt; advanced branching capabilities and atomic
changes on 50+ platforms.</font>
  <br>
  <font size="2">&gt; Free Eval! <a target="_blank"
 href="http://www.perforce.com/perforce/loadprog.html">http://www.perforce.com/perforce/loadprog.html</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>
<br>
</body>
</html>

Re: [ebxmlms-develop] JMSMessageListener contrib?

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

Ronald,

Thanks for your contribution. I suggest you can email your patches to 
us. And then we can manage to post it to the source repository. I guess 
this is the best way for the time being, to avoid conflicts. What do you 
think?

Regards, -Patrick


Ronald van Kuijk wrote:

> Hi all,
>
> Several months ago, there was a discussion about a JMSReceiver with 
> uri/url issue. Especially Peter Mayne was working on this and had a 
> working implementation for this.
>
> I'm currently working on an application that will be running within 
> the same applicationserver as Hermes. I therefor like to have a more 
> closely integrated method for sending and receiving messages. I was 
> thinking of a jms queue between the stub and hermes instead of http. 
> Is there already some code to start with, or extend? Maybe a kind of 
> contrib thing? Where I can also my LDAPURLResolver, and upcomming 
> LDAPCertResolver.
>
> Ronald

[ebxmlms-develop] ToParty in the ack message

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

Dear all,

=20

I have tried the following code to test the toParty and fromParty in the =
ack message.  Hermes swaps the first fromPartyID and toPartyID and DROPS =
all the rest partyID when generating the asynchronous acknowledgment. =20

Can Hermes not to drops the partyID?  Since those information would be =
useful for the toParty or any other intermediate.

=20

Actually, I=A1=A6m now trying to add an intermediary router between MSHs =
and get the problems.

i.e.   MSH(s) <----> Intermediary Router < ---- > MSH(s)

Here is the logic of intermediary router

1.        Get the ToPartyID (e.g. DUNS number in this case) from ebxml

2.        Use ToPartyID as a key to get the real destination from the =
routing table.

3.        Post the ebxml to the real destination

=20

 =20

In the test case, the router can=A1=A6t route the ACK message since it =
drop all the ToPartyID except the first one.  Can Hermes remains those =
ID in the future release?  Or anyone can suggest a better implementation =
to this issue?

=20

Marcus Wong





_____________________________________________________

Client Source

_____________________________________________________

import java.net.*;

import java.util.*;

import hk.hku.cecid.phoenix.message.handler.*;

import hk.hku.cecid.phoenix.message.packaging.*;

=20

public class LoopBack implements MessageListener {

=20

        public static void main(String [] args) {

           LoopBack sample =3D new LoopBack();       =20

           sample.run();

        }

=20

        public void run() {

           try {

              System.out.println("Packaging...");

       =20

                     String cpaID =3D "CPA_2002";

                     String conversationID =3D "Item_No_128" ;

                     String service =3D =
"http://www.cecid.hku.hk/ebxml/service";

                     String action =3D "Order";

=20

              ApplicationContext ac =3D new ApplicationContext( cpaID, =
conversationID, service, action);

                     String transportType =3D "HTTP";

                     String toMshUrl =3D "http://localhost:8081/msh";

              Request mshReq =3D new Request(ac, new URL(toMshUrl), =
this, transportType);

=20

              EbxmlMessage message =3D new EbxmlMessage();

              MessageHeader header =3D message.addMessageHeader();

=20

              header.addFromPartyId("http://localhost:8082/msh", =
"abcid");

              header.addFromPartyId("http://localhost:8084/msh");

              header.addFromPartyId("12345","DUNS");

                    =20

              header.addToPartyId( "http://localhost:8085/msh", =
"abcid");

              header.addToPartyId( "http://localhost:8086/msh");

              header.addToPartyId("678910","DUNS");

=20

              header.setCpaId(cpaID);

              header.setConversationId(conversationID);

              header.setService(service);

              header.setAction(action);

              header.setTimestamp(Utility.toUTCString(new Date()));

=20

                     String messageId =3D Utility.generateMessageId(new =
Date(), message);

              header.setMessageId(messageId);

=20

              message.saveChanges();

=20

              System.out.println("Try to send...");

              mshReq.sendReliably(message,false);

              Thread.sleep(10000);

           }

           catch(Exception e) {

              e.printStackTrace();

           }

        }

=20

        public URL getClientUrl() {

           return null;

        }

=20

        public void onMessage(EbxmlMessage ebxmlMessage) {

        }

}

=20

=20

_________________________________________

Request (Port 8085):

_________________________________________

<soap-env:Envelope =A1K>

=A1K

<eb:From>

<eb:PartyId eb:type=3D"abcid">http://localhost:8082/msh</eb:PartyId>

<eb:PartyId>http://localhost:8084/msh</eb:PartyId>

<eb:PartyId eb:type=3D"DUNS">12345</eb:PartyId>

</eb:From>

<eb:To>

<eb:PartyId eb:type=3D"abcid">http://localhost:8085/msh</eb:PartyId>

<eb:PartyId>http://localhost:8086/msh</eb:PartyId>

<eb:PartyId eb:type=3D"DUNS">678910</eb:PartyId>

</eb:To>

=A1K

<eb:MessageId>20040113-083038250-CPA_2002.http://www.cecid.hku.hk/ebxml/s=
ervice.Order.1@10.30.10.138</eb:MessageId>

=A1K

<eb:AckRequested =
xmlns:eb=3D"http://www.oasis-open.org/committees/ebxml-msg/schema/msg-hea=
der-2_0.xsd" eb:version=3D"2.0" soap-env:mustUnderstand=3D"1" =
eb:signed=3D"false" =
soap-env:actor=3D"urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH"/></soap-=
env:Header>

=A1K

</soap-env:Envelope>

=20

=20

_________________________________________

Reply (Port 8082)

_________________________________________

<soap-env:Envelope =A1K>

=A1K

<eb:From>

<eb:PartyId eb:type=3D"abcid">http://localhost:8085/msh</eb:PartyId>

</eb:From>

<eb:To>

<eb:PartyId eb:type=3D"abcid">http://localhost:8082/msh</eb:PartyId>

</eb:To>

=A1K

<eb:Acknowledgment =
xmlns:eb=3D"http://www.oasis-open.org/committees/ebxml-msg/schema/msg-hea=
der-2_0.xsd" eb:version=3D"2.0" soap-env:mustUnderstand=3D"1">

<eb:Timestamp>2004-01-13T08:30:38Z</eb:Timestamp>

<eb:RefToMessageId>20040113-083038250-CPA_2002.http://www.cecid.hku.hk/eb=
xml/service.Order.1@10.30.10.138</eb:RefToMessageId>

<eb:From>

<eb:PartyId eb:type=3D"abcid">http://localhost:8085/msh</eb:PartyId>

</eb:From>

</eb:Acknowledgment>

=A1K

</soap-env:Envelope>

RE: [ebxmlms-develop] CPP/A integration

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

For resolving a party-id to a certain URL u can provide a resolver class
in the config file. I've implemented an LDAPURLResolver myself, to map
numbers from the chamber of commerce to an url. Look in the code for the
default implementation.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Gait Boxman [mailto:gai...@ti...]
Verzonden: dinsdag 13 januari 2004 8:51
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] CPP/A integration


Hi Marcus,
 
Just a first reply, others might jump in with more detail :-)
 
Hermes is based on ebXML Messaging Specification 2.0, we don't directly
integrate with CPP/A, but the properties you mention are actually in
ebMS as well.
Let's see:
1. duplicateElimination - yes, you can set the duplicateElimination flag
in the message you send to tell the other MSH to eliminate duplicates,
and Hermes listens for it.
2. ackRequested - yes, another property you can set, and Hermes listens
for it.
3. message ordering is supported within a given application context
(cpa,conversation)
4. isNonRepReq'd - you can request the ack to be signed, which will give
NRR, messages can also be sent signed.
 
Actually, hermes uses the toMSHUrl property for the endpoint, and the
applicationcontext for delivery to a listener of the received message.
In the samples,the toMSHUrl may be the same as the toPartyId..
toPartyId has to be a URI unless you specify a type (per ebMS2).
Unfortunately, there is no authorative code list for the type parameter,
but "DUNS" might work well for you. In the code where you add the
toPartyID, simply add the type string as an extra parameter to your
call.
 
For asynchronous replies, I believe Hermes currently relies on (one of)
the fromPartyId(s) of the original message to hold the MSH URL to send
the reply to. Work is on the way to remove this dependency..

----- Original Message ----- 
From: Marcus Wong <mailto:mar...@ho...>  
To: ebx...@li... <mailto:ebxmlms-develop@lists.
sourceforge.net>  
Sent: Tuesday, January 13, 2004 8:16 AM
Subject: [ebxmlms-develop] CPP/A integration





Dear all, 



 

I’m new to Hermes.  I’ve some questions about CPP/A integration.

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

 

1.      duplicateElimination 

2.      ackRequested

3.      messageOrderSemantics

4.      isNonRepudiationRequired

 

 

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

 

 

 

Regards,

Marcus Wong