0

I have a web service that implements two contracts:

[ServiceContract]
public interface IServiceA
{
    [OperationContrcat]
    void OpertationA();
}

[ServiceContract]
public interface IServiceB
{
    [OperationContrcat]
    void OpertationB();
}

public class Service : IServiceA, IServiceB
{
 …
}

in my web.config I have the service defined with separate endpoints for each contract, which works perfectly, but I want to be able to export WSDL for each contract separately as well.

Currently I only get a single WSDL for the whole service which, when used, generates a client that sees both methods from IServiceA and IServiceB.

I am wondering if there is a way to provide a separate wsdl in a way that if I require ServiceAClinet I can use a wsdl that defines only methods from IServiceA and the same for IServiceB.

After some searching I found this Single endpoint with multiple service contracts which is actually a good idea and does not require too much additional work, but I was wondering if it is possible to do it without wrappers?

Thank you in advance.

veili_13
  • 63
  • 1
  • 9

2 Answers2

1

Though in OOP there it is useful to derive from multiple interfaces but for WCF it results in questionable benefits. By rolling into one you force all to share the same instance context; concurrency; and possibly security models.

I would urge you to keep the services separate.

i.e.

  • separate service implementation projects (only for your case because you want separate WSDLs, normally it is a best practice to put service implementation into a single project)
  • WCF service methods should ideally be nothing more than thin wrappers to your actual service logic defined in another project that has nothing to do with WCF/REST/etc. Have the wrappers delegate calls to the implementation

If you follow this advice, then the problem of how to get separate WSDLs goes away.

Tell me more

enter image description here

  • Thanks for the book I have been reading on SOA for the past few days and stumbled on arcitura. It will come in handy for properly implementing new services. Unfortunately I cannot use it currently. I will however mark this as an answer as it is by far a better solution. – veili_13 Mar 30 '19 at 07:25
0

I ended up using Singleton pattern and implemented to get the convenience of having one service implemented and somewhat separation of concerns in regards to the client.

EDIT:

public class ServiceA : IServiceA {

    public void OperationA() {
        Service.Instance.Operation()
    }

}

and the same for ServiceB. Once I did that I changed my .svc files to generate WSDL only for the Contract implementations and not main service.

EDIT 2:

While I did find a workaround for my problem this is not the best practices. A much better and approach would be what @MickyD answered i.e. design services with SOA and SOLID principles from the start, this will make your service much more maintainable and salable.

veili_13
  • 63
  • 1
  • 9
  • Not only should you post the code that solved your problem but I don't understand how making the service a singleton solves the problem. WCF singletons are a pure .NET internal implementation detail that matters not to callers of your service. Singleton information `won't` appear in the WSDL nor should it –  Mar 29 '19 at 01:38
  • Also, if you really want to follow SOLID and _"separation of concerns"_, you wouldn't be trying to essentially fuse `two services` into `one`. For WCF (and SOA/microservice best practice in general) you want to avoid monolithic services, an aim that you set out to solve but didn't –  Mar 29 '19 at 01:40
  • Sorry, I forgot to post the code and explanation. Second "fusing" two services into on is not something unknown to SOLID, for example you can have a `Register` class that implements `IAddToRegestry` and `IGetFromRegestry`. This will make the `Register` class simpler to use and at the same the user of the Registry will only be concord with what he needs (get/set from/to register). – veili_13 Mar 30 '19 at 07:16
  • Additionally going with SOA could have helped but the project itself would have needed to get a major refactoring. While I agree that this is something it should have been done, unfortunately it isn't. – veili_13 Mar 30 '19 at 07:19