Re: SOAP over SSL

From: Chris Andrews (chris@nodnol.org)
Date: Mon Oct 27 2003 - 17:16:00 EST


Tim Woodcock wrote:
> A question for you.
>
> Is SOAP a request language or a stream language?
> The request below is in request format. You send a request, and get an
> answer back.
>
> That is NOT the way opensrs operates.
>
> The OpenSRS system is set up so that you open the connection and send a
> stream of commands to the server.
>
> This means, that you should be able to make several requests during the
> same session.
>
> For example:
>
> login
> lookup mydomain.com
> lookup mydomain.ca
> lookup mydomain.net
> exit.
>
> Or for that matter,
> login
> register thisdomain.com
> register thatdomain.com
> register theotherdomain.com
> transfer thisotherdomain.ca
> lookup thisdomain.com
> get_info something.ca
> exit.

SOAP's not tied to a single transport. When run over HTTP, as is most
common, you make one request, and get one reply. You can run SOAP over a
bare TCP connection though, and in that case you're free to make as many
requests as you like over that connection.

Having said that, I can't imagine that it would be wise to use anything
but SOAP over HTTP, because that's the best-supported way of using it.

I think the OpenSRS API is pretty close to the SOAP over HTTP model -
you make a request for an authentication cookie, then make any number of
requests using that cookie, then you request that cookie be destroyed.

You're only authenticating once for all the requests you make (within
the validity of a single cookie), although you are using a separate TCP
connection for each one - but that's a *tiny* overhead compared to the
whole XML and SOAP shebang.

As for authenticating access to the SOAP service itself, there's all
manner of different ways - with HTTP, ordinary Basic authentication is
possible, with SSL there's client certificates, and there are also
standards like XML Signature and XML Encryption.

.NET people - what authentication methods are available/usual for SOAP
services on that platform?

> There are really good reasons for maintaining a protocol that allows you
> to stream requests. Those reasons do not particularly apply to smaller
> resellers, particularly those who do not want to use perl...

I'm not sure I follow you here. Could you expand on this?

Chris.



This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:48 EDT