<div class="gmail_quote">On Tue, Sep 29, 2009 at 4:30 PM, Rob Scheepmaker <span dir="ltr"><<a href="mailto:r.scheepmaker@student.utwente.nl">r.scheepmaker@student.utwente.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I never really considered the case of implementing a native Plasma::Services<br>
in jolie script since that could get a bit complicated anyway, considering the<br>
access control/message signing, plus additional overhead like the fact that we<br>
should send over valid kconfigxml describing the parameters.</blockquote><div><br>Message signing and access control shouldn't be too hard to code: I'd like to write some sort of standard Jolie library for handling Plasma services and to distribute it with Jolie. Could you provide the workflow specs? (describing them here is fine)<br>
<br>We had some work on generating kconfigxml automatically from Jolie interface files, see <a href="http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/tools/jolie2plasma/">http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/tools/jolie2plasma/</a><br>
Only problems are w.r.t. certain data types (which I see you already know by your explanation in the following).<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, publishing<br>
a Plasma::Service using a different technology (like as a SOAP service) would<br>
be tricky since the access/control and message singing would make this SOAP<br>
service quite complicated to use<br></blockquote><div> </div><div>Well, a lot of SOAP services in the industry there have very complicated specifications on how to access them. I don't think anybody would kick us for some security parameters that need to be added to messages. :-)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I mostly considered the case of accessing something like a SOAP service from<br>
plasma as something seperate, where we could leverage jolie, but need to use a<br>
different approach. In that case we would want some wsdl to jolie converter<br>
for example, since it would be a pain if a developer that just wants to use a<br>
web service needs to do that by hand. And a wsdl to configxml convertor, since<br>
Plasma::Service need to provide valid configxml. And a seperate Service<br>
implementation that doesn't do any access control stuff and just calls<br>
operations on the service, but this would be a relatively small and trivial<br>
class to make. I could at some point add a function to access manager to<br>
access any non native plasma service through a Plasma::Service. If/when (?)<br>
there are converters to help us with the wsdl, it should be very easy ... both<br>
to implement, and to use.<br></blockquote><div><br>This is true, but if we provide a way to use the loadEmbeddedJolieService in MetaService so to load custom Jolie scripts and see them as a Plasma::Service I can at least access SOAP services by making a Jolie script. In a lot of cases making a Jolie script for accessing a SOAP service is easy, and there are hard cases in which I would like to use a Jolie script even if I had all the automatic converters because there could be a necessity for some additional orchestration (security protocols, handshaking etc...) which Plasma doesn't support.<br>
<br>For the future tools, we would just need a WSDL2Jolie converter, since we already have Jolie2Plasma (which converts a Jolie interface to a kconfigxml service descriptor).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The problem of streaming the parameters is not entirely solvable. The<br>
parameters passed to any Plasma::Service are a QVariantMap. I could obviously<br>
put every element of the map as seperate child node, but they're still<br>
QVariants, and those will need to be serialized/deserialized.<br>
I could use the 3 native sodep types: string integer and double directly, but<br>
this doesn't solve the issue for all the types out there, just for some of the<br>
most common ones.<br>
</blockquote><div><br>I suggest we go this way:<br>- if a parameter can be cast to a sodep data type, convert it;<br>- otherwise, serialize it.<br><br>Nevertheless, maintain the separate child node structure. This way we already have a mostly working implementation (I imagine most parameters in Plasma are integers, strings, doubles and booleans?) and I can start adding sodep data types appropriately as we see necessary.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Another problem I've seen is that the remote widgets framework makes use of<br>
> special operations like startOperationCall, and others for checking access<br>
> control. There is nothing wrong with this, but then for performing "normal"<br>
> operation calls you are passing the operation name in the message data, not<br>
> in the message headers. This breaks interoperability with everything<br>
> because you've got two levels of operations, the special one and the<br>
> normal one, whereas services have just one. A quick solution for this<br>
> would be to make these operation names standard and reserved for<br>
> Plasma::Service, or (better) to hide them behind a specific resource name<br>
> (e.g. "PlasmaControl").<br>
<br>
</div>Yeah, I suppose I could put the actual operations in the operation name<br>
instead of the startOperationCall parameters.<br></blockquote><div><br>That would already be a great step forward, yes.<br><br>What I'd like to get working first is to, at least, be able to implement local (yes, local) services in Jolie. By doing so I would already gain a lot of power, for example a plasmoid could load this Jolie service using loadEmbeddedJolieService in MetaService and I could use this Jolie service to orchestrate whatever distributed application in a network, hiding the complexity from Plasma.<br>
Orchestrating a distributed application could be something complicated (multiparty p2p session) or simply accessing your GoogleMail. ;)<br></div></div>