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 <david.jo...@hotwaxmedia.com> 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 >> <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. >>>>>> >>>>>> >>>>> >>>>> >>> > > -- Sent from my mobile device
