RPC Under Fire
Via Lambda-the-Ultimate, Steve Vinoski's paper: RPC Under Fire.
Yet another article about RPC's failings. Also mentions SOAP and briefly goes into how SOAP has made things worse, rather than better. It is ironical, since one of SOAP's goals was to simplify interoperation, but it has actually made things worse. A large part of the problem may be XML Schema, aka XSD. XSD may have been designed with the best of intent, but it is proving to be a royal nightmare to implement, support, and worse-yet integrate into existing languages/environments.
I've been involved with all 3 types of activities, and they have all been painfully difficult. I've managed people implementing XSD, as well as a lot of experience managing people trying to fix Microsoft's implementations to be compliant. The specification is so complicated that a minor misunderstanding requires a significant API redesign to fix! The type system is so complicated that there is a constant stream of emails asking questions about why such-n-such a schema fails. The specification has a number of key controversial points where key vendors have had differing interpretations, leading to significant issues.
That said, XSD is what we've got. Relax-NG may be cleaner and simpler, but it still has the problem that it doesn't map back to any common OO language simply. That isn't so much Relax-NG's fault, as it is a central issue with XML itself. XSD is here to stay, given it's support in so many Microsoft products. That is not something to take lightly, in my book. From what I heard, the next version of Office is going to really address a lot of the issues people had with the XML support in the current version.
Back to the topic of RPC: RPC (and most especially all SOAP implementations) walk a fine line between enabling programmer productivity and distancing programmers from a core concern. I know far too many stories of RPC ruining products, where it all works great when the client and server have a fast, reliable connection, but fails miserably when deployed in the real world. Developers must keep the nature of the network in mind when developing a network application. Libraries which distance the developer to far from such a core concern, are asking for abuse, and are likely to result in applications that do not handle ugly realities of networks very well.
Yet another article about RPC's failings. Also mentions SOAP and briefly goes into how SOAP has made things worse, rather than better. It is ironical, since one of SOAP's goals was to simplify interoperation, but it has actually made things worse. A large part of the problem may be XML Schema, aka XSD. XSD may have been designed with the best of intent, but it is proving to be a royal nightmare to implement, support, and worse-yet integrate into existing languages/environments.
I've been involved with all 3 types of activities, and they have all been painfully difficult. I've managed people implementing XSD, as well as a lot of experience managing people trying to fix Microsoft's implementations to be compliant. The specification is so complicated that a minor misunderstanding requires a significant API redesign to fix! The type system is so complicated that there is a constant stream of emails asking questions about why such-n-such a schema fails. The specification has a number of key controversial points where key vendors have had differing interpretations, leading to significant issues.
That said, XSD is what we've got. Relax-NG may be cleaner and simpler, but it still has the problem that it doesn't map back to any common OO language simply. That isn't so much Relax-NG's fault, as it is a central issue with XML itself. XSD is here to stay, given it's support in so many Microsoft products. That is not something to take lightly, in my book. From what I heard, the next version of Office is going to really address a lot of the issues people had with the XML support in the current version.
Back to the topic of RPC: RPC (and most especially all SOAP implementations) walk a fine line between enabling programmer productivity and distancing programmers from a core concern. I know far too many stories of RPC ruining products, where it all works great when the client and server have a fast, reliable connection, but fails miserably when deployed in the real world. Developers must keep the nature of the network in mind when developing a network application. Libraries which distance the developer to far from such a core concern, are asking for abuse, and are likely to result in applications that do not handle ugly realities of networks very well.
posted by derek at 8:35 PM
0 Comments:
Post a Comment
<< Home