Ok, thanks for your comments. As I said before, here we are developing a site this way (using RMI), so when it will be ready, I will post a feedback on the list.
Cimballi On Wed, Apr 15, 2009 at 2:32 PM, David E Jones <[email protected]>wrote: > > That sounds like a different scenario. Naturally if you change the > requirements the solution should be different! > > In that case you'd have the front-end running on the client talking to the > ecommerce webapp server, which would probably be best just talking to the > database. > > That's different from have the main HTML generation using mostly OOTB stuff > talking via RMI to yet another app server that then talks to the database. > > On a side note, I'd recommend being careful introducing too many > technologies! From experience people often don't know them as well as they > say thy do and that's the main reason for choosing them. The net result is > that you can't reuse existing artifacts and have to write lots more from > scratch, and in addition you'll still have some UI using the standard OFBiz > tools and it means people maintaining it going forward will have to know or > learn about a larger set of tools. > > -David > > > > On Apr 15, 2009, at 1:20 PM, Cimballi wrote: > > 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. >>>> >>>> >>> >>> >
