Jolie, the service-oriented programming language

Re:Jolie, the service-oriented programming language by klag on Monday May 17, 2021 @08:30AM (#27182688)

In jolie, develoeprs program services instead of classes or functions. I think this is the main novelty introduced by jolie. Everything is a service, and you can postpone the decision on how to deploy an application. You can deploy it as a monolith (so your services will play the roles of classes, because they are internal) or independent services.

[ Parent | on HN ]

Re:Jolie, the service-oriented programming language by rajinl on Monday May 17, 2021 @09:20AM (#27183065)

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?

[ Parent | on HN ]

Re:Jolie, the service-oriented programming language by sidecut on Wednesday May 26, 2021 @01:08PM (#27293199)

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

[ Parent | on HN ]

Re:Jolie, the service-oriented programming language by klag on Monday May 17, 2021 @10:00AM (#27183486)

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.

[ Parent | on HN ]