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

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

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

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



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

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

Cheers, -Patrick


Ronald van Kuijk wrote:


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

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


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

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

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

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


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


Mayne, Peter wrote:


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

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

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

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