Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Recorded at:
Presented by Steve Vinoski on Apr 04, 2009
Free $40 SOA Demystified Book Offer
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
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.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
8 comments
Watch Thread Reply