Our shop is attempting to move towards a more "distributed" architecture. I didn't want to use the term "SOA" because I'm not really sure if that's appropriate in our situation.

For each new feature that is developed, a new service (WCF in our case) is created specifically for that feature. A feature is defined as new functionality, which can be a brand new application or a new addition for an existing piece of software. As more features are added, the number of services that we need to maintain goes up. Each of these services are hosted in isolation and expose their own endpoint.

I don't have a lot of experience with distributed architectures or SOA in general, but this just feels wrong. Is there better way we can do this?

Instead of having separate services for each of these features, would it make more sense to logically group and consolidate some of these service into one large service and provide a "unified" API? Or would something like this tend to grow too large and become unwieldy/fragile?

7 Answers 7


One important aspect of SOA is that a SOA service is a commodity, or product. This isn't a technical issue, but a business issue. The same way you plan an application, consider it's clients demands etc.

The Business \ Product management overhead of developing a service should be similar to developing an application

Regarding the more "technical" aspects of your question.

  • A service may contain more then one operation - so you usually group related operations in one service.
  • There are various software suites (ESB - Enterprise Service Bus) that allow managing an environment with large number of services - like managing a repository of services, central routing, etc. - maybe you should consider using one

It does indeed sound like you have some kind of layering, granularity problem.

Single-function endpoints feels wrong, unless there are significant reasons for doing so - different security policies might be a driving factor here, but still does not seem right.

If you end up with too many services like


You have done little but extended method calls across the wire; which is likely to be slow given the overhead of the calls required.

There should generally be some non-trivial encapsulated business value behind each remote call to justify the overhead. Protocols that are too chatty don't tend to scale well, YMMV.


Distributed architecture does not work with buzzwords.

So what is SOA ... when does it make sense?

SOA is for huge corporates and is an approach to integrate heterogeneous back-end system into one infrastructure ... Anything else a service oriented application architecture.

but this just feels wrong

A service is nothing else than "module" or a group of "module" that exposes it's external interface in a fashion other technologies can interface in a reliable fashion. For anything else you don't need a service.

I you have little time check the Remobjects SDK for .NET. It is a little more complex example and you will get a more clear understanding of the direction you architecture can evolve and what parts are finally required - no need to take it - just investigate. This is very effective.

You application will still be an application, maybe split into autonomous acting parts. You will for sure have to decompose your application : seperate the concerns in the domain view.

Check the book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions you will see that there is lot more beyond simple services.


What you're trying to achieve is a CBA - Component Based Architecture. You basically classify your services and add them into a corresponding component. Refer to http://en.wikipedia.org/wiki/Component-based_software_engineering


I've run into these sorts of SOA setups before. Here are some things to watch out for:

  • Versioning. What happens when you have 5 different consumers of a service, and you want to add a 6th, but the 6th needs a feature that the other 5 didn't? So now you need a new version of the service, but does that mean you have to change the other 5?
  • Configuration. You are going to have to manage a lot of configuration "gunk" in order to point service consumers at service providers. This is where some of the SOA products (ESBs, etc.) help. But still in my experience this is always a challenge.
  • Knowledge sharing / consistency. Depending on how large your team is, it can be hard to keep consistency amongst the different services. One developer might use one set of standards for service A and another dev might use different standards for service B. Also, as more devs get involved, they might start duplicating each others work unknowingly, and you end up with two different services doing slight variations on the same functionality.

I'm not saying SOA is a bad idea. But you need to adopt it with your eyes open to the challenges. Good luck.


What you are building is a service-oriented architecture. In a true distributed architecture, the bound that controls granularity is inter-process latency, not functionality. The goal in true distributed processing is to maximize parallelism (e.g., Google's MapReduce framework).

With the above said, you should try to keep your service interfaces as uncluttered as possible. When in doubt, your should error on the side of the service interface being too simple. All complex services started as simple services that worked.


Many people think that SOA is focused on application integration. But the basic, SOA is an architectural style, where the system was designed in a way to divide the service, and service that interact with one another. Just like OOP, is a style of software development software by way of collaboration between objects.

Service was not just components are that can be accessed by remote as WebService, Rest, RMI, etc.

But the service are: A service is the technical authority for a specific business capability. Any piece of data or rule must be Owned by only one service.

What this means is that even when services are publishing and subscribing to each other’s events, we always know what the authoritative source of truth is for every piece of data and rule.

Also, when looking at services from the lense of business capabilities, what we see is that many user interfaces present information belonging to different capabilities – a product’s price alongside whether or not it’s in stock. In order for us to comply with the above definition of services, this leads us to an understanding that such user interfaces are actually a mashup – with each service having the fragment of the UI dealing with its particular data.

source: http://www.udidahan.com/2010/11/15/the-known-unknowns-of-soa/

To know about SOA, I suggest you to read source from the man Who I trust for a long time, He is Udi Dahan http://www.udidahan.com/?blog=true

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.