Every now and then I get a question by email. I usually just answer them directly, but considering I got two such questions this week, and that I have’t blogged for awhile (I do have a post about YARN which I hope to finish soon), I thought I’d also publish my replies here.
Question #1 from Simon:
In your very interesting article “Bridging the Impedance Mismatch Between Business Intelligence and Service-Oriented Architecture” you highlight the challenges for BI and SOA to co-exist – that was 6 or so years ago – have you seen any advances that would cause you to revise that view?
Question #2 from Marc:
Great book! I have some trouble with ch 8.4. If you want say a service directly maps with n table representations on the DB, if n is the wrong thing I agree whith you. BUT, if a service is named ‘person’ and the result of get or put (a1b2c3) is a document of all the person's information, is it SOA or the old way? Personally, I implement this on a large insurance company. This type of service in an entity service, but I think for you it is a coarse service. Coarse, of course, because they are a lot of information. But it’s the more of a use and reuse service (it’s an attribute of thin service on other books). In fact we test this architecture deeply, and (because we make just one call) it’s more relevant than the RPC way (not for one call but it’s better after two calls, ex. Person + addresses.
I think I am not using it in the old way, but what’s your opinion?
PS sorry for my poor English, I’m French !
Thanks for the compliment on the book :)
It doesn’t sound like what you’re doing is the “same old way” anti-pattern. The point of that anti-pattern is to say that that if you just put an SOA name on something that is essentially an n-tier architecture and it isn’t really SOA. The same goes for artificially inserting a “service layer” without taking the steps to separate and isolate services anywhere besides that layer.
In any event, when designing architectures, getting to a SOA or a RESTful architecture is not a goal in itself. We can, and should, use design ideas from any paradigm and get something that is both a good fit for our problem and a sustainable solution for moving forward.