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.
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:
Let's switch that to a local socket:
That's it! Use the localsocket scheme in the Location URI, and supply the right path to it.
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:
inputPort MyInputPort {
Location: "socket://localhost:9000"
Protocol: soap
Interfaces: MyInterface
}Let's switch that to a local socket:
inputPort MyInputPort {
Location: "localsocket:/tmp/mylocalsocket"
Protocol: soap
Interfaces: MyInterface
}That's it! Use the localsocket scheme in the Location URI, and supply the right path to it.
Posts
4 comments:
Can you point to a place where you discuss how you map different serialization protocols like XML Schema, DBus and e.g. Protocol Buffers to each other?
The place, for now, is the code base of JOLIE. ;)
We're currently preparing the documentation for the new website to come, but here's a quick overview:
- JOLIE has an internal in-memory representation for data;
- JOLIE support for different protocols can be extended by means of plug-ins implementing a precise API;
- each plug-in is responsible for the encoding/decoding to/from its respective protocol, e.g. soap.
So, for example, we've got a "soap" extension which takes care of converting JOLIE's internal data representation to SOAP XML messages and viceversa.
You can see all of our current protocols in JOLIE's svn tree under the "extensions" directory.
So how do you deal with differences in protocol capabilities? E.g. dbus does not support polymorphism or optional fields. so you cannot map any WSDL file to a DBus XML. Or can you?
I can't, simply because D-BUS XML format does not support it.
But:
I could make a JOLIE service supporting polymorphism and exposing it through D-Bus (even if, strictly speaking, polymorphism will be supported only in the next months: this feature still has to reach JOLIE's svn, but the example is good nevertheless.. as there are other JOLIE features that are not supported by this or that other technology).
Now, if a D-Bus client would want to learn my service interface by reading a single D-Bus description file, it would have access to just one single form of my polymorphic operation (the one described in the file).
However, another client could read a different (but still valid) description file describing another form and use that: JOLIE won't complain.
This limitation stands only for clients using the D-Bus description format. If the client doesn't need it (e.g. JOLIE, as JOLIE as its own syntax for describing services), then the limitation is gone and you can have two applications talking "empowered D-Bus" with each other.
Post a Comment