Subject: [drinks] WG poll on transport protocol

From: "Alexander Mayrhofer" <[email-masked]>
Date: Fri, 26 Jun 2009 15:29:24 +0200

All,

The chairs would like to seek some input from the list on the practical
options the WG now needs to confront on what is the most appropriate,
but
more importantly,  what is also most deployable transport protocol for
DRINKS.

The protocol design team has made good progress towards a first draft 
of the DRINKS protocol, and the issue of which transport protocol to
proceed with was discussed during several conference calls.

The chairs wish to formally reach concensus on how the group
should proceed regarding that protocol transport issue.

Discussions during our face to face meetings have indicated that
a SOAP/XML based approach would fit most of the various vendors
and service providers that would potentially deploy a DRINKS protocol. 

http://en.wikipedia.org/wiki/SOAP

The design team been advised that it might also be useful to look at
REST-like
protocols as REST design principles for WEB protocols overcome many of
the
known limitations and interoperability problems associated with SOAP.

There are arguments that a RESTful Web Services approach for a DRINKS
protocol from a provisioning would not only be appropriate for a Client
2
Server but also Server 2 Server approaches as well. 

It should be understood that REST is not a protocol but a series of
design
principals. 

http://en.wikipedia.org/wiki/REST

The central counter argument is that SOAP is the most universally
deployed
data exchange mechanism out there and that anecdotal evidence indicates
that
SOAP is the predominant form of transport mechanism in current use among
SSP's and will be for the foreseeable future.

The design team has currently concluded that it would be beneficial to
seperate the definition of the data object from the underlying 
transport protocol to permit defining more than one transport, if 
necessary.

In order to document WG consensus on this issue the chairs would like to
poll the WG on the following questions:

It is very important that as many members of the list participate in
this
poll as possible. Please provide feedback to each question as fully as
possible.

General questions regarding deployed transport protocols:

1. How many folks have SOAP implementations in their OSS-BSS systems for
the
kinds of protocols DRINKS is looking out? 

2. How many folks have a REST-like implementations in their OSS-BSS
systems
for the kinds of protocols DRINKS is looking out?

3. In general what data model or protocol properties do your
organizations
ultimately lean towards - SOAP vs. REST? Other?

4. What are the specific applications that SSP are looking for DRINKS to
enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ??  

Questions to reach WG concensus on:

3. Do you agree that the design team should define the architecture / 
data model independently from the definition of a potential 
transport protocol? (as far as possible)

4. Given the goal to define the data model outside its transport, do you
prefer the group to 
	A. Define a SOAP based transport protocol and if anyone is
interested they can work on a RESTful version? 
	B. The WG try and do both? 

Please provide feedback before July 8th, if possible.

Thanks,

Richard & Alex

---

From: Andrew Newton <[email-masked]>
Date: Fri, 26 Jun 2009 16:40:44 -0400

> SSP's and will be for the foreseeable future.

Not that I have a dog in this fight, but I seriously doubt that first  
part is true.

-andy

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 26 Jun 2009 22:21:31 +0100

On Fri, Jun 26, 2009 at 2:29 PM, Alexander
Mayrhofer<[email-masked]> wrote:

> deployed data exchange mechanism out there

are you sure? I don't think i've needed to touch a SOAP API since
perhaps 2003.  Every single API around these days seems ot be RESTful
...

  http://www.programmableweb.com/apis/directory

But then, i've been working in an industry that doesn't move at
0.00034km/h below snails pace since then.

SOAP appears to be popular in corporate cultures as it is all
"point-clickey".  WSDL allows stub generation, integration is all very
pretty and useful if the developer has no clue what they're doing, but
as soon as you grind down to the protocol, it's seriously bloated and
relies on large libraries to do all the voodoo for you.  WADL now can
provide similar functionallity to WSDL, so i fail to see any excuses
for using SOAP anymore.

on a more serious practical note, people commonly stumble on using
REST over SOAP because they don't see the equvilent of WS-Transactions
and WS-Notifications in REST.  That doesn't mean you can't achieve the
same results, just it's not a "primitive" of the protocol like it is
in SOAP.

> kinds of protocols DRINKS is looking out?

probably a large number of the old-school carriers and telcos.

> for the kinds of protocols DRINKS is looking out?

some do, for sure (we do), and i know of at least one multi-national
voice carrier than does.  The rest of the interwebs seem to prefer it,
too.

> ultimately lean towards - SOAP vs. REST? Other?

REST

> enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ??

SIP inteconnection.

> transport protocol? (as far as possible)

obviously, to a degree.

While sending SOAP messages over SMTP seems "cool", and i'm sure it's
got a use, i frankly couldn't care less about it :-)

>        B. The WG try and do both?

putting my pragmatic hat on for a second, i'd prefer (A) over (B) if
the WG has no REST experience - It's harder to get SOAP wrong, as it's
already wrong -  otherwise, i'd prefer C: REST only.

 ~ Theo

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 26 Jun 2009 18:12:07 -0400

WG Chair HAT off. 

>  1. How many folks have SOAP implementations in their OSS-BSS systems

As far as I have been able to tell the vast majority of Global
Telecommunications firms I have personally consulted with and for and other
potential SSP's have formalized their Data Exchange Mechanisms on SOAP based
transport mechanisms. Teleco firms are traditionally very very conservative
and DRINKS is not exactly a WEB 2.0 like application.

>  systems for the kinds of protocols DRINKS is looking out?

I know of NO telecommunications OSS-BSS systems that currently use REST like
systems for data provisioning. 

>  organizations ultimately lean towards - SOAP vs. REST? Other?

In the majority of telecommunications I am acquainted with SOAP is the
current flavor dejure though there are provisioning systems that I could
describe involving Local Number Portability that have not been fundamentally
updated in decades. Of course TELEX is still in wide deployment as well as
Frame Relay, ATM.

>  
>  4. What are the specific applications that SSP are looking for DRINKS
>  to  enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ??

All of the above and realtime video point to point using E.164 addressing.

>  transport protocol? (as far as possible)

Yes.

>  
>  4. Given the goal to define the data model outside its transport, do
>  you prefer the group to

Option A. 

I do not believe the WG can do both though if anyone want to do B they are
more than welcome to do so.  PLUS IMHO any SOAP version MUST be a Proposed
Standard or no vendor will seriously adopt it except under severe threat of
loss of revenue. Any idea that a SOAP based transport protocol for DRINKS
would be classified 'Experimental' is completely unacceptable.

>  _______________________________________________
>  drinks mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/drinks

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 30 Jun 2009 10:09:45 -0400

KJC>> My $.02.  (I'm re-sending this due to mailing list admin.  You may not have received the first attempt.)

KJC>> Preamble:  This discussion about SOAP or REST is a diversion, imo.  When it comes down to it I would work with either.  But I vote for SOAP for now, reasons below.  The much more important and difficult discussion should be around the necessary operations and data model and peering ecosystem.  But since SOAP/REST is what we've chosen to focus on in this email thread, here goes.... I'm adding in some technical details here in this response, because talking about this decision purely in the abstract does not do it justice.

KJC>> From the all important *practical/business* perspective, SOAP is on the very very short list of B-to-B de-facto API standards at this point in time.  REST is *probably* not on that list *yet*, imo.  But REST is definitely a very nice and elegant set of architectural principles and approach.  And some or all of these principles are applicable in general, even if the delivery envelope is SOAP (idempotence of PUT and DELETE, stateless operations, simplicity, brevity, separation of form and function, etc).  And the common instantiation of REST that specifies the use of URIs for identity and type and form, TCP for transport, HTTP for envelope and, HTTP GET/POST/PUT/DELETE for operation/action, is a very elegant and Web oriented approach, albeit a somewhat less practical one at this point in time.  As a software developer I very very much appreciate REST, but as a business person I like SOAP at this point in time.  It's not fun making a trade-off like this, I wish I was still in graduate school.  :-).

KJC>> Add me to that list.  When specifying a B-to-B application over the internet, it is easy to get agreement on and adoption of SOAP (sort of like when selecting a relational DB for an enterprise application it's easy to get agreement on Oracle).  SOAP, and "simple" XML over TCP, are the de-facto standards for these types of apps, based on the various projects I've been exposed to over the past several years.  Prior to the past several years, CORBA was very common (I loved CORBA, :-)), prior to that, home grown text delimiting over TCP was very common (that was fine as well).  And-on-and-on-and-on.  "Technology thrashing" is the term I like, costing companies millions of $ to constantly change, adapt, re-train, etc.  But I digress.  SOAP is undoubtedly one of *the* (if not *the* 1) de-facto standards for these types of applications at this point in time.

KJC>> None that I know of.  But there may be.  And there would be nothing wrong with that from a *technology* perspective.  But a *practical* *business* perspective that necessitates adoption is another matter.

KJC>> SOAP for now, because that is most practical from a business perspective.  But REST has very good technical merits, imo.

KJC>>  All of the above.

KJC>>  Most definitely.  I am espousing this approach, which has been successfully applied in other IETF RFCs.  However, there are practical side affects of this.  Most importantly, the data model must be designed to not prevent the specification of multiple envelopes/architectures, particularly those like REST that impose an approach to Identity (URIs with embedded synthetic keys), Action (HTTP's PUT, GET, POST, DELETE), Type (also embedded in the URIs), idempotence, etc.  As specific examples, (1) REST APIs are often/usually built on the assumption that a URI can be used as object identity where any subpart of the URI can be an object identifier, http://adgfadvs.com/serviceArea/3987/17039871234), and (2) that the supported operations on any object type are *at most* DELETE, PUT, POST, GET.  Meaning, respectively, that object identity cannot be a composite business key, and that the action/operation should not be embedded as a structure or element in the data model.  Both of these requirements of REST will have notable side affects on the structure of the data model.

KJC>> A, at a minimum.  As a software developer, I'm interested in B, but as a business person I am not interested in B at this point in time.  It's not fun making a trade-off like this, I wish I was still in graduate school.  :-).

Thanks,

Richard & Alex

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Jun 2009 17:50:03 -0400

KJC>> My $.02.

KJC>>  All of the above.

   

Thanks,

Richard & Alex