best web framework

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

best web framework

Vince Clark
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.
Reply | Threaded
Open this post in threaded view
|

Re: best web framework

Cimballi-2
Hi,

We are currently implementing a solution using OFBiz as the back-end, Struts
on the front-end, and RMI for communication between both. We choose RMI for
2 reasons : full java (no XML) and really good performance (a call is
something like 50-100 ms). One thing you have to take care about is that
with RMI, you cannot use OFBiz entities on the front-end so you have to
write a proxy that transform OFBiz entities to front-end objects. Nothing
complicated nevertheless.

We made a prototype and it was ok, we are now implementing the real site.
Once finished I will try to give you more feedback.

HTH,

Cimballi


On Wed, Apr 15, 2009 at 12:14 PM, Vince Clark <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: best web framework

David E Jones-3
In reply to this post by Vince Clark

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.

Reply | Threaded
Open this post in threaded view
|

Re: best web framework

Vince Clark
In reply to this post by Vince Clark
Thanks for the voice of reason David.

When you say "turn off" the other webapps, what do you mean? Is it as simple as taking them out of the ofbiz-component.xml files?

Also, I would still need to set different prefixes in entityengine.xml, correct?

----- Original Message -----
From: "David E Jones" <[hidden email]>
To: [hidden email]
Sent: Wednesday, April 15, 2009 12:57:04 PM GMT -07:00 US/Canada Mountain
Subject: Re: best web framework


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.

Reply | Threaded
Open this post in threaded view
|

Re: best web framework

Cimballi-2
In reply to this post by David E Jones-3
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
<[hidden email]>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.
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: best web framework

David E Jones-3
In reply to this post by Vince Clark

On Apr 15, 2009, at 1:09 PM, Vince Clark wrote:

> Thanks for the voice of reason David.
>
> When you say "turn off" the other webapps, what do you mean? Is it  
> as simple as taking them out of the ofbiz-component.xml files?

Yes, basically just comment out the webapp elements in the ofbiz-
component.xml files (if you're deploying in the OOTB container, if in  
another app server just don't setup the webapps there). This is  
probably best done with a patch the is run only on the ecommerce server.

> Also, I would still need to set different prefixes in  
> entityengine.xml, correct?

You shouldn't need to do this. They are using the same database so  
they'll be sharing the sequencing table and they won't need a special  
prefix. Basically this scenario is just like having multiple app  
servers in general all sharing the same database. It doesn't really  
matter which webapps are deployed on each server.

Doing a different prefix per system is mainly for systems where you  
have different databases that are synchronized over time and therefore  
have different sequencing tables.

-David


> ----- Original Message -----
> From: "David E Jones" <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, April 15, 2009 12:57:04 PM GMT -07:00 US/Canada  
> Mountain
> Subject: Re: best web framework
>
>
> 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: best web framework

David E Jones-3
In reply to this post by Cimballi-2

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

Reply | Threaded
Open this post in threaded view
|

Re: best web framework

Cimballi-2
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
<[hidden email]>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
>> <[hidden email]>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.
>>>>
>>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: best web framework

David E Jones-3

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

Reply | Threaded
Open this post in threaded view
|

Re: best web framework

Brett
Another alternative to RMI is JSON.

We use the JSON library that comes with ofbiz to make ofbiz service
calls.  The library converts the results from the service to a json
string.  This can be easily parsed by an AJax client or java client.

Rmi is ok but a little heavy for our needs.  There were also
serialization problems when using eclipse for debugging and ant for
builds.


Brett

On 4/15/09, David E Jones <[hidden email]> wrote:

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

--
Sent from my mobile device
Reply | Threaded
Open this post in threaded view
|

Re: best web framework

Shi Jinghai
In reply to this post by Cimballi-2
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
> <[hidden email]>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.
> >>
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: best web framework

porkiey
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" <[hidden email]> 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
> <[hidden email]>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.
> >>
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: best web framework

BJ Freeman
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" <[hidden email]> 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
>> <[hidden email]>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.
>>>>
>>>