A
Anonieko Ramos
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
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