Too complex SMPP library

[GoogleCodeExporter]

I strongly recommend you to improve OOP aspect of your library to hide all
complexity of smpp from library user.

I've writed own smpp library for company inner use. This is example of
sending message to SMSC:

try {
            SMPPClient client = new SMPPClientImpl(new MessageHandler() {
                public void handle(Message message) throws
ProcessingFailedException {
                    System.out.println("incoming message received");
                }

                public void deliveredToDest(String messageId) {
                    System.out.println("message delivered to user");
                }
            }, "localhost", 9999, ConnectionType.TRANSCEIVER, "mysysid",
                    "mypass", "test", (short) 0, (short) 0, null, false);
            String messageId = client.send(new Message("src", "dest",
"hello"));
            System.out.println("message delivered to smsc");
            client.stop();
        } catch (SMPPException e) {
            e.printStackTrace();
        }

Original issue reported on code.google.com by bulat...@gmail.com on 28 Nov 2008 at 12:03

[GoogleCodeExporter]

Hi, I think we have common vision here.

You might see the org.jsmpp.examples.SimpleSubmitExample, it's similar to your 
code.
It just jsmpp has a lot of parameter when sending message. Yours is more 
simple, I 
want it jsmpp more simple too. But have you see the SMPP Specification? Message 
submission (SUBMIT_SM) has alot parameter, you only use 3 parameters (such as 
src, 
dest, messages), what should I do with the rest parameters? Do I have to leave 
it as 
default? So how if I need it non-default value? The possible things is creating 
2 
method for message submission, the simple one (common value should be set by 
default) 
and the complete one. But, what value should I set as default value?

Thx

Original comment by uuda...@gmail.com on 28 Nov 2008 at 2:45

[GoogleCodeExporter]

I've created two level of abstraction in my library. One is a SMPPSession and
SMPPClient over it. SMPPSession handles session lifetime control and has only 
one
send method: PDU send(PDU pdu). SMPPSession also forces user to implement 
PDUHandler
interface and implement  public PDU received(PDU pdu) method.
SMPPClient simplify the SMPP library usage by providing send(Message) method 
where
message is a simple POJO consist of Source, Destination and Text fields. 
SMPPClient
additionally provides default error handling feature: identify error returned, 
then
decide whether it should try again send message and how long it should sleep 
before
second try etc.
SMPPClient provides Message dividing functionality. It's controlled wether large
message should be sent by Message Payload TLV or by small part through sar* 
TLVs or
using UDH. It's very helpful.
Our platform has 20 connections to different SMSCs, i.e. sell phone operators. 
Almost
all SubmitSM and DeliverSM parameters set to default or NULL values. That is 
why i
make SMPPClient so stupid simple.
I cann't reveal details, cause i'm working in commercial company.

P.S. Sorry for my english. It's not my native language. But i hope you found my 
notes
helpful.

Original comment by bulat...@gmail.com on 29 Nov 2008 at 2:19

[GoogleCodeExporter]

Hi,

I agree with the SMPPClient, provides message dividing functionality. Past time 
ago, 
I've been thinking to do that, but in the end at the moment, jsmpp will keep as 
protocol implementation at this time, all parameters option is on users 
control. Not 
wrapping some functionality such as automatic message dividing.
And the best way to do this is by creating a layer on top jsmpp that wrap this, 
not 
the jsmpp (at least for now), you can set the commons value so you only need to 
specify only the dynamic values such as dest_addr, source_addr and message.

Thx

Original comment by uuda...@gmail.com on 29 Nov 2008 at 3:49

• Changed state: Done