While preparing the proposal I have done some initial experimental work on the SMPP transport support.

I wrote a experimental InOnly SMPP transport for Axis2 and use it to invoke a service

Here is what i did.

I wrote  SMPP transpot Listener using the jsmpp suppport .And Used SMSCSim to Simulate the ShotMessage Service center

Then i used a Message Format of "<ServiceName> : <OprationName> : <Parameter 1>:<Parameter 2>: ....:<Parameter N> "
like format .

So when a SMS comes it Builds the MessageContext using above paprameters and inject to the AxisEngine

Thank you Sanranga for pointing me to the SMSCSim which is very useful in my initial testing.

I would like to get more feed back from you regarding how this should be implemented and and how to iteratively improve and develop this.

following is how the transport receiver was looked like in the Axis2 Configuration

<transportReceiver name="sms"  class="sample.api.smpp.SMPPReceiver">
        <parameter name="host"></parameter>
        <parameter name="port">2775</parameter>
        <parameter name="systemType">cp</parameter>
        <parameter name="systemId">smppclient1</parameter>
        <parameter name="password">password</parameter>

thank you,

On Mon, Mar 30, 2009 at 4:12 PM, Charith Wickramarachchi <charith.dhanushka@gmail.com> wrote:

Apache ServiceMix have given support for SMPP using a SMPP component [1]

I think that code[2] will be useful to me as a reference.

And i have updated my proposal to the New Apache Proposal format It can be found at


your feedback in this is highly appreciated.

[1] http://servicemix.apache.org/servicemix-smpp.html

[2]  https://svn.apache.org/repos/asf/servicemix/components/bindings/servicemix-smpp

On Fri, Mar 27, 2009 at 10:32 AM, Saliya Ekanayake <saliya@wso2.com> wrote:

Have a look at [1] for a sample scenario with SMS and [2] for some insight into sending SMS based on XML. IMHO I guess it would be nice to have application level reliability in the case of notifying a user on an event.

[1] http://www.pymma.com/eng/content/download/620/3501/file/Soap%20Header%20management%20with%20JBI%20and%20Open%20ESB.pdf

[2] http://www.ibm.com/developerworks/xml/library/x-tipsms1.html


Charith Wickramarachchi wrote:

I'm currently evaluating  open source libraries that support SMPP and debuging the Axis2 Http transport. I'm currently Woking with jsmpp.While reading the SMPP protocal specification [1] and working with jsmpp [2] I found out that In SMPP there is a way to archive reliability by having a delevery report machanishm . (Note that this is Application layer reliability) . But this feature may be avalible or not depending on the SMSC ( Short Message Service Center* *) that the transport is connecting.
So in Axis2 and Aynapse domain does application level reliability in SMS transport add value? Any thoghts?

And aslo i would be glad  to get some feed back on realworld senarios that users  will use this transport with Axis2 and Synapse.

thank you,
 [1] http://www.smsforum.net/SMPP_v3_4_Issue1_2.zip

[2] http://code.google.com/p/jsmpp/

On Mon, Mar 23, 2009 at 9:12 AM, Charith Wickramarachchi <charith.dhanushka@gmail.com <mailto:charith.dhanushka@gmail.com>> wrote:


   Yes i m also think that the message size is a major design issue
   in this.
   I was thinking of limiting the payload size.Because IMO most of
   the practical scenarios the maximum payload size given in SMPP
   will be sufficient.

   I think aggregating messages will be harder since we have no
   control over the other side.

   I hope i'll be able to get you ideas in the future while i m doing
   the project        
   thank you,

   On Sun, Mar 22, 2009 at 8:36 PM, Ajith Ranabahu
   <ajith.ranabahu@gmail.com <mailto:ajith.ranabahu@gmail.com>> wrote:

       Hi Charith,

       This is a very good idea indeed. As many pointed out, there are
       immense benefits in doing this and it is indeed great for a GSoC.

       I think Sagara has a good point. Since there is a character
       limit per
       message you need to think about how larger payloads can be
       For cell phones I remember there was a format where you can
       send one
       single message consisting of up to some max number of separate
       messages. I remember this to be Nokia specific thing since they
       appeared messed up in the old Ericcsson I used to have.[ Am
       this mail offline so can't google :(  Not sure whether it was
       as a standard ] . You can definitely take a look at such things.
       Ultimately if you can comeup with a protocol binding (such as
       the WSDL
       bindings for HTTP or SMTP) that would be an ideal outcome. Such a
       binding would at least become a de-facto standard if you are
       successful :)

       Guys that have more knowledge in SMS can help out here, Can SMS
       transfer binary ? [I doubt whether it can. It seemed to be only
       ASCII]. If so you can think of more space efficient XML
       such as fastinfoset.

       Just some ideas


       2009/3/19 Sagara Gunathunga <sagara.gunathunga@gmail.com

       > Hi Charith,
       > It always  better to implement for a  specification instead
       of  a
       > specific implementation such as SMSlib ,  Initially  you can
       set up
       > SMPPSim for  testing  it just like running a HTTP server.
       > Any way what is your plan to handle size of the the payload
       messages ..?
       > This is not a problem with other protocols like  HTTP,JMS or
       mail but
       > SMS  you need to think about the size of the massage.
        According to
       > the SMPP spec "short_message size" is limited to 254 Octet
       > also this value may be vary with networks. pay your
       attention for
       > possible solution for this.
       > Thanks ,

       Ajith Ranabahu

       Reading, after a certain age, diverts the mind too much from its
       creative pursuits. Any man who reads too much and uses his own
       too little falls into lazy habits of thinking - Albert Einstein

   --    Charith Dhanushka Wickramarachchi

Charith Dhanushka Wickramarachchi

To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org

Charith Dhanushka Wickramarachchi

Charith Dhanushka Wickramarachchi