The Old Joel on Software Forum: Part 3 (of 5)

WEB services

Hello,
I am currently working in a company where our bread and butter is EDI data excahnge. We have agencies all over the world and exchange critical data using EDI. (works nicely)

New project comes along (offered by external company)
basicaly trying to replace EDI file exchange with WEB service.

I willl really appreciate your expert opinion on the drawbacks of the WEB services (in their current status) . Pluses i think i know.
Thanks

Seemore
Thursday, November 20, 2003

The #1 drawback to Web Services right now is the fact that authentication is not yet part of the official standard.

It's coming, but it's not here yet.

If your service is going to be open to the public, this is fine.

If your service needs to be restricted to paying customers, then you need to implement your own authentication mechanism or trust in the security of the transport layer.

If you implement your own authentication mechanism, then your clients must read the damn spec and implement it on their side too, which defeats half the point of using Web Services instead of something more efficient. Furthermore, you risk reinventing the wheel badly.

If you rely on the security of the transport layer (like using HTTPS and SSL Client Certificates), then your service is only as secure as the transport layer. Hard-coding authorized IP addresses is an easy, but ultimately insecure method of securing the transport layer.

There are groups (like WS-I) working on this, but it's not at version 1.0 yet.

Richard Ponton
Thursday, November 20, 2003

Authentication is nowhere near as difficult as the web services zealots will have you believe, which is probably because most of the structure (complexity) in web services is totally unnecessary!

1. Use SSL for encryption of traffic.
2. Register your users in your database (user-id/pwd)
3. The first message in a session is LOGON, which returns a session token.
4. Each message returns the token to maintain the session thread.
5. Each response to a message returns a (new?) token.

There.

Authenticated users.
Secure sessions.

Now, use a SIMPLE data format (yes, your old EDI format will still work), perhaps YAML (see earlier thread), and only use XML as a last resort unless you have shares in a carrier providing bandwidth-by-the-bit.

Your customers will be happy :)

HeWhoMustBeConfused
Thursday, November 20, 2003

HeWhoMustBeConfused, session management looks about that easy from Mars, but if you get into it it's a little more complex than that. But okay...

Li-fan Chen
Thursday, November 20, 2003

Another problem, Web is definitely not the most reliable medium for reliable file transfer, so you have to accomodate this weakness with some sort of abstraction that makes it look perfect without human intervention. Web services is quite raw, you don't have anything that will do job request/answer submissions retransmits (you have to deal it with by writing a tunneling library). I think web services standards has implemented transactions though, but I haven't use it enough to know for sure.

Li-fan Chen
Thursday, November 20, 2003

http://www.eweek.com/article2/0,4149,1276856,00.asp

Li-fan Chen
Thursday, November 20, 2003

There's two way to handle transactions.
1. The destination server attempts to [acknowledge message delivery], or

2. the destinationa server attempts to report back on the completion (or failure) of request.

If your only requirement is store and forward acknowledgement it's probably not that hard to find something in the web services standard that supports this, the second one is probably the interesting cookie to crack.

Li-fan Chen
Thursday, November 20, 2003

The authentication issues with Web Services are identical to those of EDI. Principally, neither standard deals with authentication at all. What you get is essentially another transport mechanism.

It is entirely possible to implement web services as CGI programs. Since the HTTP protocol already supports authentication, using that might be a good idea. Technically it's not part of the SOAP protocol, but since the protocol is designed to run over HTTP, take advantage of the things you inherit.

Clay Dowling
Thursday, November 20, 2003

Li-Fan Chen, it really IS that easy. I know because our major software product is currently doing it for a number of customers around the Asia Pacific region. We're about to launch another product doing exactly the same thing.

The saddest thing about web services is the way that people have over-complicated the whole subject. Now we've got yet another internet boom-and-bust technology in the making.

HeWhoMustBeConfused
Thursday, November 20, 2003

You could wait until WS-Authentication (or whatever it's called) has been standardised, or if your transport is HTTP, well... as far as I can see, it's a solved problem. SSL (server certificates) along with client certificates too.

Duncan Smart
Saturday, November 22, 2003