19 Feb
2010
19 Feb
'10
6:18 a.m.
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@sara.nl <mailto:Freek.Dijkstra@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@ogf.org <mailto:Nmc-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/nmc-wg >> >> >> _______________________________________________ >> Nmc-wg mailing list >> Nmc-wg@ogf.org <mailto:Nmc-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/nmc-wg > > ------------------------------------------------------------------------ > > _______________________________________________ > Nmc-wg mailing list > Nmc-wg@ogf.org > http://www.ogf.org/mailman/listinfo/nmc-wg >