The issue was raised as to which style(s) of SOAP messages should be
supported in defining the interface between XKMS complaint clients and
services. SOAP supports several styles with the two most common being
Document-Literal and RPC-SOAPEncoding. The XKMS 1.1 Note used the
former. As the WG develops its specification, we should make an explicit
decision as to which styles must and/or should be supported.For those who aren't familiar with the two styles, I have provided
simple examples of 'Locate' message requests at the end. Its obvious
that the two message structures are quite a bit different. In
particular, The Document-Literal message looks like a typical XML
document structure with nested child elements. In comparison, the
RPC-SOAPEncoding message is:
1) Quite a bit larger, due to additional namespaces and
extensive use of references
2) Includes more information about the 'type' of information
being sent, such as the explicit nil and array type attributes.
3) Uses a more complex style based on isolating multi-reference
values in independent elements which are then referenced by their
accessors. (see SOAP 1.1, Section 5, for the full discussion of these
rules). In some cases, an array element may appear as a child of its
accessor, but one should be prepared to handle the independent element,
accessor reference style shown.The second point above is really the most important. SOAP encoding is
"based on a simple type system that is a generalization of the common
features found in type system in programming languages, databases, and
semi-structured data". Hence, the RPC-SOAPEncoding style lets the
originator include more information as to their view of data being sent.
This may benefit the recipient in providing hints (beyond XML schema) as
to how best to deserialize the message back into a "value graph"
representing the information in the message. From the standpoint of the XKMS WG, the issues boil down to:
- Is there a benefit to one style over the other? The Doc-Lit
style is somewhat easier to encode/decode but the RPC-SOAPEnc style has
richer semantics. Unless we believe there is value in promoting 'type
model' fidelity between clients and services, it may be easiest to stay
with the Doc-Lit style.
- If both styles are supported, then service developers will
need to pick a style to use. This will be reflected in their WSDL
contact If they want to support both styles, then they'll need separate
URLs for each with different WSDLs. Obviously, this would increase
complexity.
- Allowing both styles creates a dilemma for client
implementers. Do they only support one style, in which case they can
only talk with some services, or do they support both which entails a
significant increase in complexity?
- If we add a simple integrity and confidentiality mechanism
based on XML Signature and XML Encryption, we'd need to be cognizant of
the possible message structure(s). The biggest impact is probably on
signature generation. With Doc-Lit encoding one could sign a reference
to the Locate element. With RPC-SOAPEnc you'd want to either sign a
reference to the Body element or an xPath selecting all the children of
Body. The latter seems preferable to avoid inclusion of namespaces
associated with the Body that aren't used in the contents.SAMPLE Document-Literal Style SOAP Message<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<Locate xmlns="http://www.xkms.org/schema/xkms-2001-01-20">
<Query>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>key</KeyName>
</KeyInfo>
</Query>
<Respond>
<string>KeyName</string>
<string>KeyValue</string>
</Respond>
</Locate>
</soap:Body>
</soap:Envelope>SAMPLE RPC-SOAPEncoding Style SOAP Message<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:a2="http://schemas.microsoft.com/clr/nsassem/XKMSTypes/XKMSTypes"
xmlns:i2="http://schemas.microsoft.com/clr/nsassem/XKMSKeyService.KeySer
vice/Key">
<SOAP-ENV:Body>
<i2:Locate id="ref-1">
<TransactionID xsi:null="1"/>
<Query href="#ref-4"/>
<Respond href="#ref-5"/>
</i2:Locate>
<a2:LocateQuery id="ref-4">
<KeyInfo href="#ref-6"/>
</a2:LocateQuery>
<SOAP-ENC:Array id="ref-5" SOAP-ENC:arrayType="xsd:string[2]">
<item id="ref-7">KeyName</item>
<item id="ref-8">KeyValue</item>
</SOAP-ENC:Array>
<a2:KeyInfo id="ref-6">
<Item href="#ref-9"/>
<Id xsi:null="1"/>
</a2:KeyInfo>
<SOAP-ENC:Array id="ref-9" SOAP-ENC:arrayType="xsd:ur-type[1]">
<item href="#ref-10"/>
</SOAP-ENC:Array>
<a2:KeyName id="ref-10">
<Text id="ref-11">mykey</Text>
</a2:KeyName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
supported in defining the interface between XKMS complaint clients and
services. SOAP supports several styles with the two most common being
Document-Literal and RPC-SOAPEncoding. The XKMS 1.1 Note used the
former. As the WG develops its specification, we should make an explicit
decision as to which styles must and/or should be supported.For those who aren't familiar with the two styles, I have provided
simple examples of 'Locate' message requests at the end. Its obvious
that the two message structures are quite a bit different. In
particular, The Document-Literal message looks like a typical XML
document structure with nested child elements. In comparison, the
RPC-SOAPEncoding message is:
1) Quite a bit larger, due to additional namespaces and
extensive use of references
2) Includes more information about the 'type' of information
being sent, such as the explicit nil and array type attributes.
3) Uses a more complex style based on isolating multi-reference
values in independent elements which are then referenced by their
accessors. (see SOAP 1.1, Section 5, for the full discussion of these
rules). In some cases, an array element may appear as a child of its
accessor, but one should be prepared to handle the independent element,
accessor reference style shown.The second point above is really the most important. SOAP encoding is
"based on a simple type system that is a generalization of the common
features found in type system in programming languages, databases, and
semi-structured data". Hence, the RPC-SOAPEncoding style lets the
originator include more information as to their view of data being sent.
This may benefit the recipient in providing hints (beyond XML schema) as
to how best to deserialize the message back into a "value graph"
representing the information in the message. From the standpoint of the XKMS WG, the issues boil down to:
- Is there a benefit to one style over the other? The Doc-Lit
style is somewhat easier to encode/decode but the RPC-SOAPEnc style has
richer semantics. Unless we believe there is value in promoting 'type
model' fidelity between clients and services, it may be easiest to stay
with the Doc-Lit style.
- If both styles are supported, then service developers will
need to pick a style to use. This will be reflected in their WSDL
contact If they want to support both styles, then they'll need separate
URLs for each with different WSDLs. Obviously, this would increase
complexity.
- Allowing both styles creates a dilemma for client
implementers. Do they only support one style, in which case they can
only talk with some services, or do they support both which entails a
significant increase in complexity?
- If we add a simple integrity and confidentiality mechanism
based on XML Signature and XML Encryption, we'd need to be cognizant of
the possible message structure(s). The biggest impact is probably on
signature generation. With Doc-Lit encoding one could sign a reference
to the Locate element. With RPC-SOAPEnc you'd want to either sign a
reference to the Body element or an xPath selecting all the children of
Body. The latter seems preferable to avoid inclusion of namespaces
associated with the Body that aren't used in the contents.SAMPLE Document-Literal Style SOAP Message<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<Locate xmlns="http://www.xkms.org/schema/xkms-2001-01-20">
<Query>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>key</KeyName>
</KeyInfo>
</Query>
<Respond>
<string>KeyName</string>
<string>KeyValue</string>
</Respond>
</Locate>
</soap:Body>
</soap:Envelope>SAMPLE RPC-SOAPEncoding Style SOAP Message<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:a2="http://schemas.microsoft.com/clr/nsassem/XKMSTypes/XKMSTypes"
xmlns:i2="http://schemas.microsoft.com/clr/nsassem/XKMSKeyService.KeySer
vice/Key">
<SOAP-ENV:Body>
<i2:Locate id="ref-1">
<TransactionID xsi:null="1"/>
<Query href="#ref-4"/>
<Respond href="#ref-5"/>
</i2:Locate>
<a2:LocateQuery id="ref-4">
<KeyInfo href="#ref-6"/>
</a2:LocateQuery>
<SOAP-ENC:Array id="ref-5" SOAP-ENC:arrayType="xsd:string[2]">
<item id="ref-7">KeyName</item>
<item id="ref-8">KeyValue</item>
</SOAP-ENC:Array>
<a2:KeyInfo id="ref-6">
<Item href="#ref-9"/>
<Id xsi:null="1"/>
</a2:KeyInfo>
<SOAP-ENC:Array id="ref-9" SOAP-ENC:arrayType="xsd:ur-type[1]">
<item href="#ref-10"/>
</SOAP-ENC:Array>
<a2:KeyName id="ref-10">
<Text id="ref-11">mykey</Text>
</a2:KeyName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
应该是RPC是：RPC风格的服务是接口驱动的，同步的交互。面向过程的ws将用PRC风格。例如：soap交互是同步的，且可能用RPC风格。
Document Style：基于消息的ws也被说成是文档驱动的，意思是在双方之间仅仅数据是最重要的。像处理的及时性和协调是不相关的。面向数据的ws借助于基于消息的风格。例如：soap消息是数据驱动的，并且特的ws将可能使用基于消息的风格。
Soap Message和Literal XML的区别又在哪里？
soap m:使用soap格式封装xml消息在soap服务器间传递。
L xml：通过上传、下载，传递xml文件进行数据交换。
Could you please show us the URL of the whole article?