This is primarily intended as feedback, so this, that, or the other person might be more interested than others. I started working on an asp.net soap extension to implement ws-metadataexchange.
The basic idea is that you would adorn your service with metadata attributes as follows:
[Metadata(MetadataAttribute.PolicyDialect, "MyService.policy")]
public class MyService : WebService
{
[WebMethod]
public void DoIt()
{
}
}
where "MyService.Policy" is a relative file path. The SoapExtension checks the wsa:Action, and if it matches one of the ws-mex Actions, it hijacks the request and returns the response. Everything is relatively hard-coded, but once I get my test suite rounded out a bit, I will post it. I know that I am not processing the ws-addressing semantics correctly, and I have explicitly chosen not to use WSE - just because. I may look at reimplementing the code to fit into the WSE pipeline, but I haven't checked to make sure all of the stars align in WSE 2.0 SP2.
Overall, I am relatively happy with the spec, especially given its similarity to the half-drawn sketch of how I thought it should have been. It would be nice to be able to request more than one type of metadata without having to request everything. It is not that I have use cases where that is necessary, it is just that it seems much more likely that a given client is going to know which types of metadata it is going to consume, and so it would be nice to be able to explicitly request those and those only. It would also be nice to be able to choose as a client whether you want the metadata inlined, an epr to the metadata, or an uri. A possible solution: add an optional attribute to the Dialect element. The nominal case would be to inline the metadata.
<mex:GetMetadata> <mex:Dialect SomeGoodName="mex:Location">dialect-uri</mex:Dialect> <mex:Dialect SomeGoodName="mex:MetadataReference">dialect-uri</mex:Dialect> </mex:GetMetadata>
Comments