WJAX, JUGCGN Presentation Slides: SOA, JAX-RS, REST, Ruby Metaprogramming
Here are my slides from the past two days:
- (K)ein Kochrezept: Von 0 auf SOA in 10 Schritten (German, obviously)
- JAX-RS (nothing new here if you've seen my earlier slides)
- Ruby Metaprogramming (mostly introductory stuff)
- Lightweight SOA
Enjoy; feedback welcome.
Hi Stefan, I’ve enjoyed your Lightweight SOA slides, but of course a lot is left for the presenter’s discourse, as it should be… 8-)
I have one gripe about your slide 61, though. Your four comparisons could be rewritten like this:
homogeneity vs. integration pain (heterogeneous tools),
integrated solutions vs. integration pain (because multiple vendors will always differentiate on things above standards),
central control vs. no control (or multiple points of failure),
mainstream vs. untested.
Where the reader/listener has the time, resources and intelligence (to which you appeal), they can get over the integration pain, learn about all the right tools, deal with the decentralized control and multiple vendors (and resulting mismatches) and maybe untested tools and do it as you suggest, but what for the time&resource-constrained, not necessarily that intelligent people who must design distributed apps? All the first parts of your 4 vs.s have their place, just like the second parts; yet your slides seem to make it black and white (and I don’t know your speech that accompanies them).
Would you say I’m overly conservative here, perhaps? 8-)
Hey Jacek, you’re right that without the accompanying sound this might sound a little controversial … I was actually not favoring one over the other, but merely wanted to point out that you have to consider both sides.
In fact a centralized, integrated solutionfrom a single vendor that is widely known might be your best option. But it’s not the only one!
Of course the slides (and the talk) are a little provocative to get attention, but at the end I try to find common ground. Sort of like a post-election Obama or McCain speeech :-)
I think the true test of “lightweight” SOA, in fact the appropriate amount of technology to apply to the problem usually results in answering two questions:
Too often we seek more complex solutions because we can afford them, when in fact frugality tends to make things lighter, simpler, cheaper, faster.
i have yet to see an example (in real life or on paper) where an ESB actually helped increase productivity. It just creates more mess and more moving parts to debug and maintain, not to mention it kicks out delivery dates by months upon months. I’d rather use perl scripts to tie stuff together! ;)