OFBIZ: the road ahead

[Brian Topping <to...@codehaus.org>]

Hi Pierre,

By your inquiry on the future, do you mean with specific features in the applications or how they work together?

As an architect, I am interested in not just an ability to integrate my application against OFBiz, but allow my application to take part in message orchestration by patching itself into the workflows.  I should like that a stock OFBiz deployment can be customized through open interfaces with now-common enterprise integration patterns instead of requiring a proprietary (if open) means of application customization.  

Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I think the "major moving parts" of that model might provide a good pattern for how the applications could work together in the future.  (In other words, Mule might be preferred, but the applications still remodeled on EIP for open integration).

If the applications integrated this way and were uncoupled into separate Maven projects, the applications would also be usable individually where appropriate.  It would be a challenge to do this, but a new class of user would result, one that could pick and choose applications that they wanted to integrate against their local deployment instead of the current all-or-nothing approach.  

ServiceMix has some rather comprehensive integrations with Maven in this regard which I don't pretend to understand very well, but a team effort might result in a solution that really reinvigorates the ecosystem through a large number of new use cases of existing applications.  For instance, REST style or WS interfaces might open the applications to use by Ruby or PHP developers.  The depth and experience wrapped up in the OFBiz ecosystem is staggering, but it's reach is limited by it's rather monolithic Java-centric deployment.  If opening it up in this way would significantly alter the user base, there would be a lot more opportunities for everyone involved.  

I am not trolling here, so please excuse if what I am writing is naive.  I do not have enough technical chops on the guts of OFBiz to know what toes I am stepping on, just presenting a vision of what I would like to integrate against.  I did investigate OFBiz for an ERP solution I need to deliver in the retail space and found that it would be challenging to use the user interface facilities I found to create the customer UI.  My solution was to avoid the problem by building my web UI in a message-oriented manner, back it by Mule, and push the problem out to the future.  It's not a question for me of whether OFBiz will be there when I need it, but more that I will integrate against the applications with standard EIP.  If OFBiz had an accessible EIP presentation like this, it would be a natural choice to integrate with, both for me, and I suspect many other people in my situation.  The Ode style orchestration is more about the applications working together, which would be gravy on the meal.

$0.02...

Brian

Re: OFBIZ: the road ahead

[Brian Topping <to...@codehaus.org>]

Hi David, thanks for setting me straight here.  

Mule might be a pretty good fit for this kind of integration.  One of the things ServiceMix focuses on is WS, Mule could work with these interfaces.  

What might not be obvious is that Mule could do all the message marshaling to the formats you mentioned and more, like ReST.  Instead of maintaining this code, it might be valuable to export maintenance and upkeep on these interfaces to Mule.  An additional upside is it gives the client a number of additional ways to connect, such as with JMS, also maintained as a part of Mule.

One concern is your observation that "[h]owever, the XML-RPC and JSON ones are pretty good", with emphasis on "pretty good".  I read from that they are not perfect.  

If these are not the mainline interfaces, they are bound to lag or not be accurate.  Mule both provides a external front-end to application APIs, as well as a performant means to access them internally.  By unifying these access points, maintenance and testing efforts are similarly reduced.  The reduction is likely offset by the extra effort to integrate Mule in the first place, but functionality should make the risk in the tradeoff worth it, and at some point, it's all payback.

I'll do more digging about the interfaces that you talked about here.  I clearly didn't understand some of the options available.  

Thanks, Brian

On Jan 27, 2011, at 11:40 AM, David E Jones wrote:

> 
> Brian,
> 
> Have you looked into the integration-oriented features of OFBiz? IMO SOAP is a mess and while there has been a SOAP to OFBiz Service tool for a long time, it has never been very good. However, the XML-RPC and JSON ones are pretty good, and along with general XML message passing (like the OAGIS XML messages in OFBiz) these are used a lot for integration with other systems, and even other types of UIs. The basic idea is that you can call ANY OFBiz service (if it is flagged for external use) through these integration means without having to write any extra code on the server (unless you can't control the service definition and need to build a service to match a certain definition, then obviously you'll need to do some server side coding).
> 
> In addition to those if you are writing anything in Java or that runs on a JVM it is VERY easy to use the Service Engine's remote dispatcher to get an object from JNDI on the OFBiz server and then do service calls, with no extra code on the client or server... just start calling services and passing data in and getting data back.
> 
> Some of your other assertions are not quite correct either. For example, if you want to use another Java web UI technology you can do it in container, even in an OFBiz webapp with other OFBiz stuff, with no problem. Just add it to the web.xml file like you would in any other situation. It's not that big a deal.
> 
> -David
> 
> 
> On Jan 27, 2011, at 2:50 AM, Brian Topping wrote:
> 
>> Hi Pierre,
>> 
>> By your inquiry on the future, do you mean with specific features in the applications or how they work together?
>> 
>> As an architect, I am interested in not just an ability to integrate my application against OFBiz, but allow my application to take part in message orchestration by patching itself into the workflows.  I should like that a stock OFBiz deployment can be customized through open interfaces with now-common enterprise integration patterns instead of requiring a proprietary (if open) means of application customization.  
>> 
>> Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I think the "major moving parts" of that model might provide a good pattern for how the applications could work together in the future.  (In other words, Mule might be preferred, but the applications still remodeled on EIP for open integration).
>> 
>> If the applications integrated this way and were uncoupled into separate Maven projects, the applications would also be usable individually where appropriate.  It would be a challenge to do this, but a new class of user would result, one that could pick and choose applications that they wanted to integrate against their local deployment instead of the current all-or-nothing approach.  
>> 
>> ServiceMix has some rather comprehensive integrations with Maven in this regard which I don't pretend to understand very well, but a team effort might result in a solution that really reinvigorates the ecosystem through a large number of new use cases of existing applications.  For instance, REST style or WS interfaces might open the applications to use by Ruby or PHP developers.  The depth and experience wrapped up in the OFBiz ecosystem is staggering, but it's reach is limited by it's rather monolithic Java-centric deployment.  If opening it up in this way would significantly alter the user base, there would be a lot more opportunities for everyone involved.  
>> 
>> I am not trolling here, so please excuse if what I am writing is naive.  I do not have enough technical chops on the guts of OFBiz to know what toes I am stepping on, just presenting a vision of what I would like to integrate against.  I did investigate OFBiz for an ERP solution I need to deliver in the retail space and found that it would be challenging to use the user interface facilities I found to create the customer UI.  My solution was to avoid the problem by building my web UI in a message-oriented manner, back it by Mule, and push the problem out to the future.  It's not a question for me of whether OFBiz will be there when I need it, but more that I will integrate against the applications with standard EIP.  If OFBiz had an accessible EIP presentation like this, it would be a natural choice to integrate with, both for me, and I suspect many other people in my situation.  The Ode style orchestration is more about the applications working together, which would be gravy on the meal.
>> 
>> $0.02...
>> 
>> Brian
> 
> 

Re: OFBIZ: the road ahead

[David E Jones <de...@me.com>]

Brian,

Have you looked into the integration-oriented features of OFBiz? IMO SOAP is a mess and while there has been a SOAP to OFBiz Service tool for a long time, it has never been very good. However, the XML-RPC and JSON ones are pretty good, and along with general XML message passing (like the OAGIS XML messages in OFBiz) these are used a lot for integration with other systems, and even other types of UIs. The basic idea is that you can call ANY OFBiz service (if it is flagged for external use) through these integration means without having to write any extra code on the server (unless you can't control the service definition and need to build a service to match a certain definition, then obviously you'll need to do some server side coding).

In addition to those if you are writing anything in Java or that runs on a JVM it is VERY easy to use the Service Engine's remote dispatcher to get an object from JNDI on the OFBiz server and then do service calls, with no extra code on the client or server... just start calling services and passing data in and getting data back.

Some of your other assertions are not quite correct either. For example, if you want to use another Java web UI technology you can do it in container, even in an OFBiz webapp with other OFBiz stuff, with no problem. Just add it to the web.xml file like you would in any other situation. It's not that big a deal.

-David


On Jan 27, 2011, at 2:50 AM, Brian Topping wrote:

> Hi Pierre,
> 
> By your inquiry on the future, do you mean with specific features in the applications or how they work together?
> 
> As an architect, I am interested in not just an ability to integrate my application against OFBiz, but allow my application to take part in message orchestration by patching itself into the workflows.  I should like that a stock OFBiz deployment can be customized through open interfaces with now-common enterprise integration patterns instead of requiring a proprietary (if open) means of application customization.  
> 
> Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I think the "major moving parts" of that model might provide a good pattern for how the applications could work together in the future.  (In other words, Mule might be preferred, but the applications still remodeled on EIP for open integration).
> 
> If the applications integrated this way and were uncoupled into separate Maven projects, the applications would also be usable individually where appropriate.  It would be a challenge to do this, but a new class of user would result, one that could pick and choose applications that they wanted to integrate against their local deployment instead of the current all-or-nothing approach.  
> 
> ServiceMix has some rather comprehensive integrations with Maven in this regard which I don't pretend to understand very well, but a team effort might result in a solution that really reinvigorates the ecosystem through a large number of new use cases of existing applications.  For instance, REST style or WS interfaces might open the applications to use by Ruby or PHP developers.  The depth and experience wrapped up in the OFBiz ecosystem is staggering, but it's reach is limited by it's rather monolithic Java-centric deployment.  If opening it up in this way would significantly alter the user base, there would be a lot more opportunities for everyone involved.  
> 
> I am not trolling here, so please excuse if what I am writing is naive.  I do not have enough technical chops on the guts of OFBiz to know what toes I am stepping on, just presenting a vision of what I would like to integrate against.  I did investigate OFBiz for an ERP solution I need to deliver in the retail space and found that it would be challenging to use the user interface facilities I found to create the customer UI.  My solution was to avoid the problem by building my web UI in a message-oriented manner, back it by Mule, and push the problem out to the future.  It's not a question for me of whether OFBiz will be there when I need it, but more that I will integrate against the applications with standard EIP.  If OFBiz had an accessible EIP presentation like this, it would be a natural choice to integrate with, both for me, and I suspect many other people in my situation.  The Ode style orchestration is more about the applications working together, which would be gravy on the meal.
> 
> $0.02...
> 
> Brian

Re: OFBIZ: the road ahead

[Jacques Le Roux <ja...@les7arts.com>]

Brian Topping wrote:
> On Jan 27, 2011, at 7:40 AM, Jacques Le Roux wrote:
>
>> Why Mule rather than ServiceMix? I can't see much diff. between them.
>
> ServiceMix is more strongly based on W3C WS where Mule is more open to different transports.  I felt for my application that Mule
> would be more performant, although I prefer the infrastructure support that ServiceMix provides (OSGi, Maven).

Yes indeed, JBI requires WSDL. Not sure about peformance, though yes Mule has a good reputation from this POV. Is the difference 
worth the rest?

>> For PHP I will soon make a proposition. It's based on Quercus (GPL hence of out OFBiz repo) and sitting on my table for almost 2
>> years now (my bad)
>
> Quercus looks really good and I've considered it in the past for other projects.  It has some notable longstanding issues, but
> they can be worked around.
>
> What I am concerned about by having named only two (Ruby, PHP) is that I left out dozens of other technologies.  Quercus only
> solves one (PHP).  What I am aiming for is opening up access to the great elements that OFBiz provides to any language that can
> support integration standards, not just repackage Java interfaces on a language-by-language basis.

The idea is more for reusing legacy code, without introducing an ESB for that (sledge-hammer vs fly)

>> I have seen others taking the same approach, for instance to link ElasticPach with OFBiz, or even to link diff. versions of
>> OFBiz...
>> But it makes more sense IMO for legacy than for new UIs. Of course this implies to know/use OFBiz widgets, but it's not that
>> hard.
>
> It's very very hard when the OFBiz widgets are assuming a UX workflow or stylesheets that are different than the rest of the
> application.  It's also very very hard when the rest of the application is not completely OFBiz based (in which case, there would
> be no reason to do any of this).
>
> The goal I am talking about is fundamentally different than a star configuration of integration where every integration endpoint
> must have strong coupling with every other application through direct API calls.  By using a bus configuration, an integration
> point just publishes itself on the bus, and other applications can be routed to whatever application can accept messages of that
> type.  It is the tight coupling to Java interfaces that needs to be weakened, IMO.

So you are mostly interested by OFBiz as WS API. David already explained how it's possible to use OFBiz without an ESB in such case 
(XML-RPC). In term of development productivity, I might be interesting to consider this possibilty.

Jacques 

Re: OFBIZ: the road ahead

[Brian Topping <to...@codehaus.org>]

On Jan 27, 2011, at 7:40 AM, Jacques Le Roux wrote:

> Why Mule rather than ServiceMix? I can't see much diff. between them.

ServiceMix is more strongly based on W3C WS where Mule is more open to different transports.  I felt for my application that Mule would be more performant, although I prefer the infrastructure support that ServiceMix provides (OSGi, Maven).

> For PHP I will soon make a proposition. It's based on Quercus (GPL hence of out OFBiz repo) and sitting on my table for almost 2 years now (my bad)

Quercus looks really good and I've considered it in the past for other projects.  It has some notable longstanding issues, but they can be worked around.

What I am concerned about by having named only two (Ruby, PHP) is that I left out dozens of other technologies.  Quercus only solves one (PHP).  What I am aiming for is opening up access to the great elements that OFBiz provides to any language that can support integration standards, not just repackage Java interfaces on a language-by-language basis.  

> I have seen others taking the same approach, for instance to link ElasticPach with OFBiz, or even to link diff. versions of OFBiz...
> But it makes more sense IMO for legacy than for new UIs. Of course this implies to know/use OFBiz widgets, but it's not that hard.

It's very very hard when the OFBiz widgets are assuming a UX workflow or stylesheets that are different than the rest of the application.  It's also very very hard when the rest of the application is not completely OFBiz based (in which case, there would be no reason to do any of this).  

The goal I am talking about is fundamentally different than a star configuration of integration where every integration endpoint must have strong coupling with every other application through direct API calls.  By using a bus configuration, an integration point just publishes itself on the bus, and other applications can be routed to whatever application can accept messages of that type.  It is the tight coupling to Java interfaces that needs to be weakened, IMO.

Re: OFBIZ: the road ahead

[Jacques Le Roux <ja...@les7arts.com>]

Brian Topping wrote:
> Hi Pierre,
>
> By your inquiry on the future, do you mean with specific features in the applications or how they work together?
>
> As an architect, I am interested in not just an ability to integrate my application against OFBiz, but allow my application to
> take part in message orchestration by patching itself into the workflows.  I should like that a stock OFBiz deployment can be
> customized through open interfaces with now-common enterprise integration patterns instead of requiring a proprietary (if open)
> means of application customization.
>
> Apache Ode, ServiceMix and the W3C WS stacks may not be the way to go, but I think the "major moving parts" of that model might
> provide a good pattern for how the applications could work together in the future.  (In other words, Mule might be preferred, but
> the applications still remodeled on EIP for open integration).

Why Mule rather than ServiceMix? I can't see much diff. between them.

> If the applications integrated this way and were uncoupled into separate Maven projects, the applications would also be usable
> individually where appropriate.  It would be a challenge to do this, but a new class of user would result, one that could pick
> and choose applications that they wanted to integrate against their local deployment instead of the current all-or-nothing
> approach.
>
> ServiceMix has some rather comprehensive integrations with Maven in this regard which I don't pretend to understand very well,
> but a team effort might result in a solution that really reinvigorates the ecosystem through a large number of new use cases of
> existing applications.  For instance, REST style or WS interfaces might open the applications to use by Ruby or PHP developers.

For PHP I will soon make a proposition. It's based on Quercus (GPL hence of out OFBiz repo) and sitting on my table for almost 2 
years now (my bad)

> The depth and experience wrapped up in the OFBiz ecosystem is staggering, but it's reach is limited by it's rather monolithic
> Java-centric deployment.  If opening it up in this way would significantly alter the user base, there would be a lot more
> opportunities for everyone involved.
>
> I am not trolling here, so please excuse if what I am writing is naive.  I do not have enough technical chops on the guts of
> OFBiz to know what toes I am stepping on, just presenting a vision of what I would like to integrate against.  I did investigate
> OFBiz for an ERP solution I need to deliver in the retail space and found that it would be challenging to use the user interface
> facilities I found to create the customer UI.  My solution was to avoid the problem by building my web UI in a message-oriented
> manner, back it by Mule, and push the problem out to the future.

I have seen others taking the same approach, for instance to link ElasticPach with OFBiz, or even to link diff. versions of OFBiz...
But it makes more sense IMO for legacy than for new UIs. Of course this implies to know/use OFBiz widgets, but it's not that hard.

Jacques

>It's not a question for me of whether OFBiz will be there when
> I need it, but more that I will integrate against the applications with standard EIP.  If OFBiz had an accessible EIP
> presentation like this, it would be a natural choice to integrate with, both for me, and I suspect many other people in my
> situation.  The Ode style orchestration is more about the applications working together, which would be grav! y on the meal.
>
> $0.02...
>
> Brian