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