Disclaimer: These archives are mirrored from smsforum.net in 2007 before the forum got closed. Please only part of the forum is available here.
For any clarifications regarding these archives you can contact us at http://www.telecomspace.com/contact.


+  SMS Forum Online Discussion
|-+  Protocols
| |-+  MMAP-Related (Moderator: SMS Forum Support)
| | |-+  Why not use SOAP for SMAP messaging?
« previous next »
Pages: [1] Go Down Print
Author Topic: Why not use SOAP for SMAP messaging?  (Read 2188 times)
Offline Offline

Posts: 4

« on: December 18, 2001, 20:29:46 UTC »

"It is proposed to define a new text protocol to support application access to message centers and/or messaging gateway nodes over HTTP and other Web protocols.".

The above is a quote from the SMAP V1.0 Draft09 spec. Can I suggest that the W3C-sponsored SOAP protocol (see http://www.w3c.org/TR/SOAP) be used as the message services layer for SMAP, and that the evolution of SOAP by the W3C be leveraged for SMAP purposes.

SOAP, which is the underlying technology for Web Services, is XML-centric and transport-layer independent. HTTP and SMTP are the most widely supported, but any transport can be used. I believe that SOAP meets the requirements as documented in Section 2 "Design Principles" of the SMAP spec.
The SOAP Envelope, specifically the SOAP Header, is extensible for usage-specific information and would be appropriate for SMAP control information. The short message
text would simply map to the SOAP Body element.

Using SOAP would arguably be more beneficial to implementation developers, adopter organisations, and SMS users and service providers.

For developers, there already exists widespread support for SOAP toolsets and implementations on a variety of platforms - using an appropriate offering as a base for SMAP aupport should significantly decrease time to market.

For organisations, adherence to SOAP potentially makes adoption more attractive because it aids in common application access from disparate platforms. Providing an access method for every device and platform is not necessary.

For SMS users and service providers, support for SOAP by an SMSC, or an SMAP Gateway, opens the interesting possibility of access to the same set of services which are available to other web clients.

Finally, can I also suggest perusal of the ebXML Message Service Specification (see http://www.ebxml.org) to examine how SOAP has been used to carry XML messages which exchange higher layer information.

Neil Coleman
Insession Technologies
« Last Edit: January 01, 1970, 00:00:00 UTC by 1025067600 » Logged
SMS Forum Support
SMS Forum Support
Sr. Member
Offline Offline

Posts: 1754

« Reply #1 on: December 19, 2001, 18:20:32 UTC »

SOAP is a consideration. In fact the hope is that several different transports will be recommended to suit a wider range of applications.
« Last Edit: January 01, 1970, 00:00:00 UTC by 1025067600 » Logged

   Cormac Long
   Webmaster & Technical Enquiry Moderator,
   SMS Forum

« Reply #2 on: December 27, 2001, 09:40:28 UTC »

From an application developer's point of view, the less transports are specified the better. SOAP would be my preferred choice.
« Last Edit: January 01, 1970, 00:00:00 UTC by 1025067600 » Logged
Jr. Member
Offline Offline

Posts: 6

« Reply #3 on: March 06, 2002, 19:57:16 UTC »

I would also support the use of a SOAP transport.  We are getting a number of enquiries from corporporate users who already are familiar with SOAP and want to connect to our SMSC via a SOAP type interface.
« Last Edit: January 01, 1970, 00:00:00 UTC by 1025067600 » Logged
Offline Offline

Posts: 2

« Reply #4 on: May 29, 2002, 06:56:32 UTC »

We have been proposing XML for SMS transmission of MO, MT and SR for 2 years now, and did not meet -any- problem for implementation of client interfaces on customer side since. But I agree, the most important is to cover the functionnalities that were not foreseen in GSM 3.39 protocols (premium, etc).
« Last Edit: January 01, 1970, 00:00:00 UTC by 1025067600 » Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Login with username, password and session length