Woah, so this happened. Maintainer here. I'll do my best to reply to all questions/doubts that get posted about an hour from now, since there is some valid feedback and there are some good questions in here.
Some more info at:
- https://dzone.com/articles/introduction-to-jolie (a brief introduction to Jolie and some concepts)
- https://hackernoon.com/a-detailed-introduction-to-service-or... (a deeper dive/discussion on some of the concepts)
Our (for now subjective) experience is that people who become familiar with Jolie are much faster at prototyping a service system, which makes it worth pursuing for us. Jolie code requires less boilerplate and state management for interesting scenarios. Two examples: communications can be natively composed in structures, e.g., the code
open()
close()
provide
[next(element)] { ..manage element here.. }
until
[end()] // stream ended here
Another big reason for exploring languages is discipline. Languages discipline how you write code. An example: in Jolie, you decompose software in terms of services. Many of these run locally as libraries, and are optimised by the interpreter by using hidden shared memory. But the language enforces that if you ever decide that a component should become an external, independent services, you can do it by updating a few references (input/output ports, our access points). See also https://fmontesi.github.io/2015/06/09/non-distributed-micros... Another example: Jolie discipline also gives you the ability of reusing the same business logic under multiple access points with different protocols.
This is the tip of the iceberg. In general, programming in terms of service abstractions is showing to be an interesting experience for us.
Phew, that was quite a bit for a "in a nutshell".. I hope that it's clear, otherwise, just write below.
> Jolie, you write code that maps directly to the concepts that matter. What are the important concepts? APIs, Access Points, and Services (duh..) are examples.
I come out of the Domain Driven Design school of thought, where the true key concepts are the domain-related ones. E.g., if you're doing ecommerce, things like Product and Order are much more important. They're also much more stable. Over time what gets exposed as an API will vary much more than whether or not we have a Product or an Order.
What you're calling important is what I think of as implementation details. Important in the sense that pipe fittings are important to a house: vital, but very much secondary to the purpose.
You're talking about the domain model, which I agree is more abstract and stable. It comes before making the implementation model. In the case of microservices, some concepts overlap and/or are very similar between domain and implementation, but some mapping is required. We started exploring a bit how to relate MDE languages to Jolie in https://arxiv.org/abs/2104.02458 and it looks pretty promising in the sense that they seem easily linkable.
In short: once you get to the implementation model and if this is service-oriented, Jolie gives you a concise and executable syntax to write it. (And there is ongoing work on how some elements of domain models can be mapped automatically to Jolie concepts.)
We are at historically bad levels of Interoperability because we don't really engineer software for management. We just call it an implementation detail.
Domains overlap. An e-commerce system will have a domain perspective to Infrastructure and the Infrastructure provider will have domain perspective on a Tennant like a specific e-commerce system. Bother are valid. There's real value in reducing the impedance between those views