Package: rsl
RSL - Remote Service LibraryThis module provides a collection of interfaces and a “plugin” mechanism to
access remote services with different protocols and technology in a unified
way.The library has been developed as part of a “command line shell service
integration”. It has been separated into its own package to allow a modular
installation and if may be useful for other projects too.RSL is a pure client side library which allows easy access to web services. It
provides a full abstraction of service protocol and technology and tries to map
each remote service to Python methods. Hence, from a programmers point of view,
there should be almost no difference (except some minimal boilerplate) between
a local method call and a remote call. Even the fact, whether SOAP, JSON or
whatever protocol in use, should be completely hidden (but not inaccessible).One of the main goals of the library is, to make it easily possible to add more
web service and transport protocols, without changing all the other parts. This
allows to extend the library bit by bit and makes each package much more
maintainable. It also allows to keep the installation foot print at a minimum
(just install only required modules).DocumentationDocumentation is currently in a very bad shape, but this will change soon, as
the API stabilises. Furthermore, a growing user base which provides feedback,
will shorten this time frame further ;).As mentioned above the core of this modules are the interface definitions, and
the discovery mechanism for “protocol-plugins” using Setuptools and Zope
interfaces. In general the philosophy behind the given interfaces is, that
a web-service client can be split into various components.Transport:Every remote access needs some kind of transport. Transport protocols
are plug-able and can easily be replaced to allow easier integration
into other frameworks like Twisted.Description:As there are many different service description formats, which often
support multiple service protocols, it is just logical to implement
service descriptions as separate components.Proxy:These kind of components have the knowledge to convert the information
from a description and protocols standards into a usable Python object,
which acts as proxy to invoke remote services.De/Serialiser:As different protocols allow different encoding formats, de/serialisers,
are implemented as independent components, which allows to reuse them
wherever appropriate.Typesystem:Often XML based encoding standards, feature an own type system (mostly
expressed as XML-Schema). Such Typeystems, will also be used for JSON,
and probably other future encoding standards will follow. A Typesystem,
tries to map between Python data types and wire-representation, and
allows the actual user, to ignore the technical details.All these components above are implemented as independent from each other as
possible, to allow easy replacement, high reusability, great extensibility
and flexibility, and of course easy installation.The following modules are developed along with this modules:rsl.wsdl: common WSDL modulersl.wsdl1: WSDL 1rsl.soap11: SOAP 1.1 + WSDL 1 SOAP 1.1 extensionrsl.mime: WSDL 1 MIME extensionrsl.http: WSDL 1 HTTP extensionrsl.rest: REST like servicesrsl.jsonrpc10: JSON-RPC 1.0 implementationrsl.smd01: SMD 0.1 implementationrsl.upnp: UPnP descriptionrsl.xmlrpc: XML-RPCrsl.xsd: XML Schema type systemFor examples on how to use the library, please see the additional modules,
and tests included there.StatusThe library works quite well for the command line service integration.
The installation is quite effortless with Python eggs and easyinstall.
However, as the whole project grows quite huge, and it is in an early
development stage, there are many things, which are not solved that elegant,
and it is very likely, that some refactoring will be happen in the near future.
However, most of the refactoring will make the code base more conformant to
PEP-08. The high likeliness in API changes is also the reason why this
release is currently classifiedalpha.An important to-do is, to remove as much inconveniences for the library
as possible, which will also greatly improve the overall library design.The type system component is a bit cumbersome, and currently there is only one
implementation (XML-Schema) available for it. I hope, that the situation here,
will improve, as at least a second type system implementation becomes available.CommentAs this library also supports SOAP, there may be the question: “Why another
SOAP library?”. The simple answer is, that there is no working client side
SOAP library available. I tested all three (or four?) major SOAP libraries,
and not one of them worked with the web service I needed. Most of those
SOAP libraries are just too simple, for my use cases, and others have some
major interoperability problems. (So two reasons: extending an already
available library would be about the same effort, and fixing a full-featured
library, would be even more effort because of ugly code base.)CHANGES0.2.1 (2008-12-09)Fixed source distribution (missing CHANGES.txt file)0.2.0 (2008-12-03)Initial release