If you can share your experiences with that it would be great!
Whatever the case, I hope your use of OFBiz is working well for you,
and feedback (or contribution... ;) ) of things to improve in the
project to make how you are using it easier is always welcome.
-David
On Apr 15, 2009, at 1:44 PM, Cimballi wrote:
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
<david.jo...@hotwaxmedia.com>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
<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.
