Using Web Services with XPO

XPO Team Blog
05 May 2006

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!

Tags
9 comment(s)
Anonymous
Dan Vanderboom
There is a reason to use web services with XPO, which is that Compact Framework doesn't support remoting.  I've worked with DevExpress to create a web service solution, and for distributed solutions involving Windows Mobile OS, it's a lifesaver.
21 June, 2006
Oliver Sturm (DevExpress)
Oliver Sturm (DevExpress)
Dan - interesting you should mention that, because it has recently come up in the XPO newsgroup as well. Of course you are right. Web Services is the only distributed application technology that CF currently supports, and so it's good that XPO can work with it if needed.
21 June, 2006
Anonymous
XPO
I have previously blogged about our knowledge base article AK3911, which describes an approach to tunneling...
13 July, 2006
Anonymous
XPO

I have previously blogged about our knowledge base article AK3911 , which describes an approach to tunneling

28 March, 2008
Anonymous
Mark

Great blog. We just bought the DevExpress suite and being able to use XPO across services would definitely help my case for using it as our persistence framework. Looking forward to the service for abitrary clients.

8 May, 2008
Anonymous
eXpress App Framework Team

This is post no. 10 in the mini series "10 exciting things to know about XAF". You can find

31 May, 2008
Shaw Innes
Shaw Innes

Are you sure that "obscurity" is adequate security?  What would be required to add some sort of authentication to the data requests rather than just assume a malicious person doesn't know anything about XPO, or web services?

25 July, 2009
Oliver Sturm (DevExpress)
Oliver Sturm (DevExpress)

Hi Shaw,

I've been reading and re-reading my post above, but I can't see anything relating in any way to security. I can only imagine that you misunderstood one of the sentences dealing with who "can use" the service -- this is meant literally, as in "is able to use, technically and practically", not as in "is allowed to use".

If you want to add security to your connection, you use the infrastructure provided by your communication technology of choice to do so. XML Web Services, Remoting, WCF -- whatever it is, each of these "protocol stacks" (for lack of a better expression) has its own way of integrating transport level security and usually access control as well, and typically multiple options. Any one of these should be fully compatible with XPO data layer publishing.

Oliver

27 July, 2009
Mélanie
Mélanie

Hi Oliver and everybody,

I need to create a webService. To use my AspxGridViews, I see I need use XpoObject. I created my XpoObject in a new web service project but I don't no how to make communicate my 2 projects.

Do you have a small project of sample that I can download and I can examine, please ?

Best Regard,

Mélanie

29 August, 2013

Please login or register to post comments.