I find myself agreeing with Steve on this

In addition to defining addressing-related information headers for SOAP messages, WS-Addressing introduces the concept of an EndpointReference (EPR) which is used as the means of capturing the addressing-related information of a service endpoint. I don’t see why an EPR couldn’t be of the form:

<wsa:ReplyTo>

<!- Protocol-specific addresses ->

<wsa:Address>http://service.com/myservice</wsa:Address>

<wsa:Address>corba:bla-bla-bla</wsa:Address>

<wsa:Address>tcp-ip:123.123.123.123</wsa:Address>

<!- And a logical address ->

<wsa:Address>urn:my:service</wsa:Address>

</wsa:ReplyTo>

If a service wishes to make available EPRs that advertise the service’s accessibility over a number of transports, why shouldn’t we allow it to? So, I agree with Steve‘s arguments on this one.

The alternative, of course, is to have separate EPRs for each of the above <wsa:Address> elements.

Recent Posts

The Beginning of CVOYA

There’s a unique energy that comes with starting something new — a blend of excitement,…

3 weeks ago

Enhancements in Graph Model: Dynamic Entities & Full-Text Search

As I continued work on BrainExpanded and its MCP service, I came to realize that…

4 months ago

GraphModel: A .NET Abstraction for Graphs

Just over a month ago, I published "Playing with graphs and Neo4j". Back then, it…

5 months ago

Playing with graphs and neo4j

After my initial implementation of some BrainExpanded-related ideas on top of dgraph using its GraphQL…

6 months ago

A Graph Model DSL

Say hello to the Graph Model Domain Specific Language (GMDSL), created with the help of…

6 months ago

BrainExpanded – Web app and Data Sources

As I wrote in previous posts, the manual recording of memories for BrainExpanded is just…

7 months ago