Random musings that I would appreciate confirmation or clarification on to close the loop on my understanding of this topic.
Services can be called from either SOAP or XML-RPC clients, and the OfBiz service engine will consume the request and respond with the properly formatted output. This would be a simple XML formatted response to an XML-RPC request, and for SOAP a wrapper with content inside based on the WSDL. This will provide web services access to any service defined with export="true", but realistically it will be necessary to create wrapper services to get more sophisticated functionality such as calling multiple services in a single request. This would probably include most existing eCommerce functionality as it depends heavily on bsh scripts that are not defined as services. So for example if I wanted to integrate with a CMS and have similar functionality to OOTB OfBiz eCommerce, I would have three options: 1) Write wrapper services that replicate current eCommerce functionality (searches, storing items in shopping cart, shopping lists, checkout, etc.) 2) Call existing services from SOAP or XMLRPC client and handle details on the other end (looping thru categories, grouping products, etc.) This could result in too much data being returned and may not be a good option, and would still depend on option 1 to maintain shopping cart and checkout. 3) Forget the whole integration craziness and just "embed" the OfBiz webstore in a CMS template. This seems like a much easier option as I haven't even begun to ask about how sessions would be tracked for shopping carts, checkout, etc., or user management between the two systems. 4) Forget an external CMS, and make the most of OfBiz CMS functionality so as to avoid this whole topic altogether. One very important point this research exposed for me that I really need clarification on. BSH scripts are not typically defined as services. I only found one example of a service defined with engine="bsh". It is in the common component and is in services_test.xml. Conceptually I understand why. Much of the functionality implemented in bsh is to support rendering of the UI such as storing/retrieving values from the context and performing searches. Is it correct to say that most of these bsh scripts fall into the UI category as opposed to business logic, and therefore do not qualify as a "service"? David E Jones wrote: > > Actually I think at the minute that the XMLRPC automatic service > mapping in OFBiz is better than the SOAP auto-mapping. > > The service engine will try for any service definition, but just be > aware that the real world is not as simple as this. If you have to > implement to a spec that you don't control you probably won't be able > to use the automated mapping and you'll have to write wrapper services. > > -David > > > Vince Clark wrote: >> I am researching this topic and need some clarification on integration >> options. >> >> As far as I can tell we can use either SOAP or XML-RPC. My understanding >> of web services is limited, but as I understand it any service in OfBiz >> defined as "export=true" can be consumed as a web service via SOAP. If >> this is true then it leads me to believe that there is much more >> functionality available to the consuming application, a CMS for example, >> using SOAP as opposed to XML-RPC. >> >> There is a component available from OpenTaps called livecatalog that has >> some classes available for use with XML-RPC integration. Although upon >> reviewing that code I cannot see anything specific to XML-RPC. Is the >> purpose of this component to make some information more easily >> accesssible, or is it targeted at XML-RPC integrations? >> >> This also leads me to the question, can any exported OfBiz service be >> consumed with either SOAP or XML-RPC? Am I comparing apples to apples? >> >> Finally, the CMS we want to integrate is Joomla. Which should we use, >> SOAP or XML-RPC? The latter seems to be better supported in Joomla, but >> if my understanding of OfBiz services is correct, we will have much more >> functionality available to us if we use SOAP. -- Vince Clark Global Era The freedom of open source. (303) 493-6723 (303) 455-2409 fax [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www.globalera.com
