Re: [Nmc-wg] Transport protocol
Michael Bischoff wrote:
After discussing some of this off list with Jason it seems we are leaning towards how it was done SAML spec the base is completely transport agnostic and perhaps specify later how to bind these (http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf)
I think it is reasonable if the base document is transport agnostic, but I would be very much in favour if it is documented somewhere: after all, if I read NM charter, it is chartered with defining a schema, while NMC is chartered with defining a protocol. So, I would say: define exactly what is going over the wire. That includes specifying the underlying transport protocol, as long that is a concern for the end-hosts (so it must be defined up to the transport layer (in this case: define that we use SOAP + HTTP + TCP and that the port number should be looked up in the lookup service). The only drawback of this approach is the plethora of documents we're creating, but otherwise it seems fine with me. If we agree, I will rework the SHOULD and MUSTs in the base document according to this agreement, and note that the transport protocol is defined elsewhere. Regards, Freek
Hi Freek; I will note your proposal regarding the base document in the meeting notes. 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 - if it travels over pigeons or wires should not be a primary concern. The documents that I think you and Michael speak of belong to the projects that implement these protocols into specific services. We commonly refer to 'perfSONAR capable' services as services that speak perfSONAR protocols. In this case we should be saying, 'perfSONAR is really NMC that travels on SOAP over HTTP'. I would argue that these specifications should be undertaken by these projects, not by NMC. Thanks; -jason
Michael Bischoff wrote:
After discussing some of this off list with Jason it seems we are leaning towards how it was done SAML spec the base is completely transport agnostic and perhaps specify later how to bind these (http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf)
I think it is reasonable if the base document is transport agnostic, but I would be very much in favour if it is documented somewhere: after all, if I read NM charter, it is chartered with defining a schema, while NMC is chartered with defining a protocol. So, I would say: define exactly what is going over the wire. That includes specifying the underlying transport protocol, as long that is a concern for the end-hosts (so it must be defined up to the transport layer (in this case: define that we use SOAP + HTTP + TCP and that the port number should be looked up in the lookup service).
The only drawback of this approach is the plethora of documents we're creating, but otherwise it seems fine with me.
If we agree, I will rework the SHOULD and MUSTs in the base document according to this agreement, and note that the transport protocol is defined elsewhere.
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
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. 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 - Michael On Thu, Feb 18, 2010 at 8:57 PM, Freek Dijkstra <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 http://www.ogf.org/mailman/listinfo/nmc-wg
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@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 http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
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 >
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@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@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 http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
------------------------------
_______________________________________________ Nmc-wg mailing listNmc-wg@ogf.orghttp://www.ogf.org/mailman/listinfo/nmc-wg
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@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@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 http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list 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
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@acad.bg <mailto:nina@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@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
participants (6)
-
Freek Dijkstra -
Jason Zurawski -
Jeff W. Boote -
Jeff W.Boote
-
Michael Bischoff -
Nina Jeliazkova