[Nmc-wg] Transport protocol

[Nina Jeliazkova]

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