SOA best practices, tooled! at AlpesJUG
Up to now, all presentations we did about EasySOA had been about how much EasySOA would make life easy to actors of the SOA process, and how it was done (or planned to). Sure, we did reality checks and worked closely with users that we’d trust – that is, EasySOA Partner Entreprises. But we’d never asked you what you actually think of how we’d like to help you, dear prospective EasySOA user!
From talking to listening
So that’s exactly what we did when we went to the Grenoble JUG on April the 19th to talk about SOA best practices tooled by EasySOA (slides, in French). We started by presenting what we thought were important parts of “doing SOA”, went on by the tune of “here’s how you could do it bare handed” and only at the end how EasySOA gave them those benefits and more.
Lo and behold, we came back with a backpack shockfull of answers to our questions, spur-of-the-moment ideas and overall support ! So thanks to all of you who were there, you made our trip worthwhile. Rest assured you’ll see your contributions in EasySOA’s next releases, for now I’ve listed a few at the end of the post.
SOA key factors of success
So what’s important in SOA ? If you’re a regular around here, you won’t be surprised if I answer :
- mining and discovery, because you can’t use a service if you don’t know it first,
- collaborative documentation, so users will know which service to consume or provide and how, from technical details to what constraints to meet and which business it provides,
- sanity checking, to make your model stay on track with reality, especially when you don’t control it,
- testing, because ultimately being sure your SOA behaves as expected boils down to that.
We then talked about how you can start doing that right know using some simple best practices, and finally showed how EasySOA provides them and with which additional benefits.
Actually, EasySOA goes even beyond (on the side of Light mashups and Integration extensions plugging in deep in your own SOA platform from business design tools up to monitoring), but we didn’t go that far and stayed around what would engage a (mostly) developer audience.
Ideas given and received
It was my first talk at a Java User Group anywhere, and I was pleased to discover a passionate audience eager to interact when prompted. I guess the Alpes JUG team is no stranger to this mood, nor to the success of the closing pizza party, so congrats to them (and thanks for letting me in) !
Anyway, I wouldn’t do justice to the audience’s insightful involvment if I didn’t at least list a few ideas it provided. Here it comes…
- Generate documentation from JAXRS interfaces using Swagger and copy / paste it in a wiki, as does Loïc (actually Swagger does much more to make your business REST APIs valuable, up to being your own Mashery)
- Keep your REST services simple (KISS) using a 40 lines upper limit to documentation, as does Remy,
- Wonder when REST will ever “get in the entreprise” (answer : maybe when the Cloud will be so prevalent and pervasive it will impose a continuous deployment model to the entreprise),
- Make your stories be even more about your users, using personas,
- Use testing tools beyong SOAPUI (and its Java API) : SOAP / REST Client & Poster Firefox plugins, jersey-test for jersey, proxy & monitoring with Membrane SOA,
- Yearn for formal constraints to help service composition (somehow addressed it in OW2 Scarbo’s semantic service search, the missing piece back then was – surprise – an SOA repository. In any way, the catch is that someone has to manage those constraints).
And a final high five to the attending friends, partners & other usual suspects !