[ebxmlms-develop] RE: Hermes confugration

[Mayne, P. <Pet...@ap...>]

Excellent.

The development guide makes no mention of MessageListenerImpl. It does say
"getClientURL() should return a URL if you intend the MSH application
server to send the received message directly to you via that URL". This led
me to believe that merely modifying LoopBack.java's getClientUrl() to return
a URL ("http://myServer/") would make Hermes send the received message
directly to my HTTP server. It does not imply (to me) that I must implement
the sending myself. (It took some time trawling through the source code to
discover the existence of MessageListenerImpl which uses an HttpSender.)

Now that (I think) I know what's going on, the documentation can be read in
a new light, but the message listening mechanism is still somewhat unclear.

Perhaps some clarification in the documentation is required. 8-)

Thanks.

PJDM
-- 
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727  F: 61 2 62689777 
-----Original Message-----
From: Frankie Lam [mailto:fr...@mi...]
Sent: Friday, 31 January 2003 6:45 PM
To: Mayne, Peter
Cc: Vijiaraj, Prabaharan; ebx...@li...
Subject: Re: Hermes confugration


Dear Peter,

There are currently three ways to receive a message in 0.9.2.0:
1. Trusted repository approach - the incoming message is saved as a file.
2. Client-side polling - the Request object constantly polls the MSH and see
if there is new message.
3. URL approach - the incoming message is sent to the location specified,
e.g. a mail account.

The key to choosing the approach to receive message is MessageListener and
its URL parameter:
1. Trusted repository - URL points to a directory location, e.g.
"file://tmp/ebxmlms/repository".. This directory must be configured in MSH
configuration file. "MessageListenerImpl" should be used instead of
implementing an MessageListener interface by yourself, since it will never
be called.
2. Client-side polling - URL should be "null", and you can implement
MessageListener interface and pass "this" to the constructor.
3. URL approach - this is very similar to case 1. In fact, if the URL has a
"file" protocol, it is regarded as a repository. Otherwise it is the
destination address where the message should be sent.

I think your implementation is correct =)

Best regards,
  Frankie
----- Original Message ----- 
From: Mayne, Peter 
To: 'fr...@mi...' 
Cc: Vijiaraj, Prabaharan 
Sent: Friday, January 31, 2003 7:58 AM
Subject: Hermes confugration


I work with Prabaharan Vijiaraj at Spherion. We've been looking at the
Hermes Message Service Handler V0.9.2.0. Praba says that you're the current
support mechanism. 8-)
We set it up so the LoopBack test works. The documentation says that
returning a URL from getCLientUrl() will make the server pass incoming
messages to that URL. However, doing this just made the server instantiate a
LoopBack object and call its onMessage() method.
To get the server to send an incoming message to a URL, we had to replace: 
Request mshReq = new Request(ac, new URL(toMshUrl), this, transportType); 
with: 
MessageListener ml = new MessageListenerImpl(new
URL("http://myWebServer/")); 
Request mshReq = new Request(ac, new URL(toMshUrl), ml, transportType); 
which bypasses the LoopBack client's getClientUrl completely. 
Is this the correct way to send an incoming message to a URL? 
Thanks. 
PJDM 
--  
Peter Mayne 
Technology Consultant 
Spherion Technology Solutions 
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 
T: 61 2 62689727  F: 61 2 62689777 
The information contained in this email and any attachments to it:

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

(b) may contain personal information of the recipient and/or the sender as
defined 
under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to 
collect, hold and use such information and any personal information
contained in a 
response to this email, for any reasonable purpose in the ordinary course of

Spherion's 
business, including forwarding this email internally or disclosing it to a
third party. All 
personal information collected by Spherion will be handled in accordance
with 
Spherion's Privacy Policy. If you have received this email in error, please
notify the 
sender and delete it.

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