Q
Problem solve Get help with specific problems with your technologies, process and projects.

Service autonomy: How it works with SOA and the data service layer

How does the data service layer affect service autonomy? Get an SOA and integration expert's take, plus learn how service autonomy works in developing a data services environment.

How can service autonomy and the data service layer live together in peace? If I understand service autonomy right, each service should have its own data and one should avoid shared access to resources wherever possible. Since service autonomy is one of the tenets of SOA, how will this be influenced by a data service layer -- a layer which seems to be a bit monolithic to me to fit into the SOA concept? Or am I misunderstanding something completely?
The whole idea behind service autonomy is to ensure that a particular service can be "self-sufficient" or autonomous in carrying out its defined task or responsibility. It's important to realize that when a service is interfacing to (or communicating with) another system, there will always be some level of dependency on the interfaces and existence of the other system. The idea of service autonomy is to ensure that the service can run in isolation in an autonomous fashion in a manner that shares as little as possible with any other entity. But obviously, if data is being passed to/from another entity, there's no way around some amount of dependency. That's where the use of standard interfaces becomes so important.

I'm not sure that your remark regarding a data service layer is any different than the coding practices associated...

with any shared or common reusable service. My take on this is to reduce the number or quantity of abstraction levels within your code. My perspective of developing a data services environment is to ensure that all code that communicates to the defined interface is self-contained (prior to passing the data to the interface). In the days of writing shared components (shared code libraries, objects, etc.), problems would inevitably crop up when someone changed the underlying code without telling anyone else. The focus should be to only interface to shared or common services that don't change.

This was last published in February 2010

Dig Deeper on SOA data services and architecture

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchAWS

SearchContentManagement

SearchOracle

SearchSAP

SearchSQLServer

Close