Could be for security reasons, though when a user logs in they are using the backend. hmmmm
Sam Hamilton sent the following on 4/17/2009 5:33 AM: > How much extra capacity does the backend applications take on a server? Is it > really worth while splitting the servers up or would just pooling them all > together would be a better use as that could be more easily be HA’d / load > balanced? > > > On 16/04/2009 08:06, "Shi Jinghai" <sh...@langhua.cn> wrote: > > As you mentioned RMI and WS, I guess you forgot to list your No.1 > reason: security. :) > > Regards, > > Shi Jinghai/Beijing Langhua Ltd. > > > 在 2009-04-15三的 14:20 -0500，Cimballi写道： >> 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 >> <david.jo...@hotwaxmedia.com>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. >>>> >>>
