Hi David, thanks for setting me straight here. Mule might be a pretty good fit for this kind of integration. One of the things ServiceMix focuses on is WS, Mule could work with these interfaces.
What might not be obvious is that Mule could do all the message marshaling to the formats you mentioned and more, like ReST. Instead of maintaining this code, it might be valuable to export maintenance and upkeep on these interfaces to Mule. An additional upside is it gives the client a number of additional ways to connect, such as with JMS, also maintained as a part of Mule. One concern is your observation that "[h]owever, the XML-RPC and JSON ones are pretty good", with emphasis on "pretty good". I read from that they are not perfect. If these are not the mainline interfaces, they are bound to lag or not be accurate. Mule both provides a external front-end to application APIs, as well as a performant means to access them internally. By unifying these access points, maintenance and testing efforts are similarly reduced. The reduction is likely offset by the extra effort to integrate Mule in the first place, but functionality should make the risk in the tradeoff worth it, and at some point, it's all payback. I'll do more digging about the interfaces that you talked about here. I clearly didn't understand some of the options available. Thanks, Brian On Jan 27, 2011, at 11:40 AM, David E Jones wrote: > > 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 > >
