Brian, Have you looked into the integration-oriented features of OFBiz? IMO SOAP is a mess and while there has been a SOAP to OFBiz Service tool for a long time, it has never been very good. However, the XML-RPC and JSON ones are pretty good, and along with general XML message passing (like the OAGIS XML messages in OFBiz) these are used a lot for integration with other systems, and even other types of UIs. The basic idea is that you can call ANY OFBiz service (if it is flagged for external use) through these integration means without having to write any extra code on the server (unless you can't control the service definition and need to build a service to match a certain definition, then obviously you'll need to do some server side coding).
In addition to those if you are writing anything in Java or that runs on a JVM it is VERY easy to use the Service Engine's remote dispatcher to get an object from JNDI on the OFBiz server and then do service calls, with no extra code on the client or server... just start calling services and passing data in and getting data back. Some of your other assertions are not quite correct either. For example, if you want to use another Java web UI technology you can do it in container, even in an OFBiz webapp with other OFBiz stuff, with no problem. Just add it to the web.xml file like you would in any other situation. It's not that big a deal. -David On Jan 27, 2011, at 2:50 AM, 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). > > 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. 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. 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 > gravy on the meal. > > $0.02... > > Brian
