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.
