Charith,
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
Thanks,
Saliya
Charith Wickramarachchi wrote:
Hi,
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,
Charith
[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
<[email protected] <mailto:[email protected]>> wrote:
Hi,
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,
Charith
On Sun, Mar 22, 2009 at 8:36 PM, Ajith Ranabahu
<[email protected] <mailto:[email protected]>> 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
transfered.
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
writing
this mail offline so can't google :( Not sure whether it was
adopted
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
serializations
such as fastinfoset.
Just some ideas
Ajith
2009/3/19 Sagara Gunathunga <[email protected]
<mailto:[email protected]>>:
> 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
String,
> 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
brain
too little falls into lazy habits of thinking - Albert Einstein
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
