[Nmc-wg] Transport protocol

[Jeff W. Boote]

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> 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 
>>> > 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
>>>
>>>
>>> _______________________________________________
>>> Nmc-wg mailing list
>>> Nmc-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>>
>>> _______________________________________________
>>> Nmc-wg mailing list
>>> Nmc-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>
>>
>> _______________________________________________
>> Nmc-wg mailing list
>> Nmc-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nmc-wg/attachments/20100219/d61aa792/attachment-0001.html