Sedukhin, Igor S wrote:
Re: [wsdm] MUWS: New issue to consider?
I would be fine with saying that an EPR is constructed by the
"provider" which is close to the implementation and therefore knows
where to put what. For example, if I'm a provider and I use say Axis
and I don't want to mess around with reference properties and I have
only one resource to worry about, then I will *advertize* an EPR which
has just <wsa:Address> in it. Now, if I'm a .NET with WSE
provider then I may be able to get the WSA dispatch for free and
therefore I could advertize an EPR which includes <wsa:Address>
and <wsa:ReferenceProperties> in it. So the choice is at the
"provider".
OK, I think.
The client needs to only know of WSA and how to deal with it in
either case. It does not need to know why the provider did it one way
or the other.
true, but
What is it that we can say here except "use WSA"?
What we can do though is to say use only wsa:Address and
wsa:ReferenceProperties for resource disambiguation.
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
Sedukhin, Igor S wrote:
>Didn't we say in WSRF that you may use any of the embodiments you
like
>
Well, insofar as I know, we did say that in WSRF. However, WSDM has not
yet updated to the not-yet-released WSRF spec, so I think we (meaning
WSDM) are (is) still restricted to WS-Addressing (if that's what you're
asking).
That said, I guess my question was do we/should we (for, say,
interoperability) define how our EPR is constructed. Or do we just rely
on the appropriate magic for obtaining one. I know that's probably what
we say -- I'm just not terribly comfortable with it.
>
>
>-- Igor Sedukhin .. (igor.sedukhin@ca.com)
>-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
>
>
>-----Original Message-----
>From: fred carter [mailto:fred.carter@amberpoint.com]
>Sent: Tuesday, November 16, 2004 4:23 PM
>To: wsdm@lists.oasis-open.org
>Subject: [wsdm] MUWS: New issue to consider?
>
>In reading the WS-Management spec the other day, one thing that
sticks
>out as contextually different is that they describe a normative [I
>think] mapping to WS-Addressing. That is, they make specific
reference
>to where the analogous concept to identity fits into the WS-Address.
>
>Do we need to map this? That is, to describe how to identify the
>resource in question in our WS-Address? I think that this is
currently
>missing, and I don't recall seeing it specifically addressed in WSRF
>(and it couldn't be, since they don't have an identity
capability...).
>
>Seems like we could say that there must exist a ref prop that's the
same
>as the property in the property sheet in the WS-A. This leaves open
>discovery, but that's a separate problem...
>
>Opinions?
>
>/fred
>
>
|