Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A Couple of SOA Q&As

DZone's Guide to

A Couple of SOA Q&As

Free Resource

The Integration Zone is brought to you in partnership with Cloud Elements. What's below the surface of an API integration? Download The Definitive Guide to API Integrations to start building an API strategy.

SOAPatterns

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?

I think the gap and dissonance between SOA needs and BI needs is still there. However, in addition to event publishing mentioned in the article, I see the approach to getting BI on SOA becoming more standardized. I outlined that in my book under “Aggregated Reporting” patterns ( aggregated-reporting/) where essentially you create an immutable storage of historic data and let different services each update thier part of the big picture.
A trend that I've seen in the last couple of years is the adoption of Hadoop (and other big-data platforms) as a means to implement the aggregated reporting pattern. The advantage of a platform like Hadoop is the ability to handle poly-structured data and apply schemas on read which help alleviate the challenges of diverse data sources that flow into the aggregated reporting pool

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.

Your API is not enough. Learn why (and how) leading SaaS providers are turning their products into platforms with API integration in the ebook, Build Platforms, Not Products from Cloud Elements.

Topics:

Published at DZone with permission of Arnon Rotem-gal-oz, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}