Advice needed: Integrating an External Webapp with OfBiz Order Application service layer via RMI...

[DeAngelo Lampkin]

Hello all!

I'll get right to it.

Scenario:
1) I have a pre-built, no-ofbiz webapp built using a separate MVC framework
(Spring, struts, etc)
2)  This app needs an ecommerce solutio.  So in this non-ofbiz webapp, a
user can add a bunch of items to a shopping cart , and click "buy" and have
ofbiz handle the rest.  Now, the products may be added to OFBiz using one of
the out-of-the-box applications,  but the user should browse the product
catalog and buy shopping cart items from the external webapp.

Ideal solution:
1) Expose ofbiz's out-of-box order processing application via
RMI/SOAP/some-other-remoting-technology .  Essentially I want to staple
ofbiz's shopping cart and order processing parts onto the side of this other
application. Another user described a similiar scenario in another post:
http://www.nabble.com/using-ofbiz-as-an-authentication-store-for-a-webapp--to15424697.html#a15442073.

I've semi-disqualified SOAP at this point.  Since OfBiz integrates with Axis
at an API level, this would require me to go in and modify a number of OfBiz
classes so that they emit proper XML (for WSDLs and whatnot) since only
simple types are support out of box  Feels like a less that optimal
approach.

So now, I'm looking into RMI, but I want to make sure I'm doing  things in a
way that makes sense and that lines up with any current de facto Best
Practices.

Right now, I'm thinking of:
 (a) going into the services xml files under the "order" application and
 (b) then exposing order and shopping cart services by setting
"export=true".

Is this approach workable?  Anyone have any experience or sample code for
doing this?

Another theorhetical approach would be to essentially include all the ofbiz
jar files inside my WEB-INF/lib directory and then just import the necessary
ofbiz classes into my webapp classes.  Now I know this *specific* approach
is not compatible with OFBiz since OFBiz expects a certain directory
structure, but I was wondering if the *concept* of "embedding" ofbiz
application in a "standard" webapp in some manner is (a) possible and (b)
exactly how should one approach it?

Thanks for any help you can provide!
-DeAngelo Lampkin

[David Legg]

Hi DeAngelo,

I'm a 'me-too' on this subject.

It's only in the last week I got round to trying out OfBiz.  After the
initial Wow! factor died down I quickly realized that the storefront
looks almost hard-wired to the back-end.  In the short time I've been
subscribed to the list I've seen several similar requests for advice on
how to cleanly separate the store front from the backend with no
apparent solution so far.

> 2)  This app needs an ecommerce solutio.  So in this non-ofbiz webapp, a
> user can add a bunch of items to a shopping cart , and click "buy" and have
> ofbiz handle the rest.  Now, the products may be added to OFBiz using one of
> the out-of-the-box applications,  but the user should browse the product
> catalog and buy shopping cart items from the external webapp

Regards,
David Legg

[rajsaini]

Hi David,

I had the exactly same feeling you have now when I started looking at
the OFBiz as e-commerce solution. Immediate thought that came to me why
not to have my own store front in the technology of I like for example a
JSP, struts etc etc. Looking deep into the system I found it was a
unwarranted thought and current framework (widgets, screens, freemarker
etc.) are no less than other frameworks.

Going back to your question, what exactly you mean by clearly separate
store front? To me it looks clearly separate as you can create your own
web application and have your e-commerce store front as you want without
keeping any thing from the default technologies.

If you are looking for network level communication, I think RMI is the
way to go if both of the applications are Java based. Recently, I had
integrated OFBiz with a Liferay Portal where store front was written as
a set of portlets.

Thanks,

Raj

David Legg wrote:

> Hi DeAngelo,
>
> I'm a 'me-too' on this subject.
>
> It's only in the last week I got round to trying out OfBiz.  After the
> initial Wow! factor died down I quickly realized that the storefront
> looks almost hard-wired to the back-end.  In the short time I've been
> subscribed to the list I've seen several similar requests for advice
> on how to cleanly separate the store front from the backend with no
> apparent solution so far.
>
>> 2)  This app needs an ecommerce solutio.  So in this non-ofbiz webapp, a
>> user can add a bunch of items to a shopping cart , and click "buy"
>> and have
>> ofbiz handle the rest.  Now, the products may be added to OFBiz using
>> one of
>> the out-of-the-box applications,  but the user should browse the product
>> catalog and buy shopping cart items from the external webapp
>
> Regards,
> David Legg
>
>

[David Legg]

Hi Raj,

> ...what exactly you mean by clearly separate store front? To me it
> looks clearly separate as you can create your own web application and
> have your e-commerce store front as you want without keeping any thing
> from the default technologies.

I don't wish to hijack DeAngelo's thread but... like him, I have my own
preferred web framework (Cocoon) into which I would like to bolt on an
estore.  However, I'd rather not end up with a Frankenstein monster with
a big bolt holding it all together!  I'm taking great pains to ensure
that the look and feel of the site is managed in one place.  If I bolt
OfBiz on the side I will have to keep two sets of templates in sync with
each other.

To me the ideal solution would be to have a library of POJOs that
implement a storefront and a shopping basket API and use spring
configuration to establish settings like where the database is.  Then I
could incorporate those beans in a JSP page or a Cocoon pipeline or a
Struts app as appropriate.  I think it is the distributed nature of the
configuration which is a stumbling block at the moment.

Of course all those things may exist already and I haven't spotted them...
Maybe I should take a closer look at the GenericDelegator class which I
see is used a lot in things like
org.ofbiz.order.shoppingcart.ShoppingCart.java


Regards,
David Legg

[Peter Sparkes]

Hi,

I too - have my own preferred web framework (Cocoon) into which I would
like to bolt on an estore.

Regards

Peter Sparkes

> Hi Raj,
>
>> ...what exactly you mean by clearly separate store front? To me it
>> looks clearly separate as you can create your own web application and
>> have your e-commerce store front as you want without keeping any
>> thing from the default technologies.
>
> I don't wish to hijack DeAngelo's thread but... like him, I have my
> own preferred web framework (Cocoon) into which I would like to bolt
> on an estore.  However, I'd rather not end up with a Frankenstein
> monster with a big bolt holding it all together!  I'm taking great
> pains to ensure that the look and feel of the site is managed in one
> place.  If I bolt OfBiz on the side I will have to keep two sets of
> templates in sync with each other.
>
> To me the ideal solution would be to have a library of POJOs that
> implement a storefront and a shopping basket API and use spring
> configuration to establish settings like where the database is.  Then
> I could incorporate those beans in a JSP page or a Cocoon pipeline or
> a Struts app as appropriate.  I think it is the distributed nature of
> the configuration which is a stumbling block at the moment.
>
> Of course all those things may exist already and I haven't spotted
> them...
> Maybe I should take a closer look at the GenericDelegator class which
> I see is used a lot in things like
> org.ofbiz.order.shoppingcart.ShoppingCart.java
>
>
> Regards,
> David Legg
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.100 / Virus Database: 270.8.1/1727 - Release Date: 15/10/2008 20:02
>  

[rajsaini]

David Legg wrote:

> Hi Raj,
>
>> ...what exactly you mean by clearly separate store front? To me it
>> looks clearly separate as you can create your own web application and
>> have your e-commerce store front as you want without keeping any
>> thing from the default technologies.
>
> I don't wish to hijack DeAngelo's thread but... like him, I have my
> own preferred web framework (Cocoon) into which I would like to bolt
> on an estore.  However, I'd rather not end up with a Frankenstein
> monster with a big bolt holding it all together!  I'm taking great
> pains to ensure that the look and feel of the site is managed in one
> place.  If I bolt OfBiz on the side I will have to keep two sets of
> templates in sync with each other.
>
> To me the ideal solution would be to have a library of POJOs that
> implement a storefront and a shopping basket API and use spring
> configuration to establish settings like where the database is.  Then
> I could incorporate those beans in a JSP page or a Cocoon pipeline or
> a Struts app as appropriate.  I think it is the distributed nature of
> the configuration which is a stumbling block at the moment.

If you want to run your application within the OFBiz container , you can
have a look at various event handlers configured in the e-commerce
controller.xml. There are event handlers for Java, SOAP etc. Thought I
have not tried, you can write your own event handler to handle the
Cocoon request pipeline. However, please note that this will need you to
write all the logic you find out of the box in the ecommerce component.

If your application runs in another container/server and it is Java, RMI
is the way to go. You can still use the service framework and reuse most
of the services of OFBiz. My suggestion is to create facade RMI services
instead of modifying the exiting one.

Thanks,

Raj

[David Legg]

Hi Raj,

> If your application runs in another container/server and it is Java,
> RMI is the way to go.

I'll have a look... thanks.

David Legg.

[Adrian Crum]

David Legg wrote:
> To me the ideal solution would be to have a library of POJOs that
> implement a storefront and a shopping basket API and use spring
> configuration to establish settings like where the database is.  Then I
> could incorporate those beans in a JSP page or a Cocoon pipeline or a
> Struts app as appropriate.  I think it is the distributed nature of the
> configuration which is a stumbling block at the moment.

I think your view on this subject may change after spending some time
with OFBiz. Not everyone will agree that the solution you describe is ideal.

Cobbling together a bunch of libraries might seem like a cool idea, but
it will take a lot more work to set up and maintain. The OFBiz framework
is designed to get you up and running quickly.

I've been working with OFBiz for four years, and I shudder to think of
using POJOs, beans, or (yuck) JSPs to build a website. The combination
of OFBiz screen widgets, Groovy scripts, FreeMarker templates, and the
OFBiz mini-language is far easier to use.

-Adrian

[DeAngelo Lampkin]

On Thu, Oct 16, 2008 at 4:26 AM, David Legg <[hidden email]>wrote:

> Hi Raj,
>
>  ...what exactly you mean by clearly separate store front? To me it looks
>> clearly separate as you can create your own web application and have your
>> e-commerce store front as you want without keeping any thing from the
>> default technologies.
>>
>
> I don't wish to hijack DeAngelo's thread but...


By all means, hijack away!  The more conversation the better.

-DeAngelo

[BJ Freeman]

The concept is that ofbiz is the backend and the store front(ecommerce)
is just an application that uses the framework.
Ofbiz is not Ecommerce, though it has an application that supports
Ecommerce.
So yes the Ecommerce depends on the backend.
there are RMI examples in ofbiz that if one spent the time could come up
with an RMI connector so another Web App or even an other cart could
access the Backend.
ofbiz was designed so the back end could have other application layered
on it.
However theres is not active participation, at this, time to have such
connectors done.



David Legg sent the following on 10/16/2008 2:28 AM:

> Hi DeAngelo,
>
> I'm a 'me-too' on this subject.
>
> It's only in the last week I got round to trying out OfBiz.  After the
> initial Wow! factor died down I quickly realized that the storefront
> looks almost hard-wired to the back-end.  In the short time I've been
> subscribed to the list I've seen several similar requests for advice on
> how to cleanly separate the store front from the backend with no
> apparent solution so far.
>
>> 2)  This app needs an ecommerce solutio.  So in this non-ofbiz webapp, a
>> user can add a bunch of items to a shopping cart , and click "buy" and
>> have
>> ofbiz handle the rest.  Now, the products may be added to OFBiz using
>> one of
>> the out-of-the-box applications,  but the user should browse the product
>> catalog and buy shopping cart items from the external webapp
>
> Regards,
> David Legg
>
>
>
>

[Vince Clark]

Raj - I would love to know more about the Liferay integration. Also would you be willing to share a URL so we can see how it looks?


----- Original Message -----
From: "Raj Saini" <[hidden email]>
To: [hidden email]
Sent: Thursday, October 16, 2008 4:13:27 AM (GMT-0700) America/Denver
Subject: Re: Advice needed: Integrating an External Webapp with OfBiz Order Application service layer via RMI...

Hi David,

I had the exactly same feeling you have now when I started looking at
the OFBiz as e-commerce solution. Immediate thought that came to me why
not to have my own store front in the technology of I like for example a
JSP, struts etc etc. Looking deep into the system I found it was a
unwarranted thought and current framework (widgets, screens, freemarker
etc.) are no less than other frameworks.

Going back to your question, what exactly you mean by clearly separate
store front? To me it looks clearly separate as you can create your own
web application and have your e-commerce store front as you want without
keeping any thing from the default technologies.

If you are looking for network level communication, I think RMI is the
way to go if both of the applications are Java based. Recently, I had
integrated OFBiz with a Liferay Portal where store front was written as
a set of portlets.

Thanks,

Raj

David Legg wrote:

> Hi DeAngelo,
>
> I'm a 'me-too' on this subject.
>
> It's only in the last week I got round to trying out OfBiz. After the
> initial Wow! factor died down I quickly realized that the storefront
> looks almost hard-wired to the back-end. In the short time I've been
> subscribed to the list I've seen several similar requests for advice
> on how to cleanly separate the store front from the backend with no
> apparent solution so far.
>
>> 2) This app needs an ecommerce solutio. So in this non-ofbiz webapp, a
>> user can add a bunch of items to a shopping cart , and click "buy"
>> and have
>> ofbiz handle the rest. Now, the products may be added to OFBiz using
>> one of
>> the out-of-the-box applications, but the user should browse the product
>> catalog and buy shopping cart items from the external webapp
>
> Regards,
> David Legg
>
>

[rajsaini]

Vince,

This application is not yet in production. However, I can share the test
system URL with you privately.

Thanks

Raj

Vince M. Clark wrote:

> Raj - I would love to know more about the Liferay integration. Also would you be willing to share a URL so we can see how it looks?
>
>
> ----- Original Message -----
> From: "Raj Saini" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, October 16, 2008 4:13:27 AM (GMT-0700) America/Denver
> Subject: Re: Advice needed: Integrating an External Webapp with OfBiz Order Application service layer via RMI...
>
> Hi David,
>
> I had the exactly same feeling you have now when I started looking at
> the OFBiz as e-commerce solution. Immediate thought that came to me why
> not to have my own store front in the technology of I like for example a
> JSP, struts etc etc. Looking deep into the system I found it was a
> unwarranted thought and current framework (widgets, screens, freemarker
> etc.) are no less than other frameworks.
>
> Going back to your question, what exactly you mean by clearly separate
> store front? To me it looks clearly separate as you can create your own
> web application and have your e-commerce store front as you want without
> keeping any thing from the default technologies.
>
> If you are looking for network level communication, I think RMI is the
> way to go if both of the applications are Java based. Recently, I had
> integrated OFBiz with a Liferay Portal where store front was written as
> a set of portlets.
>
> Thanks,
>
> Raj
>
> David Legg wrote:
>  
>> Hi DeAngelo,
>>
>> I'm a 'me-too' on this subject.
>>
>> It's only in the last week I got round to trying out OfBiz. After the
>> initial Wow! factor died down I quickly realized that the storefront
>> looks almost hard-wired to the back-end. In the short time I've been
>> subscribed to the list I've seen several similar requests for advice
>> on how to cleanly separate the store front from the backend with no
>> apparent solution so far.
>>
>>    
>>> 2) This app needs an ecommerce solutio. So in this non-ofbiz webapp, a
>>> user can add a bunch of items to a shopping cart , and click "buy"
>>> and have
>>> ofbiz handle the rest. Now, the products may be added to OFBiz using
>>> one of
>>> the out-of-the-box applications, but the user should browse the product
>>> catalog and buy shopping cart items from the external webapp
>>>      
>> Regards,
>> David Legg
>>
>>
>>    
>
>
>  

[Vince Clark]

I would appreciate that very much. Please send to my email address.

Thanks!

----- Original Message -----
From: "Raj Saini" <[hidden email]>
To: [hidden email]
Sent: Thursday, October 16, 2008 11:41:49 AM (GMT-0700) America/Denver
Subject: Re: Advice needed: Integrating an External Webapp with OfBiz Order Application service layer via RMI...

Vince,

This application is not yet in production. However, I can share the test
system URL with you privately.

Thanks

Raj

Vince M. Clark wrote:

> Raj - I would love to know more about the Liferay integration. Also would you be willing to share a URL so we can see how it looks?
>
>
> ----- Original Message -----
> From: "Raj Saini" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, October 16, 2008 4:13:27 AM (GMT-0700) America/Denver
> Subject: Re: Advice needed: Integrating an External Webapp with OfBiz Order Application service layer via RMI...
>
> Hi David,
>
> I had the exactly same feeling you have now when I started looking at
> the OFBiz as e-commerce solution. Immediate thought that came to me why
> not to have my own store front in the technology of I like for example a
> JSP, struts etc etc. Looking deep into the system I found it was a
> unwarranted thought and current framework (widgets, screens, freemarker
> etc.) are no less than other frameworks.
>
> Going back to your question, what exactly you mean by clearly separate
> store front? To me it looks clearly separate as you can create your own
> web application and have your e-commerce store front as you want without
> keeping any thing from the default technologies.
>
> If you are looking for network level communication, I think RMI is the
> way to go if both of the applications are Java based. Recently, I had
> integrated OFBiz with a Liferay Portal where store front was written as
> a set of portlets.
>
> Thanks,
>
> Raj
>
> David Legg wrote:
>
>> Hi DeAngelo,
>>
>> I'm a 'me-too' on this subject.
>>
>> It's only in the last week I got round to trying out OfBiz. After the
>> initial Wow! factor died down I quickly realized that the storefront
>> looks almost hard-wired to the back-end. In the short time I've been
>> subscribed to the list I've seen several similar requests for advice
>> on how to cleanly separate the store front from the backend with no
>> apparent solution so far.
>>
>>
>>> 2) This app needs an ecommerce solutio. So in this non-ofbiz webapp, a
>>> user can add a bunch of items to a shopping cart , and click "buy"
>>> and have
>>> ofbiz handle the rest. Now, the products may be added to OFBiz using
>>> one of
>>> the out-of-the-box applications, but the user should browse the product
>>> catalog and buy shopping cart items from the external webapp
>>>
>> Regards,
>> David Legg
>>
>>
>>
>
>
>

[David Legg]

Hi BJ,

> there are RMI examples in ofbiz that if one spent the time could come up
> with an RMI connector so another Web App or even an other cart could
> access the Backend.
>  

That sounds promising.  I'll take a closer look.  I think I can see what
you are talking about in svn.

Some people have sounded surprised that people would even consider not
using the built-in ecommerce web app.  Whilst I think the OfBiz
framework is very elegant you can't expect everyone to drop their
existing frameworks just to display a product list and a shopping basket!

> ofbiz was designed so the back end could have other application layered
> on it.
> However theres is not active participation, at this, time to have such
> connectors done.
>  

I fully understand.

The idea of using RMI to connect a storefront with OfBiz is no different
to sites which get their content from remote CMS repositories.

Regards,
David Legg

[Adrian Crum]

David Legg wrote:
> Some people have sounded surprised that people would even consider not
> using the built-in ecommerce web app.  Whilst I think the OfBiz
> framework is very elegant you can't expect everyone to drop their
> existing frameworks just to display a product list and a shopping basket!

I think you're mis-interpreting what was said. Raj said you can create
your own eCommerce web application if you don't like the default.

As far as I know, very few people use the eCommerce application as-is in
production. Most developers use the existing eCommerce application as a
*guide* to design their own.

As far as dropping existing frameworks is concerned, some have found it
easier to drop their existing framework and port their data over to
OFBiz, rather than kludge together OFBiz with some other framework.

-Adrian

[BJ Freeman]

David Legg sent the following on 10/16/2008 4:21 PM:
> Hi BJ,
> Some people have sounded surprised that people would even consider not
> using the built-in ecommerce web app.  Whilst I think the OfBiz
> framework is very elegant you can't expect everyone to drop their
> existing frameworks just to display a product list and a shopping basket!

yes, considering the ecommerce portion is just a shell without the backend.


I don't see what you will get by trying to use the ecommerce apps with
another  backend, unless that backend supplies the necessary support
that the ofbiz backend does.

In that case it would be less effort then to use the ecommerce as a
model but do the coding in same model as the backend you are working with.
IMHO
:D

[BJ Freeman]

let me expand on that.
Backend:
catalog is used to display the products.
content is used to display forums and blogs.
Promos is generated by the catalog to be diplayed.
reviews are from the content application.
configurable products use the catalog and manufacturing.
Cart is in the order application.
Login ability and info about the customer is in the Party application.
the login code is in the framework.
So you see there is not much in the ecommerce but a shell to display all
this info from other applications and the framework.


BJ Freeman sent the following on 10/16/2008 5:03 PM:

>
> David Legg sent the following on 10/16/2008 4:21 PM:
>> Hi BJ,
>> Some people have sounded surprised that people would even consider not
>> using the built-in ecommerce web app.  Whilst I think the OfBiz
>> framework is very elegant you can't expect everyone to drop their
>> existing frameworks just to display a product list and a shopping basket!
>
> yes, considering the ecommerce portion is just a shell without the backend.
>
>
> I don't see what you will get by trying to use the ecommerce apps with
> another  backend, unless that backend supplies the necessary support
> that the ofbiz backend does.
>
> In that case it would be less effort then to use the ecommerce as a
> model but do the coding in same model as the backend you are working with.
> IMHO
> :D
>
>

[David Legg]

Hi BJ,

> let me expand on that.
>  

Thanks for explaining the OfBiz structure in more detail.

> So you see there is not much in the ecommerce but a shell to display all
> this info from other applications and the framework.
>
>  
>> I don't see what you will get by trying to use the ecommerce apps with
>> another  backend, unless that backend supplies the necessary support
>> that the ofbiz backend does

I think I lost you somewhere.  Far from wanting to drop OfBiz backend
and use the ecommerce app on its own, I (and I guess also DeAngelo and
Peter) want to do the opposite.  We want to embrace OfBiz but we want
the final view to be generated by our own frameworks and not the
ecommerce app.

Actually, I'd like to use a single OfBiz installation as the backend to
two web sites with a common set of products but slightly different
catalogues (English spelling... sorry ;-) ).

Thanks for your help.  I'll do some more exploring now.


Regards,
David Legg

[rajsaini]

> Actually, I'd like to use a single OfBiz installation as the backend
> to two web sites with a common set of products but slightly different
> catalogues (English spelling... sorry ;-) ).
It should be possible to achieve this even with the inbuilt e-commerce
application. You can create as many as site you want. You can share the
same catalog in multiple sites or separate catalog for each site. Or you
can use same set of products or different product in each catalog. Each
catalog can have same set of categories or or different categories.

Thanks,

Raj

>
> Thanks for your help.  I'll do some more exploring now.
>
>
> Regards,
> David Legg
>
>

[BJ Freeman]

Ok terminology.
ofbiz Framework is the components under the framework folder.
Application are under the Application folder.


Unless you bringing more functionality to ofbiz by your code, you might
consider using the ecommerce, since you can have many, from one ofbiz if
it is the company that runs them.

and if you have some presentation different than the handlers in ofbiz
now, then you can look at creating a handler for you presentation layer.

But what could be simpler than just making some CSS changes to have the
 ecommerce side look like anything you want.

you can also implement your presentation on the httpd, PHP, and use a
connector (ajp) between the httpd and ofbiz.



David Legg sent the following on 10/17/2008 2:07 AM:

> Hi BJ,
>
>> let me expand on that.
>>  
>
> Thanks for explaining the OfBiz structure in more detail.
>
>> So you see there is not much in the ecommerce but a shell to display all
>> this info from other applications and the framework.
>>
>>  
>>> I don't see what you will get by trying to use the ecommerce apps with
>>> another  backend, unless that backend supplies the necessary support
>>> that the ofbiz backend does
>
> I think I lost you somewhere.  Far from wanting to drop OfBiz backend
> and use the ecommerce app on its own, I (and I guess also DeAngelo and
> Peter) want to do the opposite.  We want to embrace OfBiz but we want
> the final view to be generated by our own frameworks and not the
> ecommerce app.
>
> Actually, I'd like to use a single OfBiz installation as the backend to
> two web sites with a common set of products but slightly different
> catalogues (English spelling... sorry ;-) ).
>
> Thanks for your help.  I'll do some more exploring now.
>
>
> Regards,
> David Legg
>
>
>