10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
REST, Reuse, and Serendipity
Presented by
Steve Vinoski
on
Apr 04, 2009
Length 01:00:48
- Sections
- Architecture & Design,
- Development,
- Enterprise Architecture
- Topics
- REST ,
- Reuse ,
- SOA
- Tags
- QCon London 2008 ,
- HTTP ,
- QCon
-
- The next QCon is in London March 5-9, Join us!
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
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.
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Type System Illusions?
by
Troels Knak-Nielsen
Posted
Re: Type System Illusions?
by
todd hoff
Posted
Re: Type System Illusions?
by
Stefan Tilkov
Posted
Re: Type System Illusions?
by
Troels Knak-Nielsen
Posted
Re: Type System Illusions?
by
Steve Vinoski
Posted
Re: Type System Illusions?
by
Tjerk Wolterink
Posted
Re: Type System Illusions?
by
Steve Vinoski
Posted
Re: Type System Illusions?
by
Steve Vinoski
Posted
-
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?
-
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.
-
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.
-
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.
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? -
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. -
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. -
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.
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.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.
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?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.
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.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.
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-*. -
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.
8 comments
Watch Thread Reply