On Jan 27, 2011, at 7:40 AM, Jacques Le Roux wrote: > Why Mule rather than ServiceMix? I can't see much diff. between them.
ServiceMix is more strongly based on W3C WS where Mule is more open to different transports. I felt for my application that Mule would be more performant, although I prefer the infrastructure support that ServiceMix provides (OSGi, Maven). > For PHP I will soon make a proposition. It's based on Quercus (GPL hence of > out OFBiz repo) and sitting on my table for almost 2 years now (my bad) Quercus looks really good and I've considered it in the past for other projects. It has some notable longstanding issues, but they can be worked around. What I am concerned about by having named only two (Ruby, PHP) is that I left out dozens of other technologies. Quercus only solves one (PHP). What I am aiming for is opening up access to the great elements that OFBiz provides to any language that can support integration standards, not just repackage Java interfaces on a language-by-language basis. > I have seen others taking the same approach, for instance to link ElasticPach > with OFBiz, or even to link diff. versions of OFBiz... > But it makes more sense IMO for legacy than for new UIs. Of course this > implies to know/use OFBiz widgets, but it's not that hard. It's very very hard when the OFBiz widgets are assuming a UX workflow or stylesheets that are different than the rest of the application. It's also very very hard when the rest of the application is not completely OFBiz based (in which case, there would be no reason to do any of this). The goal I am talking about is fundamentally different than a star configuration of integration where every integration endpoint must have strong coupling with every other application through direct API calls. By using a bus configuration, an integration point just publishes itself on the bus, and other applications can be routed to whatever application can accept messages of that type. It is the tight coupling to Java interfaces that needs to be weakened, IMO.
