Show HN: Jolie – The First Programming Language for Microservices | Hacker News Reader

Show HN: Jolie – The First Programming Language for Microservices

jolie-lang.org

64 pointsfmontesi37 comments

How does this differ from say Erlang and OTP? (conceptually)

That is exactly what I wondered, sadly the page does not mention Erlang/OTP whatsoever.

Right, excellent question. We should put something in the FAQ. It's going to take some time to answer properly, but here are some initial pointers. Note that while I know Erlang academically I am definitely not an expert, so feel free to add more comments if you like.

Both languages are based on message passing, but Erlang is functional whereas Jolie is classical imperative/stateful.

Jolie provides architectural programming, e.g., you can make proxies abstracting from the behaviour of what you are composing with a language primitive.

Jolie provides integration natively, e.g., with automatic data transformations between different data protocols. The contract with the developer is that if you need to change protocols or deployment information (e.g., switch from TCP/IP to Bluetooth L2CAP or in-memory communication), you just have to change a couple of lines in the deployment part of a Jolie program and the rest will continue working without modifications to the program logic (logic/deployment decoupling).

Jolie has dynamic fault handling: fault handlers can be updated at runtime compositionally (higher-order code composition), which is afaik a new thing.

Another thing: the fact that it is imperative does not mean that we suffer from all the side effects. You cannot share data among different microservices, you must use communications (if you need performance, communications can be in-memory). The imperative paradigm (mixed with workflow programming) is used only for internal state manipulation, so that it is safer for concurrent programming.

I should really get down to write all of this in the FAQ page.. ;)

None of those concepts seem unique to Jolie compared to Erlang, but I have yet to understand the concepts of Jolie well enough to figure out if something is conceptually different.

Architectural programming: gen_server is a fine example.

Integration: Erlang is opinionated but as soon as you have a lens to erlang terms, everything is easy. This is the point where Jolie may have an advantage.

Dynamic fault handling is subsumed by dynamic code loading.

I would be very interested in seeing a comparison with gen_server, it looks interesting.

Embedding in Jolie looks like a language primitive implementing something that resembles some of the ideas found in supervision trees.

AFAIK, dynamic fault handling is not subsumed by dynamic code loading in the specific case of request-response operations in parallel code (http://iospress.metapress.com/content/p0647559l8455778/?issu..., see my webpage fabriziomontesi.com/research.html for the pdf), but if that's relevant for the comparison with Erlang, I don't know. In all other cases your statement is correct. It's subsumed also in that case if you allow for dynamic code loading in the middle of waiting for a response for a request in a request-response invocation.

Another point which may be interesting: in Jolie a process inside of a microservice can have many input queues. Which messages go in which queue is decided by (an easier form of) correlation sets, basically a declarative part of the program where the programmer tells which parts of messages identify the queue in which they must go. These can be application data or even HTTP cookies, we use this features a lot for integration.

It looks like another interesting difference may come from the workflow primitives (e.g., sequence, parallel, input choice) that Jolie comes with.

In my experience the biggest frustration when building microservices is the replicated logic across multiple languages/frameworks. For example if my microservices are in node/io.js and my app a rails app, then I can't replicate my model logic in my node services. Have you done anything in the jolie language to help this problem?

It may be the late hour here (CET), but I only kinda understood your question. What do you mean by "I can't replicate my model logic in my node services" ?

I think by "model logic" he is referring to MVC and things like data model relationships (and an ORM possibly), validation/casting, etc.

For example, in a single programming language and framework you could say:

payment.isPayPay()

from a payment out of a database wrapped into a model.

It has not been traditionally easy to share that business logic across languages (and by easy I mean not wrapping huge numbers of methods in http requests).

This is correct. Business logic that exists in the model methods like in an MVC framework talking to backend services. When you have micro services in general you tend to have logic replicated in all the different micro services and even the consumers of those services.

Thanks, I get it now.

If you use Jolie for implementing MVC, then every component is automatically a microservice (by construction from the language) and you can reuse them very easily in Jolie, Java, and Javascript inside of web browsers.

If you use other languages:

- if you need to use logic handled by a Jolie microservice, then you just need an API for making remote calls to that microservice. Jolie provides HTTP/JSON, HTTP/XML, SOAP, SODEP, XML-RPC, Java RMI, HTTP/GWT, and others. We have native libraries in Java (also usable in Scala) for making it even easier and look more native. You do not need to consider which protocol you will use in your logic, Jolie separates data format from logic by design. So it boils down to how easy it is to make remote calls in the "client" language.

- if you have programmed your logic in another language, you will need to expose it somehow to Jolie. If you use Java or Javascript, we can reuse it natively or almost natively. Otherwise, you will need to expose the functionalities using one of the protocols above, then Jolie will immediately see it as a native service as if it were implemented in Jolie (we make no difference between stuff implemented in Jolie or not if you support any of our communication means).

Is this a satisfactory answer? We can dive into examples if you have something specific in mind.

> For example if my microservices are in node/io.js and my app a rails app, then I can't replicate my model logic in my node services.

Why would you want to do this? If something is the responsibility of one service, why is another service or app duplicating its logic?

Perhaps several layers of input data validation? Typically the problem is that you want the client side (ie: javascript) to do form validation for early-feedback to the user, and the back-end to do actual input filtering/validation -- but I suppose one might want to push input-errors/validation-errors as far out towards the input as possible -- also in case of a web of micro-services? Things like allowing only utf8, or maintaining data integrity for relationships (eg: in order to add dependants to a person, those need to be defined with some kind of minimal data, like a social security number?).

I am a bit puzzled as well -- I normally think of this as a problem of synchronizing back-end and front-end -- but then again, if you have a proper SQL-schema, with a thin REST-layer abstraction/API on top, you'd probably have to have other services know about your models in order to do input-validation before attempting to post/insert/update data?

What we can do right now is having a microservice for input validation and call it when we need to validate something, both from the client and the server parts. In Jolie, adding calls to a validator for all functionalities exposed by a microservice is easy with courier constructs (http://docs.jolie-lang.org/#!documentation/architectural_com...).

However, if your client application is a web app, that may mean generating a lot of traffic between clients and web server.

In theory, we could make a tool for automatically propagating validation checking from Jolie to client code, but that's a hard problem because some checks depend on information that only the server knows, so sometimes you need to make remote calls anyway. Not all hope is lost, because in many cases a static analysis could tell us what can be safely exported to the client and what cannot.

I am not sure I understood well the question but I hope this answer could help you. Usually in Jolie we proceed as follows: - the logic (the one which should be replicated) is served by one microservice (which could be embedded or deployed separately, it doesn't matter). Let me call it L. - the other entities which requires that logic just invoke the microservice L - in the case of the web app, we use Leonardo (http://sourceforge.net/projects/leonardo/), which is a web server written in pure Jolie, we public the calls to L by simply adding them in few lines of code through aggregation. In this case Leonardo, which serves the http protocol, just take the message, transform it in another protocol (we usually exploit sodep for Jolie to Jolie communication) and redirect the message to L which exectues the logic.

So... the code[1] for Leonardo is certainly short and sweet -- but is this considered a production-grade web server? I doesn't appear to do anything in parallel (no "|" in the code, anyway) -- is this a thin wrapper around something more robust in the Jolie standard lib/run-time?

[1] http://sourceforge.net/p/leonardo/code/HEAD/tree/trunk/leona...

If not Leonardo -- is there some production-quality, yet simple, code that one could look at to get a feel for how an actual Jolie service might look? Say a micro-blogging site or something?

Always interesting to see new languages and platforms!

Leonardo is almost production ready, we usually just add some lines to tune the caching parameters as needed.

This is the code for the Jolie website if you're curious about an example:

https://sourceforge.net/p/jolie/code/HEAD/tree/web/trunk/jol...

We launch leonardo/leonardo.ol on the server.

The reason for which Leonardo works is that "execution { concurrent }" line which tells Jolie to start a new (light) process whenever a top-level operation is invoked. In this case we have only default, a catch-all operation for serving requests for files. So each time a client invokes Leonardo, a new process handles the request. Jolie processes are implemented as threads (cached in a thread pool when possible) with a local state (no data sharing, only communications).

Notice that in Leonardo we are embedding frontend.ol, which means that it will be run as a sub-service. And we also aggregate it in the HTTP input port, which means that its operations become available to clients. So now clients can not only invoke the catch-all default operation, but also the operations in frontend.ol.

Looking at frontend.ol, you will find one of these operation, e.g., "news". That's what you access when you go to http://www.jolie-lang.org/news

What does it do? It uses another sub-(micro)service, a blog reader, to fetch blog entries from our news blog, and then displays it to the user.

It's all a bit crude, in the enterprise we don't usually build html from scratch, but the Jolie website was so simple that we just went for it.

Looks interesting, but "It is used in Computer Science research and teaching at many universities around the world." turns into "It's had papers about it published by the same handful of researchers for the last decade" when you actually look at the references.

Consider toning down the sales pitch and focusing on the language.

We are in the middle, you know :-) Usually the academic part ask to us to focus more on the research topics instead of the language details (they usually call them "details" :-)).

We believe both of the aspects are very important. There are formal models behind the language which are, and will be, very useful for building analysis and verification tools

For anyone who is interested, the implementation is as an interpreter and runtime implemented in Java[1].

[1] http://sourceforge.net/projects/jolie/

Is there a git repo anywhere, out of curiousity? (Perhaps I'm being blind?) This looks interesting..

Like marktangotango wrote, the official repository is at [1]

May I ask why you prefer git? For cloning/forking the project?

[1] http://sourceforge.net/projects/jolie/

> May I ask why you prefer git? For cloning/forking the project?

Not that it's difficult to break out of the cycle, and download a tarfile and so on but.. Yeah, creature of habit... git's part of the workflow these days.

(for better or worse!)

We are in the process of moving to github, but it is not a high priority right now and we have so many things to reconfigure in our servers that it is not going to happen until March at the earliest. Meanwhile you can use svn:

svn co svn://svn.code.sf.net/p/jolie/code/trunk jolie-src

You can also browse the code here:

https://sourceforge.net/p/jolie/code/HEAD/tree/

wow really well done, now need some code samples in definitely languages to illustrate this :)

I recently posted here[1] a tutorial on how to implement quicksort as a service in Jolie. I think it could be a good starting point to learn some of the main features of the language.

You can find a good deal of examples also in the official documentation [2].

[1] https://news.ycombinator.com/submitted?id=thesave [2] http://docs.jolie-lang.org

I stopped reading when I saw the word "SOAP".

Why? Most modern tools are pretty good at Json, but SOAP is still everywhere, especially health care. And, current support for SOAP in modern tools could be better (outside of.Net land).

OK, from that perspective it makes sense - if there are some APIs you just can't go without. I just don't want to touch SOAP ever again, not even with a 10 foot pole. But maybe if this makes SOAP invisible it could be acceptable - although I don't see how that could be possible.

Short answer: we usually don't use SOAP unless it is strictly necessary in your system. We have simpler and/or more efficient protocols.

Long answer:

We do not use SOAP when it is not strictly necessary. Most Jolie programs use SODEP (our own open binary protocol) or HTTP/JSON or HTTP/XML. You do not need to deal with this manually, you just tell Jolie "use HTTP" or "use SODEP" in the deployment part. For example, this is how you expose your service in SODEP:

inputPort MyService { Location: "socket://localhost:80" Protocol: sodep Interfaces: MyIface }

and this is how you get the same thing but in HTTP:

inputPort MyService { Location: "socket://localhost:80" Protocol: http Interfaces: MyIface }

If you use Jolie to provide a SOAP service, it will most probably be completely invisible. You just have to choose soap and you are done:

inputPort MyService { Location: "socket://localhost:80" Protocol: soap Interfaces: MyIface }

Jolie will take care of using the right data formats without you noticing.

If you need to access an external SOAP service, there are many cases in which it can be invisible, but also many other cases in which you will have to tell Jolie some extra parameters in case some extensions or weird details need to be used.

Shame its GPL'd.

The website is published under creative commons and GPL (code examples) but the Jolie codebase is published under LGPL.

Maybe this is a good hint that we should clarify this in the footer. :)

Do not mind the other guy. Thank you for making it GPL'd. As a potential user, I thank you.

Code examples should be in public domain.

Reply on news.ycombinator.com