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" <[email protected]> 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 > <[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. > >> > > > >
