tag:blogger.com,1999:blog-38566248621316725922024-03-13T22:05:23.021+01:00Fabrizio Montesifmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.comBlogger32125tag:blogger.com,1999:blog-3856624862131672592.post-73343679586958786732015-06-09T12:54:00.002+02:002015-06-09T14:58:32.364+02:00Non-distributed Microservices<div dir="ltr">
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX31KDiwOYeIOv3v4k0Idu_tx_rw1rjGtabqapblRlC3Zj-aiohctCfpgJA6z3ifWAxnazXc5OFTNJe6z1XO2PX7xqWwfil5fa_al9SACRHaJlyKVDWrG-P3r_ZpWM_ZZOylF2N48KpdAa/s1600/puzzle-654957_1280.jpg" imageanchor="1" style="clear: left; display: inline !important; float: left; margin-bottom: 1em; margin-right: 1em; text-align: center;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX31KDiwOYeIOv3v4k0Idu_tx_rw1rjGtabqapblRlC3Zj-aiohctCfpgJA6z3ifWAxnazXc5OFTNJe6z1XO2PX7xqWwfil5fa_al9SACRHaJlyKVDWrG-P3r_ZpWM_ZZOylF2N48KpdAa/s200/puzzle-654957_1280.jpg" width="200" /></a><br />
Thanks to Martin's <a href="https://github.com/jolie/jolie/pull/45" target="_blank">great</a> <a href="https://github.com/jolie/jolie/pull/48" target="_blank">help</a>, <a href="http://www.jolie-lang.org/" target="_blank">Jolie</a> 1.4 will have support for <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/internal_services.html" target="_blank">Internal Services</a> and enhanced <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/embedding_jolie.html" target="_blank">local locations</a>. If you feel like testing, you can already find it in <a href="https://github.com/jolie/jolie" target="_blank">our git repository</a> (see <a href="http://jolie-lang.org/downloads.html" target="_blank">compile from sources</a>).<br />
While these features do not add any essential expressiveness to Jolie, they make it easier to program non-distributed microservice architectures (NMSA here for brevity). "Wait" - I hear you - "NMSAs?"<br />
<br />
<a name='more'></a><br />
<h2>
Non-distributed Microservice Architectures (NMSAs)</h2>
<div>
When I teach somebody (students or professionals) how to program microservices, I pay attention to following a very gradual path. The fact is, there are simply too many things to worry about when you program Microservice Architectures (MSAs). If you are not an expert, you are going to get overwhelmed by the complexity. Even if you are an expert, you may be better off with the <a href="http://martinfowler.com/bliki/MonolithFirst.html" target="_blank">MonolithFirst</a> approach.<br />
<br />
But why are Microservices so complicated? The main reason is that an MSA is typically distributed, and distributed computing is hard (see <a href="http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing" target="_blank">the fallacies of distributed computing</a>). So, intuitively, it is much simpler to start with a monolith, and switch to microservices later. Unfortunately intuition is not really met by reality here. Developing a monolith does not force programmers to make their components modular and loosely-coupled enough to be smoothly ported to microservices; for example, it is way too tempting to share resources and/or develop APIs that are not suitable for message passing. Most probably, your initial monolith will end up being a <a href="http://martinfowler.com/bliki/SacrificialArchitecture.html" target="_blank">SacrificialArchitecture</a>. This is not necessarily a bad thing: many successes were built on top of sacrificing architectures. I am more worried about the fact that this is not really a smooth learning process: develop a monolith, learn something, now change everything.<br />
<br />
NMSAs is a style where you program your system <i>as if it were an MSA, but without the distribution</i>. In an NMSA, Microservices are run concurrently in the same container (in our case, a Jolie-controlled JVM). It is an attempt at providing an easier setting for learners and experimenters to start with: no distributed computing means no fallacies of distributed computing. What can you learn in such an environment? A great deal, including:<br />
<br />
<ul>
<li>You can learn how to develop loosely-coupled service interfaces, and how to deal with message passing in the easier setting of a perfectly-working "network".</li>
<li>You can learn how to test your services, and how to automatise testing.</li>
<li>You can learn how to monitor service execution.</li>
</ul>
The idea is to first approach the programming of microservices in this simpler ("fake", if you like) setting, and learn how to deal with distribution later. In the Jolie programming language, this path from NMSAs to MSAs is supported by the language itself.<br />
<br />
<h2>
NMSAs first...</h2>
</div>
NMSAs are created in Jolie by using <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/embedding.html" target="_blank">embedded</a> or <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/internal_services.html" target="_blank">internal services</a>, i.e., services that run locally in the same container of the main service program. I will refer to such services as "local services" here. All components that you can write in Jolie are services, therefore all the architectures that you write in Jolie are service-oriented by design. This means that components cannot share state, and must interact through service interfaces based on message passing. What happens behind the scenes depends on the deployment information that you specify for your services, which is kept separate from the application logic. If the case of a local service, messages are efficiently communicated via shared memory, but without breaking the message passing abstraction given to the programmer.<br />
<br />
Here is a toy example of a program using local services (you can of course split this in multiple files; oh, and I'm omitting what happens in case we do not find some records or files):<br />
<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace;">service Images {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> Interfaces: ImagesIface</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> main {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get( request )( img ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> fetch@ImageDB( request )</span><span style="font-family: 'Courier New', Courier, monospace;">( img )</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span>
<span style="font-family: 'Courier New', Courier, monospace;">service Products {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> Interfaces: ProductsIface</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> main {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get( request )( response ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> query@ProductDB</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> ( "select name,desc,imageurl from products where id=:id"</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> { .id = request.id } )</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> ( response )</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span>
<span style="font-family: 'Courier New', Courier, monospace;">main {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> viewProduct( request )( product ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get@Products( { .id = request.id } )( product );</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> if ( request.embedImage ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get@Images( { .url = product.imageurl } )( product.image )</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<div>
<br />
The program above is a simple service to access product information. It offers one operation, viewProduct, that clients can invoke with a message containing the id of the product they want to see (as a subnode of request). The service then invoke the internal service Products, which queries a database for some basic information and returns it. The product information contains an URL to an image depicting the product. Then, the main program checks whether the original client requested the image to be embedded in the response (useful, e.g., for mobile applications that want to minimize the number of message exchanges); if positive, the image is added to the response by fetching it from the Images service.<br />
<br />
The main service, Images, and Products communicate using shared memory in the Jolie implementation of internal services. Communications are therefore always going to succeed, but each service has its own interface and state and the style is still message passing. Hence, internal services can be used to teach how to design a loosely-coupled architecture.<br />
<br /></div>
<h2>
...and MSAs later</h2>
<div>
NMSAs are expressive enough to teach, e.g., how to deal with concurrency issues (each service has its own processes), message passing interfaces, and good API design. They are also fairly easy to achieve, relieving beginners from the frustrations of service deployment.<br />
<br />
After a while, however, an NMSA that needs to scale has to evolve into an MSA, by taking some internal services and making them distributed. Distributing an internal service in Jolie is easy. Simply put, take the code of the internal service you want to distribute and execute it with a separate interpreter in another machine (<a href="http://www.italianasoftware.com/products.html" target="_blank">Jolie Enterprise</a> automatises this job for you in a cloud environment, but you can use the tools of your choice).<br />
<br />
The main service now needs to be updated to refer to Images and Products as external distributed services:<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace;">outputPort Images {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">Location: "socket://images.example:8080"</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">Protocol: sodep</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">Interfaces: ImagesIface</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span>
<span style="font-family: 'Courier New', Courier, monospace;">outputPort Products {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">Location: "socket://products.example:8080"</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">Protocol: sodep</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">Interfaces: ProductsIface</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span><span style="font-family: 'Courier New', Courier, monospace;">main {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> viewProduct( request )( product ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get@Products( { .id = request.id } )( product );</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> if ( request.embedImage ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get@Images( { .url = product.imageurl } )( product.image )</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<br />
Basically, we have replaced the code for each internal service with a respective <a href="http://docs.jolie-lang.org/#!documentation/basics/communication_ports.html" target="_blank">output port</a>. The rest of the code does not change (again, a key aspect of developing services with Jolie is that deployment is kept as separate as possible from behaviour). However, now the system is distributed. Among other consequences of this, communications with services Products and Images may now fail! In practice, this means that the invocations get@Products and get@Images can throw network-related faults now, and we must account for that. If we leave the code like this, such faults are going to be automatically propagated to clients. This may be undesirable. A better strategy could be:<br />
<br />
<ul>
<li>If we fail to get the product information, we immediately return an informative fault to the client.</li>
<li>If we manage to get the product information but fail to get its image, we should return at least the product information with a placeholder blank image.</li>
</ul>
<div>
We update the code accordingly, using <a href="http://docs.jolie-lang.org/#!documentation/fault_handling/basics.html" target="_blank">dynamic fault handlers</a>:</div>
<br />
<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace;">main {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> viewProduct( request )( product ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> scope( s ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> install( default => throw( ProductsCurrentlyUnavailable ) );</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get@Products( { .id = request.id } )( product )</span><span style="font-family: 'Courier New', Courier, monospace;">;</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span>
<span style="font-family: 'Courier New', Courier, monospace;"> install( default => product.image = BLANK_IMAGE );</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> if ( request.embedImage ) {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> get@Images( { .url = product.imageurl } )( product.image )</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<br />
There we go. Now our code accounts for network errors (actually any error, since I used the default handler, which catches any fault). There are, of course, many other things to watch out for, e.g., distributed monitoring, crash recovery, and performance. However, this small example gives already an idea of the overall methodology.</div>
<h2>
Gotcha</h2>
<div>
Although Jolie does its best in not allowing resource sharing among services (they simply cannot be shared, by the language syntax), this can always be circumvented via external side-effects. For example, two internal service may share access to the same file system. However, this can also be abstracted from: in Jolie all accesses to the file system happen through the File service from the standard library which, being a service, can also be distributed.<br />
<br />
<h2>
Conclusions</h2>
<div>
The microservices style arises out of practical needs, and although it should be used only when necessary, sometimes it is appropriate. I believe that we should find ways to guide a smoother transition from monoliths to microservices, and that finding such ways is possible. This is a rough attempt at giving a first piece of the puzzle towards building such a transition model.</div>
<div>
<br /></div>
<br />
PS: I should really try to come up with better acronyms.<br />
PPS: If you have interesting examples to share in other languages, please feel free to do so!</div>
</div>
fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com5tag:blogger.com,1999:blog-3856624862131672592.post-80556196694809276612015-05-04T14:47:00.003+02:002015-05-04T15:16:51.577+02:00Evaluating the Design of a Microservice<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhccJUlaN_wBKT0BisaKJMHjh4nmVxbWzVcIhbf__uZ2siR4JJtun0Ux56rLxNOHZQ8-p5K9B2npeG-_Co1OpiOsu53GnNFm61TJPZAt6A8F3P-AYLFzydYiSJFYIKlvPg_xASxtamaxhlY/s1600/stock_task.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhccJUlaN_wBKT0BisaKJMHjh4nmVxbWzVcIhbf__uZ2siR4JJtun0Ux56rLxNOHZQ8-p5K9B2npeG-_Co1OpiOsu53GnNFm61TJPZAt6A8F3P-AYLFzydYiSJFYIKlvPg_xASxtamaxhlY/s1600/stock_task.png" /></a></div>
<br />
I made a little rubric for evaluating the design of Microservices. Keep in mind that it is still very preliminary. If you have comments, I would be more than happy to discuss them with you.<br />
<br />
Find it here:<br />
<br />
<div style="text-align: center;">
<a href="https://github.com/microservices-course/material/blob/master/rubrics/design.md">https://github.com/microservices-course/material/blob/master/rubrics/design.md</a></div>
fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-38388815333957781632015-02-06T15:44:00.001+01:002015-02-10T13:40:29.651+01:00Programming Microservices with Jolie - Part 1: Data formats, Proxies, and Workflows.In <a href="http://en.wikipedia.org/wiki/Microservices" target="_blank">Microservice</a> architectures, software components are built as reusable and scalable services that interact with each other. While this introduces many advantages, it also brings all the issues of distributed computing to the internals of software applications and developers <a href="http://martinfowler.com/articles/microservices.html" target="_blank">need to be careful about this</a>. Luckily, we are standing on the shoulders of all the knowledge that we accumulated by using <a href="http://en.wikipedia.org/wiki/Service-oriented_architecture" target="_blank">Service-oriented Architectures</a> (SOAs), so we are more aware of these issues and we have more technologies and methodologies to deal with them. Microservices could (and I believe they will) fly after all, in one form or the other, and we at the <a href="http://www.jolie-lang.org/" target="_blank">Jolie</a> team are surely not the only ones sharing this <a href="http://www.infoworld.com/article/2864453/application-development/why-2015-will-be-the-year-of-microservices.html" target="_blank">optimism</a>.<br />
<br />
But like SOAs were, Microservices are also at risk of exposing programmers to too much complexity to deal with when they take their first steps in this world. And we are at risk again of making arbitrary technology choices that we may regret later, just like <a href="http://en.wikipedia.org/wiki/SOAP" target="_blank">SOAP</a> was in many cases.<br />
<br />
In developing <a href="http://www.jolie-lang.org/" target="_blank">Jolie</a>, a microservice-oriented programming language, we are trying to make microservice programming simple and productive. A major challenge in this is <b>how we can map design ideas for a microservice architecture to code as fast as possible</b>, without committing to specific implementation details on communications and service deployment/distribution.<br />
<br />
The problem of focusing on design issues and not getting locked inside of interoperability problems is particularly dear to me. Jolie helps in this, e.g., by abstracting application logic from the underlying data formats that you will use for communications.<br />
<br />
Another problem that is dear to the team in general and I will talk about below is that of making composition of microservices easy. This does not simply mean composition of the operations offered by microservices, but also dealing with how we can deploy new systems based on previously developed systems.<br />
<br />
But talk is cheap. Let's do code and see an example.<br />
<br />
<br />
<h2>
Get Jolie</h2>
You don't need to have Jolie installed to read this article, but if you want to try what I will show, <a href="http://jolie-lang.org/downloads.html" target="_blank">go install Jolie</a>.<br />
Ready? Let's proceed.<br />
<br />
<br />
<h2>
A calculator microservice</h2>
We are going to program a little toy calculator microservice for making additions. Feeling lazy? Download the code <a href="http://fabriziomontesi.com/files/blog/jolie_microservices_part1.zip" target="_blank">here</a>.<br />
Open a file and call it <span style="font-family: Courier New, Courier, monospace;">calculator.ol</span><span style="font-family: inherit;">.</span><br />
<span style="font-family: inherit;">Then we write:</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">include "calculator.iol"</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">execution { concurrent }</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">inputPort CalcInput {</span><br />
<span style="font-family: Courier New, Courier, monospace;">Location: "socket://localhost:8000"</span><br />
<span style="font-family: Courier New, Courier, monospace;">Protocol: sodep</span><br />
<span style="font-family: Courier New, Courier, monospace;">Interfaces: CalcIface</span><br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">main</span><br />
<span style="font-family: Courier New, Courier, monospace;">{</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>sum( req )( resp ) {</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>resp = req.x + req.y</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>}</span><br />
<br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
Above, we are telling Jolie that this microservice is concurrent, i.e., each request is handled in parallel by a lightweight process (Jolie processes are implemented as threads with a local state).<br />
The input port CalcInput states that the service can be accessed using TCP/IP sockets on port 8000, using the <a href="http://docs.jolie-lang.org/#!documentation/protocols/sodep.html" target="_blank">SODEP</a> protocol. CalcIface is the exposed interface, which we define in the included file <span style="font-family: Courier New, Courier, monospace;">calculator.iol</span><span style="font-family: inherit;">:</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">type SumT:void {</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.x:int</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.y:int</span><br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">interface CalcIface {</span><br />
<span style="font-family: Courier New, Courier, monospace;">RequestResponse: s</span><span style="font-family: 'Courier New', Courier, monospace;">um( SumT )( int )</span><br />
<br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<div>
<br /></div>
<div>
<span style="font-family: inherit;">CalcIface is an interface with only one Request-Response operation called sum, which receives a tree with two nodes (x and y, both integers) and returns an integer.</span></div>
<div>
The sum operation is implemented in the main procedure of the calculator microservice: it simply receives the message on variable req and replies with the sum of the two subnodes x and y to the invoker.</div>
<div>
<br /></div>
<div>
<br /></div>
<h2>
<span style="font-family: inherit;">Using the calculator</span></h2>
<div>
<span style="font-family: inherit;">Using the calculator service from Jolie is easy. We create a </span><span style="font-family: Courier New, Courier, monospace;">client.ol </span><span style="font-family: inherit;">program, include the interface and off we go:</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<div>
<span style="font-family: Courier New, Courier, monospace;">include "calculator.iol"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">include "console.iol"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">outputPort Calculator {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Location: "socket://localhost:8000"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Protocol: sodep</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Interfaces: CalcIface</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">main</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">{</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>with( req ) {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.x = 3;</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.y = 2</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>};</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>sum@Calculator( req )( resp );</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>println@Console( resp )()</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div style="font-family: inherit;">
<br /></div>
</div>
<div>
<span style="font-family: inherit;">Running this client program will reach the calculator service and print the number 5 on screen. SODEP is a binary protocol, so you don't need to worry about overhead as much as you have to in, e.g., SOAP.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
The attentive reader may have noticed that in our client code we are calling the println operation of the Console service, just like we are calling the sum operation of calculator. That's right, even our Console library is a microservice that you can relocate as you like.</div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<h2>
<span style="font-family: inherit;">OK, but what if the rest of my system is not in Jolie?</span></h2>
<div>
<span style="font-family: inherit;">Jolie is interoperable with many other technologies, both server- and client-side. Let's see what happens if our client is not written in Jolie and does not support SODEP. Let's say instead that it's a web browser and that it consequently uses HTTP.</span></div>
<div>
Take the calculator program again and add the following before the main procedure:</div>
<div>
<br /></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">inputPort CalcWebInput {</span><br />
<span style="font-family: Courier New, Courier, monospace;">Location: "socket://localhost:8080"</span><br />
<span style="font-family: Courier New, Courier, monospace;">Protocol: http</span><br />
<span style="font-family: Courier New, Courier, monospace;">Interfaces: CalcIface</span><br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: inherit;">Et voil</span>à, now calculator is not only exposed on TCP port 8000 with SODEP but <b>also</b> on TCP port 8080 with the HTTP protocol. Run calculator and you can now point your browser to:<br />
<br />
<div style="text-align: center;">
<a href="http://localhost:8080/sum?x=3&y=5" target="_blank">http://localhost:8080/sum?x=3&y=5</a></div>
<br />
You will see calculator crunching the numbers and reply with:<br />
<br />
<div style="text-align: center;">
<span style="font-family: Courier New, Courier, monospace;"><span class="html-tag" style="font-size: 14px;"><sumResponse></span><span class="text" style="font-size: 14px;">8</span><span class="html-tag" style="font-size: 14px;"></sumResponse></span></span></div>
<span style="font-family: Courier New, Courier, monospace;"><span class="html-tag" style="font-size: 14px;"><br /></span></span>
You can use many other protocols (HTTP/JSON, SOAP, local memory, ...) and communication mediums (Bluetooth, UNIX sockets, ...), depending on your needs. See <a href="http://docs.jolie-lang.org/#!documentation/protocols/introduction.html" target="_blank">here</a>.<br />
<br />
<br />
<h2>
What if I cannot change the code of my microservices?</h2>
</div>
<div>
<span style="font-family: inherit;">If your calculator is a black box that you cannot or do not want to touch, then you cannot just edit its code to add an HTTP input port. This is the typical case in which you would like to compositionally evolve your system without touching what has already been deployed.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
The standard solution is to use a proxy. In our example, we wish to make a proxy that enables web browsers to communicate with the calculator service:</div>
<div>
<br /></div>
<div style="text-align: center;">
Web browser <-> Proxy <-> Calculator<!-----><!-----><!-----><!-----></-></-></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Proxies (and variants) are very useful in general as intermediate glue components in service systems, but managing them may require you getting to know yet another technology. In Jolie, instead, proxies are powered by a native language primitive for forwarding messages and integrate well with our communication ports, so you can take advantage of the data abstraction layer provided by Jolie.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Open a file <span style="font-family: Courier New, Courier, monospace;">proxy.ol</span><span style="font-family: inherit;"> and write:</span></div>
<div style="text-align: left;">
<span style="font-family: inherit;"><br /></span></div>
<div style="text-align: left;">
<div>
<span style="font-family: Courier New, Courier, monospace;">include "calculator.iol"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">include "console.iol"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">execution { concurrent }</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">outputPort Calculator {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Location: "socket://localhost:8000"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Protocol: sodep</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Interfaces: CalcIface</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">inputPort ProxyInput {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Location: "socket://localhost:9000"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Protocol: http</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Aggregates: Calculator</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">main</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">{</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>in()</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: inherit;">The important part here is that we have an input port on TCP port 9000 that <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/aggregation.html" target="_blank">aggregates</a> the output port towards the Calculator. This means that all messages on port ProxyInput for an operation provided by Calculator will be forwarded to that service. So now we have our proxy and we can navigate to:</span></div>
</div>
<div style="text-align: left;">
<span style="font-family: inherit;"><br /></span></div>
<div style="text-align: center;">
<a href="http://localhost:9000/sum?x=3&y=5">http://localhost:9000/sum?x=3&y=5</a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
The proxy service will now receive your HTTP message on port ProxyInput, see that it is for the sum operation of calculator. The message is therefore converted to the SODEP format, as specified by the output port towards the calculator. The response from calculator will finally be converted again from SODEP to HTTP and sent to the initial client.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Aggregation is really useful. You can also add hooks (called <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/couriers.html" target="_blank">couriers</a>) for intercepting messages and, e.g, log operations or check for authentication credentials.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<h2>
</h2>
<h2>
Workflows</h2>
<div>
Alright, now we have our toy microservice system. Let's say that after a while, you want to add the requirement that a user must log in before calling the sum operation on the calculator. This is a workflow, the magic keyword being <b>before</b> in the previous sentence. Jolie inherits native workflow primitives from business process languages (e.g., <a href="http://en.wikipedia.org/wiki/Business_Process_Execution_Language" target="_blank">BPEL</a>), making handling flows of communications among services a breeze!</div>
<div>
<br /></div>
<div>
Open <span style="font-family: Courier New, Courier, monospace;">calculator.ol</span><span style="font-family: inherit;"> and change the main definition as follows:</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<div>
<span style="font-family: Courier New, Courier, monospace;">cset {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">sid : SumT.sid</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">main</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">{</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>login( creds )( csets.sid ) {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>if ( creds.pwd != "jolie" ) {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>throw( InvalidPwd, "The password is jolie" )</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>};</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>csets.sid = new</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>};</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>sum( req )( resp ) {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>resp = req.x + req.y</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
</div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: inherit;">The cset block above declares a session identifier sid, which we will use to track invocations coming from a same client (that's a <a href="http://docs.jolie-lang.org/#!documentation/basics/sessions.html" target="_blank">correlation set</a>). We also introduced a new operation, login, which simply checks if the password sent by the client is jolie and otherwise throws a fault to the invoker. Observe now that we use the semicolon operator to tell Jolie that sum becomes available only after login has successfully completed.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">This is a fundamental difference with respect to, say, object-oriented computing, where if you want to enforce order in how different methods are called, you have to implement it yourself with bookkeeping variables and concurrent lock mechanisms. Here instead, you just write a semicolon.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">We also need to update the interface of the calculator, in </span><span style="font-family: Courier New, Courier, monospace;">calculator.iol</span><span style="font-family: inherit;">, to account for our modifications:</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<div>
<span style="font-family: Courier New, Courier, monospace;">type SumT:void {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.x:int</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.y:int</span></div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"><span style="font-family: Courier New, Courier, monospace;"> </span></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.sid:string</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">type LoginT:void {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>.pwd:string</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">interface CalcIface {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">RequestResponse:</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>login( LoginT )( string ) throws InvalidPwd( string ),</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>sum( SumT )( int )</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div style="font-family: inherit;">
<br /></div>
</div>
<div>
<span style="font-family: inherit;">We are done! No need to update the code of the proxy, as the aggregation primitive is parametric on the interface and the protocols used by the aggregated services. Jolie will do that lifting for us. So now we can browse to: </span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div style="text-align: center;">
<a href="http://localhost:9000/login?pwd=jolie">http://localhost:9000/login?pwd=jolie</a></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
You will get a random session identifier. I got:</div>
<div>
<br /></div>
<div style="text-align: center;">
<span class="html-tag" style="font-family: monospace; font-size: 14px;"><loginResponse></span><span class="text" style="font-family: monospace; font-size: 14px;">193e6a7a-895c-4ff6-b32a-5bbab0eea7f3</span><span class="html-tag" style="font-family: monospace; font-size: 14px;"></loginResponse</span><span style="font-family: monospace; font-size: 14px;">></span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">So now I can go to (remember to replace sid with what you got in the previous call if you try this yourself):</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div style="text-align: center;">
<a href="http://localhost:9000/sum?x=3&y=5&sid=193e6a7a-895c-4ff6-b32a-5bbab0eea7f3">http://localhost:9000/sum?x=3&y=5&sid=193e6a7a-895c-4ff6-b32a-5bbab0eea7f3</a></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
And receive my good old 8 as result.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Have a look at the Jolie documentation if you are interested in using cookies and theming your responses with nice HTML. You can put that in a separate microservice, to keep calculator clean!</div>
<div style="text-align: left;">
<br /></div>
<h2 style="text-align: left;">
Conclusions</h2>
<div>
This is just the tip of the iceberg of what you may have to do with microservices and what Jolie can do for you.</div>
<div>
<br /></div>
<div>
But we can already see some of the underlying concepts that Jolie is based on:</div>
<div>
<br /></div>
<div>
<ul>
<li>You should not commit to any particular communication technology. Microservices are born to be lean and reusable, and should be kept decoupled from the implementation details of how data is exchanged.</li>
<li>Building proxies and <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/introduction.html" target="_blank">other kinds of architectural composers</a> is very handy in microservice architectures just like it is in any other distributed system. However, with microservices you can end up having a lot of them. Jolie helps in creating and managing these composers by making them programmable with native primitives that make it clear what is happening.</li>
<li>Workflows can help in making the structure of communications followed by a service explicit. They should be easy to write and Jolie strives in doing so. See <a href="http://docs.jolie-lang.org/#!documentation/basics/composing_statements.html" target="_blank">here</a> for our other workflow primitives.</li>
</ul>
<div>
<br /></div>
</div>
<div>
<br /></div>
<div>
Stay tuned for the next chapters. :-)</div>
<div>
<br /></div>
<div>
Meanwhile, you may want to have a look at some more material <a href="http://docs.jolie-lang.org/" target="_blank">here</a> and <a href="http://fabriziomontesi.com/teaching/imds-f2014/index.html" target="_blank">here</a>.</div>
</div>
fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com3tag:blogger.com,1999:blog-3856624862131672592.post-26158063809100807632015-01-30T13:25:00.000+01:002015-10-02T09:32:10.954+02:00Running Jolie inside of JavaLately I have been asked a lot how to run a Jolie program from inside of a Java program.<br />
The opposite, running Java from Jolie, is <a href="http://docs.jolie-lang.org/#!documentation/architectural_composition/embedding_java.html" target="_blank">well documented</a> in our documentation site.<br />
<br />
Running Java code from inside a Jolie program is also a very simple process.<br />
First, you need to add to your classpath (import in your project, if you are using an IDE) the jolie.jar and libjolie.jar libraries that you can find in your Jolie installation directory (JOLIE_HOME).<br />
Now, from Java, you can create an Interpreter object. Interpreter is the class that implements the Jolie language interpreter. It will need two parameters for the constructor. The first is the command line arguments that you want to pass to the interpreter. The second is the parent class loader to use for loading the resources that the interpreter will need. Here is an example based on the Linux launcher script (but it should work on any OS), where we assume that the Jolie program that we want to run is called main.ol:<br />
<br />
<br />
<pre class="brush: java">String jh = System.getenv( "JOLIE_HOME" );
String args[] = "-l ./lib/*:$JOLIE_HOME/lib:$JOLIE_HOME/javaServices/*:$JOLIE_HOME/extensions/* -i $JOLIE_HOME/include main.ol".replaceAll( "\\$JOLIE_HOME", jh ).split( " " );
final Interpreter interpreter = new Interpreter( args, this.class.getClassLoader() );
</pre>
<br />
Now you just need to use the run method of the interpreter object you have just created. Here I do it in a separate thread, as that method will return only when the Jolie program terminates. This is a toy example so I am disregarding exceptions here, but you should obviously care about them in real-world code:<br />
<br />
<pre class="brush: java">Thread t = new Thread( () -> {
try { interpreter.run(); }
catch( Exception e ) { /* Handle e.. */ }
} );
t.setContextClassLoader( interpreter.getClassLoader() );
t.start();
</pre>
<br />
If you need to stop the interpreter manually, you can use the exit method it comes with. It takes a hard timeout if you need one. Enjoy your Jolie interpreter inside of Java!fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com3tag:blogger.com,1999:blog-3856624862131672592.post-79596955068060758672015-01-26T16:18:00.003+01:002015-01-26T16:24:17.211+01:00Faster websites with Jolie - HTTP Compression enabled by defaultThanks to Matthias Dieter Wallnöfer, Jolie now supports the negotiation of HTTP compression and this is activated by default. This means that all your Jolie-powered websites will benefit from this, along with your Jolie programs which access remote HTTP content.<br /><br /> We have just uploaded the patch to the web server on the Jolie website: <a href="http://www.jolie-lang.org/">http://www.jolie-lang.org</a><br /><br />We have also added caching, with the good old <a href="http://docs.jolie-lang.org/#!documentation/protocols/http.html">.cacheControl HTTP configuration parameter</a> that I introduced a while ago (<a href="http://arxiv.org/abs/1410.3712">http://arxiv.org/abs/1410.3712</a>).<br /><br />Two minutes later, the loading speed of the main webpage doubled. We went from ~140ms down to ~70ms ! You should feel the difference navigating from one page to the other (aside from those pages using slideshare plugins, which take time to load from slideshare.net).<br /><br />Enjoy a faster Jolie website and faster $all_your_Jolie_programs.<br /><br />PS: Yes, this will be released with Jolie 1.1.1fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com3tag:blogger.com,1999:blog-3856624862131672592.post-41520004986737417052014-12-20T00:03:00.000+01:002014-12-20T00:10:55.556+01:00The first full course on Jolie has endedThe first university course almost entirely on Jolie (and choreographies!) ended today, with cakes and final discussion on the exam procedure. :-)<br />
I had a lot of fun teaching it. I look forward to the next edition, I got lots of good ideas from this one.<br />
<br />
It was also a lot of work, as I had to prepare a lot of material from scratch. There is still lots of room for improvement, but I got a decent set of lectures and exercises out of it. Here is the material from this year:<br />
<a href="http://fabriziomontesi.com/teaching/imds-f2014/index.html">http://fabriziomontesi.com/teaching/imds-f2014/index.html</a><br />
<br />
Feel free to use it, as long as you put a reference to the origin please. Or, just contact me.<br />
<br />
This year I also experimented with teaching students how to prepare and give a presentation on a scientific paper, and how to read scientific articles. I think it really paid off, they gave excellent presentations. But it's hard to tell, I had really clever students.. so maybe it's all them. ;-)<br />
Here are some of their carefully crafted presentations:<br />
<iframe src="http://www.slideshare.net/IMDS2014/slideshelf" width="760px" height="570px" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:none;" allowfullscreen webkitallowfullscreen mozallowfullscreen></iframe>
I still have to get the final feedback on the course, but an initial probing tells me that most of them would use Jolie for their future software projects. This alone makes all the effort worth it. I can't wait to see what they build with it. Some of them have already started.<br />
<br />
As the students were so happy, I am going to try carrying out an educational project on research-led teaching next year and see how to push its limits a little more every year! Doing live demos on Jolie during lectures is so much fun (you should see the faces of people when I hack a multiparty web chat server or a prototype cloud computing solution in Jolie in about 10 minutes), but I think that I can transform some of them into videos and apply some more flipped classroom techniques along with other videos from the research community on session programming. We'll see.. and suggestions are welcome!<br />
<br />
PS: something that baffled me. I could not find a good tutorial for master students on CCS and the pi-calculus. I had to prepare introductory lectures by myself, which was also quite a bit of work. But maybe they are out there and I just could not find them?
fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-29854194827748582792010-11-02T09:52:00.001+01:002010-11-02T15:06:34.623+01:00Plasma crashing upon login after updating the system clockMany people have just recently switched from DST to standard time, putting their clocks an hour back. This can possibly cause a nasty behaviour in Plasma, due to a bug in KSharedDataCache: the application simply crashes just after logging in.<br />
The bug has already been <a href="https://bugs.kde.org/show_bug.cgi?id=253795">reported</a> and corrected at the speed of light (kudos to Michael Pyne for the instantaneous reaction), so it will be fixed in KDE SC 4.5.3 and 4.6. If you are running KDE SC 4.5.2 and you do not want to apply the patch in the bug report, you can simply empty your user's cache directory.<br />
Simply go in the directory pointed by cache-$HOSTNAME inside your user's kde configuration directory and remove every file that is located inside.<br />
In openSUSE such directory is /var/tmp/kdecache-$USER, and your kde configuration directory is $HOME/.kde4.<br />
<br />
Happy Plasmaing! (or would that word be Plasming? ;-) )fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com8tag:blogger.com,1999:blog-3856624862131672592.post-35165538962483065392010-05-13T15:37:00.007+02:002010-05-13T17:11:33.814+02:00Web Services for human beings<span style="font-size: xx-small;"><i>No, this is not related to *buntu. But this is looong... and now I've got your attention. :-)</i></span><br />
<span style="font-size: xx-small;"><i><br />
</i></span><br />
Interacting with Web Services usually implies reading some <a href="http://www.w3.org/TR/wsdl">WSDL (Web Service Description Language) document</a>. Unfortunately, WSDL documents are written in XML and can be pretty complicated, leaving the user with no other choice than to use some graphical development tool in order to understand them.<br />
<br />
Lately at italianaSoftware we had to handle a lot of Web Services stuff, equipped with long WSDL documents and complex data types. <a href="http://www.jolie-lang.org/">Jolie</a> already had support for the SOAP protocol, but one had to code the interface and data types of the Web Service to invoke by hand. So we started a new project aiming to enable Jolie for the automatic usage of WSDL documents, mainly composed by two parts: a tool and an improvement to the Jolie SOAP protocol. Of course both things are open source and available in the trunk branch in the Jolie svn repository!<br />
<br />
<b>wsdl2jolie </b>(whose executable is now installed by default if you install Jolie from trunk) is the newly developed tool in question. It simply takes a URL to a WSDL document and automatically downloads all the related files (e.g., referred XML schemas), parses them and outputs the corresponding Jolie port/interface/data type definitions.<br />
Let us see an example. See this WSDL document for a service that calculates prime numbers: <a href="http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl">http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl</a>. Reading the raw XML is not so easy, or at least requires some time.<br />
Let us see what we get if we execute <span style="font-family: "Courier New",Courier,monospace;">wsdl2jolie http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl</span> <span style="font-family: inherit;">:</span><br />
<br />
<pre>Retrieving document at 'http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl'.
type GetPrimeNumbersResponse:void {
.GetPrimeNumbersResult?:string
}
type GetPrimeNumbers:void {
.max:int
}
interface PrimeNumbersHttpPost {
RequestResponse:
GetPrimeNumbers(string)(string)
}
interface PrimeNumbersHttpGet {
RequestResponse:
GetPrimeNumbers(string)(string)
}
interface PrimeNumbersSoap {
RequestResponse:
GetPrimeNumbers(GetPrimeNumbers)(GetPrimeNumbersResponse)
}
outputPort PrimeNumbersHttpPost {
Location: "socket://www50.brinkster.com:80/vbfacileinpt/np.asmx"
Protocol: http
Interfaces: PrimeNumbersHttpPost
}
outputPort PrimeNumbersHttpGet {
Location: "socket://www50.brinkster.com:80/vbfacileinpt/np.asmx"
Protocol: http
Interfaces: PrimeNumbersHttpGet
}
outputPort PrimeNumbersSoap {
Location: "socket://www50.brinkster.com:80/vbfacileinpt/np.asmx"
Protocol: soap {
.wsdl = "http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl";
.wsdl.port = "PrimeNumbersSoap"
}
Interfaces: PrimeNumbersSoap
}
</pre><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;">which is the Jolie equivalent of the WSDL document. Those ".wsdl" and ".wsdl.port" parameters are the aforementioned improvement to the SOAP protocol: when the output port is used for the first time, Jolie will read the WSDL document for processing information about the correct configuration for interacting with the service instead of forcing the user to insert it by hand.</span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;">Now we can just put this into a file, say "PrimeNumbers.iol"<span style="font-family: inherit;">, and use the output ports we discovered from Jolie code. As in the following:</span></span></span><br />
<br />
<pre>include "PrimeNumbers.iol"
include "console.iol"
main
{
request.max = 27;
GetPrimeNumbers@PrimeNumbersSoap( request )( response );
println@Console( response.GetPrimeNumbersResult )()
}
</pre><br />
<div style="font-family: inherit;"><span style="font-size: small;">That little program will output "1,3,5,7,11,13,17,19,23</span><span style="font-size: small;">"</span><span style="font-size: small;">. The example can be downloaded from <a href="http://www.jolie-lang.org/examples/unsorted/prime_numbers_wsdl.zip">this link</a> (remember, it requires Jolie from trunk).</span></div><div style="font-family: inherit;"><span style="font-size: small;"><br />
</span></div><div style="font-family: inherit;"><span style="font-size: small;">wsdl2jolie acts as a nice tool for being able to use the typed interface of a Web Service from Jolie and for getting a more human-readable form of a WSDL document (its Jolie form).</span></div><div style="font-family: inherit;"><br />
</div><span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;"><span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;">Another nice feature we get for free from the SOAP protocol improvement is that <b>now MetaService can act as a transparent bridge towards Web Services</b>. Simply call the addRedirection operation with the right protocol configuration (in this case, the ".wsdl" and ".wsdl.port" parameters) and MetaService will automatically download the WSDL document (we also have a cache system for them already in trunk!) and make it callable by clients.</span></span></span></span></span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;"><span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;">This is a huge step forward for client libraries such as QtJolie: just tell where the WSDL document is and you can already place calls to the Web Service of interest.</span></span></span></span></span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;"><span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;">Also, by using <b>wsdl2jolie</b> first and then tools such as <b>jolie2plasma</b> one could use the Jolie intermediate representation for transforming a Web Service interface definition into a (<a href="http://www.kde.org/">KDE</a>) Plasma::Service XML one. With the same trick, one could also write C++ generators for QtJolie and introduce ease and type-safeness to Web Services invocations. I and Kévin sure have things to think about now. ;-)</span></span></span></span></span></span><br />
<br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;"><span style="font-family: "Courier New",Courier,monospace;"><span style="font-family: Arial,Helvetica,sans-serif;"><span style="font-family: inherit;">Beware that the code is still in its early stages. It already works with a lot of Web Services, but we're still improving it. For instance, we currently support only the SOAP document format (which is the one people advise to use, anyway). Patches, comments and reports are welcome in jolie-devel @ lists.sourceforge.net!</span></span></span></span></span></span>fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com3tag:blogger.com,1999:blog-3856624862131672592.post-12337493886787321112009-11-24T17:00:00.000+01:002009-11-24T17:00:58.849+01:00Discovering Jolie... in italian!I have just discovered that Simone (Demo) Gentili is documenting his journey about the <a href="http://www.jolie-lang.org/">Jolie language</a> on his blog! As a matter of fact, he's practically translating the Jolie language tutorials in italian!<br />
See <a href="http://www.unodeitanti.com/wordpress/jolie/">his blog here</a> if you are interested in some Jolie lessons in italian.<br />
<br />
This is obviously a very nice surprise for us and an important form of contribution, so thank you Simone for your work!fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-12019505505760252502009-10-20T18:19:00.006+02:002009-10-21T11:09:57.055+02:00Service-Oriented Computing: a new programming paradigm?<span style="font-style: italic;">The point of this post is to introduce a paper that explains service-oriented computing that can be read by anyone, without requiring too much previous knowledge. The link is in the last paragraph of the post. If you were interested in knowing more about what service-oriented computing is, it could be a good starting point.</span><br /><br />The concepts of online service and distributed programming exist since quite some time now, to the point that they evolved into a huge research topic both for academia and the industry. Huge as it is, a lot of different results from different research areas appeared; conferences on Service-Oriented Computing (SOC) were opened; a lot of investments were made.<br />In the last decade or so it became apparent that new foundations were need in order to build truly inter-operable distributed applications and that ad-hoc technologies were not good enough for the job. Moreover, it was clear how much SOC could benefit from theoretical research for handling its complex inherent problems. New concepts were forged and new languages were made, the most notable result being the set of languages, specifications and technologies that falls under the name of "Web Services".<br /><br />Today, we reached the point in which we can look back and see that "services" follow common principles (e.g. public interface, protocol descriptions...) and must necessarily address certain problems (e.g. session handling, structured data description and manipulation, interoperability...). The whole thing grew up so much in detail that we may be looking at a new programming paradigm: the service-oriented one. A paradigm that has the concept of "service" as a native element, much like object-oriented programming has the native concept of "object" or functional programming of "function".<br />This is not something that we just imagined. We see this every day at <a href="http://www.italianasoftware.com">italianaSoftware</a>, programming solutions for our customers with the <a href="http://www.jolie-lang.org">JOLIE language</a>. Having a language that allows you to make lightweight services in a matter of minutes and to exploit local communications between them in order to maintain performance can change your point of view: services are not mere bridges between different applications anymore, they can be used (and reused) as the building blocks of a single application.<br /><br />We tried to express our definition and experience on this new paradigm on a concept paper at YR-SOC'09, which is publicly available online. Here is the <a href="http://arxiv.org/abs/0906.3920">link</a> (on the upper right area of the linked page you can find links for the pdf or postscript versions). It is an introduction to service-oriented computing that considers what has been made so far, so you will find links to a lot of existing works inside it. Some concepts may be pretty new to some readers (after all, it was originally meant for an academic audience and contains references to theoretical works), but we are currently interested in enhancing the paper to make it more readable by the casual developer (probably with less references to theoretical works and more comparisons with existing languages and technologies) and put the new version online in the JOLIE website. So, if you read the paper and find some concepts too obscure or you have some doubts or comments (apart what I have already said) or some arguments that you wish would be addressed, please let us know!fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com5tag:blogger.com,1999:blog-3856624862131672592.post-83653679619642456672009-09-29T09:48:00.001+02:002009-09-29T09:48:41.380+02:00Jolie and ARMLast year (yeah, this is one of those "I should have posted this long ago" posts, but better late than never) I received a precious delivery:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgINa_m9KMRtp-f8qClol49kS7wVVsKMKAuKgdt_0Vj4h6eY3NAzz1pXj8p2GcTsrNG0UPlfezzv4D-E4gbtWvNg_jzxD-Y3Q3c0afMU3mOekllS-M5AjiE02teJWvGM_VEuedJuRG2ahdF/s1600-h/05-12-08_1451.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 256px; height: 320px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgINa_m9KMRtp-f8qClol49kS7wVVsKMKAuKgdt_0Vj4h6eY3NAzz1pXj8p2GcTsrNG0UPlfezzv4D-E4gbtWvNg_jzxD-Y3Q3c0afMU3mOekllS-M5AjiE02teJWvGM_VEuedJuRG2ahdF/s320/05-12-08_1451.jpg" alt="" id="BLOGGER_PHOTO_ID_5276325211859609554" border="0" /></a>Oh, yes! KDE sent me bubble wrap, woohoo! I played with it until its exhaustion, so thank you KDE (and Claudia for handling the delivery, and Nokia for providing the materials)!<br /><br />After playing with the bubble wrap I discovered that there was something inside it: a shining Nokia N810. My very first ARM device to experiment with. The ARM world is indeed very interesting not only for <a href="http://www.kde.org/">KDE</a>, but also for the <a href="http://www.jolie-lang.org/">Jolie</a> language; so I started to try installing a working execution environment for Jolie in this little device.<br /><br />The first try wasn't easy. I needed a working Java environment before trying to install Jolie. Fortunately, the <a href="https://wiki.evolvis.org/jalimo/index.php/Main_Page">Jalimo project</a> out there has already made all the important steps. So I made contact with them in IRC and I've found people willing to help. Many thanks in particular to <a href="http://www.ohloh.net/accounts/xranby">xranby</a>, who provided me an almost-ready binary package for getting me started. The result?<br />Jolie has been tested on ARM, and it just works! The whole process has produced some patches for Jolie too, in terms of performance improvements (loading protocol extensions is now faster than before) and memory consumption.fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-47621038197469864712009-09-09T16:26:00.009+02:002009-09-09T19:44:17.367+02:00Random thoughts: getting ready for Jolie 1.0 and remote services inclusion in KDE<a href="http://www.jolie-lang.org/">Jolie</a> is getting into shape for the 1.0 release. This is requiring a lot of work, and whenever we reach our current objectives we feel like improving things even further (every developer likes perfection, the problem is it requires too much time)! Nevertheless, the line for a good 1.0 release has been placed and is getting very near. The two major points we need to address are SSL support (both in SODEP an HTTP) and documentation. By documentation I'm not just referring to the language documentation but also to the source code documentation of the interpreter; the aim is to make the Jolie interpreter more approachable by hackers who want to improve it or want to write an extension (protocols, specifications, hardware support, ...). The 1.0 release will also contain experimental support for XML-RPC.<br /><br />SSL support is already working and waiting for inclusion (rough edges need to be investigated) in the main source tree. SSL support will particularly benefit B2B applications, which until<br />now had to get security by wrapping Jolie in SSL containers, and <a href="http://www.kde.org/">the KDE project</a>, which has just <a href="http://pindablog.wordpress.com/2009/09/08/tokamak-3-wrap-up/">included support for remote services</a> in trunk using Jolie and MetaService as backend technologies. SSL support in Jolie would allow KDE remote Plasma services to encrypt their data exchanges, an essential feature when dealing with sensitive data (though the initial handshake part is already made secure by using Qt).<br />I must say that the KDE inclusion was pretty quick: it was just one year ago when the Jolie and the Plasma teams met at the first Tokamak and now we already have a first functioning version in trunk. This process required quite a lot of work and skill, from writing a service orchestrator that could dynamically create bridges from Plasma to services using different protocols and technologies onward to the QtJolie gluing layer and the final implementation in the Plasma library. Now we have the basis for constructing even more complex frameworks and applications, and all of this will benefit from the future Jolie static analysis tools that we (the Jolie team) are planning to implement. All of this to say that it really is a pleasure to work with the KDE team: I will be sure to keep in touch as much as possible.<br /><br />I'm now focusing heavily on source code documentation and polishing (for which I've just made some pretty big commits). Regarding code polishing, I got some help from the <a href="http://findbugs.sourceforge.net/">FindBugs</a> static analysis tool; you can just ask it to read some Java bytecode and it comes up with a lot of good hints for performance improvements and bug removals. It is really easy to use and it even considers correct resource locking and releasing. Pretty useful if you have old code to maintain or for checking new extensions before merging them.<br /><br /><br />Ah yes, I should also blog about a lot of other features and the porting of Jolie to ARM-based devices thanks to the <a href="https://wiki.evolvis.org/jalimo/index.php/Main_Page">Jalimo project</a>... but that's for other blog posts!fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com2tag:blogger.com,1999:blog-3856624862131672592.post-17790247380382720672009-02-24T13:20:00.008+01:002009-03-23T18:26:53.781+01:00RFC: Service-oriented Training & Hacking session at Akademy 2009It is some time that I'm thinking about Akademy 2009, and how to make people aware of the potential the integration of Plasma and <a href="http://www.jolie-lang.org">Jolie</a> are going to bring. The following is what I came up with, and from some early discussions it really looks like something worth doing. Please share your thoughts and comments on this.<br /><br />The idea is to make a (workshop-like) session about the service-oriented world, with pragmatism in mind. aseigo and ervin have been coerced into helping. It'd be composed by two parts, training and hacking.<br /><br /><h2>Training</h2><br />The training part would touch these topics (not necessarily in order):<br />- the Service-Oriented Computing paradigm: what is it, and how can we use it?<br />- how to exploit the service-oriented paradigm through the Jolie language.<br />- bridging Jolie and Qt with kevin's latest cool library<br />- the Plasma::Service+MetaService API explained. Service-oriented plasmoids!<br />- how to make powerful service compositors/orchestrators in Jolie, and use them as backends for plasmoids or $insert_your_app_here.<br />- use cases and surprises (?)<br />- questions and answers<br /><br /><h2>Hacking</h2><br />Everyone starts his editor of choice and starts hacking on some service-oriented UI/Plasmoid/etc, getting help and sharing ideas.<br />It will be an excellent occasion to improve the framework too (not only the C++ libraries but even the Jolie framework itself, as I'll be there), as there will probably be necessities that could be implemented as a Jolie protocol or some other extension.<br /><br /><br /><br />What I'd like to have are ideas and comments about this. Is there any topic you'd like to be covered in particular? Questions to be answered?<br /><br />Of course it would be nice to have plasma developers attending, along with any other people interested in integrating jolie/service-oriented computing in their application or framework.<br />It'<br /><br />So, dear reader, would *you* attend? =)fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com3tag:blogger.com,1999:blog-3856624862131672592.post-4271135563485915282009-02-20T09:15:00.002+01:002009-03-13T09:58:36.813+01:00Solid, UPnP and JolieLately there's been a lot of interest about UPnP and its application in KDE.<br />These days I'm speaking a lot about these things with <a href="http://ervin.ipsquad.net/">Kévin "ervin" Ottens</a> w.r.t. the <a href="http://solid.kde.org">Solid</a> project. Even at Akademy 2008, Kévin suggested to me that it would be nice to have a UPnP protocol implementation in <a href="http://www.jolie-lang.org">Jolie</a>. There's been some discussion since there, but we just couldn't afford to implement it because of lack of resources (people/time). GSOC is approaching and this item is among the ideas for KDE, so some explanation is probably a good thing to offer. The aim of this post is to offer such an explanation, but given that I'm so familiar with Jolie I could miss some points of interest... so please *ask* if *you*'ve got doubts about this (like "I didn't understand why that point would be better than doing this other thing...", or "Did you think about using this and/or this?..").<br /><br /><a href="http://www.jolie-lang.org">Jolie</a> is currently being integrated in KDE and will become a runtime dependency for activating Plasma on the network (making plasmoids in different machines communicating with each other, or with external services, etc.). Enabling Jolie to use UPnP would mean to re-use this dependency and all the technology developed until now (QtSodep, service composition, easy data manipulation etc.) for giving Solid (capital S) a solid backend (lower-case s ... yes, it's a pun! ha ha... *cough cough*) to exploit all the UPnP devices out there. Add to this the service-oriented programming capabilities of Jolie and you obtain a complete framework for making powerful orchestrators out of your UPnP network and even making Solid itself a UPnP service provider.<br /><br />A note about the implementation: nowadays Jolie offers two ways for implementing a new protocol: you can write it in Java or write it in Jolie itself. We offer these two possibilities because it's useful to distinguish between low-level and high-level protocols, and to use the right tool for the right job.<br />The first kind deals with low-level byte streams manipulations, e.g. binary protocols, and Jolie is not suited to do that; good examples are any binary protocol, or even HTTP.<br />The second kind is more about manipulating data structures in an abstract manner; for example, suppose that you need to implement a new protocol on top of XML: being able to exploit Jolie's syntax for XML manipulation is usually a winner.fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com7tag:blogger.com,1999:blog-3856624862131672592.post-46845329848631599782009-02-11T14:08:00.003+01:002009-02-11T17:10:28.394+01:00openSUSE package for JolieThe title of this blog post really leaves a trail of mistery.<br /><br />Today, under a not-so-excellent-but-still-not-too-bad weather, I've decided to enter the dark school of packaging. The results can be found here: <a href="http://download.opensuse.org/repositories/home:/fmontesi/openSUSE_11.1/">http://download.opensuse.org/repositories/home:/fmontesi/openSUSE_11.1/</a><br /><br />This means that now we've got a <a href="http://download.opensuse.org/repositories/home:/fmontesi/openSUSE_11.1/jolie.ymp">one-click installer</a> for <a href="http://www.jolie-lang.org/">Jolie</a> in openSUSE 11.1. Enjoy!<br /><br />P.S.: in the <a href="http://www.jolie-lang.org/download.php">website official download page</a> there's a better looking button ;)<br /><br /><strong>Update:</strong> andred in #plasma made me notice that many people are still using openSUSE 11.0. Jolie should work flawlessly even there, but I've got no mean to test it. Anyway, <a href="http://download.opensuse.org/repositories/home:/fmontesi/">my repository</a> now contains packages for openSUSE 11.0 and openSUSE factory, too. I must say that openSUSE build service is one fantastic piece of software!fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-52875701691058719172009-01-23T11:28:00.006+01:002009-02-04T11:04:20.466+01:00Major distribution bug in Java support for unix sockets?If you're trying to use local unix sockets using libmatthew with a Java program (as it's the case for JOLIE and thus MetaService), you might get a similar error:<br /><br />Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/libunix-java.so: /usr/lib/libunix-java.so: undefined symbol: __stack_chk_fail_local<br /><br />I get it using the libmatthew-java package from openSUSE 11.1. It looks like <a href="https://bugs.launchpad.net/ubuntu/+source/dbus-java/+bug/218658">Ubuntu users are suffering of the same problem</a> (there causing a bug in dbus-java). If you read their bug thread, you'll find that they appoint the problem to a compilation flag. I've tried to simply download libmatthew sources from <a href="http://www.matthew.ath.cx/projects/java/libmatthew-java-0.7.1.tar.gz">here</a> and compiling them: they just work (except that you have to fix the Makefile by substituting the java compiler flag -source 5.0 with -source 1.5).<br /><br />This problem really looks worth going into some official update repository for each bugged distro. I have already filed a <a href="https://bugzilla.novell.com/show_bug.cgi?id=468886">bug for openSUSE</a>, but I cannot confirm it for other distros. Could *you* (dear reader) check for it and send an appropriate bug report? =)<br /><br /><strong>UPDATE:</strong> the bug has been fixed! Thanks to all the people involved! =) If you're using openSUSE 11.1, you can fetch a backport from the Java repository (http://download.opensuse.org/repositories/Java:/packages/openSUSE_11.1/).fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com3tag:blogger.com,1999:blog-3856624862131672592.post-42100870663645661922009-01-21T12:21:00.004+01:002009-01-21T12:46:54.994+01:00MetaService enters the main source treeToday I have moved MetaService from <a href="http://www.jolie-lang.org/">JOLIE</a>'s playground source tree to the main source tree, the one that gets installed when you type <i>ant install</i>.<br /><br />A short description for people that do not know what MetaService is: MetaService is a JOLIE service that allows you to dynamically bridge applications that speak different protocols (sodep, soap, http, etc.) or use different communication transports/mechanisms (sockets, local sockets, Java RMI, etc.). It has been developed as an answer to the <a href="http://plasma.kde.org/">Plasma project</a>'s needs to have a transparent means to introduce Plasma to the Service-oriented world. The project turned out to be so useful that I have built a Java library for interacting with and dynamically loading it (metaservice-java, to be found in trunk/support/metaservice-java) which we, as <a href="http://www.italianasoftware.com">italianaSoftware</a>, have already used in the scope of web application development (I can not say much more on this topic... yet ;).<br /><br />As a bonus, *nix users get a launcher script for MetaService when installing JOLIE with <i>ant install</i>. Just type <i>metaservice -h</i> and a help screen will welcome you.<br /><br />The script supports passing MetaService's input port location and protocol as parameters. This means that for KDE launching MetaService just became a matter of executing something like:<br /><br /><i>metaservice localsocket:/tmp/ksocket-$USER/metaservice</i><br /><br />Hooray for simplicity!fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-8317412562118339082009-01-20T12:05:00.005+01:002009-01-20T16:30:47.097+01:00Jolie Jobs (now with Plasma)The Jolie web site now sponsors a "Jobs List", which can be found from the <a href="http://www.jolie-lang.org/contribute.php">Contribute page</a>, also known as "What we lack for world domination". The list features some Junior Jobs, so it's a good starting point for people that are looking for ways to start contributing to Jolie. We are continuously filling in new jobs (there's *always* something to do, as in every project ;), so be sure to refresh it if you're interested. If you don't find anything that interests you, remember that you can always post to the <a href="mailto:jolie-devel@lists.sourceforge.net">mailing list</a>. =)<br /><br />Now that JOLIE supports message types, it is feasible (and not too hard) to make automatic generators for Plasma::Service description files. These jobs are listed, so if someone wants some cool tool for automatic type-safe code generation between Plasma and JOLIE sooner rather than later and to learn something more about how Plasma and JOLIE communicate, this is a good occasion to jump on the JOLIE<->Plasma revolution train. ;)fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-33913054789331072372009-01-19T15:33:00.006+01:002009-01-20T16:30:59.803+01:00Compiling JOLIE from sources in Windows now easierFor everyone using Windows out there: <span style="font-weight:bold;">compiling JOLIE from sources in Windows is not a pain anymore</span>!<br /><br />I've patched the build system so that it recognizes the running operating system and installs the appropriate launcher script (a shell script in *nix and a .bat script in Windows), so now having a working environment is far less "manual" than before. You can find the updated guide <a href="http://www.jolie-lang.org/download.php">here</a> (Windows -> From sources).fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-89425271569064028092009-01-14T19:00:00.006+01:002009-01-14T19:59:26.225+01:00JOLIE meets Message Typing!I've just finished to adapt and merge into <a href="http://www.jolie-lang.org/">Jolie</a>'s SVN the awesome work derived from <a href="http://www.elvisciotti.it/blog/2008/12/tesi-sistema-di-tipi-per-jolie/">Elvis Ciotti's thesis</a>. The job required some time, but we are definitely improving our development process with people that decide to make a thesis on JOLIE (it required much more than a day in the past); I think that we can improve even more, but that's another story. Elvis made some testing scripts, too, so I'm pretty sure that my refactoring did not introduce any regression and testing the result was a painless process. Way to go, Elvis. =)<br /><br />So, message typing: what's that? Let's have a preface and then look at an example!<br /><br /><h2>The problem</h2><br />In a service-oriented world applications communicate with each other. An application (say, A) can communicate with another one (say, B) by using the interface exposed by the latter. An example of an interface is "I accept messages for an operation called <span style="font-weight: bold;">sum</span>. You shall send me two numbers and I will return their sum to you.".<br />The problem here is that A and B are completely separated applications. They could even have been made with different programming languages. What does assure us that A is gonna respect the interface specs of B? Unfortunately, nothing does. We do not have any means to do that, as A is a black box to our eyes: we can not peek inside. We can only hope A has been statically checked against our interface before being run, or that A hasn't been purposefully made wrong to mess B up.<br /><br />So what can we do?<br /><br />When B receives a message, it could check at run-time that it conforms to the interface. If not, it should discard it immediately. That way we are sure to be safe, and that B's internal program doesn't get unexpected data.<br /><br /><h2>Example</h2><br />Let us implement B with Jolie's syntax for message types. The code would look as the following:<br /><br /><pre><br />type SumRequest:void {<br /> .x:int<br /> .y:int<br />}<br /><br />inputPort B {<br />Location: "socket://localhost:8000"<br />Protocol: sodep<br />RequestResponse:<br /> sum(SumRequest)(int)<br />}<br /><br />main {<br /> sum( request )( result ) {<br /> result = request.x + request.y<br /> }<br />}<br /></pre><br /><br />In the example B accepts messages containing two sub-nodes, x and y. An XML representation of a valid message is the following:<br /><br /><pre><br /><request><br /> <x>5</x><br /> <y>10</y><br /></request><br /></pre><br /><br />Jolie will take care that B doesn't receive anything that doesn't conform to SumRequestType. Clients sending a malformed message would receive a "TypeMismatch" fault in return.<br /><br />Jolie types are pretty expressive, you can also play with the number of occurrencies. An example of a more complex type:<br /><br /><pre><br />// A type describing an article<br />type Article {<br /><br />// We want at least one author, but no upper limit<br /> .author[1,*]:void {<br /> .name:string<br /> .surname:string<br /> .age:int<br /> }<br /><br />// We accept from 5 to 15 pages<br /> .page[5,15]:string<br /><br />// ? is a shortcut for [0,1], i.e. giving a summary is optional<br /> .summary?:string<br /><br />/* .metadata is left completely free,<br /> * type checking is not performed on it<br /> */<br /> .metadata:any { ? }<br />}<br /></pre><br /><br />The code has just entered so it still may have some bugs, but it works already with some advanced tests I've conducted with current SVN.<br /><br />Enjoy! =)fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com1tag:blogger.com,1999:blog-3856624862131672592.post-91824298596880412362009-01-12T17:47:00.003+01:002009-01-12T17:59:06.701+01:00Jolie's new website is up!JOLIE has a new and shiny website: <a href="http://www.jolie-lang.org/">www.jolie-lang.org</a><br /><br />The new site has a wiki which we are filling in with a lot of information, minute by minute. Some tutorials are already final and we are preparing demos and packages of source code examples.<br /><br />This step required some effort and time, but we now have a serious and stable basis to build our knowledge base upon (the backend of the website is quite powerful and allows for easy administration and data versioning).<br /><br />The mailing list and IRC channel are already active since some time, respectively jolie-devel@lists.sourceforge.net and #jolie on freenode, providing the means for asking about anything related to JOLIE and getting the attention of the JOLIE team.fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-1798195103299067292008-12-15T18:26:00.005+01:002008-12-15T18:48:53.308+01:00Jolie meets JavaScriptStarting today, JOLIE services can exploit the JavaScript language!<br />As usual we are <span style="font-weight: bold;">not</span> speaking of mixing JOLIE code with another language, which would result in incomprehensible JOLIE programs. We are instead speaking of the insertion of another language in JOLIE's service-oriented paradigm, by means of the embedding mechanism (which we are detailing in our new, shiny tutorials, to be published really soon).<br /><br />Embedding a JavaScript service goes like this:<br /><br /><pre>// main.ol<br /><br />include "console.iol"<br /><br />// Standard JOLIE service declaration<br />outputPort Math {<br />RequestResponse: sum<br />}<br /><br />embedded {<br />// We load our JavaScript file as the JS service<br />JavaScript:<br /> "mathservice.js" in </span><span style="font-family:courier new;">Math</span><br /><span style="font-family:courier new;">}<br /><br />main<br />{<br /> // Now we can call JS as every other service type supported by JOLIE<br /> with( request ) {<br /> .addend[0] = 2;<br /> .addend[1] = 4;<br /> .addend[2] = 1;<br /> .addend[3] = 3<br /> };<br /> sum@</span><span style="font-family:courier new;">Math</span><span style="font-family:courier new;">( request )( response );<br /> println@Console( response ) // Will print 10<br />}<br /></pre><br />The JavaScript API for accessing structured JOLIE data is the same as the one for Java. Let us see how the Math service is implemented:<br /><pre><br />// mathservice.js<br /><br />function sum( request )<br />{<br /> var addends = request.getChildren( "addend" );<br /> var total = 0;<br /> for( var i = 0; i < addends.size(); i++ ) {<br /> total += addends.get( i ).intValue();<br /> }<br /> return total;<br />}<br /></pre><br /><br /><br />Voilà! Simple, isn't it?<br />Support for other scripting programming languages will be introduced in the future, stay tuned! =)fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com3tag:blogger.com,1999:blog-3856624862131672592.post-35853216358376948582008-11-05T18:09:00.004+01:002008-11-05T18:52:58.196+01:00Today, in JOLIE...<span style="font-weight: bold;font-size:130%;" >Build system</span><br />JOLIE's SVN contains now an ant-powered build system that compiles all the protocols, extensions and libraries and then is able to install the resulting runtime environment in your computer in a painless way. Painless like "just type <span style="font-style: italic;">sudo ant install</span> in trunk/ and you're done".<br />The system is still beta-ish, but it's been tested by some people other than me. So now installing JOLIE from SVN is just:<br /><span style="font-family:courier new;"><br />svn co https://jolie.svn.sourceforge.net/svnroot/jolie/trunk</span><br /><span style="font-family:courier new;">sudo ant install</span><br /><br /><span style="font-weight: bold;">Warning</span>: I still have to implement <span style="font-style: italic;">ant uninstall</span>, so you'll have to delete /opt/jolie and /usr/local/bin/jolie by hand for uninstalling it.<br /><br />If you want to control the install directories, just edit the buildconfig/config.properties file, it's short and easy. Suggestions and reports on the build system topic are <span style="font-style: italic;">very </span>welcome, so please tell me of anything comes up to your mind / bugs you find.<br /><br />You'll notice a couple jars in the SVN, they're there because you probably don't have them in your system and they're usually not packaged by distros (e.g. Google Web Toolkit servlet jar, relaxngDatatype). It's Java, so recompiling them is useless. But if you want to use _your_ jar anyway, just change the library paths in config.properties.<br /><span style="font-size:130%;"><br /><span style="font-size:130%;"><span style="font-weight: bold;">Program checker upgrades</span></span></span><br /><span style="font-size:100%;">The JOLIE pre-execution program checker now punches you (emits an error) whenever you're trying to use the wrong communication pattern (you send a message, but you don't wait for a response when you're supposed to, or vice versa, etc.).</span><br /><br /><span style="font-weight: bold;font-size:130%;" >Concurrent request-response pattern performing in persistent channels</span><br />Whoa, this paragraph title is so long and confusing. Let's look at the problem by using an example: if you use the same, persistent socket with multiple threads (say, 2 threads) for performing a request-response pattern (i.e. you send a request and you receive a response back, like in HTTP), the messages risk to get messed up, because now when you get the first response you aren't sure which thread is expecting it.<br />HTTP pipelining solves that problem for you by sending the responses in the same order as you sent the requests. That implies that you must first send all your requests and then wait for all the responses. But in a true asynchronous system, you'd want simply to be able to send and receive things without introducing such slowing factors.<br />How does JOLIE solve that? We tag each request with an identifier and we require the response to equip the same tag. That way we can relate responses to their requesting threads. The internal handling of this is complicated, but it's all abstracted away at the language level... the programmer doesn't even need to know this mechanism.<br />In-memory communications, Java<->JOLIE channels and the SODEP protocol already support this new feature. We're currently thinking about possible solutions to introduce this on other protocols.<br /><br /><span style="font-weight: bold;font-size:130%;" >Website and documentation progress</span><br /><span style="font-size:100%;">The new website works are on schedule (i.e. we should publish it by this month or at least december, no later). We have tutorials (Claudio already made a lot of work.. my schedule fixes next week for full diving in user documentation writing), examples (I'll problably publish some of them in advance on the blog)</span> and so on.<br />A lot of in-code documentation has been polished up (especially in the support libraries for external programs interacting with JOLIE).<br /><br /><br />Mmmh I estimate a 50% rate of things I forgot to report... I should probably post more. ;)fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com2tag:blogger.com,1999:blog-3856624862131672592.post-90316234976543442222008-10-10T12:57:00.013+02:002008-10-10T17:18:47.188+02:00Opening MetaService to Java: the MetaService-Java API layer.Today, MetaService-java hit Jolie's SVN. You can find it in /trunk/support/metaservice-java. Basically, MetaService-java is a Java API abstraction layer for interacting with MetaService, so that you can use it as if it were a Java object.<br /><br />This project was born for two reasons:<br />- it will be part of a solution for the integration of Java enterprise web applications with Service-Oriented Computing;<br />- it is a good example of how to implement an API abstraction layer to MetaService from an Object-oriented language, so its source code could be a useful reading for the Plasma::Service developers.<br /><br />I'll let the code (and its comments) and a simple example speak for themselves. They're in Java, but they should be pretty easy to understand even for people non-proficient with it. Example follows.<span style="font-weight: bold;"><br /><br /><br /><span style="font-family: courier new;"><span style="font-weight: bold;">MetaService metaService = new EmbeddedMetaService(); // Create a MetaService instance.<br /><br />// Set up access to a SOAP Web Service.<br />MetaServiceChannel myWebService = metaService.addRedirection(<br /> "MyWebService", // Resource name to assign<br /> "socket://www.mywebservice.com:80/", // Service location<br /> Value.create( "soap" ), // Protocol to use<br /> Value.create( "My metadata" ) // Descriptive metadata<br />);<br /><br />// Done! Let's communicate with it.<br />myWebService.send( "getNameById", Value.create( 4 ) );<br />Value response = myWebService.recv();<br />System.out.println( response.strValue() ); // Will print the name.<br /><br /><br /></span></span></span>The API is still to be refined, but pretty much usable already. =)fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com0tag:blogger.com,1999:blog-3856624862131672592.post-41888909370631852822008-10-02T15:12:00.006+02:002008-10-02T15:16:55.404+02:00Local socket support in JOLIE<div xmlns='http://www.w3.org/1999/xhtml'>This fall looks good so far! A lot of JOLIE sub-projects are taking shape, and are going better than anticipated. But I'm blogging about something which has just landed on JOLIE's svn.<br/><br />JOLIE now supports local sockets (a.k.a. unix sockets). How to use them? Let's see it by comparison; a communication interface over tcp/ip sockets is exposed like the following:<br/><br /><code>inputPort MyInputPort {<br />Location: "socket://localhost:9000"<br />Protocol: soap<br />Interfaces: MyInterface<br />}</code><br/><br />Let's switch that to a local socket:<br/><br /><code>inputPort MyInputPort {<br />Location: "localsocket:/tmp/mylocalsocket"<br />Protocol: soap<br />Interfaces: MyInterface<br />}</code><br /><br />That's it! Use the localsocket scheme in the Location URI, and supply the right path to it.<br/><br /></div>fmhttp://www.blogger.com/profile/12780751151972172366noreply@blogger.com5