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.
I should really get down to write all of this in the FAQ page.. ;)
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.
Why would you want to do this? If something is the responsibility of one service, why is another service or app duplicating its logic?
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?
[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!
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).
Consider toning down the sales pitch and focusing on the language.
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
svn co svn://svn.code.sf.net/p/jolie/code/trunk jolie-src
You can also browse the code here:
May I ask why you prefer git? For cloning/forking the project?
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
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!)
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.
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.
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.
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.
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.