[Nmc-wg] Transport protocol

Jeff W.Boote boote at internet2.edu
Thu Feb 18 18:04:17 CST 2010


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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nmc-wg/attachments/20100218/35449efa/attachment.html 


More information about the Nmc-wg mailing list