Q (c/o a valued customer): In the 2004/08 Devices Profile, the ServiceId Reference Property was used to distinguish a DEVICE and its HOSTED SERVICEs from each other. This allowed for a very efficient internal design (as far as resources sharing, memory, extensibility... are concerned) in case of a device hosting several services.
However, in the 2005/05 Devices Profile dropped the definition of the ServiceId Reference Property.
A (c/o Dan Conti): Before the 2005/05 revision, the Devices Profile encouraged a logical address be used in the Address portion of the endpoint reference, and that service dispatch happen based on a reference property called ServiceId. If a service was designed so that its metadata or eventing was available on a different port, this was achievable, but really required going against the "SHOULD" portions of the specification.
In the 5/05 revision, the "SHOULD" portions about logical addressing were removed and the dispatch model was made more flexible. There is no requirement for ServiceId in service endpoint reference properties but any implementation could choose to add such a reference property and clients would be required to provide it per WS-Addressing when communicating with the service. It is an issue of unfortunate naming, but the relationship section now provides a way to associate multiple endpoints to the same service using a new ServiceId field. This is 5.2 line 538.
Given this, any scenario that was achievable in the previous revision of the Devices Profile is still achievable in the current version - there are no "scenario regressions". If you would like to have all incoming requests go to a single port it is possible; there is no requirement that the address portion of the service endpoints be unique, just that the complete endpoints be unique enough to allow dispatch to different services.
Posted
Sep 29 2005, 09:26 PM
by
jeffrey-schlimmer