[OASIS Issue Tracker] Commented: (WSDD-4) Remove dependency ondevice transport address from device metadata

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/WSDD-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15831#action_15831 ] 

Antoine Mensch commented on WSDD-4:
-----------------------------------

The proposal to resolve this issue is to allow absolute transport URLs in hosted services EPRs included in relationship metadata to be replaced by alternative information allowing a client to construct the absolute transport URL through the combination of  this information with the device transport URL (used for WS-Transfer GET request). This information should include
* scheme: optional, default to device transport URL scheme
* port: optional, default to device transport URL port
* path: mandatory

This proposal is an extension: the current syntax based on absolute transport URL would still be valid.

As exposed in the PPT attachment to this email (http://www.oasis-open.org/apps/org/workgroup/ws-dd/email/archives/200907/msg00028.html), three possible approaches could be considered to solve this issue:

1) Use a constant predefined URI plus query syntax
Ex: 
<a:EndpointReference>
  <a:Address>
   http://docs.oasis-open.org/ws-dd/ns/dpws/2009/07/HostAddress?port=9090&path=/myService/DPWSEndpoint
  </a:Address>
  <a:ReferenceParameters>...</a:ReferenceParameters>
  <a:Metadata>...</a:Metadata>
</a:EndpointReference>

Advantages:
- No change of schema required
- Reuse of well-known and standard WS-Addressing EPR element
Drawbacks:
- No change of schema required: existing clients may not identify the predefined URI as such and wrongly try to connect to the OASIS Web site

2) Use a URI template
<a:EndpointReference>
  <a:Address>http://{host.ip.address}:9090/myService/DPWSEndpoint</a:Address>
  <a:ReferenceParameters>...</a:ReferenceParameters>
  <a:Metadata>...</a:Metadata>
</a:EndpointReference>

Advantages:
- No change of schema required
- Reuse of well-known and standard WS-Addressing EPR element
Drawbacks:
- No change of schema required: existing clients may not perform the required substitution
- May require a specific URL/URI parser

3) Use of a DPWS-specific relativeEPR element
<dpws:RelativeEPR>
  <dpws:RelativeAddress path="/myService/DPWSEndpoint" port="9090"/>
  <a:ReferenceParameters>...</a:ReferenceParameters>
  <a:Metadata>...</a:Metadata>
</dpws:RelativeEPR>

Advantages:
- Proper versioning
Drawbacks:
- Introduction of a new, seemingly redundant element similar to WS-Addressing EPR

My personal preference is solution 3).


> Remove dependency on device transport address from device metadata
> ------------------------------------------------------------------
>
>                 Key: WSDD-4
>                 URL: http://tools.oasis-open.org/issues/browse/WSDD-4
>             Project: OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) TC
>          Issue Type: Improvement
>          Components:  DPWS Specification
>         Environment: N/A
>            Reporter: Antoine Mensch
>            Assignee: Antoine Mensch
>
> R0042 limits supported hosted services addresses to HTTP transport addresses (presumably absolute). As hosted services generally share the network addresses (ip ddress + port) of their hosting device, allowing relative addresses (as done for the presentationURL field) could reduce the need to duplicate endpoint references for hosted services for all the transport addresses of their hosting device. It could also help simplify the management of metadata when multiple network interfaces are used, by allowing the hosting metadata to remain constant across network interfaces. This issue has appeared when a new version of the DPWS spec has changed hosted service addresses for logical to HTTP transport. Note also that there is an inconsistency in the management of metadata: the transport addresses of devices are not covered by the metadata version, while the transport addresses of hosted services are (see R2030).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira