Discussion: ESB or ServiceMix Integration

[Adrian Crum]

Anil sent out an email some time ago with the subject "Application
framework technology set" in which he started a discussion on new
technologies that could be used in OFBiz. One of the technologies
mentioned - Enterprise Service Bus - received several "+1" responses, so
I thought I would get the discussion started on that one technology.

Apache's ServiceMix was suggested as one solution to implementing ESB.
Should we start looking at that? Or are there other alternatives that
would be better?

Does anyone have experience using ESB who would be willing to coordinate
the integration effort?

I'm willing to help with this effort. Is anyone else available?

-Adrian

[Jacques Le Roux]

I have no real experience (I mean fieldwork), I just read some articles (notably 1st chapter of http://www.manning.com/rademakers/ 
when it was written - Manning Early Access Program -). There the 1st and 4th chpater are now downloadable
From what I read, and because it's Apache, I would favored Service Mix.

Jacques

From: "Adrian Crum" <[hidden email]>

> Anil sent out an email some time ago with the subject "Application framework technology set" in which he started a discussion on
> new technologies that could be used in OFBiz. One of the technologies mentioned - Enterprise Service Bus - received several "+1"
> responses, so I thought I would get the discussion started on that one technology.
>
> Apache's ServiceMix was suggested as one solution to implementing ESB. Should we start looking at that? Or are there other
> alternatives that would be better?
>
> Does anyone have experience using ESB who would be willing to coordinate the integration effort?
>
> I'm willing to help with this effort. Is anyone else available?
>
> -Adrian
>

[David E Jones-3]

I've been looking into some of these for a while now (ServiceMix, as  
well as others that have existed over the years). The basic problem  
is: what will we do with them?

Usually an ESB is used within an organization to integrate various  
applications by trying to get all of the applications to talk to the  
ESB. OFBiz would just be one of those applications. It would be great  
to make sure we could talk effectively to ServiceMix and/or other  
ESBs, but of less value to actually include ServiceMix into OFBiz.

In short we want to work well with ESBs, but if an organization needs/
wants an ESB then they will probably choose than independently of  
whatever OFBiz or any other application offers. In other words, it is  
of more value to work with a variety of ESBs than to include any.

On a related note, if want ServiceMix compatibility we should do that  
without any ServiceMix libraries. The whole point is loose coupling,  
and if we get working well with ServiceMix in a loosely coupled way  
we'll have a better chance of working well with other app servers.

One interesting project we may want to include in OFBiz in order to  
work better with external service environments is CXF. It has  
libraries for exposing services with a wide variety of standards  
support, and for consuming services available from a wide variety of  
standards. The only question I had based on limited research of it was  
whether or not we could interact with it at a low enough level to be  
able to automatically expose Service Engine services in a variety of  
ways, and also map incoming service calls of various types of OFBiz  
Service Engine services (like we do with XML-RPC and to some extend  
with Axis for SOAP).

-David


On Jan 8, 2009, at 9:49 AM, Adrian Crum wrote:

> Anil sent out an email some time ago with the subject "Application  
> framework technology set" in which he started a discussion on new  
> technologies that could be used in OFBiz. One of the technologies  
> mentioned - Enterprise Service Bus - received several "+1"  
> responses, so I thought I would get the discussion started on that  
> one technology.
>
> Apache's ServiceMix was suggested as one solution to implementing  
> ESB. Should we start looking at that? Or are there other  
> alternatives that would be better?
>
> Does anyone have experience using ESB who would be willing to  
> coordinate the integration effort?
>
> I'm willing to help with this effort. Is anyone else available?
>
> -Adrian

[Terry Zhang]

Ofbiz API site http://api.ofbiz.org/ doesn't work now.
I looked up the API three days ago, but it is down today.
Please fix it up asap.
Thanks.

[rajsaini]

I see two possible scenarios where ESB can be used in OFBiz:

1. Internally to make OFBiz applications to talk to each other. This
will make OFBiz more modular and applications loosely coupled.

2. Make external applications talk to OFBiz.

ServiceMix ESB implements Java ESB standard called Java Business
Integration (JBI). Therefore, it should be JBI integration and not the
particular ESB such as ServiceMix.

Thanks,

Raj

David E Jones wrote:

>
> I've been looking into some of these for a while now (ServiceMix, as
> well as others that have existed over the years). The basic problem
> is: what will we do with them?
>
> Usually an ESB is used within an organization to integrate various
> applications by trying to get all of the applications to talk to the
> ESB. OFBiz would just be one of those applications. It would be great
> to make sure we could talk effectively to ServiceMix and/or other
> ESBs, but of less value to actually include ServiceMix into OFBiz.
>
> In short we want to work well with ESBs, but if an organization
> needs/wants an ESB then they will probably choose than independently
> of whatever OFBiz or any other application offers. In other words, it
> is of more value to work with a variety of ESBs than to include any.
>
> On a related note, if want ServiceMix compatibility we should do that
> without any ServiceMix libraries. The whole point is loose coupling,
> and if we get working well with ServiceMix in a loosely coupled way
> we'll have a better chance of working well with other app servers.
>
> One interesting project we may want to include in OFBiz in order to
> work better with external service environments is CXF. It has
> libraries for exposing services with a wide variety of standards
> support, and for consuming services available from a wide variety of
> standards. The only question I had based on limited research of it was
> whether or not we could interact with it at a low enough level to be
> able to automatically expose Service Engine services in a variety of
> ways, and also map incoming service calls of various types of OFBiz
> Service Engine services (like we do with XML-RPC and to some extend
> with Axis for SOAP).
>
> -David
>
>
> On Jan 8, 2009, at 9:49 AM, Adrian Crum wrote:
>
>> Anil sent out an email some time ago with the subject "Application
>> framework technology set" in which he started a discussion on new
>> technologies that could be used in OFBiz. One of the technologies
>> mentioned - Enterprise Service Bus - received several "+1" responses,
>> so I thought I would get the discussion started on that one technology.
>>
>> Apache's ServiceMix was suggested as one solution to implementing
>> ESB. Should we start looking at that? Or are there other alternatives
>> that would be better?
>>
>> Does anyone have experience using ESB who would be willing to
>> coordinate the integration effort?
>>
>> I'm willing to help with this effort. Is anyone else available?
>>
>> -Adrian
>
>

[BJ Freeman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

the official ofbiz website is now
http://ofbiz.apache.org and has for some time now.

Terry Zhang sent the following on 1/8/2009 7:33 PM:
> Ofbiz API site http://api.ofbiz.org/ doesn't work now.
> I looked up the API three days ago, but it is down today.
> Please fix it up asap.
> Thanks.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJZuVkrP3NbaWWqE4RAtl7AKCI5dgUqP8E4/63F4kZhVaMp1FixQCdFi+K
5yw2pwWzbWmo9qNi6n18Buk=
=xpVe
-----END PGP SIGNATURE-----

[David E Jones-3]

On Jan 8, 2009, at 8:46 PM, Raj Saini wrote:

> 1. Internally to make OFBiz applications to talk to each other. This  
> will make OFBiz more modular and applications loosely coupled.

I'm pretty strongly against trying to make all OFBiz applications  
loosely coupled. Much of the efficiency and power of OFBiz comes from  
the fact that the entire enterprise can share common data, like Party  
and Product data, inherently because they use the same database tables.

To me loose coupling means that the applications share nothing... they  
exclusively communicate through messages or services and have minimal  
dependencies on each other. Loose coupling is not always a good thing.  
Loose coupling of things that are closely related, or that are the  
same thing from different aspects or angles, results in redundancy and  
inconsistency.

-David

[Jacques Le Roux]

Yes, but the API is at http://api.ofbiz.org/  (from the main page).
Anyway you can generate it and use it locally : run "ant docs-all"

Jacques

From: "BJ Freeman" <[hidden email]>

>
> the official ofbiz website is now
> http://ofbiz.apache.org and has for some time now.
>
> Terry Zhang sent the following on 1/8/2009 7:33 PM:
>> Ofbiz API site http://api.ofbiz.org/ doesn't work now.
>> I looked up the API three days ago, but it is down today.
>> Please fix it up asap.
>> Thanks.
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJZuVkrP3NbaWWqE4RAtl7AKCI5dgUqP8E4/63F4kZhVaMp1FixQCdFi+K
> 5yw2pwWzbWmo9qNi6n18Buk=
> =xpVe
> -----END PGP SIGNATURE-----
>

[rajsaini]

David E Jones wrote:
> To me loose coupling means that the applications share nothing... they
> exclusively communicate through messages or services and have minimal
> dependencies on each other. Loose coupling is not always a good thing.
> Loose coupling of things that are closely related, or that are the
> same thing from different aspects or angles, results in redundancy and
> inconsistency.
This is a good article how Event driven Architecture (EDA) can fit into
a Enterprise System.

http://www.eaipatterns.com/docs/EDA.pdf

Thanks,

Raj

>
> -David
>
>
>

[Adrian Crum]

David E Jones wrote:

> On Jan 8, 2009, at 8:46 PM, Raj Saini wrote:
>
>> 1. Internally to make OFBiz applications to talk to each other. This
>> will make OFBiz more modular and applications loosely coupled.
>
> I'm pretty strongly against trying to make all OFBiz applications
> loosely coupled. Much of the efficiency and power of OFBiz comes from
> the fact that the entire enterprise can share common data, like Party
> and Product data, inherently because they use the same database tables.
>
> To me loose coupling means that the applications share nothing... they
> exclusively communicate through messages or services and have minimal
> dependencies on each other. Loose coupling is not always a good thing.
> Loose coupling of things that are closely related, or that are the same
> thing from different aspects or angles, results in redundancy and
> inconsistency.

On the other hand, loose coupling could facilitate something Andrew
wished for: the ability to pick and choose modules without all of the
built-in dependencies.

-Adrian

[David E Jones-3]

On Jan 9, 2009, at 7:17 AM, Adrian Crum wrote:

> David E Jones wrote:
>> On Jan 8, 2009, at 8:46 PM, Raj Saini wrote:
>>> 1. Internally to make OFBiz applications to talk to each other.  
>>> This will make OFBiz more modular and applications loosely coupled.
>> I'm pretty strongly against trying to make all OFBiz applications  
>> loosely coupled. Much of the efficiency and power of OFBiz comes  
>> from the fact that the entire enterprise can share common data,  
>> like Party and Product data, inherently because they use the same  
>> database tables.
>> To me loose coupling means that the applications share nothing...  
>> they exclusively communicate through messages or services and have  
>> minimal dependencies on each other. Loose coupling is not always a  
>> good thing. Loose coupling of things that are closely related, or  
>> that are the same thing from different aspects or angles, results  
>> in redundancy and inconsistency.
>
>
> On the other hand, loose coupling could facilitate something Andrew  
> wished for: the ability to pick and choose modules without all of  
> the built-in dependencies.

So, how would we go about doing that?

-David

[David E Jones-3]

On Jan 9, 2009, at 12:47 AM, Raj Saini wrote:

> David E Jones wrote:
>> To me loose coupling means that the applications share nothing...  
>> they exclusively communicate through messages or services and have  
>> minimal dependencies on each other. Loose coupling is not always a  
>> good thing. Loose coupling of things that are closely related, or  
>> that are the same thing from different aspects or angles, results  
>> in redundancy and inconsistency.
> This is a good article how Event driven Architecture (EDA) can fit  
> into a Enterprise System.
>
> http://www.eaipatterns.com/docs/EDA.pdf

I'm not sure what this has to do with loose versus tight coupling of  
_applications_. It is more related to loose coupling of individual  
units of logic.

That is an interesting document, and actually does a great job of  
describing what the OFBiz Service Engine is all about.

-David