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