Transport protocol
Hi all, I was just going through the document again to see what can be improved. A few issues on the transport protocol. The document never makes it clear what kind of transport protocol is used. Section 2 say "The proposed architecture should mae this functionality available vai Web Services (WS) [...]" While there are different types of webservices, e.g. * XML in SOAP over HTTP * XML in SOAP over AMQP * XML in SOAP over JMS * XML in SOAP over TCP or UDP * XML over HTTP (the recent low-overhead RESTful webservices) In practice, only XML in SOAP over HTTP seems to be used. To we want to impose that? I think it should be, though I am fine if it is either in the NMC base document or in another document (which has the advantage that if we later want to change the transport protocol, it is not necessary to update the base document). At least, when I play with the PerfSONARUI (great work by the way, it allows me to understand PerfSONAR a bit better!), I see that a request like this:
<?xml version="1.0" encoding="UTF-8"?> <nmwg:message id="message1266324754" type="EchoRequest" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"> <nmwg:metadata id="meta"> <nmwg:eventType>http://schemas.perfsonar.net/tools/admin/echo/2.0</nmwg:eventType> </nmwg:metadata> <nmwg:data id="data" metadataIdRef="meta"/> </nmwg:message>
Is transformed on the wire to this:
POST /geant2-java-rrd-ma/services/MeasurementArchiveService HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: 62.40.123.162:8080 Cache-Control: no-cache Pragma: no-cache SOAPAction: "" Content-Length: 559
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <nmwg:message id="message1266324654" type="EchoRequest" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"> <nmwg:metadata id="meta"> <nmwg:eventType>http://schemas.perfsonar.net/tools/admin/echo/2.0</nmwg:eventType> </nmwg:metadata> <nmwg:data id="data" metadataIdRef="meta"/> </nmwg:message> </soapenv:Body> </soapenv:Envelope>
Beside describing the transport protocol, which document is to defined the preferred TCP server ports for a given service? I presume the documents describing the individual services should define the later. Regards, Freek
Hi Freek,
In practice, only XML in SOAP over HTTP seems to be used. To we want to impose that? I think it should be, though I am fine if it is either in the NMC base document or in another document (which has the advantage that if we later want to change the transport protocol, it is not necessary to update the base document).
I think that's already "imposed" and so we should document it as such. I think you raise a good point, in that it shouldn't need to be a requirement forever. If we are careful (and maybe not even too careful) we could have the WS encoding be any of the standard varieties. So I, for one, would vote for also saying that -- "it is XML/ SOAP/HTTP now, but needn't be forever."
Beside describing the transport protocol, which document is to defined the preferred TCP server ports for a given service? I presume the documents describing the individual services should define the later.
There are conventions, but as the are registered in the information service, they can change. The conventions could be added as informative text, as you suggest. best, martin
On Feb 16, 2010, at 8:52 AM, Martin Swany wrote:
Beside describing the transport protocol, which document is to defined the preferred TCP server ports for a given service? I presume the documents describing the individual services should define the later.
There are conventions, but as the are registered in the information service, they can change. The conventions could be added as informative text, as you suggest.
I'm not sure there are really conventions so much as folks have just picked things. Port choice is also heavily dependent on the implementation, e.g. if a service were implemented as a single MA instance containing ping, bandwidth, latency and utilization data vs. 4 separate services each containing one of the data types, the ports would be different even though the data you can obtain is the same. Thinking in terms of the metrics, I'm not sure it makes sense to say "get ping data on port 8065" or "get snmp data on port 8075" or whatever. All told, I'd rather get folks into the mindset of doing a lookup to find the location of information vs. assuming that "There's ping data on host X, ergo I connect to port 8065 to get it". Cheers, Aaron Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
Hey Aaron,
Port choice is also heavily dependent on the implementation, e.g. if a service were implemented as a single MA instance containing ping, bandwidth, latency and utilization data vs. 4 separate services each containing one of the data types, the ports would be different even though the data you can obtain is the same. Thinking in terms of the metrics, I'm not sure it makes sense to say "get ping data on port 8065" or "get snmp data on port 8075" or whatever.
All told, I'd rather get folks into the mindset of doing a lookup to find the location of information vs. assuming that "There's ping data on host X, ergo I connect to port 8065 to get it".
I agree that's the right thing. I was assuming that we wanted to document as much as we could about what's going on -- in a non-normative part of the doc. As you say, the "right" answer is "you look it up." martin
All;
In practice, only XML in SOAP over HTTP seems to be used. To we want to impose that? I think it should be, though I am fine if it is either in the NMC base document or in another document (which has the advantage that if we later want to change the transport protocol, it is not necessary to update the base document).
I think that's already "imposed" and so we should document it as such. I think you raise a good point, in that it shouldn't need to be a requirement forever. If we are careful (and maybe not even too careful) we could have the WS encoding be any of the standard varieties. So I, for one, would vote for also saying that -- "it is XML/ SOAP/HTTP now, but needn't be forever."
When I started the documentation it was my intention to avoid specifics of the WS (e.g. 'XML in SOAP over HTTP') because I think it is important that we don't inject implementation details into the description of the protocol bindings. This would strike me as making a heavy handed mandate on implementation styles and choices, particularly when I would envision future versions of NMC-capable frameworks trying different things as technologies mature or improve. Including this as 'we do this now, but we don't have to' still doesn't sound 100% correct me if we are going forward with the idea to document the "current" way of doing things with minor corrections, but I suppose I could be convinced. I would rather us not mandate the WS medium at all because it doesn't strike me as important to the overall functionality.
Beside describing the transport protocol, which document is to defined the preferred TCP server ports for a given service? I presume the documents describing the individual services should define the later.
There are conventions, but as the are registered in the information service, they can change. The conventions could be added as informative text, as you suggest.
As Martin (and Aaron) pointed out - this is an implementation detail. I want to avoid this at all costs. -jason
Jason Zurawski wrote:
All;
In practice, only XML in SOAP over HTTP seems to be used. To we want to impose that? I think it should be, though I am fine if it is either in the NMC base document or in another document (which has the advantage that if we later want to change the transport protocol, it is not necessary to update the base document).
I think that's already "imposed" and so we should document it as such. I think you raise a good point, in that it shouldn't need to be a requirement forever. If we are careful (and maybe not even too careful) we could have the WS encoding be any of the standard varieties. So I, for one, would vote for also saying that -- "it is XML/ SOAP/HTTP now, but needn't be forever."
When I started the documentation it was my intention to avoid specifics of the WS (e.g. 'XML in SOAP over HTTP') because I think it is important that we don't inject implementation details into the description of the protocol bindings. This would strike me as making a heavy handed mandate on implementation styles and choices, particularly when I would envision future versions of NMC-capable frameworks trying different things as technologies mature or improve.
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) Roman
Including this as 'we do this now, but we don't have to' still doesn't sound 100% correct me if we are going forward with the idea to document the "current" way of doing things with minor corrections, but I suppose I could be convinced. I would rather us not mandate the WS medium at all because it doesn't strike me as important to the overall functionality.
Beside describing the transport protocol, which document is to defined the preferred TCP server ports for a given service? I presume the documents describing the individual services should define the later.
There are conventions, but as the are registered in the information service, they can change. The conventions could be added as informative text, as you suggest.
As Martin (and Aaron) pointed out - this is an implementation detail. I want to avoid this at all costs.
-jason _______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
participants (5)
-
Aaron Brown -
Freek Dijkstra -
Jason Zurawski -
Martin Swany -
Roman Lapacz