Can OO be SO?

There is one thing that WSDL doesn't give you that in a dynamic web services environment you are going to need - a decent binding/construction mechanism.

Somehow, something needs to figure out what to do with a request and what service to run. WSDL currently fills this space - but badly. I see the stuff in SOAPAction and wsa as 'processing hints'. The point is that it is not up to the caller to specify how the receiver handles their call - this is an implementation detail of the receiver and should not be visible to the caller at all. That piece of information passed in Clemens' example is just a binding mechanism - shared data. If it is passed out through a service at some earlier point from a back-end system - that's bad - really bad. Now it's tightly coupling two systems across the internet (or whatever) with a piece of internal data - a primary key of a table in a database probably. But the data could live on the client forever. You might get away with it with a bank account number but other data is more perishable, email addresses, phone numbers for example. Long-lived sure, forever, no. This is very different to a 'RainFall' service that takes a State code like 'AZ'.

Consider versioning. Last week there was a lot of talk on this topic. We agreed how URIs squeal when they get burned so procreating in abandon is a bad thing. Why not have a single binding - www.example.com - everything else is figured out from what's passed in the message. How that is passed, as EPR parameters or client-server a priori agreed mechanisms (say, in the message body) is not important. I see one of the horrible things about publishing URIs/URLs as EPRs (whether in WSDL or wsa) left-right-and-centre is that you've got to maintain them, and like you say using the wrong scheme you could end up with thousands.

I do not expect WSDL to effectively tell me the address of an instance of a service or behind a service. It sucks at this. WSA is the mechanism.

Really, the object instance is just an object(service) and state(data); the state just happens to be a piece of shared data. But there needs to be a constructor. The client expects the caller to use a well-known shared (foreign) key to do something with. This is generally bad. The problem of sharing keys between parties is a big one which Clemens has hit on with bank accounts - who owns the key? Everyone will hit this at some point if they are using webservices to fetch stuff and then later update their 'copy' (eg with WS-Transfer) - they need to pass something that was known to both parties last time they talked - the object ref - or instance - or...moniker.

So, I don't see this as a services looking like objects issue per se but rather as an identity problem. How do we exchange and identify such information in time and space in an abstract way to cleanly identify a service from its resources to identify it as a service instance?