What's wrong with rpc-literal? Why use doc-literal?

Discussion in 'ASP .Net Web Services' started by Anonieko Ramos, Sep 27, 2004.

  1. >
    >
    >


    reference: http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl

    This post is part of Issue 8's answer



    To say it as clear and simple as possible: rpc style encoding is more
    about the service implementation than the message on the wire itself.
    That's just wrong! As already discussed in this answer series, every
    rpc-literal message can be described using doc-literal encodings.
    Therefore there is no need to specify the implementation model of a
    service stub/proxy. The only thing that matters is the data on the
    wire.

    The second thing that just drives me crazy about rpc-literal is the
    fact that there is no way to verify a message for correctness: Since
    we only got the schemas for the different message parts but not for
    the message itself it's just not possible to validate the message on
    the wire. We only can verify the message if we got the service
    description by hand. But there is usually no support to verify a
    message against the <wsdl.message> at runtime.



    To conclude: If you're serious about Web Services and loosely coupled
    messaging, don't use rpc-literal. Rather go for doc-literal!


    Using Doc Literal for all Services
    With all the discussion about the best encoding style to use for
    WSDL/SOAP, such as this excellent IBM DeveloperWorks article from
    October, 2003, I have to wonder whether the best answer is really just
    to use doc/literal for everything...?

    The doc/literal style would seem to be the most abstract or the most
    "loosely coupled," since it does not include data typing (although
    data typing is provided by an associated XML Schema) and does not
    include a method name in the message.

    True, the burden of interpreting the XML document falls on the Web
    service implementation, but isn't that how it should be? In developing
    services, as Don Box and others have been recently saying, shouldn't
    we be thinking about the content of the message independently of the
    underlying implementation of the service? Whether it's
    object-oriented, procedure-oriented, a message queue, an ERP package,
    Java, C#, COBOL, or Python? Then the implementation of the service,
    whether a direct or indirect mapping (that is, whether the execution
    stage involves transformation or multiple steps), can take
    responsiblity for extracting the relevant information from the XML
    document and formatting it for the execution environment.

    Won't this level of abstraction really make life easy? Maybe not for
    the folks who have to develop the services and the mapping of the
    documents, but for the next level developers who have to stitch
    everything together. I mean, once enterprises are all
    service-oriented, and have adopted and implemented SOA using Web
    Services and XML, won't integrators just have to worry about the data
    being passed in the messages, and not about the objects, queues,
    methods, or programs underneath the services?

    Once executable, compiled software systems are over-layed with XML
    based Web services, and they start exchanging messages based on the
    data in them, and stop worrying about the object signature,
    productivity will go way up, won't it?

    Today when integrating various bits and types of software, combining
    programs written using different languages and/or middleware systems,
    you have to know what it is you're invoking and figure out how to
    structure your data into the arguments associated with the particular
    method or program name. I don't think that's very productive, at least
    not for those integrating services into appliations and flows.

    Posted by newcomer at May 17, 2004 04:55 PM | TrackBack

    Comments
    Very good point, Eric! As editor of Cutter's "Web Services Strategies"
    newsletter, I have spent a lot of time researching what people say
    about Web services and SOA, and "loose coupling" is probably where the
    greatest confusion arises. It seems to me there is a lot of doubletalk
    going on, with people claiming all the theoretical benefits of Web
    services (e.g. loose coupling through the use of Doc Literal) - then
    going straight on to cite code that follows the RPC model, and
    enthusing about how easily it can be generated!

    Moreover, I think the use of Doc Literal fits in well with the "WSDL
    first" development style (or better still, perhaps, for those using
    MDA, "PIM first, then WSDL"). Start by figuring out the data schemas
    at the CIM level, then work downward. Code comes last!

    Convenience dictates otherwise, though - and convenience (with its
    good buddies, speed and cheapness) scores high in sales meetings. The
    convenient way is to point one of the scores of tools out there at
    some existing code, and let it generate WSDL from that.

    Posted by: Tom Welsh at May 18, 2004 04:54 AM
    Hi Eric!

    I definitely agree with your comments. However, I would like to point
    out that Doc/Literal helps if one wants to build loosely-coupled
    systems but it does not guarantee loose-coupling. This is true with
    all technologies when they are not used properly.

    Isn't WS-RF an example of a suite of specifications where doc/literal
    is used to implement a resource-oriented or object-based approach to
    building distributed applications? I suspect that the WS-RF approach
    will lead to tight-coupling and will not scale. But it may be just me.

    Related entry (since my trackback doesn't work)...

    http://savas.parastatidis.name/2004/05/21/1ea080ea-8105-4b27-8cfd-8a600aab28af.aspx

    Regards,
    ..savas.

    Posted by: Savas Parastatidis at May 21, 2004 02:03 PM
    Eric, I think you're mostly on the money: transitioning to a more
    message-centric model would be a great leap forward. I think, however,
    you overstate the ease at which integration will move forward when
    everyone is focusing on data exchange and agnostic about
    implementation choices: integrators will still be very much
    constrained by capabilities (especially delivery guarantees), business
    policies and bi-lateral agreements, etc. But come to think of it,
    those are the aspects they should be focusing on anyway...

    Greg

    Posted by: greg at May 24, 2004 10:07 AM
     
    Anonieko Ramos, Sep 27, 2004
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt
    Replies:
    3
    Views:
    531
    Tor Iver Wilhelmsen
    Sep 17, 2004
  2. Pere Montolio

    XML RPC to ONC XDR RPC

    Pere Montolio, Aug 11, 2004, in forum: XML
    Replies:
    0
    Views:
    748
    Pere Montolio
    Aug 11, 2004
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,072
    Smokey Grindel
    Dec 2, 2006
  4. Sek

    How to use RPC/literal combination?

    Sek, May 19, 2006, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    143
  5. Marvin Gülker
    Replies:
    0
    Views:
    89
    Marvin Gülker
    Oct 22, 2009
Loading...

Share This Page