Brian Topping wrote:
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).
Yes indeed, JBI requires WSDL. Not sure about peformance, though yes Mule has a good reputation from this POV. Is the difference
worth the rest?
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.
The idea is more for reusing legacy code, without introducing an ESB for that
(sledge-hammer vs fly)
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.
So you are mostly interested by OFBiz as WS API. David already explained how it's possible to use OFBiz without an ESB in such case
(XML-RPC). In term of development productivity, I might be interesting to consider this possibilty.
Jacques
