[fmontesi]

In a nutshell: because we want to minimise code <-> model distance. Other languages make you program in terms of functions, objects, etc., and make yourself model services by using these concepts. In 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.

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()

mandates that only the open operation is available at first and then only close is available (in object-oriented languages, you must encode this state with a private data field and manage it with if-then-else, etc.); likewise, streams in Jolie are consumed by writing

  provide
    [next(element)] { ..manage element here.. }
  until
    [end()] // stream ended here

which means "provide the operation next to invokers until operation end is called". A syntactically manifest approach to reactive programming and state machines, if you like.

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.

[wpietri]

Could you expand on this? I'm not seeing why the "duh" is warranted.

> 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.

[fmontesi]

I was indeed talking about implementation models, in particular models of service-oriented systems. These are usually formulated in terms of services, DTOs, APIs, business logic, etc., hence the value brought by Jolie in giving a direct syntactic representation. The model of an implementation can change often, so it's important to have code that resembles it closely (for readability, editing, etc.).

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.)

[wpietri]

Thanks for the explanation.

[rajandatta]

I'd say that you idea of Domaim is unduly restrictive. Yes, in an e-commerce or a merchandise based business, Products and Orders are domain objects. But services and ports and interfaces are every bit as real from a complementary domain - the domain Of software design and Technology Operations.

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

[wpietri]

It's true both are valid, but I think you miss that the domain of software design and technical operations is a) secondary to and dependent on the actual business, and b) far less stable than the domain. As somebody who has written software and done ops for decades, I certainly value it. But I think it's a mistake to put it on an equal footing with the actual purpose of the enterprise.