You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Alex Anderson <al...@frontlinesms.com> on 2012/01/26 15:21:28 UTC
Component Design - SMSLib
I'm working on a Camel component for SMSLib (http://www.smslib.org).
This is a Java library for communicating with mobile phones and modems
via a serial connection to send and receive SMS messages using the
Hayes (AT) command set.
I have a working prototype - you can see the source at
https://github.com/frontlinesms/camel-smslib
I have some general worries regards best-practice for designing the
Endpoint, Consumer and Producer for this component. I've not come
across comprehensive documentation for implementing Endpoints etc.,
and it's hard to know which other components would have a similar
model to mine and therefore would be worth delving into the source of.
Notes on serial devices
-----------------------
* before starting to send or receive messages through a device it must
be initialised
* initialisation can fail
Endpoint
--------
Each Endpoint will refer to a serial port, with corresponding URIs, e.g.:
* Windows: smslib:COM1
* Linux: smslib:/dev/tty01
When Endpoints are initially created, settings for the port (e.g. baud
rate) are passed to it. Later we may want to create endpoints for the
same port with different settings, but only if the original endpoint
is no longer in use.
Consumer
--------
There should be a maximum of 1 consumer per endpoint. The serial port
must be polled to check for incoming SMS. Rather than storing the SMS
within the Smslib service, I would like to pass them immediately
upstream to the Consumer's Processor.
Producer
--------
For my usage, I would like a single Producer per endpoint. This is
primarily because when there are no active producers or consumers for
an endpoint, the serial connection can be closed to allow its use by
other programs. It may be reasonable for other uses to have multiple
Producers for the same endpoint.
Current status
--------------
The endpoint has a Thread (implemented in a class SmslibService) which
controls the receiving from the serial connection - every 30 seconds
the thread wakes and checks the modem for new incoming messages. This
SmslibService keeps a reference to a Producer and a Consumer, and
should shut down the serial connection when both Consumer and Producer
are stopped.
Trying to create more than one Producer or Consumer for an Endpoint
will cause an Exception to be thrown.
This causes problems when the settings used to create an endpoint
initially are bad - there will be an Exception thrown in
SmslibProducer.doStart()
My Questions
------------
* are there any good resources for writing Endpoints that I should be reading?
* does anyone know of any similarly-modelled components whose source
might provide guidance?
* are there any patterns or base classes that I should obviously be
using for my Component, Endpoint, Consumer or Producer
implementations?
* is there anyone else interested in this component who could cast an
eye over the code?
Re: Component Design - SMSLib
Posted by Alex Anderson <al...@frontlinesms.com>.
Hi, thank you for the clear advice - I'll go through your recommended
components today and see if they help me get a better grip on things.
I definitely intend to unit test the wazoo out of everything, but it's
a little tricky right now as I'm not entirely sure where
responsibilities should lie in a Camel component. Again, hopefully
this should be clearer after reviewing file, mock and HTTP.
Cheers,
Alex
On 26 January 2012 20:50, deckerego <de...@gmail.com> wrote:
> My advice would be to read over the source for the file endpoint first - it's
> fairly bare-bones and makes it easy to comprehend how things work (for
> example, how endpoints receive parameters and then pass those along to
> consumers and producers). From there it's helpful to go through the mock
> endpoint and get a new point of view for how things are constructed largely
> in-memory. To get a better idea of how asynchronous production works, the
> source for the HTTP component is a good place to start.
>
> You'll see a common thread amongst the file/HTTP/mock components on common
> design patterns, including:
> - Start out with separate Component/Endpoint/Producer/Consumer/Message and
> unit test them out the wazoo individually
> - Use Camel's thread pool strategy when creating new thread pools
> - Use helper methods such as DefaultComponent.setProperties to set options
> from the URI onto your endpoint
> -
> DefaultAsyncProducer/DefaultConsumer/DefaultEndpoint/DefaultComponent/DefaultMessege
> should be the base classes you need
>
>
> Alex Anderson wrote
>>
>> * are there any good resources for writing Endpoints that I should be
>> reading?
>> * does anyone know of any similarly-modelled components whose source
>> might provide guidance?
>> * are there any patterns or base classes that I should obviously be
>> using for my Component, Endpoint, Consumer or Producer
>> implementations?
>> * is there anyone else interested in this component who could cast an
>> eye over the code?
>>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Component-Design-SMSLib-tp5432954p5433557.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Component Design - SMSLib
Posted by deckerego <de...@gmail.com>.
My advice would be to read over the source for the file endpoint first - it's
fairly bare-bones and makes it easy to comprehend how things work (for
example, how endpoints receive parameters and then pass those along to
consumers and producers). From there it's helpful to go through the mock
endpoint and get a new point of view for how things are constructed largely
in-memory. To get a better idea of how asynchronous production works, the
source for the HTTP component is a good place to start.
You'll see a common thread amongst the file/HTTP/mock components on common
design patterns, including:
- Start out with separate Component/Endpoint/Producer/Consumer/Message and
unit test them out the wazoo individually
- Use Camel's thread pool strategy when creating new thread pools
- Use helper methods such as DefaultComponent.setProperties to set options
from the URI onto your endpoint
-
DefaultAsyncProducer/DefaultConsumer/DefaultEndpoint/DefaultComponent/DefaultMessege
should be the base classes you need
Alex Anderson wrote
>
> * are there any good resources for writing Endpoints that I should be
> reading?
> * does anyone know of any similarly-modelled components whose source
> might provide guidance?
> * are there any patterns or base classes that I should obviously be
> using for my Component, Endpoint, Consumer or Producer
> implementations?
> * is there anyone else interested in this component who could cast an
> eye over the code?
>
--
View this message in context: http://camel.465427.n5.nabble.com/Component-Design-SMSLib-tp5432954p5433557.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Component Design - SMSLib
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Alex, it's not really clear what the license is for mock serial, looks
like you didn't think of that yet, maybe?
In a previous mail deckerego gave you some useful advice. It's actually
fairly easy, I'd recommend to just start working on it and look at the
examples. Good starting points are [1] and I think there would be some
similarities that may help you with the camel-irc component [2]. There
are others but this is simpler.
If you need help, feel free to ask,
Hadrian
[1] http://camel.apache.org/writing-components.html
[2] https://github.com/apache/camel/tree/trunk/components/camel-irc
On 01/27/2012 02:21 AM, Alex Anderson wrote:
> Hi Hadrian,
>
> I made a mock implementation of the Java serial API specifically for
> unit testing: https://github.com/frontlinesms/mock-serial
>
> Do you have any practical advice for developing components, or
> resources I should be reading?
>
> Thanks,
>
> Alex
>
>
> On 26 January 2012 21:22, Hadrian Zbarcea<hz...@gmail.com> wrote:
>> Alex, smslib is distributed under ALv2, which is great. I didn't check yet
>> if it's OSGi ready, we're looking for that too. All our components are now
>> OSGi ready. If smslib isn't we'll try to work with them to make it OSGi
>> ready or find another solution.
>>
>> The question I have for you is how to you envision the unit testing for this
>> component? Is there a way to have a mock service provider? We obviously
>> cannot afford using a real service for the unit tests.
>>
>> Cheers,
>> Hadrian
>>
>>
>> On 01/26/2012 09:21 AM, Alex Anderson wrote:
>>>
>>> I'm working on a Camel component for SMSLib (http://www.smslib.org).
>>> This is a Java library for communicating with mobile phones and modems
>>> via a serial connection to send and receive SMS messages using the
>>> Hayes (AT) command set.
>>>
>>> I have a working prototype - you can see the source at
>>> https://github.com/frontlinesms/camel-smslib
>>>
>>> I have some general worries regards best-practice for designing the
>>> Endpoint, Consumer and Producer for this component. I've not come
>>> across comprehensive documentation for implementing Endpoints etc.,
>>> and it's hard to know which other components would have a similar
>>> model to mine and therefore would be worth delving into the source of.
>>>
>>>
>>> Notes on serial devices
>>> -----------------------
>>> * before starting to send or receive messages through a device it must
>>> be initialised
>>> * initialisation can fail
>>>
>>>
>>> Endpoint
>>> --------
>>> Each Endpoint will refer to a serial port, with corresponding URIs, e.g.:
>>> * Windows: smslib:COM1
>>> * Linux: smslib:/dev/tty01
>>>
>>> When Endpoints are initially created, settings for the port (e.g. baud
>>> rate) are passed to it. Later we may want to create endpoints for the
>>> same port with different settings, but only if the original endpoint
>>> is no longer in use.
>>>
>>>
>>> Consumer
>>> --------
>>> There should be a maximum of 1 consumer per endpoint. The serial port
>>> must be polled to check for incoming SMS. Rather than storing the SMS
>>> within the Smslib service, I would like to pass them immediately
>>> upstream to the Consumer's Processor.
>>>
>>>
>>> Producer
>>> --------
>>> For my usage, I would like a single Producer per endpoint. This is
>>> primarily because when there are no active producers or consumers for
>>> an endpoint, the serial connection can be closed to allow its use by
>>> other programs. It may be reasonable for other uses to have multiple
>>> Producers for the same endpoint.
>>>
>>>
>>> Current status
>>> --------------
>>> The endpoint has a Thread (implemented in a class SmslibService) which
>>> controls the receiving from the serial connection - every 30 seconds
>>> the thread wakes and checks the modem for new incoming messages. This
>>> SmslibService keeps a reference to a Producer and a Consumer, and
>>> should shut down the serial connection when both Consumer and Producer
>>> are stopped.
>>>
>>> Trying to create more than one Producer or Consumer for an Endpoint
>>> will cause an Exception to be thrown.
>>>
>>> This causes problems when the settings used to create an endpoint
>>> initially are bad - there will be an Exception thrown in
>>> SmslibProducer.doStart()
>>>
>>>
>>> My Questions
>>> ------------
>>> * are there any good resources for writing Endpoints that I should be
>>> reading?
>>> * does anyone know of any similarly-modelled components whose source
>>> might provide guidance?
>>> * are there any patterns or base classes that I should obviously be
>>> using for my Component, Endpoint, Consumer or Producer
>>> implementations?
>>> * is there anyone else interested in this component who could cast an
>>> eye over the code?
>>
>>
>> --
>> Hadrian Zbarcea
>> Principal Software Architect
>> Talend, Inc
>> http://coders.talend.com/
>> http://camelbot.blogspot.com/
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: Component Design - SMSLib
Posted by Alex Anderson <al...@frontlinesms.com>.
Hi Hadrian,
I made a mock implementation of the Java serial API specifically for
unit testing: https://github.com/frontlinesms/mock-serial
Do you have any practical advice for developing components, or
resources I should be reading?
Thanks,
Alex
On 26 January 2012 21:22, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Alex, smslib is distributed under ALv2, which is great. I didn't check yet
> if it's OSGi ready, we're looking for that too. All our components are now
> OSGi ready. If smslib isn't we'll try to work with them to make it OSGi
> ready or find another solution.
>
> The question I have for you is how to you envision the unit testing for this
> component? Is there a way to have a mock service provider? We obviously
> cannot afford using a real service for the unit tests.
>
> Cheers,
> Hadrian
>
>
> On 01/26/2012 09:21 AM, Alex Anderson wrote:
>>
>> I'm working on a Camel component for SMSLib (http://www.smslib.org).
>> This is a Java library for communicating with mobile phones and modems
>> via a serial connection to send and receive SMS messages using the
>> Hayes (AT) command set.
>>
>> I have a working prototype - you can see the source at
>> https://github.com/frontlinesms/camel-smslib
>>
>> I have some general worries regards best-practice for designing the
>> Endpoint, Consumer and Producer for this component. I've not come
>> across comprehensive documentation for implementing Endpoints etc.,
>> and it's hard to know which other components would have a similar
>> model to mine and therefore would be worth delving into the source of.
>>
>>
>> Notes on serial devices
>> -----------------------
>> * before starting to send or receive messages through a device it must
>> be initialised
>> * initialisation can fail
>>
>>
>> Endpoint
>> --------
>> Each Endpoint will refer to a serial port, with corresponding URIs, e.g.:
>> * Windows: smslib:COM1
>> * Linux: smslib:/dev/tty01
>>
>> When Endpoints are initially created, settings for the port (e.g. baud
>> rate) are passed to it. Later we may want to create endpoints for the
>> same port with different settings, but only if the original endpoint
>> is no longer in use.
>>
>>
>> Consumer
>> --------
>> There should be a maximum of 1 consumer per endpoint. The serial port
>> must be polled to check for incoming SMS. Rather than storing the SMS
>> within the Smslib service, I would like to pass them immediately
>> upstream to the Consumer's Processor.
>>
>>
>> Producer
>> --------
>> For my usage, I would like a single Producer per endpoint. This is
>> primarily because when there are no active producers or consumers for
>> an endpoint, the serial connection can be closed to allow its use by
>> other programs. It may be reasonable for other uses to have multiple
>> Producers for the same endpoint.
>>
>>
>> Current status
>> --------------
>> The endpoint has a Thread (implemented in a class SmslibService) which
>> controls the receiving from the serial connection - every 30 seconds
>> the thread wakes and checks the modem for new incoming messages. This
>> SmslibService keeps a reference to a Producer and a Consumer, and
>> should shut down the serial connection when both Consumer and Producer
>> are stopped.
>>
>> Trying to create more than one Producer or Consumer for an Endpoint
>> will cause an Exception to be thrown.
>>
>> This causes problems when the settings used to create an endpoint
>> initially are bad - there will be an Exception thrown in
>> SmslibProducer.doStart()
>>
>>
>> My Questions
>> ------------
>> * are there any good resources for writing Endpoints that I should be
>> reading?
>> * does anyone know of any similarly-modelled components whose source
>> might provide guidance?
>> * are there any patterns or base classes that I should obviously be
>> using for my Component, Endpoint, Consumer or Producer
>> implementations?
>> * is there anyone else interested in this component who could cast an
>> eye over the code?
>
>
> --
> Hadrian Zbarcea
> Principal Software Architect
> Talend, Inc
> http://coders.talend.com/
> http://camelbot.blogspot.com/
Re: Component Design - SMSLib
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Alex, smslib is distributed under ALv2, which is great. I didn't check
yet if it's OSGi ready, we're looking for that too. All our components
are now OSGi ready. If smslib isn't we'll try to work with them to make
it OSGi ready or find another solution.
The question I have for you is how to you envision the unit testing for
this component? Is there a way to have a mock service provider? We
obviously cannot afford using a real service for the unit tests.
Cheers,
Hadrian
On 01/26/2012 09:21 AM, Alex Anderson wrote:
> I'm working on a Camel component for SMSLib (http://www.smslib.org).
> This is a Java library for communicating with mobile phones and modems
> via a serial connection to send and receive SMS messages using the
> Hayes (AT) command set.
>
> I have a working prototype - you can see the source at
> https://github.com/frontlinesms/camel-smslib
>
> I have some general worries regards best-practice for designing the
> Endpoint, Consumer and Producer for this component. I've not come
> across comprehensive documentation for implementing Endpoints etc.,
> and it's hard to know which other components would have a similar
> model to mine and therefore would be worth delving into the source of.
>
>
> Notes on serial devices
> -----------------------
> * before starting to send or receive messages through a device it must
> be initialised
> * initialisation can fail
>
>
> Endpoint
> --------
> Each Endpoint will refer to a serial port, with corresponding URIs, e.g.:
> * Windows: smslib:COM1
> * Linux: smslib:/dev/tty01
>
> When Endpoints are initially created, settings for the port (e.g. baud
> rate) are passed to it. Later we may want to create endpoints for the
> same port with different settings, but only if the original endpoint
> is no longer in use.
>
>
> Consumer
> --------
> There should be a maximum of 1 consumer per endpoint. The serial port
> must be polled to check for incoming SMS. Rather than storing the SMS
> within the Smslib service, I would like to pass them immediately
> upstream to the Consumer's Processor.
>
>
> Producer
> --------
> For my usage, I would like a single Producer per endpoint. This is
> primarily because when there are no active producers or consumers for
> an endpoint, the serial connection can be closed to allow its use by
> other programs. It may be reasonable for other uses to have multiple
> Producers for the same endpoint.
>
>
> Current status
> --------------
> The endpoint has a Thread (implemented in a class SmslibService) which
> controls the receiving from the serial connection - every 30 seconds
> the thread wakes and checks the modem for new incoming messages. This
> SmslibService keeps a reference to a Producer and a Consumer, and
> should shut down the serial connection when both Consumer and Producer
> are stopped.
>
> Trying to create more than one Producer or Consumer for an Endpoint
> will cause an Exception to be thrown.
>
> This causes problems when the settings used to create an endpoint
> initially are bad - there will be an Exception thrown in
> SmslibProducer.doStart()
>
>
> My Questions
> ------------
> * are there any good resources for writing Endpoints that I should be reading?
> * does anyone know of any similarly-modelled components whose source
> might provide guidance?
> * are there any patterns or base classes that I should obviously be
> using for my Component, Endpoint, Consumer or Producer
> implementations?
> * is there anyone else interested in this component who could cast an
> eye over the code?
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/