just so we are on the same page is this what you call ESB?
http://en.wikipedia.org/wiki/Enterprise_service_bus
I note this is similar to the Windows Operating systemm.
Since ofbiz is already pushing memory limits not sure it could handle
such a system and keep speed.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Brian Topping sent the following on 1/20/2011 11:53 PM:
On Jan 20, 2011, at 10:59 PM, David E Jones wrote:
Do you really think that is the best idea? Isn't one of the problems with OFBiz
that everything is in one big pot, but not all users want the same thing, and
so there are constant fights about what should go into the single pot?
Maybe it would be better if there were a stable framework and a bunch of separate
"pots" sitting on top of it that address different audiences and are driven by
different groups with different needs/wants? That would apply to different themes,
different UIs, different business domains, etc.
This would have convinced me to go deeper with OFBiz had it existed.
Personally, I think the right way to connect all the pots is with an ESB. I
really like what OFBiz can offer my project as far as existing workflow and
domain models, and lose interest when I am required to use a tightly-coupled UI
with it.
I swear by Wicket, but some others are going to swear by Vaadin or GWT and I
would choke and turn blue before using them. We haven't even started
considering some of the cool stuff available with Grails or what kind of UI
could be autogenerated from messages. And whether I would adopt any of these
UIs if they were accessible as a Maven artifact from a Nexus repository (i.e.
if I can deploy it to the JVM and don't have to maintain it, why do I care?)
There's no accounting for taste, but the switchboard has to be opened up so
people can integrate. That's what an ESB is all about.
When the "pots" are distributed over an ESB, I don't care whether they are
running OSGi or running on a hamster wheel, and if one of them is causing me problems, I
can deal with them as needed, without having an all-or-nothing decision to make.
When my switchboard can connect seamlessly to something like SAP, I can
convince stakeholders that they are future-proofed to some greater degree.
Every company that buys into the architecture expands the entire ecosystem in
the process, everyone wins.
Certainly, when it gets to the domain level, it would be helpful to continue
with what makes OFBiz great, but XML schema with element overrides makes a for
a far better and more portable representation than anything we could cook
ourselves. OMG standards for metadata, such as CWM [1] are conceptually far
more powerful than anything we could dream up on our own and have existing tool
support, which is better than starting from zero. Even if we just modeled our
own after CWM concepts, we'd be further ahead of the current unique method,
however open.
If we end up with Maven artifacts that form APIs to deal with the domain
through such means, people can mix and match artifacts for custom solutions.
As well, other projects will start reusing OFBiz subprojects, further
increasing the connectedness and vitality of the ecosystem.
I'm interested in how / where I am missing the boat on this, but I feel like
this old architecture is holding everyone back. At some point, the pressure on
it will be too great to resist even the combined inertia of the available OFBiz
solutions, it's just a matter of when.
Brian
[1] http://en.wikipedia.org/wiki/Common_Warehouse_Metamodel
