Brian, If I understand correctly you are proposing an architecture where the UI ONLY accesses the data store through remote service calls (ie all reads and writes go through a remote service) and in effect the database and services would live in one server and the UI would live in another and access it through some sort of ESB? Basically the UI server and the data/logic server would only communicate through these common standard XML documents sent over the network.
Have you ever worked with a system that was architected in this way? These standards are great, but are really meant for integration between separate systems. I've definitely heard of the idea of doing things this way, quite a lot in fact, but I've never seen an enterprise system architected in this way. There are certainly organizations that have an enterprise architecture where they try to push everything through an ESB, but only the messages that need to go between systems and not every little thing that a system might do internally. If you, or anyone, has experiences with that it would be interesting to hear about. -David On Jan 20, 2011, at 11:53 PM, Brian Topping wrote: > > 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
