perfsonar development work

[Loukik Kudarimoti <>]

Hi All,

Long ago, during the early stages of GGF-NMWG and during the perfmonit 
era, it was agreed that the web service standard that we will use is 
Document/Literal. After that point, almost all our implementations have 
been using doc/lit standard. I felt the need to emphasize on this today 
because it looks like sometimes, this detail tends to be overlooked.

There is a big difference between doc/lit and soap rpc.

In document/literal, an NMWG compliant request would look like the one 
below. Notice that the NMWG message element is immediately below the 
soap:body element.

<soap:envelope ...>

<soap:header...>
</soap:header>

<soap:body>
    <nmwg:message xmlns:nmwg="..." type="setupDataRequest>
    </nmwg:message>
</soap:body>

</soap:envelope>


The difference with soap rpc is that the nmwg message element is present 
inside another element which specifies the name of the method to be used 
(rpc call)

For example:

<soap:envelope ...>

<soap:header...>
</soap:header>

<soap:body>
    <m:makeMeasurement xmlns:m="...">
           <nmwg:message xmlns:nmwg="..." type="setupDataRequest>
           </nmwg:message>
     </m:makeMeasurement>
</soap:body>
</soap:envelope>

During the early years of NMWG, it was agreed that this type of 
specification of method name (rpc call) is not a good idea to 
standardize upon. Implementations should be able to choose a method name 
of their choice and the clients do not have to care. Hence, 
Document/Literal was adopted.

Another point to mention is that when we say Document / Literal, up to 
this point we haven't really mentioned about the 'Literal' part of our 
message. There are at least two types: literal and encoded. In 'encoded' 
style, the elements that we use are datatypes defined in XML Schema 
(i.e. the standard datatypes). As I understand, it means the contents 
are defined in terms of xsd:float, xsd:int, xsd:string and so on. This 
allows for automatic generation of stubs and skeletons (helper classes) 
thus simplifying web service implementation. However, it apparently also 
means that we can't define a xml schema for our own message.

With 'literal', we define our own schema and we do our own marshalling 
and unmarshalling (i.e., parsing through the xml and understanding the 
request). Basically, Document/Literal seems to fit better with the 
profile of the work that we are doing. Our current Java implementation 
is pure Document/Literal.

If you are more curious about the differences between the two styles, 
here is a good guide:
http://searchwebservices.techtarget.com/ateQuestionNResponse/0,289625,sid26_cid494324_tax289201,00.html

Loukik.