You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2009/02/02 17:51:04 UTC
[DISCUSS] Implement protocol related components in Camel [WAS] Re: [Proposal] New components
Hi,
Another option is to implement such components in Apache Camel and
provide a way to easily wrap a camel component in a jbi component.
Such components are useful to users who only use Camel too, and it
would be a pity to duplicate the work.
Thoughts?
Hadrian
On Feb 1, 2009, at 2:28 AM, Jean-Baptiste Onofré wrote:
> Hi Chris,
>
> Thanks.
>
> I propose the following priority for BCs :
> - servicemix-ldap
> - servicemix-exec
> - servicemix-jdbc
> - servicemix-asterisk
> - servicemix-talend
> - servicemix-sap
> - servicemix-cics
>
> What about the servicemix-ejb, does it make sense or do we consider
> that CXF-SE is enough ?
>
> Regards
> JB
>
> On Saturday 31 January 2009 - 17:00, Chris Custine wrote:
>> Hi JB,
>> A while back I did some playing with asterisk-java (
>> http://asterisk-java.org/) in SMX4 and OSGi so I would be happy to
>> help
>> create a more general purpose JBI component. My code never evolved
>> beyond
>> sandbox quality, but I will dust it off and maybe soon we can chat
>> about
>> some features.
>>
>> Chris
>>
>> --
>> Chris Custine
>> My Blog :: http://blog.organicelement.com
>> Apache ServiceMix :: http://servicemix.apache.org
>> Apache Directory Server :: http://directory.apache.org
>>
>>
>> On Fri, Jan 30, 2009 at 1:27 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>> >wrote:
>>
>>> Dear all,
>>>
>>> I'm completing the unit tests on the SMPP BC but it's now quite
>>> the end
>>> (Lars has already included on the svn repo) (it's the SM-1623).
>>> I have begun to work on the SM-1771 (extend the SU <classpath/>
>>> location
>>> support).
>>>
>>> But, I would like to implement new components :
>>> - JDBC BC : read and write messages from JDBC
>>> - Talend BC : read and write messages from the Talend ETL
>>> - Asterisk BC : read and write from Asterisk VoIP software
>>> - Exec BC : read and write from command execution (using commons-
>>> exec)
>>> - LDAP BC : read and write from LDAP (using JNDI)
>>> - CICS BC : read and write messages from CICS mainframe
>>> - SAP BC : read and write messages from SAP
>>> - EJB BC : currently, I use CXF-SE to call an EJB. Maybe a component
>>> exposing directly (either if it use CXF-SE in background).
>>>
>>> What do you think about these components ?
>>> Does it make sense (for me, it's the case as I have request from
>>> customers
>>> to support in FSB/SMX legacy platform such as CICS, SAP, JDBC,
>>> etc) ?
>>>
>>> I'm ready to begin this work if you are OK.
>>>
>>> Regards
>>> JB
>>> --
>>> Jean-Baptiste Onofré (Nanthrax)
>>> BuildProcess/AutoDeploy Project Leader
>>> http://buildprocess.sourceforge.net
>>> jb@nanthrax.net
>>> PGP : 17D4F086
>>>
>
> --
> Jean-Baptiste Onofré (Nanthrax)
> BuildProcess/AutoDeploy Project Leader
> http://buildprocess.sourceforge.net
> jb@nanthrax.net
> PGP : 17D4F086
Re: [DISCUSS] Implement protocol related components in Camel [WAS] Re: [Proposal] New components
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I think the path Gert, Guillaume anad James suggested to make Camel
endpoints well behaved citizens in SMX is the right thing to do. I
think the lifecycle issue is solvable in camel. Let's keep this
discussion going.
Hadrian
On Feb 3, 2009, at 8:18 AM, jb@nanthrax.net wrote:
> Guys,
>
> I have begun the servicemix-ldap component :
> http://svn.nanthrax.net/servicemix-ldap/trunk/
>
> My purpose is to compare with the Camel LDAP component and
> investigate how it's possible to use a common part.
> So, it's a kind of prototype to
> 1/ provide a LDAP component :)
> 2/ investigate and test how Camel and SMX components can be shared
>
> Regards
> JB
>
> PS : for now, I have put the source code on my svn repository. I
> will commit on the ASF one as soons as possible.
>
> On Monday 02 February 2009 - 19:25, Guillaume Nodet wrote:
>> This should not be too complicated to implement if needed.
>>
>> The idea in JBI is that service assemblies (aka routes un camel) have
>> three real states: started, stopped and shutdown.
>> Started means that all endpoints are fully operational. Shutdown
>> means that no exchanges will be processed. The stopped state is the
>> interesting one: consumer endpoints will not accept any new requests
>> from the outside world but will still process existing requests.
>> Other
>> provider endpoints fully process requets. The goal is to ensure an
>> orderly shut down of assemblies and not loose any messages. For
>> example a jms consumer will stop consuming jms messages from the
>> queue, but will still enqueue responses when they come back from the
>> route.
>>
>> If we are to support that in camel, we should do it in a way that we
>> can easily control the lifecycle of mixed applications (if you mix
>> servicemix endpoints and camel routes).
>>
>> On 02/02/2009, James Strachan <ja...@gmail.com> wrote:
>>> 2009/2/2 Guillaume Nodet <gn...@gmail.com>:
>>>> It might be doable. I guess the way to do that would be to
>>>> define the
>>>> JBI endpoint as a wrapper to a camel endpoint. When the JBI
>>>> endpoint
>>>> would be initialized / started, a camel route would be created
>>>> for it.
>>>> Not sure how well camel endpoints can handle the JBI lifecycle
>>>> where
>>>> new requests are not accepted, but existing exchanges are still
>>>> processed until completion (for a consumer endpoint).
>>>
>>> Could you give an example of a well behaving JBI endpoint that does
>>> this? I wonder how hard this would be to add; either at the
>>> Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://fusesource.com/
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by jb...@nanthrax.net.
Guys,
I have begun the servicemix-ldap component :
http://svn.nanthrax.net/servicemix-ldap/trunk/
My purpose is to compare with the Camel LDAP component and investigate how it's possible to use a common part.
So, it's a kind of prototype to
1/ provide a LDAP component :)
2/ investigate and test how Camel and SMX components can be shared
Regards
JB
PS : for now, I have put the source code on my svn repository. I will commit on the ASF one as soons as possible.
On Monday 02 February 2009 - 19:25, Guillaume Nodet wrote:
> This should not be too complicated to implement if needed.
>
> The idea in JBI is that service assemblies (aka routes un camel) have
> three real states: started, stopped and shutdown.
> Started means that all endpoints are fully operational. Shutdown
> means that no exchanges will be processed. The stopped state is the
> interesting one: consumer endpoints will not accept any new requests
> from the outside world but will still process existing requests. Other
> provider endpoints fully process requets. The goal is to ensure an
> orderly shut down of assemblies and not loose any messages. For
> example a jms consumer will stop consuming jms messages from the
> queue, but will still enqueue responses when they come back from the
> route.
>
> If we are to support that in camel, we should do it in a way that we
> can easily control the lifecycle of mixed applications (if you mix
> servicemix endpoints and camel routes).
>
> On 02/02/2009, James Strachan <ja...@gmail.com> wrote:
> > 2009/2/2 Guillaume Nodet <gn...@gmail.com>:
> >> It might be doable. I guess the way to do that would be to define the
> >> JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
> >> would be initialized / started, a camel route would be created for it.
> >> Not sure how well camel endpoints can handle the JBI lifecycle where
> >> new requests are not accepted, but existing exchanges are still
> >> processed until completion (for a consumer endpoint).
> >
> > Could you give an example of a well behaving JBI endpoint that does
> > this? I wonder how hard this would be to add; either at the
> > Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc
> >
> > --
> > James
> > -------
> > http://macstrac.blogspot.com/
> >
> > Open Source Integration
> > http://fusesource.com/
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by Claus Ibsen <cl...@gmail.com>.
Would be cool if SMX and Camel could share more components.
A bit silly when we invent the wheels twice. Also the documentation
part of the component would be easier.
On Mon, Feb 2, 2009 at 7:25 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> This should not be too complicated to implement if needed.
>
> The idea in JBI is that service assemblies (aka routes un camel) have
> three real states: started, stopped and shutdown.
> Started means that all endpoints are fully operational. Shutdown
> means that no exchanges will be processed. The stopped state is the
> interesting one: consumer endpoints will not accept any new requests
> from the outside world but will still process existing requests. Other
> provider endpoints fully process requets. The goal is to ensure an
> orderly shut down of assemblies and not loose any messages. For
> example a jms consumer will stop consuming jms messages from the
> queue, but will still enqueue responses when they come back from the
> route.
>
> If we are to support that in camel, we should do it in a way that we
> can easily control the lifecycle of mixed applications (if you mix
> servicemix endpoints and camel routes).
>
> On 02/02/2009, James Strachan <ja...@gmail.com> wrote:
>> 2009/2/2 Guillaume Nodet <gn...@gmail.com>:
>>> It might be doable. I guess the way to do that would be to define the
>>> JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
>>> would be initialized / started, a camel route would be created for it.
>>> Not sure how well camel endpoints can handle the JBI lifecycle where
>>> new requests are not accepted, but existing exchanges are still
>>> processed until completion (for a consumer endpoint).
>>
>> Could you give an example of a well behaving JBI endpoint that does
>> this? I wonder how hard this would be to add; either at the
>> Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by Guillaume Nodet <gn...@gmail.com>.
This should not be too complicated to implement if needed.
The idea in JBI is that service assemblies (aka routes un camel) have
three real states: started, stopped and shutdown.
Started means that all endpoints are fully operational. Shutdown
means that no exchanges will be processed. The stopped state is the
interesting one: consumer endpoints will not accept any new requests
from the outside world but will still process existing requests. Other
provider endpoints fully process requets. The goal is to ensure an
orderly shut down of assemblies and not loose any messages. For
example a jms consumer will stop consuming jms messages from the
queue, but will still enqueue responses when they come back from the
route.
If we are to support that in camel, we should do it in a way that we
can easily control the lifecycle of mixed applications (if you mix
servicemix endpoints and camel routes).
On 02/02/2009, James Strachan <ja...@gmail.com> wrote:
> 2009/2/2 Guillaume Nodet <gn...@gmail.com>:
>> It might be doable. I guess the way to do that would be to define the
>> JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
>> would be initialized / started, a camel route would be created for it.
>> Not sure how well camel endpoints can handle the JBI lifecycle where
>> new requests are not accepted, but existing exchanges are still
>> processed until completion (for a consumer endpoint).
>
> Could you give an example of a well behaving JBI endpoint that does
> this? I wonder how hard this would be to add; either at the
> Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by Guillaume Nodet <gn...@gmail.com>.
This should not be too complicated to implement if needed.
The idea in JBI is that service assemblies (aka routes un camel) have
three real states: started, stopped and shutdown.
Started means that all endpoints are fully operational. Shutdown
means that no exchanges will be processed. The stopped state is the
interesting one: consumer endpoints will not accept any new requests
from the outside world but will still process existing requests. Other
provider endpoints fully process requets. The goal is to ensure an
orderly shut down of assemblies and not loose any messages. For
example a jms consumer will stop consuming jms messages from the
queue, but will still enqueue responses when they come back from the
route.
If we are to support that in camel, we should do it in a way that we
can easily control the lifecycle of mixed applications (if you mix
servicemix endpoints and camel routes).
On 02/02/2009, James Strachan <ja...@gmail.com> wrote:
> 2009/2/2 Guillaume Nodet <gn...@gmail.com>:
>> It might be doable. I guess the way to do that would be to define the
>> JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
>> would be initialized / started, a camel route would be created for it.
>> Not sure how well camel endpoints can handle the JBI lifecycle where
>> new requests are not accepted, but existing exchanges are still
>> processed until completion (for a consumer endpoint).
>
> Could you give an example of a well behaving JBI endpoint that does
> this? I wonder how hard this would be to add; either at the
> Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by James Strachan <ja...@gmail.com>.
2009/2/2 Guillaume Nodet <gn...@gmail.com>:
> It might be doable. I guess the way to do that would be to define the
> JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
> would be initialized / started, a camel route would be created for it.
> Not sure how well camel endpoints can handle the JBI lifecycle where
> new requests are not accepted, but existing exchanges are still
> processed until completion (for a consumer endpoint).
Could you give an example of a well behaving JBI endpoint that does
this? I wonder how hard this would be to add; either at the
Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by James Strachan <ja...@gmail.com>.
2009/2/2 Guillaume Nodet <gn...@gmail.com>:
> It might be doable. I guess the way to do that would be to define the
> JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
> would be initialized / started, a camel route would be created for it.
> Not sure how well camel endpoints can handle the JBI lifecycle where
> new requests are not accepted, but existing exchanges are still
> processed until completion (for a consumer endpoint).
Could you give an example of a well behaving JBI endpoint that does
this? I wonder how hard this would be to add; either at the
Camel-Endpoint-As-JBI-Endpoint wrapper or inside Camel etc
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by Guillaume Nodet <gn...@gmail.com>.
It might be doable. I guess the way to do that would be to define the
JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
would be initialized / started, a camel route would be created for it.
Not sure how well camel endpoints can handle the JBI lifecycle where
new requests are not accepted, but existing exchanges are still
processed until completion (for a consumer endpoint).
On Mon, Feb 2, 2009 at 17:53, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Let's include the camel folks in this discussion.
>
>
> On Feb 2, 2009, at 11:51 AM, Hadrian Zbarcea wrote:
>
>> Hi,
>>
>> Another option is to implement such components in Apache Camel and provide
>> a way to easily wrap a camel component in a jbi component. Such components
>> are useful to users who only use Camel too, and it would be a pity to
>> duplicate the work.
>>
>> Thoughts?
>> Hadrian
>>
>>
>> On Feb 1, 2009, at 2:28 AM, Jean-Baptiste Onofré wrote:
>>
>>> Hi Chris,
>>>
>>> Thanks.
>>>
>>> I propose the following priority for BCs :
>>> - servicemix-ldap
>>> - servicemix-exec
>>> - servicemix-jdbc
>>> - servicemix-asterisk
>>> - servicemix-talend
>>> - servicemix-sap
>>> - servicemix-cics
>>>
>>> What about the servicemix-ejb, does it make sense or do we consider that
>>> CXF-SE is enough ?
>>>
>>> Regards
>>> JB
>>>
>>> On Saturday 31 January 2009 - 17:00, Chris Custine wrote:
>>>>
>>>> Hi JB,
>>>> A while back I did some playing with asterisk-java (
>>>> http://asterisk-java.org/) in SMX4 and OSGi so I would be happy to help
>>>> create a more general purpose JBI component. My code never evolved
>>>> beyond
>>>> sandbox quality, but I will dust it off and maybe soon we can chat about
>>>> some features.
>>>>
>>>> Chris
>>>>
>>>> --
>>>> Chris Custine
>>>> My Blog :: http://blog.organicelement.com
>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>> Apache Directory Server :: http://directory.apache.org
>>>>
>>>>
>>>> On Fri, Jan 30, 2009 at 1:27 PM, Jean-Baptiste Onofré
>>>> <jb...@nanthrax.net>wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I'm completing the unit tests on the SMPP BC but it's now quite the end
>>>>> (Lars has already included on the svn repo) (it's the SM-1623).
>>>>> I have begun to work on the SM-1771 (extend the SU <classpath/>
>>>>> location
>>>>> support).
>>>>>
>>>>> But, I would like to implement new components :
>>>>> - JDBC BC : read and write messages from JDBC
>>>>> - Talend BC : read and write messages from the Talend ETL
>>>>> - Asterisk BC : read and write from Asterisk VoIP software
>>>>> - Exec BC : read and write from command execution (using commons-exec)
>>>>> - LDAP BC : read and write from LDAP (using JNDI)
>>>>> - CICS BC : read and write messages from CICS mainframe
>>>>> - SAP BC : read and write messages from SAP
>>>>> - EJB BC : currently, I use CXF-SE to call an EJB. Maybe a component
>>>>> exposing directly (either if it use CXF-SE in background).
>>>>>
>>>>> What do you think about these components ?
>>>>> Does it make sense (for me, it's the case as I have request from
>>>>> customers
>>>>> to support in FSB/SMX legacy platform such as CICS, SAP, JDBC, etc) ?
>>>>>
>>>>> I'm ready to begin this work if you are OK.
>>>>>
>>>>> Regards
>>>>> JB
>>>>> --
>>>>> Jean-Baptiste Onofré (Nanthrax)
>>>>> BuildProcess/AutoDeploy Project Leader
>>>>> http://buildprocess.sourceforge.net
>>>>> jb@nanthrax.net
>>>>> PGP : 17D4F086
>>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré (Nanthrax)
>>> BuildProcess/AutoDeploy Project Leader
>>> http://buildprocess.sourceforge.net
>>> jb@nanthrax.net
>>> PGP : 17D4F086
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Implement protocol related components in Camel [WAS]
Re: [Proposal] New components
Posted by Guillaume Nodet <gn...@gmail.com>.
It might be doable. I guess the way to do that would be to define the
JBI endpoint as a wrapper to a camel endpoint. When the JBI endpoint
would be initialized / started, a camel route would be created for it.
Not sure how well camel endpoints can handle the JBI lifecycle where
new requests are not accepted, but existing exchanges are still
processed until completion (for a consumer endpoint).
On Mon, Feb 2, 2009 at 17:53, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Let's include the camel folks in this discussion.
>
>
> On Feb 2, 2009, at 11:51 AM, Hadrian Zbarcea wrote:
>
>> Hi,
>>
>> Another option is to implement such components in Apache Camel and provide
>> a way to easily wrap a camel component in a jbi component. Such components
>> are useful to users who only use Camel too, and it would be a pity to
>> duplicate the work.
>>
>> Thoughts?
>> Hadrian
>>
>>
>> On Feb 1, 2009, at 2:28 AM, Jean-Baptiste Onofré wrote:
>>
>>> Hi Chris,
>>>
>>> Thanks.
>>>
>>> I propose the following priority for BCs :
>>> - servicemix-ldap
>>> - servicemix-exec
>>> - servicemix-jdbc
>>> - servicemix-asterisk
>>> - servicemix-talend
>>> - servicemix-sap
>>> - servicemix-cics
>>>
>>> What about the servicemix-ejb, does it make sense or do we consider that
>>> CXF-SE is enough ?
>>>
>>> Regards
>>> JB
>>>
>>> On Saturday 31 January 2009 - 17:00, Chris Custine wrote:
>>>>
>>>> Hi JB,
>>>> A while back I did some playing with asterisk-java (
>>>> http://asterisk-java.org/) in SMX4 and OSGi so I would be happy to help
>>>> create a more general purpose JBI component. My code never evolved
>>>> beyond
>>>> sandbox quality, but I will dust it off and maybe soon we can chat about
>>>> some features.
>>>>
>>>> Chris
>>>>
>>>> --
>>>> Chris Custine
>>>> My Blog :: http://blog.organicelement.com
>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>> Apache Directory Server :: http://directory.apache.org
>>>>
>>>>
>>>> On Fri, Jan 30, 2009 at 1:27 PM, Jean-Baptiste Onofré
>>>> <jb...@nanthrax.net>wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I'm completing the unit tests on the SMPP BC but it's now quite the end
>>>>> (Lars has already included on the svn repo) (it's the SM-1623).
>>>>> I have begun to work on the SM-1771 (extend the SU <classpath/>
>>>>> location
>>>>> support).
>>>>>
>>>>> But, I would like to implement new components :
>>>>> - JDBC BC : read and write messages from JDBC
>>>>> - Talend BC : read and write messages from the Talend ETL
>>>>> - Asterisk BC : read and write from Asterisk VoIP software
>>>>> - Exec BC : read and write from command execution (using commons-exec)
>>>>> - LDAP BC : read and write from LDAP (using JNDI)
>>>>> - CICS BC : read and write messages from CICS mainframe
>>>>> - SAP BC : read and write messages from SAP
>>>>> - EJB BC : currently, I use CXF-SE to call an EJB. Maybe a component
>>>>> exposing directly (either if it use CXF-SE in background).
>>>>>
>>>>> What do you think about these components ?
>>>>> Does it make sense (for me, it's the case as I have request from
>>>>> customers
>>>>> to support in FSB/SMX legacy platform such as CICS, SAP, JDBC, etc) ?
>>>>>
>>>>> I'm ready to begin this work if you are OK.
>>>>>
>>>>> Regards
>>>>> JB
>>>>> --
>>>>> Jean-Baptiste Onofré (Nanthrax)
>>>>> BuildProcess/AutoDeploy Project Leader
>>>>> http://buildprocess.sourceforge.net
>>>>> jb@nanthrax.net
>>>>> PGP : 17D4F086
>>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré (Nanthrax)
>>> BuildProcess/AutoDeploy Project Leader
>>> http://buildprocess.sourceforge.net
>>> jb@nanthrax.net
>>> PGP : 17D4F086
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Implement protocol related components in Camel [WAS] Re: [Proposal] New components
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Let's include the camel folks in this discussion.
On Feb 2, 2009, at 11:51 AM, Hadrian Zbarcea wrote:
> Hi,
>
> Another option is to implement such components in Apache Camel and
> provide a way to easily wrap a camel component in a jbi component.
> Such components are useful to users who only use Camel too, and it
> would be a pity to duplicate the work.
>
> Thoughts?
> Hadrian
>
>
> On Feb 1, 2009, at 2:28 AM, Jean-Baptiste Onofré wrote:
>
>> Hi Chris,
>>
>> Thanks.
>>
>> I propose the following priority for BCs :
>> - servicemix-ldap
>> - servicemix-exec
>> - servicemix-jdbc
>> - servicemix-asterisk
>> - servicemix-talend
>> - servicemix-sap
>> - servicemix-cics
>>
>> What about the servicemix-ejb, does it make sense or do we consider
>> that CXF-SE is enough ?
>>
>> Regards
>> JB
>>
>> On Saturday 31 January 2009 - 17:00, Chris Custine wrote:
>>> Hi JB,
>>> A while back I did some playing with asterisk-java (
>>> http://asterisk-java.org/) in SMX4 and OSGi so I would be happy to
>>> help
>>> create a more general purpose JBI component. My code never
>>> evolved beyond
>>> sandbox quality, but I will dust it off and maybe soon we can chat
>>> about
>>> some features.
>>>
>>> Chris
>>>
>>> --
>>> Chris Custine
>>> My Blog :: http://blog.organicelement.com
>>> Apache ServiceMix :: http://servicemix.apache.org
>>> Apache Directory Server :: http://directory.apache.org
>>>
>>>
>>> On Fri, Jan 30, 2009 at 1:27 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>>> >wrote:
>>>
>>>> Dear all,
>>>>
>>>> I'm completing the unit tests on the SMPP BC but it's now quite
>>>> the end
>>>> (Lars has already included on the svn repo) (it's the SM-1623).
>>>> I have begun to work on the SM-1771 (extend the SU <classpath/>
>>>> location
>>>> support).
>>>>
>>>> But, I would like to implement new components :
>>>> - JDBC BC : read and write messages from JDBC
>>>> - Talend BC : read and write messages from the Talend ETL
>>>> - Asterisk BC : read and write from Asterisk VoIP software
>>>> - Exec BC : read and write from command execution (using commons-
>>>> exec)
>>>> - LDAP BC : read and write from LDAP (using JNDI)
>>>> - CICS BC : read and write messages from CICS mainframe
>>>> - SAP BC : read and write messages from SAP
>>>> - EJB BC : currently, I use CXF-SE to call an EJB. Maybe a
>>>> component
>>>> exposing directly (either if it use CXF-SE in background).
>>>>
>>>> What do you think about these components ?
>>>> Does it make sense (for me, it's the case as I have request from
>>>> customers
>>>> to support in FSB/SMX legacy platform such as CICS, SAP, JDBC,
>>>> etc) ?
>>>>
>>>> I'm ready to begin this work if you are OK.
>>>>
>>>> Regards
>>>> JB
>>>> --
>>>> Jean-Baptiste Onofré (Nanthrax)
>>>> BuildProcess/AutoDeploy Project Leader
>>>> http://buildprocess.sourceforge.net
>>>> jb@nanthrax.net
>>>> PGP : 17D4F086
>>>>
>>
>> --
>> Jean-Baptiste Onofré (Nanthrax)
>> BuildProcess/AutoDeploy Project Leader
>> http://buildprocess.sourceforge.net
>> jb@nanthrax.net
>> PGP : 17D4F086
>
Re: [DISCUSS] Implement protocol related components in Camel [WAS] Re: [Proposal] New components
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Let's include the camel folks in this discussion.
On Feb 2, 2009, at 11:51 AM, Hadrian Zbarcea wrote:
> Hi,
>
> Another option is to implement such components in Apache Camel and
> provide a way to easily wrap a camel component in a jbi component.
> Such components are useful to users who only use Camel too, and it
> would be a pity to duplicate the work.
>
> Thoughts?
> Hadrian
>
>
> On Feb 1, 2009, at 2:28 AM, Jean-Baptiste Onofré wrote:
>
>> Hi Chris,
>>
>> Thanks.
>>
>> I propose the following priority for BCs :
>> - servicemix-ldap
>> - servicemix-exec
>> - servicemix-jdbc
>> - servicemix-asterisk
>> - servicemix-talend
>> - servicemix-sap
>> - servicemix-cics
>>
>> What about the servicemix-ejb, does it make sense or do we consider
>> that CXF-SE is enough ?
>>
>> Regards
>> JB
>>
>> On Saturday 31 January 2009 - 17:00, Chris Custine wrote:
>>> Hi JB,
>>> A while back I did some playing with asterisk-java (
>>> http://asterisk-java.org/) in SMX4 and OSGi so I would be happy to
>>> help
>>> create a more general purpose JBI component. My code never
>>> evolved beyond
>>> sandbox quality, but I will dust it off and maybe soon we can chat
>>> about
>>> some features.
>>>
>>> Chris
>>>
>>> --
>>> Chris Custine
>>> My Blog :: http://blog.organicelement.com
>>> Apache ServiceMix :: http://servicemix.apache.org
>>> Apache Directory Server :: http://directory.apache.org
>>>
>>>
>>> On Fri, Jan 30, 2009 at 1:27 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>>> >wrote:
>>>
>>>> Dear all,
>>>>
>>>> I'm completing the unit tests on the SMPP BC but it's now quite
>>>> the end
>>>> (Lars has already included on the svn repo) (it's the SM-1623).
>>>> I have begun to work on the SM-1771 (extend the SU <classpath/>
>>>> location
>>>> support).
>>>>
>>>> But, I would like to implement new components :
>>>> - JDBC BC : read and write messages from JDBC
>>>> - Talend BC : read and write messages from the Talend ETL
>>>> - Asterisk BC : read and write from Asterisk VoIP software
>>>> - Exec BC : read and write from command execution (using commons-
>>>> exec)
>>>> - LDAP BC : read and write from LDAP (using JNDI)
>>>> - CICS BC : read and write messages from CICS mainframe
>>>> - SAP BC : read and write messages from SAP
>>>> - EJB BC : currently, I use CXF-SE to call an EJB. Maybe a
>>>> component
>>>> exposing directly (either if it use CXF-SE in background).
>>>>
>>>> What do you think about these components ?
>>>> Does it make sense (for me, it's the case as I have request from
>>>> customers
>>>> to support in FSB/SMX legacy platform such as CICS, SAP, JDBC,
>>>> etc) ?
>>>>
>>>> I'm ready to begin this work if you are OK.
>>>>
>>>> Regards
>>>> JB
>>>> --
>>>> Jean-Baptiste Onofré (Nanthrax)
>>>> BuildProcess/AutoDeploy Project Leader
>>>> http://buildprocess.sourceforge.net
>>>> jb@nanthrax.net
>>>> PGP : 17D4F086
>>>>
>>
>> --
>> Jean-Baptiste Onofré (Nanthrax)
>> BuildProcess/AutoDeploy Project Leader
>> http://buildprocess.sourceforge.net
>> jb@nanthrax.net
>> PGP : 17D4F086
>