Patrick Yee wrote:
> Ronald van Kuijk wrote:
>
>> One thing I like to do there is move the Command object internal into
>> Hermes and not expose it to the outside world. Each monitor is then
>> responsible for mapping a request into a Command object. e.g.
>> - an xml structure can have all command elements in tags
>> - a jms monitor gets the command elements from jms headers
>> - a servlet monitor gets it from request parameters
>>
>> This is exactely what I was proposing on the other thread by
>> splitting the use of the one servlet into separate things. Each
>> implementation of a monitor is then also responsible for their own
>> authentication (which I hope will one day be based on the principal
>> from the servlet/j2ee engine
>>
>> Ronald
>>
> I agree with this totally. Thanks for the idea, Ronald.
> Regards, -Patrick
>
I'd be more than happy to give this a first try. It would make a web-gui
much easier to build etc...
Question about terminology:
- A dispatcher is a piece of code (module) receiving requests to send
(dispatch) a message on behalf of internal applications
- A ..... is a piece of code (module) sending messages to other MSH's
(currently smtp and http)
- A monitor is a piece of code (module) receiving messages from the
internet (currently imap and http)
- A ..... is a piece of code (module) delivering messages to applications
What should be on the dotted lines?
Short proposal
------------------------------
The following are fully 'internal' to hermes
- One default MSH servlet for receiving messages from the internet
- One configurable MailMonitor for receiving messages from the internet
- One servlet for receiving commands from the fat-client monitor
application (excluding the sending of messages, just the
start/stop/archive/.... commands
Configurable:
- One servlet for receiving 'dispatch message' requests, NOT using the
command object (this will be a default for hermes, but in a configurable
way)
- One JMS listener for receiving 'dispatch message' requests, NOT using
the command object (this will *not* be default in hermes, but in a
contrib dir and used in a configurable way.
<Dispatchers>
<DefaultServletDispatcher>ON</DefaultServletDispatcher>
<DispatcherImpl>
<Class> ......... </Class>
<ConfigFile>....... </ConfigFile>
</DispatcherImpl>
<DispatcherImpl>
<Class> ......... </Class>
<ConfigFile>....... </ConfigFile>
</DispatcherImpl>
</Dispatchers>
Delivering messages to applications is currently done by dynamically
registering a url. Besides this form, I'd like to have a
preconfigurable way. Kind of registering a context in the admin.
- File
- HTTP
- JMS (again the jms/url 'discussion")
- XMLRPC? / SOAP
Security (who has access to a certain dispatchers and how should that be
configured?) is a thing that has to be worked out. I would propose to
have the dynamic registration like there is now only in a development
mode. For a production mode dynamic registration should be off. Security
can than be worked out by using normal java security and detecting the
role a user is in when he accesses a certain dispatcher.
Ronald
P.S. I cross-posted to the development mailinglist to take the
discussion there and changed the subject
|
