Today, Joel posted some strong opinions about SOAP:

The real problem with SOAP is that it's a completely inadequate remoting system. It doesn't have events (which makes it useless for large classes of applications). It doesn't support references (ditto).

Well, I guess at least for .NET there's Remoting which takes care of this issues.

That said, I have to affirm you that I Like Web Services.

I just see the applications somewhat differently than some people want you to see them. For me, a SOAP service only provides an interface to some backend tiers, compareable somewhat to the GUI of a classic application. Let's say you write an ERP software: what services would you publish via SOAP endpoints? Your complete internal object model or parts similar like the ones which are accessible for your users by using the GUI?

I guess one should only publish services which have a somewhat closer resemblance to business processes (BP). That is, for example, Google published a SOAP API which allows you to access the same BP which you would normally access using your web browser (it's "fetch a list of pages which match my query"). Google definitely wouldn't allow you to access their internal object models or databases.

So, back to the ERP system. In this case, you'd probably publish interfaces that allows the automated entry of orders by identified customers. Again, that's something which would normally be done using your GUI - but this time with the instant benefit that your customers can now place the orders themselves.

When now thinking about Joel's comment again, I guess the question is: Are events necessary in Web Services?. I guess they aren't. Web Services are fine for cross-company computing and cross-platform computing (ever used a DCOM component from an application developed in Perl running on Linux?). For intra-company, LAN based computing with its rich GUIs and fixed sets of application development platforms, there are better ways.

The fine thing is that you can use whatever your platform offers: Running on .NET you have the feature-rich System.Runtime.Remoting and Enterprise Services, on Java there's RMI, EJB and such. If you're still on VB 6 or VC++, go for DCOM/COM+ and if you want cross-platform you could also choose CORBA. The best thing about it: You can still use SOAP endpoints to publish entry points for your business logic, no matter what distributed application platform you chose for implementing them inside your LAN.

To summarize my point: most of the time, a SOAP web service should be a first tier implementation - just like a GUI. An exception can be seen in the integration of programming languages which couldn't work together before. But that's a different story ...