InfoQ Homepage Presentations REST, Reuse, and Serendipity
REST, Reuse, and Serendipity
01:00:48
Summary
Planning reusability is hard, designing for unforeseen reuse might be even harder. In this QCon London 2008 talk, Steve Vinoski presents some of the barriers to reuse found in typical distributed systems development approaches, and discusses how REST not only helps overcome some of these barriers, but also leads to potentially significantly increased chances for achieving serendipitous reuse.
Bio
Steve Vinoski is a very well-known expert on middleware, mostly known for his long-time involvement with CORBA. He is a member of technical staff at Verivue and was previously chief architect and Fellow at IONA Technologies for a decade. Over the past 15 years, Steve has authored or co-authored over 80 highly-regarded publications on distributed computing and enterprise integration.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Apr 04, 2009
Community comments
Type System Illusions?
by Troels Knak-Nielsen,
Re: Type System Illusions?
by todd hoff,
Re: Type System Illusions?
by Stefan Tilkov,
Re: Type System Illusions?
by Troels Knak-Nielsen,
Re: Type System Illusions?
by Steve Vinoski,
Re: Type System Illusions?
by Tjerk Wolterink,
Re: Type System Illusions?
by Steve Vinoski,
Re: Type System Illusions?
by Steve Vinoski,
Type System Illusions?
by Troels Knak-Nielsen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Around 00:15:00 (The slide "Type System Illusions"), he says something along the lines of "Types can't be enforced over RPC". Could someone explain what did he mean with that statement?
Re: Type System Illusions?
by todd hoff,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think it means types are defined by code that manipulates the data sent through an RPC. An RPC is just a data definition. It doesn't know a bank deposit shouldn't be negative, for example, which a type would know.
Re: Type System Illusions?
by Stefan Tilkov,
Your message is awaiting moderation. Thank you for participating in the discussion.
With an in-process call, a static type system protects you (to a certain degree). If a method invocation is done over the wire, you have no idea whether the two communicating programs have been built with the same language, let alone the same version of the exact same interface.
Re: Type System Illusions?
by Troels Knak-Nielsen,
Your message is awaiting moderation. Thank you for participating in the discussion.
So, in other words, runtime violations of the protocol could occur? I thought he perhaps meant there was some fundamental issue which had alluded me. All that is saying is that when you have multiple parties involved, you can't guarantee that protocols are respected. But that's hardly the fault of the protocols, is it?
Re: Type System Illusions?
by Steve Vinoski,
Your message is awaiting moderation. Thank you for participating in the discussion.
Stefan's explanation of what I meant by "type system illusions" is correct.
I've heard many arguments over the years that using Java, C++, etc. for distributed systems development was very important and beneficial because of the type safety they offer. I probably mistakenly made such arguments myself at one point or another. When you compile a regular program, the compiler/linker/loader can detect type mismatches, signature mismatches, etc. because what's being produced is pretty much a monolithic entity. However, the same is not even close to being true in a distributed system given that what's at the endpoints can vary in terms of not only implementation languages, but also versions of interfaces, transfer syntax, and compile-time types.
In reality any claims of type safety offered by such languages in a distributed setting are misguided because these languages can offer no safety beyond what they provide to ordinary non-distributed programs. Once a message or RPC call leaves a particular address space, the language can no longer enforce or guarantee any static type safety, especially in a multi-language system. There are ways to achieve some degree of safety by sending the actual code that implements the types as part of the call, but that trade-off makes handling multiple languages difficult or even impossible, which automatically limits your scalability, flexibility, and adaptability.
Re: Type System Illusions?
by Tjerk Wolterink,
Your message is awaiting moderation. Thank you for participating in the discussion.
You say RPC calls try to look like local calls:
Thats not totally true: the programmer must be aware: to handle the errors that only happen with remote calls. Some EAI systems even use transaction management for remote calls in order to prevent the problem you name: suppose the client crashes before the server can respond. Distribute systems theory exactly solve these kind of problems.
Coupling between source language and Interface Description:
The code generation and the coupling with the source language is not really that true, because Web Services are based on XML Schema.
About the Type Safety Illusion:
RCP in general doesnt provide type safety, but certain RCP techniques like Web Services do: they are based on XML Schema language. So type safety is guaranteed. So I basically do not agree with you.
Off course it depends on the RCP technique you use.
I agree that the sevices of a system must be specified before you do coding. So generating an IDL from sourcecode is not really good.
In fact i do research about Domain Specific Languages to first model the domain of interest: the business services etc.
Re: Type System Illusions?
by Steve Vinoski,
Your message is awaiting moderation. Thank you for participating in the discussion.
I hear this sort of response quite often. The very nature of RPC is that it was invented to make remote programming look local; you may want to read RFC 707, where RPC was first described. Also, the term "RPC" does not refer to "just any network message" — you may want to go review my slides from QCon London 2009.
There's more to it than just error handling. For example, there are sometimes issues related to impedance mismatch between the types in the distributed system and the local programming language types used to represent them, and there are issues related to idempotency and how to recover properly should a failure occur somewhere within a stateful interaction. Such issues can significantly impact RPC-oriented development, trust me.
Ah, so you write all your applications in XML Schema! I was unaware it was a programming language. ;-) So you're telling me that with XML Schema, there is no impedance mismatch between it and any programming language? In other words, mapping between any programming language and XML Schema is entirely faithful and lossless?
XML Schema does not solve this problem, since you have no way to guarantee that the schema node A uses is exactly the same schema that node B uses, unless you send the whole schema document along with every single message and receivers always validate all messages, neither of which does much to help performance or scalability. XML Schema is no different than any other type system in this regard.
Instead of focusing on XML Schema and Web Services, which IMO is a dead end, I suggest you should devote your research to RESTful web services. You'll get far more benefit from it for your own work, perhaps leading to systems of significant scale that would be well beyond anything achievable with XSD and WS-*.
Re: Type System Illusions?
by Steve Vinoski,
Your message is awaiting moderation. Thank you for participating in the discussion.
Keep in mind that RPC hides protocols. All the programmer sees are the functions to call, the types to pass, and the expected return type. That in and of itself is a fundamental problem.