XPO

First of all, my apologies – I haven’t had time lately to continue the series of posts about XPO and distributed applications.

Luckily, others have been doing some work on the same topic, and so I can refer you today to a knowledge base article, published last week, that details how XPO can be used with a Web Service. It’s here: AK3911

As you’ll notice when reading the description, this approach makes use of the same principles as the Remoting approach I blogged about earlier – it makes one of the distribution-friendly interfaces (in this case IDataStore) available by way of an XML Web Service.

So now everybody can use my Web Service, right?

Wrong. Well, at least not the way you might think. Why? Simple: because this approach works only if client has the complete XPO infrastructure available. Think about it – you’ve seen the interface of the Web Service:

public class Xpo : System.Web.Services.WebService {
  [WebMethod]
  public ModificationResult ModifyData(params ModificationStatement[] dmlStatements) {
    ...
  }
  [WebMethod]
  public SelectedData SelectData(params SelectStatement[] selects) {
    ...
  }
}

So the data that goes over the wire is encapsulated in the four types ModificationStatement, SelectStatement, ModificationResult and SelectedData. How are you going to create a ModificationStatement on the client, ready to send over to the server? What are you going to do with the ModificationResult that’s returned?

Of course the types are described in the WSDL definition that the service returns, so you can have equivalent types created on the client side, automatically if you want (just add a web reference in VS to see this). But you need a lot of code to actually create and handle the content of these types – of course you could write that code yourself on the client, but then you’d end up with a library closely resembling XPO itself.

The conclusion has to be: while this approach is technically able to make a service available to arbitrary client systems (as long as they support XML Web Services), a client can’t really use this type of service if it doesn’t have XPO itself available. So it’s not really every arbitrary client that can use this service, it’s just those clients that are written on .NET and that use XPO themselves.

Why would I use this approach?

You wouldn’t. Not to sound condescending, I should probably say “I wouldn’t”. There’s no advantage to this approach, that I can see. In the situations where you could theoretically make this work, you’d be better off using .NET Remoting instead, as it offers you a richer platform for your own extensions, and it might have a slight performance advantage in the form of binary serialization. .NET Remoting can also be more flexibly deployed, offering IIS hosting of SOAP (the same the Web Service scenario uses) as well as in-process deployment, which can come in handy in those cases where you actually have an XPO client/server setup.

So what if I want to create a Web Service that’s really available to arbitrary clients?

Good question. I’m not going to explain this right now, but this is what the next post is going to be about. Watch this space!