Remote login via XML-RPC or SOAP?
62 views
Skip to first unread message
Rodrigo Cea
Sep 14, 2009, 10:07:13 PM9/14/09
to Django users
I am creating a Django website for a client who won't give me access
to their database or server, but will allow login / account creation
on their server via SOAP or XML-RPC from my server, where the Django-
based website will reside.
I would like to get an idea beforehand about which route, SOAP or XML-
RPC, is easier, more stable, less buggy, more widely used, etc.
The process will be:
a) user inputs new account info on my server (lets call it D for
Django).
b) account is created on client's server (lets call it C for client)
c) C responds with Success or Fail.
d) next morning, user logs in via D
e) C responds with Success or Fail, plus some user info such as name,
age and other info gleaned during step (a).
f) D stores this information to use during the session and logs in
user.
Any help, caveats, libraries or suggestions are much appreciated.
to their database or server, but will allow login / account creation
on their server via SOAP or XML-RPC from my server, where the Django-
based website will reside.
I would like to get an idea beforehand about which route, SOAP or XML-
RPC, is easier, more stable, less buggy, more widely used, etc.
The process will be:
a) user inputs new account info on my server (lets call it D for
Django).
b) account is created on client's server (lets call it C for client)
c) C responds with Success or Fail.
d) next morning, user logs in via D
e) C responds with Success or Fail, plus some user info such as name,
age and other info gleaned during step (a).
f) D stores this information to use during the session and logs in
user.
Any help, caveats, libraries or suggestions are much appreciated.
dfis...@ucsdmail.com
Sep 15, 2009, 4:16:34 AM9/15/09
to Django users
SOAP and XMLRPC have quite a few tradeoffs, but without knowing
exactly what your setup is (other than Python/Django) I'd advise you
to go with XMLRPC. However, I'll lay out why I think so and perhaps
SOAP does make more sense for you.
SOAP is the successor to XMLRPC and some people -- notably people from
the Java and .NET worlds -- think that SOAP is "better". In the Java
and .NET worlds, SOAP is pretty common but a lot of the scripting
language worlds are moving toward a third option REST which I won't
get into here since it doesn't seem to be an option for you. With
Python, XMLRPC is built into the standard library where you'll have to
go to Pypi for a SOAP library. Rolling your own SOAP library is
probably not a good idea since SOAP is complex and verbose. In
addition, there are occasionally incompatibilities with .NET SOAP
services or so I've been led to believe from others at work.
While SOAP is certainly more complex, in some cases it can make up for
it with type checking, code generation or object translation. SOAP
services usually make use of a web service description language
document (WSDL) that describes the service and can contain XML schemas
that describe in great detail the properties of the objects in the
service. Using this, a SOAP library may be able to automatically take
native objects and send them in web service calls or take web service
responses and translate them into objects. It is possible that with a
good library, you may need to write less code with SOAP. In general,
XMLRPC in Python will translate your objects into requests and
responses into objects, but XMLRPC only supports a few data types
(int, float, list, dict, datetime) compared with SOAP. Possibly
because of this lack of complexity, XMLRPC is pretty well standardized
between various clients and servers. If you just need to use a couple
services that your client is exposing and those services accept just a
couple primitive parameters, XMLRPC is your best bet.
exactly what your setup is (other than Python/Django) I'd advise you
to go with XMLRPC. However, I'll lay out why I think so and perhaps
SOAP does make more sense for you.
SOAP is the successor to XMLRPC and some people -- notably people from
the Java and .NET worlds -- think that SOAP is "better". In the Java
and .NET worlds, SOAP is pretty common but a lot of the scripting
language worlds are moving toward a third option REST which I won't
get into here since it doesn't seem to be an option for you. With
Python, XMLRPC is built into the standard library where you'll have to
go to Pypi for a SOAP library. Rolling your own SOAP library is
probably not a good idea since SOAP is complex and verbose. In
addition, there are occasionally incompatibilities with .NET SOAP
services or so I've been led to believe from others at work.
While SOAP is certainly more complex, in some cases it can make up for
it with type checking, code generation or object translation. SOAP
services usually make use of a web service description language
document (WSDL) that describes the service and can contain XML schemas
that describe in great detail the properties of the objects in the
service. Using this, a SOAP library may be able to automatically take
native objects and send them in web service calls or take web service
responses and translate them into objects. It is possible that with a
good library, you may need to write less code with SOAP. In general,
XMLRPC in Python will translate your objects into requests and
responses into objects, but XMLRPC only supports a few data types
(int, float, list, dict, datetime) compared with SOAP. Possibly
because of this lack of complexity, XMLRPC is pretty well standardized
between various clients and servers. If you just need to use a couple
services that your client is exposing and those services accept just a
couple primitive parameters, XMLRPC is your best bet.
ash
Sep 16, 2009, 4:15:53 AM9/16/09
to Django users
Why do we need such a mechanism for the relationship between
client database and the master server. Maybe you need something
else entirely. Could you tell more general idea.
On Sep 15, 12:16 pm, "djfis...@gmail.com" <dfisc...@ucsdmail.com>
wrote:
client database and the master server. Maybe you need something
else entirely. Could you tell more general idea.
On Sep 15, 12:16 pm, "djfis...@gmail.com" <dfisc...@ucsdmail.com>
wrote:
Rodrigo Cea
Sep 16, 2009, 8:14:25 AM9/16/09
to Django users
> Why do we need such a mechanism for the relationship between
> client database and the master server. Maybe you need something
> else entirely. Could you tell more general idea.
The general idea is to allow users to register and login on our
> client database and the master server. Maybe you need something
> else entirely. Could you tell more general idea.
server, but store all the users information on our client's server,
including authentication info. The client will not give us direct
access to their database, but are willing to allow us a limited form
of access via XML-RPC or SOAP, basically logging in users and
retrieving some of their profile information.
ash
Sep 17, 2009, 2:54:08 AM9/17/09
to Django users
I recommend the following, every client must will be run XMLRPC
server,
which allow access for your with their database. You must developed
skeleton this XMLRPC server with uniform set of public methods,
every client himself realised this methods, because their databases
may
be different.
Base XMLRPC server is twisted framework. Look at these simple
examples:
http://twistedmatrix.com/projects/web/documentation/howto/xmlrpc.html
Django-based website will be give access for their servers and managed
their accounts.
server,
which allow access for your with their database. You must developed
skeleton this XMLRPC server with uniform set of public methods,
every client himself realised this methods, because their databases
may
be different.
Base XMLRPC server is twisted framework. Look at these simple
examples:
http://twistedmatrix.com/projects/web/documentation/howto/xmlrpc.html
Django-based website will be give access for their servers and managed
their accounts.
Reply all
Reply to author
Forward
0 new messages