Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 70551 invoked from network); 27 Mar 2009 03:03:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 Mar 2009 03:03:59 -0000 Received: (qmail 48587 invoked by uid 500); 27 Mar 2009 03:03:58 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 48501 invoked by uid 500); 27 Mar 2009 03:03:58 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 48492 invoked by uid 99); 27 Mar 2009 03:03:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Mar 2009 03:03:58 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of charith.dhanushka@gmail.com designates 74.125.92.150 as permitted sender) Received: from [74.125.92.150] (HELO qw-out-1920.google.com) (74.125.92.150) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Mar 2009 03:03:50 +0000 Received: by qw-out-1920.google.com with SMTP id 5so735728qwc.28 for ; Thu, 26 Mar 2009 20:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nmujy51sV5f1+9vqZ262muWum/JzklWaWIpFNSDGhvI=; b=h6clRgOh3RkIHxK98gNYRsR+LbMdkhd+O6LE6WaPOenh0cOzGqgRdqVnH/UPAdvvyC +wWB9v71mDKVtw1upN5A9mN3Xe2HlDpsjwC8bulSWnntj42kDJSF91dY0C14zp5gEfGY THLWXSfJd0HYOaK25KMbCTPVBl1YnOPZ5YS8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YoyE08tmrjcRWOs0IxK8gk/9LovFX+2ECvPCRwDJRaA1urnmWnfuQavlDw+Fi/A9+A WcYSPf9BBtO4AyFMLbu/s0da/IsOv02YgX9AbKEBgjhzIH8JmSLClccooxJmP7p0udpB Notz7ubmUgn/ECFfK13vq+QQrCAzMRodGmxV4= MIME-Version: 1.0 Received: by 10.220.95.202 with SMTP id e10mr528813vcn.12.1238123007934; Thu, 26 Mar 2009 20:03:27 -0700 (PDT) In-Reply-To: References: <12f870d60903180833h72b0be68k4be0a6751021f45@mail.gmail.com> <49C1B23C.5010009@gmail.com> <672a01200903182207g5421bc5dkb7538e0ff371f07b@mail.gmail.com> <474d01b00903190110r2a4e07ddsfca1d819316cc3f0@mail.gmail.com> Date: Fri, 27 Mar 2009 08:33:27 +0530 Message-ID: Subject: Re: [Axis2] SMS transport for axis2 From: Charith Wickramarachchi To: axis-dev@ws.apache.org Cc: dev@synapse.apache.org Content-Type: multipart/alternative; boundary=0016e64eacb413825a046610fac0 X-Virus-Checked: Checked by ClamAV on apache.org --0016e64eacb413825a046610fac0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 < charith.dhanushka@gmail.com> 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 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 : >> > 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/ --0016e64eacb413825a046610fac0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm currently evaluating=A0 open source libraries that suppo= rt SMPP and debuging the Axis2 Http transport. I'm currently Woking wit= h 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 SM= SC ( Short Message Service Center ) that the transport is connecting= .=A0

So in Axis2 and Aynapse domain does application level reliability in SM= S transport add value? Any thoghts?

And aslo i would be glad=A0 to g= et some feed back on realworld senarios that users=A0 will use this transpo= rt with Axis2 and Synapse.

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

[2] http://code.goo= gle.com/p/jsmpp/


On Mon, Mar 23, 2009 at 9:12 AM, Charith= Wickramarachchi <charith.dhanushka@gmail.com> 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 o= f the practical scenarios the maximum payload size given in SMPP will be su= fficient.

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

I hope i'll be able to get you ideas in the f= uture while i m doing the project=A0 =A0 =A0 =A0 =A0

thank you,
= Charith



On Sun, Mar 22, 2009 at 8:36 PM, Ajith R= anabahu <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 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 :( =A0Not 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 <sagara.gunathunga@gmail.com>:
> Hi Charith,
> It always =A0better to implement for a =A0specification instead of =A0= a
> specific implementation such as SMSlib , =A0Initially =A0you can set u= p
> SMPPSim for =A0testing =A0it 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 =A0HTTP,JMS or mail bu= t
> SMS =A0you need to think about the size of the massage. =A0According t= o
> the SMPP spec "short_message size" is limited to 254 Octet S= tring,
> 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



<= /div>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.= blogspot.com/




--
Charith Dha= nushka Wickramarachchi
http= ://charithwiki.blogspot.com/

--0016e64eacb413825a046610fac0--