Originally,?SOAP 1.1 (May,2000) chapter 5 "Encoding" ( the infamous section 5 ) defines encoding style. It tried to describe the rules for serializing and deserializing xml framgments into (from) Soap elements, but the ambiguities in the SOAP encoding lead to many problems in interoperability.
a little later, (May 2001) XML Schema was at last published as a W3C recommendation and since then it got rapid and wide adoption, which inculdes: use of XML schema and instances in WSDL and SOAP.
In order to improve the interoperability of web service, WS-I organization was formed.?WS-I Basic Profile,?which beat the use of SOAP encoding,??was published in August 2003.??WS-I basic profile explicitly prohibit SOAP encoded style.
So we can only use 2 messaging mode:?Literal / RPC? and?Literal / Document according to WS-I Basic Profile.
As my understanding, the key difference between literal and encoded is:
?? ?Literal:? based on xml schema? agreed by both service provider and requester.?
??? encoded: based on pre-determined rules (xml schema) defined by SOAP section 5
In other words,
In Literal style, as long as both parties ( provider and requester) agree on one xml schema, they can communicate.Different pair can have different rules (xml schema). say, A and B share an xml schema. C and D share an xml schema.
In encoded style, all parties of web service and all pairs of web service share a common standard?schema , which defined in soap section?5.
A, B, C and? D?all ?must conform the common rules.
Literal style is more flexible than encoded style. It also has much less ambiguities than encoded style.
see other resource about Literal / encoded, Document / RPC, and others
Books:
Java Web Service Architecure? by James Gosling and others. ?Chap.4.5 Soap messaging modes. P107
J2ee Web Services?? by Richard Monson-Haefel.?? Chap.4. Soap encoding? P119.
Articles:
Developing Web Services with EMF SDOs for complex XML schema#?
(Latest article published on IBM developerworks Feb. 28, 2006. The original Feb. 28, 2005 is a typo mistake. RAD(Rational Application Developer) 6.0.1.1?just published 2 months ago)
See 'Perceptions and standards' for relationship among various standards. esp. soap (section 5), WS-I, xml schema, jax-rpc, jax-B
JavaWorld@TW - Operation Style (Document/RPC) and Message format(literal/encoded)#
Operation Style (Document/RPC) and Message format(literal/encoded)
The Difference Between RPC and Document Style WSDL#
RPC style and document style are catchphrases frequently heard in the context of web services and the SOAP protocol. What exactly do they mean? How do they relate to the pair of terms 'encoded/literal'? Where does the confusion about these terms come from? This article describes the WSDL binding style and use attributes
P13. To be completely blunt: I do NOT believe general Web service interoperability with anonymous parties is actually feasible without the guidance of the WS-I Basic Profile 1.0. Experienced Web service developers can tell you numerous interoperability horror stories related to the loose language and broad visions defined by standards like SOAP, WSDL, and UDDI. The WS-I Basic Profile eliminates many, if not all, of the ambiguities inherent in these primary standards, finally making interoperability among disparate Web service platforms (.NET, j2ee, axis, perl, etc) possible.
Trying to integrate 365key into my blog.
In our Red machine,
to initilize cvs
use : cvs -d /cs/home/... init
(if -d option is not added, then command: cvs import -m .... does not execute correctly
The problem maybe: without -d option, CVS doesn't know the administrative subdirectory of a repository. so import failed.
So It seems here is the later use of CVSROOT)
Note.
Don't confuse the CVSROOT environment variable with CVSROOT subdirectory in repository. They are UNRELATED;
The former is a way for users to avoid having to type -d <reporisory-location> every time they use CVS;
The later is the administrative subdirectory of a repository.