Lately I've been writing about various aspects of WS-Addressing endpoint references (EPRs). (Well, actually, lately I haven't been writing in my blog much at all, due to work (over)load.) Those various articles explored why I believe creating a SOAP-only single-protocol-only EPR as a standard would be an unnecessary mistake.
Earlier this week a group of us -- IBM, IONA, and SAP -- submitted a proposal to the WS-Addressing Working Group (WG) to modify the endpoint reference by adding a single metadata element. The intent of the optional new element is, as its name implies, to allow EPR creators to include metadata "by value" directly in the EPR. It essentially replaces the policies element with a more general metadata element. The policies element would become an optional child element of the metadata element.
The proposal garnered some interest in the WG, but was deemed to be too incomplete for a solid discussion in last Monday's teleconference. Admittedly, it was incomplete, as the write-up itself was put together quickly to meet a WG action item deadline, despite the fact that a fair bit of thinking has gone into this over the past three months. I spent yesterday and today writing up a more complete proposal that we'll post to the public WG mailing list by the end of the week.
Not surprisingly, I like the approach, because it allows EPR creators to include as much or as little "by value" metadata in the EPR as they deem necessary. It also allows an easy way to optionally include WSDL service elements by value in the EPR, which among other things solves the multi-port problem. In addition, it provides a handy place to include policy information. I would think that any metadata retrievable via WS-MetadataExchange could be cached there as well, thereby potentially saving some network round trips. In short, it takes nothing away from the existing EPR and adds no required elements or attributes, thus keeping it just as lightweight as it is today, yet it adds significant flexibility and allows the EPR to solve more use cases. I honestly don't think there are any drawbacks to this proposed change.