2

As the question states: When implementing "SOA", is it a concept intended for communication between systems over a network or is it intended as a concept that operates within the language as a pattern?

3 Answers 3

2

Service Oriented Architecture is an architecture, so the answer is neither.

It's not a design pattern within a language because it governs decisions far, far outside of the program design - notably, how all your business data is organized into services, which has a close relationship with your organizational structure. Even some of the technical concepts like fire-and-forget messaging are generally language-agnostic.

And it's not specifically related to communication between systems over a network because you could implement an entire SOA in a single process if you wanted to. The preferred method of service interaction in an SOA is in-process, and data or messages should only cross process boundaries when you specifically need to scale out. Even then, SOA is concerned with the logical rather than physical deployment. If you have a "billing service", the architecture says nothing about where that service is located, and parts of it may in fact be located in several different physical endpoints.

SOA lends itself well to distributed systems because of some of the other technical constraints it tends to impose, such as asynchrony and loose coupling. Distributed systems generally behave better when they treat the network as a network (i.e. don't depend on low latency/high bandwidth) and when components can all operate autonomously. But that's an outcome of SOA, not its goal.

An SOA is very simply the opposite of a canonical data model; in other words, each Service is like a little dictatorship that guards its data ferociously and won't share anything with any other service except what it absolutely needs in order to function. You can implement that in any programming language, and with (almost) any physical infrastructure.

3
  • So if a service is written and used in-process, it should only return domain data and nothing else? Any chance you could check this question out: programmers.stackexchange.com/questions/219305/… Nov 24, 2013 at 21:39
  • 1
    @Omega: Not trying to be condescending here, but you're not even in the right ballpark. Have you read anything about SOA? And if so, then what? A service is a conceptual boundary around a set of business functions and data. It's not an object and you don't "write" a service - not the kind of "service" that SOA refers to. What you're talking about is something like a "web service" which in SOA terminology is actually just an endpoint. As for "domain data", I'm not even sure what you mean; all of your data is domain data.
    – Aaronaught
    Nov 25, 2013 at 4:56
  • Oh, none taken! This actually isn't about me, I'm trying to get better explanations to assist others with understanding SoA and that it isn't a software design pattern to be implemented with a base class. Your reaction is in fact helpful and telltale. Nov 28, 2013 at 13:12
1

If you use it within a language as a pattern, you won't need some of the features of SOA:

  • loose coupling
  • mediated communication option
  • asynchronous communication (fire & forget messages)

So if you just want to have a clean contract between components, you can also do it without SOA. Write a design document instead.

If you suspect that you will need to replace some components with 3rd party components later, SOA is a viable way. However, because of the performance impact of the XML serialization/deserialization, you might need to consider using a shortcut option for internal communication. That can be done within a wrapper which uses the shortcut for internal and SOA for external communication.

2
  • When creating an SoA, do the classes implementing business logic themselves need to be aware of any form of transport, or is it still important to keep that separation within the process? Take a look at this question to get a better idea of what I'm asking: programmers.stackexchange.com/questions/219305/… Nov 24, 2013 at 21:40
  • 1
    In my company, we even have internal standards which forbid that business logic is included in a interface layer. So transport logic is in the API layer, no matter if SOA or whatever. THe common businness logic shall not care about the transport form. However, there is still some dependency mainly because of performance reasons: if you have an API which only returns one field from a complex business object, then the business logic layer might need to support that instead of reading the whole fat object. Nov 25, 2013 at 16:16
1

In SOA your business logic is broken down into logical components where each component is exposed as a service. Hence why it's an architectural concept. It's common for these components to be distributed across multiple physical devices, but it doesn't have to be that way. You may have multiple services running on a single machine.

SOA allows for horizontal scalability, as opposed to just vertical scalability (more horse power). SOA is often applied when working with enterprise applications. Imagine a large organization with multiple unrelated applications written in various programming languages. In order for you to get these applications talking to each other (integrate), you might want to expose their functionality through services.

A range of service standards is available on the internet: http://en.wikipedia.org/wiki/List_of_web_service_specifications#Web_Service_Standards_Listings

Development frameworks such as .NET hide the complexity of these standards by offering you tools such as ASMX web services and WCF (http://keithelder.net/blog/archive/2008/10/17/WCF-vs-ASMX-WebServices.aspx)

To summarise, it would be very difficult to integrate enterprise applications if standards and frameworks that I have mentioned above didn't exist.

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.