Re: [ebxmlms-develop] JMS receiver

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

<!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>
Peter, 
 
Are you writing your MessageListener implementation and passing it to
Request? I presume you are implementing the interface MessageListener.
In our design, any MessageListener implementation sumbitted to Request
will be "interpreted" as either MessageListenerImpl or
ClientMessageListenerImpl in Hermes server. The former one is for
storing received messages in the repository/file system in the Hermes
server side. The client will be accessing that file system directly for
incoming messages. The latter one implies polling from Hermes client
side to Hermes server. Once a message is polled, the implementation
will either store it in the file system in client side or calling the
onMessage() method to deliver the message. 
 
In other words, we don't currently allow the implementation passing to
Request to be executed in Hermes server. This is due to both technical
and security concerns. Therefore, in your case, you may write your own
MessageListener implementation which pass null as client URL. The
Hermes server will interpret this as "poll needed", and start a poller
automatically. Then, once a message is polled, your onMessage() will be
called and you can do your logic for delivery of message. 
 
Any comment? 
 
Regards, -Patrick 
 
 
Mayne, Peter wrote: 
<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>RE: [ebxmlms-develop] JMS receiver</title>
 I've written an MessageListener (not based on
MessageListenerImpl) that doesn't use a URL, so I just returned null
from getClientUrl(). However, Hermes assumes that if getClientUrl()
returns null, there's nothing to do, so my MessageListener doesn't get
called. Therefore it has to return a random URL (such as <a
 href="http://1.1.1.1/" target="_blank">http://1.1.1.1/</a>) just to
get the messages. This seems very untidy to me.
 Here's an alternative suggestion for
MessageListener. Define the following: 
 public interface MessageListener extends
Serializable 
 { 
 &nbsp;&nbsp;&nbsp; void onMessage(EbxmlMessage ebxmlMessage); 
 } 
 public interface UrlMessageListener extends
MessageListener 
 { 
 &nbsp;&nbsp;&nbsp; public static final String PROTOCOL_xxxx = "xxxx"; 
 &nbsp;&nbsp;&nbsp; ... 
 &nbsp;&nbsp;&nbsp; URL getClientUrl(); 
 &nbsp;&nbsp;&nbsp; void onMessage(EbxmlMessage ebxmlMessage); 
 } 
 public class MessageListenerImpl implements
UrlMessageListener 
 { 
 &nbsp;&nbsp;&nbsp; ... 
 } 
 Remove "URL getClientUrl()" from the
MessageListener interface. Within Hermes, check to see if the
MessageListener that is being dealt with is an instanceof
UrlMessageListener. (This already happens in MessageServiceHandler,
which checks for MessageListenerImpl.) If so, cast the MessageListener
to UrlMessageListener and continue as present, calling getClientUrl()
as required. If not, just call the MessageListener.
 This seems neater than forcing MessageListener to
use a URL/URI, because a MessageListener doesn't necessarily have one.
 PJDM 
 -- 
 Peter Mayne 
 Technology Consultant 
 Spherion Technology Solutions 
 Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602 
 T: 61 2 62689727&nbsp; F: 61 2 62689777 
 -----Original Message----- 
 From: Mayne, Peter 
 Sent: Thursday, 22 May 2003 4:10 PM 
 To: '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>' 
 Subject: RE: [ebxmlms-develop] JMS receiver 
 
 My tentative suggestion for MessageListener is that
it use a URI rather than a URL. The MessageListener class *identifies*
a message listener, but it is up to implementations of the
MessageListener to *locate* a message listener.
 Therefore, MessageListener's getURL() becomes
getURI(). 
 A URI is easily converted to a URL (with toURL()), so
users of MessageListener that want to interpret the URI as a URL can do
so. In some cases, the only interesting part of the URL seems to be the
protocol, so URI.getScheme() could be used directly without having to
convert to a URL first.
 It could be possible to implement a MessageListener
that uses a scheme other than http and file, but there's at least one
place in the code that goes something like:
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if(clientUrl==null) 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { .... 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if(protocol.equals(FILE)) 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { .... 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { .... 
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } 
 which means that a non-http MessageListener would have
to use a dummy http URL (like "<a href="http://1.1.1.1/" target="_blank">http://1.1.1.1/</a>"
for instance) just to get Hermes to do the right thing, and more than
one dummy http URL to indicate different delivery instances. This seems
rather illogical to me: using an http URL to indicate a JMS queue just
isn't right. I'd much rather be able to create a MessageListener
instance with a URI such as <a class="moz-txt-link-rfc2396E" href="jms:...">"jms:..."</a> or <a class="moz-txt-link-rfc2396E" href="tcp:...">"tcp:..."</a> or whatever.
 Given the addition of an initialisation hook into
Hermes, an alternative MessageListener (eg JmsMessageListener) could be
registered whenever Hermes starts.
 The current MessageListenerImpl would be better
named asUrlMessageListener or somesuch. 
 Comments? 
 PJDM 
 
 <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>