Why is there no service-oriented language?

Question

Edit:

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.

Original:

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.

Answer 1

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.

Answer 2

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.

Answer 3

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)

Answer 4

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.

Answer 5

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.