JOLIE meets Message Typing!
I've just finished to adapt and merge into Jolie's SVN the awesome work derived from Elvis Ciotti's thesis. 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. =)
So, message typing: what's that? Let's have a preface and then look at an example!
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 sum. You shall send me two numbers and I will return their sum to you.".
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.
So what can we do?
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.
Let us implement B with Jolie's syntax for message types. The code would look as the following:
In the example B accepts messages containing two sub-nodes, x and y. An XML representation of a valid message is the following:
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.
Jolie types are pretty expressive, you can also play with the number of occurrencies. An example of a more complex type:
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.
Enjoy! =)
So, message typing: what's that? Let's have a preface and then look at an example!
The problem
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 sum. You shall send me two numbers and I will return their sum to you.".
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.
So what can we do?
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.
Example
Let us implement B with Jolie's syntax for message types. The code would look as the following:
type SumRequest:void {
.x:int
.y:int
}
inputPort B {
Location: "socket://localhost:8000"
Protocol: sodep
RequestResponse:
sum(SumRequest)(int)
}
main {
sum( request )( result ) {
result = request.x + request.y
}
}
In the example B accepts messages containing two sub-nodes, x and y. An XML representation of a valid message is the following:
<request>
<x>5</x>
<y>10</y>
</request>
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.
Jolie types are pretty expressive, you can also play with the number of occurrencies. An example of a more complex type:
// A type describing an article
type Article {
// We want at least one author, but no upper limit
.author[1,*]:void {
.name:string
.surname:string
.age:int
}
// We accept from 5 to 15 pages
.page[5,15]:string
// ? is a shortcut for [0,1], i.e. giving a summary is optional
.summary?:string
/* .metadata is left completely free,
* type checking is not performed on it
*/
.metadata:any { ? }
}
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.
Enjoy! =)