Hi David ! I would not be so "stubborn" and there can be several reasons why to not use OFBiz on the client side.
Imagine you want to provide a "web2.0" flashy site to the customer, and you have a killer PHP or JSP developer in your team who can do all the UI stuff. Then, it can be interesting to let him doing his job and then call OFBiz services via RMI or WS. I would not ask to the UI developer to learn OFBiz way to develop UIs, and, even more, OFBiz offers the possibility to call its services remotly. In a project, there are technical reasons, business reasons, and human reasons. The best solution is the best mix of these 3. Don't you think it can be a good alternative ? Cimballi On Wed, Apr 15, 2009 at 1:57 PM, David E Jones <[email protected]>wrote: > > Depending on what the more specific requirements are the usual (and by FAR > the easiest) way to do this is to use the same software on the ecommerce and > back-end servers, but have configuration differences so that only the > ecommerce webapp is available on ecommerce sever (ie turn off the other > webapps), and only the non-ecommerce applications are enabled on the > back-end servers (unless you want to use them for ecommerce staging as well, > then you can certainly leave that on, but that server is generally ONLY > accessible internally of course). > > In this scenario all app servers are communicating with the database server > and coordinate that way. There is no need for communication between the > servers except for the Entity Engine distributed cache clearing. > > If you use a pattern of a webapp server that talks to an app server that > talks to a database you have an extra level of remote communications and > that will significantly slow down your response times... as well as add the > need for LOTS of coding! There is only one reason I know of for doing such > things: a very stubborn person with his hands on the purse strings. That's > it, there is NO good technical or business reason for such things. Some > claim greater scalability, but real-world testing proves otherwise. > > -David > > > > On Apr 15, 2009, at 11:14 AM, Vince Clark wrote: > > Our client has a requirement to deploy their ecommerce storefront on a >> physically separate server from the back office apps. We have been >> experimenting with other frameworks and integrating via web services for >> some time, and this requirement pushes up the urgency. >> >> Options we are considering: >> >> • Use OFBiz MVC framework to build the ecommerce site and deploy it on a >> separate server. Use RMI to communicate between two OFBiz instances. >> • Tapestry - Java based, so maybe RMI is still an option. But not sure >> if that really makes it any easier than using web services. >> • Symfony - we have prototyped this and exposed things like user login >> and shopping cart via web services on the OFBiz side. Have tested this with >> Axis2 and Mule. >> • DJango - Just looking into this. >> >> Our primary motivation for going with Symfony or DJango is to keep the web >> tier as light weight as possible. It would be all about presentation, and >> would consume all functionality from OFBiz. >> >> Looking forward to feedback from the community on this topic. >> > >
