Re: [ebxmlms-develop] Web admin and other contributions?

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

Patrick Yee wrote:

> Ronald van Kuijk wrote:
>
>> No problem, I haven't been working on it anyway, since I've been 
>> focussing on an xforms implementation which we (me and some others) 
>> want to integrate into a BPM/WFM/B2B/EAI solution based on opensource 
>> projects (ebxmlms, chiba, jbpm all on sourceforge). Glad you 
>> responded now. btw, did you guys switch of the commit mailinglist? I 
>> thought there hadn't been any changes since january, but after doing 
>> a compare I saw there have been changes, and good ones imo.
>>
> The commit mailing list doesn't work anymore and I don't know why. I 
> have to check with sourceforge.
>
<cut/>

> We have to admit that we don't have much experience in maintaining an 
> open source project like this.

Same goes for me :-)

> So as you can see our moves, it's easier for us to commit the changes 
> provided that it's a "hook" to the current architecture. I mean, 
> whenever there is a request for more flexible way to handle things, we 
> prefer to make it as a hook and let the developers make their own 
> handling implementation.

Yes, sounds obvious,  I'm looking into one new 'hook' now. My JMSMonitor 
should not be included in the core since it  makes it j2ee dependend. 
What I'm doing now is make a 'Monitors' object that reads something like 
this from the general config:

<Monitors>
   <MonitorItem>
      <Class>tld.mycompany.monitor.MyMonitorImpl</Class>
      <ConfigFile>/my/configFile.xml</ConfigFile>
   </MonitorItem>
   <MonitorItem>
      .....
    </MonitorItem>
</Monitors>

Even the MailMonitor that you provide by default could be included this 
way, and instead of the ConfigFile reference the properties could in the 
default configfile e.g. with a <Properties> tag instead of  <ConfigFile> 
This currently works great for me and keeps the default distribution 
clean of j2ee dependend things.

> Refactoring is a far more complicated thing. In fact, we are aware of 
> the limitation of the current architecture. Internally, we have a 
> thought to rewrite the whole core architecture (Hermes 2.0?), while 
> hoping we can reuse the ebXML messaging handling part (e.g. those 
> methods in MessageServiceHandler).

This is exactely what I've been banging my brains on as well. Especially 
in relation to clustering. I have some Ideas on how to make it pluggable 
as well so a 'simple' servlet based version uses the implementation like 
it is now, and for clustered versions there is maybe a dependency on 
j2ee things.

Is there any reason not to call the current HEAD in cvs version 1.0 and 
start refactoring certain parts (e.g. the dependency on the 
HttpServletRequest object for sending messages? So the frontend is 
already split into 3 parts (receiving messages from the external world, 
receiving requests to send messages from internal systems and a 
'command/configure' part.

> Another important goal we want to achieve is to support more B2B 
> messaging protocols (e.g. WS-ReliableMessaging and AS2). Given that, 
> the idea of refactoring is important and the impact is much higher. :-)

Can't wait. Would be perfect for the integration project I'm doing

>
>
>> Yes and no, the contribution is currently not to flexible 
>> configuration wise, although it has been running here since februari 
>> in a demo server (not doing to much I have to admit ;-) ). The 
>> contribution was primarily  to give an idea what the problems. I 
>> think a consesus has to be reached on how to refactor certain parts, 
>> which mainly are in the MessageServiceHandler. So no do not include 
>> it in the 1.0 release.
>
>
> Agreed. That fits our thoughts on Hermes 2.0 as well.
>
>> Any time and thank you (all) for this product. I'm reviving a wiki I 
>> set up long ago do also discuss these things with the other people 
>> I'm working with. The main thing is that we should agree on a roadmap 
>> and then I/we have plenty of time available to work on this.  There 
>> are some other things we have in mind, but I think you'll see them 
>> appear on the wiki (I'll send the link once it is ready)
>
>
> Great. We look forward to that. Thank you.

Best,

Ronald