JAX
JAX

Reputation: 1620

Consuming SOAP service by dependency injection

I've been developing silveright app which consumes some WCF services. In my WCF, i have several different services that implement the same interface for example:

public class Service1 : IService<Type1> {...}
public class Service2 : IService<Type2> {...}

I've been thinking about acceesing the IService interface from the client app (consumer) to developer a generic class to maximize code re-use for consuming the WCF services for example:

public class MyUnitedOPs<T>  {

      ServiceReference.IService<T> _object;
      public MyUnitedOPs (ServiceReference.IService<T> _object) {
          this._object = _object;
      }
}

But, apparently I can't directly access the IService interface and it is known as IServiceOf_Service1 for instance. Although this can be still cast but the methods that I get from this IServiceOf_Service1 are different from ones that are provided in the service that implements it for example I have BeginAdd and EndAdd while in the service that implements it, I have just an AddAsync method.

So, out of curiosity, is it possible at all to do something like this ?

Upvotes: 0

Views: 1691

Answers (1)

Roman
Roman

Reputation: 2118

You can't make your IService<T> traverse to the client, as this is not supported by WSDL.

However, here are a few things that you can do:

  1. You can have a generic service contract on the server side.
  2. You can also have a generic service implementation on the server side. (you didn't have to create Service1 and Service2, you could stick with Service<T>)
  3. You can host multiple concrete instances of your generic service, each with different type.
  4. The client can reference one or more of your hosted services, and for each it will produce concrete proxies.
  5. The reason you're seeing the BeginAdd and EndAdd is just a technicality of the client side, it does not affect anything happening on the server. From your post, i take it that your Add operation returns a Task, which is an efficient asynchronous implementation of a WCF service, starting from .net 4.5. Even though your operation returns a Task, if you'll check the WSDL generated by the service, you'll see that your operation actually returns something else (an int, or string, or maybe some DataContract, depending on your implementation). That's because asynchronicity, is just an implementation detail of the service, and it doesn't change the contract. The client can call your service in three different ways:

    a. Just call it directly. Meaning the your client will block the current thread.

    b. Use the APM async model, which utilizes methods like BeginXXX and EndXXX, which will initiate the actuall I/O request over the network, from a different thread, not blocking the calling thread like the previous option.

    c. Use the TAP async model, which utilizes Tasks with methods like XXXAsync.

    You control these options (a - c), and many others (for example, what collection types to use for collections? Arrays? List? etc') from the "Add Service Reference" window in visual studio.

Upvotes: 2

Related Questions