[rajinl]

thanks for the reply. My concern was people writing services that available on the network for trivial use cases, where a class or function would be faster and as reusable. You have addressed that concern. In light of your answer, is Jolie similar to an actor based pattern like Akka, with services being the abstraction rather than actors?

[sidecut]

I think it's akin to the original conception of OOP in Smalltalk, where objects are passed messages. (I've never written ObjectiveC, but I believe that's its paradigm as well.) In that, it's similar to the actor model used in Akka and in Erlang.

If you think of a service as being like a class -- as originally conceived by Smalltalk -- then sending it messages and acting on responses is the very definition of OOP, at least according to Alan Kay, the inventor of Smalltalk and of the term "object oriented programming."

There's an interesting discussion of the definition of OOP here. https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

[klag]

I am not an expert of Akka, but more or less the answer could be yes. I don't know if the following features are supported also in Akka:

- In jolie, it is quite transparent to develop a monolith or a distributed system of services. You always develop services and finally you can decide if deploy them as a monolith, or fragmenting the deployment into a distributed solutions (https://dzone.com/articles/between-monoliths-and-microservic...)

- Any input endpoint of Jolie (named inputPorts) can be exposed with different protocols (http/json, http/soap, sodep, etc) and you can have more inputPorts at the same time, thus you can receive messages for the same business logic from http/json, http/soap, etc. You can also split the available operations in different inputPorts. As an example you could receive admin messages in a https port, whereas you can leave in http teh public ones. But you can build meven more complex scenarios thanks to this feature.