veili_13
veili_13

Reputation: 73

Generate seperate WSDL for contracts (per contract) implemented by single service

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.

Upvotes: 0

Views: 308

Answers (2)

veili_13
veili_13

Reputation: 73

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.

Upvotes: 0

user585968
user585968

Reputation:

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

Upvotes: 1

Related Questions