[ebxmlms-develop] Beyond hermes 1.0

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

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