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.
