Remote widgets, the next steps

[Rob Scheepmaker]

On Tuesday 29 September 2009 18:04:07 Fabrizio Montesi wrote:
> On Tue, Sep 29, 2009 at 4:30 PM, Rob Scheepmaker <
> 
> r.scheepmaker at student.utwente.nl> wrote:
> > I never really considered the case of implementing a native
> > Plasma::Services
> > in jolie script since that could get a bit complicated anyway,
> > considering the
> > access control/message signing, plus additional overhead like the fact
> > that we
> > should send over valid kconfigxml describing the parameters.
> 
> 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)

Cool, I'll append some more information to the remote widgets design doc when 
I've got the time.

> We had some work on generating kconfigxml automatically from Jolie
>  interface files, see
> http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/tools/jolie2plasma/
> Only problems are w.r.t. certain data types (which I see you already know
>  by your explanation in the following).

Nice, thanks for the pointer... I'll give it a spin soon.

> Also, publishing
> 
> > a Plasma::Service using a different technology (like as a SOAP service)
> > would
> > be tricky since the access/control and message singing would make this
> > SOAP service quite complicated to use
> 
> 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. :-)

Ok, it'll require me to change the implementation to no longer stream 
Credentials to a bytearray, but append the different fields as child nodes in 
the message to be somewhat usable, but that's a relatively minor change. And I 
suppose we could always write some libs for php/ruby/whatnot to make accessing 
these plasma soap services easier.

> > I mostly considered the case of accessing something like a SOAP service
> > from
> > plasma as something seperate, where we could leverage jolie, but need to
> > use a
> > different approach. In that case we would want some wsdl to jolie
> > converter for example, since it would be a pain if a developer that just
> > wants to use a
> > web service needs to do that by hand. And a wsdl to configxml convertor,
> > since
> > Plasma::Service need to provide valid configxml. And a seperate Service
> > implementation that doesn't do any access control stuff and just calls
> > operations on the service, but this would be a relatively small and
> > trivial class to make. I could at some point add a function to access
> > manager to access any non native plasma service through a
> > Plasma::Service. If/when (?) there are converters to help us with the
> > wsdl, it should be very easy ... both
> > to implement, and to use.
> 
> 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.

true.

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

That would be lovely... such a converter could make a lot of common cases 
extremely easy to use. Think of something like:

Plasma::Service *service = 
  AccessManager::self()-
>accessService("http://soap.amazon.com/schemas2/AmazonWebServices.wsdl");

and then just being able to use service just like any Plasma::Service.

> 
> > The problem of streaming the parameters is not entirely solvable. The
> > parameters passed to any Plasma::Service are a QVariantMap. I could
> > obviously
> > put every element of the map as seperate child node, but they're still
> > QVariants, and those will need to be serialized/deserialized.
> > I could use the 3 native sodep types: string integer and double directly,
> > but
> > this doesn't solve the issue for all the types out there, just for some
> > of the
> > most common ones.
> 
> I suggest we go this way:
> - if a parameter can be cast to a sodep data type, convert it;
> - otherwise, serialize it.
> 
> 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.

Ok, sounds sensible.

> 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.
> Orchestrating a distributed application could be something complicated
> (multiparty p2p session) or simply accessing your GoogleMail. ;)

Cool stuff :p

Thanks for your feedback. You've given me some useful stuff to make the 
implementation more flexible. I'll be improving the implementation, and will 
keep you informed of the progress.

Regards,
Rob