[Nmc-wg] Transport protocol

[Jason Zurawski]

To wrap this up:

  - Base remains as it is with no mention of the underlying protocol
  - Extensions that do need to mention this detail (e.g. AA), will do so 
when required
  - We note SOAP over HTTP as our use case and explain this well.  We 
can allude to others being possible candidates (don't go into detail).

Is this fair?

-jason

On 2/19/10 10:56 AM, Jeff W. Boote wrote:
> Then I think we are all in violent agreement here.
>
> My one caveat is that I don't think we should put effort/time into
> specifying how NMC protocols are bound to other transports at this time.
> Lets get the soap/http one done first.
>
> jeff
>
> On Feb 19, 2010, at 2:27 AM, Michael Bischoff wrote:
>
>>     This sounds more like you agree with what I just said... So, I'm
>>     pretty sure I don't understand your point.
>>
>>
>> I'll try to clarify;
>>
>> In an abstract formal way what I'm trying to say is:
>> you are free to choose any transport, (NMC is at it's core protocol
>> agnostic)
>> but:
>> - if you choose SOAP you must adhere to set of rules x as specified by
>> the binding document to be NMC compliant
>> - if you choose HTTP-POST you must adhere to set of rules Y as
>> specified by the binding document to be NMC compliant
>> ... where there are maintenance updates for future, at this time
>> unknown or unforeseen transport.
>>
>> This mirrors SAML which at it's core is protocol agnostic, so you have
>> freedom to choose whatever transport you want.
>> But if you choose SOAP you MUST adhere to rules defined in
>> http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
>>
>> The rationale for this is what I've have been trying to explain, but
>> perhaps it's best to quote others:
>>
>> The reason for at it's core being protocol agnostic:
>> Jason: "The strength of this work should lie in the specification and
>> meaning of the XML - if it travels over pigeons or
>> wires should not be a primary concern."
>> Nina: "There are number of (non-perfsonar) services nowadays that
>> offer both SOAP and REST interface. The goal
>> of this duality is not interoperability, but flexibility and ease of
>> adoption. A service can offer both, and let the clients
>> decide which one to use. This might be a reasonable goal for NMC."
>> I would add; that if say, for example,
>> spdy(http://dev.chromium.org/spdy/spdy-whitepaper) would ever catch on we
>> wouldn't want us to be tied to http....
>>
>> The reason for being protocol specific is that this ensures
>> interoperability, but this conflicts obviously with the former.
>> The typical way to solve this conflict is to separate the two leaving
>> only the protocol specific bits to be rewritten should
>> a new transport come along. This solves the forward compatibility
>> problem, but doesn't solve the situation when there
>> is not a single transport being embraced(a situation that will never
>> exist in my opinion, for communication between
>> two services hosted on the same node if performance is critical one
>> would always opt for IPC/shared memory). That
>> situation can be solved by having multiply optinal protocol specific
>> bits. aka multiply bindings.
>>
>> This is also what I think Roman was getting at;
>>
>>     I agree. I would not put such specifics of the WS in base and even
>>     extension documents. Maybe third type of document describing an
>>     implementation could have them (I can imagine that pS services
>>     have more
>>     interfaces than one - SOAP, REST, etc. - in the future )?
>>
>>     - base doc
>>     -- extension doc (e.g. for MA)
>>     --- transport implementation doc (including, for example WS info)
>>
>>     (lower level doc refers to upper level doc)
>>
>>
>> Like I said in the conference call, and I think we all agree is the
>> base document should be protocol agnostic and as that
>> is our main concern right now perhaps. Beyond that I'd like to keep
>> the option open, so it's best to let this sudder, and
>> revisit this at a later time. / put this on the back burner. (feel
>> free to speak up if you disagree)
>>
>> - Michael
>>
>> On Fri, Feb 19, 2010 at 7:18 AM, Nina Jeliazkova <nina at acad.bg
>> <mailto:nina at acad.bg>> wrote:
>>
>>     Jeff W.Boote wrote:
>>>     A protocol specification should indicate more than the valid
>>>     messages. It should also define the context in which those
>>>     messages are valid. If it is possible to cleanly separate the
>>>     messages from some of the underlying support we receive from
>>>     soap/http than we should structure it that way. (I believe to a
>>>     large degree this is possible.)
>>>
>>>     But, I also think it is absolutely reasonable for us to indicate
>>>     specifically which lower layer transport we are using once we get
>>>     to some of the more intricate issues. For example, I would much
>>>     rather depend on soap and/or http for authentication headers than
>>>     define that in our messages. If we separate this cleanly, I think
>>>     we can indicate that we are only doing a 'full' protocol
>>>     specification for using these messages in a soap/http context and
>>>     that future protocol specifications can indicate how they are
>>>     applicable for other transports.
>>>
>>>     Will this strategy work for people?
>>     Perhaps indeed the protocol should be documented on different
>>     levels. My view is currently
>>     - I am reluctant of locking everything down to SOAP, on the basis
>>     of existing implementation.
>>     - There are number of (non-perfsonar) services nowadays that offer
>>     both SOAP and REST interface. The goal of this duality is not
>>     interoperability, but flexibility and ease of adoption. A service
>>     can offer both, and let the clients decide which one to use. This
>>     might be a reasonable goal for NMC.
>>     - Security related (and perhaps other) solutions may rely on
>>     transport protocol, and this should be documented , yet not
>>     locking the possible solutions to a single protocol.
>>
>>     Best regards,
>>     Nina
>>>
>>>     On Feb 18, 2010, at 4:44 PM, Michael Bischoff wrote:
>>>
>>>>         If implementation A uses SOAP based webservices and
>>>>
>>>>         implementation B uses RESTful webservices they do not
>>>>         operate. So I
>>>>
>>>>         think it should be specified, preferably in a different (short)
>>>>
>>>>         document.
>>>>
>>>>
>>>>     On that basis I disagree. There might well be a implementation C
>>>>     that
>>>>     provides both a SOAP and RESTfull interface. Since that just
>>>>     starts the
>>>>     best of breed game as far as transport is concerned. Freedom here
>>>>     promotes adoption.
>>>
>>>     I do not believe this is true, but perhaps I don't understand
>>>     what you are trying to say. In my opinion, freedom to 'do it
>>>     however you want' does not promote adoption, it hinders
>>>     interoperability which in turn makes development difficult and
>>>     implementations buggy. This hinders adoption in the long run.
>>>
>>>>     My issue with not specifying it is that there might be two
>>>>     implementations
>>>>     who both have a SOAP-based interface but bind it differently.
>>>>     That leads to
>>>>     a bickering game, where no one benefits - which is a treat to
>>>>     adoption
>>>
>>>     This sounds more like you agree with what I just said... So, I'm
>>>     pretty sure I don't understand your point.
>>>
>>>     jeff
>>>
>>>>
>>>>     - Michael
>>>>
>>>>     On Thu, Feb 18, 2010 at 8:57 PM, Freek Dijkstra
>>>>     <Freek.Dijkstra at sara.nl <mailto:Freek.Dijkstra at sara.nl>> wrote:
>>>>
>>>>         Jason wrote:
>>>>
>>>>         > Specifying details regarding a specific implementation of
>>>>         an NMC-
>>>>         > capable
>>>>         > framework (like perfSONAR or something completely
>>>>         different) does not
>>>>         > seem correct to me. I still believe that we do not want to box
>>>>         > ourselves in by saying "use SOAP over HTTP because that's
>>>>         what the
>>>>         > first
>>>>         > generation used". The strength of this work should lie in the
>>>>         > specification and meaning of the XML
>>>>
>>>>         I agree with your second statement. However, I also believe
>>>>         that our
>>>>         aim is to define a standard so that different
>>>>         implementations can work
>>>>         together. If implementation A uses SOAP based webservices and
>>>>         implementation B uses RESTful webservices they do not
>>>>         operate. So I
>>>>         think it should be specified, preferably in a different (short)
>>>>         document. Otherwise you may just as well argue that "you do
>>>>         not need
>>>>         to specify the XML syntax, just because that's what the first
>>>>         generation uses"
>>>>
>>>>         Regards,
>>>>         Freek