41–50 of 78 posts
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.
Who actually wants this? People want good libraries for doing this with the languages they already use, not to have to make compromises just so they can have a microservice. Notice that the front page gives lots of examples of the servicey parts of the code, but absolutely no examples of what the business logic looks like. In fact, even in the documentation, the example code is minimal and trivial.
That's exactly my first thought. But: I'm currently working on a distributed Webassembly runtime. Jolie seems like a great way to describe your whole system. For each service the executed code would be a function exported by a Wasm module, written in the language of your choice.
Earlier quoted context omitted.
That's exactly my first thought. But: I'm currently working on a distributed Webassembly runtime. Jolie seems like a great way to describe your whole system. For each service the executed code would be a function exported by a Wasm module, written in the language of your choice.
Distrubted wasm runtime sounds interesting. Would you mind sharing a link to it? :)
Who actually wants this? People want good libraries for doing this with the languages they already use, not to have to make compromises just so they can have a microservice. Notice that the front page gives lots of examples of the servicey parts of the code, but absolutely no examples of what the business logic looks like. In fact, even in the documentation, the example code is minimal and trivial.
Earlier quoted context omitted.
I think the predominant question here is: why a language over, eg., a framework?
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-j…
> 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.
Who actually wants this? People want good libraries for doing this with the languages they already use, not to have to make compromises just so they can have a microservice. Notice that the front page gives lots of examples of the servicey parts of the code, but absolutely no examples of what the business logic looks like. In fact, even in the documentation, the example code is minimal and trivial.
It's a lot easier for full blown languages to offer servicey-like interfaces like Jolie than the other way around.
And as a matter of fact, most modern programming languages offer interfaces/traits/stubs/etc... that do just that.
A great example of a successful approach to this is Retrofit: https://square.github.io/retrofit/
Who actually wants this? People want good libraries for doing this with the languages they already use, not to have to make compromises just so they can have a microservice. Notice that the front page gives lots of examples of the servicey parts of the code, but absolutely no examples of what the business logic looks like. In fact, even in the documentation, the example code is minimal and trivial.
Who actually wants this? People want good libraries for doing this with the languages they already use, not to have to make compromises just so they can have a microservice. Notice that the front page gives lots of examples of the servicey parts of the code, but absolutely no examples of what the business logic looks like. In fact, even in the documentation, the example code is minimal and trivial.
I want it. At least the idea of it. I want something that looks like a programing language ( the mainstream ones ) that describes and specifies the flow of some functionality, not a YAML or a godforsaken XML file but also not XYZ framework that has all the implementation details. Maybe Jolie isn't what I want and has more baggage than I'm currently aware, but it somehow looks like something I need.
Earlier quoted context omitted.
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-j…
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 mor…
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.)