Brian Topping wrote:
Hi Pierre,
By your inquiry on the future, do you mean with specific features in the
applications or how they work together?
As an architect, I am interested in not just an ability to integrate my
application against OFBiz, but allow my application to
take part in message orchestration by patching itself into the workflows. I
should like that a stock OFBiz deployment can be
customized through open interfaces with now-common enterprise integration
patterns instead of requiring a proprietary (if open)
means of application customization.
Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I think the
"major moving parts" of that model might
provide a good pattern for how the applications could work together in the
future. (In other words, Mule might be preferred, but
the applications still remodeled on EIP for open integration).
Why Mule rather than ServiceMix? I can't see much diff. between them.
If the applications integrated this way and were uncoupled into separate Maven
projects, the applications would also be usable
individually where appropriate. It would be a challenge to do this, but a new
class of user would result, one that could pick
and choose applications that they wanted to integrate against their local
deployment instead of the current all-or-nothing
approach.
ServiceMix has some rather comprehensive integrations with Maven in this regard
which I don't pretend to understand very well,
but a team effort might result in a solution that really reinvigorates the
ecosystem through a large number of new use cases of
existing applications. For instance, REST style or WS interfaces might open
the applications to use by Ruby or PHP developers.
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)
The depth and experience wrapped up in the OFBiz ecosystem is staggering, but
it's reach is limited by it's rather monolithic
Java-centric deployment. If opening it up in this way would significantly
alter the user base, there would be a lot more
opportunities for everyone involved.
I am not trolling here, so please excuse if what I am writing is naive. I do
not have enough technical chops on the guts of
OFBiz to know what toes I am stepping on, just presenting a vision of what I
would like to integrate against. I did investigate
OFBiz for an ERP solution I need to deliver in the retail space and found that
it would be challenging to use the user interface
facilities I found to create the customer UI. My solution was to avoid the
problem by building my web UI in a message-oriented
manner, back it by Mule, and push the problem out to the future.
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.
Jacques
It's not a question for me of whether OFBiz will be there when
I need it, but more that I will integrate against the applications with
standard EIP. If OFBiz had an accessible EIP
presentation like this, it would be a natural choice to integrate with, both
for me, and I suspect many other people in my
situation. The Ode style orchestration is more about the applications working
together, which would be grav! y on the meal.
$0.02...
Brian
