Good musings Vince.
One thing to note: I mentioned that the service engine would TRY to do
automated mapping, that doesn't mean it will succeed. For more complex
attributes going in or out of services it WILL fail. It's not too hard to find
examples of this if you start poking around.
A fifth option: do a looser integration to just use different webapps, have
ofbiz get the content mgr content through http, and do some sort of single sign
on for forums, etc. Still not a great option... Personally I'd just go with #4,
but I do obviously have a bias there. Still, the content stuff and site
management for it have improved a lot over the last year, and we actually use
it quite a bit for clients.
-David
Vince Clark wrote:
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.
