There will be an ESB, probably ServiceMix in our enterprise architecture. That will be used to communicate with backend applications like Oracle Financials, a warehouse system, etc.
We are using OFBiz and a couple of other applications that handle e-commerce, then PHP at the web tier for presentation. Each of our ecommerce applications must be accessible via restful web services. Each has their own way of doing it, for example one of the apps is .NET. We have prototyped Axis with OFBiz. I would be fine with using the service engine directly, but from everything I have read in the documentation and ML there are limitations. And since Axis was a documented alternative that is the approach we took. So the architecture is like this: Web - PHP E-Commerce - OFBiz, .NET, Endeca, a few other custom apps. Backend - Oracle, warehouse system, retail system, etc. We are using lighter weight web service technologies between PHP and the e-commerce apps. With OFBiz we need to do more than pass around documents. We will be conducting transactions. For example the web tier will call OFBiz to create a shopping cart and take a customer through checkout, see order history, manage profile, etc. So I question the statement that " all you really need is already in OFBiz." ----- Original Message ----- From: "Jacques Le Roux" <[email protected]> To: [email protected] Sent: Wednesday, March 11, 2009 2:51:35 AM (GMT-0600) America/Chicago Subject: Re: restful web services This is also why I spoke about ESB, particularly ServiceMix (which happends to be an Apache project ;o). But in most cases, as David explained, all you need is already in OFBiz. Notably, but not only, when you need to speak between OFBiz instances. On the other hand if you regularly need to speak with other applications, then, IMO, you should really care about ESBs... A good book I'd recommend http://www.manning.com/rademakers/. There are also a lot of free informations at ServiceMix site... Jacques From: "David E Jones" <[email protected]> > > OAGIS message are just XML files, and can be sent over whatever transport > protocol. The code in OFBiz sends them via HTTPS, which > is the most common form of synchronous transfer. They are written to get > asynchronous responses though, so doing it via a > message broker would work well too. > > In general they are not SOAP, but you could call them REST using the > lame/common meaning of it. Really they are more of the "POX" > style, ie "Plain Old XML". > > This sort of thing makes a lot more business sense, IMO, than something that > tries to do object mapping and such like SOAP is > mostly meant for (and really hard to use without those sorts of tools). In > OFBiz we just make the messages with a template > (using FTL to generate XML, just like we use it to generate HTML), and then > have Java code to consume the XML coming in (though > I'd like to extend simple methods to do that). > > So, there is nothing to build for this... ie the tools are already in place > and examples of them in various places, especially > the oagis component. > > Stepping back a little bit... when you're talking about integration it mostly > depends on the constraints of the other system. If > there are no constraints then I'd recommend focusing on message format > standards (like OAGIS or UBL) instead of transport > protocol and formatting standards like SOAP, REST, etc. You can write stuff > that conforms to those lower level standards all you > want, but significant work will still be required to use those messages with > other systems that use the same technologies > because the data structures, ie message format, are totally different (and > possibly not reconcilable without encumbering and > limiting the business). > > -David > > > On Mar 10, 2009, at 1:40 PM, Vince M. Clark wrote: > >> >> Very helpful, thank you. >> >> As you may have noticed from recent threads we have been working with Axis. >> To date we have only used SOAP. Our client just >> informed us that they want to standardize on REST, which seems easy enough >> to do with Axis. As we started down this path we >> came across the blog post I referenced claiming "How NOT to do RESTful web >> services" which raised some concerns. >> >> Interesting that you mentioned OAGIS, as our client also stated that they >> want to standardize on this for transporting documents >> across systems. So I guess the question is, what is our best path? Continue >> with Axis, or make/fund/wait for changes to the >> OFBiz service engine. Either way I intend to leverage what has already been >> established in the OAGIS component. >> >> ----- Original Message ----- >> From: "David E Jones" <[email protected]> >> To: [email protected] >> Sent: Tuesday, March 10, 2009 2:27:44 PM (GMT-0600) America/Chicago >> Subject: Re: restful web services >> >> >> Yes, the term "REST" and it's cousin "REST-ful" are some of my least >> favorite these days. They were watered down and misinterpreted from >> day 1. The concept of them has been around for years, but people >> started applying it to everything that isn't SOAP, which is just silly. >> >> The thing to keep in mind with REST that most tools ignore is the >> separation of verbs and nouns. The "nouns" are addressable resources >> and verbs are used to interact with the nouns... with various verbs >> mapped to the exist HTTP request type (ie GET, POST, etc). >> >> I like the idea of separation of verbs and nouns (which OAGIS does a >> decent job of, and with a set of nouns that is much more business >> friendly), but most of the REST ideas are rather... limiting. They are >> fine for CrUD types of operations, but not much more given the limited >> set of available verbs. >> >> Still, the theory is somewhat irrelevant since the common usage of the >> term "REST" has been reduced to near meaningless. Sometimes it seems >> that people like to seem fancy, but all too often can live up to the >> fanciness they created for themselves. >> >> Anyway, for OFBiz the main concept from REST and OAGIS that we might >> consider implementing is support in the service engine for a >> separation of verbs and nouns. We have common service naming patterns >> that we use in a de-facto sort of way, like the service >> "createProduct" which has the noun "Product" and the verb "create". It >> would be cool if the service definition supported this sort of 2-part >> naming, and with a way to associate nouns to entities when applicable >> (and of course nouns could be things other than entities, like XML >> schemas or whatever). >> >> I'm not sure that is helpful commentary, but there are some thoughts >> on the issue anyway (which I've been following with agonized >> fascination for a while). >> >> -David >> >> >> On Mar 10, 2009, at 12:41 PM, Vince M. Clark wrote: >> >>> This blog is arguing that Axis2 doesn't do true RESTful web >>> services. I'm interested in thoughts and comments from the community. >>> http://atmanes.blogspot.com/2007/06/how-not-to-do-restful-web-services.html >> >
