Fog Creek Software
Discussion Board




Web Services - is this all vapour?

I just started working in a consulting firm. We are constantly bombarded by vendors claiming that they offer Web Services.

My feeling is that it is mostly vapour-ware and marketing generated to take advantage of a buzz word.

Is there sudstance to Web Services? Is anyone actually using it?

Calem Stein
Thursday, July 31, 2003

There is substance, and people are using it. However, it's also heavily over-hyped.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, July 31, 2003

My personal favorite example of the hype is the web services that converts Celsius to Fahrenheit. Yeah, that's useful. Yeesh.

I think a lot of the hype centered around being able to sell your web service; stock quotes, weather, etc.. Sure, maybe, but that just hasn't really materialized that much.

A more common use of web services seems to be having two systems communicate with one other with XML. Web services can be ideal in situations like this. It ain't sexy, but it's often just what the doctor ordered.

Mark Hoffman
Thursday, July 31, 2003

I just deployed a web service with a major financial company -- all though it isn't SOAP based and uses straight HTTP.  I think rolling out web services is far more complicated than Microsoft makes it out to be.  Especially if you care about things such as availability and scalability.  For these reasons most of our infastructure is custom built, since the technology is young. 

Having done it for a few years, I honestly feel we have a better understanding of what it takes to maintain a 24x7 web service infastructure than the ASP.NET product manager. 

I don't think the technology is revolutionary as much as evolutionary.  But it is important.

http://www.baus.net

christopher baus
Thursday, July 31, 2003

I don't think the "Service" part of Web Services has materialized in a big way as someone else mentioned.  A lot of people are just using it as a conveniant middleware replacement.

chris
Thursday, July 31, 2003

But isn't exchanging XML data a common occurance?

XML helps standardizes the exchange of data. EDI and RosettaNet has been doing this for years. XML is just a method to supposedly help make standardization easie - the vendors or standards organization has to agree on the format.

A lot of the Web Services hype was beyond the exchanging of data - actual invoking of method or classes on different platforms. Using Web Services as a replacement for RMI, CORBA etc. Is this, or will this, happen?

There are vendors such as Systinet (www.systinet.com), that clam to provide Web Services to an organization. I can't for the life of me figure out what they actually do. Or will they contribute to the IT efficiency of my business?

Calem Stein
Thursday, July 31, 2003

> A lot of the Web Services hype was beyond the exchanging of data - actual invoking of method or classes on different platforms. Using Web Services as a replacement for RMI, CORBA etc. Is this, or will this, happen?

I hope so.  My feeling is that SOAP over HTTP is superior to either primarily because it uses well understood server infastructure. 

Plus I think there is a mind set difference between the two.  Distributed object orientation was based on the idea that the developer could design an object model just as if it was all in process, and then distribute the objects as it makes sense latter.  I find that with latency, partial failure, marshalling, etc., this is almost never the case.

When developing a web service the developer thinks:

"ahh, web stuff.  I understand that.  When I go to joelonsoftware.com it takes anywhere from 1/2 second to 10 seconds to load.  Sometimes when my network is really congested it doesn't work at all, or only 1/2 the page."

Hence the developer is thinking about these issues up front.  This is the right mind set to be in when developing distributed software systems.  Ignoring these issues was idealistic and a Bad Idea (tm).

christopher baus
Thursday, July 31, 2003

My only complaint about the basic use of web services as an RPC is that the bandwidth is typically heavy, and there is a considerable amount of processor time to covert data types to text and back.  This doesn't matter much with today's blazingly fast machines and broadband connections, but implementing a text RPC over a narrowband line can be reasonably costly.  Especially if anything besides your program needs that line.  A binary implementation instead of the typical XML/SOAP solution would be more apt for those cases.

Elephant
Thursday, July 31, 2003

How about compressing the data before and after it hits the line.  Trading CPU time for bandwidth...

http://www.baus.net/

christopher baus
Thursday, July 31, 2003

Web services , when using the 'XML for data exchange' analogy, can be as simple as RSS.

This is not revolutionary but is a useful tool.

Vendors take this a step further and use the standardization of XML exchange between services as Web Services. i.e. between an ERP and Call-Center.

This again is not revolutionary - just plain tedious and time consuming. BizTalk and other convetors help the process. The hardest part is creating the data standards - hard only because it is time consuming and frustrating.

There is nothing new here. Just stuff that has been around sine the early nineties - just happens to be better structured :)

Calem Stein
Thursday, July 31, 2003

Been there, hate it :-(
Too complicated for its own good.
Recently co-developed two web services for internal use (one system needs info from another) with relatively simple interfaces in a J2EE environment.

Totally unnecessary. It would have been A LOT easier to write a servlet, taking simple HTTP parameters, and returning a response in a pre-defined, easily parsed format. I suggested it, but got the response that my solution was "not standard".

It required:
* Installing web services component on web container (with all learning time that it requires), adding new complexity to our already messy system (another component to keep track of, integrate, etc).
* writing WSDD code for definition of service (a real pain).
* writing stub code for the service (quite easy when the WSDD is in place).
* Deployment hassles/configuration of web services in web container.
* Writing a plugin to the web services component for access of HTTPS parameters (we needed to extract info from client certificate, to authenticate the invoker of the web service method). A real pain.
* writing a configurable custom client application for testing the bloody monster, which read XML data from file, and feeded it to the web service. Would not have been necessary at all if we had used HTTP.


Aaarrgh! And some people ask why I loathe J2EE.

Anonymous (I have my reasons)
Thursday, July 31, 2003

Anonymous,

We almost went down the same bloody route.  We spent day's trying to configure the tooling for webservices and it was nothing but pain with SOAP messages (rpc/encoded vs document/literal).  We finally gave up and went with a simple http post (which is what we intially started with).  We had our app up and running in half a day. 
 

Just Say No To Webservices
Thursday, July 31, 2003

I think that Web Services have their fit.  Largely though, much of the push toward them (from where I sit) seems to come from pointy haired management types.  From up on high, they hear "Web Services" and think "Next big thing!" and promptly push it down the pipe w/o knowing what it really is/means/does.

Elephant
Thursday, July 31, 2003

With all those messages about the complexity of SOAP, funny that no one mentionned its easier to implement alternative that is XML-RPC :-)

Frederic Faure
Thursday, July 31, 2003

I'd consider HTTP POST to be a basic web service mechanism as well.  Just one that isn't as structured.  I think web services are programatic interfaces that can be used by third parties over the public internet, which make use of widely available technologies such as HTTP.  Using XML messaging is just a slightly higher level.

Standards like WSDL just make it easier to integrate already written componets.  For one offs, I suspect that web services are overkill.

christopher baus
Thursday, July 31, 2003

I think web services are like anything else... a company with a good business model, good product, good marketing, and good luck can make it.

Other companes get into it because they think it's easy money, or are overly ambitious. Web Services sounds like an easy company to start... no business model, just "we can program it for you wholesale."

www.marktaw.com
Thursday, July 31, 2003

I have not ventured too deep into the WS stack, but will have to in the near future. Maybe at this point the biggest lack is the availability of an excellent widely available tutorial.
I think everybody is joyed about the availability of an interoperability standard that has wide buy-in form all sections of the market.
My main question is wether they have succeeded in keeping simple things simple, while ramping up towards enterprise class services. Sure, the whole WS-* specs are needed for large real world systems. People that claim otherwise are just not envisioning large systems, and if they do, they will find out they have to write their own equivalents. But what is the entry path for smaller, simpeler needs? Does one suddenly have to stop and study spec after dreary spec for a year if one wants to do certificate based authentication of simple soap messages, or have things been kept nice and modular with welll chasen defaults etc. I don't know. I will find out.

Just me (Sir to you)
Friday, August 01, 2003

Calem,

>> Is anyone actually using it? <<

Desaware have found an interesting use for Web Services. They sell a .NET product licensing app, which works as follows (over-simplified for brevity):

1) You strongly-sign your .NET product (set of .NET assemblies). This means that the CLR guarantees that nobody is allowed to tamper with your app in an attempt to bypass the licensing code.

2) Your customer buys your product and receives a 128-bit product key which s/he enters into your application.

3) Your app uses the strongly-signed licensing component to call your Internet web service, passing the aforementioned key and a strongly-hashed machine ID. Your web service validates the key against its internal database, then passes back a signed digital certificate to the requesting machine. The OS ensures that nobody can tamper with the digital certificate.

I like this scheme - one of its advantages is that it's trivial for my company to setup a secure Internet-facing web service for this purpose. So we're seriously considering this licensing idea for our current high-value software product.

Mark

Mark Pearce
Friday, August 01, 2003

The two good web services I've seen / heard of are:
a) Address validation services (The UK Post Office had a demo, unsure if it made it into production)
b) UPS parcel tracking (We nearly used it but in the end just linked straight to their website)

It's perfect for directory type services, they just need to sort out the billing issues.

Peter Ibbotson
Friday, August 01, 2003

This is good reading on the topic, and links to other documents as well:

http://www-106.ibm.com/developerworks/library/ws-starthere.html

Jonas B.
Saturday, August 02, 2003

*  Recent Topics

*  Fog Creek Home