[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] MUWS: New issue to consider?
Ok, so when one talks to a manageable resource's
manageability endpoint SOAP messages will need to carry
<muws-xs:ResourceID> in the header. And therefore, EPRs will need to
contain that element in the reference properties (in addition to other
junk). That seems reasonable to me, however it does restrict the
implementations somewhat. For example, if I have that Axis thing that controls
that one and only resource, then I don't need the ResourceId in SOAP
messages. Also there may be times when ResourceId is so precious that you don't
want unauthorized access to it, so you don't want an EPR to have it, but rarher
will include some generated key which is only known to that one endpoint
implementation.
-- Igor
Sedukhin
..
(igor.sedukhin@ca.com) From: fred carter [mailto:fred.carter@amberpoint.com] Sent: Tuesday, November 16, 2004 9:19 PM To: Sedukhin, Igor S Cc: wsdm@lists.oasis-open.org Subject: Re: [wsdm] MUWS: New issue to consider? OK, I think. true, but So. A "provider" returns an EPR with a bunch of junk in it. Presumably, the EPR is returned wrapped in some element (<wsa:EndpointReference/>) that clearly identifies the parts? If so, then the client can properly marshall/bind these into its SOAP:header message section. If not, then the issue is that the collected junk will have a <wsa:Address/> and/or <wsa:To/>, but may also have an <foomgr:goodness/> element. The client can't know that this is a reference property -- reference properties have no identifying mark (when placed in a header). Assuming this is reasonably correct, things are OK. The question was more about whether we wanted to normalize on thie reference property name. If, for example, we used <muws-xs:ResourceId/> as the known reference property (since it's already required as part if identity & will presumably identify the resource), then things work out nicely for constructing EPR's, aiding in one's own "discovery", working with well-understood environments, and helping to foster interoperability. It may be slightly over-spec'd, but I think it adds some clarity and linkage to the concepts... /fred
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]