WCF service metadata

Question

Hi all,

Per default, all data contract entities, involved in realization of service operation (and their known types, are include in service metadata. I am trying to find out, if it is possible in include other classes or data contracts in the metadata. The reason for this is that i have some enums, which can be used to fill in string fields of entities involved in service operation or, when service returns error messages, they have an identifier which I would like to "translate" or give a meaning to it without referencing some assembly form the external service.

Is such thing possible, or have someone other hints how to deal with this?

Thank to all in advance.

Ilustratory exmaple of service declaration would be something like:

[DataContract(Namespace = "http://schemas.example.com/Common/ExampleServices/V20090903")]
public enum SearchTaskField
{

    [EnumMember]
    Id,
    [EnumMember]
    Date,
    ...
}

[DataContract(Namespace="http://schemas.example.com/Common/ExampleServices/V20090903")]
public class SearchCondition 
{

    [DataMember(Name = "ColumnName")]
    public virtual string ColumnName
    {
     get; set; 
    }

    [DataMember(Name = "ColumnValue")]
    public virtual object ColumnValue
    {
     get; set;
    }

    [DataMember(Name = "ObjectType")]
    public virtual string ObjectType
    {
     get; set; 
    }
}

[ServiceContract(Namespace="http://schemas.examle.com/Common/ExamleServices/V20090903")]
public interface IExampleServiceServiceContract
{

    [OperationContract(Name = "Search")]
    SearchOut Search(SearchIn messageIn);
}

[MessageContract]
public class SearchIn
{

    [MessageBodyMember(Name = "Conditions", Order = 1)]
    public virtual IList<Condition> Conditions
    {
     get; set;
    }
}

Answer 1

Would the EnumMember attribute work for you?

Answer 2

If you add a [DataContract] to your enums, they should be included in your metadata automatically. That's by far the easiest way to do this.

You can also extend the way the metadata is creating and presented - in WCF, you can extend just about everything :-) - but that involves a lot more code. One example is Christian Weyer's "flattening WSDL" service behavior - he taps into the process of creating the metadata by adding an endpoint behavior to his service endpoints.

Similarly, you could write your own endpoint behavior to extend your service - but again: just marking your enum types with [DataContract] should do the trick much more easily.

Marc

UPDATE: I think your enum is not being serialized into the meta data since it doesn't appear to be used - or is that impression wrong?

What happens if you e.g. add a field of that "enum" type to one of your DataContract classes? I would think, if it's really being used, then it will show up in your metadata...

Answer 3

You can decorate your service with the ServiceKnownType attribute. This will cause the specified type to be included in the metadata even if it is not directly used by the service contract (that is not involved in the object graph of one of the other exposed types).

As you have already done, you must mark the enum as a [DataContract] and each enum value as an [EnumMember]. Adding the following line to your ServiceContract interface will expose the enum on the client.

Remember you'll need to update the service reference to see any changes in the generated code.

[ServiceKnownType(typeof(SearchTaskField))]

Answer 4

Service metadata is not intended for the purpose of defining an API. Only the types actually used by the service will be reflected in the metadata. If you want other types to be used by the clients, then you should do the exact same thing you would have done with a class library: put the shared types into a shared assembly.

Of course, this doesn't help clients not running .NET, but by attempting to expose random types, you've already moved away from SOA, so you shouldn't mind much.