There's nothing we can do about bad specs like SOAP. However, consider that OFBiz is just one little open source project, and hasn't seen even close to one percent of the investment in development that .NET or even SalesForce.com have.
On the other hand, there are good tools for building SOAP clients and servers, so fortunately in OFBiz we don't have to invest in such things. Just look into a good IDE that has tools for building SOAP services and service clients, that's the easy way out. There are some nice tools built on the Eclipse IDE, though I use IntelliJ IDEA mostly these days. BTW, in the real world of integration the reality is that there are hundreds of standards, and unless two things are designed to work well together or one has extensions to support the other, then you'll have to look into what each supports and figure it out. You didn't say what made you experiences with .NET and Salesforce easy, so it would be hard to guess at that, but changes are the SalesForce SOAP services are just as annoying as any other to work with manually, so it was really the .NET IDE you used that made it easy. The same things exist in the Java world, but not part of OFBiz (which is not an IDE). -David On Jun 24, 2011, at 6:49 PM, MikeBranch wrote: > Thanks, everybody for your replies. They were all very helpful. It sounds > like my idea of using XML-RPC would be the less painful approach. I have > gotten XML-RPC to work on .NET, but haven't tried it with OFBiz yet. > > Re: The QB Web Connector: That was where I started, but the problem is that > you have a canned client (QBWC) that you can't change, so you need to build > the service to be compatible with the client. Given the state of SOAP in > OFBiz this turned out to be too big of an obstacle, at least for me. > > I agree with David that XML/JSON-RPC are attractive options, and I think I'm > going to go that route. But your reply prompts me to make a comment about > the open source world in general: > > Coming from a .NET background (but quickly recovering!), it's very > frustrating for me to have to wade through discussions about specifications > and standards, Java data types vs .NET data types, this protocol is better > than that protocol because it only uses 547 bytes instead of 613 bytes, etc. > etc. etc. Now, I have a master's degree in software engineering, so it's not > that I don't understand that stuff. It's just that I shouldn't have to. > > When I write a .NET program to make SOAP calls to Salesforce, it just works. > I don't even have to worry about what version of SOAP I'm using (or they're > using). I have no idea what kind of web servers, database, programming > language, or operating system Salesforce is using. And I don't care, because > everything just works. > > My point is this: If you want to improve adoption of any open source > platform or technology, it wouldn't hurt to shorten the list of things that > newcomers (like me) need to figure out. If I have to drill down through 17 > layers of libraries, protocols, specifications, etc., then eventually my > brain is going to overflow and I'll just go work on something else where I > can make just as much money with fewer headaches (and fewer things that > might break for my clients). In the case of OFBiz, which I think is very > cool, when I get to the word "SOAP" that should be the end. I should be able > to say "OK, that's just SOAP. I get it. Now I'll go learn how to build a UI > or something." I guess I'm really talking about a change in attitude, where > it's not assumed that the application developer needs to understand every > line of code right down to the kernel. > > Sorry, I didn't mean to turn this into a rant. But please take it in the > spirit in which it's intended: An idea that might help improve adoption of > OFBiz. I would certainly like to help contribute to that effort myself, if I > could just get 6 months of income in the bank :-) > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Any-SOAP-success-stories-tp3620409p3623964.html > Sent from the OFBiz - User mailing list archive at Nabble.com.
