To avoid further confusion: I am not talking about web services and such. I am talking about structuring applications internally, it's not about how computers communicate. It's about programming languages, compilers and how the imperative programming paradigm is extended.


In the imperative programming field, we saw two paradigms in the past 20 years (or more): object-oriented (OO), and service-oriented (SO) aka. component-based (CB).

Both paradigms extend the imperative programming paradigm by introducing their own notion of modules. OO calls them objects (and classes) and lets them encapsulates both data (fields) and procedures (methods) together. SO, in contrast, separates data (records, beans, ...) from code (components, services).

However, only OO has programming languages which natively support its paradigm: Smalltalk, C++, Java and all other JVM-compatibles, C# and all other .NET-compatibles, Python etc.

SO has no such native language. It only comes into existence on top of procedural languages or OO languages: COM/DCOM (binary, C, C++), CORBA, EJB, Spring, Guice (all Java), ...

These SO frameworks clearly suffer from the missing native language support of their concepts.

  • They start using OO classes to represent services and records. This leads to designs where there is a clear distinction between classes that have methods only (services) and those that have fields only (records). Inheritance between services or records is then simulated by inheritance of classes. Technically, its not kept so strictly but in general programmers are adviced to make classes to play only one of the two roles.
  • They use additional, external languages to represent the missing parts: IDL's, XML configurations, Annotations in Java code, or even embedded DSL like in Guice. This is especially needed, but not limited to, since the composition of services is not part of the service code itself. In OO, objects create other objects so there is no need for such facilities but for SO there is because services don't instantiate or configure other services.
  • They establish an inner-platform effect on top of OO (early EJB, CORBA) where the programmer has to write all the code that is needed to "drive" SO. Classes represent only a part of the nature of a service and lots of classes have to be written to form a service together. All that boiler plate is necessary because there is no SO compiler which would do it for the programmer. This is just like some people did it in C for OO when there was no C++. You just pass the record which holds the data of the object as a first parameter to the procedure which is the method. In a OO language this parameter is implicit and the compiler produces all the code that we need for virtual functions etc. For SO, this is clearly missing.
  • Especially the newer frameworks extensively use AOP or introspection to add the missing parts to a OO language. This doesn't bring the necessary language expressiveness but avoids the boiler platform code described in the previous point.
  • Some frameworks use code generation to produce the boiler plate code. Configuration files in XML or annotations in OO code is the source of information for this.

Not all of the phenomena that I mentioned above can be attributed to SO but I hope it clearly shows that there is a need for a SO language. Since this paradigm is so popular: why isn't there one? Or maybe there are some academic ones but at least the industry doesn't use one.

  • 1
    Component-based architecture may be a requirement for SOA but SOA is not necessary for Component-based. OO systems that do not differ services from data structures can be Component-based too. Commented Jun 23, 2012 at 13:10
  • 1
    @Danny: I don't make a difference between CB and SOA. If you read the definitions of each of them, they are basically identical. CB is like pre-2000 and SOA i post-2000 because CB was considered "dead" at some point and nobody wanted to use the word anymore. I don't limit SOA to web services or such but refer to the programming paradigm.
    – Wolfgang
    Commented Jun 23, 2012 at 13:17
  • you might not defer between the two, but they are different. Read more on CB and its uses. Commented Jun 23, 2012 at 14:03
  • I tried for a long time to find a difference between CB and SO. Didn't find any feature of either one which the other one wouldn't also claim.
    – Wolfgang
    Commented Jun 23, 2012 at 14:14
  • Component based architecture can be seen as disconnecting dependencies between classes using interfaces, thus enabling dependency injection. Service based architecture requires that but it also provides other requirements, since it supports service and clients being remote. Commented Jun 23, 2012 at 17:36

5 Answers 5


Because <5% of code is actually defining a service, and I would argue a substantially less amount of time. Once the interface is defined, it's largely done. The rest of the time is spent in OO (or alternatives) making things work.

Simply put, it's not a big win to make a specialized language for that small slice of the problem. If anything, having two languages (one for the service and one for the implementation/consumption) is just asking for added integration complexity.

[edit for the OPs clarification that it's internal application layout, not application boundary]:

The main goal of having such a service layout is to have thin touchpoints between services. My original reason still holds (imo) and add to that answer the fact that relatively few problems suit themselves well towards an internal application structure that is service based. So not only are you addressing a small slice of the problem, but a lower percentage of problems overall.

  • That's an interesting point. But you could apply it to OO as well: most of the time it's imperative programming and only 5% is OO. OO is also a way of gluing imperative code snippets together while it's the imperative code that makes things work. Still, we benefit largely from having specialized languages for it. My point was that SO programs are written in OO languages because they seem to be similar but that leads to the problems given in the question.
    – Wolfgang
    Commented Jun 29, 2012 at 6:31
  • @Wolfgang in my experience the amount of imperative code is not that great.
    – Telastyn
    Commented Jun 29, 2012 at 11:04
  • @Wolfgang if that is the case, you are not using proper OOP, just procedural code with a OO coating Commented May 31, 2018 at 14:35

Functional languages are very service oriented at their core. Instead of creating objects and calling functions on them, you create functions and pass messages to them. Erlang is a prime example of this technique because even beyond the functional aspects of the language it does have inter-process and even inter-machine communication built into its core framework allowing you to send messages to a remote process as if it were a local process.

Other languages such as Scala, Clojure, and F# also provide "service-oriented" semantics. The problem isn't that they don't exist, it's that the general populace is afraid of them and so they aren't as popular.

  • 3
    Also Erlang has OTP which is really built around the idea of services and making them reliable. Building a server that will recover after a fault is easy in OTP. (It takes like 10 minutes of work)
    – Zachary K
    Commented Jun 25, 2012 at 4:13

Service Orientation was/is an architectural answer to integration problems. Integration ideally is an all-inclusive solution which fits any existing language, product, device, resource into a bigger picture.

There is no need for some new language, as the very problem is about having too many languages already, which causes high interoperability cost.

However, there was one kind of language introduced, the web service definition language. WSDL is meta language of S.O.A. (and there is another abandoned one for REST named WADL)

  • 2
    It's not the languages that create the interoperability problems. It's the structure of the applications. Some languages are better suited to build apps that interoperate, but interoperation is a function of the app not the language.
    – user53019
    Commented Jun 23, 2012 at 14:04

I'll turn the question around and ask "what would an SO language look like?"

How would those contracts between modules get written?
How would the fundamental mechanics of operation get executed?

Services oriented is a property of the application, not necessarily the language used. The service is a construct which relies upon a function. The function is a construct that relies upon the mechanics of a programming language to translate operation into machine executable instructions.

BPEL is a possible example of an SO language, but it is very high level and relies upon modules being available for it to utilize. Those modules are in turn written in non-BPEL languages so work can be performed (aka translated into machine language).

Great Q and gave me a good moment's reflection.

  • 1
    The biggest problem is getting rid of object references. I think Guice looks sometimes how it should be. But they have to fight too much with the fact the Java always needs a reference to an isntance of the service. For a service, you actually need the type only, no instance. Those singletons are just hacks.
    – Wolfgang
    Commented Jun 23, 2012 at 14:28

I'll offer an answer to my own question to see how many people agree and disagree.

Some possibilities:

  • It seems to be difficult to construct a SO language. Mostly because of the separation of the implementation of services and their composition. There are a couple of academic solutions I heard of at university (no reference, sorry) but it doesn't seem to make it into the industry. But I count this as a excuse, not a real reason. OO languages and compilers are pretty difficult to implement, too, yet there are solutions on the market for a long time.

  • Programmers use OO languages for SO because they don't understand OO and use it in a wrong way. I say wrong because there are two fundamental concepts in OO which contradict SO:

    1. Functionality goes to the class where the data is located that they work on. Code and data are coupled together in the same module. It's not OO style to have separate classes that work on the data of other classes. That's Züllighofen's Tools-and-materials approach (WAM) which matches the SO paradigm.

    2. Objects create other objects and form networks of objects. They can create hierarchies or whatever complex relations. Services always form flat networks which are composed from the outside. Services usually have only one instance (Singleton) whereas objects are instantiated as often as the entity they represent exists. Records in SO are not connected in networks.

  • Some features of OO look similar to SO, or can be used to facilitate what is needed for SO so it comes in handy to use a OO language.

    1. The dependency-inversion principle in OO is similar to the way services are composed externally.

    2. Singleton objects are like services, object factories are like service locators.

    3. OO also has interfaces which is similar to service interfaces.

    4. Inheritance of classes can similar (the same?) as inheritance of services and records.

  • OO and SO are useful for different kinds of problems. So in every applications it is tempting to use either paradigm here or there. Having a separate language would hamper switching between the two within the same program.

  • SO is not only a programming paradigm but also a program behavior: web services, operating system components etc. are SO but don't need to be written in a SO language necessarily. This kind of "binary components" is very natural and successful. But it's a different thing: it's how programs communicate with each other, not how the program communicates internally. I guess people mix that up often enough.

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.