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

[Patrick Y. <kc...@ce...>]

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.


> I agree, it should be incremental. It contains three parts as I 
> recall. (one of them is lost locally)
> - using a jdbc datasource/connectionpool in stead of  the 'proprietary 
> one'   : priority low-medium, impact: medium   (this one is lost locally)
> - refactoring the MessageServiceHandler so there is easier (but 
> secure!) access to the commands (e.g. for a web interface (dropping 
> the swing gui would make it easier))
> - refactoring the 'monitor' part of the MessageServiceHandler so other 
> ways of sending messages could be achieved (e.g. a jms monitor ) : 
> priority High impact medium
>
> Things that make the refactoring difficult (although I think I've 
> created a nice solution) is the deep dependency on the 
> HttpServletRequest and HttpServletResponse objects. For receiving 
> messages/commands from an application I've already made some changes. 
> Probably not in the best way, It was just to see if it could be done. 
> I had to change private/protected into public in some places, so 
> securitywise it is probably not the best solution. Again, it was just 
> to get an idea of the road ahead. One thing I have not looked into is 
> the delivery of messages to an application. Since there is already a 
> configurable way to define your own listeners I did not touch that.
>
>

We have to admit that we don't have much experience in maintaining an 
open source project like this. 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. 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). 
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. :-)


> 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.

Regards, -Patrick